From 7b786b2ec9d056c2cfc46e447839d1e68bcb2b5f Mon Sep 17 00:00:00 2001 From: m-bochenek <62942399+m-bochenek@users.noreply.github.com> Date: Wed, 22 Apr 2026 17:38:22 +0100 Subject: [PATCH 01/20] Editing the GET STARTED section of the TOC --- source/Capabilities.rst | 20 +++++++++++++++ .../Testing}/Testing.rst | 0 source/Get-Started.rst | 24 ++++++++++++++++++ source/{ => Get-Started}/About-ROS.rst | 0 .../Configuring-ROS2-Environment.rst | 0 source/{ => Get-Started}/Installation.rst | 14 +++++----- .../Installation/Alternatives.rst | 3 ++- .../Alternatives/Latest-Development-Setup.rst | 0 .../Maintaining-a-Source-Checkout.rst | 0 .../Alternatives/RHEL-Development-Setup.rst | 0 .../Alternatives/RHEL-Install-Binary.rst | 0 .../Alternatives/Ubuntu-Development-Setup.rst | 0 .../Alternatives/Ubuntu-Install-Binary.rst | 0 .../Windows-Development-Setup.rst | 0 .../Alternatives/macOS-Development-Setup.rst | 0 .../Installation/RHEL-Install-RPMs.rst | 0 .../Installation/RMW-Implementations.rst | 0 .../DDS-Implementations.rst | 0 .../Working-with-Eclipse-CycloneDDS.rst | 0 .../Working-with-GurumNetworks-GurumDDS.rst | 0 .../Working-with-RTI-Connext-DDS.rst | 0 .../Working-with-eProsima-Fast-DDS.rst | 0 .../Non-DDS-Implementations.rst | 0 .../Working-with-Zenoh.rst | 0 .../Installation/ROS-2-Mirrors.rst | 0 .../Installation/Ubuntu-Install-Debs.rst | 0 .../Installation/Windows-Install-Binary.rst | 0 .../Installation/_Apt-Repositories.rst | 0 .../Installation/_Apt-Upgrade-Admonition.rst | 0 .../Installation/_Dnf-Update-Admonition.rst | 0 .../Installation/_RHEL-Set-Locale.rst | 0 .../Installation/_Ubuntu-Set-Locale.rst | 0 .../Installation/_rosdep_Linux_Mint.rst | 0 .../python_installation_enable_debug.png | Bin .../images/python_installation_modify.png | Bin .../images/python_installation_next.png | Bin .../images/vs_community_screenshot.png | Bin .../images/windows-vs-studio-install.png | Bin .../Introducing-Turtlesim.rst | 0 .../Introducing-Turtlesim/images/new_pen.png | Bin .../Introducing-Turtlesim/images/remap.png | Bin .../Introducing-Turtlesim/images/rqt.png | Bin .../Introducing-Turtlesim/images/set_pen.png | Bin .../Introducing-Turtlesim/images/spawn.png | Bin .../images/turtlesim.png | Bin source/{ => Get-Started}/Releases.rst | 16 ++++++------ .../Releases/Alpha-Overview.rst | 0 .../Releases/Beta1-Overview.rst | 0 .../Releases/Beta2-Overview.rst | 0 .../Releases/Beta3-Overview.rst | 0 .../Releases/Development.rst | 0 .../Releases/End-of-Life.rst | 0 ...Galactic-Geochelone-Complete-Changelog.rst | 0 .../Humble-Hawksbill-Complete-Changelog.rst | 0 .../Iron-Irwini-Complete-Changelog.rst | 0 .../Jazzy-Jalisco-Complete-Changelog.rst | 0 .../Kilted-Kaiju-Complete-Changelog.rst | 0 .../Releases/Release-Ardent-Apalone.rst | 0 .../Releases/Release-Bouncy-Bolson.rst | 0 .../Releases/Release-Crystal-Clemmys.rst | 0 .../Releases/Release-Dashing-Diademata.rst | 0 .../Releases/Release-Eloquent-Elusor.rst | 0 .../Releases/Release-Foxy-Fitzroy.rst | 0 .../Releases/Release-Galactic-Geochelone.rst | 0 .../Releases/Release-Humble-Hawksbill.rst | 0 .../Releases/Release-Iron-Irwini.rst | 0 .../Releases/Release-Jazzy-Jalisco.rst | 0 .../Releases/Release-Kilted-Kaiju.rst | 0 .../Releases/Release-Lyrical-Luth.rst | 0 .../Releases/Release-Process.rst | 0 .../Releases/Release-Rolling-Ridley.rst | 0 .../Releases/ardent-small.png | Bin .../Releases/bouncy-small.png | Bin .../Releases/crystal-small.png | Bin .../Releases/dashing-small.png | Bin .../Releases/eloquent-small.png | Bin .../{ => Get-Started}/Releases/foxy-small.png | Bin .../Releases/galactic-small.png | Bin .../Releases/humble-small.png | Bin ...t_graph-qos-incompatibility-2021-05-17.png | Bin .../images/rviz2-far-plane-distance.png | Bin .../Releases/images/rviz_mass_inertia.png | Bin .../Releases/images/tb4_inertia.png | Bin .../images/triangle_marker_with_gradient.png | Bin .../{ => Get-Started}/Releases/iron-small.png | Bin .../Releases/jazzy-small.png | Bin .../Releases/kilted-small.png | Bin .../Releases/rolling-small.png | Bin .../Releases/rviz2-time-panel-2021-05-17.png | Bin source/ROS-Framework.rst | 20 +++++++++++++++ 90 files changed, 80 insertions(+), 17 deletions(-) create mode 100644 source/Capabilities.rst rename source/{Installation => Developer-Tools/Testing}/Testing.rst (100%) create mode 100644 source/Get-Started.rst rename source/{ => Get-Started}/About-ROS.rst (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Configuring-ROS2-Environment.rst (100%) rename source/{ => Get-Started}/Installation.rst (92%) rename source/{ => Get-Started}/Installation/Alternatives.rst (81%) rename source/{ => Get-Started}/Installation/Alternatives/Latest-Development-Setup.rst (100%) rename source/{Installation => Get-Started/Installation/Alternatives}/Maintaining-a-Source-Checkout.rst (100%) rename source/{ => Get-Started}/Installation/Alternatives/RHEL-Development-Setup.rst (100%) rename source/{ => Get-Started}/Installation/Alternatives/RHEL-Install-Binary.rst (100%) rename source/{ => Get-Started}/Installation/Alternatives/Ubuntu-Development-Setup.rst (100%) rename source/{ => Get-Started}/Installation/Alternatives/Ubuntu-Install-Binary.rst (100%) rename source/{ => Get-Started}/Installation/Alternatives/Windows-Development-Setup.rst (100%) rename source/{ => Get-Started}/Installation/Alternatives/macOS-Development-Setup.rst (100%) rename source/{ => Get-Started}/Installation/RHEL-Install-RPMs.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/DDS-Implementations.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/Non-DDS-Implementations.rst (100%) rename source/{ => Get-Started}/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst (100%) rename source/{ => Get-Started}/Installation/ROS-2-Mirrors.rst (100%) rename source/{ => Get-Started}/Installation/Ubuntu-Install-Debs.rst (100%) rename source/{ => Get-Started}/Installation/Windows-Install-Binary.rst (100%) rename source/{ => Get-Started}/Installation/_Apt-Repositories.rst (100%) rename source/{ => Get-Started}/Installation/_Apt-Upgrade-Admonition.rst (100%) rename source/{ => Get-Started}/Installation/_Dnf-Update-Admonition.rst (100%) rename source/{ => Get-Started}/Installation/_RHEL-Set-Locale.rst (100%) rename source/{ => Get-Started}/Installation/_Ubuntu-Set-Locale.rst (100%) rename source/{ => Get-Started}/Installation/_rosdep_Linux_Mint.rst (100%) rename source/{ => Get-Started}/Installation/images/python_installation_enable_debug.png (100%) rename source/{ => Get-Started}/Installation/images/python_installation_modify.png (100%) rename source/{ => Get-Started}/Installation/images/python_installation_next.png (100%) rename source/{ => Get-Started}/Installation/images/vs_community_screenshot.png (100%) rename source/{ => Get-Started}/Installation/images/windows-vs-studio-install.png (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/Introducing-Turtlesim.rst (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/images/new_pen.png (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/images/remap.png (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/images/rqt.png (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/images/set_pen.png (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/images/spawn.png (100%) rename source/{Tutorials/Beginner-CLI-Tools => Get-Started}/Introducing-Turtlesim/images/turtlesim.png (100%) rename source/{ => Get-Started}/Releases.rst (96%) rename source/{ => Get-Started}/Releases/Alpha-Overview.rst (100%) rename source/{ => Get-Started}/Releases/Beta1-Overview.rst (100%) rename source/{ => Get-Started}/Releases/Beta2-Overview.rst (100%) rename source/{ => Get-Started}/Releases/Beta3-Overview.rst (100%) rename source/{ => Get-Started}/Releases/Development.rst (100%) rename source/{ => Get-Started}/Releases/End-of-Life.rst (100%) rename source/{ => Get-Started}/Releases/Galactic-Geochelone-Complete-Changelog.rst (100%) rename source/{ => Get-Started}/Releases/Humble-Hawksbill-Complete-Changelog.rst (100%) rename source/{ => Get-Started}/Releases/Iron-Irwini-Complete-Changelog.rst (100%) rename source/{ => Get-Started}/Releases/Jazzy-Jalisco-Complete-Changelog.rst (100%) rename source/{ => Get-Started}/Releases/Kilted-Kaiju-Complete-Changelog.rst (100%) rename source/{ => Get-Started}/Releases/Release-Ardent-Apalone.rst (100%) rename source/{ => Get-Started}/Releases/Release-Bouncy-Bolson.rst (100%) rename source/{ => Get-Started}/Releases/Release-Crystal-Clemmys.rst (100%) rename source/{ => Get-Started}/Releases/Release-Dashing-Diademata.rst (100%) rename source/{ => Get-Started}/Releases/Release-Eloquent-Elusor.rst (100%) rename source/{ => Get-Started}/Releases/Release-Foxy-Fitzroy.rst (100%) rename source/{ => Get-Started}/Releases/Release-Galactic-Geochelone.rst (100%) rename source/{ => Get-Started}/Releases/Release-Humble-Hawksbill.rst (100%) rename source/{ => Get-Started}/Releases/Release-Iron-Irwini.rst (100%) rename source/{ => Get-Started}/Releases/Release-Jazzy-Jalisco.rst (100%) rename source/{ => Get-Started}/Releases/Release-Kilted-Kaiju.rst (100%) rename source/{ => Get-Started}/Releases/Release-Lyrical-Luth.rst (100%) rename source/{ => Get-Started}/Releases/Release-Process.rst (100%) rename source/{ => Get-Started}/Releases/Release-Rolling-Ridley.rst (100%) rename source/{ => Get-Started}/Releases/ardent-small.png (100%) rename source/{ => Get-Started}/Releases/bouncy-small.png (100%) rename source/{ => Get-Started}/Releases/crystal-small.png (100%) rename source/{ => Get-Started}/Releases/dashing-small.png (100%) rename source/{ => Get-Started}/Releases/eloquent-small.png (100%) rename source/{ => Get-Started}/Releases/foxy-small.png (100%) rename source/{ => Get-Started}/Releases/galactic-small.png (100%) rename source/{ => Get-Started}/Releases/humble-small.png (100%) rename source/{ => Get-Started}/Releases/images/rqt_graph-qos-incompatibility-2021-05-17.png (100%) rename source/{ => Get-Started}/Releases/images/rviz2-far-plane-distance.png (100%) rename source/{ => Get-Started}/Releases/images/rviz_mass_inertia.png (100%) rename source/{ => Get-Started}/Releases/images/tb4_inertia.png (100%) rename source/{ => Get-Started}/Releases/images/triangle_marker_with_gradient.png (100%) rename source/{ => Get-Started}/Releases/iron-small.png (100%) rename source/{ => Get-Started}/Releases/jazzy-small.png (100%) rename source/{ => Get-Started}/Releases/kilted-small.png (100%) rename source/{ => Get-Started}/Releases/rolling-small.png (100%) rename source/{ => Get-Started}/Releases/rviz2-time-panel-2021-05-17.png (100%) create mode 100644 source/ROS-Framework.rst diff --git a/source/Capabilities.rst b/source/Capabilities.rst new file mode 100644 index 00000000000..45a954048e3 --- /dev/null +++ b/source/Capabilities.rst @@ -0,0 +1,20 @@ +.. _InstallationGuide: +.. _RollingInstall: + +Capabilities +============ + +PLACEHOLDER + +.. toctree:: + :hidden: + :glob: + + Installation/Ubuntu-Install-Debs + Installation/Windows-Install-Binary + Installation/RHEL-Install-RPMs + Installation/Alternatives + Installation/Maintaining-a-Source-Checkout + Installation/Testing + Installation/RMW-Implementations + Installation/ROS-2-Mirrors diff --git a/source/Installation/Testing.rst b/source/Developer-Tools/Testing/Testing.rst similarity index 100% rename from source/Installation/Testing.rst rename to source/Developer-Tools/Testing/Testing.rst diff --git a/source/Get-Started.rst b/source/Get-Started.rst new file mode 100644 index 00000000000..c3241747466 --- /dev/null +++ b/source/Get-Started.rst @@ -0,0 +1,24 @@ +.. _InstallationGuide: +.. _RollingInstall: + +Get started +============ + +PLACEHOLDER + +.. toctree:: + :maxdepth: 1 + :hidden: + + Get-Started/About-ROS + Get-Started/Installation/Ubuntu-Install-Debs + Get-Started/Installation/Windows-Install-Binary + Get-Started/Installation/RHEL-Install-RPMs + Get-Started/Installation/Alternatives + Get-Started/Installation/Maintaining-a-Source-Checkout + Get-Started/Installation/Testing + Get-Started/Installation/RMW-Implementations + Get-Started/Installation/ROS-2-Mirrors + Get-Started/Releases + Get-Started/Configuring-ROS2-Environment + Get-Started/Introducing-Turtlesim \ No newline at end of file diff --git a/source/About-ROS.rst b/source/Get-Started/About-ROS.rst similarity index 100% rename from source/About-ROS.rst rename to source/Get-Started/About-ROS.rst diff --git a/source/Tutorials/Beginner-CLI-Tools/Configuring-ROS2-Environment.rst b/source/Get-Started/Configuring-ROS2-Environment.rst similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Configuring-ROS2-Environment.rst rename to source/Get-Started/Configuring-ROS2-Environment.rst diff --git a/source/Installation.rst b/source/Get-Started/Installation.rst similarity index 92% rename from source/Installation.rst rename to source/Get-Started/Installation.rst index 5f0ec3f0722..a4f445ba608 100644 --- a/source/Installation.rst +++ b/source/Get-Started/Installation.rst @@ -10,14 +10,12 @@ Options for installing ROS 2 {DISTRO_TITLE_FULL}: :hidden: :glob: - Installation/Ubuntu-Install-Debs - Installation/Windows-Install-Binary - Installation/RHEL-Install-RPMs - Installation/Alternatives - Installation/Maintaining-a-Source-Checkout - Installation/Testing - Installation/RMW-Implementations - Installation/ROS-2-Mirrors + Get-Started/Installation/Ubuntu-Install-Debs + Get-Started/Installation/Windows-Install-Binary + Get-Started/Installation/RHEL-Install-RPMs + Get-Started/Installation/Alternatives + Get-Started/Installation/RMW-Implementations + Get-Started/Installation/ROS-2-Mirrors .. _binary-package-platforms: diff --git a/source/Installation/Alternatives.rst b/source/Get-Started/Installation/Alternatives.rst similarity index 81% rename from source/Installation/Alternatives.rst rename to source/Get-Started/Installation/Alternatives.rst index 4a05c841222..8bad2cbfdc1 100644 --- a/source/Installation/Alternatives.rst +++ b/source/Get-Started/Installation/Alternatives.rst @@ -1,4 +1,4 @@ -Alternatives +Advanced installation options ============ A list of alternative ways to install ROS 2 – whether it's by building from source or installing a binary. @@ -13,3 +13,4 @@ A list of alternative ways to install ROS 2 – whether it's by building from s Alternatives/RHEL-Install-Binary Alternatives/macOS-Development-Setup Alternatives/Latest-Development-Setup + Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout diff --git a/source/Installation/Alternatives/Latest-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst similarity index 100% rename from source/Installation/Alternatives/Latest-Development-Setup.rst rename to source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst diff --git a/source/Installation/Maintaining-a-Source-Checkout.rst b/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst similarity index 100% rename from source/Installation/Maintaining-a-Source-Checkout.rst rename to source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst diff --git a/source/Installation/Alternatives/RHEL-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst similarity index 100% rename from source/Installation/Alternatives/RHEL-Development-Setup.rst rename to source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst diff --git a/source/Installation/Alternatives/RHEL-Install-Binary.rst b/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst similarity index 100% rename from source/Installation/Alternatives/RHEL-Install-Binary.rst rename to source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst diff --git a/source/Installation/Alternatives/Ubuntu-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst similarity index 100% rename from source/Installation/Alternatives/Ubuntu-Development-Setup.rst rename to source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst diff --git a/source/Installation/Alternatives/Ubuntu-Install-Binary.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst similarity index 100% rename from source/Installation/Alternatives/Ubuntu-Install-Binary.rst rename to source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst diff --git a/source/Installation/Alternatives/Windows-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst similarity index 100% rename from source/Installation/Alternatives/Windows-Development-Setup.rst rename to source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst diff --git a/source/Installation/Alternatives/macOS-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst similarity index 100% rename from source/Installation/Alternatives/macOS-Development-Setup.rst rename to source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst diff --git a/source/Installation/RHEL-Install-RPMs.rst b/source/Get-Started/Installation/RHEL-Install-RPMs.rst similarity index 100% rename from source/Installation/RHEL-Install-RPMs.rst rename to source/Get-Started/Installation/RHEL-Install-RPMs.rst diff --git a/source/Installation/RMW-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations.rst similarity index 100% rename from source/Installation/RMW-Implementations.rst rename to source/Get-Started/Installation/RMW-Implementations.rst diff --git a/source/Installation/RMW-Implementations/DDS-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst similarity index 100% rename from source/Installation/RMW-Implementations/DDS-Implementations.rst rename to source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst diff --git a/source/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst similarity index 100% rename from source/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst rename to source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst diff --git a/source/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst similarity index 100% rename from source/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst rename to source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst diff --git a/source/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst similarity index 100% rename from source/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst rename to source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst diff --git a/source/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst similarity index 100% rename from source/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst rename to source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst diff --git a/source/Installation/RMW-Implementations/Non-DDS-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst similarity index 100% rename from source/Installation/RMW-Implementations/Non-DDS-Implementations.rst rename to source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst diff --git a/source/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst similarity index 100% rename from source/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst rename to source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst diff --git a/source/Installation/ROS-2-Mirrors.rst b/source/Get-Started/Installation/ROS-2-Mirrors.rst similarity index 100% rename from source/Installation/ROS-2-Mirrors.rst rename to source/Get-Started/Installation/ROS-2-Mirrors.rst diff --git a/source/Installation/Ubuntu-Install-Debs.rst b/source/Get-Started/Installation/Ubuntu-Install-Debs.rst similarity index 100% rename from source/Installation/Ubuntu-Install-Debs.rst rename to source/Get-Started/Installation/Ubuntu-Install-Debs.rst diff --git a/source/Installation/Windows-Install-Binary.rst b/source/Get-Started/Installation/Windows-Install-Binary.rst similarity index 100% rename from source/Installation/Windows-Install-Binary.rst rename to source/Get-Started/Installation/Windows-Install-Binary.rst diff --git a/source/Installation/_Apt-Repositories.rst b/source/Get-Started/Installation/_Apt-Repositories.rst similarity index 100% rename from source/Installation/_Apt-Repositories.rst rename to source/Get-Started/Installation/_Apt-Repositories.rst diff --git a/source/Installation/_Apt-Upgrade-Admonition.rst b/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst similarity index 100% rename from source/Installation/_Apt-Upgrade-Admonition.rst rename to source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst diff --git a/source/Installation/_Dnf-Update-Admonition.rst b/source/Get-Started/Installation/_Dnf-Update-Admonition.rst similarity index 100% rename from source/Installation/_Dnf-Update-Admonition.rst rename to source/Get-Started/Installation/_Dnf-Update-Admonition.rst diff --git a/source/Installation/_RHEL-Set-Locale.rst b/source/Get-Started/Installation/_RHEL-Set-Locale.rst similarity index 100% rename from source/Installation/_RHEL-Set-Locale.rst rename to source/Get-Started/Installation/_RHEL-Set-Locale.rst diff --git a/source/Installation/_Ubuntu-Set-Locale.rst b/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst similarity index 100% rename from source/Installation/_Ubuntu-Set-Locale.rst rename to source/Get-Started/Installation/_Ubuntu-Set-Locale.rst diff --git a/source/Installation/_rosdep_Linux_Mint.rst b/source/Get-Started/Installation/_rosdep_Linux_Mint.rst similarity index 100% rename from source/Installation/_rosdep_Linux_Mint.rst rename to source/Get-Started/Installation/_rosdep_Linux_Mint.rst diff --git a/source/Installation/images/python_installation_enable_debug.png b/source/Get-Started/Installation/images/python_installation_enable_debug.png similarity index 100% rename from source/Installation/images/python_installation_enable_debug.png rename to source/Get-Started/Installation/images/python_installation_enable_debug.png diff --git a/source/Installation/images/python_installation_modify.png b/source/Get-Started/Installation/images/python_installation_modify.png similarity index 100% rename from source/Installation/images/python_installation_modify.png rename to source/Get-Started/Installation/images/python_installation_modify.png diff --git a/source/Installation/images/python_installation_next.png b/source/Get-Started/Installation/images/python_installation_next.png similarity index 100% rename from source/Installation/images/python_installation_next.png rename to source/Get-Started/Installation/images/python_installation_next.png diff --git a/source/Installation/images/vs_community_screenshot.png b/source/Get-Started/Installation/images/vs_community_screenshot.png similarity index 100% rename from source/Installation/images/vs_community_screenshot.png rename to source/Get-Started/Installation/images/vs_community_screenshot.png diff --git a/source/Installation/images/windows-vs-studio-install.png b/source/Get-Started/Installation/images/windows-vs-studio-install.png similarity index 100% rename from source/Installation/images/windows-vs-studio-install.png rename to source/Get-Started/Installation/images/windows-vs-studio-install.png diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim.rst b/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim.rst rename to source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/new_pen.png b/source/Get-Started/Introducing-Turtlesim/images/new_pen.png similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/new_pen.png rename to source/Get-Started/Introducing-Turtlesim/images/new_pen.png diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/remap.png b/source/Get-Started/Introducing-Turtlesim/images/remap.png similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/remap.png rename to source/Get-Started/Introducing-Turtlesim/images/remap.png diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/rqt.png b/source/Get-Started/Introducing-Turtlesim/images/rqt.png similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/rqt.png rename to source/Get-Started/Introducing-Turtlesim/images/rqt.png diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/set_pen.png b/source/Get-Started/Introducing-Turtlesim/images/set_pen.png similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/set_pen.png rename to source/Get-Started/Introducing-Turtlesim/images/set_pen.png diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/spawn.png b/source/Get-Started/Introducing-Turtlesim/images/spawn.png similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/spawn.png rename to source/Get-Started/Introducing-Turtlesim/images/spawn.png diff --git a/source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/turtlesim.png b/source/Get-Started/Introducing-Turtlesim/images/turtlesim.png similarity index 100% rename from source/Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/images/turtlesim.png rename to source/Get-Started/Introducing-Turtlesim/images/turtlesim.png diff --git a/source/Releases.rst b/source/Get-Started/Releases.rst similarity index 96% rename from source/Releases.rst rename to source/Get-Started/Releases.rst index 7a050c1476e..7007cc415fe 100644 --- a/source/Releases.rst +++ b/source/Get-Started/Releases.rst @@ -23,14 +23,14 @@ Rows in the table marked in blue are the currently supported distributions. .. toctree:: :hidden: - Releases/Release-Kilted-Kaiju - Releases/Release-Jazzy-Jalisco - Releases/Release-Humble-Hawksbill - Releases/Release-Rolling-Ridley - Releases/Development - Releases/End-of-Life - Releases/Release-Process - + Get-Started/Releases/Release-Process + Get-Started/Releases/Release-Kilted-Kaiju + Get-Started/Releases/Release-Jazzy-Jalisco + Get-Started/Releases/Release-Humble-Hawksbill + Get-Started/Releases/Release-Rolling-Ridley + Get-Started/Releases/Development + Get-Started/Releases/End-of-Life + .. raw:: html - - - rosdoc2.yaml - - - -However, for most packages, the default settings in ``rosdoc2`` will suffice, and no custom config is necessary. -More information about ``rosdoc2.yaml`` can be found in the `rosdoc2 readme `__. - -conf.py, rosdoc2_settings -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The final output of the package docs is (almost) always built by Sphinx. -Each Sphinx project is configured by a ``conf.py`` file in the ``doc`` directory. -If no configuration is present, a default Sphinx project is created and used when building the documentation. -If however a ``conf.py`` Sphinx config is found in the ``doc`` subdirectory of the package, this is used instead. -A custom Sphinx project is required if you want to include a standalone reStructuredText documentation page. -A standalone documentation page can be used to list multiple tutorials and guides; if that's something you want for your package you'll need to create a custom Sphinx project. - -``rosdoc2`` provides additional settings to ``conf.py`` and overrides some. -Information about changes done to the Sphinx settings are logged to the console with a ``[rosdoc2]`` prefix. - -Doxyfile -^^^^^^^^ - -Doxygen is a tool for automatically generating C++ API docs from code comments. -While Doxygen can also generate HTML output directly, in the usual workflow for ROS packages, Doxygen produces machine readable output in XML format which is then consumed by Sphinx and integrated with the rest of the documentation. -Doxygen-only docs are possible by only enabling the Doxygen builder in ``rosdoc2.yaml``, but this is uncommon. - -Customizing Sphinx Documentation --------------------------------- - -Creating a Sphinx Project -^^^^^^^^^^^^^^^^^^^^^^^^^ - -In order to add standalone documentation pages in addition to the automatically generated API docs, a custom Sphinx project is necessary. -This should be created in a subdirectory called ``doc`` in the package directory. -A new Sphinx project can be created by running ``sphinx-quickstart`` in the ``doc`` directory, answering ``no`` to "Separate source and build directories". -The wizard requires entering the project name, author and version, but this can later be removed and will be provided to Sphinx by ``rosdoc2`` from your packages ``package.xml``. -More information about creating a sphinx project can be found on the `Sphinx quickstart page `__, - -Customizing ``index.rst`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``sphinx-quickstart`` wizard creates an ``index.rst`` file, which is the custom landing page for your package, similar to a Github ``README`` file. - -Adding Python API-Docs -^^^^^^^^^^^^^^^^^^^^^^ - -By default ``rosdoc2`` uses the `sphinx-apidoc tool `__ and the `autodoc Sphinx extension `__ to automatically generate documentation for python code. -In order for autodoc to find the Python modules in your package, it must be added to the python search path in ``conf.py``: - -.. code-block:: python - - sys.path.insert(0, os.path.abspath('.')) - -This is because ``rosdoc2`` wraps the custom ``conf.py`` with more configuration from a script which will be placed in the package. -In this case the ``.`` path in ``os.path.abspath`` refers to the package's directory root, not the package's ``doc`` directory due to the interaction between rosdoc2 and ``conf.py``. - -By default, package API docs are already reachable through the "Module Index" link that is present on the landing page. -For the API docs to also appear in the table of contents, simply add a link to the ``modules`` page to your ``index.rst``: - -.. code-block:: rst - - .. toctree:: - :maxdepth: 2 - :caption: Contents: - - Python Modules - -Adding C++ API-Docs -^^^^^^^^^^^^^^^^^^^ - -If you would like to add your automatically generated API docs back to your custom landing page, add the line ``generated/index`` to your documentation page where you would like the API docs to appear: - -.. code-block:: rst - - .. toctree:: - :maxdepth: 2 - - C++ API Docs - -This adds the elements "Class Hierarchy", "File Hierarchy" and "Reference" to the table of contents in the sidebar. -To make those appear under one "C++ API Docs" heading for a less cluttered sidebar, a separate file such as ``cpp_api_docs.rst`` can be added, which links to the generated docs: - -.. code-block:: rst - :caption: cpp_api_docs.rst - - C++ API Docs - ============ - - These are the autogenerated docs for the internal implementation. - - .. toctree:: - :maxdepth: 3 - :caption: Contents: - - generated/index - -Which then also needs to be added in ``index.rst`` to appear in the sidebar: - -.. code-block:: rst - :caption: index.rst - - .. toctree:: - :maxdepth: 2 - :caption: Contents: - - cpp_api_docs - - -Including an existing README.md -------------------------------- - -If your git repository already has an existing ``README.md``, it is possible to reuse this as the landing page for the documentation, without duplicating the contents. -To correctly include a Markdown file in Sphinx while preserving relative links and images, some additional effort is required. - -First, create a proxy-file ``readme_include.md`` next to ``index.rst``. -This is a markdown file which just includes the original README.md, but preserves the relative image paths, which would otherwise break in the next step: - -.. code-block:: markdown - :caption: readme_include.md - - ```{include} ../README.md - :relative-images: - ``` - - -Then, include the contents of this file from ``index.rst`` using ``myst`` to include markdown from rst: - -.. code-block:: rst - :caption: index.rst - - .. include:: readme_include.md - :parser: myst_parser.sphinx_ - - -This also requires adding ``myst_parser`` to the extensions in ``conf.py``: - -.. code-block:: python - :caption: conf.py - - extensions = ["myst_parser"] - - -CI, docs.ros.org ----------------- - -The ROS build farm uses ``rosdoc2`` to build the package documentation hosted at ``docs.ros.org/en//p//``. -To enable this, the repository containing the documentation must be configured in `rosdistro/{DISTRO}/distribution.yaml `__. -This would usually be the package source repository: - -.. code-block:: yaml - - : - doc: - type: git - url: https://github.com//.git - version: main - release: - [...] - -The buildfarm hosts the documentation for every distribution separately, and periodically rebuilds it from the latest commit on the specified branch. -It is not required to tag a new release to update the hosted documentation. -To view the status of your package's documentation build, search for ``doc__`` on ``__. -One job is created for every distribution for which the package is released. -On each job page, you can see when a build was last triggered, as well as the status and logs of each build. - -Further Reading ---------------- - -* `rosdoc2 readme `_ -* `ROS 2 design document on package documentation `_ -* `The ROS 2 cookbook `_ +.. redirect-from:: + + How-To-Guides/Documenting-a-ROS-2-Package + +Documenting a ROS 2 package +########################### + +.. contents:: Table of Contents + :depth: 2 + :local: + + +This guide introduces the standard way to create documentation for ROS 2 packages. +For packages with binary releases this also results in the docs being hosted at ``docs.ros.org/en//p//``. +For information on how to contribute to this documentation on docs.ros.org, see :doc:`Contributing to ROS 2 Documentation <../../The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation>`. + +Prerequisites +------------- + +- :doc:`Install ROS <../../Installation>` + +- `Install rosdoc2 `__ + +Package Documentation Overview +------------------------------ + +The type of documentation discussed in this guide is referred to as "package docs" or "API docs". +For ROS packages that have been released on ROS Index, their documentation will be built on the ROS buildfarm, included on docs.ros.org, and visible via the ``API Docs`` button on index.ros.org. + +The tool responsible for generating ROS 2 package docs is `rosdoc2 `__. + +``rosdoc2`` is a convenient wrapper around the commonly used `Sphinx `__ documentation framework. +Sphinx allows freeform written documentation as well as API documentation for python code generated from comments in the code. +The `breathe `__ + `exhale `__ packages allow integration with Doxygen, to include autogenerated C++ API documentation as well. + +``rosdoc2`` creates a default configuration for packages with no documentation or configuration at all, and applies options for a uniform theme and integration with other packages. + +Building Package Docs +--------------------- + +To generate the documentation for a package in HTML format with ``rosdoc2``, run: + +.. code-block:: console + + $ rosdoc2 build --package-path + +The documentation is written to ``docs_output//index.html`` and can be viewed in a browser. + +Configuration +------------- + +There are three configuration locations for ROS package docs: ``rosdoc2.yaml`` for general settings, +``conf.py`` for sphinx settings and the ``Doxyfile`` for doxygen settings. +For all of those, a default is assumed or generated if not present, so none of them is strictly required. +However, it might be necessary to create and modify those once you want to use features such as custom textual documentation pages. + +rosdoc2.yaml +^^^^^^^^^^^^ + +This is the main entrypoint for rosdoc2. +It specifies generic settings, and can be used to control the execution of specific builders (Doxygen and Sphinx) and decides which builders to run. + +``rosdoc2`` provides a multitude of configuration options, which can be adjusted in a config file ``rosdoc2.yaml``. +To generate a default ``rosdoc2.yaml`` which you can then further customize, run: + +.. code-block:: console + + $ rosdoc2 default_config --package-path + +And add ``rosdoc2.yaml`` to the export section in your ``package.xml``: + +.. code-block:: xml + + + + + + rosdoc2.yaml + + + +However, for most packages, the default settings in ``rosdoc2`` will suffice, and no custom config is necessary. +More information about ``rosdoc2.yaml`` can be found in the `rosdoc2 readme `__. + +conf.py, rosdoc2_settings +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The final output of the package docs is (almost) always built by Sphinx. +Each Sphinx project is configured by a ``conf.py`` file in the ``doc`` directory. +If no configuration is present, a default Sphinx project is created and used when building the documentation. +If however a ``conf.py`` Sphinx config is found in the ``doc`` subdirectory of the package, this is used instead. +A custom Sphinx project is required if you want to include a standalone reStructuredText documentation page. +A standalone documentation page can be used to list multiple tutorials and guides; if that's something you want for your package you'll need to create a custom Sphinx project. + +``rosdoc2`` provides additional settings to ``conf.py`` and overrides some. +Information about changes done to the Sphinx settings are logged to the console with a ``[rosdoc2]`` prefix. + +Doxyfile +^^^^^^^^ + +Doxygen is a tool for automatically generating C++ API docs from code comments. +While Doxygen can also generate HTML output directly, in the usual workflow for ROS packages, Doxygen produces machine readable output in XML format which is then consumed by Sphinx and integrated with the rest of the documentation. +Doxygen-only docs are possible by only enabling the Doxygen builder in ``rosdoc2.yaml``, but this is uncommon. + +Customizing Sphinx Documentation +-------------------------------- + +Creating a Sphinx Project +^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to add standalone documentation pages in addition to the automatically generated API docs, a custom Sphinx project is necessary. +This should be created in a subdirectory called ``doc`` in the package directory. +A new Sphinx project can be created by running ``sphinx-quickstart`` in the ``doc`` directory, answering ``no`` to "Separate source and build directories". +The wizard requires entering the project name, author and version, but this can later be removed and will be provided to Sphinx by ``rosdoc2`` from your packages ``package.xml``. +More information about creating a sphinx project can be found on the `Sphinx quickstart page `__, + +Customizing ``index.rst`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``sphinx-quickstart`` wizard creates an ``index.rst`` file, which is the custom landing page for your package, similar to a Github ``README`` file. + +Adding Python API-Docs +^^^^^^^^^^^^^^^^^^^^^^ + +By default ``rosdoc2`` uses the `sphinx-apidoc tool `__ and the `autodoc Sphinx extension `__ to automatically generate documentation for python code. +In order for autodoc to find the Python modules in your package, it must be added to the python search path in ``conf.py``: + +.. code-block:: python + + sys.path.insert(0, os.path.abspath('.')) + +This is because ``rosdoc2`` wraps the custom ``conf.py`` with more configuration from a script which will be placed in the package. +In this case the ``.`` path in ``os.path.abspath`` refers to the package's directory root, not the package's ``doc`` directory due to the interaction between rosdoc2 and ``conf.py``. + +By default, package API docs are already reachable through the "Module Index" link that is present on the landing page. +For the API docs to also appear in the table of contents, simply add a link to the ``modules`` page to your ``index.rst``: + +.. code-block:: rst + + .. toctree:: + :maxdepth: 2 + :caption: Contents: + + Python Modules + +Adding C++ API-Docs +^^^^^^^^^^^^^^^^^^^ + +If you would like to add your automatically generated API docs back to your custom landing page, add the line ``generated/index`` to your documentation page where you would like the API docs to appear: + +.. code-block:: rst + + .. toctree:: + :maxdepth: 2 + + C++ API Docs + +This adds the elements "Class Hierarchy", "File Hierarchy" and "Reference" to the table of contents in the sidebar. +To make those appear under one "C++ API Docs" heading for a less cluttered sidebar, a separate file such as ``cpp_api_docs.rst`` can be added, which links to the generated docs: + +.. code-block:: rst + :caption: cpp_api_docs.rst + + C++ API Docs + ============ + + These are the autogenerated docs for the internal implementation. + + .. toctree:: + :maxdepth: 3 + :caption: Contents: + + generated/index + +Which then also needs to be added in ``index.rst`` to appear in the sidebar: + +.. code-block:: rst + :caption: index.rst + + .. toctree:: + :maxdepth: 2 + :caption: Contents: + + cpp_api_docs + + +Including an existing README.md +------------------------------- + +If your git repository already has an existing ``README.md``, it is possible to reuse this as the landing page for the documentation, without duplicating the contents. +To correctly include a Markdown file in Sphinx while preserving relative links and images, some additional effort is required. + +First, create a proxy-file ``readme_include.md`` next to ``index.rst``. +This is a markdown file which just includes the original README.md, but preserves the relative image paths, which would otherwise break in the next step: + +.. code-block:: markdown + :caption: readme_include.md + + ```{include} ../README.md + :relative-images: + ``` + + +Then, include the contents of this file from ``index.rst`` using ``myst`` to include markdown from rst: + +.. code-block:: rst + :caption: index.rst + + .. include:: readme_include.md + :parser: myst_parser.sphinx_ + + +This also requires adding ``myst_parser`` to the extensions in ``conf.py``: + +.. code-block:: python + :caption: conf.py + + extensions = ["myst_parser"] + + +CI, docs.ros.org +---------------- + +The ROS build farm uses ``rosdoc2`` to build the package documentation hosted at ``docs.ros.org/en//p//``. +To enable this, the repository containing the documentation must be configured in `rosdistro/{DISTRO}/distribution.yaml `__. +This would usually be the package source repository: + +.. code-block:: yaml + + : + doc: + type: git + url: https://github.com//.git + version: main + release: + [...] + +The buildfarm hosts the documentation for every distribution separately, and periodically rebuilds it from the latest commit on the specified branch. +It is not required to tag a new release to update the hosted documentation. +To view the status of your package's documentation build, search for ``doc__`` on ``__. +One job is created for every distribution for which the package is released. +On each job page, you can see when a build was last triggered, as well as the status and logs of each build. + +Further Reading +--------------- + +* `rosdoc2 readme `_ +* `ROS 2 design document on package documentation `_ +* `The ROS 2 cookbook `_ \ No newline at end of file diff --git a/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst index ff54262c528..a8d99c940bd 100644 --- a/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst +++ b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst @@ -1,230 +1,231 @@ -.. redirect-from:: - - Eclipse-Oxygen-with-ROS-2-and-rviz2 - Tutorials/Eclipse-Oxygen-with-ROS-2-and-rviz2 - -Using Eclipse Oxygen with ``rviz2`` [community-contributed] -=========================================================== - -.. contents:: Table of Contents - :depth: 1 - :local: - -Setup ------ - -This tutorial assumes Eclipse Oxygen, git, and `Egit `_ are already installed. - -Throughout the tutorial we name the eclipse workspace the same name as the ros2 package, but this is not required. - -HINT: We use nested projects and one Eclipse Workspace for each ROS-2 package. - -.. image:: images/eclipse-oxygen-01.png - - -Create a C++ Project. - -.. image:: images/eclipse-oxygen-02.png - - - -.. image:: images/eclipse-oxygen-03.png - - -Choose the ROS 2 package name as the Project Name. -Choose a Makefile Project and Other Toolchain. - -.. image:: images/eclipse-oxygen-04.png - - -Click on Finish - -.. image:: images/eclipse-oxygen-05.png - - -Our project should be shown in the "Project Explorer". - -.. image:: images/eclipse-oxygen-06.png - - -Inside our Project create a folder called "src". - -.. image:: images/eclipse-oxygen-07.png - - -Import a git repository. - -.. image:: images/eclipse-oxygen-08.png - - -Put in the repository URL. - -.. image:: images/eclipse-oxygen-09.png - - -IMPORTANT: Use the source folder of the project we created before as the destination folder. - -HINT: If you ran into problems choosing the destination folder path, the Eclipse Dialog needs a name in the name field. - -.. image:: images/eclipse-oxygen-10.png - - -Import using the new project wizard. - -.. image:: images/eclipse-oxygen-11.png - - -Create a General->Project. - -.. image:: images/eclipse-oxygen-12.png - - -Use the git repository name as the project name. -IMPORTANT: Use the folder we cloned the git repository in as the "Location". - -.. image:: images/eclipse-oxygen-13.png - - -The git project and the new project should be visible in the Project Explorer view. -The same files are listed multiple times, but only one project is linked with Egit. - -.. image:: images/eclipse-oxygen-14.png - - -Repeat this procedure again. -Import git repository pluginlib. - -.. image:: images/eclipse-oxygen-15.png - - -IMPORTANT: Use a folder inside the source folder as "Destination->Directory". - -.. image:: images/eclipse-oxygen-16.png - - -IMPORTANT: Use the folder we cloned the git repository in as the location for the new project. - -.. image:: images/eclipse-oxygen-17.png - - -Run the same procedure with the tinyxml2_vendor git repository. - -.. image:: images/eclipse-oxygen-18.png - - -IMPORTANT: Again use a folder inside the source folder. - -.. image:: images/eclipse-oxygen-19.png - - -IMPORTANT: Use the location of the folder we cloned as the new project folder. - -.. image:: images/eclipse-oxygen-20.png - - -Now all four Projects should be visible in the Project Explorer view. - -.. image:: images/eclipse-oxygen-21.png - - -Clicking in the top right cornder for the Project Explorer view allows us to change the Project Presentation to Hierarchical view. -Now it looks like a ROS-2 project as it is on the hard drive. -But this view loses the linkage to Egit, so use the Flat Project Presentation. -The Egit linkage is good if you want to see e.g. which author wrote which code-line, etc. - -.. image:: images/eclipse-oxygen-22.png - - -Go to "C/C++ build"-section and put "ament" into "Build command". - -.. image:: images/eclipse-oxygen-23.png - - -Go to "Behavior" tab and unselect "clean" and put "build" into Build textbox. - -.. image:: images/eclipse-oxygen-24.png - - -Before "Build project" will work, we need to close Eclipse. -Open a shell and source the ROS-2 setup.bash file, then cd into the directory of the eclipse project (here: /home/ubu/rviz2_ws/rviz2_ws) and start Eclipse from inside this directory. - -.. image:: images/eclipse-oxygen-25.png - - -Now code completion, egit annotations, eclipse C/C++ Tools, etc. should all work. - -.. image:: images/eclipse-oxygen-26.png - - -Eclipse-indexer ---------------- - -Opening the main.cpp of rviz2 may show a lot of "unresolved inclusion" warnings. -To fix this, go to Project->Properties->C++ General->Path and Symbols. -Click on the "References" tab and select "ros2_ws". - - -.. image:: images/eclipse-oxygen-27.png - - -Go to C/C++-General->Path-and-Symbols, click on the "Source locations" tab and click on "Link folder". -Choose the location of qt5 includes. - - -.. image:: images/eclipse-oxygen-28.png - - -The next image should be shown. -It is a good idea to add excludes to the source locations, so that some directories (like "Build" and "Install") don't get indexed. - - -.. image:: images/eclipse-oxygen-29.png - - -Go to C++General->Preprocessor includes, select "CDT GCC Built in compiler settings [Shared]" and enter in the "command to get compiler specs" text box the following: - -.. code-block:: bash - - -std=c++14 - - -.. image:: images/eclipse-oxygen-30.png - - -Go to "C/C++-General->Indexer" and select the following in the image. -E.g "index unused headers as c files" to resolve e.g. QApplication, because the QApplication headers content is only "#include "qapplication.h". - - -.. image:: images/eclipse-oxygen-31.png - - -After running the indexer (which happens later, so you will see this also later), you can see what it added - - -.. image:: images/eclipse-oxygen-32.png - - -After that right-click on the rviz2 project and select "Indexer->Rebuild", which will start rebuilding the index (there is an icon in the lower right showing progress). -Once the index is finished rebuilding, it should be able to resolve all includes. - - -.. image:: images/eclipse-oxygen-33.png - - -Debugging with eclipse ----------------------- - -Go to "C/C++-Build" and add to the build command: - -.. code-block:: bash - - -DCMAKE_BUILD_TYPE=Debug - - -.. image:: images/eclipse-oxygen-34.png - - -Then in eclipse go to "Run->Debug Configurations" and add the following and click on "Debug". - - -.. image:: images/eclipse-oxygen-35.png +.. redirect-from:: + + Eclipse-Oxygen-with-ROS-2-and-rviz2 + Tutorials/Eclipse-Oxygen-with-ROS-2-and-rviz2 + Tutorials/Miscellaneous/Eclipse-Oxygen-with-ROS-2-and-rviz2 + +Using Eclipse Oxygen with ``rviz2`` [community-contributed] +=========================================================== + +.. contents:: Table of Contents + :depth: 1 + :local: + +Setup +----- + +This tutorial assumes Eclipse Oxygen, git, and `Egit `_ are already installed. + +Throughout the tutorial we name the eclipse workspace the same name as the ros2 package, but this is not required. + +HINT: We use nested projects and one Eclipse Workspace for each ROS-2 package. + +.. image:: images/eclipse-oxygen-01.png + + +Create a C++ Project. + +.. image:: images/eclipse-oxygen-02.png + + + +.. image:: images/eclipse-oxygen-03.png + + +Choose the ROS 2 package name as the Project Name. +Choose a Makefile Project and Other Toolchain. + +.. image:: images/eclipse-oxygen-04.png + + +Click on Finish + +.. image:: images/eclipse-oxygen-05.png + + +Our project should be shown in the "Project Explorer". + +.. image:: images/eclipse-oxygen-06.png + + +Inside our Project create a folder called "src". + +.. image:: images/eclipse-oxygen-07.png + + +Import a git repository. + +.. image:: images/eclipse-oxygen-08.png + + +Put in the repository URL. + +.. image:: images/eclipse-oxygen-09.png + + +IMPORTANT: Use the source folder of the project we created before as the destination folder. + +HINT: If you ran into problems choosing the destination folder path, the Eclipse Dialog needs a name in the name field. + +.. image:: images/eclipse-oxygen-10.png + + +Import using the new project wizard. + +.. image:: images/eclipse-oxygen-11.png + + +Create a General->Project. + +.. image:: images/eclipse-oxygen-12.png + + +Use the git repository name as the project name. +IMPORTANT: Use the folder we cloned the git repository in as the "Location". + +.. image:: images/eclipse-oxygen-13.png + + +The git project and the new project should be visible in the Project Explorer view. +The same files are listed multiple times, but only one project is linked with Egit. + +.. image:: images/eclipse-oxygen-14.png + + +Repeat this procedure again. +Import git repository pluginlib. + +.. image:: images/eclipse-oxygen-15.png + + +IMPORTANT: Use a folder inside the source folder as "Destination->Directory". + +.. image:: images/eclipse-oxygen-16.png + + +IMPORTANT: Use the folder we cloned the git repository in as the location for the new project. + +.. image:: images/eclipse-oxygen-17.png + + +Run the same procedure with the tinyxml2_vendor git repository. + +.. image:: images/eclipse-oxygen-18.png + + +IMPORTANT: Again use a folder inside the source folder. + +.. image:: images/eclipse-oxygen-19.png + + +IMPORTANT: Use the location of the folder we cloned as the new project folder. + +.. image:: images/eclipse-oxygen-20.png + + +Now all four Projects should be visible in the Project Explorer view. + +.. image:: images/eclipse-oxygen-21.png + + +Clicking in the top right cornder for the Project Explorer view allows us to change the Project Presentation to Hierarchical view. +Now it looks like a ROS-2 project as it is on the hard drive. +But this view loses the linkage to Egit, so use the Flat Project Presentation. +The Egit linkage is good if you want to see e.g. which author wrote which code-line, etc. + +.. image:: images/eclipse-oxygen-22.png + + +Go to "C/C++ build"-section and put "ament" into "Build command". + +.. image:: images/eclipse-oxygen-23.png + + +Go to "Behavior" tab and unselect "clean" and put "build" into Build textbox. + +.. image:: images/eclipse-oxygen-24.png + + +Before "Build project" will work, we need to close Eclipse. +Open a shell and source the ROS-2 setup.bash file, then cd into the directory of the eclipse project (here: /home/ubu/rviz2_ws/rviz2_ws) and start Eclipse from inside this directory. + +.. image:: images/eclipse-oxygen-25.png + + +Now code completion, egit annotations, eclipse C/C++ Tools, etc. should all work. + +.. image:: images/eclipse-oxygen-26.png + + +Eclipse-indexer +--------------- + +Opening the main.cpp of rviz2 may show a lot of "unresolved inclusion" warnings. +To fix this, go to Project->Properties->C++ General->Path and Symbols. +Click on the "References" tab and select "ros2_ws". + + +.. image:: images/eclipse-oxygen-27.png + + +Go to C/C++-General->Path-and-Symbols, click on the "Source locations" tab and click on "Link folder". +Choose the location of qt5 includes. + + +.. image:: images/eclipse-oxygen-28.png + + +The next image should be shown. +It is a good idea to add excludes to the source locations, so that some directories (like "Build" and "Install") don't get indexed. + + +.. image:: images/eclipse-oxygen-29.png + + +Go to C++General->Preprocessor includes, select "CDT GCC Built in compiler settings [Shared]" and enter in the "command to get compiler specs" text box the following: + +.. code-block:: bash + + -std=c++14 + + +.. image:: images/eclipse-oxygen-30.png + + +Go to "C/C++-General->Indexer" and select the following in the image. +E.g "index unused headers as c files" to resolve e.g. QApplication, because the QApplication headers content is only "#include "qapplication.h". + + +.. image:: images/eclipse-oxygen-31.png + + +After running the indexer (which happens later, so you will see this also later), you can see what it added + + +.. image:: images/eclipse-oxygen-32.png + + +After that right-click on the rviz2 project and select "Indexer->Rebuild", which will start rebuilding the index (there is an icon in the lower right showing progress). +Once the index is finished rebuilding, it should be able to resolve all includes. + + +.. image:: images/eclipse-oxygen-33.png + + +Debugging with eclipse +---------------------- + +Go to "C/C++-Build" and add to the build command: + +.. code-block:: bash + + -DCMAKE_BUILD_TYPE=Debug + + +.. image:: images/eclipse-oxygen-34.png + + +Then in eclipse go to "Run->Debug Configurations" and add the following and click on "Debug". + + +.. image:: images/eclipse-oxygen-35.png \ No newline at end of file diff --git a/source/Developer-Tools/Build/Package-Docs.rst b/source/Developer-Tools/Build/Package-Docs.rst index 9c717d2252a..c872c20cc2f 100644 --- a/source/Developer-Tools/Build/Package-Docs.rst +++ b/source/Developer-Tools/Build/Package-Docs.rst @@ -1,39 +1,40 @@ -.. redirect-from:: - -Package Docs -============ - -ROS package documentation, that is to say documentation for specific packages you install via apt or some other tool, can be found in multiple places. -Here is a brief list of where to look for specific ROS package documentation. - - -* Most ROS 2 packages have their package level documentation `included in this index page `__. -* All ROS 2 package's documentation is hosted alongside its information on the `ROS Index `_. - Searching for packages on ROS Index will yield their information such as released distributions, ``README.md`` files, URLs, and other important metadata. - -Larger Packages ---------------- - -Larger packages like MoveIt, Nav2, and microROS, are given their own domain or subdomain on ros.org. -Here is a short list. - -* `MoveIt `__ -* `Navigation2 `__ -* `Control `__ -* `microROS (embedded systems) `__ - -API Documentation ------------------ - -You can find the API level documentation for the ROS client libraries in the {DISTRO_TITLE} distribution using the links below: - -* `rclcpp - C++ client library `_ -* `rclcpp_lifecycle - C++ lifecycle library `_ -* `rclcpp_components - C++ components library `_ -* `rclcpp_action - C++ actions library `_ - -Adding Your Package to docs.ros.org ------------------------------------ - -All released ROS 2 packages are automatically added to docs.ros.org and `ROS Index `_. -If you would like to enable or configure your own package please see: :doc:`./How-To-Guides/Documenting-a-ROS-2-Package`. +.. redirect-from:: + + Package-Docs +Package Docs +============ + +ROS package documentation, that is to say documentation for specific packages you install via apt or some other tool, can be found in multiple places. +Here is a brief list of where to look for specific ROS package documentation. + + +* Most ROS 2 packages have their package level documentation `included in this index page `__. +* All ROS 2 package's documentation is hosted alongside its information on the `ROS Index `_. + Searching for packages on ROS Index will yield their information such as released distributions, ``README.md`` files, URLs, and other important metadata. + +Larger Packages +--------------- + +Larger packages like MoveIt, Nav2, and microROS, are given their own domain or subdomain on ros.org. +Here is a short list. + +* `MoveIt `__ +* `Navigation2 `__ +* `Control `__ +* `microROS (embedded systems) `__ + +API Documentation +----------------- + +You can find the API level documentation for the ROS client libraries in the {DISTRO_TITLE} distribution using the links below: + +* `rclcpp - C++ client library `_ +* `rclcpp_lifecycle - C++ lifecycle library `_ +* `rclcpp_components - C++ components library `_ +* `rclcpp_action - C++ actions library `_ + +Adding Your Package to docs.ros.org +----------------------------------- + +All released ROS 2 packages are automatically added to docs.ros.org and `ROS Index `_. +If you would like to enable or configure your own package please see: :doc:`Documenting-a-ROS-2-Package`. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/First-Time-Release.rst b/source/Developer-Tools/Build/Releasing/First-Time-Release.rst index 5aebb14aa76..d320d8dbdeb 100644 --- a/source/Developer-Tools/Build/Releasing/First-Time-Release.rst +++ b/source/Developer-Tools/Build/Releasing/First-Time-Release.rst @@ -1,127 +1,131 @@ -First Time Release -================== - -This guide explains how to release ROS 2 packages that you have not released before. -Due to numerous options available when releasing ROS packages, this guide intends to cover the most common scenario and does not cover every corner-case. - -.. contents:: Table of Contents - :depth: 1 - :local: - -Be part of a release team -------------------------- - -You must be part of a :ref:`release team `. -If you are not part of a release team yet, follow either: - -* :ref:`Join a release team ` -* :ref:`Start a new release team ` - -Create a new release repository -------------------------------- - -You need a :ref:`release repository ` to release a package. -Follow :ref:`Create a new release repository `. - -Install dependencies --------------------- - -.. include:: _Install-Dependencies.rst - -Set Up a Personal Access Token ------------------------------- - -.. include:: _Personal-Access-Token.rst - -Ensure repositories are up-to-date ----------------------------------- - -.. include:: _Ensure-Repositories-Are-Up-To-Date.rst - -Generate Changelog ------------------- - -Generate a ``CHANGELOG.rst`` file per package in your repo using the following command: - -.. code-block:: console - - $ catkin_generate_changelog --all - -.. include:: _Clean-Up-Changelog.rst - -Bump the package version ------------------------- - -.. include:: _Bump-Package-Version.rst - -Bloom Release -------------- - -Run the following command, replacing ``my_repo`` with the name of your repository: - -.. code-block:: console - - $ bloom-release --new-track --rosdistro {DISTRO} --track {DISTRO} my_repo - -.. tip:: - - * ``--new-track`` tells bloom to create a new :ref:`track ` and configure it. - * ``--rosdistro {DISTRO}`` indicates that this release is for the ``{DISTRO}`` distro - * ``--track {DISTRO}`` indicates that you want the track name to be ``{DISTRO}`` - - -You will be prompted to enter information to configure a new track. -In a common scenario such as: - -* Your packages are in a repository called ``my_repo`` -* You are releasing a branch called ``main`` -* The repository is hosted on GitHub at ``https://github.com/my_organization/my_repo.git`` -* Your release repository is at ``https://github.com/ros2-gbp/my_repo-release.git`` - -You should respond to the prompts as following: - -.. list-table:: - :header-rows: 1 - :widths: 1 2 - - * - Configuration - - Value - * - :ref:`Release Repository url ` - - ``https://github.com/ros2-gbp/my_repo-release.git`` - * - :ref:`Repository Name ` - - ``my_repo`` - * - :ref:`Upstream Repository URI ` - - ``https://github.com/my_organization/my_repo.git`` - * - :ref:`Upstream VCS Type ` - - - * - :ref:`Version ` - - - * - :ref:`Release Tag ` - - - * - :ref:`Upstream Devel Branch ` - - ``main`` - * - :ref:`ROS Distro ` - - - * - :ref:`Patches Directory ` - - - * - :ref:`Release Repository Push URL ` - - - -.. note:: - - An empty cell in the table indicates that the default value should be used. - Simply respond to the prompt by pressing Enter. - -Bloom will automatically create a pull request for you against `rosdistro `_. - -.. note:: - - By default, bloom will release all packages in the source repository. - To selectively block the release of some packages for a particular ``{DISTRO}``, add ``{DISTRO}.ignored`` files to the ``master`` branch of the release repository. - In each file, list the name of the package, one per line, to block the release of the package. - The `rosidl-release `_ repository may serve as a useful reference for this configuration. - -Next Steps ----------- - -.. include:: _Next-Steps.rst +.. redirect-from:: + + How-To-Guides/Releasing/First-Time-Release + +First Time Release +================== + +This guide explains how to release ROS 2 packages that you have not released before. +Due to numerous options available when releasing ROS packages, this guide intends to cover the most common scenario and does not cover every corner-case. + +.. contents:: Table of Contents + :depth: 1 + :local: + +Be part of a release team +------------------------- + +You must be part of a :ref:`release team `. +If you are not part of a release team yet, follow either: + +* :ref:`Join a release team ` +* :ref:`Start a new release team ` + +Create a new release repository +------------------------------- + +You need a :ref:`release repository ` to release a package. +Follow :ref:`Create a new release repository `. + +Install dependencies +-------------------- + +.. include:: _Install-Dependencies.rst + +Set Up a Personal Access Token +------------------------------ + +.. include:: _Personal-Access-Token.rst + +Ensure repositories are up-to-date +---------------------------------- + +.. include:: _Ensure-Repositories-Are-Up-To-Date.rst + +Generate Changelog +------------------ + +Generate a ``CHANGELOG.rst`` file per package in your repo using the following command: + +.. code-block:: console + + $ catkin_generate_changelog --all + +.. include:: _Clean-Up-Changelog.rst + +Bump the package version +------------------------ + +.. include:: _Bump-Package-Version.rst + +Bloom Release +------------- + +Run the following command, replacing ``my_repo`` with the name of your repository: + +.. code-block:: console + + $ bloom-release --new-track --rosdistro {DISTRO} --track {DISTRO} my_repo + +.. tip:: + + * ``--new-track`` tells bloom to create a new :ref:`track ` and configure it. + * ``--rosdistro {DISTRO}`` indicates that this release is for the ``{DISTRO}`` distro + * ``--track {DISTRO}`` indicates that you want the track name to be ``{DISTRO}`` + + +You will be prompted to enter information to configure a new track. +In a common scenario such as: + +* Your packages are in a repository called ``my_repo`` +* You are releasing a branch called ``main`` +* The repository is hosted on GitHub at ``https://github.com/my_organization/my_repo.git`` +* Your release repository is at ``https://github.com/ros2-gbp/my_repo-release.git`` + +You should respond to the prompts as following: + +.. list-table:: + :header-rows: 1 + :widths: 1 2 + + * - Configuration + - Value + * - :ref:`Release Repository url ` + - ``https://github.com/ros2-gbp/my_repo-release.git`` + * - :ref:`Repository Name ` + - ``my_repo`` + * - :ref:`Upstream Repository URI ` + - ``https://github.com/my_organization/my_repo.git`` + * - :ref:`Upstream VCS Type ` + - + * - :ref:`Version ` + - + * - :ref:`Release Tag ` + - + * - :ref:`Upstream Devel Branch ` + - ``main`` + * - :ref:`ROS Distro ` + - + * - :ref:`Patches Directory ` + - + * - :ref:`Release Repository Push URL ` + - + +.. note:: + + An empty cell in the table indicates that the default value should be used. + Simply respond to the prompt by pressing Enter. + +Bloom will automatically create a pull request for you against `rosdistro `_. + +.. note:: + + By default, bloom will release all packages in the source repository. + To selectively block the release of some packages for a particular ``{DISTRO}``, add ``{DISTRO}.ignored`` files to the ``master`` branch of the release repository. + In each file, list the name of the package, one per line, to block the release of the package. + The `rosidl-release `_ repository may serve as a useful reference for this configuration. + +Next Steps +---------- + +.. include:: _Next-Steps.rst \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/Index-Your-Packages.rst b/source/Developer-Tools/Build/Releasing/Index-Your-Packages.rst index 296ea168307..952b4ac2e5d 100644 --- a/source/Developer-Tools/Build/Releasing/Index-Your-Packages.rst +++ b/source/Developer-Tools/Build/Releasing/Index-Your-Packages.rst @@ -1,98 +1,102 @@ -Index Your Packages -=================== - -Are you releasing a new ROS package into a ROS distribution? -Make the process faster by indexing your packages first. - -Put your ROS packages into a public repository ----------------------------------------------- - -If you haven't done so already, put the source code of your ROS packages into a public git repository. -All packages released into ROS must be open source. -You can host code anywhere, but GitHub is recommended because it gives you the option to enable pull request jobs. -Here are some choices: - -* `GitHub `__ **Recommended** -* `GitLab `__ -* `Bitbucket `__ - -Give your packages an OSI Approved license ------------------------------------------- -Choose an `OSI approved license `__ and give it to your ROS packages. -If you're having trouble deciding, consider using the license used by most of the core ROS 2 packages: `Apache-2.0 license `__. - -For each ``package.xml`` in your repository, put the SPDX short identifier of the license in the ```` tag in your ``package.xml``. - -If all of your ROS packages have the same license, or if there's only one ROS package in your repository, create a file called ``LICENSE`` at the root of your repository and put the text of the license you chose in it. -If the ROS packages in your repository have different licenses, create a ``LICENSE`` file adjacent to every ``package.xml`` file. - -Give your packages REP 144 compliant names ------------------------------------------- -Packages released into a ROS distribution must have names that comply with `REP 144 `__. -Read the full REP to understand the rules. -If one of your ROS package names doesn't comply, then change the name before continuing. - -Decide what ROS distribution you want to release into ------------------------------------------------------ -Decide what ROS distribution you want to release your packages into. -At a minimum, you should release your packages into `ROS Rolling `__ so that your ROS packages are automatically included in the next ROS release. -You may also want to release into any active ROS distributions, but this is up to you. - -Create a GitHub account ------------------------ -`Create a GitHub account `__ if you don't already have one. -You don't have to host the source code of your ROS packages on GitHub, but you will need an account to index and release packages. - -Fork and clone ros/rosdistro ----------------------------- -`Fork `__ the `ros/rosdistro `__ repository. -You only need to do this step once on your account. -The fork will be used every time you do a release. - -Make changes to your fork -------------------------- -Remember the ROS distributions you decided to release into? -Each ROS distribution has a folder in the `ros/rosdistro `__ repository. -For example, the name of the ROS Rolling folder is ``rolling``. -For each ROS distribution you want to release into: - -1. fill out the following template -2. put the filled-out template into the ``distribution.yaml`` file in the corresponding ROS distribution's folder - -.. code-block:: yaml - - YOUR-REPO-NAME: - source: - type: git - url: https://YOUR-GIT-REPO-URL.git - version: YOUR-BRANCH-NAME - status: YOUR-STATUS - -Here's how to fill out each item: - -* YOUR-REPO-NAME: This is an arbitrary human-readable name. - For repos hosted on GitHub, use the lowercase name of your repository not including the organization. - For example, the repository name of ``https://github.com/ros2/rosidl`` is ``rosidl``. -* YOUR-GIT-REPO-URL: This is the https URL from which one could ``git clone`` your repository - For example, the git repo URL of ``https://github.com/ros2/rosidl`` is ``https://github.com/ros2/rosidl.git``. - It is important that this URL ends in ``.git``, or it will fail to pass the linters. -* YOUR-BRANCH-NAME: This is the git branch on your repository from which you will release your package into this ROS distribution. - This is commonly one of: ``main``, ``master``, or the name of the ROS distribution itself. - For example, the `rosidl repository `__ uses the branch ``rolling`` to hold changes to be released into ROS Rolling. -* YOUR-STATUS: This is a status from the list in `REP 141 `__. - You likely want either ``maintained`` or ``developed``. - -Open a pull request to ros/rosdistro ------------------------------------- -`Open a pull request `__ to `ros/rosdistro `__ with the branch that you made your changes to. -Wait a few days for it to be reviewed. - -What happens next ------------------ -You've now done everything required to index your ROS packages. -One of the reviewers will look at your pull request and decide if it `satisfies the review guidelines `__. -The reviewer may either approve your changes as is, or give you actionable feedback. -Once the pull request meets the review guidelines it will be merged, and your packages will appear on the `ROS Index `__. - -You've completed an important step toward releasing your package. -Proceed to the next guide: :doc:`First Time Release `. +.. redirect-from:: + + How-To-Guides/Releasing/Index-Your-Packages + +Index Your Packages +=================== + +Are you releasing a new ROS package into a ROS distribution? +Make the process faster by indexing your packages first. + +Put your ROS packages into a public repository +---------------------------------------------- + +If you haven't done so already, put the source code of your ROS packages into a public git repository. +All packages released into ROS must be open source. +You can host code anywhere, but GitHub is recommended because it gives you the option to enable pull request jobs. +Here are some choices: + +* `GitHub `__ **Recommended** +* `GitLab `__ +* `Bitbucket `__ + +Give your packages an OSI Approved license +------------------------------------------ +Choose an `OSI approved license `__ and give it to your ROS packages. +If you're having trouble deciding, consider using the license used by most of the core ROS 2 packages: `Apache-2.0 license `__. + +For each ``package.xml`` in your repository, put the SPDX short identifier of the license in the ```` tag in your ``package.xml``. + +If all of your ROS packages have the same license, or if there's only one ROS package in your repository, create a file called ``LICENSE`` at the root of your repository and put the text of the license you chose in it. +If the ROS packages in your repository have different licenses, create a ``LICENSE`` file adjacent to every ``package.xml`` file. + +Give your packages REP 144 compliant names +------------------------------------------ +Packages released into a ROS distribution must have names that comply with `REP 144 `__. +Read the full REP to understand the rules. +If one of your ROS package names doesn't comply, then change the name before continuing. + +Decide what ROS distribution you want to release into +----------------------------------------------------- +Decide what ROS distribution you want to release your packages into. +At a minimum, you should release your packages into `ROS Rolling `__ so that your ROS packages are automatically included in the next ROS release. +You may also want to release into any active ROS distributions, but this is up to you. + +Create a GitHub account +----------------------- +`Create a GitHub account `__ if you don't already have one. +You don't have to host the source code of your ROS packages on GitHub, but you will need an account to index and release packages. + +Fork and clone ros/rosdistro +---------------------------- +`Fork `__ the `ros/rosdistro `__ repository. +You only need to do this step once on your account. +The fork will be used every time you do a release. + +Make changes to your fork +------------------------- +Remember the ROS distributions you decided to release into? +Each ROS distribution has a folder in the `ros/rosdistro `__ repository. +For example, the name of the ROS Rolling folder is ``rolling``. +For each ROS distribution you want to release into: + +1. fill out the following template +2. put the filled-out template into the ``distribution.yaml`` file in the corresponding ROS distribution's folder + +.. code-block:: yaml + + YOUR-REPO-NAME: + source: + type: git + url: https://YOUR-GIT-REPO-URL.git + version: YOUR-BRANCH-NAME + status: YOUR-STATUS + +Here's how to fill out each item: + +* YOUR-REPO-NAME: This is an arbitrary human-readable name. + For repos hosted on GitHub, use the lowercase name of your repository not including the organization. + For example, the repository name of ``https://github.com/ros2/rosidl`` is ``rosidl``. +* YOUR-GIT-REPO-URL: This is the https URL from which one could ``git clone`` your repository + For example, the git repo URL of ``https://github.com/ros2/rosidl`` is ``https://github.com/ros2/rosidl.git``. + It is important that this URL ends in ``.git``, or it will fail to pass the linters. +* YOUR-BRANCH-NAME: This is the git branch on your repository from which you will release your package into this ROS distribution. + This is commonly one of: ``main``, ``master``, or the name of the ROS distribution itself. + For example, the `rosidl repository `__ uses the branch ``rolling`` to hold changes to be released into ROS Rolling. +* YOUR-STATUS: This is a status from the list in `REP 141 `__. + You likely want either ``maintained`` or ``developed``. + +Open a pull request to ros/rosdistro +------------------------------------ +`Open a pull request `__ to `ros/rosdistro `__ with the branch that you made your changes to. +Wait a few days for it to be reviewed. + +What happens next +----------------- +You've now done everything required to index your ROS packages. +One of the reviewers will look at your pull request and decide if it `satisfies the review guidelines `__. +The reviewer may either approve your changes as is, or give you actionable feedback. +Once the pull request meets the review guidelines it will be merged, and your packages will appear on the `ROS Index `__. + +You've completed an important step toward releasing your package. +Proceed to the next guide: :doc:`First Time Release `. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst b/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst index 362f34a5e8e..a8b92c2e2c0 100644 --- a/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst +++ b/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst @@ -1,82 +1,86 @@ -Release Team / Repository -========================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page explains the recommended method of hosting your release repositories on `ros2-gbp `_. - -What is ROS 2 GBP? ------------------- - -`ros2-gbp `_ is a GitHub organization that hosts the release repositories for ROS packages. -It also maintains a list of release teams, the list of members per release team and the list of release repositories maintained by the release teams in https://github.com/ros2-gbp/ros2-gbp-github-org. -Interactions with ros2-gbp-github-org are done through raising GitHub issues. -It is recommended that you request to join a release team and set up a release repository early as it can take some time for the ros2-gbp maintainers to respond to your requests. - -.. _what-is-a-release-team: - -What is a release team? ------------------------ - -A release team is a `GitHub team `_ that consists of a group of people who are responsible for the release process of one or more repositories. -Release teams are often made up of an organization, a working group, or even an individual, and are named after the team or group that they represent. -The list of release teams and their associated release repositories are maintained at `ros2-gbp-github-org `_. - -**You must be a part of the release team that you are planning on releasing the project for.** -If you intend to release the repository under an existing team, follow :ref:`Join a release team `. -If you intend to start a new team, follow :ref:`Start a new release team `. - -.. _join-a-release-team: - -Join a release team -^^^^^^^^^^^^^^^^^^^ - -Fill the `Update Release Team Membership issue `_ issue template -if a release team already exists for your project but you are not part of it. - -.. _start-a-new-release-team: - -Start a new release team -^^^^^^^^^^^^^^^^^^^^^^^^ - -If no release team exists for your project yet, fill out the `New Release Team issue `_ issue template to request one be created. - -.. _what-is-a-release-repository: - -What is a release repository? ------------------------------ - -A release repository is a repository that - -* stores files generated from the release process, for the ROS buildfarm to use -* caches configurations from the release process to simplify subsequent releases of the repository in the future - -Having a release repository separate from your source code repository is a requirement for making a release in ROS 2. - -.. _create-a-new-release-repository: - -Create a new release repository -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If your repository is new to the ROS community, you should first open a pull request on `ros/rosdistro `_ adding a ``source`` entry for your repository (e.g. https://github.com/ros/rosdistro/pull/39513). -The review process for the rosdistro database will ensure your repository and packages conform to the `REP 144 package naming conventions `_ and other requirements before release. -Once your package name has been approved and merged, fill in the `Add New Release Repositories issue `_ issue template -if you don't have a release repo for your project yet. - -What if my existing release repo isn't on ros2-gbp? ---------------------------------------------------- - -Packages released before ros2-gbp existed may have their release repositories hosted elsewhere. -It is now strongly recommended for release repositories to live in this dedicated GitHub organization. -If you are porting a ROS 1 package to ROS 2 and planning on releasing your packages into ROS 2 for the first time, follow standard procedure to request for a new release repository for your ROS 2 releases. -If you have previously released your packages for ROS 2, when raising the `Add New Release Repositories issue `_, **specify your current release repository url**, and follow standard procedure for the rest. - -.. note:: - - **When releasing your packages into the Rolling distribution, you must use a release repository hosted in the ros2-gbp organization**. - Release repositories hosted elsewhere are still supported for stable distributions if you are not planning to release the repository into Rolling. - Since stable distributions created from Rolling will start with release repositories in the ros2-gbp organization it is recommend that you use the ros2-gbp release repositories for all ROS 2 distributions to avoid fragmenting the release information. - - A ros2-gbp release repository may become a hard requirement for all distros in the future and maintaining a single release repository for all ROS 2 distributions simplifies the maintenance of releases for both the Rolling distribution maintainers and package maintainers. +.. redirect-from:: + + How-To-Guides/Releasing/Release-Team-Repository + +Release Team / Repository +========================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page explains the recommended method of hosting your release repositories on `ros2-gbp `_. + +What is ROS 2 GBP? +------------------ + +`ros2-gbp `_ is a GitHub organization that hosts the release repositories for ROS packages. +It also maintains a list of release teams, the list of members per release team and the list of release repositories maintained by the release teams in https://github.com/ros2-gbp/ros2-gbp-github-org. +Interactions with ros2-gbp-github-org are done through raising GitHub issues. +It is recommended that you request to join a release team and set up a release repository early as it can take some time for the ros2-gbp maintainers to respond to your requests. + +.. _what-is-a-release-team: + +What is a release team? +----------------------- + +A release team is a `GitHub team `_ that consists of a group of people who are responsible for the release process of one or more repositories. +Release teams are often made up of an organization, a working group, or even an individual, and are named after the team or group that they represent. +The list of release teams and their associated release repositories are maintained at `ros2-gbp-github-org `_. + +**You must be a part of the release team that you are planning on releasing the project for.** +If you intend to release the repository under an existing team, follow :ref:`Join a release team `. +If you intend to start a new team, follow :ref:`Start a new release team `. + +.. _join-a-release-team: + +Join a release team +^^^^^^^^^^^^^^^^^^^ + +Fill the `Update Release Team Membership issue `_ issue template +if a release team already exists for your project but you are not part of it. + +.. _start-a-new-release-team: + +Start a new release team +^^^^^^^^^^^^^^^^^^^^^^^^ + +If no release team exists for your project yet, fill out the `New Release Team issue `_ issue template to request one be created. + +.. _what-is-a-release-repository: + +What is a release repository? +----------------------------- + +A release repository is a repository that + +* stores files generated from the release process, for the ROS buildfarm to use +* caches configurations from the release process to simplify subsequent releases of the repository in the future + +Having a release repository separate from your source code repository is a requirement for making a release in ROS 2. + +.. _create-a-new-release-repository: + +Create a new release repository +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If your repository is new to the ROS community, you should first open a pull request on `ros/rosdistro `_ adding a ``source`` entry for your repository (e.g. https://github.com/ros/rosdistro/pull/39513). +The review process for the rosdistro database will ensure your repository and packages conform to the `REP 144 package naming conventions `_ and other requirements before release. +Once your package name has been approved and merged, fill in the `Add New Release Repositories issue `_ issue template +if you don't have a release repo for your project yet. + +What if my existing release repo isn't on ros2-gbp? +--------------------------------------------------- + +Packages released before ros2-gbp existed may have their release repositories hosted elsewhere. +It is now strongly recommended for release repositories to live in this dedicated GitHub organization. +If you are porting a ROS 1 package to ROS 2 and planning on releasing your packages into ROS 2 for the first time, follow standard procedure to request for a new release repository for your ROS 2 releases. +If you have previously released your packages for ROS 2, when raising the `Add New Release Repositories issue `_, **specify your current release repository url**, and follow standard procedure for the rest. + +.. note:: + + **When releasing your packages into the Rolling distribution, you must use a release repository hosted in the ros2-gbp organization**. + Release repositories hosted elsewhere are still supported for stable distributions if you are not planning to release the repository into Rolling. + Since stable distributions created from Rolling will start with release repositories in the ros2-gbp organization it is recommend that you use the ros2-gbp release repositories for all ROS 2 distributions to avoid fragmenting the release information. + + A ros2-gbp release repository may become a hard requirement for all distros in the future and maintaining a single release repository for all ROS 2 distributions simplifies the maintenance of releases for both the Rolling distribution maintainers and package maintainers. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/Release-Track.rst b/source/Developer-Tools/Build/Releasing/Release-Track.rst index c7a1c71cb4a..a033e48dc08 100644 --- a/source/Developer-Tools/Build/Releasing/Release-Track.rst +++ b/source/Developer-Tools/Build/Releasing/Release-Track.rst @@ -1,246 +1,250 @@ -Release Track -============= - -.. contents:: Table of Contents - :depth: 2 - :local: - -.. _what-is-a-track: - -What is a Track? ----------------- - -Bloom requires the user to enter configuration information when releasing packages for the first time. -It is beneficial to store such configurations in the release repository so we don't have to manually enter configurations that won't change for subsequent releases. - -Since some of the configurations will differ when releasing the package for different ROS distributions, bloom uses **release tracks to store the configurations for releasing** per distribution. -By convention you should create tracks with the same name as the ROS distro you are releasing for. - -All release track configurations are stored in ``tracks.yaml`` on the master branch of your release repository. - -Track Configurations --------------------- - -Track configurations are explained in more detail along with the prompts from bloom. - -.. _release-repository-url: - -Release Repository url -^^^^^^^^^^^^^^^^^^^^^^ - -This is the url of your release repository, and should be of form ``https://github.com/ros2-gbp/my_repo-release.git`` if your release repository is hosted on ros2-gbp. - -.. code-block:: bash - - No reasonable default release repository url could be determined from previous releases. - Release repository url [press enter to abort]: - -Paste your release repository URL and press Enter. - -Bloom may additionally ask you about initializing the new repository, as following: - -.. code-block:: bash - - Freshly initialized git repository detected. - An initial empty commit is going to be made. - Continue [Y/n]? - -Simply press Enter to accept the default of yes. - -.. _repository-name: - -Repository Name -^^^^^^^^^^^^^^^ - -The repository name is trivial, but it is recommended to set this to the name of your project. - -.. code-block:: bash - - Repository Name: - upstream - Default value, leave this as upstream if you are unsure - - Name of the repository (used in the archive name) - ['upstream']: - -Type the name of your project (e.g. ``my_project``) and press Enter. - -.. _upstream-repository-uri: - -Upstream Repository URI -^^^^^^^^^^^^^^^^^^^^^^^ - -The **upstream repository** is the repository where your source code is. -This is most likely an https link to your project hosted on a git hosting service such as GitHub or GitLab. - -.. code-block:: bash - - Upstream Repository URI: - - Any valid URI. This variable can be templated, for example an svn url - can be templated as such: "https://svn.foo.com/foo/tags/foo-:{version}" - where the :{version} token will be replaced with the version for this release. - [None]: - -Make sure you **use the https address** (e.g. ``https://github.com/my_organization/my_repo.git``) and not the ssh address. - -.. _upstream-vcs-type: - -Upstream VCS Type -^^^^^^^^^^^^^^^^^ - -This is the `Upstream Repository URI`_'s version control system (VCS) type. -You must specify the type of vcs your repository is using, from ``svn``, ``git``, ``hg`` or ``tar``. - -.. code-block:: bash - - Upstream VCS Type: - svn - Upstream URI is a svn repository - git - Upstream URI is a git repository - hg - Upstream URI is a hg repository - tar - Upstream URI is a tarball - ['git']: - -Most repositories will be using git, but some legacy repositories might be using hg or svn. - -.. _version: - -Version -^^^^^^^ - -This is the version of the package you are releasing. -(e.g. ``1.0.3``) - -.. code-block:: bash - - Version: - :{ask} - This means that the user will be prompted for the version each release. - This also means that the upstream devel will be ignored. - :{auto} - This means the version will be guessed from the devel branch. - This means that the devel branch must be set, the devel branch must exist, - and there must be a valid package.xml in the upstream devel branch. - - This will be the version used. - It must be updated for each new upstream version. - [':{auto}']: - -Setting this to ``:{auto}`` (the default, and recommended setup) will automatically determine the version from the devel branch's package.xml. - -Setting this to ``:{ask}`` will bring up a prompt asking for the version every time you run a release with bloom. - -.. _release-tag: - -Release Tag -^^^^^^^^^^^ - -The Release Tag refers to which tag or branch you want to import the code from. - -.. code-block:: bash - - Release Tag: - :{version} - This means that the release tag will match the :{version} tag. - This can be further templated, for example: "foo-:{version}" or "v:{version}" - - This can describe any vcs reference. For git that means {tag, branch, hash}, - for hg that means {tag, branch, hash}, for svn that means a revision number. - For tar this value doubles as the sub directory (if the repository is - in foo/ of the tar ball, putting foo here will cause the contents of - foo/ to be imported to upstream instead of foo itself). - :{ask} - This means the user will be prompted for the release tag on each release. - :{none} - For svn and tar only you can set the release tag to :{none}, so that - it is ignored. For svn this means no revision number is used. - [':{version}']: - -Setting this to ``:{version}`` (the default, and recommended setup) will make the release tag match the version tag. - -A less common setup is to set this to a branch name to always pull in that branch at the time of release from the upstream project. - -Alternatively, if you want to be prompted to enter a different tag every time you do a release, enter ``:{ask}``. -``:{ask}`` is useful if the upstream project has frequent tagged releases and you want to refer to the new tag every time you're releasing. - -.. _upstream-devel-branch: - -Upstream Devel Branch -^^^^^^^^^^^^^^^^^^^^^ - -The upstream devel branch is the name of the branch in your :ref:`upstream repository `. -If you use separate branches for each ROS distribution, this field would be different for each release track. -It is used to determine the version of the package you are releasing when :ref:`Version` is set to ``:{auto}``. - -.. code-block:: bash - - Upstream Devel Branch: - - Branch in upstream repository on which to search for the version. - This is used only when version is set to ':{auto}'. - [None]: - -To release from a branch called ``{DISTRO}``, enter ``{DISTRO}``. -Leaving this as ``None`` would result in the version being determined from the default branch of your repository (this is not recommended). - -.. _ros-distro: - -ROS Distro -^^^^^^^^^^ - -This is the distribution you're planning on releasing the package into. - -.. code-block:: bash - - ROS Distro: - - This can be any valid ROS distro, e.g. indigo, kinetic, lunar, melodic - ['indigo']: - -If you plan on releasing into ROS {DISTRO}, enter ``{DISTRO}``. - -.. _patches-directory: - -Patches Directory -^^^^^^^^^^^^^^^^^ - -This is the directory where any additional patches to the releases are. - -.. code-block:: bash - - Patches Directory: - - This can be any valid relative path in the bloom branch. The contents - of this folder will be overlaid onto the upstream branch after each - import-upstream. Additionally, any package.xml files found in the - overlay will have the :{version} string replaced with the current - version being released. - :{none} - Use this if you want to disable overlaying of files. - [None]: - -Adding additional patches to a release is a rarely used feature. -For almost all packages, this should be left as the default ``None``. - -.. _release-repository-push-url: - -Release Repository Push URL -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: bash - - Release Repository Push URL: - :{none} - This indicates that the default release url should be used. - - (optional) Used when pushing to remote release repositories. This is only - needed when the release uri which is in the rosdistro file is not writable. - This is useful, for example, when a releaser would like to use a ssh url - to push rather than a https:// url. - [None]: - -Can be left as the default in most cases. +.. redirect-from:: + + How-To-Guides/Releasing/Release-Track + +Release Track +============= + +.. contents:: Table of Contents + :depth: 2 + :local: + +.. _what-is-a-track: + +What is a Track? +---------------- + +Bloom requires the user to enter configuration information when releasing packages for the first time. +It is beneficial to store such configurations in the release repository so we don't have to manually enter configurations that won't change for subsequent releases. + +Since some of the configurations will differ when releasing the package for different ROS distributions, bloom uses **release tracks to store the configurations for releasing** per distribution. +By convention you should create tracks with the same name as the ROS distro you are releasing for. + +All release track configurations are stored in ``tracks.yaml`` on the master branch of your release repository. + +Track Configurations +-------------------- + +Track configurations are explained in more detail along with the prompts from bloom. + +.. _release-repository-url: + +Release Repository url +^^^^^^^^^^^^^^^^^^^^^^ + +This is the url of your release repository, and should be of form ``https://github.com/ros2-gbp/my_repo-release.git`` if your release repository is hosted on ros2-gbp. + +.. code-block:: bash + + No reasonable default release repository url could be determined from previous releases. + Release repository url [press enter to abort]: + +Paste your release repository URL and press Enter. + +Bloom may additionally ask you about initializing the new repository, as following: + +.. code-block:: bash + + Freshly initialized git repository detected. + An initial empty commit is going to be made. + Continue [Y/n]? + +Simply press Enter to accept the default of yes. + +.. _repository-name: + +Repository Name +^^^^^^^^^^^^^^^ + +The repository name is trivial, but it is recommended to set this to the name of your project. + +.. code-block:: bash + + Repository Name: + upstream + Default value, leave this as upstream if you are unsure + + Name of the repository (used in the archive name) + ['upstream']: + +Type the name of your project (e.g. ``my_project``) and press Enter. + +.. _upstream-repository-uri: + +Upstream Repository URI +^^^^^^^^^^^^^^^^^^^^^^^ + +The **upstream repository** is the repository where your source code is. +This is most likely an https link to your project hosted on a git hosting service such as GitHub or GitLab. + +.. code-block:: bash + + Upstream Repository URI: + + Any valid URI. This variable can be templated, for example an svn url + can be templated as such: "https://svn.foo.com/foo/tags/foo-:{version}" + where the :{version} token will be replaced with the version for this release. + [None]: + +Make sure you **use the https address** (e.g. ``https://github.com/my_organization/my_repo.git``) and not the ssh address. + +.. _upstream-vcs-type: + +Upstream VCS Type +^^^^^^^^^^^^^^^^^ + +This is the `Upstream Repository URI`_'s version control system (VCS) type. +You must specify the type of vcs your repository is using, from ``svn``, ``git``, ``hg`` or ``tar``. + +.. code-block:: bash + + Upstream VCS Type: + svn + Upstream URI is a svn repository + git + Upstream URI is a git repository + hg + Upstream URI is a hg repository + tar + Upstream URI is a tarball + ['git']: + +Most repositories will be using git, but some legacy repositories might be using hg or svn. + +.. _version: + +Version +^^^^^^^ + +This is the version of the package you are releasing. +(e.g. ``1.0.3``) + +.. code-block:: bash + + Version: + :{ask} + This means that the user will be prompted for the version each release. + This also means that the upstream devel will be ignored. + :{auto} + This means the version will be guessed from the devel branch. + This means that the devel branch must be set, the devel branch must exist, + and there must be a valid package.xml in the upstream devel branch. + + This will be the version used. + It must be updated for each new upstream version. + [':{auto}']: + +Setting this to ``:{auto}`` (the default, and recommended setup) will automatically determine the version from the devel branch's package.xml. + +Setting this to ``:{ask}`` will bring up a prompt asking for the version every time you run a release with bloom. + +.. _release-tag: + +Release Tag +^^^^^^^^^^^ + +The Release Tag refers to which tag or branch you want to import the code from. + +.. code-block:: bash + + Release Tag: + :{version} + This means that the release tag will match the :{version} tag. + This can be further templated, for example: "foo-:{version}" or "v:{version}" + + This can describe any vcs reference. For git that means {tag, branch, hash}, + for hg that means {tag, branch, hash}, for svn that means a revision number. + For tar this value doubles as the sub directory (if the repository is + in foo/ of the tar ball, putting foo here will cause the contents of + foo/ to be imported to upstream instead of foo itself). + :{ask} + This means the user will be prompted for the release tag on each release. + :{none} + For svn and tar only you can set the release tag to :{none}, so that + it is ignored. For svn this means no revision number is used. + [':{version}']: + +Setting this to ``:{version}`` (the default, and recommended setup) will make the release tag match the version tag. + +A less common setup is to set this to a branch name to always pull in that branch at the time of release from the upstream project. + +Alternatively, if you want to be prompted to enter a different tag every time you do a release, enter ``:{ask}``. +``:{ask}`` is useful if the upstream project has frequent tagged releases and you want to refer to the new tag every time you're releasing. + +.. _upstream-devel-branch: + +Upstream Devel Branch +^^^^^^^^^^^^^^^^^^^^^ + +The upstream devel branch is the name of the branch in your :ref:`upstream repository `. +If you use separate branches for each ROS distribution, this field would be different for each release track. +It is used to determine the version of the package you are releasing when :ref:`Version` is set to ``:{auto}``. + +.. code-block:: bash + + Upstream Devel Branch: + + Branch in upstream repository on which to search for the version. + This is used only when version is set to ':{auto}'. + [None]: + +To release from a branch called ``{DISTRO}``, enter ``{DISTRO}``. +Leaving this as ``None`` would result in the version being determined from the default branch of your repository (this is not recommended). + +.. _ros-distro: + +ROS Distro +^^^^^^^^^^ + +This is the distribution you're planning on releasing the package into. + +.. code-block:: bash + + ROS Distro: + + This can be any valid ROS distro, e.g. indigo, kinetic, lunar, melodic + ['indigo']: + +If you plan on releasing into ROS {DISTRO}, enter ``{DISTRO}``. + +.. _patches-directory: + +Patches Directory +^^^^^^^^^^^^^^^^^ + +This is the directory where any additional patches to the releases are. + +.. code-block:: bash + + Patches Directory: + + This can be any valid relative path in the bloom branch. The contents + of this folder will be overlaid onto the upstream branch after each + import-upstream. Additionally, any package.xml files found in the + overlay will have the :{version} string replaced with the current + version being released. + :{none} + Use this if you want to disable overlaying of files. + [None]: + +Adding additional patches to a release is a rarely used feature. +For almost all packages, this should be left as the default ``None``. + +.. _release-repository-push-url: + +Release Repository Push URL +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: bash + + Release Repository Push URL: + :{none} + This indicates that the default release url should be used. + + (optional) Used when pushing to remote release repositories. This is only + needed when the release uri which is in the rosdistro file is not writable. + This is useful, for example, when a releaser would like to use a ssh url + to push rather than a https:// url. + [None]: + +Can be left as the default in most cases. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst b/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst index b005b0a979e..94611980328 100644 --- a/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst +++ b/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst @@ -1,34 +1,35 @@ -.. redirect-from:: - - Releasing-a-ROS-2-package-with-bloom - Guides/Releasing-a-ROS-2-package-with-bloom - Tutorials/Releasing-a-ROS-2-package-with-bloom - How-To-Guides/Releasing-a-ROS-2-package-with-bloom - -Releasing a Package -=================== - -.. toctree:: - :hidden: - - Index-Your-Packages - First-Time-Release - Subsequent-Releases - Release-Team-Repository - Release-Track - -**Releasing a package makes your package available on the public ROS 2 buildfarm.** -This will: - -* Make your package available to be installed via package managers (e.g. ``apt`` on Ubuntu) for all supported Linux platforms in a ROS distribution as described in `REP 2000 `_. -* Allow your package to have API documentation automatically generated. -* Make your package part of the `ROS Index `_. -* (Optionally) Allow you to have automatic CI run for pull requests in your repository. - -**Follow one of the guides below to get your package released:** - -* :doc:`Index Your Packages ` - if this is the first release for the package -* :doc:`First Time Release ` - if this is the first release for the package, but it is already indexed -* :doc:`Subsequent Releases ` - if you are releasing a new version of a package that has already been released - -After successfully following the instructions, your package will be released into the ROS ecosystem on the next distro synchronization! +.. redirect-from:: + + Releasing-a-ROS-2-package-with-bloom + Guides/Releasing-a-ROS-2-package-with-bloom + Tutorials/Releasing-a-ROS-2-package-with-bloom + How-To-Guides/Releasing-a-ROS-2-package-with-bloom + How-To-Guides/Releasing/Releasing-a-Package + +Releasing a Package +=================== + +.. toctree:: + :hidden: + + Index-Your-Packages + First-Time-Release + Subsequent-Releases + Release-Team-Repository + Release-Track + +**Releasing a package makes your package available on the public ROS 2 buildfarm.** +This will: + +* Make your package available to be installed via package managers (e.g. ``apt`` on Ubuntu) for all supported Linux platforms in a ROS distribution as described in `REP 2000 `_. +* Allow your package to have API documentation automatically generated. +* Make your package part of the `ROS Index `_. +* (Optionally) Allow you to have automatic CI run for pull requests in your repository. + +**Follow one of the guides below to get your package released:** + +* :doc:`Index Your Packages ` - if this is the first release for the package +* :doc:`First Time Release ` - if this is the first release for the package, but it is already indexed +* :doc:`Subsequent Releases ` - if you are releasing a new version of a package that has already been released + +After successfully following the instructions, your package will be released into the ROS ecosystem on the next distro synchronization! \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst b/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst index 44cca46b85f..32d4c557e7f 100644 --- a/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst +++ b/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst @@ -1,67 +1,71 @@ -Subsequent Releases -=================== - -This guide explains how to release new versions of ROS packages that have already been released before. - -.. contents:: Table of Contents - :depth: 1 - :local: - -Be part of the release team ---------------------------- - -If you are not part of the release team that has write access to the release repository, follow :ref:`Join a release team `. - -Install dependencies --------------------- - -.. include:: _Install-Dependencies.rst - -Set up a Personal Access Token ------------------------------- - -.. include:: _Personal-Access-Token.rst - -Ensure repositories are up-to-date ----------------------------------- - -.. include:: _Ensure-Repositories-Are-Up-To-Date.rst - -Updating Changelog ------------------- - -For your users and for the developers, keep the changelog concise and up to date. - -.. code-block:: console - - $ catkin_generate_changelog - -.. include:: _Clean-Up-Changelog.rst - -Bump the package version ------------------------- - -.. include:: _Bump-Package-Version.rst - -Bloom Release -------------- - -Run the following command, replacing ``my_repo`` with the name of your repository with the packages: - -.. code-block:: console - - $ bloom-release --rosdistro {DISTRO} my_repo - -Bloom will automatically create a pull request for you against `rosdistro `_. - -.. note:: - - By default, bloom will release all packages in the source repository. - To selectively block the release of some packages for a particular ``{DISTRO}``, add ``{DISTRO}.ignored`` files to the ``master`` branch of the release repository. - In each file, list the name of the package, one per line, to block the release of the package. - The `rosidl-release `_ repository may serve as a useful reference for this configuration. - -Next Steps ----------- - -.. include:: _Next-Steps.rst +.. redirect-from:: + + How-To-Guides/Releasing/Subsequent-Releases + +Subsequent Releases +=================== + +This guide explains how to release new versions of ROS packages that have already been released before. + +.. contents:: Table of Contents + :depth: 1 + :local: + +Be part of the release team +--------------------------- + +If you are not part of the release team that has write access to the release repository, follow :ref:`Join a release team `. + +Install dependencies +-------------------- + +.. include:: _Install-Dependencies.rst + +Set up a Personal Access Token +------------------------------ + +.. include:: _Personal-Access-Token.rst + +Ensure repositories are up-to-date +---------------------------------- + +.. include:: _Ensure-Repositories-Are-Up-To-Date.rst + +Updating Changelog +------------------ + +For your users and for the developers, keep the changelog concise and up to date. + +.. code-block:: console + + $ catkin_generate_changelog + +.. include:: _Clean-Up-Changelog.rst + +Bump the package version +------------------------ + +.. include:: _Bump-Package-Version.rst + +Bloom Release +------------- + +Run the following command, replacing ``my_repo`` with the name of your repository with the packages: + +.. code-block:: console + + $ bloom-release --rosdistro {DISTRO} my_repo + +Bloom will automatically create a pull request for you against `rosdistro `_. + +.. note:: + + By default, bloom will release all packages in the source repository. + To selectively block the release of some packages for a particular ``{DISTRO}``, add ``{DISTRO}.ignored`` files to the ``master`` branch of the release repository. + In each file, list the name of the package, one per line, to block the release of the package. + The `rosidl-release `_ repository may serve as a useful reference for this configuration. + +Next Steps +---------- + +.. include:: _Next-Steps.rst \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/_Bump-Package-Version.rst b/source/Developer-Tools/Build/Releasing/_Bump-Package-Version.rst index 96e7c7ca10b..b5cea782391 100644 --- a/source/Developer-Tools/Build/Releasing/_Bump-Package-Version.rst +++ b/source/Developer-Tools/Build/Releasing/_Bump-Package-Version.rst @@ -1,27 +1,31 @@ -Every release of the package must have a unique version number higher than the previous release. - -Run: - -.. code-block:: console - - $ catkin_prepare_release - -which performs the following: - -#. increases the package version in ``package.xml`` -#. replaces the heading ``Forthcoming`` with ``version (date)`` (e.g. ``0.0.1 (2022-01-08)``) in ``CHANGELOG.rst`` -#. commits those changes -#. creates a tag (e.g. ``0.0.1``) -#. pushes the changes and the tag to your remote repository - -.. note:: - - By default the patch version of the package is incremented, such as from ``0.0.0`` to ``0.0.1``. - To increment the minor or major version instead, run ``catkin_prepare_release --bump minor`` or ``catkin_prepare_release --bump major``. - For more details, see ``catkin_prepare_release --help``. - -.. note:: - - If your repository has a strict merge rule like ``Require a pull request before merging``, you will need to create a pull request with the changes/tag generated by ``catkin_prepare_release`` and then merge that, since you cannot directly push to the branch. - Depending on your repository's pull request merge settings (such as squash merge or rebase merge), merging the pull request may change the SHA of the version commit. - In such cases, you will need to manually re-tag the version commit after merging to ensure the tag points to the correct commit. +.. redirect-from:: + + How-To-Guides/Releasing/_Bump-Package-Version + +Every release of the package must have a unique version number higher than the previous release. + +Run: + +.. code-block:: console + + $ catkin_prepare_release + +which performs the following: + +#. increases the package version in ``package.xml`` +#. replaces the heading ``Forthcoming`` with ``version (date)`` (e.g. ``0.0.1 (2022-01-08)``) in ``CHANGELOG.rst`` +#. commits those changes +#. creates a tag (e.g. ``0.0.1``) +#. pushes the changes and the tag to your remote repository + +.. note:: + + By default the patch version of the package is incremented, such as from ``0.0.0`` to ``0.0.1``. + To increment the minor or major version instead, run ``catkin_prepare_release --bump minor`` or ``catkin_prepare_release --bump major``. + For more details, see ``catkin_prepare_release --help``. + +.. note:: + + If your repository has a strict merge rule like ``Require a pull request before merging``, you will need to create a pull request with the changes/tag generated by ``catkin_prepare_release`` and then merge that, since you cannot directly push to the branch. + Depending on your repository's pull request merge settings (such as squash merge or rebase merge), merging the pull request may change the SHA of the version commit. + In such cases, you will need to manually re-tag the version commit after merging to ensure the tag points to the correct commit. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/_Clean-Up-Changelog.rst b/source/Developer-Tools/Build/Releasing/_Clean-Up-Changelog.rst index 59adf33a35d..fe9605dbfa3 100644 --- a/source/Developer-Tools/Build/Releasing/_Clean-Up-Changelog.rst +++ b/source/Developer-Tools/Build/Releasing/_Clean-Up-Changelog.rst @@ -1,16 +1,20 @@ -Open all ``CHANGELOG.rst`` files in an editor. -You will see that ``catkin_generate_changelog`` has auto-generated a forthcoming section with notes from commit messages: - -.. code-block:: rst - - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Changelog for package your_package - ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - Forthcoming - ----------- - * you can modify this commit message - * and this - -Clean up the list of commit messages to concisely convey the notable changes that have been made to the packages since the last release, and **commit all the CHANGELOG.rst files.** -Do not modify the ``Forthcoming`` header. +.. redirect-from:: + + How-To-Guides/Releasing/_Clean-Up-Changelog + +Open all ``CHANGELOG.rst`` files in an editor. +You will see that ``catkin_generate_changelog`` has auto-generated a forthcoming section with notes from commit messages: + +.. code-block:: rst + + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + Changelog for package your_package + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + Forthcoming + ----------- + * you can modify this commit message + * and this + +Clean up the list of commit messages to concisely convey the notable changes that have been made to the packages since the last release, and **commit all the CHANGELOG.rst files.** +Do not modify the ``Forthcoming`` header. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/_Ensure-Repositories-Are-Up-To-Date.rst b/source/Developer-Tools/Build/Releasing/_Ensure-Repositories-Are-Up-To-Date.rst index 58ed6d1b20a..e9ef79ba392 100644 --- a/source/Developer-Tools/Build/Releasing/_Ensure-Repositories-Are-Up-To-Date.rst +++ b/source/Developer-Tools/Build/Releasing/_Ensure-Repositories-Are-Up-To-Date.rst @@ -1,5 +1,9 @@ -Make sure that: - -* Your repository is hosted on a remote such as GitHub. -* You have a clone of the repository on your computer and are on the right branch. -* Both the remote repository and your clone are up-to-date. +.. redirect-from:: + + How-To-Guides/Releasing/_Ensure-Repositories-Are-Up-To-Date + +Make sure that: + +* Your repository is hosted on a remote such as GitHub. +* You have a clone of the repository on your computer and are on the right branch. +* Both the remote repository and your clone are up-to-date. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/_Install-Dependencies.rst b/source/Developer-Tools/Build/Releasing/_Install-Dependencies.rst index 8b69dca153a..6362625427c 100644 --- a/source/Developer-Tools/Build/Releasing/_Install-Dependencies.rst +++ b/source/Developer-Tools/Build/Releasing/_Install-Dependencies.rst @@ -1,30 +1,34 @@ -Install tools that you will use in the upcoming steps according to your platform: - -.. tabs:: - - .. group-tab:: deb (e.g. Ubuntu) - - .. code-block:: console - - $ sudo apt install python3-bloom python3-catkin-pkg - - .. group-tab:: RPM (e.g. RHEL) - - .. code-block:: console - - $ sudo dnf install python3-bloom python3-catkin_pkg - - .. group-tab:: Other - - .. code-block:: console - - $ pip3 install -U bloom catkin_pkg - -Make sure you have rosdep initialized: - -.. code-block:: console - - $ sudo rosdep init - $ rosdep update - -Note that the ``rosdep init`` command may fail if it has already been initialized in the past; this can safely be ignored. +.. redirect-from:: + + How-To-Guides/Releasing/_Install-Dependencies + +Install tools that you will use in the upcoming steps according to your platform: + +.. tabs:: + + .. group-tab:: deb (e.g. Ubuntu) + + .. code-block:: console + + $ sudo apt install python3-bloom python3-catkin-pkg + + .. group-tab:: RPM (e.g. RHEL) + + .. code-block:: console + + $ sudo dnf install python3-bloom python3-catkin_pkg + + .. group-tab:: Other + + .. code-block:: console + + $ pip3 install -U bloom catkin_pkg + +Make sure you have rosdep initialized: + +.. code-block:: console + + $ sudo rosdep init + $ rosdep update + +Note that the ``rosdep init`` command may fail if it has already been initialized in the past; this can safely be ignored. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/_Next-Steps.rst b/source/Developer-Tools/Build/Releasing/_Next-Steps.rst index 99310bb60c3..33c1071cef0 100644 --- a/source/Developer-Tools/Build/Releasing/_Next-Steps.rst +++ b/source/Developer-Tools/Build/Releasing/_Next-Steps.rst @@ -1,6 +1,10 @@ -Once your pull request has been submitted, usually within one or two days, one of the maintainers of rosdistro will review and merge your Pull Request. -If your package build is successful, in 24-48 hours your packages will become available in the **ros-testing** repository, where you can :doc:`test your pre-release binaries <../../../Installation/Testing>`. - -Approximately every two to four weeks, the distribution's release manager manually synchronizes the contents of ros-testing into the main ROS repository. -This is when your packages actually become available to the rest of the ROS community. -To get updates on when the next synchronization (sync) is coming, subscribe to the `Packaging and Release Management Category on Open Robotics Discourse `_. +.. redirect-from:: + + How-To-Guides/Releasing/_Next-Steps + +Once your pull request has been submitted, usually within one or two days, one of the maintainers of rosdistro will review and merge your Pull Request. +If your package build is successful, in 24-48 hours your packages will become available in the **ros-testing** repository, where you can :doc:`test your pre-release binaries <../../../Installation/Testing>`. + +Approximately every two to four weeks, the distribution's release manager manually synchronizes the contents of ros-testing into the main ROS repository. +This is when your packages actually become available to the rest of the ROS community. +To get updates on when the next synchronization (sync) is coming, subscribe to the `Packaging and Release Management Category on Open Robotics Discourse `_. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst b/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst index b60e80db8ff..d0c8b7fe244 100644 --- a/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst +++ b/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst @@ -1,45 +1,49 @@ -.. warning:: - - If the file ``~/.config/bloom`` exists on your computer, it is likely that you have done this before so you should skip this section. - -During the release process, multiple HTTPS Git operations will be performed that require password authentication. -To avoid being repeatedly asked for a password, a `Personal Access Token (PAT) `_ will be set up. -If you have multi-factor authentication setup on your GitHub account, you **must** setup a Personal Access Token. - -Create a Personal Access Token by: - -#. Log in to GitHub and go to `Personal access tokens `_. -#. Click the **Generate new token** button. -#. In the dropdown, select **Generate new token (classic)** -#. Set **Note** to something like ``Bloom token``. -#. Set **Expiration** to **No expiration**. -#. Tick the ``public_repo`` and ``workflow`` checkboxes. -#. Click the **Generate token** button. - -After you have created the token, you will end up back at the *Personal access tokens* page. -**Copy the alphanumeric token** that is highlighted in green. - -Save your GitHub username and PAT to a new file called ``~/.config/bloom``, with the format below: - -.. code-block:: text - - { - "github_user": "", - "oauth_token": "" - } - -Configure in your ``~/.gitconfig`` that your GitHub account and PAT are used for all release repositories under `ros2-gbp `_: - -.. code-block:: ini - - [credential "https://github.com/ros2-gbp"] - username = x-access-token - helper = "!f() { test \"$1\" = get && echo \"password=\"; }; f" - -You can additionally use different GitHub accounts and PATs for individual release repositories: - -.. code-block:: ini - - [credential "https://github.com/ros2-gbp/my_package-release.git"] - username = x-access-token - helper = "!f() { test \"$1\" = get && echo \"password=\"; }; f" +.. redirect-from:: + + How-To-Guides/Releasing/_Personal-Access-Token + +.. warning:: + + If the file ``~/.config/bloom`` exists on your computer, it is likely that you have done this before so you should skip this section. + +During the release process, multiple HTTPS Git operations will be performed that require password authentication. +To avoid being repeatedly asked for a password, a `Personal Access Token (PAT) `_ will be set up. +If you have multi-factor authentication setup on your GitHub account, you **must** setup a Personal Access Token. + +Create a Personal Access Token by: + +#. Log in to GitHub and go to `Personal access tokens `_. +#. Click the **Generate new token** button. +#. In the dropdown, select **Generate new token (classic)** +#. Set **Note** to something like ``Bloom token``. +#. Set **Expiration** to **No expiration**. +#. Tick the ``public_repo`` and ``workflow`` checkboxes. +#. Click the **Generate token** button. + +After you have created the token, you will end up back at the *Personal access tokens* page. +**Copy the alphanumeric token** that is highlighted in green. + +Save your GitHub username and PAT to a new file called ``~/.config/bloom``, with the format below: + +.. code-block:: text + + { + "github_user": "", + "oauth_token": "" + } + +Configure in your ``~/.gitconfig`` that your GitHub account and PAT are used for all release repositories under `ros2-gbp `_: + +.. code-block:: ini + + [credential "https://github.com/ros2-gbp"] + username = x-access-token + helper = "!f() { test \"$1\" = get && echo \"password=\"; }; f" + +You can additionally use different GitHub accounts and PATs for individual release repositories: + +.. code-block:: ini + + [credential "https://github.com/ros2-gbp/my_package-release.git"] + username = x-access-token + helper = "!f() { test \"$1\" = get && echo \"password=\"; }; f" \ No newline at end of file diff --git a/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst b/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst index 5053a56be1c..3a8d28dd972 100644 --- a/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst +++ b/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst @@ -1,89 +1,90 @@ -.. redirect-from:: - - Tutorials/Run-2-nodes-in-a-single-docker-container - Tutorials/Run-2-nodes-in-two-separate-docker-containers - Guides/Run-2-nodes-in-two-separate-docker-containers - -Running ROS 2 nodes in Docker [community-contributed] -===================================================== - -Run two nodes in a single docker container ------------------------------------------- - -Pull the ROS docker image with tag "{DISTRO}-desktop". - -.. code-block:: console - - $ docker pull osrf/ros:{DISTRO}-desktop - - -Run the image in a container in interactive mode. - -.. code-block:: console - - $ docker run -it osrf/ros:{DISTRO}-desktop - -Your best friend is the ``ros2`` command line help now. - -.. code-block:: console - - $ ros2 --help - -E.g. list all installed packages. - -.. code-block:: console - - $ ros2 pkg list - (you will see a list of packages) - - -E.g. list all executables: - -.. code-block:: console - - $ ros2 pkg executables - (you will see a list of ) - - -Run a minimal example of 2 C++ nodes (1 topic subscriber ``listener``, 1 topic publisher ``talker``) from the package ``demo_nodes_cpp`` in this container: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener & - $ ros2 run demo_nodes_cpp talker - -Run two nodes in two separate docker containers ------------------------------------------------ - -Open a terminal. -Run the image in a container in interactive mode and launch a topic publisher (executable ``talker`` from the package ``demo_nodes_cpp``) with ``ros2 run``: - -.. code-block:: console - - $ docker run -it --rm osrf/ros:{DISTRO}-desktop ros2 run demo_nodes_cpp talker - -Open a second terminal. -Run the image in a container in interactive mode and launch a topic subscriber (executable ``listener`` from the package ``demo_nodes_cpp``) with ``ros2 run``: - -.. code-block:: console - - $ docker run -it --rm osrf/ros:{DISTRO}-desktop ros2 run demo_nodes_cpp listener - -As an alternative to the command line invocation, you can create a ``docker-compose.yml`` file (here version 2) with the following (minimal) content: - -.. code-block:: yaml - - version: '2' - - services: - talker: - image: osrf/ros:{DISTRO}-desktop - command: ros2 run demo_nodes_cpp talker - listener: - image: osrf/ros:{DISTRO}-desktop - command: ros2 run demo_nodes_cpp listener - depends_on: - - talker - -To run the containers call ``docker compose up`` in the same directory. -You can close the containers with ``Ctrl+C``. +.. redirect-from:: + + Tutorials/Run-2-nodes-in-a-single-docker-container + Tutorials/Run-2-nodes-in-two-separate-docker-containers + Guides/Run-2-nodes-in-two-separate-docker-containers + How-To-Guides/Run-2-nodes-in-single-or-separate-docker-containers + +Running ROS 2 nodes in Docker [community-contributed] +===================================================== + +Run two nodes in a single docker container +------------------------------------------ + +Pull the ROS docker image with tag "{DISTRO}-desktop". + +.. code-block:: console + + $ docker pull osrf/ros:{DISTRO}-desktop + + +Run the image in a container in interactive mode. + +.. code-block:: console + + $ docker run -it osrf/ros:{DISTRO}-desktop + +Your best friend is the ``ros2`` command line help now. + +.. code-block:: console + + $ ros2 --help + +E.g. list all installed packages. + +.. code-block:: console + + $ ros2 pkg list + (you will see a list of packages) + + +E.g. list all executables: + +.. code-block:: console + + $ ros2 pkg executables + (you will see a list of ) + + +Run a minimal example of 2 C++ nodes (1 topic subscriber ``listener``, 1 topic publisher ``talker``) from the package ``demo_nodes_cpp`` in this container: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener & + $ ros2 run demo_nodes_cpp talker + +Run two nodes in two separate docker containers +----------------------------------------------- + +Open a terminal. +Run the image in a container in interactive mode and launch a topic publisher (executable ``talker`` from the package ``demo_nodes_cpp``) with ``ros2 run``: + +.. code-block:: console + + $ docker run -it --rm osrf/ros:{DISTRO}-desktop ros2 run demo_nodes_cpp talker + +Open a second terminal. +Run the image in a container in interactive mode and launch a topic subscriber (executable ``listener`` from the package ``demo_nodes_cpp``) with ``ros2 run``: + +.. code-block:: console + + $ docker run -it --rm osrf/ros:{DISTRO}-desktop ros2 run demo_nodes_cpp listener + +As an alternative to the command line invocation, you can create a ``docker-compose.yml`` file (here version 2) with the following (minimal) content: + +.. code-block:: yaml + + version: '2' + + services: + talker: + image: osrf/ros:{DISTRO}-desktop + command: ros2 run demo_nodes_cpp talker + listener: + image: osrf/ros:{DISTRO}-desktop + command: ros2 run demo_nodes_cpp listener + depends_on: + - talker + +To run the containers call ``docker compose up`` in the same directory. +You can close the containers with ``Ctrl+C``. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst b/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst index 02d6150d0f2..2b622f41300 100644 --- a/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst +++ b/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst @@ -1,223 +1,227 @@ -Setup ROS 2 with VSCode and Docker [community-contributed] -========================================================== - - -.. contents:: Contents - :depth: 2 - :local: - - -Install VS Code and Docker --------------------------- - - -Using Visual Studio Code and Docker Containers will enable you to run your favorite ROS 2 Distribution without the necessity to change your operating system or use a virtual machine. -With this tutorial you can set up a docker container, which can be used for your future ROS 2 projects. - - -Install Docker -^^^^^^^^^^^^^^ - - -To install docker and set the correct user rights please use the following commands. - -.. code-block:: console - - $ sudo apt install docker.io git python3-pip - $ pip3 install vcstool - $ echo export PATH=$HOME/.local/bin:$PATH >> ~/.bashrc - $ source ~/.bashrc - $ sudo groupadd docker - $ sudo usermod -aG docker $USER - $ newgrp docker - -Now you can check if the installation was successful by running the following command: - -.. code-block:: console - - $ docker run hello-world - -You might need to start the Docker Daemon first, if you cannot run hello-world out of the box: - -.. code-block:: console - - $ sudo systemctl start docker - -Install VS Code -^^^^^^^^^^^^^^^ - -To install VS Code please use the following commands: - -.. code-block:: console - - $ sudo apt update - $ sudo apt install software-properties-common apt-transport-https wget -y - $ wget -q https://packages.microsoft.com/keys/microsoft.asc -O- | sudo apt-key add - - $ sudo add-apt-repository "deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main" - $ sudo apt install code - - -You can run VS Code by typing ``code`` in a terminal. - - -Install Remote Development Extension -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - -Within VS Code search in Extensions (CTRL+SHIFT+X) for the "Remote Development" Extension and install it. - - -Configure workspace in Docker and VS Code ------------------------------------------ - -Add your ROS 2 workspace -^^^^^^^^^^^^^^^^^^^^^^^^ - - -Add a workspace in order to build and open them in a container, e.g.: - -.. code-block:: console - - $ cd ~/ - $ mkdir ws - $ cd ws - $ mkdir src - -Now create a ``.devcontainer`` folder in the root of your workspace and add a ``devcontainer.json`` and ``Dockerfile`` to this ``.devcontainer`` folder. -The workspace structure should look like this: - -:: - - ws - ├── .devcontainer - │ ├── devcontainer.json - │ └── Dockerfile - ├── src - ├── package1 - └── package2 - - -With ``File->Open Folder...`` or ``Ctrl+K Ctrl+O``, open the ``ws`` folder of your workspace in VS Code. - -Edit ``devcontainer.json`` for your environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For the Dev Container to function properly, we have to build it with the correct user. -Therefore add the following to ``.devcontainer/devcontainer.json``: - -.. code-block:: json - - { - "name": "ROS 2 Development Container", - "privileged": true, - "remoteUser": "YOUR_USERNAME", - "build": { - "dockerfile": "Dockerfile", - "args": { - "USERNAME": "YOUR_USERNAME" - } - }, - "workspaceFolder": "/home/ws", - "workspaceMount": "source=${localWorkspaceFolder},target=/home/ws,type=bind", - "customizations": { - "vscode": { - "extensions":[ - "ms-vscode.cpptools", - "ms-vscode.cpptools-themes", - "twxs.cmake", - "donjayamanne.python-extension-pack", - "eamodio.gitlens", - "ms-iot.vscode-ros" - ] - } - }, - "containerEnv": { - "DISPLAY": "unix:0", - "ROS_AUTOMATIC_DISCOVERY_RANGE": "LOCALHOST", - "ROS_DOMAIN_ID": "42" - }, - "runArgs": [ - "--net=host", - "--pid=host", - "--ipc=host", - "-e", "DISPLAY=${env:DISPLAY}" - ], - "mounts": [ - "source=/tmp/.X11-unix,target=/tmp/.X11-unix,type=bind,consistency=cached", - "source=/dev/dri,target=/dev/dri,type=bind,consistency=cached" - ], - "postCreateCommand": "sudo rosdep update && sudo rosdep install --from-paths src --ignore-src -y && sudo chown -R $(whoami) /home/ws/" - } - - - -Use ``Ctrl+F`` to open the search and replace menu. -Search for ``YOUR_USERNAME`` and replace it with your ``Linux username``. -If you do not know your username, you can find it by running ``echo $USERNAME`` in the terminal. - - -Edit ``Dockerfile`` -^^^^^^^^^^^^^^^^^^^ - -Open the Dockerfile and add the following contents: - - -.. code-block:: bash - - FROM ros:ROS_DISTRO - ARG USERNAME=USERNAME - ARG USER_UID=1000 - ARG USER_GID=$USER_UID - - # Delete user if it exists in container (e.g Ubuntu Noble: ubuntu) - RUN if id -u $USER_UID ; then userdel `id -un $USER_UID` ; fi - - # Create the user - RUN groupadd --gid $USER_GID $USERNAME \ - && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \ - # - # [Optional] Add sudo support. Omit if you don't need to install software after connecting. - && apt-get update \ - && apt-get install -y sudo \ - && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \ - && chmod 0440 /etc/sudoers.d/$USERNAME - RUN apt-get update && apt-get upgrade -y - RUN apt-get install -y python3-pip - ENV SHELL /bin/bash - - # ******************************************************** - # * Anything else you want to do like clean up goes here * - # ******************************************************** - - # [Optional] Set the default user. Omit if you want to keep the default as root. - USER $USERNAME - CMD ["/bin/bash"] - -Replace ``ROS_DISTRO`` with the ROS 2 distribution you wish to use as base image above, for example ``rolling``. - - -Open and Build Development Container ------------------------------------- - -Use ``View->Command Palette...`` or ``Ctrl+Shift+P`` to open the command palette. -Search for the command ``Dev Containers: Reopen in Container`` and execute it. -This will build your development docker container for your. -It will take a while - sit back or go for a coffee. - - -Test Container -^^^^^^^^^^^^^^ - -To test if everything worked correctly, open a terminal in the container using ``View->Terminal`` or ``Ctrl+Shift+``` and ``New Terminal`` in VS Code. -Inside the terminal do the following: - -.. code-block:: console - - $ sudo apt install ros-$ROS_DISTRO-rviz2 -y - $ source /opt/ros/$ROS_DISTRO/setup.bash - $ rviz2 - -.. Note:: There might be a problem with displaying RVIZ. - Please make sure to allow the user to access X window system with ``xhost +local:``. - If no window still pops up, then check the value of ``echo $DISPLAY`` - if the output is 1, you can fix this problem with ``echo "export DISPLAY=unix:1" >> /etc/bash.bashrc`` and then test it again. - You can also change the DISPLAY value in the devcontainer.json and rebuild it. +.. redirect-from:: + + How-To-Guides/Setup-ROS-2-with-VSCode-and-Docker-Container + +Setup ROS 2 with VSCode and Docker [community-contributed] +========================================================== + + +.. contents:: Contents + :depth: 2 + :local: + + +Install VS Code and Docker +-------------------------- + + +Using Visual Studio Code and Docker Containers will enable you to run your favorite ROS 2 Distribution without the necessity to change your operating system or use a virtual machine. +With this tutorial you can set up a docker container, which can be used for your future ROS 2 projects. + + +Install Docker +^^^^^^^^^^^^^^ + + +To install docker and set the correct user rights please use the following commands. + +.. code-block:: console + + $ sudo apt install docker.io git python3-pip + $ pip3 install vcstool + $ echo export PATH=$HOME/.local/bin:$PATH >> ~/.bashrc + $ source ~/.bashrc + $ sudo groupadd docker + $ sudo usermod -aG docker $USER + $ newgrp docker + +Now you can check if the installation was successful by running the following command: + +.. code-block:: console + + $ docker run hello-world + +You might need to start the Docker Daemon first, if you cannot run hello-world out of the box: + +.. code-block:: console + + $ sudo systemctl start docker + +Install VS Code +^^^^^^^^^^^^^^^ + +To install VS Code please use the following commands: + +.. code-block:: console + + $ sudo apt update + $ sudo apt install software-properties-common apt-transport-https wget -y + $ wget -q https://packages.microsoft.com/keys/microsoft.asc -O- | sudo apt-key add - + $ sudo add-apt-repository "deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main" + $ sudo apt install code + + +You can run VS Code by typing ``code`` in a terminal. + + +Install Remote Development Extension +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +Within VS Code search in Extensions (CTRL+SHIFT+X) for the "Remote Development" Extension and install it. + + +Configure workspace in Docker and VS Code +----------------------------------------- + +Add your ROS 2 workspace +^^^^^^^^^^^^^^^^^^^^^^^^ + + +Add a workspace in order to build and open them in a container, e.g.: + +.. code-block:: console + + $ cd ~/ + $ mkdir ws + $ cd ws + $ mkdir src + +Now create a ``.devcontainer`` folder in the root of your workspace and add a ``devcontainer.json`` and ``Dockerfile`` to this ``.devcontainer`` folder. +The workspace structure should look like this: + +:: + + ws + ├── .devcontainer + │ ├── devcontainer.json + │ └── Dockerfile + ├── src + ├── package1 + └── package2 + + +With ``File->Open Folder...`` or ``Ctrl+K Ctrl+O``, open the ``ws`` folder of your workspace in VS Code. + +Edit ``devcontainer.json`` for your environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For the Dev Container to function properly, we have to build it with the correct user. +Therefore add the following to ``.devcontainer/devcontainer.json``: + +.. code-block:: json + + { + "name": "ROS 2 Development Container", + "privileged": true, + "remoteUser": "YOUR_USERNAME", + "build": { + "dockerfile": "Dockerfile", + "args": { + "USERNAME": "YOUR_USERNAME" + } + }, + "workspaceFolder": "/home/ws", + "workspaceMount": "source=${localWorkspaceFolder},target=/home/ws,type=bind", + "customizations": { + "vscode": { + "extensions":[ + "ms-vscode.cpptools", + "ms-vscode.cpptools-themes", + "twxs.cmake", + "donjayamanne.python-extension-pack", + "eamodio.gitlens", + "ms-iot.vscode-ros" + ] + } + }, + "containerEnv": { + "DISPLAY": "unix:0", + "ROS_AUTOMATIC_DISCOVERY_RANGE": "LOCALHOST", + "ROS_DOMAIN_ID": "42" + }, + "runArgs": [ + "--net=host", + "--pid=host", + "--ipc=host", + "-e", "DISPLAY=${env:DISPLAY}" + ], + "mounts": [ + "source=/tmp/.X11-unix,target=/tmp/.X11-unix,type=bind,consistency=cached", + "source=/dev/dri,target=/dev/dri,type=bind,consistency=cached" + ], + "postCreateCommand": "sudo rosdep update && sudo rosdep install --from-paths src --ignore-src -y && sudo chown -R $(whoami) /home/ws/" + } + + + +Use ``Ctrl+F`` to open the search and replace menu. +Search for ``YOUR_USERNAME`` and replace it with your ``Linux username``. +If you do not know your username, you can find it by running ``echo $USERNAME`` in the terminal. + + +Edit ``Dockerfile`` +^^^^^^^^^^^^^^^^^^^ + +Open the Dockerfile and add the following contents: + + +.. code-block:: bash + + FROM ros:ROS_DISTRO + ARG USERNAME=USERNAME + ARG USER_UID=1000 + ARG USER_GID=$USER_UID + + # Delete user if it exists in container (e.g Ubuntu Noble: ubuntu) + RUN if id -u $USER_UID ; then userdel `id -un $USER_UID` ; fi + + # Create the user + RUN groupadd --gid $USER_GID $USERNAME \ + && useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \ + # + # [Optional] Add sudo support. Omit if you don't need to install software after connecting. + && apt-get update \ + && apt-get install -y sudo \ + && echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \ + && chmod 0440 /etc/sudoers.d/$USERNAME + RUN apt-get update && apt-get upgrade -y + RUN apt-get install -y python3-pip + ENV SHELL /bin/bash + + # ******************************************************** + # * Anything else you want to do like clean up goes here * + # ******************************************************** + + # [Optional] Set the default user. Omit if you want to keep the default as root. + USER $USERNAME + CMD ["/bin/bash"] + +Replace ``ROS_DISTRO`` with the ROS 2 distribution you wish to use as base image above, for example ``rolling``. + + +Open and Build Development Container +------------------------------------ + +Use ``View->Command Palette...`` or ``Ctrl+Shift+P`` to open the command palette. +Search for the command ``Dev Containers: Reopen in Container`` and execute it. +This will build your development docker container for your. +It will take a while - sit back or go for a coffee. + + +Test Container +^^^^^^^^^^^^^^ + +To test if everything worked correctly, open a terminal in the container using ``View->Terminal`` or ``Ctrl+Shift+``` and ``New Terminal`` in VS Code. +Inside the terminal do the following: + +.. code-block:: console + + $ sudo apt install ros-$ROS_DISTRO-rviz2 -y + $ source /opt/ros/$ROS_DISTRO/setup.bash + $ rviz2 + +.. Note:: There might be a problem with displaying RVIZ. + Please make sure to allow the user to access X window system with ``xhost +local:``. + If no window still pops up, then check the value of ``echo $DISPLAY`` - if the output is 1, you can fix this problem with ``echo "export DISPLAY=unix:1" >> /etc/bash.bashrc`` and then test it again. + You can also change the DISPLAY value in the devcontainer.json and rebuild it. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst b/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst index 712777738fc..75a5dd8dba9 100644 --- a/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst +++ b/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst @@ -1,141 +1,145 @@ -Supplementing custom rosdep keys -================================ - -.. contents:: Contents - :depth: 2 - :local: - -Overview and motivation ------------------------ - -As explained in :doc:`../Intermediate/Rosdep`, ``rosdep`` looks for rosdep keys in ``package.xml`` files and maps them to packages to be installed for the ROS distribution and OS in use. -Anyone can request for new rosdep keys to be added by `contributing to rosdistro `_. -This is the preferred course of action when you have some dependency (like a ``apt`` or ``pip`` package) that you wish to be able to install via ``rosdep``. - -However, there are many cases when contributing your keys directly might be difficult. -For example, if the dependency - -1. is not available on the target distributions default APT (or pip) repositories -2. is a proprietary library -3. is some niche library which is useful only for you or your organization -4. is a ROS package you :doc:`built and packaged yourself <../../How-To-Guides/Building-a-Custom-Deb-Package>`, but don't wish to share with the broader ROS community - -While the option exists to :doc:`fork rosdistro <../../How-To-Guides/Using-Custom-Rosdistro>` in its entirety, this might be overkill if you just want to keep using a official ROS distribution as usual, only with some extra rosdep keys defined on top. -This tutorial explains how to achieve this. - -As a word of warning though, please don't use this indiscriminately. -It can cause very hard to debug problems because of binary incompatibilities which can manifest in silent failures, unexplained crashes, or data corruption. -And if you're asking anyone for help on a system with this enabled, make sure to explain everything that's being added or overridden. - -Preliminaries: How ``rosdep`` fetches rosdep keys -------------------------------------------------- - -In order to get a good understanding of what we're about to do, let's first explore some relevant details about how ``rosdep`` works. - -``rosdep`` is similar to other tools like ``apt`` that use a sources list to maintain a local index. -These sources are stored in ``/etc/ros/rosdep/sources.list.d``. -This is similar to how apt stores repositories in ``/etc/apt/sources.list.d``. - -By default (as part of first-time setup, ``rosdep init``), you only have a single sources file: ``/etc/ros/rosdep/sources.list.d/20-default.list``. -Inspecting its contents, you will see entries like these: - -.. code-block:: console - - $ cat /etc/ros/rosdep/sources.list.d/20-default.list - ... - yaml https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml - yaml https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/python.yaml - ... - -These entries are what dictates where ``rosdep`` fetches rosdep keys and their mappings (rosdep **rules**) from when ``rosdep update`` is called. -When called, ``rosdep`` compiles the relevant contents from all declared entries in all sources files into a local cached index. -This local index is then used when installing or looking up ("resolving") rosdep keys. - -For example, the fact that the first entry (``base.yaml``) defines the ``libopencv-dev`` key (see `here `_) is what allows ``rosdep`` to resolve it: - -.. code-block:: console - - $ rosdep where-defined libopencv-dev - https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml - $ rosdep resolve libopencv-dev - #apt - libopencv-dev - -In summary, it allows ``rosdep`` to resolve the ``libopencv-dev`` key to the ``apt`` package of the same name. - -Note that, from the output above, we can deduce that the command was run on a Ubuntu or Debian OS. -On RHEL, the key instead resolves to the DNF package ``opencv-devel``: - -.. code-block:: console - - $ rosdep resolve libopencv-dev --os=rhel:9 - #dnf - opencv-devel - -Extending ``rosdep`` with a custom sources file ------------------------------------------------ - -The above hopefully makes it clear what needs to be done to get ``rosdep`` to understand new keys: add a new custom sources file! - -As a toy example, let's add a new sources file telling ``rosdep`` to fetch keys from a YAML file stored on the local machine. -Fire up your favorite text editor and write the following into ``/etc/ros/rosdep/sources.list.d/30-custom.list`` (the editor will need to be launched with root privileges, e.g. via ``sudo``): - -.. code-block:: yaml - - yaml file:///etc/ros/rosdep/custom_rules.yaml - -Now write the following into ``/etc/ros/rosdep/custom_rules.yaml``: - -.. code-block:: yaml - - awesome_library: - ubuntu: [awesome_library] - that_other_library: - ubuntu: - pip: - packages: [another_library] - -This defines two new rosdep rules: - -1. The key ``awesome_library``, defined only for Ubuntu, mapping to the ``apt`` package of the same name -2. The key ``that_other_library``, defined only for Ubuntu, mapping to the ``pip`` package named ``another_library`` - -After running ``rosdep update``, ``rosdep`` will detect the new ``30-custom.list``, prompting it to scan the contents of the ``custom_rules.yaml`` file. -Now ``rosdep`` is set up to recognize these new keys and what they should map to: - -.. code-block:: console - - $ rosdep resolve awesome_library - #apt - awesome_library - $ rosdep resolve that_other_library - #pip - another_library - -Now all you have to do is add ``awesome_library`` to your ROS packages ``package.xml``, and ``rosdep`` will know how to install the dependency! - -Closing remarks ---------------- - -The toy example above only hints at what is possible with custom rosdep keys. - -- **Is your dependency an APT package hosted in a third party PPA?** - Not a problem. - Since all ``rosdep`` does is converting the key to a ``apt install`` invocation, APT will have no problem installing the package (provided you have added the PPA). -- **Is your dependency a pip package hosted in a third party index?** - Add the index to your ``pip.conf`` and you're good to go. -- **Sources files don't have to point to files on the local machine.** - Both ``file://`` and ``https://`` syntax is supported (on Linux, absolute paths start with ``/``, which leads to a triple slash like ``file:///etc/rosdep/my.file``). -- **Sources are loaded in alphabetical order.** - If you add a conflicting rule in the 30 prefix it will not be used. - If you created a sources file with a 10 prefix it will override packages in the default list (prefix 20). - If you're using packages installed from binary repositories it's highly recommended to not override dependency declarations as it will likely cause binary incompatibilities which can be very hard to debug. -- **Merging keys is not possible.** - It is not possible to e.g. only add a ``fedora`` installation rule to an existing rosdep key. - Depending on the load order, such rule would either be ignored, or it would completely override the whole rosdep key, removing all other installers. - -Further reading ---------------- - -- https://docs.ros.org/en/independent/api/rosdep/html/rosdep_yaml_format.html -- https://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html +.. redirect-from:: + + Tutorials/Advanced/Supplementing-Custom-Rosdep-Keys + +Supplementing custom rosdep keys +================================ + +.. contents:: Contents + :depth: 2 + :local: + +Overview and motivation +----------------------- + +As explained in :doc:`../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep`, ``rosdep`` looks for rosdep keys in ``package.xml`` files and maps them to packages to be installed for the ROS distribution and OS in use. +Anyone can request for new rosdep keys to be added by `contributing to rosdistro `_. +This is the preferred course of action when you have some dependency (like a ``apt`` or ``pip`` package) that you wish to be able to install via ``rosdep``. + +However, there are many cases when contributing your keys directly might be difficult. +For example, if the dependency + +1. is not available on the target distributions default APT (or pip) repositories +2. is a proprietary library +3. is some niche library which is useful only for you or your organization +4. is a ROS package you :doc:`built and packaged yourself `, but don't wish to share with the broader ROS community + +While the option exists to :doc:`fork rosdistro <../../Migration-and-Upgrades/Using-Custom-Rosdistro>` in its entirety, this might be overkill if you just want to keep using a official ROS distribution as usual, only with some extra rosdep keys defined on top. +This tutorial explains how to achieve this. + +As a word of warning though, please don't use this indiscriminately. +It can cause very hard to debug problems because of binary incompatibilities which can manifest in silent failures, unexplained crashes, or data corruption. +And if you're asking anyone for help on a system with this enabled, make sure to explain everything that's being added or overridden. + +Preliminaries: How ``rosdep`` fetches rosdep keys +------------------------------------------------- + +In order to get a good understanding of what we're about to do, let's first explore some relevant details about how ``rosdep`` works. + +``rosdep`` is similar to other tools like ``apt`` that use a sources list to maintain a local index. +These sources are stored in ``/etc/ros/rosdep/sources.list.d``. +This is similar to how apt stores repositories in ``/etc/apt/sources.list.d``. + +By default (as part of first-time setup, ``rosdep init``), you only have a single sources file: ``/etc/ros/rosdep/sources.list.d/20-default.list``. +Inspecting its contents, you will see entries like these: + +.. code-block:: console + + $ cat /etc/ros/rosdep/sources.list.d/20-default.list + ... + yaml https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml + yaml https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/python.yaml + ... + +These entries are what dictates where ``rosdep`` fetches rosdep keys and their mappings (rosdep **rules**) from when ``rosdep update`` is called. +When called, ``rosdep`` compiles the relevant contents from all declared entries in all sources files into a local cached index. +This local index is then used when installing or looking up ("resolving") rosdep keys. + +For example, the fact that the first entry (``base.yaml``) defines the ``libopencv-dev`` key (see `here `_) is what allows ``rosdep`` to resolve it: + +.. code-block:: console + + $ rosdep where-defined libopencv-dev + https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml + $ rosdep resolve libopencv-dev + #apt + libopencv-dev + +In summary, it allows ``rosdep`` to resolve the ``libopencv-dev`` key to the ``apt`` package of the same name. + +Note that, from the output above, we can deduce that the command was run on a Ubuntu or Debian OS. +On RHEL, the key instead resolves to the DNF package ``opencv-devel``: + +.. code-block:: console + + $ rosdep resolve libopencv-dev --os=rhel:9 + #dnf + opencv-devel + +Extending ``rosdep`` with a custom sources file +----------------------------------------------- + +The above hopefully makes it clear what needs to be done to get ``rosdep`` to understand new keys: add a new custom sources file! + +As a toy example, let's add a new sources file telling ``rosdep`` to fetch keys from a YAML file stored on the local machine. +Fire up your favorite text editor and write the following into ``/etc/ros/rosdep/sources.list.d/30-custom.list`` (the editor will need to be launched with root privileges, e.g. via ``sudo``): + +.. code-block:: yaml + + yaml file:///etc/ros/rosdep/custom_rules.yaml + +Now write the following into ``/etc/ros/rosdep/custom_rules.yaml``: + +.. code-block:: yaml + + awesome_library: + ubuntu: [awesome_library] + that_other_library: + ubuntu: + pip: + packages: [another_library] + +This defines two new rosdep rules: + +1. The key ``awesome_library``, defined only for Ubuntu, mapping to the ``apt`` package of the same name +2. The key ``that_other_library``, defined only for Ubuntu, mapping to the ``pip`` package named ``another_library`` + +After running ``rosdep update``, ``rosdep`` will detect the new ``30-custom.list``, prompting it to scan the contents of the ``custom_rules.yaml`` file. +Now ``rosdep`` is set up to recognize these new keys and what they should map to: + +.. code-block:: console + + $ rosdep resolve awesome_library + #apt + awesome_library + $ rosdep resolve that_other_library + #pip + another_library + +Now all you have to do is add ``awesome_library`` to your ROS packages ``package.xml``, and ``rosdep`` will know how to install the dependency! + +Closing remarks +--------------- + +The toy example above only hints at what is possible with custom rosdep keys. + +- **Is your dependency an APT package hosted in a third party PPA?** + Not a problem. + Since all ``rosdep`` does is converting the key to a ``apt install`` invocation, APT will have no problem installing the package (provided you have added the PPA). +- **Is your dependency a pip package hosted in a third party index?** + Add the index to your ``pip.conf`` and you're good to go. +- **Sources files don't have to point to files on the local machine.** + Both ``file://`` and ``https://`` syntax is supported (on Linux, absolute paths start with ``/``, which leads to a triple slash like ``file:///etc/rosdep/my.file``). +- **Sources are loaded in alphabetical order.** + If you add a conflicting rule in the 30 prefix it will not be used. + If you created a sources file with a 10 prefix it will override packages in the default list (prefix 20). + If you're using packages installed from binary repositories it's highly recommended to not override dependency declarations as it will likely cause binary incompatibilities which can be very hard to debug. +- **Merging keys is not possible.** + It is not possible to e.g. only add a ``fedora`` installation rule to an existing rosdep key. + Depending on the load order, such rule would either be ignored, or it would completely override the whole rosdep key, removing all other installers. + +Further reading +--------------- + +- https://docs.ros.org/en/independent/api/rosdep/html/rosdep_yaml_format.html +- https://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html \ No newline at end of file diff --git a/source/Developer-Tools/Build/The-Keystore.rst b/source/Developer-Tools/Build/The-Keystore.rst index 6ac5b90c048..480c3e269f6 100644 --- a/source/Developer-Tools/Build/The-Keystore.rst +++ b/source/Developer-Tools/Build/The-Keystore.rst @@ -1,262 +1,263 @@ -.. redirect-from:: - - Tutorials/Security/The-Keystore - -.. _The-Keystore: - -Understanding the security keystore -=================================== - -**Goal:** Explore files located in the ROS 2 security keystore. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- - -Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. - -The ``sros2`` package can be used to create keys, certificates and policies necessary to enable ROS 2 security. -However, the security configuration is extremely flexible. -A basic understanding of the ROS 2 Security Keystore will allow integration with an existing PKI (Public Key Infrastructure) and management of sensitive key materials consistent with organizational policies. - - -Security Artifact Locations ---------------------------- - -With communications security enabled in the prior tutorial, let's take a look at the files which were created when security was enabled. -These are the files which make encryption possible. - -The ``sros2`` utilities (``ros2 security ...``) separate files into public, private and enclave key materials. - -ROS uses the directory defined by the environmental variable ``ROS_SECURITY_KEYSTORE`` as the keystore. -For this tutorial, we use the directory ``~/sros2_demo/demo_keystore``. - - -Public Key Materials -^^^^^^^^^^^^^^^^^^^^ - -You will find three encryption certificates in the public directory at ``~/sros2_demo/demo_keystore/public``; however, the identity and permissions certificates are actually just a link to the Certificate Authority (CA) certificate. - -In a public key infrastructure, the `Certificate Authority `_ acts as a trust anchor: it validates the identities and permissions of participants. -For ROS, that means all the nodes that participate in the ROS graph (which may extend to an entire fleet of individual robots). -By placing the Certificate Authority's certificate (``ca.cert.pem``) in the proper location on the robot, all ROS nodes can establish mutual trust with other nodes using the same Certificate Authority. - -Although in our tutorials we create a Certificate Authority on-the-fly, in a production system this should be done according to a pre-defined security plan. -Typically the Certificate Authority for a production system will be created off-line, and placed on the robot during initial setup. -It may be unique for each robot, or shared across a fleet of robots all intended to trust each other. - -DDS (and ROS, by extension) supports separation of identity and permission trust chains, so each function has its own certificate authority. -In most cases a ROS system security plan does not require a separation between these duties, so the security utilities generate a single Certificate Authority which is used for both identity and permissions. - -Use ``openssl`` to view this x509 certificate and display it as text: - -.. code-block:: console - - $ cd ~/sros2_demo/demo_keystore/public - $ openssl x509 -in ca.cert.pem -text -noout - -The output should look similar to the following:: - - Certificate: - Data: - Version: 3 (0x2) - Serial Number: - 02:8e:9a:24:ea:10:55:cb:e6:ea:e8:7a:c0:5f:58:6d:37:42:78:aa - Signature Algorithm: ecdsa-with-SHA256 - Issuer: CN = sros2CA - Validity - Not Before: Jun 1 16:57:37 2021 GMT - Not After : May 31 16:57:37 2031 GMT - Subject: CN = sros2CA - Subject Public Key Info: - Public Key Algorithm: id-ecPublicKey - Public-Key: (256 bit) - pub: - 04:71:e9:37:d7:32:ba:b8:a0:97:66:da:9f:e3:c4: - 08:4f:7a:13:59:24:c6:cf:6a:f7:95:c5:cd:82:c0: - 7f:7f:e3:90:dd:7b:0f:77:d1:ee:0e:af:68:7c:76: - a9:ca:60:d7:1e:2c:01:d7:bc:7e:e3:86:2a:9f:38: - dc:ed:39:c5:32 - ASN1 OID: prime256v1 - NIST CURVE: P-256 - X509v3 extensions: - X509v3 Basic Constraints: critical - CA:TRUE, pathlen:1 - Signature Algorithm: ecdsa-with-SHA256 - 30:45:02:21:00:d4:fc:d8:45:ff:a4:51:49:98:4c:f0:c4:3f: - e0:e7:33:19:8e:31:3c:d0:43:e7:e9:8f:36:f0:90:18:ed:d7: - 7d:02:20:30:84:f7:04:33:87:bb:4f:d3:8b:95:61:48:df:83: - 4b:e5:92:b3:e6:ee:3c:d5:cf:30:43:09:04:71:bd:dd:7c - -Some things to note about this CA certificate: - - The certificate subject name ``sros2CA`` is the default provided by the ``sros2`` utilities. - - This certificate is valid for ten years from time of creation - - Like all certificates, this contains a public key used for public-private key encryption - - As a Root Certificate Authority, this is a `self-signed certificate `_; i.e., it is signed using its own private key. - -Since this is a public certificate, it can be freely copied as needed to establish trust throughout your ROS system. - - -Private Key Materials -^^^^^^^^^^^^^^^^^^^^^ - -Private key materials can be found in the keystore directory ``~/sros2_demo/demo_keystore/private``. -Similar to the ``public`` directory, this contains one certificate authority key ``ca.key.pem`` and symbolic links to it to be used as both an Identity and a Permissions CA private key. - -.. warning:: - - Protect this private key and create a secure backup of it! - -This is the private key associated with the public Certificate Authority which serves as the anchor for all security in your ROS system. -You will use it to modify encryption policies for the ROS graph and to add new ROS participants. -Depending upon your robot's security needs, the key can be protected with access permissions and locked down to another account, or it can be moved off the robot entirely and onto another system or device. -If the file is lost, you will be unable to change access permissions and add new participants to the system. -Similarly, any user or process with access to the file has the ability to modify system policies and participants. - -This file is only required for configuring the robot, but is not needed for the robot to run. -It can safely be stored offline in another system or removable media. - -The ``sros2`` utilities use `elliptic curve cryptograpy `_ rather than RSA for improved security and reduced key size. -Use the following command to show details about this elliptic curve private key: - - -.. code-block:: console - - $ cd ~/sros2_demo/demo_keystore/private - $ openssl ec -in ca.key.pem -text -noout - read EC key - Private-Key: (256 bit) - priv: - 93:da:76:b9:e3:91:ab:e9:42:76:f2:38:f1:9d:94: - 90:5e:b5:96:7b:7f:71:ee:13:1b:d4:a0:f9:48:fb: - ae:77 - pub: - 04:71:e9:37:d7:32:ba:b8:a0:97:66:da:9f:e3:c4: - 08:4f:7a:13:59:24:c6:cf:6a:f7:95:c5:cd:82:c0: - 7f:7f:e3:90:dd:7b:0f:77:d1:ee:0e:af:68:7c:76: - a9:ca:60:d7:1e:2c:01:d7:bc:7e:e3:86:2a:9f:38: - dc:ed:39:c5:32 - ASN1 OID: prime256v1 - NIST CURVE: P-256 - -In addition to the private key itself, note that the public key is listed, and it matches the public key listed in the Certificate Authority ``ca.cert.pem``. - - -Domain Governance Policy -^^^^^^^^^^^^^^^^^^^^^^^^ - -Find the domain governance policy in the enclave directory within the keystore, ``~/sros2_demo/demo_keystore/enclaves``. -The ``enclave`` directory contains XML governance policy document ``governance.xml``, as well as a copy of the document which has been signed by the Permissions CA as ``governance.p7s``. - -The ``governance.p7s`` file contains domain-wide settings such as how to handle unauthenticated participants, whether to encrypt discovery, and default rules for access to topics. - -Use the following command to validate the `S/MIME signature `_ of the governance file: - -.. code-block:: console - - $ openssl smime -verify -in governance.p7s -CAfile ../public/permissions_ca.cert.pem - -This command will print out the XML document, and the last line will be ``Verification successful`` to show that the document was properly signed by the Permissions CA. - - -Security Enclaves -^^^^^^^^^^^^^^^^^ - -Secure processes (typically ROS nodes) run within a security enclave. -In the simplest case, all the processes can be consolidated into the same enclave, and all processes will then use the same security policy. -However, to apply different policies to different processes, the processes can use different security enclaves when starting. -For more details about security enclaves, see the `design document `_. -The security enclave is specified by using the ROS argument ``--enclave`` when running a node. - -**Each security enclave requires six files** in order to enable security. -Each file **must** be named as defined below, and as outlined in the `DDS Security standard `_. -In order to avoid having multiple copies of the same files, the ``sros2`` utilities create links for each enclave to the single governance policy, the Identity CA and Permissions CA described above. - -See the following six files within the ``listener`` enclave. -Three are specific to this enclave, while three are generic to this ROS system: - - - ``key.pem``, the private key used to encrypt and decrypt within this enclave - - ``cert.pem``, the public certificate for this enclave; this certificate has been signed by the Identity CA - - ``permissions.p7s``, the permissions for this enclave; this file has been signed with the Permissions CA - - ``governance.p7s``, a link to the signed security policy file for this domain - - ``identity_ca.cert.pem``, a link to the Identity CA for this domain - - ``permissions_ca.cert.pem``, a link to the Permissions CA for this domain - -The private encryption key ``key.pem`` should be protected according to your security plan. -This key encrypts, decrypts and validates communications within this specific enclave. -Should the key be lost or stolen, revoke the key and create a new identity for this enclave. - -The file ``permissions.xml`` has also been created in this directory and can be used to recreate the signed permissions file. -However, this file is not required to enable security since DDS uses the signed version of the file instead. - - -Take the quiz! --------------- - -See if you can answer these questions about the ROS security keystore. -Begin with a new terminal session and enable security with the keystore created in the prior tutorial: - -.. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - - $ cd ~/sros2_demo/demo_keystore/enclaves/talker_listener/listener - -Make a backup copy of ``permissions.p7s`` before beginning. - -.. tabs:: - - .. group-tab:: Question 1 - - Open ``permissions.p7s`` in a text editor. - Make a negligible change to the XML content (e.g., add a space or a blank line) and save the file. - Launch the listener node: - - .. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener - - What do you expect to happen? - - Can you launch the talker node? - - .. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker - - What is the difference between launching the listener and launching the talker? - - .. group-tab:: Answer 1 - - The listener fails to launch and throws an error. - When the ``permissions.p7s`` file was modified--however minor--the file's signature became invalid. - A node will not launch with security enabled and enforced when the permissions file is invalid. - - The talker will start as expected. - It uses the ``permissions.p7s`` file in a different enclave, and the file is still valid. - -.. tabs:: - - .. group-tab:: Question 2 - - What command lets you check to see if the signature on the modified ``permissions.p7s`` file is valid? - - .. group-tab:: Answer 2 - - Check that ``permissions.p7s`` has been properly signed by the Permissions CA using the ``openssl smime`` command: - - .. code-block:: console - - $ openssl smime -verify -in permissions.p7s -CAfile permissions_ca.cert.pem - -Restore your original, properly signed ``permissions.p7s`` file before proceeding to the next tutorial. +.. redirect-from:: + + Tutorials/Security/The-Keystore + Tutorials/Advanced/Security/The-Keystore + +.. _The-Keystore: + +Understanding the security keystore +=================================== + +**Goal:** Explore files located in the ROS 2 security keystore. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- + +Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. + +The ``sros2`` package can be used to create keys, certificates and policies necessary to enable ROS 2 security. +However, the security configuration is extremely flexible. +A basic understanding of the ROS 2 Security Keystore will allow integration with an existing PKI (Public Key Infrastructure) and management of sensitive key materials consistent with organizational policies. + + +Security Artifact Locations +--------------------------- + +With communications security enabled in the prior tutorial, let's take a look at the files which were created when security was enabled. +These are the files which make encryption possible. + +The ``sros2`` utilities (``ros2 security ...``) separate files into public, private and enclave key materials. + +ROS uses the directory defined by the environmental variable ``ROS_SECURITY_KEYSTORE`` as the keystore. +For this tutorial, we use the directory ``~/sros2_demo/demo_keystore``. + + +Public Key Materials +^^^^^^^^^^^^^^^^^^^^ + +You will find three encryption certificates in the public directory at ``~/sros2_demo/demo_keystore/public``; however, the identity and permissions certificates are actually just a link to the Certificate Authority (CA) certificate. + +In a public key infrastructure, the `Certificate Authority `_ acts as a trust anchor: it validates the identities and permissions of participants. +For ROS, that means all the nodes that participate in the ROS graph (which may extend to an entire fleet of individual robots). +By placing the Certificate Authority's certificate (``ca.cert.pem``) in the proper location on the robot, all ROS nodes can establish mutual trust with other nodes using the same Certificate Authority. + +Although in our tutorials we create a Certificate Authority on-the-fly, in a production system this should be done according to a pre-defined security plan. +Typically the Certificate Authority for a production system will be created off-line, and placed on the robot during initial setup. +It may be unique for each robot, or shared across a fleet of robots all intended to trust each other. + +DDS (and ROS, by extension) supports separation of identity and permission trust chains, so each function has its own certificate authority. +In most cases a ROS system security plan does not require a separation between these duties, so the security utilities generate a single Certificate Authority which is used for both identity and permissions. + +Use ``openssl`` to view this x509 certificate and display it as text: + +.. code-block:: console + + $ cd ~/sros2_demo/demo_keystore/public + $ openssl x509 -in ca.cert.pem -text -noout + +The output should look similar to the following:: + + Certificate: + Data: + Version: 3 (0x2) + Serial Number: + 02:8e:9a:24:ea:10:55:cb:e6:ea:e8:7a:c0:5f:58:6d:37:42:78:aa + Signature Algorithm: ecdsa-with-SHA256 + Issuer: CN = sros2CA + Validity + Not Before: Jun 1 16:57:37 2021 GMT + Not After : May 31 16:57:37 2031 GMT + Subject: CN = sros2CA + Subject Public Key Info: + Public Key Algorithm: id-ecPublicKey + Public-Key: (256 bit) + pub: + 04:71:e9:37:d7:32:ba:b8:a0:97:66:da:9f:e3:c4: + 08:4f:7a:13:59:24:c6:cf:6a:f7:95:c5:cd:82:c0: + 7f:7f:e3:90:dd:7b:0f:77:d1:ee:0e:af:68:7c:76: + a9:ca:60:d7:1e:2c:01:d7:bc:7e:e3:86:2a:9f:38: + dc:ed:39:c5:32 + ASN1 OID: prime256v1 + NIST CURVE: P-256 + X509v3 extensions: + X509v3 Basic Constraints: critical + CA:TRUE, pathlen:1 + Signature Algorithm: ecdsa-with-SHA256 + 30:45:02:21:00:d4:fc:d8:45:ff:a4:51:49:98:4c:f0:c4:3f: + e0:e7:33:19:8e:31:3c:d0:43:e7:e9:8f:36:f0:90:18:ed:d7: + 7d:02:20:30:84:f7:04:33:87:bb:4f:d3:8b:95:61:48:df:83: + 4b:e5:92:b3:e6:ee:3c:d5:cf:30:43:09:04:71:bd:dd:7c + +Some things to note about this CA certificate: + - The certificate subject name ``sros2CA`` is the default provided by the ``sros2`` utilities. + - This certificate is valid for ten years from time of creation + - Like all certificates, this contains a public key used for public-private key encryption + - As a Root Certificate Authority, this is a `self-signed certificate `_; i.e., it is signed using its own private key. + +Since this is a public certificate, it can be freely copied as needed to establish trust throughout your ROS system. + + +Private Key Materials +^^^^^^^^^^^^^^^^^^^^^ + +Private key materials can be found in the keystore directory ``~/sros2_demo/demo_keystore/private``. +Similar to the ``public`` directory, this contains one certificate authority key ``ca.key.pem`` and symbolic links to it to be used as both an Identity and a Permissions CA private key. + +.. warning:: + + Protect this private key and create a secure backup of it! + +This is the private key associated with the public Certificate Authority which serves as the anchor for all security in your ROS system. +You will use it to modify encryption policies for the ROS graph and to add new ROS participants. +Depending upon your robot's security needs, the key can be protected with access permissions and locked down to another account, or it can be moved off the robot entirely and onto another system or device. +If the file is lost, you will be unable to change access permissions and add new participants to the system. +Similarly, any user or process with access to the file has the ability to modify system policies and participants. + +This file is only required for configuring the robot, but is not needed for the robot to run. +It can safely be stored offline in another system or removable media. + +The ``sros2`` utilities use `elliptic curve cryptograpy `_ rather than RSA for improved security and reduced key size. +Use the following command to show details about this elliptic curve private key: + + +.. code-block:: console + + $ cd ~/sros2_demo/demo_keystore/private + $ openssl ec -in ca.key.pem -text -noout + read EC key + Private-Key: (256 bit) + priv: + 93:da:76:b9:e3:91:ab:e9:42:76:f2:38:f1:9d:94: + 90:5e:b5:96:7b:7f:71:ee:13:1b:d4:a0:f9:48:fb: + ae:77 + pub: + 04:71:e9:37:d7:32:ba:b8:a0:97:66:da:9f:e3:c4: + 08:4f:7a:13:59:24:c6:cf:6a:f7:95:c5:cd:82:c0: + 7f:7f:e3:90:dd:7b:0f:77:d1:ee:0e:af:68:7c:76: + a9:ca:60:d7:1e:2c:01:d7:bc:7e:e3:86:2a:9f:38: + dc:ed:39:c5:32 + ASN1 OID: prime256v1 + NIST CURVE: P-256 + +In addition to the private key itself, note that the public key is listed, and it matches the public key listed in the Certificate Authority ``ca.cert.pem``. + + +Domain Governance Policy +^^^^^^^^^^^^^^^^^^^^^^^^ + +Find the domain governance policy in the enclave directory within the keystore, ``~/sros2_demo/demo_keystore/enclaves``. +The ``enclave`` directory contains XML governance policy document ``governance.xml``, as well as a copy of the document which has been signed by the Permissions CA as ``governance.p7s``. + +The ``governance.p7s`` file contains domain-wide settings such as how to handle unauthenticated participants, whether to encrypt discovery, and default rules for access to topics. + +Use the following command to validate the `S/MIME signature `_ of the governance file: + +.. code-block:: console + + $ openssl smime -verify -in governance.p7s -CAfile ../public/permissions_ca.cert.pem + +This command will print out the XML document, and the last line will be ``Verification successful`` to show that the document was properly signed by the Permissions CA. + + +Security Enclaves +^^^^^^^^^^^^^^^^^ + +Secure processes (typically ROS nodes) run within a security enclave. +In the simplest case, all the processes can be consolidated into the same enclave, and all processes will then use the same security policy. +However, to apply different policies to different processes, the processes can use different security enclaves when starting. +For more details about security enclaves, see the `design document `_. +The security enclave is specified by using the ROS argument ``--enclave`` when running a node. + +**Each security enclave requires six files** in order to enable security. +Each file **must** be named as defined below, and as outlined in the `DDS Security standard `_. +In order to avoid having multiple copies of the same files, the ``sros2`` utilities create links for each enclave to the single governance policy, the Identity CA and Permissions CA described above. + +See the following six files within the ``listener`` enclave. +Three are specific to this enclave, while three are generic to this ROS system: + + - ``key.pem``, the private key used to encrypt and decrypt within this enclave + - ``cert.pem``, the public certificate for this enclave; this certificate has been signed by the Identity CA + - ``permissions.p7s``, the permissions for this enclave; this file has been signed with the Permissions CA + - ``governance.p7s``, a link to the signed security policy file for this domain + - ``identity_ca.cert.pem``, a link to the Identity CA for this domain + - ``permissions_ca.cert.pem``, a link to the Permissions CA for this domain + +The private encryption key ``key.pem`` should be protected according to your security plan. +This key encrypts, decrypts and validates communications within this specific enclave. +Should the key be lost or stolen, revoke the key and create a new identity for this enclave. + +The file ``permissions.xml`` has also been created in this directory and can be used to recreate the signed permissions file. +However, this file is not required to enable security since DDS uses the signed version of the file instead. + + +Take the quiz! +-------------- + +See if you can answer these questions about the ROS security keystore. +Begin with a new terminal session and enable security with the keystore created in the prior tutorial: + +.. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + + $ cd ~/sros2_demo/demo_keystore/enclaves/talker_listener/listener + +Make a backup copy of ``permissions.p7s`` before beginning. + +.. tabs:: + + .. group-tab:: Question 1 + + Open ``permissions.p7s`` in a text editor. + Make a negligible change to the XML content (e.g., add a space or a blank line) and save the file. + Launch the listener node: + + .. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener + + What do you expect to happen? + + Can you launch the talker node? + + .. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker + + What is the difference between launching the listener and launching the talker? + + .. group-tab:: Answer 1 + + The listener fails to launch and throws an error. + When the ``permissions.p7s`` file was modified--however minor--the file's signature became invalid. + A node will not launch with security enabled and enforced when the permissions file is invalid. + + The talker will start as expected. + It uses the ``permissions.p7s`` file in a different enclave, and the file is still valid. + +.. tabs:: + + .. group-tab:: Question 2 + + What command lets you check to see if the signature on the modified ``permissions.p7s`` file is valid? + + .. group-tab:: Answer 2 + + Check that ``permissions.p7s`` has been properly signed by the Permissions CA using the ``openssl smime`` command: + + .. code-block:: console + + $ openssl smime -verify -in permissions.p7s -CAfile permissions_ca.cert.pem + +Restore your original, properly signed ``permissions.p7s`` file before proceeding to the next tutorial. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Using-Python-Packages.rst b/source/Developer-Tools/Build/Using-Python-Packages.rst index 56d2793f680..1860778fcdd 100644 --- a/source/Developer-Tools/Build/Using-Python-Packages.rst +++ b/source/Developer-Tools/Build/Using-Python-Packages.rst @@ -1,101 +1,102 @@ -.. redirect-from:: - - Guides/Using-Python-Packages - Tutorials/Using-Python-Packages - -.. _PythonPackages: - -Using Python Packages with ROS 2 -================================ - -**Goal:** Explain how to interoperate with other Python packages from the ROS 2 ecosystem. - -.. contents:: Contents - :depth: 2 - :local: - -.. note:: - - A cautionary note, if you intended to use pre-packaged binaries (either ``deb`` files, or the binary archive distributions), the Python interpreter must match what was used to build the original binaries. - If you intend to use something like ``virtualenv`` or ``pipenv``\, make sure to use the system interpreter. - If you use something like ``conda``, it is very likely that the interpreter will not match the system interpreter and will be incompatible with ROS 2 binaries. - -Installing via ``rosdep`` -------------------------- - -The fastest way to include third-party python packages is to use their corresponding rosdep keys, if available. -``rosdep`` keys can be checked via: - -* https://github.com/ros/rosdistro/blob/master/rosdep/base.yaml -* https://github.com/ros/rosdistro/blob/master/rosdep/python.yaml - -These ``rosdep`` keys can be added to your ``package.xml`` file, which indicates to the build system that your package (and dependent packages) depend on those keys. -In a new workspace, you can also quickly install all rosdep keys with: - -.. code-block:: console - - $ rosdep install -yr --from-paths ./path/to/your/workspace - -If there aren't currently ``rosdep`` keys for the package that you are interested in, it is possible to add them by following the `rosdep key contribution guide`_. - -To learn more about the ``rosdep`` tool and how it works, consult the `rosdep documentation`_. - -Installing via a package manager --------------------------------- - -If you don't want to make a rosdep key, but the package is available in your system package manager (eg ``apt``), you can install and use the package that way: - -.. code-block:: console - - $ sudo apt install python3-serial - -If the package is available on `The Python Package Index (PyPI) `_ and you want to install globally on your system: - -.. code-block:: console - - $ python3 -m pip install -U pyserial - -If the package is available on PyPI and you want to install locally to your user: - -.. code-block:: console - - $ python3 -m pip install -U --user pyserial - -Installing via a virtual environment ------------------------------------- - -First, create a Colcon workspace: - -.. code-block:: console - - $ mkdir -p ~/colcon_venv/src - $ cd ~/colcon_venv/ - -Then setup your virtual environment: - -.. code-block:: console - - $ virtualenv -p python3 ./venv # Make a virtual env and activate it - $ source ./venv/bin/activate - $ touch ./venv/COLCON_IGNORE # Make sure that colcon does not try to build the venv - -Next, install the Python packages that you want in your virtual environment: - -.. code-block:: console - - $ python3 -m pip install gtsam pyserial… etc - -Now you can build your workspace and run your python node that depends on packages installed in your virtual environment. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash # Source {DISTRO_TITLE} and build - $ colcon build - -.. note:: - - If you want to release your package using Bloom, you should add the packages you require to ``rosdep``, see the `rosdep key contribution guide`_. - -.. _rosdep key contribution guide: http://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html - -.. _rosdep documentation: http://docs.ros.org/en/independent/api/rosdep/html/ +.. redirect-from:: + + Guides/Using-Python-Packages + Tutorials/Using-Python-Packages + How-To-Guides/Using-Python-Packages + +.. _PythonPackages: + +Using Python Packages with ROS 2 +================================ + +**Goal:** Explain how to interoperate with other Python packages from the ROS 2 ecosystem. + +.. contents:: Contents + :depth: 2 + :local: + +.. note:: + + A cautionary note, if you intended to use pre-packaged binaries (either ``deb`` files, or the binary archive distributions), the Python interpreter must match what was used to build the original binaries. + If you intend to use something like ``virtualenv`` or ``pipenv``\, make sure to use the system interpreter. + If you use something like ``conda``, it is very likely that the interpreter will not match the system interpreter and will be incompatible with ROS 2 binaries. + +Installing via ``rosdep`` +------------------------- + +The fastest way to include third-party python packages is to use their corresponding rosdep keys, if available. +``rosdep`` keys can be checked via: + +* https://github.com/ros/rosdistro/blob/master/rosdep/base.yaml +* https://github.com/ros/rosdistro/blob/master/rosdep/python.yaml + +These ``rosdep`` keys can be added to your ``package.xml`` file, which indicates to the build system that your package (and dependent packages) depend on those keys. +In a new workspace, you can also quickly install all rosdep keys with: + +.. code-block:: console + + $ rosdep install -yr --from-paths ./path/to/your/workspace + +If there aren't currently ``rosdep`` keys for the package that you are interested in, it is possible to add them by following the `rosdep key contribution guide`_. + +To learn more about the ``rosdep`` tool and how it works, consult the `rosdep documentation`_. + +Installing via a package manager +-------------------------------- + +If you don't want to make a rosdep key, but the package is available in your system package manager (eg ``apt``), you can install and use the package that way: + +.. code-block:: console + + $ sudo apt install python3-serial + +If the package is available on `The Python Package Index (PyPI) `_ and you want to install globally on your system: + +.. code-block:: console + + $ python3 -m pip install -U pyserial + +If the package is available on PyPI and you want to install locally to your user: + +.. code-block:: console + + $ python3 -m pip install -U --user pyserial + +Installing via a virtual environment +------------------------------------ + +First, create a Colcon workspace: + +.. code-block:: console + + $ mkdir -p ~/colcon_venv/src + $ cd ~/colcon_venv/ + +Then setup your virtual environment: + +.. code-block:: console + + $ virtualenv -p python3 ./venv # Make a virtual env and activate it + $ source ./venv/bin/activate + $ touch ./venv/COLCON_IGNORE # Make sure that colcon does not try to build the venv + +Next, install the Python packages that you want in your virtual environment: + +.. code-block:: console + + $ python3 -m pip install gtsam pyserial… etc + +Now you can build your workspace and run your python node that depends on packages installed in your virtual environment. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash # Source {DISTRO_TITLE} and build + $ colcon build + +.. note:: + + If you want to release your package using Bloom, you should add the packages you require to ``rosdep``, see the `rosdep key contribution guide`_. + +.. _rosdep key contribution guide: http://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html + +.. _rosdep documentation: http://docs.ros.org/en/independent/api/rosdep/html/ \ No newline at end of file diff --git a/source/Developer-Tools/Build/Using-Variants.rst b/source/Developer-Tools/Build/Using-Variants.rst index bda4db07e9c..01497bd5622 100644 --- a/source/Developer-Tools/Build/Using-Variants.rst +++ b/source/Developer-Tools/Build/Using-Variants.rst @@ -1,68 +1,72 @@ -Using variants -============== - -Metapackages do not provide software directly but depend on a group of other related packages to provide a convenient installation mechanism for the complete group of packages. -[#]_ [#]_ -Variants are a list of official metapackages for commonly useful groups of ROS packages. - -.. [#] https://wiki.debian.org/metapackage -.. [#] https://help.ubuntu.com/community/MetaPackages - -The different variants in ROS 2 are specified in `REP-2001 `_. - -In addition to the official variants, there may be metapackages for specific institutions or robots as described in `REP-108 `_. - -Adding variants ---------------- - -Additional variants that are of general use to the ROS community can be proposed by contributing an update to `REP-2001 via pull request `_ describing the packages included in the new variant. -Institution and robot specific variants can be published directly by their respective maintainers and no update to REP-2001 is required. - -Creating project-specific variants ----------------------------------- - -If you are creating ROS packages to use privately in your own projects, you can create variants specific to your projects using the official variants as examples. -To do so you need only create two files: - -#. A minimal variant package is created as a package with the ``ament_cmake`` build type, a ``buildtool_depend`` on ``ament_cmake`` and ``exec_depend`` entries for each package you want to include in the variant. - - .. code-block:: xml - - - - - my_project_variant - 1.0.0 - A package to aggregate all packages in my_project. - Maintainer Name - Apache-2.0 - - my_project_msgs - my_project_services - my_project_examples - - - ament_cmake - - - -#. A minimal ament_cmake package includes a ``CMakeLists.txt`` which registers the package.xml as an ament package for use in ROS 2. - - .. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - - project(my_project_variant NONE) - find_package(ament_cmake REQUIRED) - ament_package() - -You can then build and install your variant package alongside your other private packages. - -Creating custom variants with platform-specific tools -***************************************************** - -Some platforms have tools for creating basic packages that do not require a full ROS build farm environment or equivalent infrastructure. -It is possible to use these tools to create platform-dependent variants. -This approach does not include support for ROS packaging tools and is platform dependent but requires much less infrastructure to produce if you are creating collections of existing packages rather than a mix of public and private ROS packages. -For example, on Debian or Ubuntu systems you can use the ``equivs`` utilities. -The Debian Administrator's handbook has a `Section on meta-packages `_. +.. redirect-from:: + + How-To-Guides/Using-Variants + +Using variants +============== + +Metapackages do not provide software directly but depend on a group of other related packages to provide a convenient installation mechanism for the complete group of packages. +[#]_ [#]_ +Variants are a list of official metapackages for commonly useful groups of ROS packages. + +.. [#] https://wiki.debian.org/metapackage +.. [#] https://help.ubuntu.com/community/MetaPackages + +The different variants in ROS 2 are specified in `REP-2001 `_. + +In addition to the official variants, there may be metapackages for specific institutions or robots as described in `REP-108 `_. + +Adding variants +--------------- + +Additional variants that are of general use to the ROS community can be proposed by contributing an update to `REP-2001 via pull request `_ describing the packages included in the new variant. +Institution and robot specific variants can be published directly by their respective maintainers and no update to REP-2001 is required. + +Creating project-specific variants +---------------------------------- + +If you are creating ROS packages to use privately in your own projects, you can create variants specific to your projects using the official variants as examples. +To do so you need only create two files: + +#. A minimal variant package is created as a package with the ``ament_cmake`` build type, a ``buildtool_depend`` on ``ament_cmake`` and ``exec_depend`` entries for each package you want to include in the variant. + + .. code-block:: xml + + + + + my_project_variant + 1.0.0 + A package to aggregate all packages in my_project. + Maintainer Name + Apache-2.0 + + my_project_msgs + my_project_services + my_project_examples + + + ament_cmake + + + +#. A minimal ament_cmake package includes a ``CMakeLists.txt`` which registers the package.xml as an ament package for use in ROS 2. + + .. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + + project(my_project_variant NONE) + find_package(ament_cmake REQUIRED) + ament_package() + +You can then build and install your variant package alongside your other private packages. + +Creating custom variants with platform-specific tools +***************************************************** + +Some platforms have tools for creating basic packages that do not require a full ROS build farm environment or equivalent infrastructure. +It is possible to use these tools to create platform-dependent variants. +This approach does not include support for ROS packaging tools and is platform dependent but requires much less infrastructure to produce if you are creating collections of existing packages rather than a mix of public and private ROS packages. +For example, on Debian or Ubuntu systems you can use the ``equivs`` utilities. +The Debian Administrator's handbook has a `Section on meta-packages `_. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File.rst b/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File.rst index 8d22b025085..e5a5b59b6de 100644 --- a/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File.rst +++ b/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File.rst @@ -1,284 +1,285 @@ -.. redirect-from:: - - Tutorials/URDF/Using-Xacro-to-Clean-Up-a-URDF-File - -.. _URDFXacro: - -Using Xacro to clean up your code -================================= - -**Goal:** Learn some tricks to reduce the amount of code in a URDF file using Xacro - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -By now, if you're following all these steps at home with your own robot design, you might be sick of doing all sorts of math to get very simple robot descriptions to parse correctly. -Fortunately, you can use the `xacro `_ package to make your life simpler. -It does three things that are very helpful. - - * Constants - * Simple Math - * Macros - -In this tutorial, we take a look at all these shortcuts to help reduce the overall size of the URDF file and make it easier to read and maintain. - -Using Xacro ------------ -As its name implies, `xacro `_ is a macro language for XML. -The xacro program runs all of the macros and outputs the result. -Typical usage looks something like this: - -.. code-block:: console - - $ xacro model.xacro > model.urdf - -You can also automatically generate the urdf in a launch file. -This is convenient because it stays up to date and doesn't use up hard drive space. -However, it does take time to generate, so be aware that your launch file might take longer to start up. - -To run xacro within your launch file, you need to put the ``Command`` substitution as a parameter to the ``robot_state_publisher``. - -.. code-block:: python - - path_to_urdf = get_package_share_path('turtlebot3_description') / 'urdf' / 'turtlebot3_burger.urdf' - robot_state_publisher_node = launch_ros.actions.Node( - package='robot_state_publisher', - executable='robot_state_publisher', - parameters=[{ - 'robot_description': ParameterValue( - Command(['xacro ', str(path_to_urdf)]), value_type=str - ) - }] - ) - -An easier way to load the robot model is to use the `urdf_launch `_ package to automatically load the xacro/urdf. - -.. literalinclude:: launch/urdf_display_launch.py - :language: python - -At the top of the URDF file, you must specify a namespace in order for the file to parse properly. -For example, these are the first two lines of a valid xacro file: - -.. code-block:: xml - - - - -Constants ---------- -Let's take a quick look at our base_link in R2D2. - -.. code-block:: xml - - - - - - - - - - - - - - - -The information here is a little redundant. -We specify the length and radius of the cylinder twice. -Worse, if we want to change that, we need to do so in two different places. - -Fortunately, xacro allows you to specify properties which act as constants. -Instead, of the above code, we can write this. - -.. code-block:: xml - - - - - - - - - - - - - - - - - -* The two values are specified in the first two lines. - They can be defined just about anywhere (assuming valid XML), at any level, before or after they are used. - Usually they go at the top. -* Instead of specifying the actual radius in the geometry element, we use a dollar sign and curly brackets to signify the value. -* This code will generate the same code shown above. - -The value of the contents of the ${} construct are then used to replace the ${}. -This means you can combine it with other text in the attribute. - -.. code-block:: xml - - - - -This will generate - -.. code-block:: xml - - - -However, the contents in the ${} don't have to only be a property, which brings us to our next point... - -Math ----- -You can build up arbitrarily complex expressions in the ${} construct using the four basic operations (+,-,*,/), the unary minus, and parenthesis. -Examples: - -.. code-block:: xml - - - - -You can also use more than the basic mathematical operations, like ``sin`` and ``cos``. - -Macros ------- -Here's the biggest and most useful component to the xacro package. - -Simple Macro -^^^^^^^^^^^^ -Let's take a look at a simple useless macro. - -.. code-block:: xml - - - - - - -(This is useless, since if the origin is not specified, it has the same value as this.) -This code will generate the following. - -.. code-block:: xml - - - -* The name is not technically a required element, but you need to specify it to be able to use it. -* Every instance of the ```` is replaced with the contents of the ``xacro:macro`` tag. -* Note that even though its not exactly the same (the two attributes have switched order), the generated XML is equivalent. -* If the xacro with a specified name is not found, it will not be expanded and will NOT generate an error. - -Parameterized Macro -^^^^^^^^^^^^^^^^^^^ -You can also parameterize macros so that they don't generate the same exact text every time. -When combined with the math functionality, this is even more powerful. - -First, let's take an example of a simple macro used in R2D2. - -.. code-block:: xml - - - - - - - - -This can be used with the code - -.. code-block:: xml - - - -The parameters act just like properties, and you can use them in expressions - -You can also use entire blocks as parameters too. - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - -* To specify a block parameter, include an asterisk before its parameter name. -* A block can be inserted using the insert_block command -* Insert the block as many times as you wish. - -Practical Usage ---------------- -The xacro language is rather flexible in what it allows you to do. -Here are a few useful ways that xacro is used in the `R2D2 model `_, in addition to the default inertial macro shown above. - -To see the model generated by a xacro file, run the same command as with previous tutorials: - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/08-macroed.urdf.xacro - -(The launch file has been running the xacro command this whole time, but since there were no macros to expand, it didn't matter) - -Leg macro -^^^^^^^^^ -Often you want to create multiple similar looking objects in different locations. -You can use a macro and some simple math to reduce the amount of code you have to write, like we do with R2's two legs. - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* Common Trick 1: Use a name prefix to get two similarly named objects. -* Common Trick 2: Use math to calculate joint origins. - In the case that you change the size of your robot, changing a property with some math to calculate the joint offset will save a lot of trouble. -* Common Trick 3: Using a reflect parameter, and setting it to 1 or -1. - See how we use the reflect parameter to put the legs on either side of the body in the base_to_${prefix}_leg origin. +.. redirect-from:: + + Tutorials/URDF/Using-Xacro-to-Clean-Up-a-URDF-File + Tutorials/Intermediate/URDF/Using-Xacro-to-Clean-Up-a-URDF-File + +.. _URDFXacro: + +Using Xacro to clean up your code +================================= + +**Goal:** Learn some tricks to reduce the amount of code in a URDF file using Xacro + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +By now, if you're following all these steps at home with your own robot design, you might be sick of doing all sorts of math to get very simple robot descriptions to parse correctly. +Fortunately, you can use the `xacro `_ package to make your life simpler. +It does three things that are very helpful. + + * Constants + * Simple Math + * Macros + +In this tutorial, we take a look at all these shortcuts to help reduce the overall size of the URDF file and make it easier to read and maintain. + +Using Xacro +----------- +As its name implies, `xacro `_ is a macro language for XML. +The xacro program runs all of the macros and outputs the result. +Typical usage looks something like this: + +.. code-block:: console + + $ xacro model.xacro > model.urdf + +You can also automatically generate the urdf in a launch file. +This is convenient because it stays up to date and doesn't use up hard drive space. +However, it does take time to generate, so be aware that your launch file might take longer to start up. + +To run xacro within your launch file, you need to put the ``Command`` substitution as a parameter to the ``robot_state_publisher``. + +.. code-block:: python + + path_to_urdf = get_package_share_path('turtlebot3_description') / 'urdf' / 'turtlebot3_burger.urdf' + robot_state_publisher_node = launch_ros.actions.Node( + package='robot_state_publisher', + executable='robot_state_publisher', + parameters=[{ + 'robot_description': ParameterValue( + Command(['xacro ', str(path_to_urdf)]), value_type=str + ) + }] + ) + +An easier way to load the robot model is to use the `urdf_launch `_ package to automatically load the xacro/urdf. + +.. literalinclude:: launch/urdf_display_launch.py + :language: python + +At the top of the URDF file, you must specify a namespace in order for the file to parse properly. +For example, these are the first two lines of a valid xacro file: + +.. code-block:: xml + + + + +Constants +--------- +Let's take a quick look at our base_link in R2D2. + +.. code-block:: xml + + + + + + + + + + + + + + + +The information here is a little redundant. +We specify the length and radius of the cylinder twice. +Worse, if we want to change that, we need to do so in two different places. + +Fortunately, xacro allows you to specify properties which act as constants. +Instead, of the above code, we can write this. + +.. code-block:: xml + + + + + + + + + + + + + + + + + +* The two values are specified in the first two lines. + They can be defined just about anywhere (assuming valid XML), at any level, before or after they are used. + Usually they go at the top. +* Instead of specifying the actual radius in the geometry element, we use a dollar sign and curly brackets to signify the value. +* This code will generate the same code shown above. + +The value of the contents of the ${} construct are then used to replace the ${}. +This means you can combine it with other text in the attribute. + +.. code-block:: xml + + + + +This will generate + +.. code-block:: xml + + + +However, the contents in the ${} don't have to only be a property, which brings us to our next point... + +Math +---- +You can build up arbitrarily complex expressions in the ${} construct using the four basic operations (+,-,*,/), the unary minus, and parenthesis. +Examples: + +.. code-block:: xml + + + + +You can also use more than the basic mathematical operations, like ``sin`` and ``cos``. + +Macros +------ +Here's the biggest and most useful component to the xacro package. + +Simple Macro +^^^^^^^^^^^^ +Let's take a look at a simple useless macro. + +.. code-block:: xml + + + + + + +(This is useless, since if the origin is not specified, it has the same value as this.) +This code will generate the following. + +.. code-block:: xml + + + +* The name is not technically a required element, but you need to specify it to be able to use it. +* Every instance of the ```` is replaced with the contents of the ``xacro:macro`` tag. +* Note that even though its not exactly the same (the two attributes have switched order), the generated XML is equivalent. +* If the xacro with a specified name is not found, it will not be expanded and will NOT generate an error. + +Parameterized Macro +^^^^^^^^^^^^^^^^^^^ +You can also parameterize macros so that they don't generate the same exact text every time. +When combined with the math functionality, this is even more powerful. + +First, let's take an example of a simple macro used in R2D2. + +.. code-block:: xml + + + + + + + + +This can be used with the code + +.. code-block:: xml + + + +The parameters act just like properties, and you can use them in expressions + +You can also use entire blocks as parameters too. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + +* To specify a block parameter, include an asterisk before its parameter name. +* A block can be inserted using the insert_block command +* Insert the block as many times as you wish. + +Practical Usage +--------------- +The xacro language is rather flexible in what it allows you to do. +Here are a few useful ways that xacro is used in the `R2D2 model `_, in addition to the default inertial macro shown above. + +To see the model generated by a xacro file, run the same command as with previous tutorials: + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/08-macroed.urdf.xacro + +(The launch file has been running the xacro command this whole time, but since there were no macros to expand, it didn't matter) + +Leg macro +^^^^^^^^^ +Often you want to create multiple similar looking objects in different locations. +You can use a macro and some simple math to reduce the amount of code you have to write, like we do with R2's two legs. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +* Common Trick 1: Use a name prefix to get two similarly named objects. +* Common Trick 2: Use math to calculate joint origins. + In the case that you change the size of your robot, changing a property with some math to calculate the joint offset will save a lot of trouble. +* Common Trick 3: Using a reflect parameter, and setting it to 1 or -1. + See how we use the reflect parameter to put the legs on either side of the body in the base_to_${prefix}_leg origin. \ No newline at end of file diff --git a/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst b/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst index 988e1486e06..7709c6608f5 100644 --- a/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst +++ b/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst @@ -1,102 +1,103 @@ -.. redirect-from:: - - How-To-Guides/Building-ROS-2-with-Tracing-Instrumentation - -Building ROS 2 with tracing -=========================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Tracing instrumentation is included in the ROS 2 source code, and Linux installations of ROS 2 include the LTTng tracer as a dependency. -Therefore, ROS 2 can be traced out-of-the-box on Linux. - -However, ROS 2 can be built from source to remove the tracepoints or completely remove the instrumentation. -This guide shows how to do that. -For more information, see `the repository `__. - -.. note:: - - This guide only applies to Linux systems. - -Prerequisites -------------- - -Set up your system to build ROS 2 from source. -See :doc:`the source installation page <../Installation/Alternatives/Ubuntu-Development-Setup>` for more information. - -Build configurations --------------------- - -The ROS 2 tracing instrumentation is split into two components: function instrumentation and tracepoints. -First, a ROS 2 core package (e.g., ``rclcpp``) calls a function provided by the ``tracetools`` package. -Then, that function triggers a tracepoint, which records data if the tracepoint is enabled at runtime. - -By default, if the tracer is not `configured to trace or if the tracepoints are not enabled `__, they will have virtually no impact on the execution. -However, the tracepoints can still be removed through a CMake option. -Furthermore, the functions can be completely removed through a CMake option, which implies that tracepoints are also removed. - -Building without tracepoints -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This step depends on whether you are :doc:`building ROS 2 from source <../Installation/Alternatives/Ubuntu-Development-Setup>` or using ROS 2 binaries (:doc:`deb packages <../Installation/Ubuntu-Install-Debs>` or :doc:`binary archive <../Installation/Alternatives/Ubuntu-Install-Binary>`). -To remove the tracepoints, (re)build ``tracetools`` and set the ``TRACETOOLS_TRACEPOINTS_EXCLUDED`` CMake option to ``ON``: - -.. tabs:: - - .. group-tab:: Source installation - - .. code-block:: console - - $ cd ~/ros2_{DISTRO} - $ colcon build --packages-select tracetools --cmake-clean-cache --cmake-args -DTRACETOOLS_TRACEPOINTS_EXCLUDED=ON - - .. group-tab:: Binary installation - - Clone the ``ros2_tracing`` repository into your workspace and build: - - .. code-block:: console - - $ cd ~/ws - $ git clone https://github.com/ros2/ros2_tracing.git -b {DISTRO} src/ros2_tracing - $ colcon build --packages-select tracetools --cmake-args -DTRACETOOLS_TRACEPOINTS_EXCLUDED=ON - -Building without instrumentation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To completely remove both tracepoints and function calls, :doc:`build ROS 2 from source <../Installation/Alternatives/Ubuntu-Development-Setup>` and set the ``TRACETOOLS_DISABLED`` CMake option to ``ON``: - -.. code-block:: console - - $ cd ~/ros2_{DISTRO} - $ colcon build --cmake-args -DTRACETOOLS_DISABLED=ON --no-warn-unused-cli - -Validating ----------- - -Validate that tracing is disabled: - -.. code-block:: console - - $ cd ~/ws - $ source install/setup.bash - $ ros2 run tracetools status - -It should print out: - -.. tabs:: - - .. group-tab:: Without tracepoints - - .. code-block:: bash - - Tracing disabled - - .. group-tab:: Without instrumentation - - .. code-block:: bash - - Tracing disabled through configuration - -If something else is printed, then something went wrong. +.. redirect-from:: + + How-To-Guides/Building-ROS-2-with-Tracing-Instrumentation + How-To-Guides/Building-ROS-2-with-Tracing + +Building ROS 2 with tracing +=========================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Tracing instrumentation is included in the ROS 2 source code, and Linux installations of ROS 2 include the LTTng tracer as a dependency. +Therefore, ROS 2 can be traced out-of-the-box on Linux. + +However, ROS 2 can be built from source to remove the tracepoints or completely remove the instrumentation. +This guide shows how to do that. +For more information, see `the repository `__. + +.. note:: + + This guide only applies to Linux systems. + +Prerequisites +------------- + +Set up your system to build ROS 2 from source. +See :doc:`the source installation page <../../Get-Started/Installation/Alternatives/Ubuntu-Development-Setup>` for more information. + +Build configurations +-------------------- + +The ROS 2 tracing instrumentation is split into two components: function instrumentation and tracepoints. +First, a ROS 2 core package (e.g., ``rclcpp``) calls a function provided by the ``tracetools`` package. +Then, that function triggers a tracepoint, which records data if the tracepoint is enabled at runtime. + +By default, if the tracer is not `configured to trace or if the tracepoints are not enabled `__, they will have virtually no impact on the execution. +However, the tracepoints can still be removed through a CMake option. +Furthermore, the functions can be completely removed through a CMake option, which implies that tracepoints are also removed. + +Building without tracepoints +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This step depends on whether you are :doc:`building ROS 2 from source <../../Get-Started/Installation/Alternatives/Ubuntu-Development-Setup>` or using ROS 2 binaries (:doc:`deb packages <../../Get-Started/Installation/Ubuntu-Install-Debs>` or :doc:`binary archive <../../Get-Started/Installation/Alternatives/Ubuntu-Install-Binary>`). +To remove the tracepoints, (re)build ``tracetools`` and set the ``TRACETOOLS_TRACEPOINTS_EXCLUDED`` CMake option to ``ON``: + +.. tabs:: + + .. group-tab:: Source installation + + .. code-block:: console + + $ cd ~/ros2_{DISTRO} + $ colcon build --packages-select tracetools --cmake-clean-cache --cmake-args -DTRACETOOLS_TRACEPOINTS_EXCLUDED=ON + + .. group-tab:: Binary installation + + Clone the ``ros2_tracing`` repository into your workspace and build: + + .. code-block:: console + + $ cd ~/ws + $ git clone https://github.com/ros2/ros2_tracing.git -b {DISTRO} src/ros2_tracing + $ colcon build --packages-select tracetools --cmake-args -DTRACETOOLS_TRACEPOINTS_EXCLUDED=ON + +Building without instrumentation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To completely remove both tracepoints and function calls, :doc:`build ROS 2 from source <../../Get-Started/Installation/Alternatives/Ubuntu-Development-Setup>` and set the ``TRACETOOLS_DISABLED`` CMake option to ``ON``: + +.. code-block:: console + + $ cd ~/ros2_{DISTRO} + $ colcon build --cmake-args -DTRACETOOLS_DISABLED=ON --no-warn-unused-cli + +Validating +---------- + +Validate that tracing is disabled: + +.. code-block:: console + + $ cd ~/ws + $ source install/setup.bash + $ ros2 run tracetools status + +It should print out: + +.. tabs:: + + .. group-tab:: Without tracepoints + + .. code-block:: bash + + Tracing disabled + + .. group-tab:: Without instrumentation + + .. code-block:: bash + + Tracing disabled through configuration + +If something else is printed, then something went wrong. \ No newline at end of file diff --git a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst index 8c33936f203..0905580285f 100644 --- a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst +++ b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst @@ -1,318 +1,319 @@ -.. redirect-from:: - - Tutorials/Tf2/Debugging-Tf2-Problems - -.. _DebuggingTf2Problems: - -Debugging -========= - -**Goal:** Learn how to use a systematic approach for debugging tf2 related problems. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -This tutorial walks you through the steps to debug a typical tf2 problem. -It will also use many of the tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames``. -This tutorial assumes you have completed the :doc:`learning tf2 <./Tf2-Main>` tutorials. - -Debugging example ------------------ - -1 Setting and starting the example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For this tutorial we will set up a demo application that has a number of problems. -The goal of this tutorial is to apply a systematic approach to find and tackle these problems. -First, let's create the source file. - -Go to the ``learning_tf2_cpp`` package we created in :doc:`tf2 tutorials <./Tf2-Main>`. -Inside the ``src`` directory make a copy of the source file ``turtle_tf2_listener.cpp`` and rename it to ``turtle_tf2_listener_debug.cpp``. - -Open the file using your preferred text editor, and change line 65 from - -.. code-block:: C++ - - std::string toFrameRel = "turtle2"; - -to - -.. code-block:: C++ - - std::string toFrameRel = "turtle3"; - -and change ``lookupTransform()`` call in lines 73-77 from - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePointZero); - } catch (const tf2::TransformException & ex) { - -to - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - this->now()); - } catch (const tf2::TransformException & ex) { - -And save changes to the file. -In order to run this demo, we need to create a launch file ``start_tf2_debug_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` subdirectory of package ``learning_tf2_cpp``: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/start_tf2_debug_demo_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/start_tf2_debug_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/start_tf2_debug_demo_launch.yaml - :language: yaml - -Don't forget to add the ``turtle_tf2_listener_debug`` executable to the ``CMakeLists.txt`` and build the package. - -Now let's run it to see what happens: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.py - -You will now see that the turtlesim came up. -At the same time, if you run the ``turtle_teleop_key`` in another terminal window, you can use the arrow keys to drive the ``turtle1`` around. - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - [turtle_tf2_listener_debug-4] [INFO] [1630223454.942322623] [listener_debug]: Could not - transform turtle3 to turtle1: "turtle3" passed to lookupTransform argument target_frame - does not exist - -You will also notice that there is a second turtle in the lower, left corner. -If the demo would be working correctly, this second turtle should be following the turtle you can command with the arrow keys. -However, it is not the case because we have to solve some problems first. - -2 Finding the tf2 request -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Firstly, we need to find out what exactly we are asking tf2 to do. -Therefore, we go into the part of the code that is using tf2. -Open the ``src/turtle_tf2_listener_debug.cpp`` file, and take a look at line 65: - -.. code-block:: C++ - - std::string toFrameRel = "turtle3"; - -and lines 73-77: - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - this->now()); - } catch (const tf2::TransformException & ex) { - -Here we do the actual request to tf2. -The three arguments tell us directly what we are asking tf2: transform from frame ``turtle3`` to frame ``turtle1`` at time ``now``. - -Now, let's take a look at why this request to tf2 is failing. - -3 Checking the frames -^^^^^^^^^^^^^^^^^^^^^ - -Firstly, to find out if tf2 knows about our transform between ``turtle3`` and ``turtle1``, we will use ``tf2_echo`` tool. - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo turtle3 turtle1 - [INFO] [1630223557.477636052] [tf2_echo]: Waiting for transform turtle3 -> turtle1: - Invalid frame ID "turtle3" passed to canTransform argument target_frame - frame does - not exist - -The output tells us that frame ``turtle3`` does not exist. - -Then what frames do exist? -If you like to get a graphical representation of this, use ``view_frames`` tool. - -.. code-block:: console - - $ ros2 run tf2_tools view_frames - -Open the generated ``frames.pdf`` file to see the following output: - -.. image:: images/turtlesim_frames.png - -So obviously the problem is that we are requesting transform from frame ``turtle3``, which does not exist. -To fix this bug, just replace ``turtle3`` with ``turtle2`` in line 65. - -And now stop the running demo, build it, and run it again: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.xml - [turtle_tf2_listener_debug-4] [INFO] [1630223704.617382464] [listener_debug]: Could not - transform turtle2 to turtle1: Lookup would require extrapolation into the future. Requested - time 1630223704.617054 but the latest data is at time 1630223704.616726, when looking up - transform from frame [turtle1] to frame [turtle2] - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.yaml - [turtle_tf2_listener_debug-4] [INFO] [1630223704.617382464] [listener_debug]: Could not - transform turtle2 to turtle1: Lookup would require extrapolation into the future. Requested - time 1630223704.617054 but the latest data is at time 1630223704.616726, when looking up - transform from frame [turtle1] to frame [turtle2] - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.py - [turtle_tf2_listener_debug-4] [INFO] [1630223704.617382464] [listener_debug]: Could not - transform turtle2 to turtle1: Lookup would require extrapolation into the future. Requested - time 1630223704.617054 but the latest data is at time 1630223704.616726, when looking up - transform from frame [turtle1] to frame [turtle2] - -And right away we run into the next problem. - -4 Checking the timestamp -^^^^^^^^^^^^^^^^^^^^^^^^ - -Now that we solved the frame name problem, it is time to look at the timestamps. -Remember, we are trying to get the transform between ``turtle2`` and ``turtle1`` at the current time (i.e., ``now``). -To get statistics on the timing, call ``tf2_monitor`` with corresponding frames. - -.. code-block:: console - - $ ros2 run tf2_ros tf2_monitor turtle2 turtle1 - RESULTS: for turtle2 to turtle1 - Chain is: turtle1 - Net delay avg = 0.00287347: max = 0.0167241 - - Frames: - Frame: turtle1, published by , Average Delay: 0.000295833, Max Delay: 0.000755072 - - All Broadcasters: - Node: 125.246 Hz, Average Delay: 0.000290237 Max Delay: 0.000786781 - -The key part here is the delay for the chain from ``turtle2`` to ``turtle1``. -The output shows there is an average delay of about 3 milliseconds. -This means that tf2 can only transform between the turtles after 3 milliseconds are passed. -So, if we would be asking tf2 for the transformation between the turtles 3 milliseconds ago instead of ``now``, tf2 would be able to give us an answer sometimes. -Let's test this quickly by changing lines 73-77 to: - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - this->now() - rclcpp::Duration::from_seconds(0.1)); - } catch (const tf2::TransformException & ex) { - -In the new code we are asking for the transform between the turtles 100 milliseconds ago. -It is usual to use a longer periods, just to make sure that the transform will arrive. -Stop the demo, build and run: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.py - -And you should finally see the turtle move! - -.. image:: images/turtlesim_follow1.png - -That last fix we made is not really what you want to do, it was just to make sure that was our problem. -The real fix would look like this: - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePointZero); - } catch (const tf2::TransformException & ex) { - -Or like this: - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePoint()); - } catch (const tf2::TransformException & ex) { - -You can learn more about timeouts in the :doc:`Using time <./Learning-About-Tf2-And-Time-Cpp>` tutorial, and use them as below: - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - this->now(), - rclcpp::Duration::from_seconds(0.05)); - } catch (const tf2::TransformException & ex) { - -Summary -------- - -In this tutorial you learned how to use a systematic approach for debugging tf2 related problems. -You also learned how to use tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames`` to help you debug those tf2 problems. +.. redirect-from:: + + Tutorials/Tf2/Debugging-Tf2-Problems + Tutorials/Intermediate/Tf2/Debugging-Tf2-Problems + +.. _DebuggingTf2Problems: + +Debugging +========= + +**Goal:** Learn how to use a systematic approach for debugging tf2 related problems. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +This tutorial walks you through the steps to debug a typical tf2 problem. +It will also use many of the tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames``. +This tutorial assumes you have completed the :doc:`learning tf2 <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` tutorials. + +Debugging example +----------------- + +1 Setting and starting the example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For this tutorial we will set up a demo application that has a number of problems. +The goal of this tutorial is to apply a systematic approach to find and tackle these problems. +First, let's create the source file. + +Go to the ``learning_tf2_cpp`` package we created in :doc:`tf2 tutorials <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>`. +Inside the ``src`` directory make a copy of the source file ``turtle_tf2_listener.cpp`` and rename it to ``turtle_tf2_listener_debug.cpp``. + +Open the file using your preferred text editor, and change line 65 from + +.. code-block:: C++ + + std::string toFrameRel = "turtle2"; + +to + +.. code-block:: C++ + + std::string toFrameRel = "turtle3"; + +and change ``lookupTransform()`` call in lines 73-77 from + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePointZero); + } catch (const tf2::TransformException & ex) { + +to + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + this->now()); + } catch (const tf2::TransformException & ex) { + +And save changes to the file. +In order to run this demo, we need to create a launch file ``start_tf2_debug_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` subdirectory of package ``learning_tf2_cpp``: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/start_tf2_debug_demo_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/start_tf2_debug_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/start_tf2_debug_demo_launch.yaml + :language: yaml + +Don't forget to add the ``turtle_tf2_listener_debug`` executable to the ``CMakeLists.txt`` and build the package. + +Now let's run it to see what happens: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.py + +You will now see that the turtlesim came up. +At the same time, if you run the ``turtle_teleop_key`` in another terminal window, you can use the arrow keys to drive the ``turtle1`` around. + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + [turtle_tf2_listener_debug-4] [INFO] [1630223454.942322623] [listener_debug]: Could not + transform turtle3 to turtle1: "turtle3" passed to lookupTransform argument target_frame + does not exist + +You will also notice that there is a second turtle in the lower, left corner. +If the demo would be working correctly, this second turtle should be following the turtle you can command with the arrow keys. +However, it is not the case because we have to solve some problems first. + +2 Finding the tf2 request +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Firstly, we need to find out what exactly we are asking tf2 to do. +Therefore, we go into the part of the code that is using tf2. +Open the ``src/turtle_tf2_listener_debug.cpp`` file, and take a look at line 65: + +.. code-block:: C++ + + std::string toFrameRel = "turtle3"; + +and lines 73-77: + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + this->now()); + } catch (const tf2::TransformException & ex) { + +Here we do the actual request to tf2. +The three arguments tell us directly what we are asking tf2: transform from frame ``turtle3`` to frame ``turtle1`` at time ``now``. + +Now, let's take a look at why this request to tf2 is failing. + +3 Checking the frames +^^^^^^^^^^^^^^^^^^^^^ + +Firstly, to find out if tf2 knows about our transform between ``turtle3`` and ``turtle1``, we will use ``tf2_echo`` tool. + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo turtle3 turtle1 + [INFO] [1630223557.477636052] [tf2_echo]: Waiting for transform turtle3 -> turtle1: + Invalid frame ID "turtle3" passed to canTransform argument target_frame - frame does + not exist + +The output tells us that frame ``turtle3`` does not exist. + +Then what frames do exist? +If you like to get a graphical representation of this, use ``view_frames`` tool. + +.. code-block:: console + + $ ros2 run tf2_tools view_frames + +Open the generated ``frames.pdf`` file to see the following output: + +.. image:: images/turtlesim_frames.png + +So obviously the problem is that we are requesting transform from frame ``turtle3``, which does not exist. +To fix this bug, just replace ``turtle3`` with ``turtle2`` in line 65. + +And now stop the running demo, build it, and run it again: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.xml + [turtle_tf2_listener_debug-4] [INFO] [1630223704.617382464] [listener_debug]: Could not + transform turtle2 to turtle1: Lookup would require extrapolation into the future. Requested + time 1630223704.617054 but the latest data is at time 1630223704.616726, when looking up + transform from frame [turtle1] to frame [turtle2] + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.yaml + [turtle_tf2_listener_debug-4] [INFO] [1630223704.617382464] [listener_debug]: Could not + transform turtle2 to turtle1: Lookup would require extrapolation into the future. Requested + time 1630223704.617054 but the latest data is at time 1630223704.616726, when looking up + transform from frame [turtle1] to frame [turtle2] + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.py + [turtle_tf2_listener_debug-4] [INFO] [1630223704.617382464] [listener_debug]: Could not + transform turtle2 to turtle1: Lookup would require extrapolation into the future. Requested + time 1630223704.617054 but the latest data is at time 1630223704.616726, when looking up + transform from frame [turtle1] to frame [turtle2] + +And right away we run into the next problem. + +4 Checking the timestamp +^^^^^^^^^^^^^^^^^^^^^^^^ + +Now that we solved the frame name problem, it is time to look at the timestamps. +Remember, we are trying to get the transform between ``turtle2`` and ``turtle1`` at the current time (i.e., ``now``). +To get statistics on the timing, call ``tf2_monitor`` with corresponding frames. + +.. code-block:: console + + $ ros2 run tf2_ros tf2_monitor turtle2 turtle1 + RESULTS: for turtle2 to turtle1 + Chain is: turtle1 + Net delay avg = 0.00287347: max = 0.0167241 + + Frames: + Frame: turtle1, published by , Average Delay: 0.000295833, Max Delay: 0.000755072 + + All Broadcasters: + Node: 125.246 Hz, Average Delay: 0.000290237 Max Delay: 0.000786781 + +The key part here is the delay for the chain from ``turtle2`` to ``turtle1``. +The output shows there is an average delay of about 3 milliseconds. +This means that tf2 can only transform between the turtles after 3 milliseconds are passed. +So, if we would be asking tf2 for the transformation between the turtles 3 milliseconds ago instead of ``now``, tf2 would be able to give us an answer sometimes. +Let's test this quickly by changing lines 73-77 to: + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + this->now() - rclcpp::Duration::from_seconds(0.1)); + } catch (const tf2::TransformException & ex) { + +In the new code we are asking for the transform between the turtles 100 milliseconds ago. +It is usual to use a longer periods, just to make sure that the transform will arrive. +Stop the demo, build and run: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp start_tf2_debug_demo_launch.py + +And you should finally see the turtle move! + +.. image:: images/turtlesim_follow1.png + +That last fix we made is not really what you want to do, it was just to make sure that was our problem. +The real fix would look like this: + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePointZero); + } catch (const tf2::TransformException & ex) { + +Or like this: + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePoint()); + } catch (const tf2::TransformException & ex) { + +You can learn more about timeouts in the :doc:`Using time <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp>` tutorial, and use them as below: + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + this->now(), + rclcpp::Duration::from_seconds(0.05)); + } catch (const tf2::TransformException & ex) { + +Summary +------- + +In this tutorial you learned how to use a systematic approach for debugging tf2 related problems. +You also learned how to use tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames`` to help you debug those tf2 problems. \ No newline at end of file diff --git a/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst b/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst index c66f5799d7e..adfe1a01a96 100644 --- a/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst +++ b/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst @@ -1,353 +1,357 @@ -Getting Backtraces in ROS 2 -########################### - -.. contents:: Table of Contents - :local: - -**Goal:** Show various methods for getting backtraces in ROS 2 - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -The following steps show ROS 2 users how to get backtraces when they encounter a problem. - -Overview --------- - -**What is a Backtrace ?** - -- Imagine your program is like a stack of pancakes where each pancake represents a function it's currently executing. - A backtrace is like a photo of the collapsed pancake stack, showing you the order they were in, revealing how the program ended up with the failure. -- It lists out the sequence of functions that were called, one on top of the other, leading up to the point of failure. - -**Why is it Useful?** - -- **Pinpoints the Problem:** Instead of guessing where in your code an error occurred, the backtrace shows you the exact line number responsible for the crash. -- **Reveals Context:** You can see the chain of events (functions calling other functions) that ultimately triggered the failure. - This helps you understand not just where things went wrong, but also why. - -**Visual Analogy**: Stack of Pancakes - -1. Each Pancake is a Function: Imagine each pancake in a stack represents a function that your program is currently executing. - The pancake at the bottom is your main() function, where it all begins. - -2. Adding Pancakes: Every time a function calls another function, a new pancake is placed on top of the stack. - -3. The Crash: A crash is like the plate slipping out from the bottom of the stack – something went disastrously wrong in the function currently executing. - -4. The Backtrace: The backtrace is like a photo of that fallen pancake stack. - It shows the order of pancakes (functions) from top to bottom, revealing how you ended up at the crash site. - - -**Code Example:** - -.. code-block:: cpp - - void functionC() { - // Something bad happens here, causing a crash - } - - void functionB() { - functionC(); - } - - void functionA() { - functionB(); - } - - int main() { - functionA(); - return 0; - } - -**Backtrace from the Crash:** - -.. code-block:: bash - - #0 functionC() at file.cpp:3 // Crash occurred here - #1 functionB() at file.cpp:8 - #2 functionA() at file.cpp:13 - #3 main() at file.cpp:18 - -**How the Backtrace Helps:** - -- **Crash Origin:** Shows you the exact line in ``functionC()`` that triggered the crash. -- **Call Sequence:** Reveals that ``main()`` called ``functionA()``, which called ``functionB()``, which ultimately led to the error in ``functionC()``. - -The above example gave us a clear picture of what is a backtrace and how it can be useful. -Now, the following steps show ROS 2 users how to get traces from specific nodes when they encounter a problem. -This tutorial applies to both simulated and physical robots. - -This will cover how to get a backtrace from a specific node using ``ros2 run``, from a launch file representing a single node using ``ros2 launch``, and from a more complex orchestration of nodes. -By the end of this tutorial, you should be able to get a backtrace when you notice a node crashing in ROS 2. - -Preliminaries -------------- - -GDB is the most popular debugger for C/C++ on Unix systems. -It can be used to determine the reason for a crash and track threads. -It may also be used to add breakpoints in your code to check values in memory at particular points in your software. - -Using GDB is a critical skill for all software developers working on C/C++. -While many IDEs have some kind of debugger or profiler built in, it is important to understand how to use these raw tools you have available rather than relying on an IDE to provide them. -Understanding these tools is a fundamental skill of C/C++ development and leaving it up to your IDE can be problematic if you change roles and no longer have access to it or are doing development on the fly through an ssh session to a remote asset. - -Using GDB luckily is fairly simple after you have the basics under your belt. -Here's how to ensure your ROS2 code is ready for debugging: - -- By using ``--cmake-args``: The easiest way to include debug symbols is by adding ``--cmake-args -DCMAKE_BUILD_TYPE=Debug`` to your ``colcon build`` command: - -.. code-block:: console - - $ colcon build --packages-up-to --cmake-args -DCMAKE_BUILD_TYPE=Debug - -- By editing ``CMakeLists.txt`` : Another way is to add ``-g`` to your compiler flags for the ROS package you want to profile / debug. - This flag builds debug symbols that GDB can read to tell you specific lines of code in your project are failing and why. - If you do not set this flag, you can still get backtraces but it will not provide line numbers for failures. - -Now you're ready to debug your code! -If this was a non-ROS project, at this point you might do something like below. -Here we're launching a GDB session and telling our program to immediately run. -Once your program crashes, it will return a gdb session prompt denoted by ``(gdb)``. -At this prompt you can access the information you're interested in. -However, since this is a ROS project with lots of node configurations and other things going on, this isn't a great option for beginners or those that don't like tons of commandline work and understanding the filesystem. - -.. code-block:: console - - $ gdb ex run --args /path/to/exe/program - -Below are sections to describe the three major situations you could run into with ROS 2-based systems. -Read the section that best describes the problem you're attempting to solve. - -Debugging a specific node with GDB ----------------------------------- - -To easily set up a GDB session before launching a ROS 2 node, leverage the ``--prefix`` option to easily set up a GDB session before launching a ROS 2 node. -For GDB debugging, use it as follows: - -.. note:: - - Keep in mind that a ROS 2 executable might contain multiple nodes. - The ``--prefix`` approach ensures you're debugging the correct node within the process. - -**Why Direct GDB Usage Can Be Tricky** - -``--prefix`` will execute some bits of code before our ROS 2 command allowing us to insert some information. -If you attempted to do ``gdb ex run --args ros2 run `` as analog to our example in the preliminaries, you'd find that it couldn't find the ``ros2`` command. -Additionally, trying to source your workspace within GDB would fail for similar reasons. -This is because GDB, when launched this way, lacks the environment setup that normally makes the ``ros2`` command available. - -**Simplifying the Process with --prefix** - -Rather than having to revert to finding the install path of the executable and typing it all out, we can instead use ``--prefix``. -This allows us to use the same ``ros2 run`` syntax you're used to without having to worry about some of the GDB details. - -.. code-block:: console - - $ ros2 run --prefix 'gdb -ex run --args' --all-other-launch arguments - -**The GDB Experience** - -Just as before, this prefix will launch a GDB session and run the node you requested with all the additional command-line arguments. -You should now have your node running and should be chugging along with some debug printing. - -Reading the Stack Trace ------------------------ - -After you obtain a backtrace using GDB, here's how to interpret it: - -- Start at the Bottom: Backtraces list function calls in reverse chronological order. - The function at the bottom is where the crash originates. - -- Follow the Stack Upwards: Each line above represents the function that called the function below it. - Trace upwards until you reach a line of code within your own project. - This often reveals where the problem initiated. - -- Debugging Clues: Function names and their arguments can provide valuable clues about what went wrong. - -**How to Debug once your Node Crashes** - -Once your node crashes, you'll see a prompt like below. -At this point you can get a backtrace. - -.. code-block:: bash - - (gdb) - -In this session, type ``backtrace`` and it will provide you with a backtrace. -Copy this for your needs. - - -**Example backtrace** - -.. code-block:: bash - - (gdb) backtrace - #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 - #1 0x00007ffff79cc859 in __GI_abort () at abort.c:79 - #2 0x00007ffff7c52951 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 - #3 0x00007ffff7c5e47c in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 - #4 0x00007ffff7c5e4e7 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 - #5 0x00007ffff7c5e799 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 - #6 0x00007ffff7c553eb in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 - #7 0x000055555555936c in std::vector >::_M_range_check ( - this=0x5555555cfdb0, __n=100) at /usr/include/c++/9/bits/stl_vector.h:1070 - #8 0x0000555555558e1d in std::vector >::at (this=0x5555555cfdb0, - __n=100) at /usr/include/c++/9/bits/stl_vector.h:1091 - #9 0x000055555555828b in GDBTester::VectorCrash (this=0x5555555cfb40) - at /home/steve/Documents/nav2_ws/src/gdb_test_pkg/src/gdb_test_node.cpp:44 - #10 0x0000555555559cfc in main (argc=1, argv=0x7fffffffc108) - at /home/steve/Documents/nav2_ws/src/gdb_test_pkg/src/main.cpp:25 - -In this example you should read this in the following way, starting at the bottom: - -- In the main function, on line 25 we call a function VectorCrash. - -- In VectorCrash, on line 44, we crashed in the Vector's ``at()`` method with input ``100``. - -- It crashed in ``at()`` on STL vector line 1091 after throwing an exception from a range check failure. - -These traces take some time to get used to reading, but in general, start at the bottom and follow it up the stack until you see the line it crashed on. -Then you can deduce why it crashed. -When you are done with GDB, type ``quit`` and it will exit the session and kill any processes still up. -It may ask you if you want to kill some threads at the end, say yes. - -From a Launch File ------------------- - -Just as in our non-ROS example, we need to setup a GDB session before launching our ROS 2 launch file. -While we could set this up through the commandline, we can instead make use of the same mechanics that we did in the ``ros2 run`` node example, now using a launch file. - -In your launch file, find the node that you're interested in debugging. -For this section, we assume that your launch file contains only a single node (and potentially other information as well). -The ``Node`` function used in the ``launch_ros`` package will take in a field prefix taking a list of prefix arguments. -We will insert the GDB snippet here. - -**Consider the following approaches, depending on your setup:** - -- **Local Debugging with GUI :** If you are debugging locally and have a GUI system available, use: - -.. code-block:: python - - prefix=['xterm -e gdb -ex run --args'] - -This will provide a more interactive debugging experience. -Example usecase for debugging building upon ``'start_sync_slam_toolbox_node'`` - - -.. code-block:: python - - start_sync_slam_toolbox_node = Node( - parameters=[ - get_package_share_directory("slam_toolbox") + '/config/mapper_params_online_sync.yaml', - {'use_sim_time': use_sim_time} - ], - package='slam_toolbox', - executable='sync_slam_toolbox_node', - name='slam_toolbox', - prefix=['xterm -e gdb -ex run --args'], # For interactive GDB in a separate window/GUI - output='screen') - -- **Remote Debugging (without GUI):** If debugging without GUI, omit ``xterm -e`` : - -.. code-block:: bash - - prefix=['gdb -ex run --args'] - -GDB's output and interaction will happen within the terminal session where you launched the ROS 2 application. -Here's an similar example for the ``'start_sync_slam_toolbox_node'`` - - -.. code-block:: python - - start_sync_slam_toolbox_node = Node( - parameters=[ - get_package_share_directory("slam_toolbox") + '/config/mapper_params_online_sync.yaml', - {'use_sim_time': use_sim_time} - ], - package='slam_toolbox', - executable='sync_slam_toolbox_node', - name='slam_toolbox', - prefix=['gdb -ex run --args'], # For GDB within the launch terminal - output='screen') - -Just as before, this prefix will launch a GDB session, now in ``xterm`` and run the launch file you requested with all the additional launch arguments defined. - -Once your node crashes, you'll see a prompt like below, now in the ``xterm`` session. -At this point you can now get a backtrace, and read it using the instructions in `Reading the Stack Trace`_. - -From a Large Project --------------------- -Working with launch files with multiple nodes is a little different so you can interact with your GDB session without being bogged down by other logging in the same terminal. -For this reason, when working with larger launch files, it is a good idea to pull out the specific node you're interested in and launch it separately. - -If your node of interest is being launched from a nested launch file (e.g. an included launch file) you may want to do the following: - -- Comment out the launch file inclusion from the parent launch file - -- Recompile the package of interest with ``-g`` flag for debug symbols - -- Launch the parent launch file in a terminal - -- Launch the node's launch file in another terminal following the instructions in `From a Launch File`_. - -Alternatively, if your node of interest is being launched in these files directly (e.g. you see a ``Node``, ``LifecycleNode``, or inside a ``ComponentContainer``), you will need to separate this from the others: - -- Comment out the node's inclusion from the parent launch file - -- Recompile the package of interest with ``-g`` flag for debug symbols - -- Launch the parent launch file in a terminal - -- Launch the node in another terminal following the instructions in `Debugging a specific node with GDB`_. - -.. note:: - - In this case you may need to remap or provide parameter files to this node if it was previously provided by the launch file. - Using ``--ros-args`` you can give it the path to the new parameters file, remaps, or names. - See :doc:`this tutorial <../../How-To-Guides/Node-arguments>` for the commandline arguments required. - - We understand this can be a pain, so it might encourage you to rather have each node possible as a separately included launch file to make debugging easier. - An example set of arguments might be ``--ros-args -r __node:= --params-file /absolute/path/to/params.yaml`` (as a template). - -Once your node crashes, you'll see a prompt like below in the terminal of the specific node. -At this point you can now get a backtrace, and read it using the instructions in `Reading the Stack Trace`_. - -Debugging tests with GDB ------------------------- - -If a C++ test is failing, GDB can be used directly on the test executable in the build directory. -Ensure to build the code in debug mode. -Since the previous build type may be cached by CMake, clean the cache and rebuild. - -.. code-block:: console - - $ colcon build --cmake-clean-cache --mixin debug - -In order for GDB to load debug symbols for any shared libraries called, make sure to source your environment. -This configures the value of ``LD_LIBRARY_PATH``. - -.. code-block:: console - - $ source install/setup.bash - -Finally, run the test directly through GDB. -For example: - -.. code-block:: console - - $ gdb -ex run ./build/rcl/test/test_logging - -If the code is throwing an unhandled exception, you can catch it in GDB before gtest handles it. - -.. code-block:: console - - $ gdb ./build/rcl/test/test_logging - $ catch throw - $ run - -Automatic backtrace on crash ----------------------------- - -The `backward-cpp `_ library provides beautiful stack traces, and the `backward_ros `_ wrapper simplifies its integration. - -Just add it as a dependency and ``find_package`` it in your CMakeLists and the backward libraries will be injected in all your executables and libraries. +.. redirect-from:: + + How-To-Guides/Getting-Backtraces-in-ROS-2 + +Getting Backtraces in ROS 2 +########################### + +.. contents:: Table of Contents + :local: + +**Goal:** Show various methods for getting backtraces in ROS 2 + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +The following steps show ROS 2 users how to get backtraces when they encounter a problem. + +Overview +-------- + +**What is a Backtrace ?** + +- Imagine your program is like a stack of pancakes where each pancake represents a function it's currently executing. + A backtrace is like a photo of the collapsed pancake stack, showing you the order they were in, revealing how the program ended up with the failure. +- It lists out the sequence of functions that were called, one on top of the other, leading up to the point of failure. + +**Why is it Useful?** + +- **Pinpoints the Problem:** Instead of guessing where in your code an error occurred, the backtrace shows you the exact line number responsible for the crash. +- **Reveals Context:** You can see the chain of events (functions calling other functions) that ultimately triggered the failure. + This helps you understand not just where things went wrong, but also why. + +**Visual Analogy**: Stack of Pancakes + +1. Each Pancake is a Function: Imagine each pancake in a stack represents a function that your program is currently executing. + The pancake at the bottom is your main() function, where it all begins. + +2. Adding Pancakes: Every time a function calls another function, a new pancake is placed on top of the stack. + +3. The Crash: A crash is like the plate slipping out from the bottom of the stack – something went disastrously wrong in the function currently executing. + +4. The Backtrace: The backtrace is like a photo of that fallen pancake stack. + It shows the order of pancakes (functions) from top to bottom, revealing how you ended up at the crash site. + + +**Code Example:** + +.. code-block:: cpp + + void functionC() { + // Something bad happens here, causing a crash + } + + void functionB() { + functionC(); + } + + void functionA() { + functionB(); + } + + int main() { + functionA(); + return 0; + } + +**Backtrace from the Crash:** + +.. code-block:: bash + + #0 functionC() at file.cpp:3 // Crash occurred here + #1 functionB() at file.cpp:8 + #2 functionA() at file.cpp:13 + #3 main() at file.cpp:18 + +**How the Backtrace Helps:** + +- **Crash Origin:** Shows you the exact line in ``functionC()`` that triggered the crash. +- **Call Sequence:** Reveals that ``main()`` called ``functionA()``, which called ``functionB()``, which ultimately led to the error in ``functionC()``. + +The above example gave us a clear picture of what is a backtrace and how it can be useful. +Now, the following steps show ROS 2 users how to get traces from specific nodes when they encounter a problem. +This tutorial applies to both simulated and physical robots. + +This will cover how to get a backtrace from a specific node using ``ros2 run``, from a launch file representing a single node using ``ros2 launch``, and from a more complex orchestration of nodes. +By the end of this tutorial, you should be able to get a backtrace when you notice a node crashing in ROS 2. + +Preliminaries +------------- + +GDB is the most popular debugger for C/C++ on Unix systems. +It can be used to determine the reason for a crash and track threads. +It may also be used to add breakpoints in your code to check values in memory at particular points in your software. + +Using GDB is a critical skill for all software developers working on C/C++. +While many IDEs have some kind of debugger or profiler built in, it is important to understand how to use these raw tools you have available rather than relying on an IDE to provide them. +Understanding these tools is a fundamental skill of C/C++ development and leaving it up to your IDE can be problematic if you change roles and no longer have access to it or are doing development on the fly through an ssh session to a remote asset. + +Using GDB luckily is fairly simple after you have the basics under your belt. +Here's how to ensure your ROS2 code is ready for debugging: + +- By using ``--cmake-args``: The easiest way to include debug symbols is by adding ``--cmake-args -DCMAKE_BUILD_TYPE=Debug`` to your ``colcon build`` command: + +.. code-block:: console + + $ colcon build --packages-up-to --cmake-args -DCMAKE_BUILD_TYPE=Debug + +- By editing ``CMakeLists.txt`` : Another way is to add ``-g`` to your compiler flags for the ROS package you want to profile / debug. + This flag builds debug symbols that GDB can read to tell you specific lines of code in your project are failing and why. + If you do not set this flag, you can still get backtraces but it will not provide line numbers for failures. + +Now you're ready to debug your code! +If this was a non-ROS project, at this point you might do something like below. +Here we're launching a GDB session and telling our program to immediately run. +Once your program crashes, it will return a gdb session prompt denoted by ``(gdb)``. +At this prompt you can access the information you're interested in. +However, since this is a ROS project with lots of node configurations and other things going on, this isn't a great option for beginners or those that don't like tons of commandline work and understanding the filesystem. + +.. code-block:: console + + $ gdb ex run --args /path/to/exe/program + +Below are sections to describe the three major situations you could run into with ROS 2-based systems. +Read the section that best describes the problem you're attempting to solve. + +Debugging a specific node with GDB +---------------------------------- + +To easily set up a GDB session before launching a ROS 2 node, leverage the ``--prefix`` option to easily set up a GDB session before launching a ROS 2 node. +For GDB debugging, use it as follows: + +.. note:: + + Keep in mind that a ROS 2 executable might contain multiple nodes. + The ``--prefix`` approach ensures you're debugging the correct node within the process. + +**Why Direct GDB Usage Can Be Tricky** + +``--prefix`` will execute some bits of code before our ROS 2 command allowing us to insert some information. +If you attempted to do ``gdb ex run --args ros2 run `` as analog to our example in the preliminaries, you'd find that it couldn't find the ``ros2`` command. +Additionally, trying to source your workspace within GDB would fail for similar reasons. +This is because GDB, when launched this way, lacks the environment setup that normally makes the ``ros2`` command available. + +**Simplifying the Process with --prefix** + +Rather than having to revert to finding the install path of the executable and typing it all out, we can instead use ``--prefix``. +This allows us to use the same ``ros2 run`` syntax you're used to without having to worry about some of the GDB details. + +.. code-block:: console + + $ ros2 run --prefix 'gdb -ex run --args' --all-other-launch arguments + +**The GDB Experience** + +Just as before, this prefix will launch a GDB session and run the node you requested with all the additional command-line arguments. +You should now have your node running and should be chugging along with some debug printing. + +Reading the Stack Trace +----------------------- + +After you obtain a backtrace using GDB, here's how to interpret it: + +- Start at the Bottom: Backtraces list function calls in reverse chronological order. + The function at the bottom is where the crash originates. + +- Follow the Stack Upwards: Each line above represents the function that called the function below it. + Trace upwards until you reach a line of code within your own project. + This often reveals where the problem initiated. + +- Debugging Clues: Function names and their arguments can provide valuable clues about what went wrong. + +**How to Debug once your Node Crashes** + +Once your node crashes, you'll see a prompt like below. +At this point you can get a backtrace. + +.. code-block:: bash + + (gdb) + +In this session, type ``backtrace`` and it will provide you with a backtrace. +Copy this for your needs. + + +**Example backtrace** + +.. code-block:: bash + + (gdb) backtrace + #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 + #1 0x00007ffff79cc859 in __GI_abort () at abort.c:79 + #2 0x00007ffff7c52951 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 + #3 0x00007ffff7c5e47c in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 + #4 0x00007ffff7c5e4e7 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 + #5 0x00007ffff7c5e799 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 + #6 0x00007ffff7c553eb in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 + #7 0x000055555555936c in std::vector >::_M_range_check ( + this=0x5555555cfdb0, __n=100) at /usr/include/c++/9/bits/stl_vector.h:1070 + #8 0x0000555555558e1d in std::vector >::at (this=0x5555555cfdb0, + __n=100) at /usr/include/c++/9/bits/stl_vector.h:1091 + #9 0x000055555555828b in GDBTester::VectorCrash (this=0x5555555cfb40) + at /home/steve/Documents/nav2_ws/src/gdb_test_pkg/src/gdb_test_node.cpp:44 + #10 0x0000555555559cfc in main (argc=1, argv=0x7fffffffc108) + at /home/steve/Documents/nav2_ws/src/gdb_test_pkg/src/main.cpp:25 + +In this example you should read this in the following way, starting at the bottom: + +- In the main function, on line 25 we call a function VectorCrash. + +- In VectorCrash, on line 44, we crashed in the Vector's ``at()`` method with input ``100``. + +- It crashed in ``at()`` on STL vector line 1091 after throwing an exception from a range check failure. + +These traces take some time to get used to reading, but in general, start at the bottom and follow it up the stack until you see the line it crashed on. +Then you can deduce why it crashed. +When you are done with GDB, type ``quit`` and it will exit the session and kill any processes still up. +It may ask you if you want to kill some threads at the end, say yes. + +From a Launch File +------------------ + +Just as in our non-ROS example, we need to setup a GDB session before launching our ROS 2 launch file. +While we could set this up through the commandline, we can instead make use of the same mechanics that we did in the ``ros2 run`` node example, now using a launch file. + +In your launch file, find the node that you're interested in debugging. +For this section, we assume that your launch file contains only a single node (and potentially other information as well). +The ``Node`` function used in the ``launch_ros`` package will take in a field prefix taking a list of prefix arguments. +We will insert the GDB snippet here. + +**Consider the following approaches, depending on your setup:** + +- **Local Debugging with GUI :** If you are debugging locally and have a GUI system available, use: + +.. code-block:: python + + prefix=['xterm -e gdb -ex run --args'] + +This will provide a more interactive debugging experience. +Example usecase for debugging building upon ``'start_sync_slam_toolbox_node'`` - + +.. code-block:: python + + start_sync_slam_toolbox_node = Node( + parameters=[ + get_package_share_directory("slam_toolbox") + '/config/mapper_params_online_sync.yaml', + {'use_sim_time': use_sim_time} + ], + package='slam_toolbox', + executable='sync_slam_toolbox_node', + name='slam_toolbox', + prefix=['xterm -e gdb -ex run --args'], # For interactive GDB in a separate window/GUI + output='screen') + +- **Remote Debugging (without GUI):** If debugging without GUI, omit ``xterm -e`` : + +.. code-block:: bash + + prefix=['gdb -ex run --args'] + +GDB's output and interaction will happen within the terminal session where you launched the ROS 2 application. +Here's an similar example for the ``'start_sync_slam_toolbox_node'`` - + +.. code-block:: python + + start_sync_slam_toolbox_node = Node( + parameters=[ + get_package_share_directory("slam_toolbox") + '/config/mapper_params_online_sync.yaml', + {'use_sim_time': use_sim_time} + ], + package='slam_toolbox', + executable='sync_slam_toolbox_node', + name='slam_toolbox', + prefix=['gdb -ex run --args'], # For GDB within the launch terminal + output='screen') + +Just as before, this prefix will launch a GDB session, now in ``xterm`` and run the launch file you requested with all the additional launch arguments defined. + +Once your node crashes, you'll see a prompt like below, now in the ``xterm`` session. +At this point you can now get a backtrace, and read it using the instructions in `Reading the Stack Trace`_. + +From a Large Project +-------------------- +Working with launch files with multiple nodes is a little different so you can interact with your GDB session without being bogged down by other logging in the same terminal. +For this reason, when working with larger launch files, it is a good idea to pull out the specific node you're interested in and launch it separately. + +If your node of interest is being launched from a nested launch file (e.g. an included launch file) you may want to do the following: + +- Comment out the launch file inclusion from the parent launch file + +- Recompile the package of interest with ``-g`` flag for debug symbols + +- Launch the parent launch file in a terminal + +- Launch the node's launch file in another terminal following the instructions in `From a Launch File`_. + +Alternatively, if your node of interest is being launched in these files directly (e.g. you see a ``Node``, ``LifecycleNode``, or inside a ``ComponentContainer``), you will need to separate this from the others: + +- Comment out the node's inclusion from the parent launch file + +- Recompile the package of interest with ``-g`` flag for debug symbols + +- Launch the parent launch file in a terminal + +- Launch the node in another terminal following the instructions in `Debugging a specific node with GDB`_. + +.. note:: + + In this case you may need to remap or provide parameter files to this node if it was previously provided by the launch file. + Using ``--ros-args`` you can give it the path to the new parameters file, remaps, or names. + See :doc:`this tutorial <../../How-To-Guides/Node-arguments>` for the commandline arguments required. + + We understand this can be a pain, so it might encourage you to rather have each node possible as a separately included launch file to make debugging easier. + An example set of arguments might be ``--ros-args -r __node:= --params-file /absolute/path/to/params.yaml`` (as a template). + +Once your node crashes, you'll see a prompt like below in the terminal of the specific node. +At this point you can now get a backtrace, and read it using the instructions in `Reading the Stack Trace`_. + +Debugging tests with GDB +------------------------ + +If a C++ test is failing, GDB can be used directly on the test executable in the build directory. +Ensure to build the code in debug mode. +Since the previous build type may be cached by CMake, clean the cache and rebuild. + +.. code-block:: console + + $ colcon build --cmake-clean-cache --mixin debug + +In order for GDB to load debug symbols for any shared libraries called, make sure to source your environment. +This configures the value of ``LD_LIBRARY_PATH``. + +.. code-block:: console + + $ source install/setup.bash + +Finally, run the test directly through GDB. +For example: + +.. code-block:: console + + $ gdb -ex run ./build/rcl/test/test_logging + +If the code is throwing an unhandled exception, you can catch it in GDB before gtest handles it. + +.. code-block:: console + + $ gdb ./build/rcl/test/test_logging + $ catch throw + $ run + +Automatic backtrace on crash +---------------------------- + +The `backward-cpp `_ library provides beautiful stack traces, and the `backward_ros `_ wrapper simplifies its integration. + +Just add it as a dependency and ``find_package`` it in your CMakeLists and the backward libraries will be injected in all your executables and libraries. \ No newline at end of file diff --git a/source/Developer-Tools/Debugging/ROS-2-IDEs.rst b/source/Developer-Tools/Debugging/ROS-2-IDEs.rst index 06601c64de1..d25c6b9f171 100644 --- a/source/Developer-Tools/Debugging/ROS-2-IDEs.rst +++ b/source/Developer-Tools/Debugging/ROS-2-IDEs.rst @@ -1,266 +1,270 @@ -IDEs and Debugging [community-contributed] -========================================== - -ROS 2 is not made around a specific development environment and the main focus is on building / running from the command line. -Nonetheless Integrated Development Environments (IDEs) can be used to develop, run and/or debug ROS 2 nodes. - -Below are listed some IDEs and instructions on how to use them with ROS 2. - - -.. contents:: Contents - :depth: 2 - :local: - - -General -------- - - -.. _InstalledPythonCode: - -Installed Python Code -^^^^^^^^^^^^^^^^^^^^^ - -By default, when building workspaces with: - -.. code-block:: console - - $ colcon build - -The Python code will be coped over into the ``build``/``install`` directories. -So when attaching a debugger to a ``ros2 run`` command from within an IDE, the code being run (from the ``build``/``install``) is not the same as the files opened in the IDE project. - -There are 2 options to deal with this: - -* Open the source files from ``build``/``install`` directory and place breakpoints there. -* Build the workspace with the `--symlink-install `__ flag to colcon, which will symlink the source files to the ``build``/``install`` directory instead. - - -Visual Studio Code ------------------- - -`VSCode `_ is a versatile and free development environment. - -VSCode is relatively easy to use with ROS 2. -Simply activate your environment in a command line and start the VSCode application from the same terminal and use as normal. -So: - -#. Create your ROS workspace as you would normally. -#. In a terminal, source both ROS 2 and your install (if it was built already). -#. Start VSCode from the same command line. - The terminal will be blocked until the application is closed again. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ cd ~/dev_ws - $ source ./install/setup.bash - $ /usr/bin/code ./src/my_node/ - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - $ cd ~/dev_ws - $ . ./install/setup.bash - $ /Applications/Visual Studio Code.app/Contents/Resources/app/bin/code ./src/my_node/ - - .. group-tab:: Windows - - In a Windows command line interface: - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - $ cd C:\dev_ws - $ call .\install\local_setup.bat - $ "C:\Program Files\Microsoft VS Code\Code.exe" .\src\my_node\ - - Or in powershell: - - .. code-block:: console - - $ C:\dev\ros2\local_setup.ps1 - $ cd C:\dev_ws - $ .\install\local_setup.ps1 - $ & "C:\Program Files\Microsoft VS Code\Code.exe" .\src\my_node\ - - -VSCode and any terminal created inside VSCode will correctly inherit from the parent environment and should have ROS and installed package available. - -.. note:: - - After adding packages or making major changes you might need to source your install again. - The simplest way to do this is to close VSCode and restart it as above. - - -Python -^^^^^^ - -In your workspace, verify the correct interpreter is used. -Through sourcing the basic command ``python`` should be correct, but VSCode likes to resort to an absolute path for Python. -In the bottom right corner click on "Selected Python Interpreter" to change it. - -If your ROS 2 Python version is from a virtual environment, VSCode will try to source it at each run command. -But we already started VSCode from a sourced environment, so this extra step is not necessary. -You can disable this for the current workspace by finding "Settings" > "Extensions" > "Python" > "Activate Environment" and disabling the check. - -Now simply run a file or create a configuration in ``launch.json``. -Debugging a node is easiest by creating a configuration like a ``python ...`` command, instead of ``ros2 run/launch ...``. -An example of ``launch.json`` could be: - -.. code-block:: - - { - "version": "0.2.0", - "configurations": [ - { - "name": "Python: File", - "type": "python", - "request": "launch", - "program": "my_node.py" - }, - ] - } - - -Instead you could also create a configuration for attaching to a running process, under "Attach using Process Id". - - -See :doc:`Setup ROS 2 with VSCode and Docker` for full instructions on how to use VSCode, in combination with Docker. - - -PyCharm -------- - -`PyCharm `_ is an IDE specifically for Python. - -Of course it can only be meaningfully used for nodes made in Python. - -With PyCharm you can either attach to an existing process (probably started by you via ``ros2 run ...`` or ``ros2 launch ...``) or run the node directly from Python (equivalent to ``python [file.py]``. - - -Integrate for code inspection -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can setup your PyCharm project such that it is fully aware of ROS 2 code, allowing code completion and suggestion. - - -Linux -""""" - -Open a terminal, source ROS and start PyCharm: - -.. code-block:: console - - $ source /opt/ros/humble/setup.bash - $ cd path/to/dev_ws - $ /opt/pycharm/bin/pycharm.sh - -After selecting the correct interpreter, everything should work. - -.. note:: - - This is untested. - - -Windows -""""""" - -First sourcing ROS and then starting PyCharm from the command line seems to have no effect on Windows. -Instead, some settings need to be tweaked. - -#. Create your ROS workspace as you would normally. -#. Start PyCharm normally. -#. Open a project. - This should be the root directory of the ROS node you're developing, e.g. ``C:\dev_ws\src\my_node``. -#. Click "Add new interpreter" > "Add local interpreter...". - Select a system interpreter (or virtual environment if you're using one) and select the executable of your ROS Python version (typically ``C:\Python38\python.exe``). - - * If you now open one of your code files, you will see warnings about missing imports. - Trying to run the file will confirm these issues. - -#. Under the "Python Interpreters" window, find and select your ROS interpreter. - Edit the name to something recognizable. - More importantly, now click the "Show Interpreter Paths" button. -#. In the new window, you will see the paths already associated with this interpreter. - Click the "+" button and add two more paths (according to your ROS install): - - * ``C:\dev\ros2_humble\bin`` - * ``C:\dev\ros2_humble\Lib\site-packages`` - -PyCharm will re-index and when finished it should correctly interpret your project, recognising the ROS 2 system packages. -You can navigate through code, get completion and read doc blurbs as expected. - - -If there are dependencies built alongside with your package, they are probably not yet recognized and result in invalid IDE warnings and runtime errors. - -Resolve this by: - -* Making sure the ``PATH`` override in the run/debug configuration includes both the ROS 2 install and your workspace, e.g.: - - .. code-block:: console - - $ C:\dev\ros2_humble\local_setup.ps1 - $ C:\dev_ws\install\local_setup.ps1 - $ echo $ENV:Path - -* Adding the relevant folders from the ``install/`` directory to your project sources. - - Go to "Settings..." and under "Project: " > "Project Structure" click "Add content root". - Add all the relevant ``site-packages`` folders under ``install/Lib/*``. - - Finally, make sure your run/debug configuration has the option "include content roots in PYTHONPATH" enabled. - -.. tip:: - - Using the `--merge-install `__ option with your colcon build will limit the number of depending directories, making it easier to configure PyCharm. - - -Attach to Process -^^^^^^^^^^^^^^^^^ - -Even without any configuration to PyCharm, you can always just attach to a running Python node. -Open your project source and simply run your node as usual: - -.. code-block:: console - - $ ros2 run my_node main - -Then in PyCharm select "Run" > "Attach to Process...". -It might take a second, but a small window should show listing the currently running Python instances, including your node. -There can be multiple Python processes, so there may be some trial-and-error to find the right one. - -After selecting an instance, the usual debugging tools are available. -You can pause it or create breakpoints in the code and step through it. - -.. note:: - - The code in your project might not be the files being executed, see :ref:`this`. - - -Run/Debug -^^^^^^^^^ - -Follow the steps for integration first. - -Running your Python file from PyCharm will likely result in import errors. -This is because PyCharm extends the ``PYTHONPATH`` environment variable, but it leaves ``PATH`` untouched. -Necessary library files in ``ros/bin`` are not found. - -Edit the run/debug configuration for your file and under "Environment Variables:" add a new variable. -It is currently not supported to extend the existing ``PATH``, so we need to override it. -From a sourced ROS terminal, export the content of ``PATH`` with: ``echo $Env:PATH``. -Copy the result. - -Back in PyCharm, paste it as ``PATH``, apply changes and run or debug your node. -It should work like any Python project now, allowing easy additions of breakpoints and other debug methods. - -.. note:: - - On Windows it seems the capitalization of the ``PATH`` variable under "Environment Variables:" must be "path" (all lowercase) in order to work. +.. redirect-from:: + + How-To-Guides/ROS-2-IDEs + +IDEs and Debugging [community-contributed] +========================================== + +ROS 2 is not made around a specific development environment and the main focus is on building / running from the command line. +Nonetheless Integrated Development Environments (IDEs) can be used to develop, run and/or debug ROS 2 nodes. + +Below are listed some IDEs and instructions on how to use them with ROS 2. + + +.. contents:: Contents + :depth: 2 + :local: + + +General +------- + + +.. _InstalledPythonCode: + +Installed Python Code +^^^^^^^^^^^^^^^^^^^^^ + +By default, when building workspaces with: + +.. code-block:: console + + $ colcon build + +The Python code will be coped over into the ``build``/``install`` directories. +So when attaching a debugger to a ``ros2 run`` command from within an IDE, the code being run (from the ``build``/``install``) is not the same as the files opened in the IDE project. + +There are 2 options to deal with this: + +* Open the source files from ``build``/``install`` directory and place breakpoints there. +* Build the workspace with the `--symlink-install `__ flag to colcon, which will symlink the source files to the ``build``/``install`` directory instead. + + +Visual Studio Code +------------------ + +`VSCode `_ is a versatile and free development environment. + +VSCode is relatively easy to use with ROS 2. +Simply activate your environment in a command line and start the VSCode application from the same terminal and use as normal. +So: + +#. Create your ROS workspace as you would normally. +#. In a terminal, source both ROS 2 and your install (if it was built already). +#. Start VSCode from the same command line. + The terminal will be blocked until the application is closed again. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ cd ~/dev_ws + $ source ./install/setup.bash + $ /usr/bin/code ./src/my_node/ + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + $ cd ~/dev_ws + $ . ./install/setup.bash + $ /Applications/Visual Studio Code.app/Contents/Resources/app/bin/code ./src/my_node/ + + .. group-tab:: Windows + + In a Windows command line interface: + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + $ cd C:\dev_ws + $ call .\install\local_setup.bat + $ "C:\Program Files\Microsoft VS Code\Code.exe" .\src\my_node\ + + Or in powershell: + + .. code-block:: console + + $ C:\dev\ros2\local_setup.ps1 + $ cd C:\dev_ws + $ .\install\local_setup.ps1 + $ & "C:\Program Files\Microsoft VS Code\Code.exe" .\src\my_node\ + + +VSCode and any terminal created inside VSCode will correctly inherit from the parent environment and should have ROS and installed package available. + +.. note:: + + After adding packages or making major changes you might need to source your install again. + The simplest way to do this is to close VSCode and restart it as above. + + +Python +^^^^^^ + +In your workspace, verify the correct interpreter is used. +Through sourcing the basic command ``python`` should be correct, but VSCode likes to resort to an absolute path for Python. +In the bottom right corner click on "Selected Python Interpreter" to change it. + +If your ROS 2 Python version is from a virtual environment, VSCode will try to source it at each run command. +But we already started VSCode from a sourced environment, so this extra step is not necessary. +You can disable this for the current workspace by finding "Settings" > "Extensions" > "Python" > "Activate Environment" and disabling the check. + +Now simply run a file or create a configuration in ``launch.json``. +Debugging a node is easiest by creating a configuration like a ``python ...`` command, instead of ``ros2 run/launch ...``. +An example of ``launch.json`` could be: + +.. code-block:: + + { + "version": "0.2.0", + "configurations": [ + { + "name": "Python: File", + "type": "python", + "request": "launch", + "program": "my_node.py" + }, + ] + } + + +Instead you could also create a configuration for attaching to a running process, under "Attach using Process Id". + + +See :doc:`Setup ROS 2 with VSCode and Docker` for full instructions on how to use VSCode, in combination with Docker. + + +PyCharm +------- + +`PyCharm `_ is an IDE specifically for Python. + +Of course it can only be meaningfully used for nodes made in Python. + +With PyCharm you can either attach to an existing process (probably started by you via ``ros2 run ...`` or ``ros2 launch ...``) or run the node directly from Python (equivalent to ``python [file.py]``. + + +Integrate for code inspection +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can setup your PyCharm project such that it is fully aware of ROS 2 code, allowing code completion and suggestion. + + +Linux +""""" + +Open a terminal, source ROS and start PyCharm: + +.. code-block:: console + + $ source /opt/ros/humble/setup.bash + $ cd path/to/dev_ws + $ /opt/pycharm/bin/pycharm.sh + +After selecting the correct interpreter, everything should work. + +.. note:: + + This is untested. + + +Windows +""""""" + +First sourcing ROS and then starting PyCharm from the command line seems to have no effect on Windows. +Instead, some settings need to be tweaked. + +#. Create your ROS workspace as you would normally. +#. Start PyCharm normally. +#. Open a project. + This should be the root directory of the ROS node you're developing, e.g. ``C:\dev_ws\src\my_node``. +#. Click "Add new interpreter" > "Add local interpreter...". + Select a system interpreter (or virtual environment if you're using one) and select the executable of your ROS Python version (typically ``C:\Python38\python.exe``). + + * If you now open one of your code files, you will see warnings about missing imports. + Trying to run the file will confirm these issues. + +#. Under the "Python Interpreters" window, find and select your ROS interpreter. + Edit the name to something recognizable. + More importantly, now click the "Show Interpreter Paths" button. +#. In the new window, you will see the paths already associated with this interpreter. + Click the "+" button and add two more paths (according to your ROS install): + + * ``C:\dev\ros2_humble\bin`` + * ``C:\dev\ros2_humble\Lib\site-packages`` + +PyCharm will re-index and when finished it should correctly interpret your project, recognising the ROS 2 system packages. +You can navigate through code, get completion and read doc blurbs as expected. + + +If there are dependencies built alongside with your package, they are probably not yet recognized and result in invalid IDE warnings and runtime errors. + +Resolve this by: + +* Making sure the ``PATH`` override in the run/debug configuration includes both the ROS 2 install and your workspace, e.g.: + + .. code-block:: console + + $ C:\dev\ros2_humble\local_setup.ps1 + $ C:\dev_ws\install\local_setup.ps1 + $ echo $ENV:Path + +* Adding the relevant folders from the ``install/`` directory to your project sources. + + Go to "Settings..." and under "Project: " > "Project Structure" click "Add content root". + Add all the relevant ``site-packages`` folders under ``install/Lib/*``. + + Finally, make sure your run/debug configuration has the option "include content roots in PYTHONPATH" enabled. + +.. tip:: + + Using the `--merge-install `__ option with your colcon build will limit the number of depending directories, making it easier to configure PyCharm. + + +Attach to Process +^^^^^^^^^^^^^^^^^ + +Even without any configuration to PyCharm, you can always just attach to a running Python node. +Open your project source and simply run your node as usual: + +.. code-block:: console + + $ ros2 run my_node main + +Then in PyCharm select "Run" > "Attach to Process...". +It might take a second, but a small window should show listing the currently running Python instances, including your node. +There can be multiple Python processes, so there may be some trial-and-error to find the right one. + +After selecting an instance, the usual debugging tools are available. +You can pause it or create breakpoints in the code and step through it. + +.. note:: + + The code in your project might not be the files being executed, see :ref:`this`. + + +Run/Debug +^^^^^^^^^ + +Follow the steps for integration first. + +Running your Python file from PyCharm will likely result in import errors. +This is because PyCharm extends the ``PYTHONPATH`` environment variable, but it leaves ``PATH`` untouched. +Necessary library files in ``ros/bin`` are not found. + +Edit the run/debug configuration for your file and under "Environment Variables:" add a new variable. +It is currently not supported to extend the existing ``PATH``, so we need to override it. +From a sourced ROS terminal, export the content of ``PATH`` with: ``echo $Env:PATH``. +Copy the result. + +Back in PyCharm, paste it as ``PATH``, apply changes and run or debug your node. +It should work like any Python project now, allowing easy additions of breakpoints and other debug methods. + +.. note:: + + On Windows it seems the capitalization of the ``PATH`` variable under "Environment Variables:" must be "path" (all lowercase) in order to work. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst b/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst index ecab8b362d8..a4fdbcb4ed8 100644 --- a/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst +++ b/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst @@ -1,94 +1,95 @@ -.. redirect-from:: - - Introspection-with-command-line-tools - Tutorials/Introspection-with-command-line-tools - Concepts/About-Command-Line-Tools - -Introspection with command line tools -===================================== - -.. contents:: Table of Contents - :local: - -ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system. - -Usage ------ - -The main entry point for the tools is the command ``ros2``, which itself has various sub-commands for introspecting and working with nodes, topics, services, and more. - -To see all available sub-commands run: - -.. code-block:: console - - $ ros2 --help - -Examples of sub-commands that are available include: - -* ``action``: Introspect/interact with ROS actions -* ``bag``: Record/play a rosbag -* ``component``: Manage component containers -* ``daemon``: Introspect/configure the ROS 2 daemon -* ``doctor``: Check ROS setup for potential issues -* ``interface``: Show information about ROS interfaces -* ``launch``: Run/introspect a launch file -* ``lifecycle``: Introspect/manage nodes with managed lifecycles -* ``multicast``: Multicast debugging commands -* ``node``: Introspect ROS nodes -* ``param``: Introspect/configure parameters on a node -* ``pkg``: Introspect ROS packages -* ``plugin``: Introspect ROS plugins -* ``run``: Run ROS nodes -* ``security``: Configure security settings -* ``service``: Introspect/call ROS services -* ``test``: Run a ROS launch test -* ``topic``: Introspect/publish ROS topics -* ``trace``: Tracing tools to get information on ROS nodes execution (only available on Linux) - -Example -------- - -To produce the typical talker-listener example using command-line tools, the ``topic`` sub-command can be used to publish and echo messages on a topic. - -Publish messages in one terminal with: - -.. code-block:: console - - $ ros2 topic pub /chatter std_msgs/msg/String "data: Hello world" - publisher: beginning loop - publishing #1: std_msgs.msg.String(data='Hello world') - - publishing #2: std_msgs.msg.String(data='Hello world') - -Echo messages received in another terminal with: - -.. code-block:: console - - $ ros2 topic echo /chatter - data: Hello world - - data: Hello world - -ROS 2 Daemon: Background Discovery Service ------------------------------------------- - -ROS 2 uses a distributed discovery process for nodes to connect to each other. -As this process purposefully does not use a centralized discovery mechanism, it can take time for ROS nodes to discover all other participants in the ROS graph. -To address this, ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the list of node names. - -The ROS 2 daemon is automatically started when you first use command-line tools like ``ros2 node list``, ``ros2 topic list``, or other introspection commands. -If no daemon is running, these tools will instantiate a new daemon process in the background before executing the requested command. - -The daemon communicates using the localhost network interface (127.0.0.1) and uses the :doc:`ROS_DOMAIN_ID <../Intermediate/About-Domain-ID>` environment variable as a port number offset. -This means that if you want to control a specific daemon instance (for example, using ``ros2 daemon stop``), you must ensure that your :doc:`ROS_DOMAIN_ID <../Intermediate/About-Domain-ID>` matches the domain ID used by that daemon. -Different :doc:`ROS_DOMAIN_ID <../Intermediate/About-Domain-ID>` values will result in separate daemon instances running on different ports. - -You can run ``ros2 daemon --help`` for more options for interacting with the daemon, including commands to start, stop, or check the status of the daemon process. - -Implementation --------------- - -The source code for the ``ros2`` command is available at https://github.com/ros2/ros2cli. - -The ``ros2`` tool has been implemented as a framework that can be extended via plugins. -For example, the `sros2 `__ package provides a ``security`` sub-command that is automatically detected by the ``ros2`` tool if the ``sros2`` package is installed. +.. redirect-from:: + + Introspection-with-command-line-tools + Tutorials/Introspection-with-command-line-tools + Concepts/About-Command-Line-Tools + Concepts/Basic/About-Command-Line-Tools + +Introspection with command line tools +===================================== + +.. contents:: Table of Contents + :local: + +ROS 2 includes a suite of command-line tools for introspecting a ROS 2 system. + +Usage +----- + +The main entry point for the tools is the command ``ros2``, which itself has various sub-commands for introspecting and working with nodes, topics, services, and more. + +To see all available sub-commands run: + +.. code-block:: console + + $ ros2 --help + +Examples of sub-commands that are available include: + +* ``action``: Introspect/interact with ROS actions +* ``bag``: Record/play a rosbag +* ``component``: Manage component containers +* ``daemon``: Introspect/configure the ROS 2 daemon +* ``doctor``: Check ROS setup for potential issues +* ``interface``: Show information about ROS interfaces +* ``launch``: Run/introspect a launch file +* ``lifecycle``: Introspect/manage nodes with managed lifecycles +* ``multicast``: Multicast debugging commands +* ``node``: Introspect ROS nodes +* ``param``: Introspect/configure parameters on a node +* ``pkg``: Introspect ROS packages +* ``plugin``: Introspect ROS plugins +* ``run``: Run ROS nodes +* ``security``: Configure security settings +* ``service``: Introspect/call ROS services +* ``test``: Run a ROS launch test +* ``topic``: Introspect/publish ROS topics +* ``trace``: Tracing tools to get information on ROS nodes execution (only available on Linux) + +Example +------- + +To produce the typical talker-listener example using command-line tools, the ``topic`` sub-command can be used to publish and echo messages on a topic. + +Publish messages in one terminal with: + +.. code-block:: console + + $ ros2 topic pub /chatter std_msgs/msg/String "data: Hello world" + publisher: beginning loop + publishing #1: std_msgs.msg.String(data='Hello world') + + publishing #2: std_msgs.msg.String(data='Hello world') + +Echo messages received in another terminal with: + +.. code-block:: console + + $ ros2 topic echo /chatter + data: Hello world + + data: Hello world + +ROS 2 Daemon: Background Discovery Service +------------------------------------------ + +ROS 2 uses a distributed discovery process for nodes to connect to each other. +As this process purposefully does not use a centralized discovery mechanism, it can take time for ROS nodes to discover all other participants in the ROS graph. +To address this, ROS 2 runs a background daemon process that maintains information about the ROS graph to provide faster responses to queries, such as the list of node names. + +The ROS 2 daemon is automatically started when you first use command-line tools like ``ros2 node list``, ``ros2 topic list``, or other introspection commands. +If no daemon is running, these tools will instantiate a new daemon process in the background before executing the requested command. + +The daemon communicates using the localhost network interface (127.0.0.1) and uses the :doc:`ROS_DOMAIN_ID <../../ROS-Framework/nodes/About-Domain-ID>` environment variable as a port number offset. +This means that if you want to control a specific daemon instance (for example, using ``ros2 daemon stop``), you must ensure that your :doc:`ROS_DOMAIN_ID <../../ROS-Framework/nodes/About-Domain-ID>` matches the domain ID used by that daemon. +Different :doc:`ROS_DOMAIN_ID <../../ROS-Framework/nodes/About-Domain-ID>` values will result in separate daemon instances running on different ports. + +You can run ``ros2 daemon --help`` for more options for interacting with the daemon, including commands to start, stop, or check the status of the daemon process. + +Implementation +-------------- + +The source code for the ``ros2`` command is available at https://github.com/ros2/ros2cli. + +The ``ros2`` tool has been implemented as a framework that can be extended via plugins. +For example, the `sros2 `__ package provides a ``security`` sub-command that is automatically detected by the ``ros2`` tool if the ``sros2`` package is installed. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/About-Security.rst b/source/Developer-Tools/Introspection-and-analysis/About-Security.rst index a52066c4a4e..41f062271c5 100644 --- a/source/Developer-Tools/Introspection-and-analysis/About-Security.rst +++ b/source/Developer-Tools/Introspection-and-analysis/About-Security.rst @@ -1,94 +1,95 @@ -.. redirect-from:: - - Concepts/About-Security - -ROS 2 Security -============== - -.. contents:: Table of Contents - :local: - -Overview --------- - -ROS 2 includes the ability to secure communications among nodes within the ROS 2 computational graph. -Similar to discovery, security happens through the underlying ROS 2 middleware (provided it has support for the corresponding security plugins). -No additional software installation is needed to enable security; however, the middleware requires configuration files for each ROS graph participant. -These files enable encryption and authentication, and define policies both for individual nodes and for the overall ROS graph. -ROS 2 also adds a master "on/off" switch to control security behavior. - -ROS utilities can create the authoritative `trust anchor `_ for a ROS application, or an external certificate authority can be used. - -Built-in ROS 2 security features enable control over communications throughout the ROS graph. -This not only allows for encrypting data in transit between ROS domain participants, but also enables authentication of participants sending data, ensures the integrity of data being sent, and enables domain-wide access controls. - -ROS 2 security services are provided by the underlying `Data Distribution Service (DDS) `_ which is used for communications between nodes. -DDS vendors provide open source and commercial DDS implementations that work with ROS. -However, in order to create a specification-compliant implementation of DDS, all vendors must include security plugins as outlined in the `DDS Security Specification `_. -ROS security features take advantage of these DDS security plugins to provide policy-based encryption, authentication and access control. -DDS and ROS security is enabled through predefined configuration files and environment variables. - - -The Security Enclave --------------------- - -A security enclave encapsulates a single policy for protecting ROS communications. -The enclave may set policy for multiple nodes, for an entire ROS graph, or any combination of protected ROS processes and devices. -Security enclaves can be flexibly mapped to processes, users, or devices at deployment. -Adjusting this default behavior becomes important for optimizing communications and for complex systems. -See the ROS 2 Security Enclaves `design document `_ for additional details. - - -Security Files --------------- - -A `ROS 2 security enclave `_ is established with six files as outlined by the DDS specification. -Three of these files define an enclave's identity, while three other files define the permissions to be granted to the enclave. -All six files reside in a single directory, and nodes launched without a qualified enclave path use files in the default root level enclave. - -Enclave Identity -^^^^^^^^^^^^^^^^ - -The Identity Certificate Authority file ``identity_ca.cert.pem`` acts as the trust anchor used to identify participants. -Each enclave also holds its unique identifying certificate in the file ``cert.pem``, and the associated private key in the file ``key.pem``. -Because the ``cert.pem`` certificate has been signed by identity certificate, when a participant presents this certificate to other domain members, they are able to validate the participant's identity using their own copy of the identity certificate. -This valid certificate exchange allows the enclave to securely establish trusted communications with other participants. -The enclave does not not share the ``key.pem`` private key, but only uses it for decryption and message signing. - -Enclave Permissions -^^^^^^^^^^^^^^^^^^^ - -The Permissions Certificate Authority file ``permissions_ca.cert.pem`` serves as the trust anchor to grant permissions to security enclaves. -This certificate is used to create the signed file ``governance.p7s``, an XML document which defines domain-wide protection policies. -Similarly the XML file ``permissions.p7s`` outlines permissions of this particular enclave and has been signed by the Permissions CA. -Domain members use a copy of the permissions CA to validate these signed files and grant the requested access. - -Although these two certificate authorities enable separate workflows for identity and permissions, often the same certificate serves as both the identity and the permissions authority. - -Private Keys -^^^^^^^^^^^^ - -The identity and permissions certificates also have associated private key files. -Add new enclaves to the domain by signing their Certificate Signing Request (CSR) with the identity certificate's private key. -Similarly, grant permissions for a new enclave by signing a permissions XML document with the permission certificate's private key. - - -Security Environment Variables ------------------------------- - -The environment variable ``ROS_SECURITY_ENABLE`` acts as the enclave's master "on/off" switch for ROS 2 security features. -Security has been turned off by default, so security features will not be enabled even when the proper security files are present. -In order to enable ROS 2 security, set this environment variable to ``true`` (case sensitive). - -Once security has been enabled, the environment variable ``ROS_SECURITY_STRATEGY`` defines how domain participants handle problems when launching participants. -Security features depend on certificates and properly signed configuration files, yet by default, an improperly configured participant will still launch successfully but without security features. -In order to enforce strict compliance with security settings and fail to launch non-compliant enclaves, set this environment variable to ``Enforce`` (case sensitive). - -Additional security-related environment variables can be found in the `ROS 2 DDS-Security Integration design document `_. -These variables generally assist ROS in managing enclaves and locating the security files. - - -Learn More ----------- - -For more information and hands-on exercises enabling ROS 2 communications security, see the :doc:`../../Tutorials/Advanced/Security/Introducing-ros2-security`. +.. redirect-from:: + + Concepts/About-Security + Concepts/Intermediate/About-Security + +ROS 2 Security +============== + +.. contents:: Table of Contents + :local: + +Overview +-------- + +ROS 2 includes the ability to secure communications among nodes within the ROS 2 computational graph. +Similar to discovery, security happens through the underlying ROS 2 middleware (provided it has support for the corresponding security plugins). +No additional software installation is needed to enable security; however, the middleware requires configuration files for each ROS graph participant. +These files enable encryption and authentication, and define policies both for individual nodes and for the overall ROS graph. +ROS 2 also adds a master "on/off" switch to control security behavior. + +ROS utilities can create the authoritative `trust anchor `_ for a ROS application, or an external certificate authority can be used. + +Built-in ROS 2 security features enable control over communications throughout the ROS graph. +This not only allows for encrypting data in transit between ROS domain participants, but also enables authentication of participants sending data, ensures the integrity of data being sent, and enables domain-wide access controls. + +ROS 2 security services are provided by the underlying `Data Distribution Service (DDS) `_ which is used for communications between nodes. +DDS vendors provide open source and commercial DDS implementations that work with ROS. +However, in order to create a specification-compliant implementation of DDS, all vendors must include security plugins as outlined in the `DDS Security Specification `_. +ROS security features take advantage of these DDS security plugins to provide policy-based encryption, authentication and access control. +DDS and ROS security is enabled through predefined configuration files and environment variables. + + +The Security Enclave +-------------------- + +A security enclave encapsulates a single policy for protecting ROS communications. +The enclave may set policy for multiple nodes, for an entire ROS graph, or any combination of protected ROS processes and devices. +Security enclaves can be flexibly mapped to processes, users, or devices at deployment. +Adjusting this default behavior becomes important for optimizing communications and for complex systems. +See the ROS 2 Security Enclaves `design document `_ for additional details. + + +Security Files +-------------- + +A `ROS 2 security enclave `_ is established with six files as outlined by the DDS specification. +Three of these files define an enclave's identity, while three other files define the permissions to be granted to the enclave. +All six files reside in a single directory, and nodes launched without a qualified enclave path use files in the default root level enclave. + +Enclave Identity +^^^^^^^^^^^^^^^^ + +The Identity Certificate Authority file ``identity_ca.cert.pem`` acts as the trust anchor used to identify participants. +Each enclave also holds its unique identifying certificate in the file ``cert.pem``, and the associated private key in the file ``key.pem``. +Because the ``cert.pem`` certificate has been signed by identity certificate, when a participant presents this certificate to other domain members, they are able to validate the participant's identity using their own copy of the identity certificate. +This valid certificate exchange allows the enclave to securely establish trusted communications with other participants. +The enclave does not not share the ``key.pem`` private key, but only uses it for decryption and message signing. + +Enclave Permissions +^^^^^^^^^^^^^^^^^^^ + +The Permissions Certificate Authority file ``permissions_ca.cert.pem`` serves as the trust anchor to grant permissions to security enclaves. +This certificate is used to create the signed file ``governance.p7s``, an XML document which defines domain-wide protection policies. +Similarly the XML file ``permissions.p7s`` outlines permissions of this particular enclave and has been signed by the Permissions CA. +Domain members use a copy of the permissions CA to validate these signed files and grant the requested access. + +Although these two certificate authorities enable separate workflows for identity and permissions, often the same certificate serves as both the identity and the permissions authority. + +Private Keys +^^^^^^^^^^^^ + +The identity and permissions certificates also have associated private key files. +Add new enclaves to the domain by signing their Certificate Signing Request (CSR) with the identity certificate's private key. +Similarly, grant permissions for a new enclave by signing a permissions XML document with the permission certificate's private key. + + +Security Environment Variables +------------------------------ + +The environment variable ``ROS_SECURITY_ENABLE`` acts as the enclave's master "on/off" switch for ROS 2 security features. +Security has been turned off by default, so security features will not be enabled even when the proper security files are present. +In order to enable ROS 2 security, set this environment variable to ``true`` (case sensitive). + +Once security has been enabled, the environment variable ``ROS_SECURITY_STRATEGY`` defines how domain participants handle problems when launching participants. +Security features depend on certificates and properly signed configuration files, yet by default, an improperly configured participant will still launch successfully but without security features. +In order to enforce strict compliance with security settings and fail to launch non-compliant enclaves, set this environment variable to ``Enforce`` (case sensitive). + +Additional security-related environment variables can be found in the `ROS 2 DDS-Security Integration design document `_. +These variables generally assist ROS in managing enclaves and locating the security files. + + +Learn More +---------- + +For more information and hands-on exercises enabling ROS 2 communications security, see the :doc:`Security/Introducing-ros2-security`. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst b/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst index a1e5a4e8c1c..69ba3b4ba5c 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst @@ -1,767 +1,768 @@ -.. redirect-from:: - - Discovery-Server - Tutorials/Discovery-Server/Discovery-Server - -Using Fast DDS Discovery Server as discovery protocol [community-contributed] -============================================================================= - -**Goal:** This tutorial will show how to launch ROS 2 Nodes using the **Fast DDS Discovery Server** discovery protocol. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -Starting from ROS 2 Eloquent Elusor, the **Fast DDS Discovery Server** protocol is a feature that offers a centralized dynamic discovery mechanism, as opposed to the distributed mechanism used in DDS by default. -This tutorial explains how to run some ROS 2 examples using the Fast DDS Discovery Server feature as discovery communication. - -In order to get more information about the available discovery configuration, please check the `following documentation `_ or read the `Fast DDS Discovery Server specific documentation `__. - -The `Simple Discovery Protocol `__ is the standard protocol defined in the `DDS standard `__. -However, it has known disadvantages in some scenarios. - -* It does not **scale** efficiently, as the number of exchanged packets increases significantly as new nodes are added. -* It requires **multicasting** capabilities that may not work reliably in some scenarios, e.g. WiFi. - -The **Fast DDS Discovery Server** provides a Client-Server Architecture that allows nodes to connect with each other using an intermediate server. -Each node functions as a *discovery client*, sharing its info with one or more *discovery servers* and receiving discovery information from it. -This reduces discovery-related network traffic and it does not require multicasting capabilities. - -.. image:: figures/ds_explanation.svg - :align: center - -These discovery servers can be independent, duplicated or connected with each other in order to create redundancy over the network and avoid having a single point of failure. - -Fast DDS Discovery Server v2 ----------------------------- - -The latest ROS 2 Foxy Fitzroy release (December 2020) included a new version, version 2 of the Fast DDS Discovery Server. -This version includes a new filter feature that further reduces the number of discovery messages sent. -This version uses the topic of the different nodes to decide if two nodes wish to communicate, or if they can be left unmatched (i.e. not discovering each other). -The following figure shows the decrease in discovery messages: - -.. image:: figures/ds1vs2.svg - :align: center - -This architecture reduces the number of messages sent between the server and clients dramatically. -In the following graph, the reduction in network traffic over the discovery phase for the `RMF Clinic demonstration `__ is shown: - -.. image:: figures/discovery_server_v2_performance.svg - :align: center - - -In order to use this functionality, the discovery server can be configured using the `XML configuration for Participants `__. -It is also possible to configure the discovery server using the ``fastdds`` `tool `__ and an `environment variable `__, which is the approach used in this tutorial. -For a more detailed explanation about the configuration of the discovery server, visit `the Fast DDS Discovery Server documentation `__. - - -Prerequisites -------------- - -This tutorial assumes you have a ROS 2 Foxy (or newer) :doc:`installation <../../../Installation>`. -If your installation is using a ROS 2 version lower than Foxy, you cannot use the ``fastdds`` tool. -Thus, in order to use the Discovery Server, you can update your repository to use a different Fast DDS version, or configure the discovery server using the `Fast DDS XML QoS configuration `__. - - -Run this tutorial ------------------ - -The ``talker-listener`` ROS 2 demo creates a ``talker`` node that publishes a "hello world" message every second, and a ``listener`` node that listens to these messages. - -By :doc:`sourcing ROS 2 <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>` you will get access to the CLI tool ``fastdds``. -This tool gives access to the `discovery tool `__, which can be used to launch a discovery server. -This server will manage the discovery process for the nodes that connect to it. - -.. important:: - - Do not forget to :doc:`source ROS 2 <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>` in every new terminal opened. - - -Setup Discovery Server -^^^^^^^^^^^^^^^^^^^^^^ - -Start by launching a discovery server with id 0, port 11811 (default port) and listening on all available interfaces. - -Open a new terminal and run: - -.. code-block:: console - - $ fastdds discovery --server-id 0 - - -Launch listener node -^^^^^^^^^^^^^^^^^^^^ - -Execute the listener demo, to listen to the ``/chatter`` topic. - -In a new terminal, set the environment variable ``ROS_DISCOVERY_SERVER`` to the location of the discovery server. -(Do not forget to source ROS 2 in every new terminal) - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER=127.0.0.1:11811 - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER=127.0.0.1:11811 - -Launch the listener node. -Use the argument ``--remap __node:=listener_discovery_server`` to change the node's name for this tutorial. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_discovery_server - -This will create a ROS 2 node, that will automatically create a client for the discovery server and connect to the server created previously to perform discovery, rather than using multicast. - - -Launch talker node -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and set the ``ROS_DISCOVERY_SERVER`` environment variable as before so that the node starts a discovery client. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER=127.0.0.1:11811 - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER=127.0.0.1:11811 - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_discovery_server - -You should now see the talker publishing "hello world" messages, and the listener receiving these messages. - - -Demonstrate Discovery Server execution -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -So far, there is no evidence that this example and the standard talker-listener example are running differently. -To clearly demonstrate this, run another node that is not connected to the discovery server. -Run a new listener (listening in ``/chatter`` topic by default) in a new terminal and check that it is not connected to the talker already running. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=simple_listener - -The new listener node should not be receiving the "hello world" messages. - -To finally verify that everything is running correctly, a new talker can be created using the simple discovery protocol (the default DDS distributed discovery mechanism) for discovery. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=simple_talker - -Now you should see the ``simple_listener`` node receiving the "hello world" messages from ``simple_talker`` but not the other messages from ``talker_discovery_server``. - - -Visualization tool ``rqt_graph`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``rqt_graph`` tool can be used to verify the nodes and structure of this example. -Remember, in order to use ``rqt_graph`` with the discovery server protocol (i.e., to see the ``listener_discovery_server`` and ``talker_discovery_server`` nodes) the ``ROS_DISCOVERY_SERVER`` environment variable must be set before launching it. - - -Advanced use cases ------------------- - -The following sections show different features of the discovery server that allow you to build a robust discovery server over the network. - -Server Redundancy -^^^^^^^^^^^^^^^^^ - -By using ``fastdds`` tool, multiple discovery servers can be created. -Discovery clients (ROS nodes) can connect to as many servers as desired. -This allows us to have a redundant network that will work even if some servers or nodes shut down unexpectedly. -The figure below shows a simple architecture that provides server redundancy. - -.. image:: figures/ds_redundancy_example.svg - :align: center - -In several terminals, run the following code to establish a communication with redundant servers. - -.. code-block:: console - - $ fastdds discovery --server-id 0 --udp-address 127.0.0.1 --udp-port 11811 - -.. code-block:: console - - $ fastdds discovery --server-id 1 --udp-address 127.0.0.1 --udp-port 11888 - -``--server-id N`` means server with id N. When referencing the servers with ``ROS_DISCOVERY_SERVER``, server ``0`` must be in first place and server ``1`` in second place. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener - -Now, if one of these servers fails, there will still be discovery capability available and nodes will still discover each other. - - -Backup Server -^^^^^^^^^^^^^ - -The Fast DDS Discovery Server allows creating a server with backup functionality. -This allows the server to restore the last state it saved in case of a shutdown. - -.. image:: figures/ds_backup_example.svg - :align: center - -In different terminals, run the following code to establish a communication with a backed-up server. - -.. code-block:: console - - $ fastdds discovery --server-id 0 --udp-address 127.0.0.1 --udp-port 11811 --backup - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener - -Several backup files are created in the discovery server's working directory (the directory it was launched in). -The two ``SQLite`` files and two ``json`` files contain the information required to start a new server and restore the failed server's state in case of failure, avoiding the need for the discovery process to happen again, and without losing information. - - -Discovery partitions -^^^^^^^^^^^^^^^^^^^^ - -Communication with discovery servers can be split to create virtual partitions in the discovery information. -This means that two endpoints will only know about each other if there is a shared discovery server or a network of discovery servers between them. -We are going to execute an example with two independent servers. -The following figure shows the architecture. - -.. image:: figures/ds_partition_example.svg - :align: center - -With this schema ``Listener 1`` will be connected to ``Talker 1`` and ``Talker 2``, as they share ``Server 1``. -``Listener 2`` will connect with ``Talker 1`` as they share ``Server 2``. -But ``Listener 2`` will not hear the messages from ``Talker 2`` because they do not share any discovery server or discovery servers, including indirectly via connections between redundant discovery servers. - -Run the first server listening on localhost with the default port of 11811. - -.. code-block:: console - - $ fastdds discovery --server-id 0 --udp-address 127.0.0.1 --udp-port 11811 - -In another terminal run the second server listening on localhost using another port, in this case port 11888. - -.. code-block:: console - - $ fastdds discovery --server-id 1 --udp-address 127.0.0.1 --udp-port 11888 - -Now, run each node in a different terminal. -Use ``ROS_DISCOVERY_SERVER`` environment variable to decide which server they are connected to. -Be aware that the `ids must match `__. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_1 - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_1 - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_2 - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER=";127.0.0.1:11888" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER=";127.0.0.1:11888" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_2 - -We should see how ``Listener 1`` is receiving messages from both talker nodes, while ``Listener 2`` is in a different partition from ``Talker 2`` and so does not receive messages from it. - -.. note:: - - Once two endpoints (ROS nodes) have discovered each other, they do not need the discovery server network between them to listen to each other's messages. - - -Large number of participants -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When running more than 100 DDS participants on a single host (e.g., launching more than 100 ROS 2 `contexts `__ simultaneously), participants may fail to discover each other and become unresponsive. -This applies to both the Discovery Server protocol and the Simple Discovery Protocol. - -.. note:: - - Each DDS *Participant* corresponds to a ROS 2 *Context*, not a ROS 2 *Node*. - Multiple nodes can share a single context, and each process typically creates one context by default. - Therefore, the number of participants depends on the number of processes (contexts), not the number of nodes. - -The root cause is the ``mutation_tries`` parameter in Fast DDS, which defaults to ``100``. -This parameter controls how many attempts Fast DDS makes to find a unique unicast listening port for each participant. -When the number of participants exceeds ``mutation_tries``, port allocation is exhausted and new participants cannot listen for incoming traffic, effectively becoming deaf. - -.. warning:: - - Having more than 119 participants on the same host within a single domain will cause their listening ports to collide with those of the next domain ID. - -To support more participants, increase ``mutation_tries`` by applying the following XML configuration via the ``FASTDDS_DEFAULT_PROFILES_FILE`` environment variable: - -.. code-block:: xml - - - - - - - - 1000 - - - - - - -Save this file (e.g. as ``large_scale_configuration.xml``) and set the environment variable before launching your nodes: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export FASTDDS_DEFAULT_PROFILES_FILE=large_scale_configuration.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ set FASTDDS_DEFAULT_PROFILES_FILE=large_scale_configuration.xml - -.. note:: - - The ``mutation_tries`` value should be set to at least the number of participants you intend to run on a single host. - Increasing it beyond what is needed has no negative side effects. - This configuration must be applied to **all** participants in the system, except the discovery server, for which a specific unicast port is already configured at launch. - -For more details, see the `Fast DDS documentation on participant configuration `__. - - -ROS 2 Introspection -------------------- - -The `ROS 2 Command Line Interface `__ supports several introspection tools to analyze the behavior of a ROS 2 network. -These tools (i.e. ``ros2 bag record``, ``ros2 topic list``, etc.) are very helpful to understand a ROS 2 working network. - -Most of these tools use DDS simple discovery to exchange topic information with every existing participant (using simple discovery, every participant in the network is connected with each other). -However, the new Discovery Server v2 implements a network traffic reduction scheme that limits the discovery data between participants that do not share a topic. -This means that nodes will only receive topic's discovery data if it has a writer or a reader for that topic. -As most ROS 2 CLIs need a node in the network (some of them rely on a running ROS 2 daemon, and some create their own nodes), using the Discovery Server v2 these nodes will not have all the network information, and thus their functionality will be limited. - -The Discovery Server v2 functionality allows every Participant to run as a **Super Client**, a kind of **Client** that connects to a **Server**, from which it receives all the available discovery information (instead of just what it needs). -In this sense, ROS 2 introspection tools can be configured as **Super Client**, thus being able to discover every entity that is using the Discovery Server protocol within the network. - -.. note:: - - In this section we use the term *Participant* as a DDS entity. - Each DDS *Participant* corresponds with a ROS 2 *Context*, a ROS 2 abstraction over DDS. - `Nodes ` are ROS 2 entities that rely on DDS communication interfaces: ``DataWriter`` and ``DataReader``. - Each *Participant* can hold multiple ROS 2 Nodes. - For further details about these concepts, please visit the `Node to Participant mapping design document `__ - - -Daemon's related tools -^^^^^^^^^^^^^^^^^^^^^^ - -The ROS 2 Daemon is used in several ROS 2 CLI introspection tools. -It creates its own Participant to add a ROS 2 Node to the network graph, in order to receive all the data sent. -In order for the ROS 2 CLI to work when using the Discovery Server mechanism, the ROS 2 Daemon needs to be -configured as **Super Client**. -Therefore, this section is devoted to explain how to use ROS 2 CLI with ROS 2 Daemon running as a **Super Client**. -This will allow the Daemon to discover the entire Node graph, and to receive all topic and endpoint information. -To do so, a Fast DDS XML configuration file is used to configure the ROS 2 Daemon and CLI tools. - -Below you can find a XML configuration profile, which for this tutorial should be saved in the working directory as ``super_client_configuration_file.xml`` file. -This file will configure every new participant using it, as a **Super Client**. - -.. code-block:: xml - - - - - - - - - SUPER_CLIENT - - - - - -
127.0.0.1
- 11811 - - - - - - - - - - - - - -.. note:: - - Under the *RemoteServer* tag, the *prefix* attribute value should be updated according to the server ID passed on the CLI (see `Fast DDS CLI `__). - The value specified in the shown XML snippet corresponds to an ID of value 0. - -First of all, instantiate a Discovery Server using `Fast DDS CLI `__ specifying an ID of value 0. - -.. code-block:: console - - $ fastdds discovery -i 0 -l 127.0.0.1 -p 11811 - -Run a talker and a listener that will discover each other through the Server (notice that ``ROS_DISCOVERY_SERVER`` configuration is the same as the one in ``super_client_configuration_file.xml``). - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker - -Then, instantiate a ROS 2 Daemon using the **Super Client** configuration (remember to source ROS 2 installation in every new terminal). - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ set FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml - -.. code-block:: console - - $ ros2 daemon stop - $ ros2 daemon start - $ ros2 topic list - $ ros2 node info /talker - $ ros2 topic info /chatter - $ ros2 topic echo /chatter - -We can also see the Node's Graph using the ROS 2 tool ``rqt_graph`` as follows (you may need to press the refresh button): - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ set FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml - -.. code-block:: console - - $ ros2 run rqt_graph rqt_graph - - -No Daemon tools -^^^^^^^^^^^^^^^ - -Some ROS 2 CLI tools do not use the ROS 2 Daemon. -In order for these tools to connect with a Discovery Server and receive all the topic information they need to be instantiated as a **Super Client** that connects to the **Server**. - -Following the previous configuration, build a simple system with a talker and a listener. -First, run a **Server**: - -.. code-block:: console - - $ fastdds discovery -i 0 -l 127.0.0.1 -p 11811 - -Then, run the talker and listener in separate terminals: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker - -Continue using the ROS 2 CLI with ``--no-daemon`` option with the new configuration. -New nodes will connect with the existing Server and will know every topic. -Exporting ``ROS_DISCOVERY_SERVER`` is not needed as the ROS 2 tools will be configured through the ``FASTDDS_DEFAULT_PROFILES_FILE``. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ set FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml - -.. code-block:: console - - $ ros2 topic list --no-daemon - $ ros2 node info /talker --no-daemon --spin-time 2 - -Compare Fast DDS Discovery Server with Simple Discovery Protocol ----------------------------------------------------------------- - -In order to compare executing nodes using the *Simple Discovery* Protocol (the default DDS mechanism for distributed discovery) or the *Discovery Server*, two scripts that execute a talker and many listeners and analyze the network traffic during this time are provided. -For this experiment, ``tshark`` is required to be installed on your system. -The configuration file is mandatory in order to avoid using intraprocess mode. - -.. note:: - - These scripts are only supported on Linux, and require a discovery server closure feature that is only available from versions newer than the version provided in ROS 2 Foxy. - In order to use this functionality, compile ROS 2 with Fast DDS v2.1.0 or higher. - -These scripts' features are references for advanced purposes and their study is left to the user. - -* :download:`bash network traffic generator ` - -* :download:`python3 graph generator ` - -* :download:`XML configuration ` - -Run the bash script with the path to ``setup.bash`` file to source ROS 2 as an argument. -This will generate the traffic trace for simple discovery. -Execute the same script with second argument ``SERVER``. -It will generate the trace for using the discovery server. - -.. note:: - - Depending on your configuration of ``tcpdump``, this script may require ``sudo`` privileges to read traffic across your network device. - -After both executions are done, run the Python script to generate a graph similar to the one below. - -.. code-block:: console - - $ export FASTDDS_DEFAULT_PROFILES_FILE="no_intraprocess_configuration.xml" - $ sudo bash generate_discovery_packages.bash ~/ros2/install/local_setup.bash - $ sudo bash generate_discovery_packages.bash ~/ros2/install/local_setup.bash SERVER - $ python3 discovery_packets.py - -.. image:: figures/discovery_packets.svg - :align: center - -This graph is the result of a specific run of the experiment. -The reader can execute the scripts and generate their own results for comparison. -It can easily be seen that network traffic is reduced when using the discovery service. - -The reduction in traffic is a result of avoiding every node announcing itself and waiting for a response from every other node on the network. -This creates a huge amount of traffic in large architectures. -The reduction from this method increases with the number of nodes, making this architecture more scalable than the Simple Discovery Protocol approach. - -The new Fast DDS Discovery Server v2 is available since *Fast DDS* v2.0.2, replacing the old discovery server. -In this new version, those nodes that do not share topics will automatically not discover each other, saving the whole discovery data required to connect them and their endpoints. -The experiment above does not show this case, but even so the massive reduction in traffic can be appreciated due to the hidden infrastructure topics of ROS 2 nodes. +.. redirect-from:: + + Discovery-Server + Tutorials/Discovery-Server/Discovery-Server + Tutorials/Advanced/Discovery-Server/Discovery-Server + +Using Fast DDS Discovery Server as discovery protocol [community-contributed] +============================================================================= + +**Goal:** This tutorial will show how to launch ROS 2 Nodes using the **Fast DDS Discovery Server** discovery protocol. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +Starting from ROS 2 Eloquent Elusor, the **Fast DDS Discovery Server** protocol is a feature that offers a centralized dynamic discovery mechanism, as opposed to the distributed mechanism used in DDS by default. +This tutorial explains how to run some ROS 2 examples using the Fast DDS Discovery Server feature as discovery communication. + +In order to get more information about the available discovery configuration, please check the `following documentation `_ or read the `Fast DDS Discovery Server specific documentation `__. + +The `Simple Discovery Protocol `__ is the standard protocol defined in the `DDS standard `__. +However, it has known disadvantages in some scenarios. + +* It does not **scale** efficiently, as the number of exchanged packets increases significantly as new nodes are added. +* It requires **multicasting** capabilities that may not work reliably in some scenarios, e.g. WiFi. + +The **Fast DDS Discovery Server** provides a Client-Server Architecture that allows nodes to connect with each other using an intermediate server. +Each node functions as a *discovery client*, sharing its info with one or more *discovery servers* and receiving discovery information from it. +This reduces discovery-related network traffic and it does not require multicasting capabilities. + +.. image:: figures/ds_explanation.svg + :align: center + +These discovery servers can be independent, duplicated or connected with each other in order to create redundancy over the network and avoid having a single point of failure. + +Fast DDS Discovery Server v2 +---------------------------- + +The latest ROS 2 Foxy Fitzroy release (December 2020) included a new version, version 2 of the Fast DDS Discovery Server. +This version includes a new filter feature that further reduces the number of discovery messages sent. +This version uses the topic of the different nodes to decide if two nodes wish to communicate, or if they can be left unmatched (i.e. not discovering each other). +The following figure shows the decrease in discovery messages: + +.. image:: figures/ds1vs2.svg + :align: center + +This architecture reduces the number of messages sent between the server and clients dramatically. +In the following graph, the reduction in network traffic over the discovery phase for the `RMF Clinic demonstration `__ is shown: + +.. image:: figures/discovery_server_v2_performance.svg + :align: center + + +In order to use this functionality, the discovery server can be configured using the `XML configuration for Participants `__. +It is also possible to configure the discovery server using the ``fastdds`` `tool `__ and an `environment variable `__, which is the approach used in this tutorial. +For a more detailed explanation about the configuration of the discovery server, visit `the Fast DDS Discovery Server documentation `__. + + +Prerequisites +------------- + +This tutorial assumes you have a ROS 2 Foxy (or newer) :doc:`installation <../../../Get-Started/Installation>`. +If your installation is using a ROS 2 version lower than Foxy, you cannot use the ``fastdds`` tool. +Thus, in order to use the Discovery Server, you can update your repository to use a different Fast DDS version, or configure the discovery server using the `Fast DDS XML QoS configuration `__. + + +Run this tutorial +----------------- + +The ``talker-listener`` ROS 2 demo creates a ``talker`` node that publishes a "hello world" message every second, and a ``listener`` node that listens to these messages. + +By :doc:`sourcing ROS 2 <../../../Get-Started/Configuring-ROS2-Environment>` you will get access to the CLI tool ``fastdds``. +This tool gives access to the `discovery tool `__, which can be used to launch a discovery server. +This server will manage the discovery process for the nodes that connect to it. + +.. important:: + + Do not forget to :doc:`source ROS 2 <../../../Get-Started/Configuring-ROS2-Environment>` in every new terminal opened. + + +Setup Discovery Server +^^^^^^^^^^^^^^^^^^^^^^ + +Start by launching a discovery server with id 0, port 11811 (default port) and listening on all available interfaces. + +Open a new terminal and run: + +.. code-block:: console + + $ fastdds discovery --server-id 0 + + +Launch listener node +^^^^^^^^^^^^^^^^^^^^ + +Execute the listener demo, to listen to the ``/chatter`` topic. + +In a new terminal, set the environment variable ``ROS_DISCOVERY_SERVER`` to the location of the discovery server. +(Do not forget to source ROS 2 in every new terminal) + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER=127.0.0.1:11811 + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER=127.0.0.1:11811 + +Launch the listener node. +Use the argument ``--remap __node:=listener_discovery_server`` to change the node's name for this tutorial. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_discovery_server + +This will create a ROS 2 node, that will automatically create a client for the discovery server and connect to the server created previously to perform discovery, rather than using multicast. + + +Launch talker node +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and set the ``ROS_DISCOVERY_SERVER`` environment variable as before so that the node starts a discovery client. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER=127.0.0.1:11811 + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER=127.0.0.1:11811 + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_discovery_server + +You should now see the talker publishing "hello world" messages, and the listener receiving these messages. + + +Demonstrate Discovery Server execution +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +So far, there is no evidence that this example and the standard talker-listener example are running differently. +To clearly demonstrate this, run another node that is not connected to the discovery server. +Run a new listener (listening in ``/chatter`` topic by default) in a new terminal and check that it is not connected to the talker already running. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=simple_listener + +The new listener node should not be receiving the "hello world" messages. + +To finally verify that everything is running correctly, a new talker can be created using the simple discovery protocol (the default DDS distributed discovery mechanism) for discovery. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=simple_talker + +Now you should see the ``simple_listener`` node receiving the "hello world" messages from ``simple_talker`` but not the other messages from ``talker_discovery_server``. + + +Visualization tool ``rqt_graph`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``rqt_graph`` tool can be used to verify the nodes and structure of this example. +Remember, in order to use ``rqt_graph`` with the discovery server protocol (i.e., to see the ``listener_discovery_server`` and ``talker_discovery_server`` nodes) the ``ROS_DISCOVERY_SERVER`` environment variable must be set before launching it. + + +Advanced use cases +------------------ + +The following sections show different features of the discovery server that allow you to build a robust discovery server over the network. + +Server Redundancy +^^^^^^^^^^^^^^^^^ + +By using ``fastdds`` tool, multiple discovery servers can be created. +Discovery clients (ROS nodes) can connect to as many servers as desired. +This allows us to have a redundant network that will work even if some servers or nodes shut down unexpectedly. +The figure below shows a simple architecture that provides server redundancy. + +.. image:: figures/ds_redundancy_example.svg + :align: center + +In several terminals, run the following code to establish a communication with redundant servers. + +.. code-block:: console + + $ fastdds discovery --server-id 0 --udp-address 127.0.0.1 --udp-port 11811 + +.. code-block:: console + + $ fastdds discovery --server-id 1 --udp-address 127.0.0.1 --udp-port 11888 + +``--server-id N`` means server with id N. When referencing the servers with ``ROS_DISCOVERY_SERVER``, server ``0`` must be in first place and server ``1`` in second place. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener + +Now, if one of these servers fails, there will still be discovery capability available and nodes will still discover each other. + + +Backup Server +^^^^^^^^^^^^^ + +The Fast DDS Discovery Server allows creating a server with backup functionality. +This allows the server to restore the last state it saved in case of a shutdown. + +.. image:: figures/ds_backup_example.svg + :align: center + +In different terminals, run the following code to establish a communication with a backed-up server. + +.. code-block:: console + + $ fastdds discovery --server-id 0 --udp-address 127.0.0.1 --udp-port 11811 --backup + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener + +Several backup files are created in the discovery server's working directory (the directory it was launched in). +The two ``SQLite`` files and two ``json`` files contain the information required to start a new server and restore the failed server's state in case of failure, avoiding the need for the discovery process to happen again, and without losing information. + + +Discovery partitions +^^^^^^^^^^^^^^^^^^^^ + +Communication with discovery servers can be split to create virtual partitions in the discovery information. +This means that two endpoints will only know about each other if there is a shared discovery server or a network of discovery servers between them. +We are going to execute an example with two independent servers. +The following figure shows the architecture. + +.. image:: figures/ds_partition_example.svg + :align: center + +With this schema ``Listener 1`` will be connected to ``Talker 1`` and ``Talker 2``, as they share ``Server 1``. +``Listener 2`` will connect with ``Talker 1`` as they share ``Server 2``. +But ``Listener 2`` will not hear the messages from ``Talker 2`` because they do not share any discovery server or discovery servers, including indirectly via connections between redundant discovery servers. + +Run the first server listening on localhost with the default port of 11811. + +.. code-block:: console + + $ fastdds discovery --server-id 0 --udp-address 127.0.0.1 --udp-port 11811 + +In another terminal run the second server listening on localhost using another port, in this case port 11888. + +.. code-block:: console + + $ fastdds discovery --server-id 1 --udp-address 127.0.0.1 --udp-port 11888 + +Now, run each node in a different terminal. +Use ``ROS_DISCOVERY_SERVER`` environment variable to decide which server they are connected to. +Be aware that the `ids must match `__. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_1 + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811;127.0.0.1:11888" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_1 + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker_2 + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER=";127.0.0.1:11888" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER=";127.0.0.1:11888" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener_2 + +We should see how ``Listener 1`` is receiving messages from both talker nodes, while ``Listener 2`` is in a different partition from ``Talker 2`` and so does not receive messages from it. + +.. note:: + + Once two endpoints (ROS nodes) have discovered each other, they do not need the discovery server network between them to listen to each other's messages. + + +Large number of participants +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When running more than 100 DDS participants on a single host (e.g., launching more than 100 ROS 2 `contexts `__ simultaneously), participants may fail to discover each other and become unresponsive. +This applies to both the Discovery Server protocol and the Simple Discovery Protocol. + +.. note:: + + Each DDS *Participant* corresponds to a ROS 2 *Context*, not a ROS 2 *Node*. + Multiple nodes can share a single context, and each process typically creates one context by default. + Therefore, the number of participants depends on the number of processes (contexts), not the number of nodes. + +The root cause is the ``mutation_tries`` parameter in Fast DDS, which defaults to ``100``. +This parameter controls how many attempts Fast DDS makes to find a unique unicast listening port for each participant. +When the number of participants exceeds ``mutation_tries``, port allocation is exhausted and new participants cannot listen for incoming traffic, effectively becoming deaf. + +.. warning:: + + Having more than 119 participants on the same host within a single domain will cause their listening ports to collide with those of the next domain ID. + +To support more participants, increase ``mutation_tries`` by applying the following XML configuration via the ``FASTDDS_DEFAULT_PROFILES_FILE`` environment variable: + +.. code-block:: xml + + + + + + + + 1000 + + + + + + +Save this file (e.g. as ``large_scale_configuration.xml``) and set the environment variable before launching your nodes: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export FASTDDS_DEFAULT_PROFILES_FILE=large_scale_configuration.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ set FASTDDS_DEFAULT_PROFILES_FILE=large_scale_configuration.xml + +.. note:: + + The ``mutation_tries`` value should be set to at least the number of participants you intend to run on a single host. + Increasing it beyond what is needed has no negative side effects. + This configuration must be applied to **all** participants in the system, except the discovery server, for which a specific unicast port is already configured at launch. + +For more details, see the `Fast DDS documentation on participant configuration `__. + + +ROS 2 Introspection +------------------- + +The `ROS 2 Command Line Interface `__ supports several introspection tools to analyze the behavior of a ROS 2 network. +These tools (i.e. ``ros2 bag record``, ``ros2 topic list``, etc.) are very helpful to understand a ROS 2 working network. + +Most of these tools use DDS simple discovery to exchange topic information with every existing participant (using simple discovery, every participant in the network is connected with each other). +However, the new Discovery Server v2 implements a network traffic reduction scheme that limits the discovery data between participants that do not share a topic. +This means that nodes will only receive topic's discovery data if it has a writer or a reader for that topic. +As most ROS 2 CLIs need a node in the network (some of them rely on a running ROS 2 daemon, and some create their own nodes), using the Discovery Server v2 these nodes will not have all the network information, and thus their functionality will be limited. + +The Discovery Server v2 functionality allows every Participant to run as a **Super Client**, a kind of **Client** that connects to a **Server**, from which it receives all the available discovery information (instead of just what it needs). +In this sense, ROS 2 introspection tools can be configured as **Super Client**, thus being able to discover every entity that is using the Discovery Server protocol within the network. + +.. note:: + + In this section we use the term *Participant* as a DDS entity. + Each DDS *Participant* corresponds with a ROS 2 *Context*, a ROS 2 abstraction over DDS. + `Nodes ` are ROS 2 entities that rely on DDS communication interfaces: ``DataWriter`` and ``DataReader``. + Each *Participant* can hold multiple ROS 2 Nodes. + For further details about these concepts, please visit the `Node to Participant mapping design document `__ + + +Daemon's related tools +^^^^^^^^^^^^^^^^^^^^^^ + +The ROS 2 Daemon is used in several ROS 2 CLI introspection tools. +It creates its own Participant to add a ROS 2 Node to the network graph, in order to receive all the data sent. +In order for the ROS 2 CLI to work when using the Discovery Server mechanism, the ROS 2 Daemon needs to be +configured as **Super Client**. +Therefore, this section is devoted to explain how to use ROS 2 CLI with ROS 2 Daemon running as a **Super Client**. +This will allow the Daemon to discover the entire Node graph, and to receive all topic and endpoint information. +To do so, a Fast DDS XML configuration file is used to configure the ROS 2 Daemon and CLI tools. + +Below you can find a XML configuration profile, which for this tutorial should be saved in the working directory as ``super_client_configuration_file.xml`` file. +This file will configure every new participant using it, as a **Super Client**. + +.. code-block:: xml + + + + + + + + + SUPER_CLIENT + + + + + +
127.0.0.1
+ 11811 + + + + + + + + + + + + + +.. note:: + + Under the *RemoteServer* tag, the *prefix* attribute value should be updated according to the server ID passed on the CLI (see `Fast DDS CLI `__). + The value specified in the shown XML snippet corresponds to an ID of value 0. + +First of all, instantiate a Discovery Server using `Fast DDS CLI `__ specifying an ID of value 0. + +.. code-block:: console + + $ fastdds discovery -i 0 -l 127.0.0.1 -p 11811 + +Run a talker and a listener that will discover each other through the Server (notice that ``ROS_DISCOVERY_SERVER`` configuration is the same as the one in ``super_client_configuration_file.xml``). + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker + +Then, instantiate a ROS 2 Daemon using the **Super Client** configuration (remember to source ROS 2 installation in every new terminal). + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ set FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml + +.. code-block:: console + + $ ros2 daemon stop + $ ros2 daemon start + $ ros2 topic list + $ ros2 node info /talker + $ ros2 topic info /chatter + $ ros2 topic echo /chatter + +We can also see the Node's Graph using the ROS 2 tool ``rqt_graph`` as follows (you may need to press the refresh button): + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ set FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml + +.. code-block:: console + + $ ros2 run rqt_graph rqt_graph + + +No Daemon tools +^^^^^^^^^^^^^^^ + +Some ROS 2 CLI tools do not use the ROS 2 Daemon. +In order for these tools to connect with a Discovery Server and receive all the topic information they need to be instantiated as a **Super Client** that connects to the **Server**. + +Following the previous configuration, build a simple system with a talker and a listener. +First, run a **Server**: + +.. code-block:: console + + $ fastdds discovery -i 0 -l 127.0.0.1 -p 11811 + +Then, run the talker and listener in separate terminals: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener --ros-args --remap __node:=listener + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISCOVERY_SERVER="127.0.0.1:11811" + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISCOVERY_SERVER="127.0.0.1:11811" + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --remap __node:=talker + +Continue using the ROS 2 CLI with ``--no-daemon`` option with the new configuration. +New nodes will connect with the existing Server and will know every topic. +Exporting ``ROS_DISCOVERY_SERVER`` is not needed as the ROS 2 tools will be configured through the ``FASTDDS_DEFAULT_PROFILES_FILE``. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ set FASTDDS_DEFAULT_PROFILES_FILE=super_client_configuration_file.xml + +.. code-block:: console + + $ ros2 topic list --no-daemon + $ ros2 node info /talker --no-daemon --spin-time 2 + +Compare Fast DDS Discovery Server with Simple Discovery Protocol +---------------------------------------------------------------- + +In order to compare executing nodes using the *Simple Discovery* Protocol (the default DDS mechanism for distributed discovery) or the *Discovery Server*, two scripts that execute a talker and many listeners and analyze the network traffic during this time are provided. +For this experiment, ``tshark`` is required to be installed on your system. +The configuration file is mandatory in order to avoid using intraprocess mode. + +.. note:: + + These scripts are only supported on Linux, and require a discovery server closure feature that is only available from versions newer than the version provided in ROS 2 Foxy. + In order to use this functionality, compile ROS 2 with Fast DDS v2.1.0 or higher. + +These scripts' features are references for advanced purposes and their study is left to the user. + +* :download:`bash network traffic generator ` + +* :download:`python3 graph generator ` + +* :download:`XML configuration ` + +Run the bash script with the path to ``setup.bash`` file to source ROS 2 as an argument. +This will generate the traffic trace for simple discovery. +Execute the same script with second argument ``SERVER``. +It will generate the trace for using the discovery server. + +.. note:: + + Depending on your configuration of ``tcpdump``, this script may require ``sudo`` privileges to read traffic across your network device. + +After both executions are done, run the Python script to generate a graph similar to the one below. + +.. code-block:: console + + $ export FASTDDS_DEFAULT_PROFILES_FILE="no_intraprocess_configuration.xml" + $ sudo bash generate_discovery_packages.bash ~/ros2/install/local_setup.bash + $ sudo bash generate_discovery_packages.bash ~/ros2/install/local_setup.bash SERVER + $ python3 discovery_packets.py + +.. image:: figures/discovery_packets.svg + :align: center + +This graph is the result of a specific run of the experiment. +The reader can execute the scripts and generate their own results for comparison. +It can easily be seen that network traffic is reduced when using the discovery service. + +The reduction in traffic is a result of avoiding every node announcing itself and waiting for a response from every other node on the network. +This creates a huge amount of traffic in large architectures. +The reduction from this method increases with the number of nodes, making this architecture more scalable than the Simple Discovery Protocol approach. + +The new Fast DDS Discovery Server v2 is available since *Fast DDS* v2.0.2, replacing the old discovery server. +In this new version, those nodes that do not share topics will automatically not discover each other, saving the whole discovery data required to connect them and their endpoints. +The experiment above does not show this case, but even so the massive reduction in traffic can be appreciated due to the hidden infrastructure topics of ROS 2 nodes. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst b/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst index f5b53a71c06..3b109e00d73 100644 --- a/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst +++ b/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst @@ -1,802 +1,803 @@ -.. redirect-from:: - - FastDDS-Configuration - Tutorials/FastDDS-Configuration/FastDDS-Configuration - -Unlocking the potential of Fast DDS middleware [community-contributed] -====================================================================== - -**Goal:** This tutorial will show how to use the extended configuration capabilities of Fast DDS in ROS 2. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -The interface between the ROS 2 stack and *Fast DDS* is provided by the ROS 2 middleware implementation `rmw_fastrtps `_. -This implementation is available in all ROS 2 distributions, both from binaries and from sources. - -ROS 2 RMW only allows for the configuration of certain middleware QoS -(see :doc:`ROS 2 QoS policies <../../Concepts/Intermediate/About-Quality-of-Service-Settings>`). -However, ``rmw_fastrtps`` offers extended configuration capabilities to take full advantage of the features in *Fast DDS*. -This tutorial will guide you through a series of examples explaining how to use XML files to unlock this extended configuration. - -In order to get more information about using *Fast DDS* on ROS 2, please check the `following documentation `__. - - -Prerequisites -------------- - -This tutorial assumes that you know how to :doc:`create a package <../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. -It also assumes you know how to write a :doc:`simple publisher and subscriber<../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` and a :doc:`simple service and client <../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`. -Although the examples are implemented in C++, the same concepts apply to Python packages. - - -Mixing synchronous and asynchronous publications in the same node ------------------------------------------------------------------ - -In this first example, a node with two publishers, one of them with synchronous publication mode and the other one with asynchronous publication mode, will be created. - -``rmw_fastrtps`` uses synchronous publication mode by default. - -With synchronous publication mode the data is sent directly within the context of the user thread. -This entails that any blocking call occurring during the write operation would block the user thread, thus preventing the application from continuing its operation. -However, this mode typically yields higher throughput rates at lower latencies, since there is no notification nor context switching between threads. - -On the other hand, with asynchronous publication mode, each time the publisher invokes the write operation, the data is copied into a queue, -a background thread (asynchronous thread) is notified about the addition to the queue, and control of the thread is returned to the user before the data is actually sent. -The background thread is in charge of consuming the queue and sending the data to every matched reader. - -Create the node with the publishers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -First, create a new package named ``sync_async_node_example_cpp`` on a new workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ md \ros2_ws\src - $ cd \ros2_ws\src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp - - -Then, add a file named ``src/sync_async_writer.cpp`` to the package, with the following content. -Note that the synchronous publisher will be publishing on topic ``sync_topic``, while the asynchronous one will be publishing on topic ``async_topic``. - -.. code-block:: C++ - - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - - class SyncAsyncPublisher : public rclcpp::Node - { - public: - SyncAsyncPublisher() - : Node("sync_async_publisher"), count_(0) - { - // Create the synchronous publisher on topic 'sync_topic' - sync_publisher_ = this->create_publisher("sync_topic", 10); - - // Create the asynchronous publisher on topic 'async_topic' - async_publisher_ = this->create_publisher("async_topic", 10); - - // Actions to run every time the timer expires - auto timer_callback = [this](){ - - // Create a new message to be sent - auto sync_message = std_msgs::msg::String(); - sync_message.data = "SYNC: Hello, world! " + std::to_string(count_); - - // Log the message to the console to show progress - RCLCPP_INFO(this->get_logger(), "Synchronously publishing: '%s'", sync_message.data.c_str()); - - // Publish the message using the synchronous publisher - sync_publisher_->publish(sync_message); - - // Create a new message to be sent - auto async_message = std_msgs::msg::String(); - async_message.data = "ASYNC: Hello, world! " + std::to_string(count_); - - // Log the message to the console to show progress - RCLCPP_INFO(this->get_logger(), "Asynchronously publishing: '%s'", async_message.data.c_str()); - - // Publish the message using the asynchronous publisher - async_publisher_->publish(async_message); - - // Prepare the count for the next message - count_++; - }; - - // This timer will trigger the publication of new data every half a second - timer_ = this->create_wall_timer(500ms, timer_callback); - } - - private: - // This timer will trigger the publication of new data every half a second - rclcpp::TimerBase::SharedPtr timer_; - - // A publisher that publishes asynchronously - rclcpp::Publisher::SharedPtr async_publisher_; - - // A publisher that publishes synchronously - rclcpp::Publisher::SharedPtr sync_publisher_; - - // Number of messages sent so far - size_t count_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -Now open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncWriter`` so you can run your node using ``ros2 run``: - -.. code-block:: cmake - - add_executable(SyncAsyncWriter src/sync_async_writer.cpp) - target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: cmake - - install(TARGETS - SyncAsyncWriter - DESTINATION lib/${PROJECT_NAME}) - -You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(sync_async_node_example_cpp) - - # Default to C++14 - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 14) - endif() - - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - - add_executable(SyncAsyncWriter src/sync_async_writer.cpp) - target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - SyncAsyncWriter - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - -If this node is built and run now, both publishers will behave the same, publishing asynchronously in both topics, because this is the default publication mode. -The default publication mode configuration can be changed in runtime during the node launching, using an XML file. - -Create the XML file with the profile configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Create a file with name ``SyncAsync.xml`` and the following content: - -.. code-block:: XML - - - - - - - DYNAMIC - - - - - DYNAMIC - - - - - DYNAMIC - - - SYNCHRONOUS - - - - - - - DYNAMIC - - - ASYNCHRONOUS - - - - - - -Note that several profiles for publisher and subscriber are defined. -Two default profiles which are defined setting the ``is_default_profile`` to ``true``, and two profiles with names that coincide with those of the previously defined topics: ``sync_topic`` and another one for ``async_topic``. -These last two profiles set the publication mode to ``SYNCHRONOUS`` or ``ASYNCHRONOUS`` accordingly. -Note also that all profiles specify a ``historyMemoryPolicy`` value, which is needed for the example to work, and the reason will be explained later on this tutorial. - -Execute the publisher node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You will need to export the following environment variables for the XML to be loaded: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: macOS - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - -Finally, ensure you have sourced your setup files and run the node: - -.. code-block:: console - - $ source install/setup.bash - $ ros2 run sync_async_node_example_cpp SyncAsyncWriter - [INFO] [1612972049.994630332] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 0' - [INFO] [1612972049.995097767] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 0' - [INFO] [1612972050.494478706] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 1' - [INFO] [1612972050.494664334] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 1' - [INFO] [1612972050.994368474] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 2' - [INFO] [1612972050.994549851] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 2' - -Now you have a synchronous publisher and an asynchronous publisher running inside the same node. - - -Create a node with the subscribers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Next, a new node with the subscribers that will listen to the ``sync_topic`` and ``async_topic`` publications is going to be created. -In a new source file named ``src/sync_async_reader.cpp`` write the following content: - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - class SyncAsyncSubscriber : public rclcpp::Node - { - public: - - SyncAsyncSubscriber() - : Node("sync_async_subscriber") - { - // Lambda function to run every time a new message is received - auto topic_callback = [this](const std_msgs::msg::String & msg){ - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); - }; - - // Create the synchronous subscriber on topic 'sync_topic' - // and tie it to the topic_callback - sync_subscription_ = this->create_subscription( - "sync_topic", 10, topic_callback); - - // Create the asynchronous subscriber on topic 'async_topic' - // and tie it to the topic_callback - async_subscription_ = this->create_subscription( - "async_topic", 10, topic_callback); - } - - private: - - // A subscriber that listens to topic 'sync_topic' - rclcpp::Subscription::SharedPtr sync_subscription_; - - // A subscriber that listens to topic 'async_topic' - rclcpp::Subscription::SharedPtr async_subscription_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - -Open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncReader`` under the previous ``SyncAsyncWriter``: - -.. code-block:: cmake - - add_executable(SyncAsyncReader src/sync_async_reader.cpp) - target_link_libraries(SyncAsyncReader PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - SyncAsyncReader - DESTINATION lib/${PROJECT_NAME}) - - -Execute the subscriber node -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -With the publisher node running in one terminal, open another one and export the required environment variables for the XML to be loaded: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: macOS - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - -Finally, ensure you have sourced your setup files and run the node: - -.. code-block:: console - - $ source install/setup.bash - $ ros2 run sync_async_node_example_cpp SyncAsyncReader - [INFO] [1612972054.495429090] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 10' - [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' - [INFO] [1612972055.495453494] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 11' - [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' - [INFO] [1612972056.495534818] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 12' - [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' - - -Analysis of the example -^^^^^^^^^^^^^^^^^^^^^^^ - -Configuration profiles XML -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The XML file defines several configurations for publishers and subscribers. -You can have a default publisher configuration profile and several topic-specific publisher profiles. -The only requirement is that all publisher profiles have a different name and that there is only a single default profile. -The same goes for subscribers. - -In order to define a configuration for a specific topic, just name the profile after the the ROS 2 topic name (like ``/sync_topic`` and ``/async_topic`` in the example), -and ``rmw_fastrtps`` will apply this profile to all publishers and subscribers for that topic. -The default configuration profile is identified by the attribute ``is_default_profile`` set to ``true``, and acts as a fallback profile when there is no other one with a name matching the topic name. - -The environment variable ``FASTDDS_DEFAULT_PROFILES_FILE`` is used to inform *Fast DDS* the path to the XML file with the configuration profiles to load. - -RMW_FASTRTPS_USE_QOS_FROM_XML -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Among all the configurable attributes, ``rmw_fastrtps`` treats ``publishMode`` and ``historyMemoryPolicy`` differently. -By default, these values are set to ``ASYNCHRONOUS`` and ``PREALLOCATED_WITH_REALLOC`` within the ``rmw_fastrtps`` implementation, and the values set on the XML file are ignored. -In order to use the values in the XML file, the environment variable ``RMW_FASTRTPS_USE_QOS_FROM_XML`` must be set to ``1``. - -However, this entails **another caveat**: If ``RMW_FASTRTPS_USE_QOS_FROM_XML`` is set, but the XML file does not define -``publishMode`` or ``historyMemoryPolicy``, these attributes take the *Fast DDS* default value instead of the ``rmw_fastrtps`` default value. -This is important, especially for ``historyMemoryPolicy``, because the *Fast DDS* default value is ``PREALLOCATED`` which does not work with ROS2 topic data types. -Therefore, in the example, a valid value for this policy has been explicitly set (``DYNAMIC``). - - -Prioritization of rmw_qos_profile_t -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -ROS 2 QoS contained in `rmw_qos_profile_t `_ are always honored, unless set to ``*_SYSTEM_DEFAULT``. -In that case, XML values (or *Fast DDS* default values in the absence of XML ones) are applied. -This means that if any QoS in ``rmw_qos_profile_t`` is set to something other than ``*_SYSTEM_DEFAULT``, the corresponding value in the XML is ignored. - - -Using other FastDDS capabilities with XML ------------------------------------------ - -Although we have created a node with two publishers with different configuration, it is not easy to check that they are behaving differently. -Now that the basics of XML profiles have been covered, let us use them to configure something which has some visual effect on the nodes. -Specifically, a maximum number of matching subscribers on one of the publishers and a partition definition on the other will be set. -Note that these are only very simple examples among all the configuration attributes that can be tuned on ``rmw_fastrtps`` through XML files. -Please refer to `*Fast DDS* documentation `__ to see the whole list of attributes that can be configured through XML files. - -Limiting the number of matching subscribers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Add a maximum number of matched subscribers to the ``/async_topic`` publisher profile. -It should look like this: - -.. code-block:: XML - - - - DYNAMIC - - - ASYNCHRONOUS - - - - 0 - 1 - 1 - - - -The number of matching subscribers is being limited to one. - -Now open three terminals and do not forget to source the setup files and to set the required environment variables. -On the first terminal run the publisher node, and the subscriber node on the other two. -You should see that only the first subscriber node receives the messages from both topics. -The second one could not complete the matching process in the ``/async_topic`` because the publisher prevented it, as it had already reached its maximum of matched publishers. -Consequently, only the messages from the ``/sync_topic`` are going to be received in this third terminal: - -.. code-block:: console - - [INFO] [1613127657.088860890] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 18' - [INFO] [1613127657.588896594] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 19' - [INFO] [1613127658.088849401] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 20' - - -Using partitions within the topic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The partitions feature can be used to control which publishers and subscribers exchange information within the same topic. - -Partitions introduce a logical entity isolation level concept inside the physical isolation induced by a Domain ID. -For a publisher to communicate with a subscriber, they have to belong at least to one common partition. -Partitions represent another level to separate publishers and subscribers beyond domain and topic. -Unlike domain and topic, an endpoint can belong to several partitions at the same time. -For certain data to be shared over different domains or topics, there must be a different publisher for each, sharing its own history of changes. -However, a single publisher can share the same data sample over different partitions using a single topic data change, thus reducing network overload. - -Let us change the ``/sync_topic`` publisher to partition ``part1`` and create a new ``/sync_topic`` subscriber which uses partition ``part2``. -Their profiles should now look like this: - -.. code-block:: XML - - - - DYNAMIC - - - SYNCHRONOUS - - - - part1 - - - - - - - - DYNAMIC - - - - part2 - - - - - -Open two terminals. -Do not forget to source the setup files and to set the required environment variables. -On the first terminal run the publisher node, and the subscriber node on the other one. -You should see that only the ``/async_topic`` messages are reaching the subscriber. -The ``/sync_topic`` subscriber is not receiving the data as it is in a different partition from the corresponding publisher. - -.. code-block:: console - - [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' - [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' - [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' - - -Configuring a service and a client ----------------------------------- - -Services and clients have a publisher and a subscriber each, that communicate through two different topics. -For example, for a service named ``ping`` there is: - -* A service subscriber listening to requests on ``/rq/ping``. -* A service publisher sending responses on ``/rr/ping``. -* A client publisher sending requests on ``/rq/ping``. -* A client subscriber listening to responses on ``/rr/ping``. - -Although you can use these topic names to set the configuration profiles on the XML, sometimes you may wish to apply the same profile to all services or clients on a node. -Instead of copying the same profile with all topic names generated for all services, you can just create a publisher and subscriber profile pair named ``service``. -The same can be done for clients creating a pair named ``client``. - - -Create the nodes with the service and client -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Start creating the node with the service. -Add a new source file named ``src/ping_service.cpp`` on your package with the following content: - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - #include "example_interfaces/srv/trigger.hpp" - - /** - * Service action: responds with success=true and prints the request on the console - */ - void ping(const std::shared_ptr request, - std::shared_ptr response) - { - // The request data is unused - (void) request; - - // Build the response - response->success = true; - - // Log to the console - RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Incoming request"); - RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Sending back response"); - } - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - // Create the node and the service - std::shared_ptr node = rclcpp::Node::make_shared("ping_server"); - rclcpp::Service::SharedPtr service = - node->create_service("ping", &ping); - - // Log that the service is ready - RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Ready to serve."); - - // run the node - rclcpp::spin(node); - rclcpp::shutdown(); - } - -Create the client in a file named ``src/ping_client.cpp`` with the following content: - -.. code-block:: C++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "example_interfaces/srv/trigger.hpp" - - using namespace std::chrono_literals; - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - // Create the node and the client - std::shared_ptr node = rclcpp::Node::make_shared("ping_client"); - rclcpp::Client::SharedPtr client = - node->create_client("ping"); - - // Create a request - auto request = std::make_shared(); - - // Wait for the service to be available - while (!client->wait_for_service(1s)) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Interrupted while waiting for the service. Exiting."); - return 0; - } - RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Service not available, waiting again..."); - } - - // Now that the service is available, send the request - RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Sending request"); - auto result = client->async_send_request(request); - - // Wait for the result and log it to the console - if (rclcpp::spin_until_future_complete(node, result) == - rclcpp::FutureReturnCode::SUCCESS) - { - RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Response received"); - } else { - RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Failed to call service ping"); - } - - rclcpp::shutdown(); - return 0; - } - -Open the ``CMakeLists.txt`` file and add two new executables ``ping_service`` and ``ping_client``: - -.. code-block:: cmake - - find_package(example_interfaces REQUIRED) - - add_executable(ping_service src/ping_service.cpp) - target_link_libraries(ping_service PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) - - add_executable(ping_client src/ping_client.cpp) - target_link_libraries(ping_client PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) - - install(TARGETS - ping_service - DESTINATION lib/${PROJECT_NAME}) - - install(TARGETS - ping_client - DESTINATION lib/${PROJECT_NAME}) - -Finally, build the package. - - -Create the XML profiles for the service and client -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Create a file with name ``ping.xml`` with the following content: - -.. code-block:: XML - - - - - - - DYNAMIC - - - - - DYNAMIC - - - - - DYNAMIC - - - SYNCHRONOUS - - - - - - - DYNAMIC - - - ASYNCHRONOUS - - - - - - - -This configuration file sets the publication mode to ``SYNCHRONOUS`` on the service and to ``ASYNCHRONOUS`` on the client. -Note that we are only defining the publisher profiles for both the service and the client, but subscriber profiles could be provided too. - - -Execute the nodes -^^^^^^^^^^^^^^^^^ - -Open two terminals and source the setup files on each one. -Then set the required environment variables for the XML to be loaded: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml - - .. group-tab:: macOS - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml - - -On the first terminal run the service node. -You should see the service waiting for requests: - -.. code-block:: console - - $ ros2 run sync_async_node_example_cpp ping_service - [INFO] [1612977403.805799037] [ping_server]: Ready to serve. - -On the second terminal, run the client node. -You should see the client sending the request and receiving the response: - - -.. code-block:: console - - $ ros2 run sync_async_node_example_cpp ping_client - [INFO] [1612977404.805799037] [ping_client]: Sending request - [INFO] [1612977404.825473835] [ping_client]: Response received - -At the same time, the output in the server console has been updated: - -.. code-block:: console - - [INFO] [1612977403.805799037] [ping_server]: Ready to serve. - [INFO] [1612977404.807314904] [ping_server]: Incoming request - [INFO] [1612977404.836405125] [ping_server]: Sending back response +.. redirect-from:: + + FastDDS-Configuration + Tutorials/FastDDS-Configuration/FastDDS-Configuration + Tutorials/Advanced/FastDDS-Configuration + +Unlocking the potential of Fast DDS middleware [community-contributed] +====================================================================== + +**Goal:** This tutorial will show how to use the extended configuration capabilities of Fast DDS in ROS 2. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +The interface between the ROS 2 stack and *Fast DDS* is provided by the ROS 2 middleware implementation `rmw_fastrtps `_. +This implementation is available in all ROS 2 distributions, both from binaries and from sources. + +ROS 2 RMW only allows for the configuration of certain middleware QoS +(see :doc:`ROS 2 QoS policies <../../ROS-Framework/topics/About-Quality-of-Service-Settings>`). +However, ``rmw_fastrtps`` offers extended configuration capabilities to take full advantage of the features in *Fast DDS*. +This tutorial will guide you through a series of examples explaining how to use XML files to unlock this extended configuration. + +In order to get more information about using *Fast DDS* on ROS 2, please check the `following documentation `__. + + +Prerequisites +------------- + +This tutorial assumes that you know how to :doc:`create a package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`. +It also assumes you know how to write a :doc:`simple publisher and subscriber <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` and a :doc:`simple service and client <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`. +Although the examples are implemented in C++, the same concepts apply to Python packages. + + +Mixing synchronous and asynchronous publications in the same node +----------------------------------------------------------------- + +In this first example, a node with two publishers, one of them with synchronous publication mode and the other one with asynchronous publication mode, will be created. + +``rmw_fastrtps`` uses synchronous publication mode by default. + +With synchronous publication mode the data is sent directly within the context of the user thread. +This entails that any blocking call occurring during the write operation would block the user thread, thus preventing the application from continuing its operation. +However, this mode typically yields higher throughput rates at lower latencies, since there is no notification nor context switching between threads. + +On the other hand, with asynchronous publication mode, each time the publisher invokes the write operation, the data is copied into a queue, +a background thread (asynchronous thread) is notified about the addition to the queue, and control of the thread is returned to the user before the data is actually sent. +The background thread is in charge of consuming the queue and sending the data to every matched reader. + +Create the node with the publishers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +First, create a new package named ``sync_async_node_example_cpp`` on a new workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ md \ros2_ws\src + $ cd \ros2_ws\src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp + + +Then, add a file named ``src/sync_async_writer.cpp`` to the package, with the following content. +Note that the synchronous publisher will be publishing on topic ``sync_topic``, while the asynchronous one will be publishing on topic ``async_topic``. + +.. code-block:: C++ + + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + + class SyncAsyncPublisher : public rclcpp::Node + { + public: + SyncAsyncPublisher() + : Node("sync_async_publisher"), count_(0) + { + // Create the synchronous publisher on topic 'sync_topic' + sync_publisher_ = this->create_publisher("sync_topic", 10); + + // Create the asynchronous publisher on topic 'async_topic' + async_publisher_ = this->create_publisher("async_topic", 10); + + // Actions to run every time the timer expires + auto timer_callback = [this](){ + + // Create a new message to be sent + auto sync_message = std_msgs::msg::String(); + sync_message.data = "SYNC: Hello, world! " + std::to_string(count_); + + // Log the message to the console to show progress + RCLCPP_INFO(this->get_logger(), "Synchronously publishing: '%s'", sync_message.data.c_str()); + + // Publish the message using the synchronous publisher + sync_publisher_->publish(sync_message); + + // Create a new message to be sent + auto async_message = std_msgs::msg::String(); + async_message.data = "ASYNC: Hello, world! " + std::to_string(count_); + + // Log the message to the console to show progress + RCLCPP_INFO(this->get_logger(), "Asynchronously publishing: '%s'", async_message.data.c_str()); + + // Publish the message using the asynchronous publisher + async_publisher_->publish(async_message); + + // Prepare the count for the next message + count_++; + }; + + // This timer will trigger the publication of new data every half a second + timer_ = this->create_wall_timer(500ms, timer_callback); + } + + private: + // This timer will trigger the publication of new data every half a second + rclcpp::TimerBase::SharedPtr timer_; + + // A publisher that publishes asynchronously + rclcpp::Publisher::SharedPtr async_publisher_; + + // A publisher that publishes synchronously + rclcpp::Publisher::SharedPtr sync_publisher_; + + // Number of messages sent so far + size_t count_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +Now open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncWriter`` so you can run your node using ``ros2 run``: + +.. code-block:: cmake + + add_executable(SyncAsyncWriter src/sync_async_writer.cpp) + target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: cmake + + install(TARGETS + SyncAsyncWriter + DESTINATION lib/${PROJECT_NAME}) + +You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(sync_async_node_example_cpp) + + # Default to C++14 + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 14) + endif() + + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + + add_executable(SyncAsyncWriter src/sync_async_writer.cpp) + target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + SyncAsyncWriter + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + +If this node is built and run now, both publishers will behave the same, publishing asynchronously in both topics, because this is the default publication mode. +The default publication mode configuration can be changed in runtime during the node launching, using an XML file. + +Create the XML file with the profile configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Create a file with name ``SyncAsync.xml`` and the following content: + +.. code-block:: XML + + + + + + + DYNAMIC + + + + + DYNAMIC + + + + + DYNAMIC + + + SYNCHRONOUS + + + + + + + DYNAMIC + + + ASYNCHRONOUS + + + + + + +Note that several profiles for publisher and subscriber are defined. +Two default profiles which are defined setting the ``is_default_profile`` to ``true``, and two profiles with names that coincide with those of the previously defined topics: ``sync_topic`` and another one for ``async_topic``. +These last two profiles set the publication mode to ``SYNCHRONOUS`` or ``ASYNCHRONOUS`` accordingly. +Note also that all profiles specify a ``historyMemoryPolicy`` value, which is needed for the example to work, and the reason will be explained later on this tutorial. + +Execute the publisher node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You will need to export the following environment variables for the XML to be loaded: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: macOS + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + +Finally, ensure you have sourced your setup files and run the node: + +.. code-block:: console + + $ source install/setup.bash + $ ros2 run sync_async_node_example_cpp SyncAsyncWriter + [INFO] [1612972049.994630332] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 0' + [INFO] [1612972049.995097767] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 0' + [INFO] [1612972050.494478706] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 1' + [INFO] [1612972050.494664334] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 1' + [INFO] [1612972050.994368474] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 2' + [INFO] [1612972050.994549851] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 2' + +Now you have a synchronous publisher and an asynchronous publisher running inside the same node. + + +Create a node with the subscribers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Next, a new node with the subscribers that will listen to the ``sync_topic`` and ``async_topic`` publications is going to be created. +In a new source file named ``src/sync_async_reader.cpp`` write the following content: + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + class SyncAsyncSubscriber : public rclcpp::Node + { + public: + + SyncAsyncSubscriber() + : Node("sync_async_subscriber") + { + // Lambda function to run every time a new message is received + auto topic_callback = [this](const std_msgs::msg::String & msg){ + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); + }; + + // Create the synchronous subscriber on topic 'sync_topic' + // and tie it to the topic_callback + sync_subscription_ = this->create_subscription( + "sync_topic", 10, topic_callback); + + // Create the asynchronous subscriber on topic 'async_topic' + // and tie it to the topic_callback + async_subscription_ = this->create_subscription( + "async_topic", 10, topic_callback); + } + + private: + + // A subscriber that listens to topic 'sync_topic' + rclcpp::Subscription::SharedPtr sync_subscription_; + + // A subscriber that listens to topic 'async_topic' + rclcpp::Subscription::SharedPtr async_subscription_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + +Open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncReader`` under the previous ``SyncAsyncWriter``: + +.. code-block:: cmake + + add_executable(SyncAsyncReader src/sync_async_reader.cpp) + target_link_libraries(SyncAsyncReader PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + SyncAsyncReader + DESTINATION lib/${PROJECT_NAME}) + + +Execute the subscriber node +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +With the publisher node running in one terminal, open another one and export the required environment variables for the XML to be loaded: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: macOS + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + +Finally, ensure you have sourced your setup files and run the node: + +.. code-block:: console + + $ source install/setup.bash + $ ros2 run sync_async_node_example_cpp SyncAsyncReader + [INFO] [1612972054.495429090] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 10' + [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' + [INFO] [1612972055.495453494] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 11' + [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' + [INFO] [1612972056.495534818] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 12' + [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' + + +Analysis of the example +^^^^^^^^^^^^^^^^^^^^^^^ + +Configuration profiles XML +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The XML file defines several configurations for publishers and subscribers. +You can have a default publisher configuration profile and several topic-specific publisher profiles. +The only requirement is that all publisher profiles have a different name and that there is only a single default profile. +The same goes for subscribers. + +In order to define a configuration for a specific topic, just name the profile after the the ROS 2 topic name (like ``/sync_topic`` and ``/async_topic`` in the example), +and ``rmw_fastrtps`` will apply this profile to all publishers and subscribers for that topic. +The default configuration profile is identified by the attribute ``is_default_profile`` set to ``true``, and acts as a fallback profile when there is no other one with a name matching the topic name. + +The environment variable ``FASTDDS_DEFAULT_PROFILES_FILE`` is used to inform *Fast DDS* the path to the XML file with the configuration profiles to load. + +RMW_FASTRTPS_USE_QOS_FROM_XML +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Among all the configurable attributes, ``rmw_fastrtps`` treats ``publishMode`` and ``historyMemoryPolicy`` differently. +By default, these values are set to ``ASYNCHRONOUS`` and ``PREALLOCATED_WITH_REALLOC`` within the ``rmw_fastrtps`` implementation, and the values set on the XML file are ignored. +In order to use the values in the XML file, the environment variable ``RMW_FASTRTPS_USE_QOS_FROM_XML`` must be set to ``1``. + +However, this entails **another caveat**: If ``RMW_FASTRTPS_USE_QOS_FROM_XML`` is set, but the XML file does not define +``publishMode`` or ``historyMemoryPolicy``, these attributes take the *Fast DDS* default value instead of the ``rmw_fastrtps`` default value. +This is important, especially for ``historyMemoryPolicy``, because the *Fast DDS* default value is ``PREALLOCATED`` which does not work with ROS2 topic data types. +Therefore, in the example, a valid value for this policy has been explicitly set (``DYNAMIC``). + + +Prioritization of rmw_qos_profile_t +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ROS 2 QoS contained in `rmw_qos_profile_t `_ are always honored, unless set to ``*_SYSTEM_DEFAULT``. +In that case, XML values (or *Fast DDS* default values in the absence of XML ones) are applied. +This means that if any QoS in ``rmw_qos_profile_t`` is set to something other than ``*_SYSTEM_DEFAULT``, the corresponding value in the XML is ignored. + + +Using other FastDDS capabilities with XML +----------------------------------------- + +Although we have created a node with two publishers with different configuration, it is not easy to check that they are behaving differently. +Now that the basics of XML profiles have been covered, let us use them to configure something which has some visual effect on the nodes. +Specifically, a maximum number of matching subscribers on one of the publishers and a partition definition on the other will be set. +Note that these are only very simple examples among all the configuration attributes that can be tuned on ``rmw_fastrtps`` through XML files. +Please refer to `*Fast DDS* documentation `__ to see the whole list of attributes that can be configured through XML files. + +Limiting the number of matching subscribers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Add a maximum number of matched subscribers to the ``/async_topic`` publisher profile. +It should look like this: + +.. code-block:: XML + + + + DYNAMIC + + + ASYNCHRONOUS + + + + 0 + 1 + 1 + + + +The number of matching subscribers is being limited to one. + +Now open three terminals and do not forget to source the setup files and to set the required environment variables. +On the first terminal run the publisher node, and the subscriber node on the other two. +You should see that only the first subscriber node receives the messages from both topics. +The second one could not complete the matching process in the ``/async_topic`` because the publisher prevented it, as it had already reached its maximum of matched publishers. +Consequently, only the messages from the ``/sync_topic`` are going to be received in this third terminal: + +.. code-block:: console + + [INFO] [1613127657.088860890] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 18' + [INFO] [1613127657.588896594] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 19' + [INFO] [1613127658.088849401] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 20' + + +Using partitions within the topic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The partitions feature can be used to control which publishers and subscribers exchange information within the same topic. + +Partitions introduce a logical entity isolation level concept inside the physical isolation induced by a Domain ID. +For a publisher to communicate with a subscriber, they have to belong at least to one common partition. +Partitions represent another level to separate publishers and subscribers beyond domain and topic. +Unlike domain and topic, an endpoint can belong to several partitions at the same time. +For certain data to be shared over different domains or topics, there must be a different publisher for each, sharing its own history of changes. +However, a single publisher can share the same data sample over different partitions using a single topic data change, thus reducing network overload. + +Let us change the ``/sync_topic`` publisher to partition ``part1`` and create a new ``/sync_topic`` subscriber which uses partition ``part2``. +Their profiles should now look like this: + +.. code-block:: XML + + + + DYNAMIC + + + SYNCHRONOUS + + + + part1 + + + + + + + + DYNAMIC + + + + part2 + + + + + +Open two terminals. +Do not forget to source the setup files and to set the required environment variables. +On the first terminal run the publisher node, and the subscriber node on the other one. +You should see that only the ``/async_topic`` messages are reaching the subscriber. +The ``/sync_topic`` subscriber is not receiving the data as it is in a different partition from the corresponding publisher. + +.. code-block:: console + + [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' + [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' + [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' + + +Configuring a service and a client +---------------------------------- + +Services and clients have a publisher and a subscriber each, that communicate through two different topics. +For example, for a service named ``ping`` there is: + +* A service subscriber listening to requests on ``/rq/ping``. +* A service publisher sending responses on ``/rr/ping``. +* A client publisher sending requests on ``/rq/ping``. +* A client subscriber listening to responses on ``/rr/ping``. + +Although you can use these topic names to set the configuration profiles on the XML, sometimes you may wish to apply the same profile to all services or clients on a node. +Instead of copying the same profile with all topic names generated for all services, you can just create a publisher and subscriber profile pair named ``service``. +The same can be done for clients creating a pair named ``client``. + + +Create the nodes with the service and client +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Start creating the node with the service. +Add a new source file named ``src/ping_service.cpp`` on your package with the following content: + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + #include "example_interfaces/srv/trigger.hpp" + + /** + * Service action: responds with success=true and prints the request on the console + */ + void ping(const std::shared_ptr request, + std::shared_ptr response) + { + // The request data is unused + (void) request; + + // Build the response + response->success = true; + + // Log to the console + RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Incoming request"); + RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Sending back response"); + } + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + // Create the node and the service + std::shared_ptr node = rclcpp::Node::make_shared("ping_server"); + rclcpp::Service::SharedPtr service = + node->create_service("ping", &ping); + + // Log that the service is ready + RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Ready to serve."); + + // run the node + rclcpp::spin(node); + rclcpp::shutdown(); + } + +Create the client in a file named ``src/ping_client.cpp`` with the following content: + +.. code-block:: C++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "example_interfaces/srv/trigger.hpp" + + using namespace std::chrono_literals; + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + // Create the node and the client + std::shared_ptr node = rclcpp::Node::make_shared("ping_client"); + rclcpp::Client::SharedPtr client = + node->create_client("ping"); + + // Create a request + auto request = std::make_shared(); + + // Wait for the service to be available + while (!client->wait_for_service(1s)) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Interrupted while waiting for the service. Exiting."); + return 0; + } + RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Service not available, waiting again..."); + } + + // Now that the service is available, send the request + RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Sending request"); + auto result = client->async_send_request(request); + + // Wait for the result and log it to the console + if (rclcpp::spin_until_future_complete(node, result) == + rclcpp::FutureReturnCode::SUCCESS) + { + RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Response received"); + } else { + RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Failed to call service ping"); + } + + rclcpp::shutdown(); + return 0; + } + +Open the ``CMakeLists.txt`` file and add two new executables ``ping_service`` and ``ping_client``: + +.. code-block:: cmake + + find_package(example_interfaces REQUIRED) + + add_executable(ping_service src/ping_service.cpp) + target_link_libraries(ping_service PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) + + add_executable(ping_client src/ping_client.cpp) + target_link_libraries(ping_client PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) + + install(TARGETS + ping_service + DESTINATION lib/${PROJECT_NAME}) + + install(TARGETS + ping_client + DESTINATION lib/${PROJECT_NAME}) + +Finally, build the package. + + +Create the XML profiles for the service and client +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Create a file with name ``ping.xml`` with the following content: + +.. code-block:: XML + + + + + + + DYNAMIC + + + + + DYNAMIC + + + + + DYNAMIC + + + SYNCHRONOUS + + + + + + + DYNAMIC + + + ASYNCHRONOUS + + + + + + + +This configuration file sets the publication mode to ``SYNCHRONOUS`` on the service and to ``ASYNCHRONOUS`` on the client. +Note that we are only defining the publisher profiles for both the service and the client, but subscriber profiles could be provided too. + + +Execute the nodes +^^^^^^^^^^^^^^^^^ + +Open two terminals and source the setup files on each one. +Then set the required environment variables for the XML to be loaded: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml + + .. group-tab:: macOS + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml + + +On the first terminal run the service node. +You should see the service waiting for requests: + +.. code-block:: console + + $ ros2 run sync_async_node_example_cpp ping_service + [INFO] [1612977403.805799037] [ping_server]: Ready to serve. + +On the second terminal, run the client node. +You should see the client sending the request and receiving the response: + + +.. code-block:: console + + $ ros2 run sync_async_node_example_cpp ping_client + [INFO] [1612977404.805799037] [ping_client]: Sending request + [INFO] [1612977404.825473835] [ping_client]: Response received + +At the same time, the output in the server console has been updated: + +.. code-block:: console + + [INFO] [1612977403.805799037] [ping_server]: Ready to serve. + [INFO] [1612977404.807314904] [ping_server]: Incoming request + [INFO] [1612977404.836405125] [ping_server]: Sending back response \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst b/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst index 3402077c576..0d687fdf0a4 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst @@ -1,270 +1,274 @@ -.. _ImprovedDynamicDiscovery: - -Improved Dynamic Discovery -========================== - -**Goal:** This tutorial will show how to use the improved dynamic discovery configuration. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Overview --------- - -By default, ROS 2 will attempt to find all nodes on all hosts on the same subnet automatically. -However, the following options are available to control the ROS 2 discovery range. - -.. warning:: - - These environment variables (``ROS_AUTOMATIC_DISCOVERY_RANGE`` and ``ROS_STATIC_PEERS``) are **not supported** by ``rmw_zenoh``. - If you are using ``rmw_zenoh`` as your RMW implementation, please refer to the `rmw_zenoh configuration documentation `_ for instructions on how to configure discovery and communication behavior. - - -Configuration Parameters ------------------------- - -* ``ROS_AUTOMATIC_DISCOVERY_RANGE``: controls how far ROS nodes will try to discover each other. - - Valid options are: - - * ``SUBNET`` is the default, and for DDS based middleware it means it will discover any node reachable via multicast. - * ``LOCALHOST`` means a node will only try to discover other nodes on the same machine. - * ``OFF`` means the node won't discover any other nodes, even on the same machine. - * ``SYSTEM_DEFAULT`` means "don't change any discovery settings". - -* ``ROS_STATIC_PEERS``: is a semicolon (``;``) separated list of addresses that ROS should try to discover nodes on. - This allows connecting to nodes on specific machines (as long as their discovery range is not set to ``OFF``). - -The combination of these two environment variables for local and remote nodes will enable and control the ROS 2 communication discovery range. -The following tables highlight the discovery range behavior for possible combination. - -A ``X`` indicates that nodes A and B will not discover each other and communicate. -A ``O`` indicates that nodes A and B will discover each other and communicate. - -.. list-table:: Node A and B running in the same host - :widths: 20 20 20 20 20 20 20 20 20 - :header-rows: 1 - - * - Same host - - - - - - Node B setting - - - - - - - - - - - * - - - - - - - No static peer - - - - - - With static peer - - - - - * - - - - - - - Off - - Localhost - - Subnet - - Off - - Localhost - - Subnet - * - Node A setting - - No static peer - - Off - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - * - - - - - Localhost - - ``X`` - - ``O`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - * - - - - - Subnet - - ``X`` - - ``O`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - * - - - With static peer - - Off - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - * - - - - - Localhost - - ``X`` - - ``O`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - * - - - - - Subnet - - ``X`` - - ``O`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - - -.. list-table:: Node A and B running in the different hosts - :widths: 20 20 20 20 20 20 20 20 20 - :header-rows: 1 - - * - Different hosts - - - - - - Node B setting - - - - - - - - - - - * - - - - - - - No static peer - - - - - - With static peer - - - - - * - - - - - - - Off - - Localhost - - Subnet - - Off - - Localhost - - Subnet - * - Node A setting - - No static peer - - Off - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - * - - - - - Localhost - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``O`` - - ``O`` - * - - - - - Subnet - - ``X`` - - ``X`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - * - - - With static peer - - Off - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - - ``X`` - * - - - - - Localhost - - ``X`` - - ``O`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - * - - - - - Subnet - - ``X`` - - ``O`` - - ``O`` - - ``X`` - - ``O`` - - ``O`` - - -Examples --------- - -For example, the following commands will limit the ROS 2 communication only with localhost and specific peers: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST - $ export ROS_STATIC_PEERS='192.168.0.1;remote.com' - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST" >> ~/.bashrc - $ echo "export ROS_STATIC_PEERS='192.168.0.1;remote.com'" >> ~/.bashrc - - .. group-tab:: macOS - - .. code-block:: console - - $ export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST - $ export ROS_STATIC_PEERS='192.168.0.1;remote.com' - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST" >> ~/.bash_profile - $ echo "export ROS_STATIC_PEERS='192.168.0.1;remote.com'" >> ~/.bash_profile - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST - $ set ROS_STATIC_PEERS=192.168.0.1;remote.com - - If you want to make this permanent between shell sessions, also run: - - .. code-block:: console - - $ setx ROS_AUTOMATIC_DISCOVERY_RANGE LOCALHOST - $ setx ROS_STATIC_PEERS 192.168.0.1;remote.com +.. redirect-from:: + + Tutorials/Advanced/Improved-Dynamic-Discovery + +.. _ImprovedDynamicDiscovery: + +Improved Dynamic Discovery +========================== + +**Goal:** This tutorial will show how to use the improved dynamic discovery configuration. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Overview +-------- + +By default, ROS 2 will attempt to find all nodes on all hosts on the same subnet automatically. +However, the following options are available to control the ROS 2 discovery range. + +.. warning:: + + These environment variables (``ROS_AUTOMATIC_DISCOVERY_RANGE`` and ``ROS_STATIC_PEERS``) are **not supported** by ``rmw_zenoh``. + If you are using ``rmw_zenoh`` as your RMW implementation, please refer to the `rmw_zenoh configuration documentation `_ for instructions on how to configure discovery and communication behavior. + + +Configuration Parameters +------------------------ + +* ``ROS_AUTOMATIC_DISCOVERY_RANGE``: controls how far ROS nodes will try to discover each other. + + Valid options are: + + * ``SUBNET`` is the default, and for DDS based middleware it means it will discover any node reachable via multicast. + * ``LOCALHOST`` means a node will only try to discover other nodes on the same machine. + * ``OFF`` means the node won't discover any other nodes, even on the same machine. + * ``SYSTEM_DEFAULT`` means "don't change any discovery settings". + +* ``ROS_STATIC_PEERS``: is a semicolon (``;``) separated list of addresses that ROS should try to discover nodes on. + This allows connecting to nodes on specific machines (as long as their discovery range is not set to ``OFF``). + +The combination of these two environment variables for local and remote nodes will enable and control the ROS 2 communication discovery range. +The following tables highlight the discovery range behavior for possible combination. + +A ``X`` indicates that nodes A and B will not discover each other and communicate. +A ``O`` indicates that nodes A and B will discover each other and communicate. + +.. list-table:: Node A and B running in the same host + :widths: 20 20 20 20 20 20 20 20 20 + :header-rows: 1 + + * - Same host + - + - + - Node B setting + - + - + - + - + - + * - + - + - + - No static peer + - + - + - With static peer + - + - + * - + - + - + - Off + - Localhost + - Subnet + - Off + - Localhost + - Subnet + * - Node A setting + - No static peer + - Off + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + * - + - + - Localhost + - ``X`` + - ``O`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + * - + - + - Subnet + - ``X`` + - ``O`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + * - + - With static peer + - Off + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + * - + - + - Localhost + - ``X`` + - ``O`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + * - + - + - Subnet + - ``X`` + - ``O`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + + +.. list-table:: Node A and B running in the different hosts + :widths: 20 20 20 20 20 20 20 20 20 + :header-rows: 1 + + * - Different hosts + - + - + - Node B setting + - + - + - + - + - + * - + - + - + - No static peer + - + - + - With static peer + - + - + * - + - + - + - Off + - Localhost + - Subnet + - Off + - Localhost + - Subnet + * - Node A setting + - No static peer + - Off + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + * - + - + - Localhost + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``O`` + - ``O`` + * - + - + - Subnet + - ``X`` + - ``X`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + * - + - With static peer + - Off + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + - ``X`` + * - + - + - Localhost + - ``X`` + - ``O`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + * - + - + - Subnet + - ``X`` + - ``O`` + - ``O`` + - ``X`` + - ``O`` + - ``O`` + + +Examples +-------- + +For example, the following commands will limit the ROS 2 communication only with localhost and specific peers: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST + $ export ROS_STATIC_PEERS='192.168.0.1;remote.com' + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST" >> ~/.bashrc + $ echo "export ROS_STATIC_PEERS='192.168.0.1;remote.com'" >> ~/.bashrc + + .. group-tab:: macOS + + .. code-block:: console + + $ export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST + $ export ROS_STATIC_PEERS='192.168.0.1;remote.com' + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST" >> ~/.bash_profile + $ echo "export ROS_STATIC_PEERS='192.168.0.1;remote.com'" >> ~/.bash_profile + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST + $ set ROS_STATIC_PEERS=192.168.0.1;remote.com + + If you want to make this permanent between shell sessions, also run: + + .. code-block:: console + + $ setx ROS_AUTOMATIC_DISCOVERY_RANGE LOCALHOST + $ setx ROS_STATIC_PEERS 192.168.0.1;remote.com \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst b/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst index dfbe892c47b..74a0ff845d0 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst @@ -1,526 +1,527 @@ -.. redirect-from:: - - Logging-and-logger-configuration - Tutorials/Logging-and-logger-configuration - -Logging -======= - -.. contents:: Table of Contents - :depth: 2 - :local: - -See `the logging page <../../Concepts/Intermediate/About-Logging>` for details on available functionality. - -Using log statements in code ----------------------------- - -Basic logging -^^^^^^^^^^^^^ - -The following code will output a log message from a ROS 2 node at ``DEBUG`` severity: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: C++ - - // printf style - RCLCPP_DEBUG(node->get_logger(), "My log message %d", 4); - - // C++ stream style - RCLCPP_DEBUG_STREAM(node->get_logger(), "My log message " << 4); - - .. group-tab:: Python - - .. code-block:: python - - node.get_logger().debug('My log message %d' % (4)) - -Note that in both cases, no trailing newline is added, as the logging infrastructure will automatically add one. - -Logging only the first time -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following code will output a log message from a ROS 2 node at ``INFO`` severity, but only the first time it is hit: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: C++ - - // printf style - RCLCPP_INFO_ONCE(node->get_logger(), "My log message %d", 4); - - // C++ stream style - RCLCPP_INFO_STREAM_ONCE(node->get_logger(), "My log message " << 4); - - .. group-tab:: Python - - .. code-block:: python - - num = 4 - node.get_logger().info(f'My log message {num}', once=True) - -Logging all but the first time -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following code will output a log message from a ROS 2 node at ``WARN`` severity, but not the very first time it is hit: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: C++ - - // printf style - RCLCPP_WARN_SKIPFIRST(node->get_logger(), "My log message %d", 4); - - // C++ stream style - RCLCPP_WARN_STREAM_SKIPFIRST(node->get_logger(), "My log message " << 4); - - .. group-tab:: Python - - .. code-block:: python - - num = 4 - node.get_logger().warning('My log message {0}'.format(num), skip_first=True) - -Logging throttled -^^^^^^^^^^^^^^^^^ - -The following code will output a log message from a ROS 2 node at ``ERROR`` severity, but no more than once per second. - -The interval parameter specifying milliseconds between messages should have an integer data type so it can be converted to a ``rcutils_duration_value_t`` (an ``int64_t``): - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: C++ - - // printf style - RCLCPP_ERROR_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message %d", 4); - - // C++ stream style - RCLCPP_ERROR_STREAM_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message " << 4); - - // For now, use the nanoseconds() method to use an existing rclcpp::Duration value, see https://github.com/ros2/rclcpp/issues/1929 - RCLCPP_ERROR_STREAM_THROTTLE(node->get_logger(), *node->get_clock(), msg_interval.nanoseconds()/1000000, "My log message " << 4); - - .. group-tab:: Python - - .. code-block:: python - - num = 4 - node.get_logger().error(f'My log message {num}', throttle_duration_sec=1) - -Logging throttled all but the first time -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following code will output a log message from a ROS 2 node at ``DEBUG`` severity, no more than once per second, skipping the very first time it is hit: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: C++ - - // printf style - RCLCPP_DEBUG_SKIPFIRST_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message %d", 4); - - RCLCPP_DEBUG_SKIPFIRST_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message " << 4); - - .. group-tab:: Python - - .. code-block:: python - - num = 4 - node.get_logger().debug(f'My log message {num}', skip_first=True, throttle_duration_sec=1.0) - -Logging demo ------------- - -In this `demo `_, different types of log calls are shown and the severity level of different loggers is configured locally and externally. - -Start the demo with: - -.. code-block:: console - - $ ros2 run logging_demo logging_demo_main - -Over time you will see output from various log calls with different properties. -To start with you will only see output from log calls with severity ``INFO`` and above (``WARN``, ``ERROR``, ``FATAL``). -Note that the first message will only be logged once, though the line is reached on each iteration, as that is a property of the log call used for that message. - -Logging directory configuration -------------------------------- - -The logging directory can be configured through two environment variables: ``ROS_LOG_DIR`` and ``ROS_HOME``. -The logic is as follows: - -* Use ``$ROS_LOG_DIR`` if ``ROS_LOG_DIR`` is set and not empty. -* Otherwise, use ``$ROS_HOME/log``, using ``~/.ros`` for ``ROS_HOME`` if not set or if empty. - -For example, to set the logging directory to ``~/my_logs``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_LOG_DIR=~/my_logs - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: macOS - - .. code-block:: console - - $ export ROS_LOG_DIR=~/my_logs - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: Windows - - .. code-block:: console - - $ set "ROS_LOG_DIR=~/my_logs" - $ ros2 run logging_demo logging_demo_main - -You will then find the logs under ``~/my_logs/``. - -Alternatively, you can set ``ROS_HOME`` and the logging directory will be relative to it (``$ROS_HOME/log``). -``ROS_HOME`` is intended to be used by anything that needs a base directory. -Note that ``ROS_LOG_DIR`` has to be either unset or empty. -For example, with ``ROS_HOME`` set to ``~/my_ros_home``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_HOME=~/my_ros_home - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: macOS - - .. code-block:: console - - $ export ROS_HOME=~/my_ros_home - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: Windows - - .. code-block:: console - - $ set "ROS_HOME=~/my_ros_home" - $ ros2 run logging_demo logging_demo_main - -You will then find the logs under ``~/my_ros_home/log/``. - -Logger level configuration: programmatically --------------------------------------------- - -After 10 iterations the level of the logger will be set to ``DEBUG``, which will cause additional messages to be logged. - -Some of these debug messages cause additional functions/expressions to be evaluated, which were previously skipped as ``DEBUG`` log calls were not enabled. -See `the source code `__ of the demo for further explanation of the calls used, and see the rclcpp logging documentation for a full list of supported logging calls. - -Logger level configuration: externally --------------------------------------- - -ROS 2 nodes have services available to configure the logging level externally at runtime. -These services are disabled by default. -The following code shows how to enable the logger service while creating the node. - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: C++ - - // Create a node with logger service enabled - auto node = std::make_shared("NodeWithLoggerService", rclcpp::NodeOptions().enable_logger_service(true)); - - .. group-tab:: Python - - .. code-block:: python - - # Create a node with logger service enabled - node = Node('NodeWithLoggerService', enable_logger_service=True) - -If you run one of the nodes as configured above, you will find 2 services when running ``ros2 service list``: - -.. code-block:: console - - $ ros2 service list - ... - /NodeWithLoggerService/get_logger_levels - /NodeWithLoggerService/set_logger_levels - ... - -* get_logger_levels - - Use this service to get logger levels for specified logger names. - - Run ``ros2 service call`` to get logger levels for ``NodeWithLoggerService`` and ``rcl``. - - .. code-block:: console - - $ ros2 service call /NodeWithLoggerService/get_logger_levels rcl_interfaces/srv/GetLoggerLevels '{names: ["NodeWithLoggerService", "rcl"]}' - - requester: making request: rcl_interfaces.srv.GetLoggerLevels_Request(names=['NodeWithLoggerService', 'rcl']) - - response: - rcl_interfaces.srv.GetLoggerLevels_Response(levels=[rcl_interfaces.msg.LoggerLevel(name='NodeWithLoggerService', level=0), rcl_interfaces.msg.LoggerLevel(name='rcl', level=0)]) - -* set_logger_levels - - Use this service to set logger levels for specified logger names. - - Run ``ros2 service call`` to set logger levels for ``NodeWithLoggerService`` and ``rcl``. - - .. code-block:: console - - $ ros2 service call /NodeWithLoggerService/set_logger_levels rcl_interfaces/srv/SetLoggerLevels '{levels: [{name: "NodeWithLoggerService", level: 20}, {name: "rcl", level: 10}]}' - - requester: making request: rcl_interfaces.srv.SetLoggerLevels_Request(levels=[rcl_interfaces.msg.LoggerLevel(name='NodeWithLoggerService', level=20), rcl_interfaces.msg.LoggerLevel(name='rcl', level=10)]) - - response: - rcl_interfaces.srv.SetLoggerLevels_Response(results=[rcl_interfaces.msg.SetLoggerLevelsResult(successful=True, reason=''), rcl_interfaces.msg.SetLoggerLevelsResult(successful=True, reason='')]) - - -There is also demo code showing how to set or get the logger level via the logger service. - - * rclcpp: `demo code `__ - - .. code-block:: console - - $ ros2 run demo_nodes_cpp use_logger_service - - * rclpy: `demo code `__ - - .. code-block:: console - - $ ros2 run demo_nodes_py use_logger_service - -.. warning:: - - Currently, there is a limitation that ``get_logger_levels`` and ``set_logger_levels`` services are not thread-safe. - This means that you need to ensure that only one thread is calling the services at a time. - Please see the details in https://github.com/ros2/rcutils/issues/397 - -Using the logger config component -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The server that responds to the logger configuration requests has been developed as a component so that it may be added to an existing composition-based system. -For example, if you are using `a container to run your nodes <../Intermediate/Composition>`, to be able to configure your loggers you only need to request that it additionally load the ``logging_demo::LoggerConfig`` component into the container. - -As an example, if you want to debug the ``composition::Talker`` demo, you can start the talker as normal with: - -Shell 1: - -.. code-block:: console - - $ ros2 run rclcpp_components component_container - -Shell 2: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker - -And then when you want to enable debug logging, load the ``LoggerConfig`` component with: - -Shell 2 - -.. code-block:: console - - $ ros2 component load /ComponentManager logging_demo logging_demo::LoggerConfig - -And finally, configure all unset loggers to the debug severity by addressing the empty-named logger. -Note that loggers that have been specifically configured to use a particular severity will not be affected by this call. - -Shell 2: - -.. code-block:: console - - $ ros2 service call /config_logger logging_demo/srv/ConfigLogger "{logger_name: '', level: DEBUG}" - -You should see debug output from any previously unset loggers in the process start to appear, including from the ROS 2 core. - -Logger level configuration: command line ----------------------------------------- - -As of the Bouncy ROS 2 release, the severity level for loggers that have not had their severity set explicitly can be configured from the command line. -Restart the demo including the following command line argument: - - -.. code-block:: console - - $ ros2 run logging_demo logging_demo_main --ros-args --log-level debug - -This configures the default severity for any unset logger to the debug severity level. -You should see debug output from loggers from the demo itself and from the ROS 2 core. - -The severity level for individual loggers can be configured from the command-line. -Restart the demo including the following command line arguments: - -.. code-block:: console - - $ ros2 run logging_demo logging_demo_main --ros-args --log-level logger_usage_demo:=debug - - -Console output formatting -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you would like more or less verbose formatting, you can use the ``RCUTILS_CONSOLE_OUTPUT_FORMAT`` environment variable. -For example, to additionally get the timestamp and location of the log calls, stop the demo and restart it with the environment variable set: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RCUTILS_CONSOLE_OUTPUT_FORMAT="[{severity} {time}] [{name}]: {message} ({function_name}() at {file_name}:{line_number})" - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: macOS - - .. code-block:: console - - $ export RCUTILS_CONSOLE_OUTPUT_FORMAT="[{severity} {time}] [{name}]: {message} ({function_name}() at {file_name}:{line_number})" - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: Windows - - .. code-block:: console - - $ set "RCUTILS_CONSOLE_OUTPUT_FORMAT=[{severity} {time}] [{name}]: {message} ({function_name}() at {file_name}:{line_number})" - $ ros2 run logging_demo logging_demo_main - -You should see the timestamp in seconds and the function name, filename and line number additionally printed with each message. - -For more information on configuring the console logger formatting, see the :ref:`logger console configuration ` - -Console output colorizing -^^^^^^^^^^^^^^^^^^^^^^^^^ - -By default, the output is colorized when it's targeting a terminal. -If you would like to force enabling or disabling it, you can use the ``RCUTILS_COLORIZED_OUTPUT`` environment variable. -For example: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RCUTILS_COLORIZED_OUTPUT=0 # 1 for forcing it - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: macOS - - .. code-block:: console - - $ export RCUTILS_COLORIZED_OUTPUT=0 # 1 for forcing it - $ ros2 run logging_demo logging_demo_main - - .. group-tab:: Windows - - .. code-block:: console - - $ set "RCUTILS_COLORIZED_OUTPUT=0" :: 1 for forcing it - $ ros2 run logging_demo logging_demo_main - -You should see that debug, warn, error and fatal logs aren't colorized now. - -.. note:: - - In Linux and MacOS forcing colorized output means that if you redirect the output to a file, the ansi escape color codes will appear on it. - In windows the colorization method relies on console APIs. - If it is forced you will get a new warning saying that colorization failed. - The default behavior already checks if the output is a console or not, so forcing colorization is not recommended. - -.. note:: - - If you start several nodes via ``ros2 launch``, no node has an active terminal attached to it (unless you set ``emulate_tty=True``). - This means that to get colorized output for ``ros2 launch``, you need to set ``RCUTILS_COLORIZED_OUTPUT=1`` explicitly. - -Default stream for console output -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In Foxy and later, the output from all debug levels goes to stderr by default. -It is possible to force all output to go to stdout by setting the ``RCUTILS_LOGGING_USE_STDOUT`` environment variable to ``1``. -For example: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RCUTILS_LOGGING_USE_STDOUT=1 - - .. group-tab:: macOS - - .. code-block:: console - - $ export RCUTILS_LOGGING_USE_STDOUT=1 - - .. group-tab:: Windows - - .. code-block:: console - - $ set "RCUTILS_LOGGING_USE_STDOUT=1" - - -Line buffered console output -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - -By default, all logging output is unbuffered. -You can force it to be buffered by setting the ``RCUTILS_LOGGING_BUFFERED_STREAM`` environment variable to 1. -For example: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RCUTILS_LOGGING_BUFFERED_STREAM=1 - - .. group-tab:: macOS - - .. code-block:: console - - $ export RCUTILS_LOGGING_BUFFERED_STREAM=1 - - .. group-tab:: Windows - - .. code-block:: console - - $ set "RCUTILS_LOGGING_BUFFERED_STREAM=1" - -Then run: - -.. code-block:: console - - $ ros2 run logging_demo logging_demo_main - -Setting the log file name prefix --------------------------------- - -By default, the log file name is based on the executable file name followed by process ID and system timestamp on file creation. -You can change the log file name prefix to one of your choice using the ``--log-file-name`` command line argument: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --log-file-name filename - -This configures the log file name prefix to ``filename``, instead of the executable file name (which is ``talker`` in this case). +.. redirect-from:: + + Logging-and-logger-configuration + Tutorials/Logging-and-logger-configuration + Tutorials/Demos/Logging-and-logger-configuration + +Logging +======= + +.. contents:: Table of Contents + :depth: 2 + :local: + +See `the logging page <../../Concepts/Intermediate/About-Logging>` for details on available functionality. + +Using log statements in code +---------------------------- + +Basic logging +^^^^^^^^^^^^^ + +The following code will output a log message from a ROS 2 node at ``DEBUG`` severity: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: C++ + + // printf style + RCLCPP_DEBUG(node->get_logger(), "My log message %d", 4); + + // C++ stream style + RCLCPP_DEBUG_STREAM(node->get_logger(), "My log message " << 4); + + .. group-tab:: Python + + .. code-block:: python + + node.get_logger().debug('My log message %d' % (4)) + +Note that in both cases, no trailing newline is added, as the logging infrastructure will automatically add one. + +Logging only the first time +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following code will output a log message from a ROS 2 node at ``INFO`` severity, but only the first time it is hit: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: C++ + + // printf style + RCLCPP_INFO_ONCE(node->get_logger(), "My log message %d", 4); + + // C++ stream style + RCLCPP_INFO_STREAM_ONCE(node->get_logger(), "My log message " << 4); + + .. group-tab:: Python + + .. code-block:: python + + num = 4 + node.get_logger().info(f'My log message {num}', once=True) + +Logging all but the first time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following code will output a log message from a ROS 2 node at ``WARN`` severity, but not the very first time it is hit: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: C++ + + // printf style + RCLCPP_WARN_SKIPFIRST(node->get_logger(), "My log message %d", 4); + + // C++ stream style + RCLCPP_WARN_STREAM_SKIPFIRST(node->get_logger(), "My log message " << 4); + + .. group-tab:: Python + + .. code-block:: python + + num = 4 + node.get_logger().warning('My log message {0}'.format(num), skip_first=True) + +Logging throttled +^^^^^^^^^^^^^^^^^ + +The following code will output a log message from a ROS 2 node at ``ERROR`` severity, but no more than once per second. + +The interval parameter specifying milliseconds between messages should have an integer data type so it can be converted to a ``rcutils_duration_value_t`` (an ``int64_t``): + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: C++ + + // printf style + RCLCPP_ERROR_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message %d", 4); + + // C++ stream style + RCLCPP_ERROR_STREAM_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message " << 4); + + // For now, use the nanoseconds() method to use an existing rclcpp::Duration value, see https://github.com/ros2/rclcpp/issues/1929 + RCLCPP_ERROR_STREAM_THROTTLE(node->get_logger(), *node->get_clock(), msg_interval.nanoseconds()/1000000, "My log message " << 4); + + .. group-tab:: Python + + .. code-block:: python + + num = 4 + node.get_logger().error(f'My log message {num}', throttle_duration_sec=1) + +Logging throttled all but the first time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following code will output a log message from a ROS 2 node at ``DEBUG`` severity, no more than once per second, skipping the very first time it is hit: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: C++ + + // printf style + RCLCPP_DEBUG_SKIPFIRST_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message %d", 4); + + RCLCPP_DEBUG_SKIPFIRST_THROTTLE(node->get_logger(), *node->get_clock(), 1000, "My log message " << 4); + + .. group-tab:: Python + + .. code-block:: python + + num = 4 + node.get_logger().debug(f'My log message {num}', skip_first=True, throttle_duration_sec=1.0) + +Logging demo +------------ + +In this `demo `_, different types of log calls are shown and the severity level of different loggers is configured locally and externally. + +Start the demo with: + +.. code-block:: console + + $ ros2 run logging_demo logging_demo_main + +Over time you will see output from various log calls with different properties. +To start with you will only see output from log calls with severity ``INFO`` and above (``WARN``, ``ERROR``, ``FATAL``). +Note that the first message will only be logged once, though the line is reached on each iteration, as that is a property of the log call used for that message. + +Logging directory configuration +------------------------------- + +The logging directory can be configured through two environment variables: ``ROS_LOG_DIR`` and ``ROS_HOME``. +The logic is as follows: + +* Use ``$ROS_LOG_DIR`` if ``ROS_LOG_DIR`` is set and not empty. +* Otherwise, use ``$ROS_HOME/log``, using ``~/.ros`` for ``ROS_HOME`` if not set or if empty. + +For example, to set the logging directory to ``~/my_logs``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_LOG_DIR=~/my_logs + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: macOS + + .. code-block:: console + + $ export ROS_LOG_DIR=~/my_logs + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: Windows + + .. code-block:: console + + $ set "ROS_LOG_DIR=~/my_logs" + $ ros2 run logging_demo logging_demo_main + +You will then find the logs under ``~/my_logs/``. + +Alternatively, you can set ``ROS_HOME`` and the logging directory will be relative to it (``$ROS_HOME/log``). +``ROS_HOME`` is intended to be used by anything that needs a base directory. +Note that ``ROS_LOG_DIR`` has to be either unset or empty. +For example, with ``ROS_HOME`` set to ``~/my_ros_home``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_HOME=~/my_ros_home + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: macOS + + .. code-block:: console + + $ export ROS_HOME=~/my_ros_home + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: Windows + + .. code-block:: console + + $ set "ROS_HOME=~/my_ros_home" + $ ros2 run logging_demo logging_demo_main + +You will then find the logs under ``~/my_ros_home/log/``. + +Logger level configuration: programmatically +-------------------------------------------- + +After 10 iterations the level of the logger will be set to ``DEBUG``, which will cause additional messages to be logged. + +Some of these debug messages cause additional functions/expressions to be evaluated, which were previously skipped as ``DEBUG`` log calls were not enabled. +See `the source code `__ of the demo for further explanation of the calls used, and see the rclcpp logging documentation for a full list of supported logging calls. + +Logger level configuration: externally +-------------------------------------- + +ROS 2 nodes have services available to configure the logging level externally at runtime. +These services are disabled by default. +The following code shows how to enable the logger service while creating the node. + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: C++ + + // Create a node with logger service enabled + auto node = std::make_shared("NodeWithLoggerService", rclcpp::NodeOptions().enable_logger_service(true)); + + .. group-tab:: Python + + .. code-block:: python + + # Create a node with logger service enabled + node = Node('NodeWithLoggerService', enable_logger_service=True) + +If you run one of the nodes as configured above, you will find 2 services when running ``ros2 service list``: + +.. code-block:: console + + $ ros2 service list + ... + /NodeWithLoggerService/get_logger_levels + /NodeWithLoggerService/set_logger_levels + ... + +* get_logger_levels + + Use this service to get logger levels for specified logger names. + + Run ``ros2 service call`` to get logger levels for ``NodeWithLoggerService`` and ``rcl``. + + .. code-block:: console + + $ ros2 service call /NodeWithLoggerService/get_logger_levels rcl_interfaces/srv/GetLoggerLevels '{names: ["NodeWithLoggerService", "rcl"]}' + + requester: making request: rcl_interfaces.srv.GetLoggerLevels_Request(names=['NodeWithLoggerService', 'rcl']) + + response: + rcl_interfaces.srv.GetLoggerLevels_Response(levels=[rcl_interfaces.msg.LoggerLevel(name='NodeWithLoggerService', level=0), rcl_interfaces.msg.LoggerLevel(name='rcl', level=0)]) + +* set_logger_levels + + Use this service to set logger levels for specified logger names. + + Run ``ros2 service call`` to set logger levels for ``NodeWithLoggerService`` and ``rcl``. + + .. code-block:: console + + $ ros2 service call /NodeWithLoggerService/set_logger_levels rcl_interfaces/srv/SetLoggerLevels '{levels: [{name: "NodeWithLoggerService", level: 20}, {name: "rcl", level: 10}]}' + + requester: making request: rcl_interfaces.srv.SetLoggerLevels_Request(levels=[rcl_interfaces.msg.LoggerLevel(name='NodeWithLoggerService', level=20), rcl_interfaces.msg.LoggerLevel(name='rcl', level=10)]) + + response: + rcl_interfaces.srv.SetLoggerLevels_Response(results=[rcl_interfaces.msg.SetLoggerLevelsResult(successful=True, reason=''), rcl_interfaces.msg.SetLoggerLevelsResult(successful=True, reason='')]) + + +There is also demo code showing how to set or get the logger level via the logger service. + + * rclcpp: `demo code `__ + + .. code-block:: console + + $ ros2 run demo_nodes_cpp use_logger_service + + * rclpy: `demo code `__ + + .. code-block:: console + + $ ros2 run demo_nodes_py use_logger_service + +.. warning:: + + Currently, there is a limitation that ``get_logger_levels`` and ``set_logger_levels`` services are not thread-safe. + This means that you need to ensure that only one thread is calling the services at a time. + Please see the details in https://github.com/ros2/rcutils/issues/397 + +Using the logger config component +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The server that responds to the logger configuration requests has been developed as a component so that it may be added to an existing composition-based system. +For example, if you are using `a container to run your nodes <../Intermediate/Composition>`, to be able to configure your loggers you only need to request that it additionally load the ``logging_demo::LoggerConfig`` component into the container. + +As an example, if you want to debug the ``composition::Talker`` demo, you can start the talker as normal with: + +Shell 1: + +.. code-block:: console + + $ ros2 run rclcpp_components component_container + +Shell 2: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker + +And then when you want to enable debug logging, load the ``LoggerConfig`` component with: + +Shell 2 + +.. code-block:: console + + $ ros2 component load /ComponentManager logging_demo logging_demo::LoggerConfig + +And finally, configure all unset loggers to the debug severity by addressing the empty-named logger. +Note that loggers that have been specifically configured to use a particular severity will not be affected by this call. + +Shell 2: + +.. code-block:: console + + $ ros2 service call /config_logger logging_demo/srv/ConfigLogger "{logger_name: '', level: DEBUG}" + +You should see debug output from any previously unset loggers in the process start to appear, including from the ROS 2 core. + +Logger level configuration: command line +---------------------------------------- + +As of the Bouncy ROS 2 release, the severity level for loggers that have not had their severity set explicitly can be configured from the command line. +Restart the demo including the following command line argument: + + +.. code-block:: console + + $ ros2 run logging_demo logging_demo_main --ros-args --log-level debug + +This configures the default severity for any unset logger to the debug severity level. +You should see debug output from loggers from the demo itself and from the ROS 2 core. + +The severity level for individual loggers can be configured from the command-line. +Restart the demo including the following command line arguments: + +.. code-block:: console + + $ ros2 run logging_demo logging_demo_main --ros-args --log-level logger_usage_demo:=debug + + +Console output formatting +^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you would like more or less verbose formatting, you can use the ``RCUTILS_CONSOLE_OUTPUT_FORMAT`` environment variable. +For example, to additionally get the timestamp and location of the log calls, stop the demo and restart it with the environment variable set: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RCUTILS_CONSOLE_OUTPUT_FORMAT="[{severity} {time}] [{name}]: {message} ({function_name}() at {file_name}:{line_number})" + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: macOS + + .. code-block:: console + + $ export RCUTILS_CONSOLE_OUTPUT_FORMAT="[{severity} {time}] [{name}]: {message} ({function_name}() at {file_name}:{line_number})" + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: Windows + + .. code-block:: console + + $ set "RCUTILS_CONSOLE_OUTPUT_FORMAT=[{severity} {time}] [{name}]: {message} ({function_name}() at {file_name}:{line_number})" + $ ros2 run logging_demo logging_demo_main + +You should see the timestamp in seconds and the function name, filename and line number additionally printed with each message. + +For more information on configuring the console logger formatting, see the :ref:`logger console configuration ` + +Console output colorizing +^^^^^^^^^^^^^^^^^^^^^^^^^ + +By default, the output is colorized when it's targeting a terminal. +If you would like to force enabling or disabling it, you can use the ``RCUTILS_COLORIZED_OUTPUT`` environment variable. +For example: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RCUTILS_COLORIZED_OUTPUT=0 # 1 for forcing it + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: macOS + + .. code-block:: console + + $ export RCUTILS_COLORIZED_OUTPUT=0 # 1 for forcing it + $ ros2 run logging_demo logging_demo_main + + .. group-tab:: Windows + + .. code-block:: console + + $ set "RCUTILS_COLORIZED_OUTPUT=0" :: 1 for forcing it + $ ros2 run logging_demo logging_demo_main + +You should see that debug, warn, error and fatal logs aren't colorized now. + +.. note:: + + In Linux and MacOS forcing colorized output means that if you redirect the output to a file, the ansi escape color codes will appear on it. + In windows the colorization method relies on console APIs. + If it is forced you will get a new warning saying that colorization failed. + The default behavior already checks if the output is a console or not, so forcing colorization is not recommended. + +.. note:: + + If you start several nodes via ``ros2 launch``, no node has an active terminal attached to it (unless you set ``emulate_tty=True``). + This means that to get colorized output for ``ros2 launch``, you need to set ``RCUTILS_COLORIZED_OUTPUT=1`` explicitly. + +Default stream for console output +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In Foxy and later, the output from all debug levels goes to stderr by default. +It is possible to force all output to go to stdout by setting the ``RCUTILS_LOGGING_USE_STDOUT`` environment variable to ``1``. +For example: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RCUTILS_LOGGING_USE_STDOUT=1 + + .. group-tab:: macOS + + .. code-block:: console + + $ export RCUTILS_LOGGING_USE_STDOUT=1 + + .. group-tab:: Windows + + .. code-block:: console + + $ set "RCUTILS_LOGGING_USE_STDOUT=1" + + +Line buffered console output +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +By default, all logging output is unbuffered. +You can force it to be buffered by setting the ``RCUTILS_LOGGING_BUFFERED_STREAM`` environment variable to 1. +For example: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RCUTILS_LOGGING_BUFFERED_STREAM=1 + + .. group-tab:: macOS + + .. code-block:: console + + $ export RCUTILS_LOGGING_BUFFERED_STREAM=1 + + .. group-tab:: Windows + + .. code-block:: console + + $ set "RCUTILS_LOGGING_BUFFERED_STREAM=1" + +Then run: + +.. code-block:: console + + $ ros2 run logging_demo logging_demo_main + +Setting the log file name prefix +-------------------------------- + +By default, the log file name is based on the executable file name followed by process ID and system timestamp on file creation. +You can change the log file name prefix to one of your choice using the ``--log-file-name`` command line argument: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --log-file-name filename + +This configures the log file name prefix to ``filename``, instead of the executable file name (which is ``talker`` in this case). \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst b/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst index fffebb4f469..01eb2bc465d 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst @@ -1,174 +1,175 @@ -.. redirect-from:: - - Node-arguments - Guides/Node-arguments - Tutorials/Node-arguments - -Passing ROS arguments to nodes via the command-line -=================================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - - -All ROS nodes take a set of arguments that allow various properties to be reconfigured. -Examples include configuring the name/namespace of the node, topic/service names used, and parameters on the node. -All ROS-specific arguments have to be specified after a ``--ros-args`` flag: - - -.. code-block:: console - - $ ros2 run my_package node_executable --ros-args ... - - -For more details, see `this design doc `__. - -Name remapping --------------- - -Names within a node (e.g. topics/services) can be remapped using the syntax ``-r :=``. -The name/namespace of the node itself can be remapped using ``-r __node:=`` and ``-r __ns:=``. - - -Note that these remappings are "static" remappings, in that they apply for the lifetime of the node. -"Dynamic" remapping of names after nodes have been started is not yet supported. - -See `this design doc `__ for more details on remapping arguments (not all functionality is available yet). - -Example -^^^^^^^ - -The following invocation will cause the ``talker`` node to be started under the node name ``my_talker``, publishing on the topic named ``my_topic`` instead of the default of ``chatter``. -The namespace, which must start with a forward slash, is set to ``/demo``, which means that topics are created in that namespace (``/demo/my_topic``), as opposed to globally (``/my_topic``). - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args -r __ns:=/demo -r __node:=my_talker -r chatter:=my_topic - -Passing remapping arguments to specific nodes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If multiple nodes are being run within a single process (e.g. using :doc:`Composition <../Concepts/Intermediate/About-Composition>`), remapping arguments can be passed to a specific node using its name as a prefix. -For example, the following will pass the remapping arguments to the specified nodes: - -.. code-block:: console - - $ ros2 run composition manual_composition --ros-args -r talker:__node:=my_talker -r listener:__node:=my_listener - - -The following example will both change the node name and remap a topic (node and namespace changes are always applied *before* topic remapping): - -.. code-block:: console - - $ ros2 run composition manual_composition --ros-args -r talker:__node:=my_talker -r my_talker:chatter:=my_topic -r listener:__node:=my_listener -r my_listener:chatter:=my_topic - - -Logger configuration --------------------- - -The per-node logging level can be specified using the ``--log-level`` command line argument. -The executable log file name prefix, which includes all nodes in the executable, can be specified using ``--log-file-name`` command line argument. -For more information please see :doc:`the logging page <../Tutorials/Demos/Logging-and-logger-configuration>`. - -Parameters ----------- - -.. _NodeArgsParameters: - -Setting parameters directly from the command line -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can set parameters directly from the command line using the following syntax: - -.. code-block:: console - - $ ros2 run package_name executable_name --ros-args -p param_name:=param_value - -As an example, you can run: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp parameter_blackboard --ros-args -p some_int:=42 -p "a_string:=Hello world" -p "some_lists.some_integers:=[1, 2, 3, 4]" -p "some_lists.some_doubles:=[3.14, 2.718]" - -Other nodes will be able to retrieve the parameter values, e.g.: - -.. code-block:: console - - $ ros2 param list parameter_blackboard - a_string - qos_overrides./parameter_events.publisher.depth - qos_overrides./parameter_events.publisher.durability - qos_overrides./parameter_events.publisher.history - qos_overrides./parameter_events.publisher.reliability - some_int - some_lists.some_doubles - some_lists.some_integers - use_sim_time - -Setting parameters from YAML files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Parameters can be set from the command-line in the form of yaml files. - -`See here `__ for examples of the yaml file syntax. - -As an example, save the following as ``demo_params.yaml``: - -.. code-block:: yaml - - parameter_blackboard: - ros__parameters: - some_int: 42 - a_string: "Hello world" - some_lists: - some_integers: [1, 2, 3, 4] - some_doubles : [3.14, 2.718] - - /**: - ros__parameters: - wildcard_full: "Full wildcard for any namespaces and any node names" - - /**/parameter_blackboard: - ros__parameters: - wildcard_namespace: "Wildcard for a specific node name under any namespace" - - /*: - ros__parameters: - wildcard_nodename_root_namespace: "Wildcard for any node names, but only in root namespace" - - -.. note:: - - Wildcards can be used for node names and namespaces. - ``*`` matches a single token delimited by slashes (``/``). - ``**`` matches zero or more tokens delimited by slashes. - Partial matches are not allowed (e.g. ``foo*``). - - -Then either declare the parameters within your node with `declare_parameter `__ or `declare_parameters `__, or `set the node to automatically declare parameters `__ if they were passed in via a command line override. - -Then run the following: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp parameter_blackboard --ros-args --params-file demo_params.yaml - - -Other nodes will be able to retrieve the parameter values, e.g.: - -.. code-block:: console - - $ ros2 param list parameter_blackboard - a_string - qos_overrides./parameter_events.publisher.depth - qos_overrides./parameter_events.publisher.durability - qos_overrides./parameter_events.publisher.history - qos_overrides./parameter_events.publisher.reliability - some_int - some_lists.some_doubles - some_lists.some_integers - use_sim_time - wildcard_full - wildcard_namespace - wildcard_nodename_root_namespace +.. redirect-from:: + + Node-arguments + Guides/Node-arguments + Tutorials/Node-arguments + How-To-Guides/Node-arguments + +Passing ROS arguments to nodes via the command-line +=================================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + + +All ROS nodes take a set of arguments that allow various properties to be reconfigured. +Examples include configuring the name/namespace of the node, topic/service names used, and parameters on the node. +All ROS-specific arguments have to be specified after a ``--ros-args`` flag: + + +.. code-block:: console + + $ ros2 run my_package node_executable --ros-args ... + + +For more details, see `this design doc `__. + +Name remapping +-------------- + +Names within a node (e.g. topics/services) can be remapped using the syntax ``-r :=``. +The name/namespace of the node itself can be remapped using ``-r __node:=`` and ``-r __ns:=``. + + +Note that these remappings are "static" remappings, in that they apply for the lifetime of the node. +"Dynamic" remapping of names after nodes have been started is not yet supported. + +See `this design doc `__ for more details on remapping arguments (not all functionality is available yet). + +Example +^^^^^^^ + +The following invocation will cause the ``talker`` node to be started under the node name ``my_talker``, publishing on the topic named ``my_topic`` instead of the default of ``chatter``. +The namespace, which must start with a forward slash, is set to ``/demo``, which means that topics are created in that namespace (``/demo/my_topic``), as opposed to globally (``/my_topic``). + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args -r __ns:=/demo -r __node:=my_talker -r chatter:=my_topic + +Passing remapping arguments to specific nodes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If multiple nodes are being run within a single process (e.g. using :doc:`Composition <../../ROS-Framework/nodes/About-Composition>`), remapping arguments can be passed to a specific node using its name as a prefix. +For example, the following will pass the remapping arguments to the specified nodes: + +.. code-block:: console + + $ ros2 run composition manual_composition --ros-args -r talker:__node:=my_talker -r listener:__node:=my_listener + + +The following example will both change the node name and remap a topic (node and namespace changes are always applied *before* topic remapping): + +.. code-block:: console + + $ ros2 run composition manual_composition --ros-args -r talker:__node:=my_talker -r my_talker:chatter:=my_topic -r listener:__node:=my_listener -r my_listener:chatter:=my_topic + + +Logger configuration +-------------------- + +The per-node logging level can be specified using the ``--log-level`` command line argument. +The executable log file name prefix, which includes all nodes in the executable, can be specified using ``--log-file-name`` command line argument. +For more information please see :doc:`the logging page `. + +Parameters +---------- + +.. _NodeArgsParameters: + +Setting parameters directly from the command line +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can set parameters directly from the command line using the following syntax: + +.. code-block:: console + + $ ros2 run package_name executable_name --ros-args -p param_name:=param_value + +As an example, you can run: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp parameter_blackboard --ros-args -p some_int:=42 -p "a_string:=Hello world" -p "some_lists.some_integers:=[1, 2, 3, 4]" -p "some_lists.some_doubles:=[3.14, 2.718]" + +Other nodes will be able to retrieve the parameter values, e.g.: + +.. code-block:: console + + $ ros2 param list parameter_blackboard + a_string + qos_overrides./parameter_events.publisher.depth + qos_overrides./parameter_events.publisher.durability + qos_overrides./parameter_events.publisher.history + qos_overrides./parameter_events.publisher.reliability + some_int + some_lists.some_doubles + some_lists.some_integers + use_sim_time + +Setting parameters from YAML files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Parameters can be set from the command-line in the form of yaml files. + +`See here `__ for examples of the yaml file syntax. + +As an example, save the following as ``demo_params.yaml``: + +.. code-block:: yaml + + parameter_blackboard: + ros__parameters: + some_int: 42 + a_string: "Hello world" + some_lists: + some_integers: [1, 2, 3, 4] + some_doubles : [3.14, 2.718] + + /**: + ros__parameters: + wildcard_full: "Full wildcard for any namespaces and any node names" + + /**/parameter_blackboard: + ros__parameters: + wildcard_namespace: "Wildcard for a specific node name under any namespace" + + /*: + ros__parameters: + wildcard_nodename_root_namespace: "Wildcard for any node names, but only in root namespace" + + +.. note:: + + Wildcards can be used for node names and namespaces. + ``*`` matches a single token delimited by slashes (``/``). + ``**`` matches zero or more tokens delimited by slashes. + Partial matches are not allowed (e.g. ``foo*``). + + +Then either declare the parameters within your node with `declare_parameter `__ or `declare_parameters `__, or `set the node to automatically declare parameters `__ if they were passed in via a command line override. + +Then run the following: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp parameter_blackboard --ros-args --params-file demo_params.yaml + + +Other nodes will be able to retrieve the parameter values, e.g.: + +.. code-block:: console + + $ ros2 param list parameter_blackboard + a_string + qos_overrides./parameter_events.publisher.depth + qos_overrides./parameter_events.publisher.durability + qos_overrides./parameter_events.publisher.history + qos_overrides./parameter_events.publisher.reliability + some_int + some_lists.some_doubles + some_lists.some_integers + use_sim_time + wildcard_full + wildcard_namespace + wildcard_nodename_root_namespace \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst b/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst index 2cba9b8a6cc..59ef7698679 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst @@ -1,111 +1,115 @@ -Publishing messages using YAML files -==================================== - -**Goal:** Record and replay topics using YAML files. - -**Tutorial level:** Intermediate - -**Time:** 5 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Overview --------- - -Publishing ROS 2 messages via CLI is straightforward for simple types like {interface(std_msgs/msg/Bool)} or {interface(std_msgs/msg/String)}. -However, it becomes tedious for complex message structures. -This tutorial demonstrates how to use ``ros2 echo`` and ``ros2 pub`` with YAML files to record, edit, and replay topic data efficiently. - -Prerequisites -------------- - -This tutorial uses concepts like ROS 2 topics and CLI tools covered in the following tutorial: - -- :doc:`Understanding topics <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` - -Tasks ------ - -We assume that an entity is publishing a {interface(geometry_msgs/msg/Twist)} message through a topic named ``cmd_vel`` and we want to capture the message, edit it and publish it to a topic. -We can use the ``echo`` verb to capture the message and save it in a YAML file ``cmd_vel.yaml`` using the output redirection operator ``>``. - -.. code-block:: console - - $ ros2 topic echo --once /cmd_vel > cmd_vel.yaml - -This creates a ``cmd_vel.yaml`` file with the following content in the directory the command was executed: - -.. code-block:: yaml - - linear: - x: 1.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -To publish a message, we utilize the ``--yaml-file`` option available with the ``pub`` verb of the ``ros2 topic`` command. -First, we specify the target topic—in this case, ``/cmd_vel``, followed by the message type {interface(geometry_msgs/msg/Twist)}. -Lastly, we specify the YAML file containing the message data. -The following command will publish the message contained in the ``YAML`` file to the designated ``topic`` once. - -.. code-block:: console - - $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml - publisher: beginning loop - publishing geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - -You can also publish more than once by adding more data to the YAML file as demonstrated in the example below. -In this case two messages where added to the YAML file with different values. - -.. code-block:: yaml - - linear: - x: 1.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - linear: - x: 3.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -By executing the same command as before, we publish three different messages to the ``/cmd_vel`` topic. - -.. code-block:: console - - $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml - publisher: beginning loop - publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - - publishing #2: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=3.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - - publishing #3: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - -Next steps ----------- - -If you are interested in publishing multiple topics using the CLI, you can take a look at the :doc:`Recording and playing back data <../Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` tutorial. +.. redirect-from:: + + Tutorials/Intermediate/Publishing-Messages-Using-YAML-Files + +Publishing messages using YAML files +==================================== + +**Goal:** Record and replay topics using YAML files. + +**Tutorial level:** Intermediate + +**Time:** 5 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Overview +-------- + +Publishing ROS 2 messages via CLI is straightforward for simple types like {interface(std_msgs/msg/Bool)} or {interface(std_msgs/msg/String)}. +However, it becomes tedious for complex message structures. +This tutorial demonstrates how to use ``ros2 echo`` and ``ros2 pub`` with YAML files to record, edit, and replay topic data efficiently. + +Prerequisites +------------- + +This tutorial uses concepts like ROS 2 topics and CLI tools covered in the following tutorial: + +- :doc:`Understanding topics <../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` + +Tasks +----- + +We assume that an entity is publishing a {interface(geometry_msgs/msg/Twist)} message through a topic named ``cmd_vel`` and we want to capture the message, edit it and publish it to a topic. +We can use the ``echo`` verb to capture the message and save it in a YAML file ``cmd_vel.yaml`` using the output redirection operator ``>``. + +.. code-block:: console + + $ ros2 topic echo --once /cmd_vel > cmd_vel.yaml + +This creates a ``cmd_vel.yaml`` file with the following content in the directory the command was executed: + +.. code-block:: yaml + + linear: + x: 1.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +To publish a message, we utilize the ``--yaml-file`` option available with the ``pub`` verb of the ``ros2 topic`` command. +First, we specify the target topic—in this case, ``/cmd_vel``, followed by the message type {interface(geometry_msgs/msg/Twist)}. +Lastly, we specify the YAML file containing the message data. +The following command will publish the message contained in the ``YAML`` file to the designated ``topic`` once. + +.. code-block:: console + + $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml + publisher: beginning loop + publishing geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + +You can also publish more than once by adding more data to the YAML file as demonstrated in the example below. +In this case two messages where added to the YAML file with different values. + +.. code-block:: yaml + + linear: + x: 1.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + linear: + x: 3.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +By executing the same command as before, we publish three different messages to the ``/cmd_vel`` topic. + +.. code-block:: console + + $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml + publisher: beginning loop + publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + + publishing #2: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=3.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + + publishing #3: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + +Next steps +---------- + +If you are interested in publishing multiple topics using the CLI, you can take a look at the :doc:`Recording and playing back data <../../ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` tutorial. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst index 4c23d724a4f..c7e0ae05acb 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst @@ -1,184 +1,185 @@ -.. redirect-from:: - - Tutorials/Security/Access-Controls - -.. _Access-Controls: - -Setting access controls -======================= - -**Goal:** Limit the topics a node can use. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- - -Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. - -Permissions are quite flexible and can be used to control many behaviors within the ROS graph. - -For this tutorial, we demonstrate a policy which only allows publishing messages on the default ``chatter`` topic. -This would prevent, for instance, remapping the topic when launching the listener or using the same security enclaves for another purpose. - -In order to enforce this policy, we need to update the ``permissions.xml`` file and re-sign it before launching the node. -This can be done by modifying the permissions file by hand, or by using XML templates. - - -Modify ``permissions.xml`` -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Begin by making a backup of your permissions files, and open ``permissions.xml`` for editing: - -.. code-block:: console - - $ cd ~/sros2_demo/demo_keystore/enclaves/talker_listener/talker - $ mv permissions.p7s permissions.p7s~ - $ mv permissions.xml permissions.xml~ - $ vi permissions.xml - -We will be modifying the ```` for ```` and ````. -The topics in this XML file use the DDS naming format, not the ROS name. -Find details on mapping topic names between ROS and DDS in the `Topic and Service Names design document `_. - -Paste the following XML content into ``permissions.xml``, save the file and exit the text editor. -This shows the ``chatter`` and ``rosout`` ROS topics renamed to the DDS ``rt/chatter`` and ``rt/rosout`` topics, respectively: - -.. code-block:: xml - :emphasize-lines: 15,16,17,18,23,24 - - - - - CN=/talker_listener/talker - - 2021-06-01T16:57:53 - 2031-05-31T16:57:53 - - - - 0 - - - - rt/chatter - rt/rosout - rt/parameter_events - */talker/* - - - - - rt/parameter_events - */talker/* - - - - - - 0 - - - - ros_discovery_info - - - - - ros_discovery_info - - - - DENY - - - - -This policy allows the talker to publish on the ``chatter`` and the ``rosout`` topics. -It also includes publish and subscribe permissions needed for the talker node to manage parameters (a requirement for all nodes). -Discovery permissions remain unchanged from the original template. - - -Sign the policy file -^^^^^^^^^^^^^^^^^^^^ - -This next command creates the new S/MIME signed policy file ``permissions.p7s`` from the updated XML file ``permissions.xml``. -The file must be signed with the Permissions CA certificate, **which requires access to the Permissions CA private key**. -If the private key has been protected, additional steps may be required to unlock and use it according to your security plan. - -.. code-block:: console - - $ openssl smime -sign -text -in permissions.xml -out permissions.p7s \ - --signer permissions_ca.cert.pem \ - -inkey ~/sros2_demo/demo_keystore/private/permissions_ca.key.pem - - -Launch the node -^^^^^^^^^^^^^^^ - -With the updated permissions in place, we can launch the node successfully using the same command used in prior tutorials: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker - -However, attempting to remap the ``chatter`` topic prevents the node from launching (note that this requires the ``ROS_SECURITY_STRATEGY`` set to ``Enforce``). - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker \ - --remap chatter:=not_chatter - - -Use the templates -^^^^^^^^^^^^^^^^^ - -Security policies can quickly become confusing, so the ``sros2`` utilities add the ability to create policies from templates. -Do this by using the `sample policy file `_ provided in the ``sros2`` repository. -Let's create a policy for both the ``talker`` and the ``listener`` to only use the ``chatter`` topic. - -Begin by downloading the ``sros2`` repository with the sample policy files: - -.. code-block:: console - - $ git clone https://github.com/ros2/sros2.git /tmp/sros2 - -Then use the ``create_permission`` verb while pointing to the sample policy to generate the XML permission files: - -.. code-block:: console - - $ ros2 security create_permission demo_keystore \ - /talker_listener/talker \ - /tmp/sros2/sros2/test/policies/sample.policy.xml - $ ros2 security create_permission demo_keystore \ - /talker_listener/listener \ - /tmp/sros2/sros2/test/policies/sample.policy.xml - -These permission files allow nodes to only publish or subscribe to the ``chatter`` topic, and enable communications required for parameters. - -In one terminal with security enabled as in previous security tutorials, run the ``talker`` demo program: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker - -In another terminal do the same with the ``listener`` program: - -.. code-block:: console - - $ ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener - -At this point, your ``talker`` and ``listener`` nodes will be communicating securely using explicit access control lists. -However, the following attempt for the ``listener`` node to subscribe to a topic other than ``chatter`` will fail: - -.. code-block:: console - - $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener \ - --remap chatter:=not_chatter +.. redirect-from:: + + Tutorials/Security/Access-Controls + Tutorials/Advanced/Security/Access-Controls + +.. _Access-Controls: + +Setting access controls +======================= + +**Goal:** Limit the topics a node can use. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- + +Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. + +Permissions are quite flexible and can be used to control many behaviors within the ROS graph. + +For this tutorial, we demonstrate a policy which only allows publishing messages on the default ``chatter`` topic. +This would prevent, for instance, remapping the topic when launching the listener or using the same security enclaves for another purpose. + +In order to enforce this policy, we need to update the ``permissions.xml`` file and re-sign it before launching the node. +This can be done by modifying the permissions file by hand, or by using XML templates. + + +Modify ``permissions.xml`` +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Begin by making a backup of your permissions files, and open ``permissions.xml`` for editing: + +.. code-block:: console + + $ cd ~/sros2_demo/demo_keystore/enclaves/talker_listener/talker + $ mv permissions.p7s permissions.p7s~ + $ mv permissions.xml permissions.xml~ + $ vi permissions.xml + +We will be modifying the ```` for ```` and ````. +The topics in this XML file use the DDS naming format, not the ROS name. +Find details on mapping topic names between ROS and DDS in the `Topic and Service Names design document `_. + +Paste the following XML content into ``permissions.xml``, save the file and exit the text editor. +This shows the ``chatter`` and ``rosout`` ROS topics renamed to the DDS ``rt/chatter`` and ``rt/rosout`` topics, respectively: + +.. code-block:: xml + :emphasize-lines: 15,16,17,18,23,24 + + + + + CN=/talker_listener/talker + + 2021-06-01T16:57:53 + 2031-05-31T16:57:53 + + + + 0 + + + + rt/chatter + rt/rosout + rt/parameter_events + */talker/* + + + + + rt/parameter_events + */talker/* + + + + + + 0 + + + + ros_discovery_info + + + + + ros_discovery_info + + + + DENY + + + + +This policy allows the talker to publish on the ``chatter`` and the ``rosout`` topics. +It also includes publish and subscribe permissions needed for the talker node to manage parameters (a requirement for all nodes). +Discovery permissions remain unchanged from the original template. + + +Sign the policy file +^^^^^^^^^^^^^^^^^^^^ + +This next command creates the new S/MIME signed policy file ``permissions.p7s`` from the updated XML file ``permissions.xml``. +The file must be signed with the Permissions CA certificate, **which requires access to the Permissions CA private key**. +If the private key has been protected, additional steps may be required to unlock and use it according to your security plan. + +.. code-block:: console + + $ openssl smime -sign -text -in permissions.xml -out permissions.p7s \ + --signer permissions_ca.cert.pem \ + -inkey ~/sros2_demo/demo_keystore/private/permissions_ca.key.pem + + +Launch the node +^^^^^^^^^^^^^^^ + +With the updated permissions in place, we can launch the node successfully using the same command used in prior tutorials: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker + +However, attempting to remap the ``chatter`` topic prevents the node from launching (note that this requires the ``ROS_SECURITY_STRATEGY`` set to ``Enforce``). + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker \ + --remap chatter:=not_chatter + + +Use the templates +^^^^^^^^^^^^^^^^^ + +Security policies can quickly become confusing, so the ``sros2`` utilities add the ability to create policies from templates. +Do this by using the `sample policy file `_ provided in the ``sros2`` repository. +Let's create a policy for both the ``talker`` and the ``listener`` to only use the ``chatter`` topic. + +Begin by downloading the ``sros2`` repository with the sample policy files: + +.. code-block:: console + + $ git clone https://github.com/ros2/sros2.git /tmp/sros2 + +Then use the ``create_permission`` verb while pointing to the sample policy to generate the XML permission files: + +.. code-block:: console + + $ ros2 security create_permission demo_keystore \ + /talker_listener/talker \ + /tmp/sros2/sros2/test/policies/sample.policy.xml + $ ros2 security create_permission demo_keystore \ + /talker_listener/listener \ + /tmp/sros2/sros2/test/policies/sample.policy.xml + +These permission files allow nodes to only publish or subscribe to the ``chatter`` topic, and enable communications required for parameters. + +In one terminal with security enabled as in previous security tutorials, run the ``talker`` demo program: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args -e /talker_listener/talker + +In another terminal do the same with the ``listener`` program: + +.. code-block:: console + + $ ros2 run demo_nodes_py listener --ros-args -e /talker_listener/listener + +At this point, your ``talker`` and ``listener`` nodes will be communicating securely using explicit access control lists. +However, the following attempt for the ``listener`` node to subscribe to a topic other than ``chatter`` will fail: + +.. code-block:: console + + $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener \ + --remap chatter:=not_chatter \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst index 96900ad0ac6..c750aeadd42 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst @@ -1,216 +1,217 @@ -.. redirect-from:: - - Tutorials/Security/Examine-Traffic - -.. _Examine-Traffic: - -Examining network traffic -========================= - -**Goal:** Capture and examine raw ROS 2 network traffic. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Overview --------- - -ROS 2 communications security is all about protecting communications between nodes. -Prior tutorials enabled security, but how can you **really** tell if traffic is being encrypted? -In this tutorial we'll take a look at capturing live network traffic to show the difference between encrypted and unencrypted traffic. - -.. note:: - - ``rmw_fastrtps_cpp`` uses `Shared Memory Transport `_ by default to improve the performance in the transport layer when the endpoints are in the same host system. - Security enclaves are still applied, and data will be encrypted. - However, you cannot capture live network traffic since the data will not be on the network interface. - If you are using ``rmw_fastrtps_cpp``, you need to either go through this tutorial and use a different host system between the publisher and subscriber, or disable shared memory transport with `Enabling UDP Transport `_ and `How to set Fast-DDS XML configuration `_. - -Prerequisites -------------- - -This guide only runs on Linux, and assumes you have already :doc:`installed ROS 2 <../../../Installation>`. - -Run the demo ------------- - -Install ``tcpdump`` -^^^^^^^^^^^^^^^^^^^ - -Begin in a new terminal window by installing `tcpdump `_, a command-line tool for capturing and displaying network traffic. -Although this tutorial describes ``tcpdump`` commands, you can also use `Wireshark `_, a similar graphical tool for capturing and analyzing traffic. - -.. code-block:: console - - $ sudo apt update - $ sudo apt install tcpdump - -Run the following commands on a single machine through multiple ``ssh`` sessions. - -Start the talker and listener -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Start both the talker and the listener again, each in its own terminal. -The security environment variables are not set so security is not enabled for these sessions. -In one terminal run: - -.. code-block:: console - - $ unset ROS_SECURITY_ENABLE - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker - -In another terminal run: - -.. code-block:: console - - $ unset ROS_SECURITY_ENABLE - $ ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener - - -Display unencrypted discovery packets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -With the talker and listener running, open another terminal and start ``tcpdump`` to look at the network traffic. -You need to use ``sudo`` since reading raw network traffic is a privileged operation. - -The command below uses the ``-X`` option to print packet contents, the ``-i`` option to listen for packets on any interface, and captures only `UDP `_ port 7400 traffic. - -.. code-block:: console - - $ sudo tcpdump -X -i any udp port 7400 - 20:18:04.400770 IP 8_xterm.46392 > 239.255.0.1.7400: UDP, length 252 - 0x0000: 4500 0118 d48b 4000 0111 7399 c0a8 8007 E.....@...s..... - 0x0010: efff 0001 b538 1ce8 0104 31c6 5254 5053 .....8....1.RTPS - ... - 0x00c0: 5800 0400 3f0c 3f0c 6200 1c00 1800 0000 X...?.?.b....... - 0x00d0: 2f74 616c 6b65 725f 6c69 7374 656e 6572 /talker_listener - 0x00e0: 2f74 616c 6b65 7200 2c00 2800 2100 0000 /talker.,.(.!... - 0x00f0: 656e 636c 6176 653d 2f74 616c 6b65 725f enclave=/talker_ - 0x0100: 6c69 7374 656e 6572 2f74 616c 6b65 723b listener/talker; - 0x0110: 0000 0000 0100 0000 ........ - -This is a discovery datagram--the talker looking for subscribers. -As you can see, the node name (``/talker_listener/talker``) and the enclave (also ``/talker_listener/talker``) are passed in plain text. -You should also see similar discovery datagrams from the ``listener`` node. -Some other features of a typical discovery packet: - -- The destination address is 239.255.0.1, which is a multicast IP address; ROS 2 uses multicast traffic for discovery by default. -- UDP 7400 is the destination port, as per the `DDS-RTPS specification `_. -- The packet contains the "RTPS" tag, also as defined to the DDS-RTPS specification. - - -Display unencrypted data packets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use ``tcpdump`` to capture non-discovery RTPS packets by filtering on UDP ports above 7400. -You will see few different types of packets, but watch for something like the following which is obviously data being sent from a talker to a listener: - -.. code-block:: console - - $ sudo tcpdump -i any -X udp portrange 7401-7500 - 20:49:17.927303 IP localhost.46392 > localhost.7415: UDP, length 84 - 0x0000: 4500 0070 5b53 4000 4011 e127 7f00 0001 E..p[S@.@..'.... - 0x0010: 7f00 0001 b538 1cf7 005c fe6f 5254 5053 .....8...\.oRTPS - 0x0020: 0203 010f 010f 4874 e752 0000 0100 0000 ......Ht.R...... - 0x0030: 0901 0800 cdee b760 5bf3 5aed 1505 3000 .......`[.Z...0. - 0x0040: 0000 1000 0000 1204 0000 1203 0000 0000 ................ - 0x0050: 5708 0000 0001 0000 1200 0000 4865 6c6c W...........Hell - 0x0060: 6f20 576f 726c 643a 2032 3133 3500 0000 o.World:.2135... - -Some features to note about this packet: - -- The message contents, "Hello World: 2135", are sent in clear text -- The source and destination IP address is ``localhost``: since both nodes are running on the same machine, the nodes discovered each other on the ``localhost`` interface - - -Enable encryption -^^^^^^^^^^^^^^^^^ - -Stop both the talker and the listener nodes. -Enable encryption for both by setting the security environment variables and run them again. - -In terminal 1: - -.. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker - -In terminal 2: - -.. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - $ ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener - - -Display encrypted discovery packets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Run the same ``tcpdump`` command used earlier to examine the output of discovery traffic with encryption enabled -The typical discovery packet looks somewhat like the following: - -.. code-block:: console - - $ sudo tcpdump -X -i any udp port 7400 - 21:09:07.336617 IP 8_xterm.60409 > 239.255.0.1.7400: UDP, length 596 - 0x0000: 4500 0270 c2f6 4000 0111 83d6 c0a8 8007 E..p..@......... - 0x0010: efff 0001 ebf9 1ce8 025c 331e 5254 5053 .........\3.RTPS - 0x0020: 0203 010f bbdd 199c 7522 b6cb 699f 74ae ........u"..i.t. - ... - 0x00c0: 5800 0400 3f0c ff0f 6200 2000 1a00 0000 X...?...b....... - 0x00d0: 2f74 616c 6b65 725f 6c69 7374 656e 6572 /talker_listener - 0x00e0: 2f6c 6973 7465 6e65 7200 0000 2c00 2800 /listener...,.(. - 0x00f0: 2300 0000 656e 636c 6176 653d 2f74 616c #...enclave=/tal - 0x0100: 6b65 725f 6c69 7374 656e 6572 2f6c 6973 ker_listener/lis - 0x0110: 7465 6e65 723b 0000 0110 c400 1400 0000 tener;.......... - 0x0120: 4444 533a 4175 7468 3a50 4b49 2d44 483a DDS:Auth:PKI-DH: - 0x0130: 312e 3000 0400 0000 0c00 0000 6464 732e 1.0.........dds. - ... - 0x0230: 1100 0000 6464 732e 7065 726d 5f63 612e ....dds.perm_ca. - 0x0240: 616c 676f 0000 0000 0d00 0000 4543 4453 algo........ECDS - 0x0250: 412d 5348 4132 3536 0000 0000 0000 0000 A-SHA256........ - 0x0260: 0510 0800 0700 0080 0600 0080 0100 0000 ................ - -This packet is much larger and includes information which can be used to set up encryption among ROS nodes. -As we will see shortly, this actually includes some of the security configuration files that were created when we enabled security. -Interested in learning more? -Take a look at the excellent paper `Network Reconnaissance and Vulnerability Excavation of Secure DDS Systems `_ to understand why this matters. - - -Display encrypted data packets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now use ``tcpdump`` to capture data packets. -A typical data packet looks like the following: - -.. code-block:: console - - $ sudo tcpdump -i any -X udp portrange 7401-7500 - 21:18:14.531102 IP localhost.54869 > localhost.7415: UDP, length 328 - 0x0000: 4500 0164 bb42 4000 4011 8044 7f00 0001 E..d.B@.@..D.... - 0x0010: 7f00 0001 d655 1cf7 0150 ff63 5254 5053 .....U...P.cRTPS - 0x0020: 0203 010f daf7 10ce d977 449b bb33 f04a .........wD..3.J - 0x0030: 3301 1400 0000 0003 492a 6066 8603 cdb5 3.......I*`f.... - 0x0040: 9df6 5da6 8402 2136 0c01 1400 0000 0000 ..]...!6........ - 0x0050: 0203 010f daf7 10ce d977 449b bb33 f04a .........wD..3.J - ... - 0x0130: 7905 d390 3201 1400 3ae5 0b60 3906 967e y...2...:..`9..~ - 0x0140: 5b17 fd42 de95 54b9 0000 0000 3401 1400 [..B..T.....4... - 0x0150: 42ae f04d 0559 84c5 7116 1c51 91ba 3799 B..M.Y..q..Q..7. - 0x0160: 0000 0000 .... - -The data in this RTPS packet is all encrypted. - -In addition to this data packet, you should see additional packets with node and enclave names; these support other ROS features such as parameters and services. -Encryption options for these packets can also be controlled by security policy. +.. redirect-from:: + + Tutorials/Security/Examine-Traffic + Tutorials/Advanced/Security/Examine-Traffic + +.. _Examine-Traffic: + +Examining network traffic +========================= + +**Goal:** Capture and examine raw ROS 2 network traffic. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Overview +-------- + +ROS 2 communications security is all about protecting communications between nodes. +Prior tutorials enabled security, but how can you **really** tell if traffic is being encrypted? +In this tutorial we'll take a look at capturing live network traffic to show the difference between encrypted and unencrypted traffic. + +.. note:: + + ``rmw_fastrtps_cpp`` uses `Shared Memory Transport `_ by default to improve the performance in the transport layer when the endpoints are in the same host system. + Security enclaves are still applied, and data will be encrypted. + However, you cannot capture live network traffic since the data will not be on the network interface. + If you are using ``rmw_fastrtps_cpp``, you need to either go through this tutorial and use a different host system between the publisher and subscriber, or disable shared memory transport with `Enabling UDP Transport `_ and `How to set Fast-DDS XML configuration `_. + +Prerequisites +------------- + +This guide only runs on Linux, and assumes you have already :doc:`installed ROS 2 <../../../Get-Started/Installation>`. + +Run the demo +------------ + +Install ``tcpdump`` +^^^^^^^^^^^^^^^^^^^ + +Begin in a new terminal window by installing `tcpdump `_, a command-line tool for capturing and displaying network traffic. +Although this tutorial describes ``tcpdump`` commands, you can also use `Wireshark `_, a similar graphical tool for capturing and analyzing traffic. + +.. code-block:: console + + $ sudo apt update + $ sudo apt install tcpdump + +Run the following commands on a single machine through multiple ``ssh`` sessions. + +Start the talker and listener +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Start both the talker and the listener again, each in its own terminal. +The security environment variables are not set so security is not enabled for these sessions. +In one terminal run: + +.. code-block:: console + + $ unset ROS_SECURITY_ENABLE + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker + +In another terminal run: + +.. code-block:: console + + $ unset ROS_SECURITY_ENABLE + $ ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener + + +Display unencrypted discovery packets +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +With the talker and listener running, open another terminal and start ``tcpdump`` to look at the network traffic. +You need to use ``sudo`` since reading raw network traffic is a privileged operation. + +The command below uses the ``-X`` option to print packet contents, the ``-i`` option to listen for packets on any interface, and captures only `UDP `_ port 7400 traffic. + +.. code-block:: console + + $ sudo tcpdump -X -i any udp port 7400 + 20:18:04.400770 IP 8_xterm.46392 > 239.255.0.1.7400: UDP, length 252 + 0x0000: 4500 0118 d48b 4000 0111 7399 c0a8 8007 E.....@...s..... + 0x0010: efff 0001 b538 1ce8 0104 31c6 5254 5053 .....8....1.RTPS + ... + 0x00c0: 5800 0400 3f0c 3f0c 6200 1c00 1800 0000 X...?.?.b....... + 0x00d0: 2f74 616c 6b65 725f 6c69 7374 656e 6572 /talker_listener + 0x00e0: 2f74 616c 6b65 7200 2c00 2800 2100 0000 /talker.,.(.!... + 0x00f0: 656e 636c 6176 653d 2f74 616c 6b65 725f enclave=/talker_ + 0x0100: 6c69 7374 656e 6572 2f74 616c 6b65 723b listener/talker; + 0x0110: 0000 0000 0100 0000 ........ + +This is a discovery datagram--the talker looking for subscribers. +As you can see, the node name (``/talker_listener/talker``) and the enclave (also ``/talker_listener/talker``) are passed in plain text. +You should also see similar discovery datagrams from the ``listener`` node. +Some other features of a typical discovery packet: + +- The destination address is 239.255.0.1, which is a multicast IP address; ROS 2 uses multicast traffic for discovery by default. +- UDP 7400 is the destination port, as per the `DDS-RTPS specification `_. +- The packet contains the "RTPS" tag, also as defined to the DDS-RTPS specification. + + +Display unencrypted data packets +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Use ``tcpdump`` to capture non-discovery RTPS packets by filtering on UDP ports above 7400. +You will see few different types of packets, but watch for something like the following which is obviously data being sent from a talker to a listener: + +.. code-block:: console + + $ sudo tcpdump -i any -X udp portrange 7401-7500 + 20:49:17.927303 IP localhost.46392 > localhost.7415: UDP, length 84 + 0x0000: 4500 0070 5b53 4000 4011 e127 7f00 0001 E..p[S@.@..'.... + 0x0010: 7f00 0001 b538 1cf7 005c fe6f 5254 5053 .....8...\.oRTPS + 0x0020: 0203 010f 010f 4874 e752 0000 0100 0000 ......Ht.R...... + 0x0030: 0901 0800 cdee b760 5bf3 5aed 1505 3000 .......`[.Z...0. + 0x0040: 0000 1000 0000 1204 0000 1203 0000 0000 ................ + 0x0050: 5708 0000 0001 0000 1200 0000 4865 6c6c W...........Hell + 0x0060: 6f20 576f 726c 643a 2032 3133 3500 0000 o.World:.2135... + +Some features to note about this packet: + +- The message contents, "Hello World: 2135", are sent in clear text +- The source and destination IP address is ``localhost``: since both nodes are running on the same machine, the nodes discovered each other on the ``localhost`` interface + + +Enable encryption +^^^^^^^^^^^^^^^^^ + +Stop both the talker and the listener nodes. +Enable encryption for both by setting the security environment variables and run them again. + +In terminal 1: + +.. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker + +In terminal 2: + +.. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + $ ros2 run demo_nodes_cpp listener --ros-args --enclave /talker_listener/listener + + +Display encrypted discovery packets +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Run the same ``tcpdump`` command used earlier to examine the output of discovery traffic with encryption enabled +The typical discovery packet looks somewhat like the following: + +.. code-block:: console + + $ sudo tcpdump -X -i any udp port 7400 + 21:09:07.336617 IP 8_xterm.60409 > 239.255.0.1.7400: UDP, length 596 + 0x0000: 4500 0270 c2f6 4000 0111 83d6 c0a8 8007 E..p..@......... + 0x0010: efff 0001 ebf9 1ce8 025c 331e 5254 5053 .........\3.RTPS + 0x0020: 0203 010f bbdd 199c 7522 b6cb 699f 74ae ........u"..i.t. + ... + 0x00c0: 5800 0400 3f0c ff0f 6200 2000 1a00 0000 X...?...b....... + 0x00d0: 2f74 616c 6b65 725f 6c69 7374 656e 6572 /talker_listener + 0x00e0: 2f6c 6973 7465 6e65 7200 0000 2c00 2800 /listener...,.(. + 0x00f0: 2300 0000 656e 636c 6176 653d 2f74 616c #...enclave=/tal + 0x0100: 6b65 725f 6c69 7374 656e 6572 2f6c 6973 ker_listener/lis + 0x0110: 7465 6e65 723b 0000 0110 c400 1400 0000 tener;.......... + 0x0120: 4444 533a 4175 7468 3a50 4b49 2d44 483a DDS:Auth:PKI-DH: + 0x0130: 312e 3000 0400 0000 0c00 0000 6464 732e 1.0.........dds. + ... + 0x0230: 1100 0000 6464 732e 7065 726d 5f63 612e ....dds.perm_ca. + 0x0240: 616c 676f 0000 0000 0d00 0000 4543 4453 algo........ECDS + 0x0250: 412d 5348 4132 3536 0000 0000 0000 0000 A-SHA256........ + 0x0260: 0510 0800 0700 0080 0600 0080 0100 0000 ................ + +This packet is much larger and includes information which can be used to set up encryption among ROS nodes. +As we will see shortly, this actually includes some of the security configuration files that were created when we enabled security. +Interested in learning more? +Take a look at the excellent paper `Network Reconnaissance and Vulnerability Excavation of Secure DDS Systems `_ to understand why this matters. + + +Display encrypted data packets +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now use ``tcpdump`` to capture data packets. +A typical data packet looks like the following: + +.. code-block:: console + + $ sudo tcpdump -i any -X udp portrange 7401-7500 + 21:18:14.531102 IP localhost.54869 > localhost.7415: UDP, length 328 + 0x0000: 4500 0164 bb42 4000 4011 8044 7f00 0001 E..d.B@.@..D.... + 0x0010: 7f00 0001 d655 1cf7 0150 ff63 5254 5053 .....U...P.cRTPS + 0x0020: 0203 010f daf7 10ce d977 449b bb33 f04a .........wD..3.J + 0x0030: 3301 1400 0000 0003 492a 6066 8603 cdb5 3.......I*`f.... + 0x0040: 9df6 5da6 8402 2136 0c01 1400 0000 0000 ..]...!6........ + 0x0050: 0203 010f daf7 10ce d977 449b bb33 f04a .........wD..3.J + ... + 0x0130: 7905 d390 3201 1400 3ae5 0b60 3906 967e y...2...:..`9..~ + 0x0140: 5b17 fd42 de95 54b9 0000 0000 3401 1400 [..B..T.....4... + 0x0150: 42ae f04d 0559 84c5 7116 1c51 91ba 3799 B..M.Y..q..Q..7. + 0x0160: 0000 0000 .... + +The data in this RTPS packet is all encrypted. + +In addition to this data packet, you should see additional packets with node and enclave names; these support other ROS features such as parameters and services. +Encryption options for these packets can also be controlled by security policy. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst index 4a8931d8399..e9bac8a9e0d 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst @@ -1,413 +1,414 @@ -.. redirect-from:: - - Tutorials/Security/Introducing-ros2-security - -.. _sros2: -.. _ROS-2-Security-Tutorials: - -Setting up security -=================== - -**Goal:** Set up security with ``sros2``. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 3 - :local: - - -Background ----------- - -The ``sros2`` package provides the tools and instructions to use ROS 2 on top of DDS-Security. -The security features have been tested across platforms (Linux, macOS, and Windows) as well as across different languages (C++ and Python). -The SROS2 has been designed to work with any secure middleware, although not all middleware is open source and support varies depending on the ROS distribution in use. - -Installation ------------- - -Typically security is available following installation using the :doc:`ROS 2 Installation Guide <../../../Installation>` and the :doc:`configuration guide <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>`. -However, if you intend to install from source or switch middleware implementations, consider the following caveats: - - -Installing from source -^^^^^^^^^^^^^^^^^^^^^^ - -Before installing from source, you will need to have a recent version openssl (1.0.2g or later) installed: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ sudo apt update - $ sudo apt install libssl-dev - - .. group-tab:: MacOS - - .. code-block:: console - - $ brew install openssl - - You will need to have OpenSSL on your library path to run DDS-Security demos. - Run the following command, and consider adding to your ``~/.bash_profile``: - - .. code-block:: console - - $ export DYLD_LIBRARY_PATH=`brew --prefix openssl`/lib:$DYLD_LIBRARY_PATH - $ export OPENSSL_ROOT_DIR=`brew --prefix openssl` - - - .. group-tab:: Windows - - If you don't have OpenSSL installed, please follow :ref:`these instructions ` - -Fast DDS requires an additional CMake flag to build the security plugins, so the colcon invocation needs to be modified to pass: - -.. code-block:: console - - $ colcon build --symlink-install --cmake-args -DSECURITY=ON --packages-select fastdds rmw_fastrtps_cpp rmw_fastrtps_dynamic_cpp rmw_fastrtps_shared_cpp - - -Selecting an alternate middleware -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you choose not to use the default middleware implementation, be sure to :doc:`change your RMW implementation <../../../Installation/RMW-Implementations/>` before proceeding. - -ROS 2 allows you to change the RMW implementation at runtime. -See `how to work with multiple RMW implementations <../../../How-To-Guides/Working-with-multiple-RMW-implementations>` to explore different middleware implementations. - -Note that secure communication between vendors is not supported. - -Run the demo ------------- - -1) Create a folder for the security files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Begin by creating folder to store all the files necessary for this demo: - - .. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir ~/sros2_demo - - .. group-tab:: MacOS - - .. code-block:: console - - $ mkdir ~/sros2_demo - - .. group-tab:: Windows - - .. code-block:: console - - $ md C:\dev\ros2\sros2_demo - -2) Generate a keystore -^^^^^^^^^^^^^^^^^^^^^^^ - -Use the ``sros2`` utilities to create the keystore. -Files in the keystore will be used to enable security for all the participants in the ROS 2 graph. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/sros2_demo - $ ros2 security create_keystore demo_keystore - - .. group-tab:: MacOS - - .. code-block:: console - - $ cd ~/sros2_demo - $ ros2 security create_keystore demo_keystore - - .. group-tab:: Windows - - .. code-block:: console - - $ cd sros2_demo - $ ros2 security create_keystore demo_keystore - -3) Generate keys and certificates -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Once the keystore is created, create keys and certificates for each node with security enabled. -For our demo, that includes the talker and listener nodes. -This command uses the ``create_enclave`` feature which is covered in more detail in the next tutorial. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ ros2 security create_enclave demo_keystore /talker_listener/talker - $ ros2 security create_enclave demo_keystore /talker_listener/listener - - .. group-tab:: MacOS - - .. code-block:: console - - $ ros2 security create_enclave demo_keystore /talker_listener/talker - $ ros2 security create_enclave demo_keystore /talker_listener/listener - - .. group-tab:: Windows - - .. code-block:: console - - $ ros2 security create_enclave demo_keystore /talker_listener/talker - $ ros2 security create_enclave demo_keystore /talker_listener/listener - - - If ``unable to write 'random state'`` appears then set the environment variable ``RANDFILE``. - - .. code-block:: console - - $ set RANDFILE=C:\dev\ros2\sros2_demo\.rnd - - Then re-run the commands above. - -If the selected RMW implementation is Zenoh, then the Zenoh router also requires its own keys and certificates: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: bash - - ros2 security create_enclave demo_keystore /zenohd - - .. group-tab:: MacOS - - .. code-block:: bash - - ros2 security create_enclave demo_keystore /zenohd - - .. group-tab:: Windows - - .. code-block:: bat - - ros2 security create_enclave demo_keystore /zenohd - - - If ``unable to write 'random state'`` appears then set the environment variable ``RANDFILE``. - - .. code-block:: bat - - set RANDFILE=C:\dev\ros2\sros2_demo\.rnd - - Then re-run the commands above. - -4) Configure environment variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Three environment variables allow the middleware to locate encryption materials and enable (and possibly enforce) security. -These and other security-related environment variables are described in the `ROS 2 DDS-Security Integration design document `_. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - - .. group-tab:: MacOS - - .. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_SECURITY_KEYSTORE=%cd%/demo_keystore - $ set ROS_SECURITY_ENABLE=true - $ set ROS_SECURITY_STRATEGY=Enforce - -These variables need to be defined in each terminal used for the demo. -For convenience you can add them to your boot environment. - -4\.1\. Zenoh -"""""""""""" - -The RMW implementation Zenoh has its own tools to configure security, in particular a package called `zenoh_security_tools `_. -It contains the ``generate_configs`` executable which generates Zenoh session config files with access control, authentication and encryption parameters -based on policies and keystores generated using sros2. - -5) Run the ``talker/listener`` demo -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Begin the demo by launching the talker node. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker - -In another terminal, do the same to launch the ``listener`` node. -The environment variables in this terminal must be properly set as described in step 4 above. - -.. code-block:: console - - $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener - -If the RMW implementation is ``rmw_zenoh_cpp``, in another terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: bash - - export ZENOH_ROUTER_CONFIG_URI=~/sros2_demo/zenohd - ros2 run rmw_zenoh_cpp zenohd - - .. group-tab:: MacOS - - .. code-block:: bash - - export ZENOH_ROUTER_CONFIG_URI= - ros2 run rmw_zenoh_cpp zenohd - - .. group-tab:: Windows - - .. code-block:: bat - - set ZENOH_ROUTER_CONFIG_URI= - ros2 run rmw_zenoh_cpp zenohd - -These nodes will be communicating using authentication and encryption! -If you look at the packet contents (for example, using ``tcpdump`` or ``Wireshark`` as covered in another tutorial), you can see that the messages are encrypted. - -Note: You can switch between the C++ (demo_nodes_cpp) and Python (demo_nodes_py) packages arbitrarily. - -These nodes are able to communicate because we have created the appropriate keys and certificates for them. - -Leave both nodes running as you use ``ros2cli`` and answer the questions below. - - -6) Use ``ros2cli`` with security -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To use ``ros2cli`` to iterate with ROS 2 secured network, you need to provide it with override enclave by ``ROS_SECURITY_ENCLAVE_OVERRIDE`` environmental variable. -Open an another terminal and set up the following environmental variables. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - $ export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener - - .. group-tab:: MacOS - - .. code-block:: console - - $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore - $ export ROS_SECURITY_ENABLE=true - $ export ROS_SECURITY_STRATEGY=Enforce - $ export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_SECURITY_KEYSTORE=%cd%/demo_keystore - $ set ROS_SECURITY_ENABLE=true - $ set ROS_SECURITY_STRATEGY=Enforce - $ set ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener - - -Now you can use ``ros2cli`` to communicate with ROS 2 secured network. - -.. code-block:: console - - $ ros2 node list --no-daemon --spin-time 3 - [INFO] [1733862009.410918416] [rcl]: Found security directory: /root/ros2_ws/colcon_ws/demo_keystore/enclaves/talker_listener/talker - /listener - /talker - -.. code-block:: console - - $ ros2 topic list --no-daemon --spin-time 3 - [INFO] [1733861998.562163611] [rcl]: Found security directory: /root/ros2_ws/colcon_ws/demo_keystore/enclaves/talker_listener/talker - /chatter - /parameter_events - /rosout - -.. note:: - - Avoid using ros2 daemon because it may not have security enclaves, and enough time duration should be given for the discovery in ROS 2 secured network. - - -Take the Quiz! --------------- - -.. tabs:: - - .. group-tab:: Question 1 - - Open another terminal session, but **do not** set the environment variables so that security is not enabled. - Start the listener. - What do you expect to happen? - - .. group-tab:: Answer 1 - - The listener launches but does not receive any messages. - All traffic is encrypted, and without security enabled the listener does not receive anything. - - -.. tabs:: - - .. group-tab:: Question 2 - - Stop the listener, set the environment variable ``ROS_SECURITY_ENABLE`` to ``true`` and start the listener again. - What results do you expect this time? - - .. group-tab:: Answer 2 - - The listener still launches but does not receive messages. - Although security has now been enabled, it is not been configured properly since ROS is unable to locate the key files. - The listener launches, but in non-secure mode since security is not enforced, which means that although the properly configured talker is sending encrypted messages, this listener is unable to decrypt them. - -.. tabs:: - - .. group-tab:: Question 3 - - Stop the listener and set ``ROS_SECURITY_STRATEGY`` to ``Enforce``. - What happens now? - - .. group-tab:: Answer 3 - - The listener fails to launch. - Security has been enabled and is being enforced. - Since it still is not properly configured, an error is thrown rather than launching in non-secure mode. - - -Learn More! ------------ - -Are you ready to go further with ROS Security? -Take a look at the `Secure Turtlebot2 Demo `_. -You'll find a functioning and complex implementation of ROS 2 security, ready to try out your own custom scenarios. -Be sure to create pull requests and issues here so we can continue improving security support in ROS! +.. redirect-from:: + + Tutorials/Security/Introducing-ros2-security + Tutorials/Advanced/Security/Introducing-ros2-security + +.. _sros2: +.. _ROS-2-Security-Tutorials: + +Setting up security +=================== + +**Goal:** Set up security with ``sros2``. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 3 + :local: + + +Background +---------- + +The ``sros2`` package provides the tools and instructions to use ROS 2 on top of DDS-Security. +The security features have been tested across platforms (Linux, macOS, and Windows) as well as across different languages (C++ and Python). +The SROS2 has been designed to work with any secure middleware, although not all middleware is open source and support varies depending on the ROS distribution in use. + +Installation +------------ + +Typically security is available following installation using the :doc:`ROS 2 Installation Guide <../../../Get-Started/Installation>` and the :doc:`configuration guide <../../../Get-Started/Configuring-ROS2-Environment>`. +However, if you intend to install from source or switch middleware implementations, consider the following caveats: + + +Installing from source +^^^^^^^^^^^^^^^^^^^^^^ + +Before installing from source, you will need to have a recent version openssl (1.0.2g or later) installed: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ sudo apt update + $ sudo apt install libssl-dev + + .. group-tab:: MacOS + + .. code-block:: console + + $ brew install openssl + + You will need to have OpenSSL on your library path to run DDS-Security demos. + Run the following command, and consider adding to your ``~/.bash_profile``: + + .. code-block:: console + + $ export DYLD_LIBRARY_PATH=`brew --prefix openssl`/lib:$DYLD_LIBRARY_PATH + $ export OPENSSL_ROOT_DIR=`brew --prefix openssl` + + + .. group-tab:: Windows + + If you don't have OpenSSL installed, please follow :ref:`these instructions ` + +Fast DDS requires an additional CMake flag to build the security plugins, so the colcon invocation needs to be modified to pass: + +.. code-block:: console + + $ colcon build --symlink-install --cmake-args -DSECURITY=ON --packages-select fastdds rmw_fastrtps_cpp rmw_fastrtps_dynamic_cpp rmw_fastrtps_shared_cpp + + +Selecting an alternate middleware +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you choose not to use the default middleware implementation, be sure to :doc:`change your RMW implementation <../../../Get-Started/Installation/RMW-Implementations>` before proceeding. + +ROS 2 allows you to change the RMW implementation at runtime. +See `how to work with multiple RMW implementations <../../../How-To-Guides/Working-with-multiple-RMW-implementations>` to explore different middleware implementations. + +Note that secure communication between vendors is not supported. + +Run the demo +------------ + +1) Create a folder for the security files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + Begin by creating folder to store all the files necessary for this demo: + + .. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir ~/sros2_demo + + .. group-tab:: MacOS + + .. code-block:: console + + $ mkdir ~/sros2_demo + + .. group-tab:: Windows + + .. code-block:: console + + $ md C:\dev\ros2\sros2_demo + +2) Generate a keystore +^^^^^^^^^^^^^^^^^^^^^^^ + +Use the ``sros2`` utilities to create the keystore. +Files in the keystore will be used to enable security for all the participants in the ROS 2 graph. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/sros2_demo + $ ros2 security create_keystore demo_keystore + + .. group-tab:: MacOS + + .. code-block:: console + + $ cd ~/sros2_demo + $ ros2 security create_keystore demo_keystore + + .. group-tab:: Windows + + .. code-block:: console + + $ cd sros2_demo + $ ros2 security create_keystore demo_keystore + +3) Generate keys and certificates +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Once the keystore is created, create keys and certificates for each node with security enabled. +For our demo, that includes the talker and listener nodes. +This command uses the ``create_enclave`` feature which is covered in more detail in the next tutorial. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ ros2 security create_enclave demo_keystore /talker_listener/talker + $ ros2 security create_enclave demo_keystore /talker_listener/listener + + .. group-tab:: MacOS + + .. code-block:: console + + $ ros2 security create_enclave demo_keystore /talker_listener/talker + $ ros2 security create_enclave demo_keystore /talker_listener/listener + + .. group-tab:: Windows + + .. code-block:: console + + $ ros2 security create_enclave demo_keystore /talker_listener/talker + $ ros2 security create_enclave demo_keystore /talker_listener/listener + + + If ``unable to write 'random state'`` appears then set the environment variable ``RANDFILE``. + + .. code-block:: console + + $ set RANDFILE=C:\dev\ros2\sros2_demo\.rnd + + Then re-run the commands above. + +If the selected RMW implementation is Zenoh, then the Zenoh router also requires its own keys and certificates: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: bash + + ros2 security create_enclave demo_keystore /zenohd + + .. group-tab:: MacOS + + .. code-block:: bash + + ros2 security create_enclave demo_keystore /zenohd + + .. group-tab:: Windows + + .. code-block:: bat + + ros2 security create_enclave demo_keystore /zenohd + + + If ``unable to write 'random state'`` appears then set the environment variable ``RANDFILE``. + + .. code-block:: bat + + set RANDFILE=C:\dev\ros2\sros2_demo\.rnd + + Then re-run the commands above. + +4) Configure environment variables +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Three environment variables allow the middleware to locate encryption materials and enable (and possibly enforce) security. +These and other security-related environment variables are described in the `ROS 2 DDS-Security Integration design document `_. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + + .. group-tab:: MacOS + + .. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_SECURITY_KEYSTORE=%cd%/demo_keystore + $ set ROS_SECURITY_ENABLE=true + $ set ROS_SECURITY_STRATEGY=Enforce + +These variables need to be defined in each terminal used for the demo. +For convenience you can add them to your boot environment. + +4\.1\. Zenoh +"""""""""""" + +The RMW implementation Zenoh has its own tools to configure security, in particular a package called `zenoh_security_tools `_. +It contains the ``generate_configs`` executable which generates Zenoh session config files with access control, authentication and encryption parameters +based on policies and keystores generated using sros2. + +5) Run the ``talker/listener`` demo +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Begin the demo by launching the talker node. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker + +In another terminal, do the same to launch the ``listener`` node. +The environment variables in this terminal must be properly set as described in step 4 above. + +.. code-block:: console + + $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener + +If the RMW implementation is ``rmw_zenoh_cpp``, in another terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: bash + + export ZENOH_ROUTER_CONFIG_URI=~/sros2_demo/zenohd + ros2 run rmw_zenoh_cpp zenohd + + .. group-tab:: MacOS + + .. code-block:: bash + + export ZENOH_ROUTER_CONFIG_URI= + ros2 run rmw_zenoh_cpp zenohd + + .. group-tab:: Windows + + .. code-block:: bat + + set ZENOH_ROUTER_CONFIG_URI= + ros2 run rmw_zenoh_cpp zenohd + +These nodes will be communicating using authentication and encryption! +If you look at the packet contents (for example, using ``tcpdump`` or ``Wireshark`` as covered in another tutorial), you can see that the messages are encrypted. + +Note: You can switch between the C++ (demo_nodes_cpp) and Python (demo_nodes_py) packages arbitrarily. + +These nodes are able to communicate because we have created the appropriate keys and certificates for them. + +Leave both nodes running as you use ``ros2cli`` and answer the questions below. + + +6) Use ``ros2cli`` with security +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To use ``ros2cli`` to iterate with ROS 2 secured network, you need to provide it with override enclave by ``ROS_SECURITY_ENCLAVE_OVERRIDE`` environmental variable. +Open an another terminal and set up the following environmental variables. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + $ export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener + + .. group-tab:: MacOS + + .. code-block:: console + + $ export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore + $ export ROS_SECURITY_ENABLE=true + $ export ROS_SECURITY_STRATEGY=Enforce + $ export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_SECURITY_KEYSTORE=%cd%/demo_keystore + $ set ROS_SECURITY_ENABLE=true + $ set ROS_SECURITY_STRATEGY=Enforce + $ set ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener + + +Now you can use ``ros2cli`` to communicate with ROS 2 secured network. + +.. code-block:: console + + $ ros2 node list --no-daemon --spin-time 3 + [INFO] [1733862009.410918416] [rcl]: Found security directory: /root/ros2_ws/colcon_ws/demo_keystore/enclaves/talker_listener/talker + /listener + /talker + +.. code-block:: console + + $ ros2 topic list --no-daemon --spin-time 3 + [INFO] [1733861998.562163611] [rcl]: Found security directory: /root/ros2_ws/colcon_ws/demo_keystore/enclaves/talker_listener/talker + /chatter + /parameter_events + /rosout + +.. note:: + + Avoid using ros2 daemon because it may not have security enclaves, and enough time duration should be given for the discovery in ROS 2 secured network. + + +Take the Quiz! +-------------- + +.. tabs:: + + .. group-tab:: Question 1 + + Open another terminal session, but **do not** set the environment variables so that security is not enabled. + Start the listener. + What do you expect to happen? + + .. group-tab:: Answer 1 + + The listener launches but does not receive any messages. + All traffic is encrypted, and without security enabled the listener does not receive anything. + + +.. tabs:: + + .. group-tab:: Question 2 + + Stop the listener, set the environment variable ``ROS_SECURITY_ENABLE`` to ``true`` and start the listener again. + What results do you expect this time? + + .. group-tab:: Answer 2 + + The listener still launches but does not receive messages. + Although security has now been enabled, it is not been configured properly since ROS is unable to locate the key files. + The listener launches, but in non-secure mode since security is not enforced, which means that although the properly configured talker is sending encrypted messages, this listener is unable to decrypt them. + +.. tabs:: + + .. group-tab:: Question 3 + + Stop the listener and set ``ROS_SECURITY_STRATEGY`` to ``Enforce``. + What happens now? + + .. group-tab:: Answer 3 + + The listener fails to launch. + Security has been enabled and is being enforced. + Since it still is not properly configured, an error is thrown rather than launching in non-secure mode. + + +Learn More! +----------- + +Are you ready to go further with ROS Security? +Take a look at the `Secure Turtlebot2 Demo `_. +You'll find a functioning and complex implementation of ROS 2 security, ready to try out your own custom scenarios. +Be sure to create pull requests and issues here so we can continue improving security support in ROS! \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst index dc4ad4ed4f6..38168da5837 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst @@ -1,10 +1,14 @@ -Security -======== - -.. toctree:: - :maxdepth: 1 - - Introducing-ros2-security - Security-on-Two - Examine-Traffic +.. redirect-from:: + + Tutorials/Advanced/Security/Security-Main + +Security +======== + +.. toctree:: + :maxdepth: 1 + + Introducing-ros2-security + Security-on-Two + Examine-Traffic Access-Controls \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst index 4bee04bff8e..392e1cc2a00 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst @@ -1,120 +1,121 @@ -.. redirect-from:: - - Tutorials/Security/Security-on-Two - -.. _Security-on-Two: - -Ensuring security across machines -================================= - -**Goal:** Make two different machines communicate securely. - -**Tutorial level:** Advanced - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- - -Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. - -The previous tutorials have used two ROS nodes on the same machine sending all network communications over the localhost interface. -Let's extend that scenario to involve multiple machines, since the benefits of authentication and encryption then become more obvious. - -Suppose that the machine with the keystore created in the previous demo has a hostname ``Alice``, and that we want to also use another machine with hostname ``Bob`` for our multi-machine ``talker/listener`` demo. -We need to move some keys from ``Alice`` to ``Bob`` to allow SROS 2 to authenticate and encrypt the transmissions. - - -Create the second keystore --------------------------- - -Begin by creating an empty keystore on ``Bob``; the keystore is actually just an empty directory: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ ssh Bob - $ mkdir ~/sros2_demo - $ exit - - .. group-tab:: MacOS - - .. code-block:: console - - $ ssh Bob - $ mkdir ~/sros2_demo - $ exit - - .. group-tab:: Windows - - .. code-block:: console - - $ ssh Bob - $ md C:\dev\ros2\sros2_demo - $ exit - - -Copy files ----------- - -Next copy the keys and certificates for the ``talker`` program from ``Alice`` to ``Bob``. -Since the keys are just text files, we can use ``scp`` to copy them. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/sros2_demo/demo_keystore - $ scp -r talker USERNAME@Bob:~/sros2_demo/demo_keystore - - .. group-tab:: MacOS - - .. code-block:: console - - $ cd ~/sros2_demo/demo_keystore - $ scp -r talker USERNAME@Bob:~/sros2_demo/demo_keystore - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\dev\ros2\sros2_demo\demo_keystore - $ scp -r talker USERNAME@Bob:/dev/ros2/sros2_demo/demo_keystore - -.. warning:: - - Note that in this case the entire keystore is shared across the different machines which may not be the desired behavior, as it may result in a security risk. - Please refer to :doc:`Deployment-Guidelines` for more information in this regard. - -That will be very quick, since it's just copying some very small text files. -Now, we're ready to run a multi-machine talker/listener demo! - - -Launch the nodes ----------------- - -Once the environment is set up, run the talker on ``Bob``: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker - -and launch the listener on ``Alice``: - -.. code-block:: console - - $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener - -Alice will now be receiving encrypted messages from Bob. - -With two machines successfully communicating using both encryption and authentication, you can use the same procedure to add more machines to your ROS graph. +.. redirect-from:: + + Tutorials/Security/Security-on-Two + Tutorials/Advanced/Security/Security-on-Two + +.. _Security-on-Two: + +Ensuring security across machines +================================= + +**Goal:** Make two different machines communicate securely. + +**Tutorial level:** Advanced + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- + +Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. + +The previous tutorials have used two ROS nodes on the same machine sending all network communications over the localhost interface. +Let's extend that scenario to involve multiple machines, since the benefits of authentication and encryption then become more obvious. + +Suppose that the machine with the keystore created in the previous demo has a hostname ``Alice``, and that we want to also use another machine with hostname ``Bob`` for our multi-machine ``talker/listener`` demo. +We need to move some keys from ``Alice`` to ``Bob`` to allow SROS 2 to authenticate and encrypt the transmissions. + + +Create the second keystore +-------------------------- + +Begin by creating an empty keystore on ``Bob``; the keystore is actually just an empty directory: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ ssh Bob + $ mkdir ~/sros2_demo + $ exit + + .. group-tab:: MacOS + + .. code-block:: console + + $ ssh Bob + $ mkdir ~/sros2_demo + $ exit + + .. group-tab:: Windows + + .. code-block:: console + + $ ssh Bob + $ md C:\dev\ros2\sros2_demo + $ exit + + +Copy files +---------- + +Next copy the keys and certificates for the ``talker`` program from ``Alice`` to ``Bob``. +Since the keys are just text files, we can use ``scp`` to copy them. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/sros2_demo/demo_keystore + $ scp -r talker USERNAME@Bob:~/sros2_demo/demo_keystore + + .. group-tab:: MacOS + + .. code-block:: console + + $ cd ~/sros2_demo/demo_keystore + $ scp -r talker USERNAME@Bob:~/sros2_demo/demo_keystore + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\dev\ros2\sros2_demo\demo_keystore + $ scp -r talker USERNAME@Bob:/dev/ros2/sros2_demo/demo_keystore + +.. warning:: + + Note that in this case the entire keystore is shared across the different machines which may not be the desired behavior, as it may result in a security risk. + Please refer to :doc:`Deployment-Guidelines` for more information in this regard. + +That will be very quick, since it's just copying some very small text files. +Now, we're ready to run a multi-machine talker/listener demo! + + +Launch the nodes +---------------- + +Once the environment is set up, run the talker on ``Bob``: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --enclave /talker_listener/talker + +and launch the listener on ``Alice``: + +.. code-block:: console + + $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener + +Alice will now be receiving encrypted messages from Bob. + +With two machines successfully communicating using both encryption and authentication, you can use the same procedure to add more machines to your ROS graph. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst b/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst index 2113f6f2bf2..da51a704515 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst @@ -1,380 +1,381 @@ -.. redirect-from:: - - Tutorials/Service-Introspection - -Configure service introspection -=============================== - -**Goal:** Configure service introspection for a service client and a server. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 1 - :local: - -Overview --------- - -ROS 2 applications usually consist of services to execute specific procedures in remote nodes. -Unlike topics, which anyone can subscribe to, service interactions are more opaque. -By default, you cannot observe or monitor when a service gets called, nor what the request or response was. - -Still, it is possible to introspect service data communication with service introspection. -To do this, the service in question needs to be configured appropriately. - -In this demo, we'll be highlighting how to configure service introspection state for a service client and a server and monitor service communication with ``ros2 service echo``. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 binary packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Introspection Configuration State ---------------------------------- - -There are 3 configuration states for service introspection. - -.. list-table:: Service Introspection Configuration State - :widths: 25 25 - - * - RCL_SERVICE_INTROSPECTION_OFF - - Disabled - * - RCL_SERVICE_INTROSPECTION_METADATA - - Only metadata without any user data contents - * - RCL_SERVICE_INTROSPECTION_CONTENTS - - User data contents with metadata - -Introspection demo ------------------- - -This demo shows how to manage service introspection and monitor the service data communication with using ``ros2 service echo``. - -IntrospectionServiceNode: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/services/introspection_service.cpp - -.. code-block:: c++ - - namespace demo_nodes_cpp - { - - class IntrospectionServiceNode : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit IntrospectionServiceNode(const rclcpp::NodeOptions & options) - : Node("introspection_service", options) - { - auto handle_add_two_ints = - [this](const std::shared_ptr request_header, - const std::shared_ptr request, - std::shared_ptr response) -> void - { - (void)request_header; - RCLCPP_INFO( - this->get_logger(), "Incoming request\na: %" PRId64 " b: %" PRId64, - request->a, request->b); - response->sum = request->a + request->b; - }; - // Create a service that will use the callback function to handle requests. - srv_ = create_service("add_two_ints", handle_add_two_ints); - - auto on_set_parameter_callback = - [](std::vector parameters) { - rcl_interfaces::msg::SetParametersResult result; - result.successful = true; - for (const rclcpp::Parameter & param : parameters) { - if (param.get_name() != "service_configure_introspection") { - continue; - } - - if (param.get_type() != rclcpp::ParameterType::PARAMETER_STRING) { - result.successful = false; - result.reason = "must be a string"; - break; - } - - if (param.as_string() != "disabled" && param.as_string() != "metadata" && - param.as_string() != "contents") - { - result.successful = false; - result.reason = "must be one of 'disabled', 'metadata', or 'contents'"; - break; - } - } - - return result; - }; - - auto post_set_parameter_callback = - [this](const std::vector & parameters) { - for (const rclcpp::Parameter & param : parameters) { - if (param.get_name() != "service_configure_introspection") { - continue; - } - - rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - - if (param.as_string() == "disabled") { - introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - } else if (param.as_string() == "metadata") { - introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; - } else if (param.as_string() == "contents") { - introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; - } - - this->srv_->configure_introspection( - this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); - break; - } - }; - - on_set_parameters_callback_handle_ = this->add_on_set_parameters_callback( - on_set_parameter_callback); - post_set_parameters_callback_handle_ = this->add_post_set_parameters_callback( - post_set_parameter_callback); - - this->declare_parameter("service_configure_introspection", "disabled"); - } - - private: - rclcpp::Service::SharedPtr srv_; - rclcpp::node_interfaces::OnSetParametersCallbackHandle::SharedPtr - on_set_parameters_callback_handle_; - rclcpp::node_interfaces::PostSetParametersCallbackHandle::SharedPtr - post_set_parameters_callback_handle_; - }; - - } // namespace demo_nodes_cpp - -Service introspection is disabled by default, so users need to enable it before any introspection can be made. -In this demo, the ``IntrospectionServiceNode`` uses a parameter named ``service_configure_introspection`` to configure the service introspection state. - -First we need to start the ``IntrospectionServiceNode``. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp introspection_service - -To change service introspection state, we need to set the ``configure_introspection`` parameter as following. - -To change it to user data contents with metadata: - -.. code-block:: console - - $ ros2 param set /introspection_service service_configure_introspection contents - -To change it to only metadata: - -.. code-block:: console - - $ ros2 param set /introspection_service service_configure_introspection metadata - -To disable: - -.. code-block:: console - - $ ros2 param set /introspection_service service_configure_introspection disabled - -IntrospectionClientNode: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/services/introspection_client.cpp - -.. code-block:: c++ - - namespace demo_nodes_cpp - { - class IntrospectionClientNode : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit IntrospectionClientNode(const rclcpp::NodeOptions & options) - : Node("introspection_client", options) - { - client_ = create_client("add_two_ints"); - - auto on_set_parameter_callback = - [](std::vector parameters) { - rcl_interfaces::msg::SetParametersResult result; - result.successful = true; - for (const rclcpp::Parameter & param : parameters) { - if (param.get_name() != "client_configure_introspection") { - continue; - } - - if (param.get_type() != rclcpp::ParameterType::PARAMETER_STRING) { - result.successful = false; - result.reason = "must be a string"; - break; - } - - if (param.as_string() != "disabled" && param.as_string() != "metadata" && - param.as_string() != "contents") - { - result.successful = false; - result.reason = "must be one of 'disabled', 'metadata', or 'contents'"; - break; - } - } - - return result; - }; - - auto post_set_parameter_callback = - [this](const std::vector & parameters) { - for (const rclcpp::Parameter & param : parameters) { - if (param.get_name() != "client_configure_introspection") { - continue; - } - - rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - - if (param.as_string() == "disabled") { - introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - } else if (param.as_string() == "metadata") { - introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; - } else if (param.as_string() == "contents") { - introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; - } - - this->client_->configure_introspection( - this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); - break; - } - }; - - on_set_parameters_callback_handle_ = this->add_on_set_parameters_callback( - on_set_parameter_callback); - post_set_parameters_callback_handle_ = this->add_post_set_parameters_callback( - post_set_parameter_callback); - - this->declare_parameter("client_configure_introspection", "disabled"); - - timer_ = this->create_wall_timer( - std::chrono::milliseconds(500), - [this]() { - if (!client_->service_is_ready()) { - return; - } - - if (!request_in_progress_) { - auto request = std::make_shared(); - request->a = 2; - request->b = 3; - request_in_progress_ = true; - client_->async_send_request( - request, - [this](rclcpp::Client::SharedFuture cb_f) - { - request_in_progress_ = false; - RCLCPP_INFO(get_logger(), "Result of add_two_ints: %ld", cb_f.get()->sum); - } - ); - return; - } - }); - } - - private: - rclcpp::Client::SharedPtr client_; - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::node_interfaces::OnSetParametersCallbackHandle::SharedPtr - on_set_parameters_callback_handle_; - rclcpp::node_interfaces::PostSetParametersCallbackHandle::SharedPtr - post_set_parameters_callback_handle_; - bool request_in_progress_{false}; - }; - - } // namespace demo_nodes_cpp - -And then, we start and configure ``IntrospectionClientNode`` in the same way, which will periodically make service calls to the server. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp introspection_client - -Change service introspection state to set ``configure_introspection`` parameter as following. - -To change it to user data contents with metadata: - -.. code-block:: console - - $ ros2 param set /introspection_client client_configure_introspection contents - -To change it to only metadata: - -.. code-block:: console - - $ ros2 param set /introspection_client client_configure_introspection metadata - -To disable: - -.. code-block:: console - - $ ros2 param set /introspection_client client_configure_introspection disabled - -Now that both the service server and client are configured, we can use ``ros2 service echo`` to monitor the interactions happening between client and server. - -In this tutorial the following is example output with service introspection state ``CONTENTS`` on ``IntrospectionServiceNode`` and ``METADATA`` on ``IntrospectionClientNode``. - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - info: - event_type: REQUEST_SENT - stamp: - sec: 1709432402 - nanosec: 680094264 - client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 247 - request: [] - response: [] - --- - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1709432402 - nanosec: 680459568 - client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 247 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: RESPONSE_SENT - stamp: - sec: 1709432402 - nanosec: 680765280 - client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 247 - request: [] - response: [{sum: 5}] - --- - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1709432402 - nanosec: 681027998 - client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 247 - request: [] - response: [] - --- - ... - -You can see the ``event_type: REQUEST_SENT`` and ``event_type: RESPONSE_RECEIVED``, those introspection service event take place in ``IntrospectionClientNode``. -And those events do not include any contents in the ``request`` and ``response`` fields, since the service introspection state of ``IntrospectionClientNode`` is set to ``METADATA``. -On the other hand, the ``event_type: REQUEST_RECEIVED`` and ``event_type: RESPONSE_SENT`` events from ``IntrospectionServiceNode`` include ``request: [{a: 2, b: 3}]`` and ``response: [{sum: 5}]``, as introspection state is set to ``CONTENTS``. - -Related content ---------------- - -- `service introspection client example (rclcpp) `__ and `service introspection service example (rclcpp) `__. -- `service introspection client and service example (rclpy) `__. -- `Service Introspection REP-2012 `__. +.. redirect-from:: + + Tutorials/Service-Introspection + Tutorials/Demos/Service-Introspection + +Configure service introspection +=============================== + +**Goal:** Configure service introspection for a service client and a server. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 1 + :local: + +Overview +-------- + +ROS 2 applications usually consist of services to execute specific procedures in remote nodes. +Unlike topics, which anyone can subscribe to, service interactions are more opaque. +By default, you cannot observe or monitor when a service gets called, nor what the request or response was. + +Still, it is possible to introspect service data communication with service introspection. +To do this, the service in question needs to be configured appropriately. + +In this demo, we'll be highlighting how to configure service introspection state for a service client and a server and monitor service communication with ``ros2 service echo``. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 binary packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Introspection Configuration State +--------------------------------- + +There are 3 configuration states for service introspection. + +.. list-table:: Service Introspection Configuration State + :widths: 25 25 + + * - RCL_SERVICE_INTROSPECTION_OFF + - Disabled + * - RCL_SERVICE_INTROSPECTION_METADATA + - Only metadata without any user data contents + * - RCL_SERVICE_INTROSPECTION_CONTENTS + - User data contents with metadata + +Introspection demo +------------------ + +This demo shows how to manage service introspection and monitor the service data communication with using ``ros2 service echo``. + +IntrospectionServiceNode: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/services/introspection_service.cpp + +.. code-block:: c++ + + namespace demo_nodes_cpp + { + + class IntrospectionServiceNode : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit IntrospectionServiceNode(const rclcpp::NodeOptions & options) + : Node("introspection_service", options) + { + auto handle_add_two_ints = + [this](const std::shared_ptr request_header, + const std::shared_ptr request, + std::shared_ptr response) -> void + { + (void)request_header; + RCLCPP_INFO( + this->get_logger(), "Incoming request\na: %" PRId64 " b: %" PRId64, + request->a, request->b); + response->sum = request->a + request->b; + }; + // Create a service that will use the callback function to handle requests. + srv_ = create_service("add_two_ints", handle_add_two_ints); + + auto on_set_parameter_callback = + [](std::vector parameters) { + rcl_interfaces::msg::SetParametersResult result; + result.successful = true; + for (const rclcpp::Parameter & param : parameters) { + if (param.get_name() != "service_configure_introspection") { + continue; + } + + if (param.get_type() != rclcpp::ParameterType::PARAMETER_STRING) { + result.successful = false; + result.reason = "must be a string"; + break; + } + + if (param.as_string() != "disabled" && param.as_string() != "metadata" && + param.as_string() != "contents") + { + result.successful = false; + result.reason = "must be one of 'disabled', 'metadata', or 'contents'"; + break; + } + } + + return result; + }; + + auto post_set_parameter_callback = + [this](const std::vector & parameters) { + for (const rclcpp::Parameter & param : parameters) { + if (param.get_name() != "service_configure_introspection") { + continue; + } + + rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + + if (param.as_string() == "disabled") { + introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + } else if (param.as_string() == "metadata") { + introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; + } else if (param.as_string() == "contents") { + introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; + } + + this->srv_->configure_introspection( + this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); + break; + } + }; + + on_set_parameters_callback_handle_ = this->add_on_set_parameters_callback( + on_set_parameter_callback); + post_set_parameters_callback_handle_ = this->add_post_set_parameters_callback( + post_set_parameter_callback); + + this->declare_parameter("service_configure_introspection", "disabled"); + } + + private: + rclcpp::Service::SharedPtr srv_; + rclcpp::node_interfaces::OnSetParametersCallbackHandle::SharedPtr + on_set_parameters_callback_handle_; + rclcpp::node_interfaces::PostSetParametersCallbackHandle::SharedPtr + post_set_parameters_callback_handle_; + }; + + } // namespace demo_nodes_cpp + +Service introspection is disabled by default, so users need to enable it before any introspection can be made. +In this demo, the ``IntrospectionServiceNode`` uses a parameter named ``service_configure_introspection`` to configure the service introspection state. + +First we need to start the ``IntrospectionServiceNode``. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp introspection_service + +To change service introspection state, we need to set the ``configure_introspection`` parameter as following. + +To change it to user data contents with metadata: + +.. code-block:: console + + $ ros2 param set /introspection_service service_configure_introspection contents + +To change it to only metadata: + +.. code-block:: console + + $ ros2 param set /introspection_service service_configure_introspection metadata + +To disable: + +.. code-block:: console + + $ ros2 param set /introspection_service service_configure_introspection disabled + +IntrospectionClientNode: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/services/introspection_client.cpp + +.. code-block:: c++ + + namespace demo_nodes_cpp + { + class IntrospectionClientNode : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit IntrospectionClientNode(const rclcpp::NodeOptions & options) + : Node("introspection_client", options) + { + client_ = create_client("add_two_ints"); + + auto on_set_parameter_callback = + [](std::vector parameters) { + rcl_interfaces::msg::SetParametersResult result; + result.successful = true; + for (const rclcpp::Parameter & param : parameters) { + if (param.get_name() != "client_configure_introspection") { + continue; + } + + if (param.get_type() != rclcpp::ParameterType::PARAMETER_STRING) { + result.successful = false; + result.reason = "must be a string"; + break; + } + + if (param.as_string() != "disabled" && param.as_string() != "metadata" && + param.as_string() != "contents") + { + result.successful = false; + result.reason = "must be one of 'disabled', 'metadata', or 'contents'"; + break; + } + } + + return result; + }; + + auto post_set_parameter_callback = + [this](const std::vector & parameters) { + for (const rclcpp::Parameter & param : parameters) { + if (param.get_name() != "client_configure_introspection") { + continue; + } + + rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + + if (param.as_string() == "disabled") { + introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + } else if (param.as_string() == "metadata") { + introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; + } else if (param.as_string() == "contents") { + introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; + } + + this->client_->configure_introspection( + this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); + break; + } + }; + + on_set_parameters_callback_handle_ = this->add_on_set_parameters_callback( + on_set_parameter_callback); + post_set_parameters_callback_handle_ = this->add_post_set_parameters_callback( + post_set_parameter_callback); + + this->declare_parameter("client_configure_introspection", "disabled"); + + timer_ = this->create_wall_timer( + std::chrono::milliseconds(500), + [this]() { + if (!client_->service_is_ready()) { + return; + } + + if (!request_in_progress_) { + auto request = std::make_shared(); + request->a = 2; + request->b = 3; + request_in_progress_ = true; + client_->async_send_request( + request, + [this](rclcpp::Client::SharedFuture cb_f) + { + request_in_progress_ = false; + RCLCPP_INFO(get_logger(), "Result of add_two_ints: %ld", cb_f.get()->sum); + } + ); + return; + } + }); + } + + private: + rclcpp::Client::SharedPtr client_; + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::node_interfaces::OnSetParametersCallbackHandle::SharedPtr + on_set_parameters_callback_handle_; + rclcpp::node_interfaces::PostSetParametersCallbackHandle::SharedPtr + post_set_parameters_callback_handle_; + bool request_in_progress_{false}; + }; + + } // namespace demo_nodes_cpp + +And then, we start and configure ``IntrospectionClientNode`` in the same way, which will periodically make service calls to the server. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp introspection_client + +Change service introspection state to set ``configure_introspection`` parameter as following. + +To change it to user data contents with metadata: + +.. code-block:: console + + $ ros2 param set /introspection_client client_configure_introspection contents + +To change it to only metadata: + +.. code-block:: console + + $ ros2 param set /introspection_client client_configure_introspection metadata + +To disable: + +.. code-block:: console + + $ ros2 param set /introspection_client client_configure_introspection disabled + +Now that both the service server and client are configured, we can use ``ros2 service echo`` to monitor the interactions happening between client and server. + +In this tutorial the following is example output with service introspection state ``CONTENTS`` on ``IntrospectionServiceNode`` and ``METADATA`` on ``IntrospectionClientNode``. + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + info: + event_type: REQUEST_SENT + stamp: + sec: 1709432402 + nanosec: 680094264 + client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 247 + request: [] + response: [] + --- + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1709432402 + nanosec: 680459568 + client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 247 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: RESPONSE_SENT + stamp: + sec: 1709432402 + nanosec: 680765280 + client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 247 + request: [] + response: [{sum: 5}] + --- + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1709432402 + nanosec: 681027998 + client_gid: [1, 15, 0, 18, 86, 208, 115, 86, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 247 + request: [] + response: [] + --- + ... + +You can see the ``event_type: REQUEST_SENT`` and ``event_type: RESPONSE_RECEIVED``, those introspection service event take place in ``IntrospectionClientNode``. +And those events do not include any contents in the ``request`` and ``response`` fields, since the service introspection state of ``IntrospectionClientNode`` is set to ``METADATA``. +On the other hand, the ``event_type: REQUEST_RECEIVED`` and ``event_type: RESPONSE_SENT`` events from ``IntrospectionServiceNode`` include ``request: [{a: 2, b: 3}]`` and ``response: [{sum: 5}]``, as introspection state is set to ``CONTENTS``. + +Related content +--------------- + +- `service introspection client example (rclcpp) `__ and `service introspection service example (rclcpp) `__. +- `service introspection client and service example (rclpy) `__. +- `Service Introspection REP-2012 `__. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst b/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst index 0f9ee18d9e2..c24e9fc4422 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst @@ -1,316 +1,317 @@ -.. redirect-from:: - - Topic-Statistics-Tutorial - Tutorials/Topics/Topic-Statistics-Tutorial - -Enabling topic statistics (C++) -=============================== - -**Goal:** Enable ROS 2 Topic Statistics and view the output statistics data. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Table of Contents - :local: - -Background ----------- - -This is a short tutorial on how to enable topic statistics in ROS 2 and view the published statistics output using command line tools (:doc:`ros2 topic <../../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). - -ROS 2 provides the integrated measurement of statistics for messages received by any subscription, -called Topic Statistics. -With Topic Statistics enabled for your subscription, you can characterize the performance of your -system or use the data to help diagnose any present issues. - -For more details please see the :doc:`Topic Statistics Concepts Page <../../../Concepts/Intermediate/About-Topic-Statistics>`. - -Prerequisites -------------- - -An installation from either binaries or source. - -In previous tutorials, you learned how to :doc:`create a workspace <../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>`, -:doc:`create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`, and create a :doc:`C++ <../../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` publisher and subscriber. - -This tutorial assumes that you still have your ``cpp_pubsub`` package from the :doc:`C++ <../../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial. - -Tasks ------ - -1 Write the subscriber node with statistics enabled -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Navigate into the ``ros2_ws/src/cpp_pubsub/src`` folder, created in the :doc:`previous tutorial <../../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>`, and -download the example talker code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp - - .. group-tab:: Windows - - Right click this link and select Save As ``publisher_member_function.cpp``: - - https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp - -Now there will be a new file named ``member_function_with_topic_statistics.cpp``. -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp/subscription_options.hpp" - - #include "std_msgs/msg/string.hpp" - - class MinimalSubscriberWithTopicStatistics : public rclcpp::Node - { - public: - MinimalSubscriberWithTopicStatistics() - : Node("minimal_subscriber_with_topic_statistics") - { - // manually enable topic statistics via options - auto options = rclcpp::SubscriptionOptions(); - options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; - - // configure the collection window and publish period (default 1s) - options.topic_stats_options.publish_period = std::chrono::seconds(10); - - // configure the topic name (default '/statistics') - // options.topic_stats_options.publish_topic = "/topic_statistics" - - auto callback = [this](const std_msgs::msg::String & msg) { - this->topic_callback(msg); - }; - - subscription_ = this->create_subscription( - "topic", 10, callback, options); - } - - private: - void topic_callback(const std_msgs::msg::String & msg) const - { - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); - } - rclcpp::Subscription::SharedPtr subscription_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -As in the :doc:`C++ <../../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial, we have a subscriber node which receives string messages from the -``topic`` topic from the ``topic_callback`` function. -However, we've now added options to configure the subscription to enable topic statistics with -the ``rclcpp::SubscriptionOptions()`` options struct. - -.. code-block:: C++ - - // manually enable topic statistics via options - auto options = rclcpp::SubscriptionOptions(); - options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; - -Optionally, fields such as the statistics collection/publish period and the topic used to publish -statistics can be configured as well. - -.. code-block:: C++ - - // configure the collection window and publish period (default 1s) - options.topic_stats_options.publish_period = std::chrono::seconds(10); - - // configure the topic name (default '/statistics') - // options.topic_stats_options.publish_topic = "/my_topic" - -The configurable fields are described in the following table: - -================================== ============================================================================================= -Subscription Config Field Purpose -================================== ============================================================================================= -topic_stats_options.state Enable or disable topic statistics (default ``rclcpp::TopicStatisticsState::Disable``) -topic_stats_options.publish_period The period in which to collect statistics data and publish a statistics message (default ``1s``) -topic_stats_options.publish_topic The topic to use when publishing statistics data (default ``/statistics``) -================================== ============================================================================================= - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. - -Add the executable and name it ``listener_with_topic_statistics`` so you can run your node using ``ros2 run``: - -.. code-block:: cmake - - add_executable(listener_with_topic_statistics src/member_function_with_topic_statistics.cpp) - target_link_libraries(listener_with_topic_statistics rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - talker - listener - listener_with_topic_statistics - DESTINATION lib/${PROJECT_NAME}) - -Make sure to save the file, and then your pub/sub system, with topic statistics enabled, -should be ready for use. - -2 Build and run -^^^^^^^^^^^^^^^ - -To build, see the :ref:`Build and run ` section in the pub/sub tutorial. - -Run the subscriber with statistics enabled node: - -.. code-block:: console - - $ ros2 run cpp_pubsub listener_with_topic_statistics - -Now run the talker node: - -.. code-block:: console - - $ ros2 run cpp_pubsub talker - [INFO] [minimal_publisher]: Publishing: "Hello World: 0" - [INFO] [minimal_publisher]: Publishing: "Hello World: 1" - [INFO] [minimal_publisher]: Publishing: "Hello World: 2" - [INFO] [minimal_publisher]: Publishing: "Hello World: 3" - [INFO] [minimal_publisher]: Publishing: "Hello World: 4" - -The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: - -.. code-block:: console - - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 10" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 11" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 12" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 13" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 14" - -Now that the subscriber node is receiving messages, it will periodically publish statistics messages. -We will observe these messages in the next section. - -3 Observe published statistic data -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While the nodes are running, open a new terminal window. -Execute the following command, which will list all currently active topics. - -.. code-block:: console - - $ ros2 topic list - /parameter_events - /rosout - /statistics - /topic - -If you optionally changed the ``topic_stats_options.publish_topic`` field earlier in the tutorial, -then you will see that name instead of ``/statistics``. - -The subscriber node you created is publishing statistics, for the topic ``topic``, to the output topic -``/statistics``. - -We can visualize this using :doc:`RQt <../../../Concepts/Intermediate/About-RQt>` - -.. image:: images/topic_stats_rqt.png - -Now we can view the statistics data published to this topic with the following command. -The terminal should start publishing statistics messages every 10 seconds, because the -``topic_stats_options.publish_period`` subscription configuration was optionally changed earlier in the tutorial: - -.. code-block:: console - - $ ros2 topic echo /statistics - --- - measurement_source_name: minimal_subscriber_with_topic_statistics - metrics_source: message_age - unit: ms - window_start: - sec: 1594856666 - nanosec: 931527366 - window_stop: - sec: 1594856676 - nanosec: 930797670 - statistics: - - data_type: 1 - data: 0.5522003000000001 - - data_type: 3 - data: 0.756992 - - data_type: 2 - data: 0.269039 - - data_type: 5 - data: 20.0 - - data_type: 4 - data: 0.16441001797065166 - --- - measurement_source_name: minimal_subscriber_with_topic_statistics - metrics_source: message_period - unit: ms - window_start: - sec: 1594856666 - nanosec: 931527366 - window_stop: - sec: 1594856676 - nanosec: 930797670 - statistics: - - data_type: 1 - data: 499.2746365105009 - - data_type: 3 - data: 500.0 - - data_type: 2 - data: 499.0 - - data_type: 5 - data: 619.0 - - data_type: 4 - data: 0.4463309283488427 - --- - -From the `message definition `__ -the ``data_types`` are as follows - -=============== =================== -data_type value statistics -=============== =================== -1 average -2 minimum -3 maximum -4 standard deviation -5 sample count -=============== =================== - -Here we see the two currently possible calculated statistics for the ``std_msgs::msg::String`` message published -to ``/topic`` by the ``minimal_publisher``. - -Summary -------- - -You created a subscriber node with topic statistics enabled, which published statistics data from -the :doc:`C++ <../../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`'s publisher node. -You were able to compile and run this node. -While running, you were able to observe the statistics data. - -Related content ---------------- - -To observe how the ``message_age`` period is calculated please see the -`ROS 2 Topic Statistics demo `__. +.. redirect-from:: + + Topic-Statistics-Tutorial + Tutorials/Topics/Topic-Statistics-Tutorial + Tutorials/Advanced/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial + +Enabling topic statistics (C++) +=============================== + +**Goal:** Enable ROS 2 Topic Statistics and view the output statistics data. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Table of Contents + :local: + +Background +---------- + +This is a short tutorial on how to enable topic statistics in ROS 2 and view the published statistics output using command line tools (:doc:`ros2 topic <../../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). + +ROS 2 provides the integrated measurement of statistics for messages received by any subscription, +called Topic Statistics. +With Topic Statistics enabled for your subscription, you can characterize the performance of your +system or use the data to help diagnose any present issues. + +For more details please see the :doc:`Topic Statistics Concepts Page <../../../ROS-Framework/topics/About-Topic-Statistics>`. + +Prerequisites +------------- + +An installation from either binaries or source. + +In previous tutorials, you learned how to :doc:`create a workspace <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>`, +:doc:`create a package <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`, and create a :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` publisher and subscriber. + +This tutorial assumes that you still have your ``cpp_pubsub`` package from the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial. + +Tasks +----- + +1 Write the subscriber node with statistics enabled +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate into the ``ros2_ws/src/cpp_pubsub/src`` folder, created in the :doc:`previous tutorial <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>`, and +download the example talker code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp + + .. group-tab:: Windows + + Right click this link and select Save As ``publisher_member_function.cpp``: + + https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp + +Now there will be a new file named ``member_function_with_topic_statistics.cpp``. +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp/subscription_options.hpp" + + #include "std_msgs/msg/string.hpp" + + class MinimalSubscriberWithTopicStatistics : public rclcpp::Node + { + public: + MinimalSubscriberWithTopicStatistics() + : Node("minimal_subscriber_with_topic_statistics") + { + // manually enable topic statistics via options + auto options = rclcpp::SubscriptionOptions(); + options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; + + // configure the collection window and publish period (default 1s) + options.topic_stats_options.publish_period = std::chrono::seconds(10); + + // configure the topic name (default '/statistics') + // options.topic_stats_options.publish_topic = "/topic_statistics" + + auto callback = [this](const std_msgs::msg::String & msg) { + this->topic_callback(msg); + }; + + subscription_ = this->create_subscription( + "topic", 10, callback, options); + } + + private: + void topic_callback(const std_msgs::msg::String & msg) const + { + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); + } + rclcpp::Subscription::SharedPtr subscription_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +As in the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial, we have a subscriber node which receives string messages from the +``topic`` topic from the ``topic_callback`` function. +However, we've now added options to configure the subscription to enable topic statistics with +the ``rclcpp::SubscriptionOptions()`` options struct. + +.. code-block:: C++ + + // manually enable topic statistics via options + auto options = rclcpp::SubscriptionOptions(); + options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; + +Optionally, fields such as the statistics collection/publish period and the topic used to publish +statistics can be configured as well. + +.. code-block:: C++ + + // configure the collection window and publish period (default 1s) + options.topic_stats_options.publish_period = std::chrono::seconds(10); + + // configure the topic name (default '/statistics') + // options.topic_stats_options.publish_topic = "/my_topic" + +The configurable fields are described in the following table: + +================================== ============================================================================================= +Subscription Config Field Purpose +================================== ============================================================================================= +topic_stats_options.state Enable or disable topic statistics (default ``rclcpp::TopicStatisticsState::Disable``) +topic_stats_options.publish_period The period in which to collect statistics data and publish a statistics message (default ``1s``) +topic_stats_options.publish_topic The topic to use when publishing statistics data (default ``/statistics``) +================================== ============================================================================================= + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. + +Add the executable and name it ``listener_with_topic_statistics`` so you can run your node using ``ros2 run``: + +.. code-block:: cmake + + add_executable(listener_with_topic_statistics src/member_function_with_topic_statistics.cpp) + target_link_libraries(listener_with_topic_statistics rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + talker + listener + listener_with_topic_statistics + DESTINATION lib/${PROJECT_NAME}) + +Make sure to save the file, and then your pub/sub system, with topic statistics enabled, +should be ready for use. + +2 Build and run +^^^^^^^^^^^^^^^ + +To build, see the :ref:`Build and run ` section in the pub/sub tutorial. + +Run the subscriber with statistics enabled node: + +.. code-block:: console + + $ ros2 run cpp_pubsub listener_with_topic_statistics + +Now run the talker node: + +.. code-block:: console + + $ ros2 run cpp_pubsub talker + [INFO] [minimal_publisher]: Publishing: "Hello World: 0" + [INFO] [minimal_publisher]: Publishing: "Hello World: 1" + [INFO] [minimal_publisher]: Publishing: "Hello World: 2" + [INFO] [minimal_publisher]: Publishing: "Hello World: 3" + [INFO] [minimal_publisher]: Publishing: "Hello World: 4" + +The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: + +.. code-block:: console + + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 10" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 11" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 12" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 13" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 14" + +Now that the subscriber node is receiving messages, it will periodically publish statistics messages. +We will observe these messages in the next section. + +3 Observe published statistic data +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While the nodes are running, open a new terminal window. +Execute the following command, which will list all currently active topics. + +.. code-block:: console + + $ ros2 topic list + /parameter_events + /rosout + /statistics + /topic + +If you optionally changed the ``topic_stats_options.publish_topic`` field earlier in the tutorial, +then you will see that name instead of ``/statistics``. + +The subscriber node you created is publishing statistics, for the topic ``topic``, to the output topic +``/statistics``. + +We can visualize this using :doc:`RQt <../../Visualization/About-RQt>` + +.. image:: images/topic_stats_rqt.png + +Now we can view the statistics data published to this topic with the following command. +The terminal should start publishing statistics messages every 10 seconds, because the +``topic_stats_options.publish_period`` subscription configuration was optionally changed earlier in the tutorial: + +.. code-block:: console + + $ ros2 topic echo /statistics + --- + measurement_source_name: minimal_subscriber_with_topic_statistics + metrics_source: message_age + unit: ms + window_start: + sec: 1594856666 + nanosec: 931527366 + window_stop: + sec: 1594856676 + nanosec: 930797670 + statistics: + - data_type: 1 + data: 0.5522003000000001 + - data_type: 3 + data: 0.756992 + - data_type: 2 + data: 0.269039 + - data_type: 5 + data: 20.0 + - data_type: 4 + data: 0.16441001797065166 + --- + measurement_source_name: minimal_subscriber_with_topic_statistics + metrics_source: message_period + unit: ms + window_start: + sec: 1594856666 + nanosec: 931527366 + window_stop: + sec: 1594856676 + nanosec: 930797670 + statistics: + - data_type: 1 + data: 499.2746365105009 + - data_type: 3 + data: 500.0 + - data_type: 2 + data: 499.0 + - data_type: 5 + data: 619.0 + - data_type: 4 + data: 0.4463309283488427 + --- + +From the `message definition `__ +the ``data_types`` are as follows + +=============== =================== +data_type value statistics +=============== =================== +1 average +2 minimum +3 maximum +4 standard deviation +5 sample count +=============== =================== + +Here we see the two currently possible calculated statistics for the ``std_msgs::msg::String`` message published +to ``/topic`` by the ``minimal_publisher``. + +Summary +------- + +You created a subscriber node with topic statistics enabled, which published statistics data from +the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`'s publisher node. +You were able to compile and run this node. +While running, you were able to observe the statistics data. + +Related content +--------------- + +To observe how the ``message_age`` period is calculated please see the +`ROS 2 Topic Statistics demo `__. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst b/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst index 60724f6188b..5e5abbc034d 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst @@ -1,195 +1,199 @@ -How to use ros2_tracing to trace and analyze an application -=========================================================== - -This tutorial shows how to use `ros2_tracing `_ to trace and analyze a ROS 2 application. -For this tutorial, the application will be `performance_test `_. - -Overview --------- - -This tutorial covers: - -1. running and tracing a ``performance_test`` run -2. analyzing the trace data using `tracetools_analysis `_ to plot the callback durations using `Jupyter Notebook `_ - -Prerequisites -------------- - -This tutorial is aimed at real-time Linux systems. -See the :doc:`real-time system setup tutorial <../Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2>`. -However, the tutorial will work if you are using a non-real-time Linux system. - -Installing and building ------------------------ - -Install ROS 2 on Linux by following the :doc:`installation instructions <../../Installation>`. - -.. note:: - - This tutorial should generally work with all supported Linux distributions. - However, you might need to adapt some commands. - -Install ``babeltrace`` and ``ros2trace``. - -.. code-block:: console - - $ sudo apt-get update - $ sudo apt-get install -y babeltrace ros-{DISTRO}-ros2trace ros-{DISTRO}-tracetools-analysis - - -Source the ROS 2 installation and verify that tracing is enabled: - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run tracetools status - Tracing enabled - -Then create a workspace, and clone ``performance_test`` and ``tracetools_analysis``. - -.. code-block:: console - - $ cd ~/ - $ mkdir -p tracing_ws/src - $ cd tracing_ws/src/ - $ git clone https://gitlab.com/ApexAI/performance_test.git - $ git clone https://github.com/ros-tracing/tracetools_analysis.git -b {DISTRO} - $ cd .. - -Install dependencies with rosdep. - -.. code-block:: console - - $ rosdep update - $ rosdep install --from-paths src --ignore-src -y --skip-keys test_tracetools - -Then build and configure ``performance_test`` for ROS 2. -See its `documentation `_. - -.. code-block:: console - - $ colcon build --packages-select performance_test --cmake-args -DPERFORMANCE_TEST_RCLCPP_ENABLED=ON - -Next, we will run a ``performance_test`` experiment and trace it. - -Tracing -------- - -Step 1: Trace -^^^^^^^^^^^^^ - -In one terminal, source the workspace and set up tracing. -When running the command, a list of ROS 2 userspace events will be printed. -It will also print the path to the directory that will contain the resulting trace (under ``~/.ros/tracing``). -In Terminal 1 run: - -.. code-block:: console - - $ cd ~/tracing_ws - $ source install/setup.bash - $ ros2 trace --session-name perf-test --list - -Press enter to start tracing. - -Step 2: Run Application -^^^^^^^^^^^^^^^^^^^^^^^ - -In a second terminal, source the workspace. -In Terminal 2 run: - -.. code-block:: console - - $ cd ~/tracing_ws - $ source install/setup.bash - -Then run the ``performance_test`` experiment (or your own application). -We simply create an experiment with a node publishing ~1 MB messages to another node as fast as possible for 60 seconds using the second highest real-time priority so that we don't interfere with critical kernel threads. -We need to run ``performance_test`` as ``root`` to be able to use real-time priorities. -In Terminal 2 run: - -.. code-block:: console - - $ sudo ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 - -If that last command doesn't work for you (with an error like: "error while loading shared libraries"), run the slightly-different command below. -This is because, for security reasons, we need to manually pass ``*PATH`` environment variables for some shared libraries to be found (see `this explanation `_). -In Terminal 2 run: - -.. code-block:: console - - $ sudo env PATH="$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH" ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 - -.. note:: - - If you're not using a real-time kernel, simply run: - In Terminal 2 run: - - .. code-block:: console - - $ ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 - -Step 3: Validate Trace -^^^^^^^^^^^^^^^^^^^^^^ - -Once the experiment is done, in the first terminal, press enter again to stop tracing. -Use ``babeltrace`` to quickly look at the resulting trace. - -.. code-block:: console - - $ babeltrace ~/.ros/tracing/perf-test | less - -The output of the above command is a human-readable version of the raw Common Trace Format (CTF) data, which is a list of trace events. -Each event has a timestamp, an event type, some information on the process that generated the event, and the values of the fields of the given event type. - -Use the arrow keys to scroll, or press ``q`` to exit. - -Next, we will analyze the trace. - -Analysis --------- - -`tracetools_analysis `_ provides a Python API to easily analyze traces. -We can use it in a `Jupyter notebook `_ with `bokeh `_ to plot the data. -The ``tracetools_analysis`` repository contains a `few sample notebooks `_, including `one notebook to analyze subscription callback durations `_. - -For this tutorial, we will plot the durations of the subscription callback in the subscriber node. - -Install Jupyter notebook and bokeh, and then open the sample notebook. - -.. code-block:: console - - $ source install/setup.bash - $ python3 -m venv venv --system-site-packages - $ source venv/bin/activate - $ pip3 install bokeh ipykernel - $ python3 -m ipykernel install --user --name=venv - $ jupyter notebook ~/tracing_ws/src/tracetools_analysis/tracetools_analysis/analysis/callback_duration.ipynb - -This will open the notebook in the browser. -Click ``Kernel``, then ``Change kernel``, and select ``venv``. - -Replace the value for the ``path`` variable in the second cell to the path to the trace directory: - -.. code-block:: python - - path = '~/.ros/tracing/perf-test' - -Run the notebook by clicking the *Run* button for each cell. -Running the cell that does the trace processing might take a few minutes on the first run, but subsequent runs will be much quicker. - -You should get a plot that looks similar to this: - -.. image:: ./images/ros2_tracing_guide_result_plot.png - :alt: callback durations result plot - :align: center - -We can see that most of the callbacks take less than 0.01 ms, but there are some outliers taking over 0.02 or 0.03 ms. - -Conclusion ----------- - -This tutorial showed how to install tracing-related tools. -Then it showed how to trace a `performance_test `_ experiment using `ros2_tracing `_ and plot the callback durations using `tracetools_analysis `_. - -For more trace analyses, take a look at the `other sample notebooks `_ and the `tracetools_analysis API documentation `_. -The `ros2_tracing design document `_ also contains a lot of information. +.. redirect-from:: + + Tutorials/Advanced/ROS2-Tracing-Trace-and-Analyze + +How to use ros2_tracing to trace and analyze an application +=========================================================== + +This tutorial shows how to use `ros2_tracing `_ to trace and analyze a ROS 2 application. +For this tutorial, the application will be `performance_test `_. + +Overview +-------- + +This tutorial covers: + +1. running and tracing a ``performance_test`` run +2. analyzing the trace data using `tracetools_analysis `_ to plot the callback durations using `Jupyter Notebook `_ + +Prerequisites +------------- + +This tutorial is aimed at real-time Linux systems. +See the :doc:`real-time system setup tutorial <../../../Tutorials/Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2>`. +However, the tutorial will work if you are using a non-real-time Linux system. + +Installing and building +----------------------- + +Install ROS 2 on Linux by following the :doc:`installation instructions <../../../Get-Started/Installation>`. + +.. note:: + + This tutorial should generally work with all supported Linux distributions. + However, you might need to adapt some commands. + +Install ``babeltrace`` and ``ros2trace``. + +.. code-block:: console + + $ sudo apt-get update + $ sudo apt-get install -y babeltrace ros-{DISTRO}-ros2trace ros-{DISTRO}-tracetools-analysis + + +Source the ROS 2 installation and verify that tracing is enabled: + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run tracetools status + Tracing enabled + +Then create a workspace, and clone ``performance_test`` and ``tracetools_analysis``. + +.. code-block:: console + + $ cd ~/ + $ mkdir -p tracing_ws/src + $ cd tracing_ws/src/ + $ git clone https://gitlab.com/ApexAI/performance_test.git + $ git clone https://github.com/ros-tracing/tracetools_analysis.git -b {DISTRO} + $ cd .. + +Install dependencies with rosdep. + +.. code-block:: console + + $ rosdep update + $ rosdep install --from-paths src --ignore-src -y --skip-keys test_tracetools + +Then build and configure ``performance_test`` for ROS 2. +See its `documentation `_. + +.. code-block:: console + + $ colcon build --packages-select performance_test --cmake-args -DPERFORMANCE_TEST_RCLCPP_ENABLED=ON + +Next, we will run a ``performance_test`` experiment and trace it. + +Tracing +------- + +Step 1: Trace +^^^^^^^^^^^^^ + +In one terminal, source the workspace and set up tracing. +When running the command, a list of ROS 2 userspace events will be printed. +It will also print the path to the directory that will contain the resulting trace (under ``~/.ros/tracing``). +In Terminal 1 run: + +.. code-block:: console + + $ cd ~/tracing_ws + $ source install/setup.bash + $ ros2 trace --session-name perf-test --list + +Press enter to start tracing. + +Step 2: Run Application +^^^^^^^^^^^^^^^^^^^^^^^ + +In a second terminal, source the workspace. +In Terminal 2 run: + +.. code-block:: console + + $ cd ~/tracing_ws + $ source install/setup.bash + +Then run the ``performance_test`` experiment (or your own application). +We simply create an experiment with a node publishing ~1 MB messages to another node as fast as possible for 60 seconds using the second highest real-time priority so that we don't interfere with critical kernel threads. +We need to run ``performance_test`` as ``root`` to be able to use real-time priorities. +In Terminal 2 run: + +.. code-block:: console + + $ sudo ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 + +If that last command doesn't work for you (with an error like: "error while loading shared libraries"), run the slightly-different command below. +This is because, for security reasons, we need to manually pass ``*PATH`` environment variables for some shared libraries to be found (see `this explanation `_). +In Terminal 2 run: + +.. code-block:: console + + $ sudo env PATH="$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH" ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 + +.. note:: + + If you're not using a real-time kernel, simply run: + In Terminal 2 run: + + .. code-block:: console + + $ ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 + +Step 3: Validate Trace +^^^^^^^^^^^^^^^^^^^^^^ + +Once the experiment is done, in the first terminal, press enter again to stop tracing. +Use ``babeltrace`` to quickly look at the resulting trace. + +.. code-block:: console + + $ babeltrace ~/.ros/tracing/perf-test | less + +The output of the above command is a human-readable version of the raw Common Trace Format (CTF) data, which is a list of trace events. +Each event has a timestamp, an event type, some information on the process that generated the event, and the values of the fields of the given event type. + +Use the arrow keys to scroll, or press ``q`` to exit. + +Next, we will analyze the trace. + +Analysis +-------- + +`tracetools_analysis `_ provides a Python API to easily analyze traces. +We can use it in a `Jupyter notebook `_ with `bokeh `_ to plot the data. +The ``tracetools_analysis`` repository contains a `few sample notebooks `_, including `one notebook to analyze subscription callback durations `_. + +For this tutorial, we will plot the durations of the subscription callback in the subscriber node. + +Install Jupyter notebook and bokeh, and then open the sample notebook. + +.. code-block:: console + + $ source install/setup.bash + $ python3 -m venv venv --system-site-packages + $ source venv/bin/activate + $ pip3 install bokeh ipykernel + $ python3 -m ipykernel install --user --name=venv + $ jupyter notebook ~/tracing_ws/src/tracetools_analysis/tracetools_analysis/analysis/callback_duration.ipynb + +This will open the notebook in the browser. +Click ``Kernel``, then ``Change kernel``, and select ``venv``. + +Replace the value for the ``path`` variable in the second cell to the path to the trace directory: + +.. code-block:: python + + path = '~/.ros/tracing/perf-test' + +Run the notebook by clicking the *Run* button for each cell. +Running the cell that does the trace processing might take a few minutes on the first run, but subsequent runs will be much quicker. + +You should get a plot that looks similar to this: + +.. image:: ./images/ros2_tracing_guide_result_plot.png + :alt: callback durations result plot + :align: center + +We can see that most of the callbacks take less than 0.01 ms, but there are some outliers taking over 0.02 or 0.03 ms. + +Conclusion +---------- + +This tutorial showed how to install tracing-related tools. +Then it showed how to trace a `performance_test `_ experiment using `ros2_tracing `_ and plot the callback durations using `tracetools_analysis `_. + +For more trace analyses, take a look at the `other sample notebooks `_ and the `tracetools_analysis API documentation `_. +The `ros2_tracing design document `_ also contains a lot of information. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Creating-Launch-Files.rst b/source/Developer-Tools/Launch/Creating-Launch-Files.rst index 3f51c2c3817..ac983e38d44 100644 --- a/source/Developer-Tools/Launch/Creating-Launch-Files.rst +++ b/source/Developer-Tools/Launch/Creating-Launch-Files.rst @@ -1,251 +1,252 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Creating-Launch-Files - Tutorials/Launch/Creating-Launch-Files - -Creating a launch file -====================== - -**Goal:** Create a launch file to run a complex ROS 2 system. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Prerequisites -------------- - -This tutorial uses the :doc:`rqt_graph and turtlesim <../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>` packages. - -You will also need to use a text editor of your preference. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>`. - -Background ----------- - -The launch system in ROS 2 is responsible for helping the user describe the configuration of their system and then execute it as described. -The configuration of the system includes what programs to run, where to run them, what arguments to pass them, and ROS-specific conventions which make it easy to reuse components throughout the system by giving them each a different configuration. -It is also responsible for monitoring the state of the processes launched, and reporting and/or reacting to changes in the state of those processes. - -Launch files written in XML, YAML, or Python can start and stop different nodes as well as trigger and act on various events. -See :doc:`../../../How-To-Guides/Launch-file-different-formats` for a description of the different formats. -The package providing this framework is ``launch_ros``, which uses the non-ROS-specific ``launch`` framework underneath. - -The `design document `__ details the goal of the design of ROS 2's launch system (not all functionality is currently available). - -Tasks ------ - -1 Setup -^^^^^^^ - -Create a new directory to store your launch files: - -.. code-block:: console - - $ mkdir launch - -2 Write the launch file -^^^^^^^^^^^^^^^^^^^^^^^ - -Let's put together a ROS 2 launch file using the ``turtlesim`` package and its executables. -As mentioned above, this can either be in XML, YAML, or Python. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_mimic_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_mimic_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_mimic_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_mimic_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_mimic_launch.py`` file: - - .. literalinclude:: launch/turtlesim_mimic_launch.py - :language: python - - -2.1 Examine the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -All of the launch files above are launching a system of three nodes, all from the ``turtlesim`` package. -The goal of the system is to launch two turtlesim windows, and have one turtle mimic the movements of the other. - -When launching the two turtlesim nodes, the primary difference between them is their namespace values. -Unique namespaces allow the system to start two nodes without node name or topic name conflicts. -Both turtles in this system receive commands over the same topic and publish their pose over the same topic. -With unique namespaces, messages meant for different turtles can be distinguished. - -The two turtlesim nodes also demonstrate different ways to pass arguments to nodes. -The first node uses ``args`` to pass arguments directly to the executable, requiring the ``--ros-args`` flag for ROS-specific arguments. -The second node uses ``ros_args`` (``ros_arguments`` in Python), designed specifically for ROS arguments. -Use ``args`` when mixing ROS and non-ROS arguments (e.g., ``my_custom_arg --ros-args --log-level info``), or ``ros_args`` for cleaner syntax with only ROS arguments like remappings, parameters, or log levels. - -The final node is also from the ``turtlesim`` package, but a different executable: ``mimic``. -This node has added configuration details in the form of remappings. -``mimic``'s ``/input/pose`` topic is remapped to ``/turtlesim1/turtle1/pose`` and it's ``/output/cmd_vel`` topic to ``/turtlesim2/turtle1/cmd_vel``. -This means ``mimic`` will subscribe to ``/turtlesim1/sim``'s pose topic and republish it for ``/turtlesim2/sim``'s velocity command topic to subscribe to. -In other words, ``turtlesim2`` will mimic ``turtlesim1``'s movements. - -.. tabs:: - - .. group-tab:: XML - - The first two actions launch the two turtlesim windows with different argument passing approaches: - - .. literalinclude:: launch/turtlesim_mimic_launch.xml - :language: xml - :lines: 3-4 - - The final action launches the mimic node with the remaps: - - .. literalinclude:: launch/turtlesim_mimic_launch.xml - :language: xml - :lines: 5-8 - - .. group-tab:: YAML - - The first two actions launch the two turtlesim windows with different argument passing approaches: - - .. literalinclude:: launch/turtlesim_mimic_launch.yaml - :language: yaml - :lines: 4-16 - - The final action launches the mimic node with the remaps: - - .. literalinclude:: launch/turtlesim_mimic_launch.yaml - :language: yaml - :lines: 18-26 - - .. group-tab:: Python - - These import statements pull in some Python ``launch`` modules. - - .. literalinclude:: launch/turtlesim_mimic_launch.py - :language: python - :lines: 1-2 - - Next, the launch description itself begins: - - .. literalinclude:: launch/turtlesim_mimic_launch.py - :language: python - :lines: 5-6,30 - - The first two actions in the launch description launch the two turtlesim windows with different argument passing approaches: - - .. literalinclude:: launch/turtlesim_mimic_launch.py - :language: python - :lines: 7-20 - - The final action launches the mimic node with the remaps: - - .. literalinclude:: launch/turtlesim_mimic_launch.py - :language: python - :lines: 21-29 - - -3 ros2 launch -^^^^^^^^^^^^^ - -To run the launch file created above, enter into the directory you created earlier and run the following command: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ cd launch - $ ros2 launch turtlesim_mimic_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ cd launch - $ ros2 launch turtlesim_mimic_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ cd launch - $ ros2 launch turtlesim_mimic_launch.py - -.. note:: - - It is possible to launch a launch file directly (as we do above), or provided by a package. - When it is provided by a package, the syntax is: - - .. code-block:: console - - $ ros2 launch - - You learned about creating packages in :doc:`../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package`. - -.. note:: - - For packages with launch files, it is a good idea to add an ``exec_depend`` dependency on the ``ros2launch`` package in your package's ``package.xml``: - - .. code-block:: xml - - ros2launch - - This helps make sure that the ``ros2 launch`` command is available after building your package. - It also ensures that all :doc:`launch file formats <../../../How-To-Guides/Launch-file-different-formats>` are recognized. - -Two turtlesim windows will open, and you will see the following ``[INFO]`` messages telling you which nodes your launch file has started: - -.. code-block:: console - - [INFO] [launch]: Default logging verbosity is set to INFO - [INFO] [turtlesim_node-1]: process started with pid [11714] - [INFO] [turtlesim_node-2]: process started with pid [11715] - [INFO] [mimic-3]: process started with pid [11716] - -To see the system in action, open a new terminal and run the ``ros2 topic pub`` command on the ``/turtlesim1/turtle1/cmd_vel`` topic to get the first turtle moving: - -.. code-block:: console - - $ ros2 topic pub -r 1 /turtlesim1/turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: -1.8}}" - -You will see both turtles following the same path. - -.. image:: images/mimic.png - -4 Introspect the system with rqt_graph -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While the system is still running, open a new terminal and run ``rqt_graph`` to get a better idea of the relationship between the nodes in your launch file. - -Run the command: - -.. code-block:: console - - $ ros2 run rqt_graph rqt_graph - -.. image:: images/mimic_graph.png - -A hidden node (the ``ros2 topic pub`` command you ran) is publishing data to the ``/turtlesim1/turtle1/cmd_vel`` topic on the left, which the ``/turtlesim1/sim`` node is subscribed to. -The rest of the graph shows what was described earlier: ``mimic`` is subscribed to ``/turtlesim1/sim``'s pose topic, and publishes to ``/turtlesim2/sim``'s velocity command topic. - -Summary -------- - -Launch files simplify running complex systems with many nodes and specific configuration details. -You can create launch files using XML, YAML, or Python, and run them using the ``ros2 launch`` command. +.. redirect-from:: + + Tutorials/Launch-Files/Creating-Launch-Files + Tutorials/Launch/Creating-Launch-Files + Tutorials/Intermediate/Launch/Creating-Launch-Files + +Creating a launch file +====================== + +**Goal:** Create a launch file to run a complex ROS 2 system. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Prerequisites +------------- + +This tutorial uses the :doc:`rqt_graph and turtlesim <../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` packages. + +You will also need to use a text editor of your preference. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../Get-Started/Configuring-ROS2-Environment>`. + +Background +---------- + +The launch system in ROS 2 is responsible for helping the user describe the configuration of their system and then execute it as described. +The configuration of the system includes what programs to run, where to run them, what arguments to pass them, and ROS-specific conventions which make it easy to reuse components throughout the system by giving them each a different configuration. +It is also responsible for monitoring the state of the processes launched, and reporting and/or reacting to changes in the state of those processes. + +Launch files written in XML, YAML, or Python can start and stop different nodes as well as trigger and act on various events. +See :doc:`Launch-file-different-formats` for a description of the different formats. +The package providing this framework is ``launch_ros``, which uses the non-ROS-specific ``launch`` framework underneath. + +The `design document `__ details the goal of the design of ROS 2's launch system (not all functionality is currently available). + +Tasks +----- + +1 Setup +^^^^^^^ + +Create a new directory to store your launch files: + +.. code-block:: console + + $ mkdir launch + +2 Write the launch file +^^^^^^^^^^^^^^^^^^^^^^^ + +Let's put together a ROS 2 launch file using the ``turtlesim`` package and its executables. +As mentioned above, this can either be in XML, YAML, or Python. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_mimic_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_mimic_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_mimic_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_mimic_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_mimic_launch.py`` file: + + .. literalinclude:: launch/turtlesim_mimic_launch.py + :language: python + + +2.1 Examine the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All of the launch files above are launching a system of three nodes, all from the ``turtlesim`` package. +The goal of the system is to launch two turtlesim windows, and have one turtle mimic the movements of the other. + +When launching the two turtlesim nodes, the primary difference between them is their namespace values. +Unique namespaces allow the system to start two nodes without node name or topic name conflicts. +Both turtles in this system receive commands over the same topic and publish their pose over the same topic. +With unique namespaces, messages meant for different turtles can be distinguished. + +The two turtlesim nodes also demonstrate different ways to pass arguments to nodes. +The first node uses ``args`` to pass arguments directly to the executable, requiring the ``--ros-args`` flag for ROS-specific arguments. +The second node uses ``ros_args`` (``ros_arguments`` in Python), designed specifically for ROS arguments. +Use ``args`` when mixing ROS and non-ROS arguments (e.g., ``my_custom_arg --ros-args --log-level info``), or ``ros_args`` for cleaner syntax with only ROS arguments like remappings, parameters, or log levels. + +The final node is also from the ``turtlesim`` package, but a different executable: ``mimic``. +This node has added configuration details in the form of remappings. +``mimic``'s ``/input/pose`` topic is remapped to ``/turtlesim1/turtle1/pose`` and it's ``/output/cmd_vel`` topic to ``/turtlesim2/turtle1/cmd_vel``. +This means ``mimic`` will subscribe to ``/turtlesim1/sim``'s pose topic and republish it for ``/turtlesim2/sim``'s velocity command topic to subscribe to. +In other words, ``turtlesim2`` will mimic ``turtlesim1``'s movements. + +.. tabs:: + + .. group-tab:: XML + + The first two actions launch the two turtlesim windows with different argument passing approaches: + + .. literalinclude:: launch/turtlesim_mimic_launch.xml + :language: xml + :lines: 3-4 + + The final action launches the mimic node with the remaps: + + .. literalinclude:: launch/turtlesim_mimic_launch.xml + :language: xml + :lines: 5-8 + + .. group-tab:: YAML + + The first two actions launch the two turtlesim windows with different argument passing approaches: + + .. literalinclude:: launch/turtlesim_mimic_launch.yaml + :language: yaml + :lines: 4-16 + + The final action launches the mimic node with the remaps: + + .. literalinclude:: launch/turtlesim_mimic_launch.yaml + :language: yaml + :lines: 18-26 + + .. group-tab:: Python + + These import statements pull in some Python ``launch`` modules. + + .. literalinclude:: launch/turtlesim_mimic_launch.py + :language: python + :lines: 1-2 + + Next, the launch description itself begins: + + .. literalinclude:: launch/turtlesim_mimic_launch.py + :language: python + :lines: 5-6,30 + + The first two actions in the launch description launch the two turtlesim windows with different argument passing approaches: + + .. literalinclude:: launch/turtlesim_mimic_launch.py + :language: python + :lines: 7-20 + + The final action launches the mimic node with the remaps: + + .. literalinclude:: launch/turtlesim_mimic_launch.py + :language: python + :lines: 21-29 + + +3 ros2 launch +^^^^^^^^^^^^^ + +To run the launch file created above, enter into the directory you created earlier and run the following command: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ cd launch + $ ros2 launch turtlesim_mimic_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ cd launch + $ ros2 launch turtlesim_mimic_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ cd launch + $ ros2 launch turtlesim_mimic_launch.py + +.. note:: + + It is possible to launch a launch file directly (as we do above), or provided by a package. + When it is provided by a package, the syntax is: + + .. code-block:: console + + $ ros2 launch + + You learned about creating packages in :doc:`../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package`. + +.. note:: + + For packages with launch files, it is a good idea to add an ``exec_depend`` dependency on the ``ros2launch`` package in your package's ``package.xml``: + + .. code-block:: xml + + ros2launch + + This helps make sure that the ``ros2 launch`` command is available after building your package. + It also ensures that all :doc:`launch file formats ` are recognized. + +Two turtlesim windows will open, and you will see the following ``[INFO]`` messages telling you which nodes your launch file has started: + +.. code-block:: console + + [INFO] [launch]: Default logging verbosity is set to INFO + [INFO] [turtlesim_node-1]: process started with pid [11714] + [INFO] [turtlesim_node-2]: process started with pid [11715] + [INFO] [mimic-3]: process started with pid [11716] + +To see the system in action, open a new terminal and run the ``ros2 topic pub`` command on the ``/turtlesim1/turtle1/cmd_vel`` topic to get the first turtle moving: + +.. code-block:: console + + $ ros2 topic pub -r 1 /turtlesim1/turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: -1.8}}" + +You will see both turtles following the same path. + +.. image:: images/mimic.png + +4 Introspect the system with rqt_graph +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While the system is still running, open a new terminal and run ``rqt_graph`` to get a better idea of the relationship between the nodes in your launch file. + +Run the command: + +.. code-block:: console + + $ ros2 run rqt_graph rqt_graph + +.. image:: images/mimic_graph.png + +A hidden node (the ``ros2 topic pub`` command you ran) is publishing data to the ``/turtlesim1/turtle1/cmd_vel`` topic on the left, which the ``/turtlesim1/sim`` node is subscribed to. +The rest of the graph shows what was described earlier: ``mimic`` is subscribed to ``/turtlesim1/sim``'s pose topic, and publishes to ``/turtlesim2/sim``'s velocity command topic. + +Summary +------- + +Launch files simplify running complex systems with many nodes and specific configuration details. +You can create launch files using XML, YAML, or Python, and run them using the ``ros2 launch`` command. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Launch-Main.rst b/source/Developer-Tools/Launch/Launch-Main.rst index b2a9920e857..2551371f146 100644 --- a/source/Developer-Tools/Launch/Launch-Main.rst +++ b/source/Developer-Tools/Launch/Launch-Main.rst @@ -1,45 +1,46 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Launch-Main - Tutorials/Launch/Launch-Main - -.. _LaunchFilesMain: - -Launch files -====== - -ROS 2 Launch files allow you to start up and configure a number of executables containing ROS 2 nodes simultaneously. - -.. toctree:: - :hidden: - - Creating-Launch-Files - Launch-system - Using-Substitutions - Using-Event-Handlers - Using-ROS2-Launch-For-Large-Projects - -#. :doc:`Creating a launch file <./Creating-Launch-Files>`. - - Learn how to create a launch file that will start up nodes and their configurations all at once. - -#. :doc:`Launching and monitoring multiple nodes <./Launch-system>`. - - Get a more advanced overview of how launch files work. - -#. :doc:`Using substitutions <./Using-Substitutions>`. - - Use substitutions to provide more flexibility when describing reusable launch files. - -#. :doc:`Using event handlers <./Using-Event-Handlers>`. - - Use event handlers to monitor the state of processes or to define a complex set of rules that can be used to dynamically modify the launch file. - -#. :doc:`Managing large projects <./Using-ROS2-Launch-For-Large-Projects>`. - - Structure launch files for large projects so they may be reused as much as possible in different situations. - See usage examples of different launch tools like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. - -.. note:: - - If you are coming from ROS 1, you can use the :doc:`ROS Launch Migration guide <../../../How-To-Guides/Migrating-from-ROS1/Migrating-Launch-Files>` to help you migrate your launch files to ROS 2. +.. redirect-from:: + + Tutorials/Launch-Files/Launch-Main + Tutorials/Launch/Launch-Main + Tutorials/Intermediate/Launch/Launch-Main + +.. _LaunchFilesMain: + +Launch files +====== + +ROS 2 Launch files allow you to start up and configure a number of executables containing ROS 2 nodes simultaneously. + +.. toctree:: + :hidden: + + Creating-Launch-Files + Launch-system + Using-Substitutions + Using-Event-Handlers + Using-ROS2-Launch-For-Large-Projects + +#. :doc:`Creating a launch file `. + + Learn how to create a launch file that will start up nodes and their configurations all at once. + +#. :doc:`Launching and monitoring multiple nodes `. + + Get a more advanced overview of how launch files work. + +#. :doc:`Using substitutions `. + + Use substitutions to provide more flexibility when describing reusable launch files. + +#. :doc:`Using event handlers `. + + Use event handlers to monitor the state of processes or to define a complex set of rules that can be used to dynamically modify the launch file. + +#. :doc:`Managing large projects `. + + Structure launch files for large projects so they may be reused as much as possible in different situations. + See usage examples of different launch tools like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. + +.. note:: + + If you are coming from ROS 1, you can use the :doc:`ROS Launch Migration guide <../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files>` to help you migrate your launch files to ROS 2. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Launch-file-different-formats.rst b/source/Developer-Tools/Launch/Launch-file-different-formats.rst index 5658a0edca7..38389aac21d 100644 --- a/source/Developer-Tools/Launch/Launch-file-different-formats.rst +++ b/source/Developer-Tools/Launch/Launch-file-different-formats.rst @@ -1,108 +1,109 @@ -.. redirect-from:: - - Guides/Launch-file-different-formats - -Using XML, YAML, and Python for ROS 2 Launch Files -================================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -ROS 2 launch files can be written in XML, YAML, and Python. -This guide shows how to use these different formats to accomplish the same task, as well as has some discussion on when to use each format. - -Launch file examples --------------------- - -Below is a launch file implemented in XML, YAML, and Python. -Each launch file performs the following actions: - -* Setup command line arguments with defaults -* Include another launch file -* Include another launch file in another namespace -* Start a node and setting its namespace -* Start a node, setting its namespace, and setting parameters in that node (using the args) -* Create a node to remap messages from one topic to another - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/different_formats_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/different_formats_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/different_formats_launch.py - :language: python - - -Using the Launch files from the command line --------------------------------------------- - -Launching -^^^^^^^^^ - -Any of the launch files above can be run with ``ros2 launch``. -To try them locally, you can either create a new package and use - -.. code-block:: console - - $ ros2 launch - -or run the file directly by specifying the path to the launch file - -.. code-block:: console - - $ ros2 launch - -Setting arguments -^^^^^^^^^^^^^^^^^ - -To set the arguments that are passed to the launch file, you should use ``key:=value`` syntax. -For example, you can set the value of ``background_r`` in the following way: - -.. code-block:: console - - $ ros2 launch background_r:=255 - -or - -.. code-block:: console - - $ ros2 launch background_r:=255 - -Controlling the turtles -^^^^^^^^^^^^^^^^^^^^^^^ - -To test that the remapping is working, you can control the turtles by running the following command in another terminal: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key --ros-args --remap __ns:=/turtlesim1 - - -.. _launch-file-different-formats-which: - -XML, YAML, or Python: Which should I use? ------------------------------------------ - -.. note:: - - Launch files in ROS 1 were written in XML, so XML may be the most familiar to people coming from ROS 1. - To see what's changed, you can visit :doc:`Migrating-from-ROS1/Migrating-Launch-Files`. - -For most applications the choice of which ROS 2 launch format comes down to developer preference. -However, if your launch file requires flexibility that you cannot achieve with XML or YAML, you can use Python to write your launch file. -Using Python for ROS 2 launch is more flexible because of following two reasons: - -* Python is a scripting language, and thus you can leverage the language and its libraries in your launch files. -* `ros2/launch `_ (general launch features) and `ros2/launch_ros `_ (ROS 2 specific launch features) are written in Python and thus you have lower level access to launch features that may not be exposed by XML and YAML. - -That being said, a launch file written in Python may be more complex and verbose than one in XML or YAML. +.. redirect-from:: + + Guides/Launch-file-different-formats + How-To-Guides/Launch-file-different-formats + +Using XML, YAML, and Python for ROS 2 Launch Files +================================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +ROS 2 launch files can be written in XML, YAML, and Python. +This guide shows how to use these different formats to accomplish the same task, as well as has some discussion on when to use each format. + +Launch file examples +-------------------- + +Below is a launch file implemented in XML, YAML, and Python. +Each launch file performs the following actions: + +* Setup command line arguments with defaults +* Include another launch file +* Include another launch file in another namespace +* Start a node and setting its namespace +* Start a node, setting its namespace, and setting parameters in that node (using the args) +* Create a node to remap messages from one topic to another + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/different_formats_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/different_formats_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/different_formats_launch.py + :language: python + + +Using the Launch files from the command line +-------------------------------------------- + +Launching +^^^^^^^^^ + +Any of the launch files above can be run with ``ros2 launch``. +To try them locally, you can either create a new package and use + +.. code-block:: console + + $ ros2 launch + +or run the file directly by specifying the path to the launch file + +.. code-block:: console + + $ ros2 launch + +Setting arguments +^^^^^^^^^^^^^^^^^ + +To set the arguments that are passed to the launch file, you should use ``key:=value`` syntax. +For example, you can set the value of ``background_r`` in the following way: + +.. code-block:: console + + $ ros2 launch background_r:=255 + +or + +.. code-block:: console + + $ ros2 launch background_r:=255 + +Controlling the turtles +^^^^^^^^^^^^^^^^^^^^^^^ + +To test that the remapping is working, you can control the turtles by running the following command in another terminal: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key --ros-args --remap __ns:=/turtlesim1 + + +.. _launch-file-different-formats-which: + +XML, YAML, or Python: Which should I use? +----------------------------------------- + +.. note:: + + Launch files in ROS 1 were written in XML, so XML may be the most familiar to people coming from ROS 1. + To see what's changed, you can visit :doc:`Migrating-from-ROS1/Migrating-Launch-Files`. + +For most applications the choice of which ROS 2 launch format comes down to developer preference. +However, if your launch file requires flexibility that you cannot achieve with XML or YAML, you can use Python to write your launch file. +Using Python for ROS 2 launch is more flexible because of following two reasons: + +* Python is a scripting language, and thus you can leverage the language and its libraries in your launch files. +* `ros2/launch `_ (general launch features) and `ros2/launch_ros `_ (ROS 2 specific launch features) are written in Python and thus you have lower level access to launch features that may not be exposed by XML and YAML. + +That being said, a launch file written in Python may be more complex and verbose than one in XML or YAML. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Launch-system.rst b/source/Developer-Tools/Launch/Launch-system.rst index a6a88f34e12..cbaca2a9011 100644 --- a/source/Developer-Tools/Launch/Launch-system.rst +++ b/source/Developer-Tools/Launch/Launch-system.rst @@ -1,234 +1,235 @@ -.. redirect-from:: - - Tutorials/Launch-system - Tutorials/Launch-Files/Launch-system - Tutorials/Launch/Launch-system - -Integrating launch files into ROS 2 packages -============================================ - -**Goal:** Add a launch file to a ROS 2 package - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Prerequisites -------------- - -You should have gone through the tutorial on how to :doc:`create a ROS 2 package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>`. - -Background ----------- - -In the :doc:`previous tutorial `, we saw how to write a standalone launch file. -This tutorial will show how to add a launch file to an existing package, and the conventions typically used. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Create a workspace for the package to live in: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p launch_ws/src - $ cd launch_ws/src - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p launch_ws/src - $ cd launch_ws/src - - .. group-tab:: Windows - - .. code-block:: console - - $ md launch_ws\src - $ cd launch_ws\src - -.. tabs:: - - .. group-tab:: Python package - - .. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_launch_example - - .. group-tab:: C++ package - - .. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_launch_example - -2 Creating the structure to hold launch files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -By convention, all launch files for a package are stored in the ``launch`` directory inside of the package. -Make sure to create a ``launch`` directory at the top-level of the package you created above. - -.. tabs:: - - .. group-tab:: Python package - - For Python packages, the directory containing your package should look like this: - - .. code-block:: console - - src/ - py_launch_example/ - launch/ - package.xml - py_launch_example/ - resource/ - setup.cfg - setup.py - test/ - - To enable colcon to locate and utilize our launch files, we need to inform Python's setup tools of their presence. - To achieve this, open the ``setup.py`` file, add the necessary ``import`` statements at the top, and include the launch files into the ``data_files`` parameter of ``setup``: - - .. code-block:: python - - import os - from glob import glob - # Other imports ... - - package_name = 'py_launch_example' - - setup( - # Other parameters ... - data_files=[ - # ... Other data files - # Include all launch files. - (os.path.join('share', package_name, 'launch'), glob('launch/*')) - ] - ) - - .. group-tab:: C++ package - - For C++ packages, we will only be adjusting the ``CMakeLists.txt`` file by adding: - - .. code-block:: cmake - - # Install launch files. - install(DIRECTORY - launch - DESTINATION share/${PROJECT_NAME}/ - ) - - to the end of the file (but before ``ament_package()``). - - -3 Writing the launch file -^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: XML launch file - - Inside your ``launch`` directory, create a new launch file called ``my_script_launch.xml``. - ``_launch.xml`` is recommended, but not required, as the file suffix for XML launch files. - - .. literalinclude:: launch/my_script_launch.xml - :language: xml - - .. group-tab:: YAML launch file - - Inside your ``launch`` directory, create a new launch file called ``my_script_launch.yaml``. - ``_launch.yaml`` is recommended, but not required, as the file suffix for YAML launch files. - - .. literalinclude:: launch/my_script_launch.yaml - :language: yaml - - .. group-tab:: Python launch file - - Inside your ``launch`` directory, create a new launch file called ``my_script_launch.py``. - ``_launch.py`` is recommended, but not required, as the file suffix for Python launch files. - However, the launch file name needs to end with ``launch.py`` to be recognized and autocompleted by ``ros2 launch``. - - Your launch file should define the ``generate_launch_description()`` function which returns a ``launch.LaunchDescription()`` to be used by the ``ros2 launch`` verb. - - .. literalinclude:: launch/my_script_launch.py - :language: python - - -4 Building and running the launch file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Go to the top-level of the workspace, and build it: - -.. code-block:: console - - $ colcon build - -After the ``colcon build`` has been successful and you've sourced the workspace, you should be able to run the launch file as follows: - -.. tabs:: - - .. group-tab:: Python package - - .. tabs:: - - .. group-tab:: XML launch file - - .. code-block:: console - - $ ros2 launch py_launch_example my_script_launch.xml - - .. group-tab:: YAML launch file - - .. code-block:: console - - $ ros2 launch py_launch_example my_script_launch.yaml - - .. group-tab:: Python launch file - - .. code-block:: console - - $ ros2 launch py_launch_example my_script_launch.py - - .. group-tab:: C++ package - - .. tabs:: - - .. group-tab:: XML launch file - - .. code-block:: console - - $ ros2 launch cpp_launch_example my_script_launch.xml - - .. group-tab:: YAML launch file - - .. code-block:: console - - $ ros2 launch cpp_launch_example my_script_launch.yaml - - .. group-tab:: Python launch file - - .. code-block:: console - - $ ros2 launch cpp_launch_example my_script_launch.py - - -Documentation -------------- - -`The launch documentation `__ provides more details on concepts that are also used in ``launch_ros``. - -Additional documentation/examples of launch capabilities are forthcoming. -See the source code (https://github.com/ros2/launch and https://github.com/ros2/launch_ros) in the meantime. +.. redirect-from:: + + Tutorials/Launch-system + Tutorials/Launch-Files/Launch-system + Tutorials/Launch/Launch-system + Tutorials/Intermediate/Launch/Launch-system + +Integrating launch files into ROS 2 packages +============================================ + +**Goal:** Add a launch file to a ROS 2 package + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Prerequisites +------------- + +You should have gone through the tutorial on how to :doc:`create a ROS 2 package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../Get-Started/Configuring-ROS2-Environment>`. + +Background +---------- + +In the :doc:`previous tutorial `, we saw how to write a standalone launch file. +This tutorial will show how to add a launch file to an existing package, and the conventions typically used. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Create a workspace for the package to live in: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p launch_ws/src + $ cd launch_ws/src + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p launch_ws/src + $ cd launch_ws/src + + .. group-tab:: Windows + + .. code-block:: console + + $ md launch_ws\src + $ cd launch_ws\src + +.. tabs:: + + .. group-tab:: Python package + + .. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_launch_example + + .. group-tab:: C++ package + + .. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_launch_example + +2 Creating the structure to hold launch files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +By convention, all launch files for a package are stored in the ``launch`` directory inside of the package. +Make sure to create a ``launch`` directory at the top-level of the package you created above. + +.. tabs:: + + .. group-tab:: Python package + + For Python packages, the directory containing your package should look like this: + + .. code-block:: console + + src/ + py_launch_example/ + launch/ + package.xml + py_launch_example/ + resource/ + setup.cfg + setup.py + test/ + + To enable colcon to locate and utilize our launch files, we need to inform Python's setup tools of their presence. + To achieve this, open the ``setup.py`` file, add the necessary ``import`` statements at the top, and include the launch files into the ``data_files`` parameter of ``setup``: + + .. code-block:: python + + import os + from glob import glob + # Other imports ... + + package_name = 'py_launch_example' + + setup( + # Other parameters ... + data_files=[ + # ... Other data files + # Include all launch files. + (os.path.join('share', package_name, 'launch'), glob('launch/*')) + ] + ) + + .. group-tab:: C++ package + + For C++ packages, we will only be adjusting the ``CMakeLists.txt`` file by adding: + + .. code-block:: cmake + + # Install launch files. + install(DIRECTORY + launch + DESTINATION share/${PROJECT_NAME}/ + ) + + to the end of the file (but before ``ament_package()``). + + +3 Writing the launch file +^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: XML launch file + + Inside your ``launch`` directory, create a new launch file called ``my_script_launch.xml``. + ``_launch.xml`` is recommended, but not required, as the file suffix for XML launch files. + + .. literalinclude:: launch/my_script_launch.xml + :language: xml + + .. group-tab:: YAML launch file + + Inside your ``launch`` directory, create a new launch file called ``my_script_launch.yaml``. + ``_launch.yaml`` is recommended, but not required, as the file suffix for YAML launch files. + + .. literalinclude:: launch/my_script_launch.yaml + :language: yaml + + .. group-tab:: Python launch file + + Inside your ``launch`` directory, create a new launch file called ``my_script_launch.py``. + ``_launch.py`` is recommended, but not required, as the file suffix for Python launch files. + However, the launch file name needs to end with ``launch.py`` to be recognized and autocompleted by ``ros2 launch``. + + Your launch file should define the ``generate_launch_description()`` function which returns a ``launch.LaunchDescription()`` to be used by the ``ros2 launch`` verb. + + .. literalinclude:: launch/my_script_launch.py + :language: python + + +4 Building and running the launch file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Go to the top-level of the workspace, and build it: + +.. code-block:: console + + $ colcon build + +After the ``colcon build`` has been successful and you've sourced the workspace, you should be able to run the launch file as follows: + +.. tabs:: + + .. group-tab:: Python package + + .. tabs:: + + .. group-tab:: XML launch file + + .. code-block:: console + + $ ros2 launch py_launch_example my_script_launch.xml + + .. group-tab:: YAML launch file + + .. code-block:: console + + $ ros2 launch py_launch_example my_script_launch.yaml + + .. group-tab:: Python launch file + + .. code-block:: console + + $ ros2 launch py_launch_example my_script_launch.py + + .. group-tab:: C++ package + + .. tabs:: + + .. group-tab:: XML launch file + + .. code-block:: console + + $ ros2 launch cpp_launch_example my_script_launch.xml + + .. group-tab:: YAML launch file + + .. code-block:: console + + $ ros2 launch cpp_launch_example my_script_launch.yaml + + .. group-tab:: Python launch file + + .. code-block:: console + + $ ros2 launch cpp_launch_example my_script_launch.py + + +Documentation +------------- + +`The launch documentation `__ provides more details on concepts that are also used in ``launch_ros``. + +Additional documentation/examples of launch capabilities are forthcoming. +See the source code (https://github.com/ros2/launch and https://github.com/ros2/launch_ros) in the meantime. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Launching-composable-nodes.rst b/source/Developer-Tools/Launch/Launching-composable-nodes.rst index 02d58e6be01..a8de2d3391f 100644 --- a/source/Developer-Tools/Launch/Launching-composable-nodes.rst +++ b/source/Developer-Tools/Launch/Launching-composable-nodes.rst @@ -1,93 +1,97 @@ -Using ROS 2 launch to launch composable nodes -============================================= - -.. contents:: Table of Contents - :depth: 1 - :local: - -In the :doc:`Composition tutorial <../Tutorials/Intermediate/Composition>`, you learned about composable nodes and how to use them from the command-line. -In the :doc:`Launch tutorials <../Tutorials/Intermediate/Launch/Launch-Main>`, you learned about launch files and how to use them to manage multiple nodes. - -This guide will combine the above two topics and teach you how to write launch files for composable nodes. - -Setup ------ - -See the :doc:`installation instructions <../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-image-tools`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Launch file examples --------------------- - -Below is a launch file that launches composable nodes in XML, YAML, and Python. -The launch files all do the following: - -* Instantiate a cam2image composable node with remappings, custom parameters, and extra arguments -* Instantiate a showimage composable node with remappings, custom parameters, and extra arguments - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/composition_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/composition_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/composition_launch.py - :language: python - - -Loading composable nodes into an existing container ---------------------------------------------------- - -Containers can sometimes be launched by other launch files or from a commandline. -In that case, you need to add your components to an existing container. -For this, you may use ``LoadComposableNodes`` to load components into a given container. -The below example launches the same nodes as above. - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/composition_load_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/composition_load_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/composition_load_launch.py - :language: python - - -Using the Launch files from the command-line --------------------------------------------- - -Any of the launch files above can be run with ``ros2 launch``. -Copy the data into a local file, and then run: - -.. code-block:: console - - $ ros2 launch - -Intra-process communications ----------------------------- - -All of the above examples use an extra argument to setup intra-process communication between the nodes. -For more information on what intra-process communications are, see the :doc:`intra-process comms tutorial <../Tutorials/Demos/Intra-Process-Communication>`. - -XML, YAML, or Python: Which should I use? ------------------------------------------ - -See the :ref:`discussion ` in :doc:`Launch-file-different-formats` for more information. +.. redirect-from:: + + How-To-Guides/Launching-composable-nodes + +Using ROS 2 launch to launch composable nodes +============================================= + +.. contents:: Table of Contents + :depth: 1 + :local: + +In the :doc:`Composition tutorial <../../ROS-Framework/nodes/Working-with-nodes/Composition>`, you learned about composable nodes and how to use them from the command-line. +In the :doc:`Launch tutorials `, you learned about launch files and how to use them to manage multiple nodes. + +This guide will combine the above two topics and teach you how to write launch files for composable nodes. + +Setup +----- + +See the :doc:`installation instructions <../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-image-tools`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Launch file examples +-------------------- + +Below is a launch file that launches composable nodes in XML, YAML, and Python. +The launch files all do the following: + +* Instantiate a cam2image composable node with remappings, custom parameters, and extra arguments +* Instantiate a showimage composable node with remappings, custom parameters, and extra arguments + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/composition_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/composition_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/composition_launch.py + :language: python + + +Loading composable nodes into an existing container +--------------------------------------------------- + +Containers can sometimes be launched by other launch files or from a commandline. +In that case, you need to add your components to an existing container. +For this, you may use ``LoadComposableNodes`` to load components into a given container. +The below example launches the same nodes as above. + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/composition_load_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/composition_load_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/composition_load_launch.py + :language: python + + +Using the Launch files from the command-line +-------------------------------------------- + +Any of the launch files above can be run with ``ros2 launch``. +Copy the data into a local file, and then run: + +.. code-block:: console + + $ ros2 launch + +Intra-process communications +---------------------------- + +All of the above examples use an extra argument to setup intra-process communication between the nodes. +For more information on what intra-process communications are, see the :doc:`intra-process comms tutorial <../../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>`. + +XML, YAML, or Python: Which should I use? +----------------------------------------- + +See the :ref:`discussion ` in :doc:`Launch-file-different-formats` for more information. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Using-Event-Handlers.rst b/source/Developer-Tools/Launch/Using-Event-Handlers.rst index 1642bb6952a..88e22449fa3 100644 --- a/source/Developer-Tools/Launch/Using-Event-Handlers.rst +++ b/source/Developer-Tools/Launch/Using-Event-Handlers.rst @@ -1,134 +1,135 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Using-Event-Handlers - Tutorials/Launch/Using-Event-Handlers - -Using event handlers -==================== - -**Goal:** Learn about event handlers in ROS 2 launch files - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -Launch in ROS 2 is a system that executes and manages user-defined processes. -It is responsible for monitoring the state of processes it launched, as well as reporting and reacting to changes in the state of those processes. -These changes are called events and can be handled by registering an event handler with the launch system. -Event handlers can be registered for specific events and can be useful for monitoring the state of processes. -Additionally, they can be used to define a complex set of rules which can be used to dynamically modify the launch file. - -This tutorial shows usage examples of event handlers in ROS 2 launch files. - -Prerequisites -------------- - -This tutorial uses the :doc:`turtlesim <../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>` package. -This tutorial also assumes you have :doc:`created a new package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>` of build type ``ament_python`` called ``launch_tutorial``. - -This tutorial extends the code shown in the :doc:`Using substitutions in launch files <./Using-Substitutions>` tutorial. - -Using event handlers --------------------- - -1 Event handlers example launch file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Create a new file called ``example_event_handlers_launch.py`` in the ``launch`` folder of the ``launch_tutorial`` package. - -.. literalinclude:: launch/example_event_handlers_launch.py - :language: python - -``RegisterEventHandler`` actions for the ``OnProcessStart``, ``OnProcessIO``, ``OnExecutionComplete``, ``OnProcessExit``, and ``OnShutdown`` events were defined in the launch description. - -The ``OnProcessStart`` event handler is used to register a callback function that is executed when the turtlesim node starts. -It logs a message to the console and executes the ``spawn_turtle`` action when the turtlesim node starts. - -.. literalinclude:: launch/example_event_handlers_launch.py - :language: python - :lines: 98-106 - -The ``OnProcessIO`` event handler is used to register a callback function that is executed when the ``spawn_turtle`` action writes to its standard output. -It logs the result of the spawn request. - -.. literalinclude:: launch/example_event_handlers_launch.py - :language: python - :lines: 107-115 - -The ``OnExecutionComplete`` event handler is used to register a callback function that is executed when the ``spawn_turtle`` action completes. -It logs a message to the console and executes the ``change_background_r`` and ``change_background_r_conditioned`` actions when the spawn action completes. - -.. literalinclude:: launch/example_event_handlers_launch.py - :language: python - :lines: 116-128 - -The ``OnProcessExit`` event handler is used to register a callback function that is executed when the turtlesim node exits. -It logs a message to the console and executes the ``EmitEvent`` action to emit a ``Shutdown`` event when the turtlesim node exits. -It means that the launch process will shutdown when the turtlesim window is closed. - -.. literalinclude:: launch/example_event_handlers_launch.py - :language: python - :lines: 129-139 - -Finally, the ``OnShutdown`` event handler is used to register a callback function that is executed when the launch file is asked to shutdown. -It logs a message to the console why the launch file is asked to shutdown. -It logs the message with a reason for shutdown like the closure of turtlesim window or :kbd:`ctrl-c` signal made by the user. - -.. literalinclude:: launch/example_event_handlers_launch.py - :language: python - :lines: 140-146 - -Build the package ------------------ - -Go to the root of the workspace, and build the package: - -.. code-block:: console - - $ colcon build - -Also remember to source the workspace after building. - -Launching example ------------------ - -Now you can launch the ``example_event_handlers_launch.py`` file using the ``ros2 launch`` command. - -.. code-block:: console - - $ ros2 launch launch_tutorial example_event_handlers_launch.py turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 - -This will do the following: - -#. Start a turtlesim node with a blue background -#. Spawn the second turtle -#. Change the color to purple -#. Change the color to pink after two seconds if the provided ``background_r`` argument is ``200`` and ``use_provided_red`` argument is ``True`` -#. Shutdown the launch file when the turtlesim window is closed - -Additionally, it will log messages to the console when: - -#. The turtlesim node starts -#. The spawn action is executed -#. The ``change_background_r`` action is executed -#. The ``change_background_r_conditioned`` action is executed -#. The turtlesim node exits -#. The launch process is asked to shutdown. - -Documentation -------------- - -`The launch documentation `_ provides detailed information about available event handlers. - -Summary -------- - -In this tutorial, you learned about using event handlers in launch files. -You learned about their syntax and usage examples to define a complex set of rules to dynamically modify launch files. +.. redirect-from:: + + Tutorials/Launch-Files/Using-Event-Handlers + Tutorials/Launch/Using-Event-Handlers + Tutorials/Intermediate/Launch/Using-Event-Handlers + +Using event handlers +==================== + +**Goal:** Learn about event handlers in ROS 2 launch files + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +Launch in ROS 2 is a system that executes and manages user-defined processes. +It is responsible for monitoring the state of processes it launched, as well as reporting and reacting to changes in the state of those processes. +These changes are called events and can be handled by registering an event handler with the launch system. +Event handlers can be registered for specific events and can be useful for monitoring the state of processes. +Additionally, they can be used to define a complex set of rules which can be used to dynamically modify the launch file. + +This tutorial shows usage examples of event handlers in ROS 2 launch files. + +Prerequisites +------------- + +This tutorial uses the :doc:`turtlesim <../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` package. +This tutorial also assumes you have :doc:`created a new package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` of build type ``ament_python`` called ``launch_tutorial``. + +This tutorial extends the code shown in the :doc:`Using substitutions in launch files ` tutorial. + +Using event handlers +-------------------- + +1 Event handlers example launch file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Create a new file called ``example_event_handlers_launch.py`` in the ``launch`` folder of the ``launch_tutorial`` package. + +.. literalinclude:: launch/example_event_handlers_launch.py + :language: python + +``RegisterEventHandler`` actions for the ``OnProcessStart``, ``OnProcessIO``, ``OnExecutionComplete``, ``OnProcessExit``, and ``OnShutdown`` events were defined in the launch description. + +The ``OnProcessStart`` event handler is used to register a callback function that is executed when the turtlesim node starts. +It logs a message to the console and executes the ``spawn_turtle`` action when the turtlesim node starts. + +.. literalinclude:: launch/example_event_handlers_launch.py + :language: python + :lines: 98-106 + +The ``OnProcessIO`` event handler is used to register a callback function that is executed when the ``spawn_turtle`` action writes to its standard output. +It logs the result of the spawn request. + +.. literalinclude:: launch/example_event_handlers_launch.py + :language: python + :lines: 107-115 + +The ``OnExecutionComplete`` event handler is used to register a callback function that is executed when the ``spawn_turtle`` action completes. +It logs a message to the console and executes the ``change_background_r`` and ``change_background_r_conditioned`` actions when the spawn action completes. + +.. literalinclude:: launch/example_event_handlers_launch.py + :language: python + :lines: 116-128 + +The ``OnProcessExit`` event handler is used to register a callback function that is executed when the turtlesim node exits. +It logs a message to the console and executes the ``EmitEvent`` action to emit a ``Shutdown`` event when the turtlesim node exits. +It means that the launch process will shutdown when the turtlesim window is closed. + +.. literalinclude:: launch/example_event_handlers_launch.py + :language: python + :lines: 129-139 + +Finally, the ``OnShutdown`` event handler is used to register a callback function that is executed when the launch file is asked to shutdown. +It logs a message to the console why the launch file is asked to shutdown. +It logs the message with a reason for shutdown like the closure of turtlesim window or :kbd:`ctrl-c` signal made by the user. + +.. literalinclude:: launch/example_event_handlers_launch.py + :language: python + :lines: 140-146 + +Build the package +----------------- + +Go to the root of the workspace, and build the package: + +.. code-block:: console + + $ colcon build + +Also remember to source the workspace after building. + +Launching example +----------------- + +Now you can launch the ``example_event_handlers_launch.py`` file using the ``ros2 launch`` command. + +.. code-block:: console + + $ ros2 launch launch_tutorial example_event_handlers_launch.py turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 + +This will do the following: + +#. Start a turtlesim node with a blue background +#. Spawn the second turtle +#. Change the color to purple +#. Change the color to pink after two seconds if the provided ``background_r`` argument is ``200`` and ``use_provided_red`` argument is ``True`` +#. Shutdown the launch file when the turtlesim window is closed + +Additionally, it will log messages to the console when: + +#. The turtlesim node starts +#. The spawn action is executed +#. The ``change_background_r`` action is executed +#. The ``change_background_r_conditioned`` action is executed +#. The turtlesim node exits +#. The launch process is asked to shutdown. + +Documentation +------------- + +`The launch documentation `_ provides detailed information about available event handlers. + +Summary +------- + +In this tutorial, you learned about using event handlers in launch files. +You learned about their syntax and usage examples to define a complex set of rules to dynamically modify launch files. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst b/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst index 03d59099322..1653dc3c7e0 100644 --- a/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst +++ b/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst @@ -1,550 +1,551 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Using-ROS2-Launch-for-Large-Projects - Tutorials/Launch/Using-ROS2-Launch-for-Large-Projects - -.. _UsingROS2LaunchForLargeProjects: - -Managing large projects -======================= - -**Goal:** Learn best practices of managing large projects using ROS 2 launch files. - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 3 - :local: - -Background ----------- - -This tutorial describes some tips for writing launch files for large projects. -The focus is on how to structure launch files so they may be reused as much as possible in different situations. -Additionally, it covers usage examples of different ROS 2 launch tools, like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. - -Prerequisites -------------- - -This tutorial uses the :doc:`turtlesim <../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>` and :doc:`turtle_tf2_py <../Tf2/Introduction-To-Tf2>` packages. -This tutorial also assumes you have :doc:`created a new package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>` of build type ``ament_python`` called ``launch_tutorial``. - -Introduction ------------- - -Large applications on a robot typically involve several interconnected nodes, each of which can have many parameters. -Simulation of multiple turtles in the turtle simulator can serve as a good example. -The turtle simulation consists of multiple turtle nodes, the world configuration, and the TF broadcaster and listener nodes. -Between all of the nodes, there are a large number of ROS parameters that affect the behavior and appearance of these nodes. -ROS 2 launch files allow us to start all nodes and set corresponding parameters in one place. -By the end of a tutorial, you will build the ``launch_turtlesim_launch`` launch file in the ``launch_tutorial`` package. -This launch file will bring up different nodes responsible for the simulation of two turtlesim simulations, starting TF broadcasters and listener, loading parameters, and launching an RViz configuration. -In this tutorial, we'll go over this launch file and all related features used. - -.. attention:: Launch files can be written in XML, YAML, or Python format. - Throughout this tutorial, launch files are shown in all three formats using tabs. - You can choose whichever format you prefer - they are functionally equivalent. - Wherever you see the file name ``launch_turtlesim_launch`` make sure to use the correct file extension for your launch file type (i.e. ``launch_turtlesim_launch.py`` for Python, ``launch_turtlesim_launch.xml`` for XML, and ``launch_turtlesim_launch.yaml`` for YAML. - -Writing launch files --------------------- - -1 Top-level organization -^^^^^^^^^^^^^^^^^^^^^^^^ - -One of the aims in the process of writing launch files should be making them as reusable as possible. -This could be done by clustering related nodes and configurations into separate launch files. -Afterwards, a top-level launch file dedicated to a specific configuration could be written. -This would allow moving between identical robots to be done without changing the launch files at all. -Even a change such as moving from a real robot to a simulated one can be done with only a few changes. - -We will now go over the top-level launch file structure that makes this possible. -Firstly, we will create a launch file that will call separate launch files. -To do this, let's create a ``launch_turtlesim_launch`` file in the ``/launch`` folder of our ``launch_tutorial`` package. - -.. attention:: - - Earlier launch system versions may not support ``let`` inside ``include`` statements and require ``arg`` instead. - The syntax is the same: ``name`` and ``value`` attributes remain unchanged (e.g., ````). - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/launch_turtlesim_launch.xml`` file: - - .. literalinclude:: launch/launch_turtlesim_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/launch_turtlesim_launch.yaml`` file: - - .. literalinclude:: launch/launch_turtlesim_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/launch_turtlesim_launch.py`` file: - - .. literalinclude:: launch/launch_turtlesim_launch.py - :language: python - -This launch file includes a set of other launch files. -Each of these included launch files contains nodes, parameters, and possibly, nested includes, which pertain to one part of the system. -To be exact, we launch two turtlesim simulation worlds, TF broadcaster, TF listener, mimic, fixed frame broadcaster, and RViz nodes. - -.. note:: Design Tip: Top-level launch files should be short, consist of includes to other files corresponding to subcomponents of the application, and commonly changed parameters. - -Writing launch files in the following manner makes it easy to swap out one piece of the system, as we'll see later. -However, there are cases when some nodes or launch files have to be launched separately due to performance and usage reasons. - -.. note:: Design tip: Be aware of the tradeoffs when deciding how many top-level launch files your application requires. - -.. _Parameters: - -2 Parameters -^^^^^^^^^^^^ - -2.1 Setting parameters in the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We will begin by writing a launch file that will start our first turtlesim simulation. -First, create a new file called ``turtlesim_world_1_launch``. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_world_1_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_world_1_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.py`` file: - - .. literalinclude:: launch/turtlesim_world_1_launch.py - :language: python - -This launch file starts the ``turtlesim_node`` node, which starts the turtlesim simulation, with simulation configuration parameters that are defined and passed to the nodes. - -.. _LoadingParametersFromYAMLFile: - -2.2 Loading parameters from YAML file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the second launch, we will start a second turtlesim simulation with a different configuration. -Now create a ``turtlesim_world_2_launch`` file. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_world_2_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_world_2_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.py`` file: - - .. literalinclude:: launch/turtlesim_world_2_launch.py - :language: python - -This launch file will launch the same ``turtlesim_node`` with parameter values that are loaded directly from the YAML configuration file. -Defining arguments and parameters in YAML files make it easy to store and load a large number of variables. -It is also worth noting that this YAML file is not another launch file, it is a configuration file for the ``turtlesim_node`` that sets parameters for the node. -In addition, YAML files can be easily exported from the current ``ros2 param`` list. -To learn how to do that, refer to the :doc:`Understand parameters <../../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. - -Let's now create a configuration file, ``turtlesim.yaml``, in the ``/config`` folder of our package, which will be loaded by our launch file. - -.. code-block:: YAML - - /turtlesim2/sim: - ros__parameters: - background_b: 255 - background_g: 86 - background_r: 150 - -To learn more about using parameters and using YAML files, take a look at the :doc:`Understand parameters <../../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. - -2.3 Using wildcards in YAML files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are cases when we want to set the same parameters in more than one node. -These nodes could have different namespaces or names but still have the same parameters. -Defining separate YAML files that explicitly define namespaces and node names is not efficient. -A solution is to use wildcard characters, which act as substitutions for unknown characters in a text value, to apply parameters to several different nodes. - -Now let's create a new ``turtlesim_world_3_launch`` file similar to ``turtlesim_world_2_launch`` to include one more ``turtlesim_node`` node in a new namespace ``turtlesim3``: - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_world_3_launch.xml - :language: xml - :emphasize-lines: 3 - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_world_3_launch.yaml - :language: yaml - :emphasize-lines: 7 - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.py`` file: - - .. literalinclude:: launch/turtlesim_world_3_launch.py - :language: python - :emphasize-lines: 12 - -Loading the same YAML file, however, will not affect the appearance of the third turtlesim world. -The reason is that its parameters are stored under another namespace as shown below: - -.. code-block:: console - - /turtlesim3/sim: - background_b - background_g - background_r - -Therefore, instead of creating a new configuration for the same node that use the same parameters, we can use wildcards syntax. -``/**`` will assign all the parameters in every node, despite differences in node names and namespaces. - -We will now update the ``turtlesim.yaml``, in the ``/config`` folder in the following manner: - -.. code-block:: YAML - - /**: - ros__parameters: - background_b: 255 - background_g: 86 - background_r: 150 - -Now include the ``turtlesim_world_3_launch`` launch description in our main launch file. -Using that configuration file in our launch descriptions will assign ``background_b``, ``background_g``, and ``background_r`` parameters to specified values in ``turtlesim3/sim`` and ``turtlesim2/sim`` nodes. - -3 Namespaces -^^^^^^^^^^^^ - -As you may have noticed, we have defined the namespace for the turtlesim world in the ``turtlesim_world_2_launch`` file. -Unique namespaces allow the system to start two similar nodes without node name or topic name conflicts. - -.. code-block:: Python - - namespace='turtlesim2', - -However, if the launch file contains a large number of nodes, defining namespaces for each of them can become tedious. -To solve that issue, the ``PushROSNamespace`` action can be used to define the global namespace for each launch file description. -Every nested node will inherit that namespace automatically. - -.. attention:: ``PushROSNamespace`` has to be the first action in the list for the following actions to apply the namespace. - -To do that, firstly, we need to remove the ``namespace='turtlesim2'`` line from the ``turtlesim_world_2_launch`` file. -Afterwards, we need to update the ``launch_turtlesim_launch`` to change the include statement to the following: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: xml - - - - - - - .. group-tab:: YAML - - .. code-block:: yaml - - - group: - - push_ros_namespace: - namespace: "turtlesim2" - - include: - file: "$(find-pkg-share launch_tutorial)/launch/turtlesim_world_2_launch.yaml" - - .. group-tab:: Python - - .. code-block:: python - - from launch.actions import GroupAction - from launch_ros.actions import PushROSNamespace - - ... - GroupAction( - actions=[ - PushROSNamespace('turtlesim2'), - IncludeLaunchDescription(PathJoinSubstitution([launch_dir, 'turtlesim_world_2_launch.py'])), - ] - ), - -As a result, each node in the ``turtlesim_world_2_launch`` launch description will have a ``turtlesim2`` namespace. - -4 Reusing nodes -^^^^^^^^^^^^^^^ - -Now create a ``broadcaster_listener_launch`` file. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/broadcaster_listener_launch.xml`` file: - - .. literalinclude:: launch/broadcaster_listener_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/broadcaster_listener_launch.yaml`` file: - - .. literalinclude:: launch/broadcaster_listener_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/broadcaster_listener_launch.py`` file: - - .. literalinclude:: launch/broadcaster_listener_launch.py - :language: python - -In this file, we have declared the ``target_frame`` launch argument with a default value of ``turtle1``. -The default value means that the launch file can receive an argument to forward to its nodes, or in case the argument is not provided, it will pass the default value to its nodes. - -Afterwards, we use the ``turtle_tf2_broadcaster`` node two times using different names and parameters during launch. -This allows us to duplicate the same node without conflicts. - -We also start a ``turtle_tf2_listener`` node and set its ``target_frame`` parameter that we declared and acquired above. - -5 Parameter overrides -^^^^^^^^^^^^^^^^^^^^^ - -Recall that we called the ``broadcaster_listener_launch`` file in our top-level launch file. -In addition to that, we have passed it ``target_frame`` launch argument as shown below: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/launch_turtlesim_launch.xml - :language: xml - :lines: 5-7 - - .. group-tab:: YAML - - .. literalinclude:: launch/launch_turtlesim_launch.yaml - :language: yaml - :lines: 8-12 - - .. group-tab:: Python - - .. literalinclude:: launch/launch_turtlesim_launch.py - :language: python - :lines: 16-19 - -This syntax allows us to change the default goal target frame to ``carrot1``. -If you would like ``turtle2`` to follow ``turtle1`` instead of the ``carrot1``, just remove the line that passes the ``target_frame`` argument. -This will assign ``target_frame`` its default value, which is ``turtle1``. - -6 Remapping -^^^^^^^^^^^ - -Now create a ``mimic_launch`` file. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/mimic_launch.xml`` file: - - .. literalinclude:: launch/mimic_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/mimic_launch.yaml`` file: - - .. literalinclude:: launch/mimic_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/mimic_launch.py`` file: - - .. literalinclude:: launch/mimic_launch.py - :language: python - -This launch file will start the ``mimic`` node, which will give commands to one turtlesim to follow the other. -The node is designed to receive the target pose on the topic ``/input/pose``. -In our case, we want to remap the target pose from ``/turtle2/pose`` topic. -Finally, we remap the ``/output/cmd_vel`` topic to ``/turtlesim2/turtle1/cmd_vel``. -This way ``turtle1`` in our ``turtlesim2`` simulation world will follow ``turtle2`` in our initial turtlesim world. - -7 Config files -^^^^^^^^^^^^^^ - -Let's now create a file called ``turtlesim_rviz_launch``. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_rviz_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_rviz_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.py`` file: - - .. literalinclude:: launch/turtlesim_rviz_launch.py - :language: python - -This launch file will start the RViz with the configuration file defined in the ``turtle_tf2_py`` package. -This RViz configuration will set the world frame, enable TF visualization, and start RViz with a top-down view. - -8 Environment Variables -^^^^^^^^^^^^^^^^^^^^^^^ - -Let's now create the last launch file called ``fixed_broadcaster_launch`` in our package. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.xml`` file: - - .. literalinclude:: launch/fixed_broadcaster_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.yaml`` file: - - .. literalinclude:: launch/fixed_broadcaster_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.py`` file: - - .. literalinclude:: launch/fixed_broadcaster_launch.py - :language: python - -This launch file shows the way environment variables can be called inside the launch files. -Environment variables can be used to define or push namespaces for distinguishing nodes on different computers or robots. - -.. note:: If you are running the launch file where the ``USER`` environment variable is not defined (like in the ROS docker file), then you can replace the environment variable reference above with any other word of your liking. - -Running launch files --------------------- - -1 Update setup.py -^^^^^^^^^^^^^^^^^ - -Open ``setup.py`` and add the following lines so that the launch files from the ``launch/`` folder and configuration file from the ``config/`` would be installed. -The ``data_files`` field should now look like this: - -.. code-block:: Python - - import os - from glob import glob - from setuptools import setup - ... - - data_files=[ - ... - (os.path.join('share', package_name, 'launch'), - glob('launch/*')), - (os.path.join('share', package_name, 'config'), - glob('config/*.yaml')), - (os.path.join('share', package_name, 'rviz'), - glob('config/*.rviz')), - ], - -2 Build and run -^^^^^^^^^^^^^^^ - -To finally see the result of our code, build the package and launch the top-level launch file using the following command: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch launch_tutorial launch_turtlesim_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch launch_tutorial launch_turtlesim_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch launch_tutorial launch_turtlesim_launch.py - -You will now see the two turtlesim simulations started. -There are two turtles in the first one and one in the second one. -In the first simulation, ``turtle2`` is spawned in the bottom-left part of the world. -Its aim is to reach the ``carrot1`` frame which is five meters away on the x-axis relative to the ``turtle1`` frame. - -The ``turtlesim2/turtle1`` in the second is designed to mimic the behavior of the ``turtle2``. - -If you want to control the ``turtle1``, run the teleop node. - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -As a result, you will see a similar picture: - -.. image:: images/turtlesim_worlds.png - -In addition to that, the RViz should have started. -It will show all turtle frames relative to the ``world`` frame, whose origin is at the bottom-left corner. - -.. image:: images/turtlesim_rviz.png - -Summary -------- - -In this tutorial, you learned about various tips and practices of managing large projects using ROS 2 launch files. +.. redirect-from:: + + Tutorials/Launch-Files/Using-ROS2-Launch-for-Large-Projects + Tutorials/Launch/Using-ROS2-Launch-for-Large-Projects + Tutorials/Intermediate/Launch/Using-ROS2-Launch-For-Large-Projects + +.. _UsingROS2LaunchForLargeProjects: + +Managing large projects +======================= + +**Goal:** Learn best practices of managing large projects using ROS 2 launch files. + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 3 + :local: + +Background +---------- + +This tutorial describes some tips for writing launch files for large projects. +The focus is on how to structure launch files so they may be reused as much as possible in different situations. +Additionally, it covers usage examples of different ROS 2 launch tools, like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. + +Prerequisites +------------- + +This tutorial uses the :doc:`turtlesim <../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` and :doc:`turtle_tf2_py <../../ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2>` packages. +This tutorial also assumes you have :doc:`created a new package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` of build type ``ament_python`` called ``launch_tutorial``. + +Introduction +------------ + +Large applications on a robot typically involve several interconnected nodes, each of which can have many parameters. +Simulation of multiple turtles in the turtle simulator can serve as a good example. +The turtle simulation consists of multiple turtle nodes, the world configuration, and the TF broadcaster and listener nodes. +Between all of the nodes, there are a large number of ROS parameters that affect the behavior and appearance of these nodes. +ROS 2 launch files allow us to start all nodes and set corresponding parameters in one place. +By the end of a tutorial, you will build the ``launch_turtlesim_launch`` launch file in the ``launch_tutorial`` package. +This launch file will bring up different nodes responsible for the simulation of two turtlesim simulations, starting TF broadcasters and listener, loading parameters, and launching an RViz configuration. +In this tutorial, we'll go over this launch file and all related features used. + +.. attention:: Launch files can be written in XML, YAML, or Python format. + Throughout this tutorial, launch files are shown in all three formats using tabs. + You can choose whichever format you prefer - they are functionally equivalent. + Wherever you see the file name ``launch_turtlesim_launch`` make sure to use the correct file extension for your launch file type (i.e. ``launch_turtlesim_launch.py`` for Python, ``launch_turtlesim_launch.xml`` for XML, and ``launch_turtlesim_launch.yaml`` for YAML. + +Writing launch files +-------------------- + +1 Top-level organization +^^^^^^^^^^^^^^^^^^^^^^^^ + +One of the aims in the process of writing launch files should be making them as reusable as possible. +This could be done by clustering related nodes and configurations into separate launch files. +Afterwards, a top-level launch file dedicated to a specific configuration could be written. +This would allow moving between identical robots to be done without changing the launch files at all. +Even a change such as moving from a real robot to a simulated one can be done with only a few changes. + +We will now go over the top-level launch file structure that makes this possible. +Firstly, we will create a launch file that will call separate launch files. +To do this, let's create a ``launch_turtlesim_launch`` file in the ``/launch`` folder of our ``launch_tutorial`` package. + +.. attention:: + + Earlier launch system versions may not support ``let`` inside ``include`` statements and require ``arg`` instead. + The syntax is the same: ``name`` and ``value`` attributes remain unchanged (e.g., ````). + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/launch_turtlesim_launch.xml`` file: + + .. literalinclude:: launch/launch_turtlesim_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/launch_turtlesim_launch.yaml`` file: + + .. literalinclude:: launch/launch_turtlesim_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/launch_turtlesim_launch.py`` file: + + .. literalinclude:: launch/launch_turtlesim_launch.py + :language: python + +This launch file includes a set of other launch files. +Each of these included launch files contains nodes, parameters, and possibly, nested includes, which pertain to one part of the system. +To be exact, we launch two turtlesim simulation worlds, TF broadcaster, TF listener, mimic, fixed frame broadcaster, and RViz nodes. + +.. note:: Design Tip: Top-level launch files should be short, consist of includes to other files corresponding to subcomponents of the application, and commonly changed parameters. + +Writing launch files in the following manner makes it easy to swap out one piece of the system, as we'll see later. +However, there are cases when some nodes or launch files have to be launched separately due to performance and usage reasons. + +.. note:: Design tip: Be aware of the tradeoffs when deciding how many top-level launch files your application requires. + +.. _Parameters: + +2 Parameters +^^^^^^^^^^^^ + +2.1 Setting parameters in the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We will begin by writing a launch file that will start our first turtlesim simulation. +First, create a new file called ``turtlesim_world_1_launch``. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_world_1_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_world_1_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.py`` file: + + .. literalinclude:: launch/turtlesim_world_1_launch.py + :language: python + +This launch file starts the ``turtlesim_node`` node, which starts the turtlesim simulation, with simulation configuration parameters that are defined and passed to the nodes. + +.. _LoadingParametersFromYAMLFile: + +2.2 Loading parameters from YAML file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the second launch, we will start a second turtlesim simulation with a different configuration. +Now create a ``turtlesim_world_2_launch`` file. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_world_2_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_world_2_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.py`` file: + + .. literalinclude:: launch/turtlesim_world_2_launch.py + :language: python + +This launch file will launch the same ``turtlesim_node`` with parameter values that are loaded directly from the YAML configuration file. +Defining arguments and parameters in YAML files make it easy to store and load a large number of variables. +It is also worth noting that this YAML file is not another launch file, it is a configuration file for the ``turtlesim_node`` that sets parameters for the node. +In addition, YAML files can be easily exported from the current ``ros2 param`` list. +To learn how to do that, refer to the :doc:`Understand parameters <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. + +Let's now create a configuration file, ``turtlesim.yaml``, in the ``/config`` folder of our package, which will be loaded by our launch file. + +.. code-block:: YAML + + /turtlesim2/sim: + ros__parameters: + background_b: 255 + background_g: 86 + background_r: 150 + +To learn more about using parameters and using YAML files, take a look at the :doc:`Understand parameters <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. + +2.3 Using wildcards in YAML files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There are cases when we want to set the same parameters in more than one node. +These nodes could have different namespaces or names but still have the same parameters. +Defining separate YAML files that explicitly define namespaces and node names is not efficient. +A solution is to use wildcard characters, which act as substitutions for unknown characters in a text value, to apply parameters to several different nodes. + +Now let's create a new ``turtlesim_world_3_launch`` file similar to ``turtlesim_world_2_launch`` to include one more ``turtlesim_node`` node in a new namespace ``turtlesim3``: + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_world_3_launch.xml + :language: xml + :emphasize-lines: 3 + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_world_3_launch.yaml + :language: yaml + :emphasize-lines: 7 + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.py`` file: + + .. literalinclude:: launch/turtlesim_world_3_launch.py + :language: python + :emphasize-lines: 12 + +Loading the same YAML file, however, will not affect the appearance of the third turtlesim world. +The reason is that its parameters are stored under another namespace as shown below: + +.. code-block:: console + + /turtlesim3/sim: + background_b + background_g + background_r + +Therefore, instead of creating a new configuration for the same node that use the same parameters, we can use wildcards syntax. +``/**`` will assign all the parameters in every node, despite differences in node names and namespaces. + +We will now update the ``turtlesim.yaml``, in the ``/config`` folder in the following manner: + +.. code-block:: YAML + + /**: + ros__parameters: + background_b: 255 + background_g: 86 + background_r: 150 + +Now include the ``turtlesim_world_3_launch`` launch description in our main launch file. +Using that configuration file in our launch descriptions will assign ``background_b``, ``background_g``, and ``background_r`` parameters to specified values in ``turtlesim3/sim`` and ``turtlesim2/sim`` nodes. + +3 Namespaces +^^^^^^^^^^^^ + +As you may have noticed, we have defined the namespace for the turtlesim world in the ``turtlesim_world_2_launch`` file. +Unique namespaces allow the system to start two similar nodes without node name or topic name conflicts. + +.. code-block:: Python + + namespace='turtlesim2', + +However, if the launch file contains a large number of nodes, defining namespaces for each of them can become tedious. +To solve that issue, the ``PushROSNamespace`` action can be used to define the global namespace for each launch file description. +Every nested node will inherit that namespace automatically. + +.. attention:: ``PushROSNamespace`` has to be the first action in the list for the following actions to apply the namespace. + +To do that, firstly, we need to remove the ``namespace='turtlesim2'`` line from the ``turtlesim_world_2_launch`` file. +Afterwards, we need to update the ``launch_turtlesim_launch`` to change the include statement to the following: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: xml + + + + + + + .. group-tab:: YAML + + .. code-block:: yaml + + - group: + - push_ros_namespace: + namespace: "turtlesim2" + - include: + file: "$(find-pkg-share launch_tutorial)/launch/turtlesim_world_2_launch.yaml" + + .. group-tab:: Python + + .. code-block:: python + + from launch.actions import GroupAction + from launch_ros.actions import PushROSNamespace + + ... + GroupAction( + actions=[ + PushROSNamespace('turtlesim2'), + IncludeLaunchDescription(PathJoinSubstitution([launch_dir, 'turtlesim_world_2_launch.py'])), + ] + ), + +As a result, each node in the ``turtlesim_world_2_launch`` launch description will have a ``turtlesim2`` namespace. + +4 Reusing nodes +^^^^^^^^^^^^^^^ + +Now create a ``broadcaster_listener_launch`` file. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/broadcaster_listener_launch.xml`` file: + + .. literalinclude:: launch/broadcaster_listener_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/broadcaster_listener_launch.yaml`` file: + + .. literalinclude:: launch/broadcaster_listener_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/broadcaster_listener_launch.py`` file: + + .. literalinclude:: launch/broadcaster_listener_launch.py + :language: python + +In this file, we have declared the ``target_frame`` launch argument with a default value of ``turtle1``. +The default value means that the launch file can receive an argument to forward to its nodes, or in case the argument is not provided, it will pass the default value to its nodes. + +Afterwards, we use the ``turtle_tf2_broadcaster`` node two times using different names and parameters during launch. +This allows us to duplicate the same node without conflicts. + +We also start a ``turtle_tf2_listener`` node and set its ``target_frame`` parameter that we declared and acquired above. + +5 Parameter overrides +^^^^^^^^^^^^^^^^^^^^^ + +Recall that we called the ``broadcaster_listener_launch`` file in our top-level launch file. +In addition to that, we have passed it ``target_frame`` launch argument as shown below: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/launch_turtlesim_launch.xml + :language: xml + :lines: 5-7 + + .. group-tab:: YAML + + .. literalinclude:: launch/launch_turtlesim_launch.yaml + :language: yaml + :lines: 8-12 + + .. group-tab:: Python + + .. literalinclude:: launch/launch_turtlesim_launch.py + :language: python + :lines: 16-19 + +This syntax allows us to change the default goal target frame to ``carrot1``. +If you would like ``turtle2`` to follow ``turtle1`` instead of the ``carrot1``, just remove the line that passes the ``target_frame`` argument. +This will assign ``target_frame`` its default value, which is ``turtle1``. + +6 Remapping +^^^^^^^^^^^ + +Now create a ``mimic_launch`` file. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/mimic_launch.xml`` file: + + .. literalinclude:: launch/mimic_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/mimic_launch.yaml`` file: + + .. literalinclude:: launch/mimic_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/mimic_launch.py`` file: + + .. literalinclude:: launch/mimic_launch.py + :language: python + +This launch file will start the ``mimic`` node, which will give commands to one turtlesim to follow the other. +The node is designed to receive the target pose on the topic ``/input/pose``. +In our case, we want to remap the target pose from ``/turtle2/pose`` topic. +Finally, we remap the ``/output/cmd_vel`` topic to ``/turtlesim2/turtle1/cmd_vel``. +This way ``turtle1`` in our ``turtlesim2`` simulation world will follow ``turtle2`` in our initial turtlesim world. + +7 Config files +^^^^^^^^^^^^^^ + +Let's now create a file called ``turtlesim_rviz_launch``. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_rviz_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_rviz_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.py`` file: + + .. literalinclude:: launch/turtlesim_rviz_launch.py + :language: python + +This launch file will start the RViz with the configuration file defined in the ``turtle_tf2_py`` package. +This RViz configuration will set the world frame, enable TF visualization, and start RViz with a top-down view. + +8 Environment Variables +^^^^^^^^^^^^^^^^^^^^^^^ + +Let's now create the last launch file called ``fixed_broadcaster_launch`` in our package. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.xml`` file: + + .. literalinclude:: launch/fixed_broadcaster_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.yaml`` file: + + .. literalinclude:: launch/fixed_broadcaster_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.py`` file: + + .. literalinclude:: launch/fixed_broadcaster_launch.py + :language: python + +This launch file shows the way environment variables can be called inside the launch files. +Environment variables can be used to define or push namespaces for distinguishing nodes on different computers or robots. + +.. note:: If you are running the launch file where the ``USER`` environment variable is not defined (like in the ROS docker file), then you can replace the environment variable reference above with any other word of your liking. + +Running launch files +-------------------- + +1 Update setup.py +^^^^^^^^^^^^^^^^^ + +Open ``setup.py`` and add the following lines so that the launch files from the ``launch/`` folder and configuration file from the ``config/`` would be installed. +The ``data_files`` field should now look like this: + +.. code-block:: Python + + import os + from glob import glob + from setuptools import setup + ... + + data_files=[ + ... + (os.path.join('share', package_name, 'launch'), + glob('launch/*')), + (os.path.join('share', package_name, 'config'), + glob('config/*.yaml')), + (os.path.join('share', package_name, 'rviz'), + glob('config/*.rviz')), + ], + +2 Build and run +^^^^^^^^^^^^^^^ + +To finally see the result of our code, build the package and launch the top-level launch file using the following command: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch launch_tutorial launch_turtlesim_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch launch_tutorial launch_turtlesim_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch launch_tutorial launch_turtlesim_launch.py + +You will now see the two turtlesim simulations started. +There are two turtles in the first one and one in the second one. +In the first simulation, ``turtle2`` is spawned in the bottom-left part of the world. +Its aim is to reach the ``carrot1`` frame which is five meters away on the x-axis relative to the ``turtle1`` frame. + +The ``turtlesim2/turtle1`` in the second is designed to mimic the behavior of the ``turtle2``. + +If you want to control the ``turtle1``, run the teleop node. + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +As a result, you will see a similar picture: + +.. image:: images/turtlesim_worlds.png + +In addition to that, the RViz should have started. +It will show all turtle frames relative to the ``world`` frame, whose origin is at the bottom-left corner. + +.. image:: images/turtlesim_rviz.png + +Summary +------- + +In this tutorial, you learned about various tips and practices of managing large projects using ROS 2 launch files. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Using-Substitutions.rst b/source/Developer-Tools/Launch/Using-Substitutions.rst index 32cdc2343d8..3999cb4a34c 100644 --- a/source/Developer-Tools/Launch/Using-Substitutions.rst +++ b/source/Developer-Tools/Launch/Using-Substitutions.rst @@ -1,469 +1,470 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Using-Substitutions - Tutorials/Launch/Using-Substitutions - -Using substitutions -=================== - -**Goal:** Learn about substitutions in ROS 2 launch files. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -Launch files are used to start nodes, services and execute processes. -This set of actions may have arguments, which affect their behavior. -Substitutions can be used in arguments to provide more flexibility when describing reusable launch files. -Substitutions are variables that are only evaluated during execution of the launch description and can be used to acquire specific information like a launch configuration, an environment variable, or to evaluate an arbitrary Python expression. - -This tutorial shows usage examples of substitutions in ROS 2 launch files. - -Prerequisites -------------- - -This tutorial uses the :doc:`turtlesim <../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>` package. -This tutorial also assumes you are familiar with :doc:`creating packages <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>`. - -Using substitutions -------------------- - -1 Create and setup the package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -First, create a new package with the name ``launch_tutorial``: - -.. tabs:: - - .. group-tab:: Python package - - Create a new package of build_type ``ament_python``: - - .. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 launch_tutorial - - .. group-tab:: C++ package - - Create a new package of build_type ``ament_cmake``: - - .. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 launch_tutorial - -Inside of that package, create a directory called ``launch``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir launch_tutorial/launch - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir launch_tutorial/launch - - .. group-tab:: Windows - - .. code-block:: console - - $ md launch_tutorial/launch - -Finally, make sure to install the launch files: - -.. tabs:: - - .. group-tab:: Python package - - Add in following changes to the ``setup.py`` of the package: - - .. code-block:: python - - import os - from glob import glob - from setuptools import find_packages, setup - - package_name = 'launch_tutorial' - - setup( - # Other parameters ... - data_files=[ - # ... Other data files - # Include all launch files. - (os.path.join('share', package_name, 'launch'), glob('launch/*')) - ] - ) - - .. group-tab:: C++ package - - Append following code to the ``CMakeLists.txt`` just before ``ament_package()``: - - .. code-block:: cmake - - install(DIRECTORY - launch - DESTINATION share/${PROJECT_NAME}/ - ) - - - -2 Parent launch file -^^^^^^^^^^^^^^^^^^^^ - -Let's create a launch file that will call and pass arguments to another launch file. -This launch file can either be in YAML, XML, or in Python. - -To do this, create following file in the ``launch`` folder of the ``launch_tutorial`` package. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/example_main_launch.xml`` file: - - .. literalinclude:: launch/example_main_launch.xml - :language: xml - - The ``$(find-pkg-share launch_tutorial)`` substitution is used to find the path to the ``launch_tutorial`` package. - The path substitution is then joined with the ``example_substitutions_launch.xml`` file name. - - .. literalinclude:: launch/example_main_launch.xml - :language: xml - :lines: 4 - - The ``background_r`` variable with ``turtlesim_ns`` and ``use_provided_red`` arguments is passed to the ``include`` action. - The ``$(var background_r)`` substitution is used to define the ``new_background_r`` argument with the value of the ``background_r`` variable. - - .. literalinclude:: launch/example_main_launch.xml - :language: xml - :lines: 5-7 - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/example_main_launch.yaml`` file: - - .. literalinclude:: launch/example_main_launch.yaml - :language: yaml - - The ``$(find-pkg-share launch_tutorial)`` substitution is used to find the path to the ``launch_tutorial`` package. - The path substitution is then joined with the ``example_substitutions_launch.yaml`` file name. - - .. literalinclude:: launch/example_main_launch.yaml - :language: yaml - :lines: 8 - - The ``background_r`` variable with ``turtlesim_ns`` and ``use_provided_red`` arguments is passed to the ``include`` action. - The ``$(var background_r)`` substitution is used to define the ``new_background_r`` argument with the value of the ``background_r`` variable. - - .. literalinclude:: launch/example_main_launch.yaml - :language: yaml - :lines: 9-15 - - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/example_main_launch.py`` file: - - .. literalinclude:: launch/example_main_launch.py - :language: python - - The ``FindPackageShare`` substitution is used to find the path to the ``launch_tutorial`` package. - The ``PathJoinSubstitution`` substitution is then used to join the path to that package path with the ``example_substitutions_launch.py`` file name. - - .. literalinclude:: launch/example_main_launch.py - :language: python - :lines: 14-18 - - .. tip:: - - A list of substitutions or strings gets concatenated into a single string. - This generally applies to anything that supports substitutions. - - For example, with ``PathJoinSubstitution``, if the file name prefix depended on a launch argument named ``file``, a list of substitutions and strings could be used to create the file name: - - .. code-block:: python - - # Make sure to import LaunchConfiguration: - # from launch.substitutions import LaunchConfiguration - - PathJoinSubstitution([ - FindPackageShare('launch_tutorial'), - 'launch', - [LaunchConfiguration('file', default='example_substitutions'), '_launch', '.py'] - ]) - - In this case, by default, the last path component provided to ``PathJoinSubstitution`` would resolve to ``example_substitutions_launch.py`` and would then be joined with the other path components. - - The ``launch_arguments`` dictionary with ``turtlesim_ns`` and ``use_provided_red`` arguments is passed to the ``IncludeLaunchDescription`` action. - - .. literalinclude:: launch/example_main_launch.py - :language: python - :lines: 19-23 - - -3 Substitutions example launch file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now create the substitution launch file in the same folder: - -.. tabs:: - - .. group-tab:: XML - - Create the file ``launch/example_substitutions_launch.xml`` and insert the following code: - - .. literalinclude:: launch/example_substitutions_launch.xml - :language: xml - - The ``turtlesim_ns``, ``use_provided_red``, and ``new_background_r`` launch configurations are defined. - They are used to store values of launch arguments in the above variables and to pass them to required actions. - The launch configuration arguments can later be used with the ``$(var )`` substitution to acquire the value of the launch argument in any part of the launch description. - - The ``arg`` tag is used to define the launch argument that can be passed from the above launch file or from the console. - - .. literalinclude:: launch/example_substitutions_launch.xml - :language: xml - :lines: 3-5 - - The ``turtlesim_node`` node with the ``namespace`` set to the ``turtlesim_ns`` launch configuration value using the ``$(var )`` substitution is defined. - - .. literalinclude:: launch/example_substitutions_launch.xml - :language: xml - :lines: 7 - - Afterwards, an ``executable`` action is defined with the corresponding ``cmd`` tag. - This command makes a call to the spawn service of the turtlesim node. - - Additionally, the ``$(var )`` substitution is used to get the value of the ``turtlesim_ns`` launch argument to construct a command string. - - .. literalinclude:: launch/example_substitutions_launch.xml - :language: xml - :lines: 8 - - The same approach is used for the ``ros2 param`` ``executable`` actions that change the turtlesim background's red color parameter. - The difference is that the second action inside of the timer is only executed if the provided ``new_background_r`` argument equals ``200`` and the ``use_provided_red`` launch argument is set to ``True``. - The evaluation of the ``if`` predicate is done using the ``$(eval )`` substitution. - - .. literalinclude:: launch/example_substitutions_launch.xml - :language: xml - :lines: 9-13 - - .. group-tab:: YAML - - Create the file ``launch/example_substitutions_launch.yaml`` and insert the following code: - - .. literalinclude:: launch/example_substitutions_launch.yaml - :language: yaml - - The ``turtlesim_ns``, ``use_provided_red``, and ``new_background_r`` launch configurations are defined. - They are used to store values of launch arguments in the above variables and to pass them to required actions. - The launch configuration arguments can later be used with the ``$(var )`` substitution to acquire the value of the launch argument in any part of the launch description. - - The ``arg`` tag is used to define the launch argument that can be passed from the above launch file or from the console. - - .. literalinclude:: launch/example_substitutions_launch.yaml - :language: yaml - :lines: 4-12 - - The ``turtlesim_node`` node with the ``namespace`` set to the ``turtlesim_ns`` launch configuration value using the ``$(var )`` substitution is defined. - - .. literalinclude:: launch/example_substitutions_launch.yaml - :language: yaml - :lines: 14-18 - - Afterwards, an ``executable`` action is defined with the corresponding ``cmd`` tag. - This command makes a call to the spawn service of the turtlesim node. - - Additionally, the ``$(var )`` substitution is used to get the value of the ``turtlesim_ns`` launch argument to construct a command string. - - .. literalinclude:: launch/example_substitutions_launch.yaml - :language: yaml - :lines: 21-22 - - The same approach is used for the ``ros2 param`` ``executable`` actions that change the turtlesim background's red color parameter. - The difference is that the second action inside of the timer is only executed if the provided ``new_background_r`` argument equals ``200`` and the ``use_provided_red`` launch argument is set to ``True``. - The evaluation of the ``if`` predicate is done using the ``$(eval )`` substitution. - - .. literalinclude:: launch/example_substitutions_launch.yaml - :language: yaml - :lines: 21-28 - - .. group-tab:: Python - - Create the file ``launch/example_substitutions_launch.py`` and insert the following code: - - .. literalinclude:: launch/example_substitutions_launch.py - :language: python - - The ``turtlesim_ns``, ``use_provided_red``, and ``new_background_r`` launch configurations are defined. - They are used to represent values of launch arguments in the above variables and to pass them to required actions. - These ``LaunchConfiguration`` substitutions allow us to acquire the value of the launch argument in any part of the launch description. - - ``DeclareLaunchArgument`` is used to define the launch argument that can be passed from the above launch file or from the console. - - .. literalinclude:: launch/example_substitutions_launch.py - :language: python - :lines: 14-25 - - The ``turtlesim_node`` node with the ``namespace`` set to ``turtlesim_ns`` ``LaunchConfiguration`` substitution is defined. - - .. literalinclude:: launch/example_substitutions_launch.py - :language: python - :lines: 26-31 - - The next action, ``ExecuteProcess``, is defined with the corresponding ``cmd`` argument to call the spawn service of the turtlesim node. - - Additionally, the ``LaunchConfiguration`` substitution is used to provide the value of the ``turtlesim_ns`` launch argument in the command string. - - .. literalinclude:: launch/example_substitutions_launch.py - :language: python - :lines: 32-41 - - The same approach is used for the ``change_background_r`` and ``change_background_r_conditioned`` actions that change the turtlesim background's red color parameter. - The difference is that the next action is only executed if the provided ``new_background_r`` argument equals ``200`` and the ``use_provided_red`` launch argument is set to ``True``. - The evaluation inside the ``IfCondition`` is done using the ``PythonExpression`` substitution. - - .. literalinclude:: launch/example_substitutions_launch.py - :language: python - :lines: 51-72 - -4 Build the package -^^^^^^^^^^^^^^^^^^^ - -Go to the root of the workspace, and build the package: - -.. code-block:: console - - $ colcon build - -Also remember to source the workspace after building. - -Launching example ------------------ - -Now you can launch using the ``ros2 launch`` command. - -.. tabs:: - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch launch_tutorial example_main_launch.yaml - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch launch_tutorial example_main_launch.xml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch launch_tutorial example_main_launch.py - -This will do the following: - -#. Start a turtlesim node with a blue background -#. Spawn the second turtle -#. Change the color to purple -#. Change the color to pink after two seconds if the provided ``background_r`` argument is ``200`` and ``use_provided_red`` argument is ``True`` - -Modifying launch arguments --------------------------- - -.. tabs:: - - .. group-tab:: YAML - - If you want to change the provided launch arguments, you can either update the ``background_r`` variable in the ``example_main_launch.yaml`` or launch the ``example_substitutions_launch.yaml`` with preferred arguments. - To see arguments that may be given to the launch file, run the following command: - - .. code-block:: console - - $ ros2 launch launch_tutorial example_substitutions_launch.yaml --show-args - - .. group-tab:: XML - - If you want to change the provided launch arguments, you can either update the ``background_r`` variable in the ``example_main_launch.xml`` or launch the ``example_substitutions_launch.xml`` with preferred arguments. - To see arguments that may be given to the launch file, run the following command: - - .. code-block:: console - - $ ros2 launch launch_tutorial example_substitutions_launch.xml --show-args - - .. group-tab:: Python - - If you want to change the provided launch arguments, you can either update them in ``launch_arguments`` dictionary in the ``example_main_launch.py`` or launch the ``example_substitutions_launch.py`` with preferred arguments. - To see arguments that may be given to the launch file, run the following command: - - .. code-block:: console - - $ ros2 launch launch_tutorial example_substitutions_launch.py --show-args - -This will show the arguments that may be given to the launch file and their default values. - -.. code-block:: console - - Arguments (pass arguments as ':='): - - 'turtlesim_ns': - no description given - (default: 'turtlesim1') - - 'use_provided_red': - no description given - (default: 'False') - - 'new_background_r': - no description given - (default: '200') - -Now you can pass the desired arguments to the launch file as follows: - -.. tabs:: - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch launch_tutorial example_substitutions_launch.yaml turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch launch_tutorial example_substitutions_launch.xml turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch launch_tutorial example_substitutions_launch.py turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 - -Documentation -------------- - -`The launch documentation `_ provides detailed information about available substitutions. - -Summary -------- - -In this tutorial, you learned about using substitutions in launch files. -You learned about their possibilities and capabilities to create reusable launch files. - -You can now learn more about :doc:`using event handlers in launch files <./Using-Event-Handlers>` which are used to define a complex set of rules which can be used to dynamically modify the launch file. +.. redirect-from:: + + Tutorials/Launch-Files/Using-Substitutions + Tutorials/Launch/Using-Substitutions + Tutorials/Intermediate/Launch/Using-Substitutions + +Using substitutions +=================== + +**Goal:** Learn about substitutions in ROS 2 launch files. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +Launch files are used to start nodes, services and execute processes. +This set of actions may have arguments, which affect their behavior. +Substitutions can be used in arguments to provide more flexibility when describing reusable launch files. +Substitutions are variables that are only evaluated during execution of the launch description and can be used to acquire specific information like a launch configuration, an environment variable, or to evaluate an arbitrary Python expression. + +This tutorial shows usage examples of substitutions in ROS 2 launch files. + +Prerequisites +------------- + +This tutorial uses the :doc:`turtlesim <../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` package. +This tutorial also assumes you are familiar with :doc:`creating packages <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../Get-Started/Configuring-ROS2-Environment>`. + +Using substitutions +------------------- + +1 Create and setup the package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +First, create a new package with the name ``launch_tutorial``: + +.. tabs:: + + .. group-tab:: Python package + + Create a new package of build_type ``ament_python``: + + .. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 launch_tutorial + + .. group-tab:: C++ package + + Create a new package of build_type ``ament_cmake``: + + .. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 launch_tutorial + +Inside of that package, create a directory called ``launch``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir launch_tutorial/launch + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir launch_tutorial/launch + + .. group-tab:: Windows + + .. code-block:: console + + $ md launch_tutorial/launch + +Finally, make sure to install the launch files: + +.. tabs:: + + .. group-tab:: Python package + + Add in following changes to the ``setup.py`` of the package: + + .. code-block:: python + + import os + from glob import glob + from setuptools import find_packages, setup + + package_name = 'launch_tutorial' + + setup( + # Other parameters ... + data_files=[ + # ... Other data files + # Include all launch files. + (os.path.join('share', package_name, 'launch'), glob('launch/*')) + ] + ) + + .. group-tab:: C++ package + + Append following code to the ``CMakeLists.txt`` just before ``ament_package()``: + + .. code-block:: cmake + + install(DIRECTORY + launch + DESTINATION share/${PROJECT_NAME}/ + ) + + + +2 Parent launch file +^^^^^^^^^^^^^^^^^^^^ + +Let's create a launch file that will call and pass arguments to another launch file. +This launch file can either be in YAML, XML, or in Python. + +To do this, create following file in the ``launch`` folder of the ``launch_tutorial`` package. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/example_main_launch.xml`` file: + + .. literalinclude:: launch/example_main_launch.xml + :language: xml + + The ``$(find-pkg-share launch_tutorial)`` substitution is used to find the path to the ``launch_tutorial`` package. + The path substitution is then joined with the ``example_substitutions_launch.xml`` file name. + + .. literalinclude:: launch/example_main_launch.xml + :language: xml + :lines: 4 + + The ``background_r`` variable with ``turtlesim_ns`` and ``use_provided_red`` arguments is passed to the ``include`` action. + The ``$(var background_r)`` substitution is used to define the ``new_background_r`` argument with the value of the ``background_r`` variable. + + .. literalinclude:: launch/example_main_launch.xml + :language: xml + :lines: 5-7 + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/example_main_launch.yaml`` file: + + .. literalinclude:: launch/example_main_launch.yaml + :language: yaml + + The ``$(find-pkg-share launch_tutorial)`` substitution is used to find the path to the ``launch_tutorial`` package. + The path substitution is then joined with the ``example_substitutions_launch.yaml`` file name. + + .. literalinclude:: launch/example_main_launch.yaml + :language: yaml + :lines: 8 + + The ``background_r`` variable with ``turtlesim_ns`` and ``use_provided_red`` arguments is passed to the ``include`` action. + The ``$(var background_r)`` substitution is used to define the ``new_background_r`` argument with the value of the ``background_r`` variable. + + .. literalinclude:: launch/example_main_launch.yaml + :language: yaml + :lines: 9-15 + + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/example_main_launch.py`` file: + + .. literalinclude:: launch/example_main_launch.py + :language: python + + The ``FindPackageShare`` substitution is used to find the path to the ``launch_tutorial`` package. + The ``PathJoinSubstitution`` substitution is then used to join the path to that package path with the ``example_substitutions_launch.py`` file name. + + .. literalinclude:: launch/example_main_launch.py + :language: python + :lines: 14-18 + + .. tip:: + + A list of substitutions or strings gets concatenated into a single string. + This generally applies to anything that supports substitutions. + + For example, with ``PathJoinSubstitution``, if the file name prefix depended on a launch argument named ``file``, a list of substitutions and strings could be used to create the file name: + + .. code-block:: python + + # Make sure to import LaunchConfiguration: + # from launch.substitutions import LaunchConfiguration + + PathJoinSubstitution([ + FindPackageShare('launch_tutorial'), + 'launch', + [LaunchConfiguration('file', default='example_substitutions'), '_launch', '.py'] + ]) + + In this case, by default, the last path component provided to ``PathJoinSubstitution`` would resolve to ``example_substitutions_launch.py`` and would then be joined with the other path components. + + The ``launch_arguments`` dictionary with ``turtlesim_ns`` and ``use_provided_red`` arguments is passed to the ``IncludeLaunchDescription`` action. + + .. literalinclude:: launch/example_main_launch.py + :language: python + :lines: 19-23 + + +3 Substitutions example launch file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now create the substitution launch file in the same folder: + +.. tabs:: + + .. group-tab:: XML + + Create the file ``launch/example_substitutions_launch.xml`` and insert the following code: + + .. literalinclude:: launch/example_substitutions_launch.xml + :language: xml + + The ``turtlesim_ns``, ``use_provided_red``, and ``new_background_r`` launch configurations are defined. + They are used to store values of launch arguments in the above variables and to pass them to required actions. + The launch configuration arguments can later be used with the ``$(var )`` substitution to acquire the value of the launch argument in any part of the launch description. + + The ``arg`` tag is used to define the launch argument that can be passed from the above launch file or from the console. + + .. literalinclude:: launch/example_substitutions_launch.xml + :language: xml + :lines: 3-5 + + The ``turtlesim_node`` node with the ``namespace`` set to the ``turtlesim_ns`` launch configuration value using the ``$(var )`` substitution is defined. + + .. literalinclude:: launch/example_substitutions_launch.xml + :language: xml + :lines: 7 + + Afterwards, an ``executable`` action is defined with the corresponding ``cmd`` tag. + This command makes a call to the spawn service of the turtlesim node. + + Additionally, the ``$(var )`` substitution is used to get the value of the ``turtlesim_ns`` launch argument to construct a command string. + + .. literalinclude:: launch/example_substitutions_launch.xml + :language: xml + :lines: 8 + + The same approach is used for the ``ros2 param`` ``executable`` actions that change the turtlesim background's red color parameter. + The difference is that the second action inside of the timer is only executed if the provided ``new_background_r`` argument equals ``200`` and the ``use_provided_red`` launch argument is set to ``True``. + The evaluation of the ``if`` predicate is done using the ``$(eval )`` substitution. + + .. literalinclude:: launch/example_substitutions_launch.xml + :language: xml + :lines: 9-13 + + .. group-tab:: YAML + + Create the file ``launch/example_substitutions_launch.yaml`` and insert the following code: + + .. literalinclude:: launch/example_substitutions_launch.yaml + :language: yaml + + The ``turtlesim_ns``, ``use_provided_red``, and ``new_background_r`` launch configurations are defined. + They are used to store values of launch arguments in the above variables and to pass them to required actions. + The launch configuration arguments can later be used with the ``$(var )`` substitution to acquire the value of the launch argument in any part of the launch description. + + The ``arg`` tag is used to define the launch argument that can be passed from the above launch file or from the console. + + .. literalinclude:: launch/example_substitutions_launch.yaml + :language: yaml + :lines: 4-12 + + The ``turtlesim_node`` node with the ``namespace`` set to the ``turtlesim_ns`` launch configuration value using the ``$(var )`` substitution is defined. + + .. literalinclude:: launch/example_substitutions_launch.yaml + :language: yaml + :lines: 14-18 + + Afterwards, an ``executable`` action is defined with the corresponding ``cmd`` tag. + This command makes a call to the spawn service of the turtlesim node. + + Additionally, the ``$(var )`` substitution is used to get the value of the ``turtlesim_ns`` launch argument to construct a command string. + + .. literalinclude:: launch/example_substitutions_launch.yaml + :language: yaml + :lines: 21-22 + + The same approach is used for the ``ros2 param`` ``executable`` actions that change the turtlesim background's red color parameter. + The difference is that the second action inside of the timer is only executed if the provided ``new_background_r`` argument equals ``200`` and the ``use_provided_red`` launch argument is set to ``True``. + The evaluation of the ``if`` predicate is done using the ``$(eval )`` substitution. + + .. literalinclude:: launch/example_substitutions_launch.yaml + :language: yaml + :lines: 21-28 + + .. group-tab:: Python + + Create the file ``launch/example_substitutions_launch.py`` and insert the following code: + + .. literalinclude:: launch/example_substitutions_launch.py + :language: python + + The ``turtlesim_ns``, ``use_provided_red``, and ``new_background_r`` launch configurations are defined. + They are used to represent values of launch arguments in the above variables and to pass them to required actions. + These ``LaunchConfiguration`` substitutions allow us to acquire the value of the launch argument in any part of the launch description. + + ``DeclareLaunchArgument`` is used to define the launch argument that can be passed from the above launch file or from the console. + + .. literalinclude:: launch/example_substitutions_launch.py + :language: python + :lines: 14-25 + + The ``turtlesim_node`` node with the ``namespace`` set to ``turtlesim_ns`` ``LaunchConfiguration`` substitution is defined. + + .. literalinclude:: launch/example_substitutions_launch.py + :language: python + :lines: 26-31 + + The next action, ``ExecuteProcess``, is defined with the corresponding ``cmd`` argument to call the spawn service of the turtlesim node. + + Additionally, the ``LaunchConfiguration`` substitution is used to provide the value of the ``turtlesim_ns`` launch argument in the command string. + + .. literalinclude:: launch/example_substitutions_launch.py + :language: python + :lines: 32-41 + + The same approach is used for the ``change_background_r`` and ``change_background_r_conditioned`` actions that change the turtlesim background's red color parameter. + The difference is that the next action is only executed if the provided ``new_background_r`` argument equals ``200`` and the ``use_provided_red`` launch argument is set to ``True``. + The evaluation inside the ``IfCondition`` is done using the ``PythonExpression`` substitution. + + .. literalinclude:: launch/example_substitutions_launch.py + :language: python + :lines: 51-72 + +4 Build the package +^^^^^^^^^^^^^^^^^^^ + +Go to the root of the workspace, and build the package: + +.. code-block:: console + + $ colcon build + +Also remember to source the workspace after building. + +Launching example +----------------- + +Now you can launch using the ``ros2 launch`` command. + +.. tabs:: + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch launch_tutorial example_main_launch.yaml + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch launch_tutorial example_main_launch.xml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch launch_tutorial example_main_launch.py + +This will do the following: + +#. Start a turtlesim node with a blue background +#. Spawn the second turtle +#. Change the color to purple +#. Change the color to pink after two seconds if the provided ``background_r`` argument is ``200`` and ``use_provided_red`` argument is ``True`` + +Modifying launch arguments +-------------------------- + +.. tabs:: + + .. group-tab:: YAML + + If you want to change the provided launch arguments, you can either update the ``background_r`` variable in the ``example_main_launch.yaml`` or launch the ``example_substitutions_launch.yaml`` with preferred arguments. + To see arguments that may be given to the launch file, run the following command: + + .. code-block:: console + + $ ros2 launch launch_tutorial example_substitutions_launch.yaml --show-args + + .. group-tab:: XML + + If you want to change the provided launch arguments, you can either update the ``background_r`` variable in the ``example_main_launch.xml`` or launch the ``example_substitutions_launch.xml`` with preferred arguments. + To see arguments that may be given to the launch file, run the following command: + + .. code-block:: console + + $ ros2 launch launch_tutorial example_substitutions_launch.xml --show-args + + .. group-tab:: Python + + If you want to change the provided launch arguments, you can either update them in ``launch_arguments`` dictionary in the ``example_main_launch.py`` or launch the ``example_substitutions_launch.py`` with preferred arguments. + To see arguments that may be given to the launch file, run the following command: + + .. code-block:: console + + $ ros2 launch launch_tutorial example_substitutions_launch.py --show-args + +This will show the arguments that may be given to the launch file and their default values. + +.. code-block:: console + + Arguments (pass arguments as ':='): + + 'turtlesim_ns': + no description given + (default: 'turtlesim1') + + 'use_provided_red': + no description given + (default: 'False') + + 'new_background_r': + no description given + (default: '200') + +Now you can pass the desired arguments to the launch file as follows: + +.. tabs:: + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch launch_tutorial example_substitutions_launch.yaml turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch launch_tutorial example_substitutions_launch.xml turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch launch_tutorial example_substitutions_launch.py turtlesim_ns:='turtlesim3' use_provided_red:='True' new_background_r:=200 + +Documentation +------------- + +`The launch documentation `_ provides detailed information about available substitutions. + +Summary +------- + +In this tutorial, you learned about using substitutions in launch files. +You learned about their possibilities and capabilities to create reusable launch files. + +You can now learn more about :doc:`using event handlers in launch files ` which are used to define a complex set of rules which can be used to dynamically modify the launch file. \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst b/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst index 100ab0c53d8..586281a2cde 100644 --- a/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst +++ b/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst @@ -1,111 +1,112 @@ -.. redirect-from:: - - Guides/Overriding-QoS-Policies-For-Recording-And-Playback - Tutorials/Ros2bag/Overriding-QoS-Policies-For-Recording-And-Playback - -.. _ROS2Bag-QoS-Override: - -rosbag2: Overriding QoS Policies -================================ - -**Goal:** Override Ros2Bag QoS profile settings for recording and playback. - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- - -With the introduction of DDS in ROS 2, Quality of Service (QoS) compatibility for publisher/subscriber nodes needs to be considered when recording and playing back data. -More detail on how QoS works can be found :doc:`here <../Concepts/Intermediate/About-Quality-of-Service-Settings>`. -For the purposes of this guide, it is sufficient to know that only the reliability and durability policies affect whether publishers/subscribers are compatible and can receive data from one other. - -Ros2Bag adapts its requested/offered QoS profile when recording/playing data from a topic to prevent dropped messages. -During playback, Ros2bag also attempts to preserve the policy originally offered by the topic. -Certain situations may require specifying explicit QoS profile settings so Ros2Bag can record/playback topics. -These QoS profile overrides can be specified via the CLI using the ``--qos-profile-overrides-path`` flag. - -Using QoS Overrides -------------------- - -The YAML schema for the profile overrides is a dictionary of topic names with key/value pairs for each QoS policy: - -.. code-block:: yaml - - topic_name: str - qos_policy_name: str - ... - qos_duration: object - sec: int - nsec: int - -If a policy value is not specified, the value will fallback to the default used by Ros2Bag. -If you specify a Duration based policy such as ``deadline`` or ``lifespan``, you will need to specify both seconds and nanoseconds. -Policy values are determined by the policy's short keys which can be found using ``ros2topic`` verbs such as ``ros2 topic pub --help``. -All values are replicated below for reference. - -.. code-block:: yaml - - history: [keep_all, keep_last] - depth: int - reliability: [system_default, reliable, best_effort, unknown] - durability: [system_default, transient_local, volatile, unknown] - deadline: - sec: int - nsec: int - lifespan: - sec: int - nsec: int - liveliness: [system_default, automatic, manual_by_topic, unknown] - liveliness_lease_duration: - sec: int - nsec: int - avoid_ros_namespace_conventions: [true, false] - -Example -------- - -Consider a topic ``/talker`` offering a ``transient_local`` Durability policy. -ROS 2 publishers by default request ``volatile`` Durability. - -.. code-block:: console - - $ ros2 topic pub -r 0.1 --qos-durability transient_local /talker std_msgs/String "data: Hello World" - -In order for Ros2Bag to record the data, we would want to override the recording policy for that specific topic like so: - -.. code-block:: yaml - - # durability_override.yaml - /talker: - durability: transient_local - history: keep_all - -And call it from the CLI: - -.. code-block:: console - - $ ros2 bag record -a -o my_bag --qos-profile-overrides-path durability_override.yaml - -If we want to playback the bag file but with a different Reliability policy, we can specify one as such; - -.. code-block:: yaml - - # reliability_override.yaml - /talker: - reliability: best_effort - history: keep_all - -And call it from the CLI: - -.. code-block:: console - - $ ros2 bag play --qos-profile-overrides-path reliability_override.yaml my_bag - -We can see the results with ``ros2 topic`` - -.. code-block:: console - - $ ros2 topic echo --qos-reliability best_effort /talker std_msgs/String +.. redirect-from:: + + Guides/Overriding-QoS-Policies-For-Recording-And-Playback + Tutorials/Ros2bag/Overriding-QoS-Policies-For-Recording-And-Playback + How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback + +.. _ROS2Bag-QoS-Override: + +rosbag2: Overriding QoS Policies +================================ + +**Goal:** Override Ros2Bag QoS profile settings for recording and playback. + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- + +With the introduction of DDS in ROS 2, Quality of Service (QoS) compatibility for publisher/subscriber nodes needs to be considered when recording and playing back data. +More detail on how QoS works can be found :doc:`here <../../ROS-Framework/topics/About-Quality-of-Service-Settings>`. +For the purposes of this guide, it is sufficient to know that only the reliability and durability policies affect whether publishers/subscribers are compatible and can receive data from one other. + +Ros2Bag adapts its requested/offered QoS profile when recording/playing data from a topic to prevent dropped messages. +During playback, Ros2bag also attempts to preserve the policy originally offered by the topic. +Certain situations may require specifying explicit QoS profile settings so Ros2Bag can record/playback topics. +These QoS profile overrides can be specified via the CLI using the ``--qos-profile-overrides-path`` flag. + +Using QoS Overrides +------------------- + +The YAML schema for the profile overrides is a dictionary of topic names with key/value pairs for each QoS policy: + +.. code-block:: yaml + + topic_name: str + qos_policy_name: str + ... + qos_duration: object + sec: int + nsec: int + +If a policy value is not specified, the value will fallback to the default used by Ros2Bag. +If you specify a Duration based policy such as ``deadline`` or ``lifespan``, you will need to specify both seconds and nanoseconds. +Policy values are determined by the policy's short keys which can be found using ``ros2topic`` verbs such as ``ros2 topic pub --help``. +All values are replicated below for reference. + +.. code-block:: yaml + + history: [keep_all, keep_last] + depth: int + reliability: [system_default, reliable, best_effort, unknown] + durability: [system_default, transient_local, volatile, unknown] + deadline: + sec: int + nsec: int + lifespan: + sec: int + nsec: int + liveliness: [system_default, automatic, manual_by_topic, unknown] + liveliness_lease_duration: + sec: int + nsec: int + avoid_ros_namespace_conventions: [true, false] + +Example +------- + +Consider a topic ``/talker`` offering a ``transient_local`` Durability policy. +ROS 2 publishers by default request ``volatile`` Durability. + +.. code-block:: console + + $ ros2 topic pub -r 0.1 --qos-durability transient_local /talker std_msgs/String "data: Hello World" + +In order for Ros2Bag to record the data, we would want to override the recording policy for that specific topic like so: + +.. code-block:: yaml + + # durability_override.yaml + /talker: + durability: transient_local + history: keep_all + +And call it from the CLI: + +.. code-block:: console + + $ ros2 bag record -a -o my_bag --qos-profile-overrides-path durability_override.yaml + +If we want to playback the bag file but with a different Reliability policy, we can specify one as such; + +.. code-block:: yaml + + # reliability_override.yaml + /talker: + reliability: best_effort + history: keep_all + +And call it from the CLI: + +.. code-block:: console + + $ ros2 bag play --qos-profile-overrides-path reliability_override.yaml my_bag + +We can see the results with ``ros2 topic`` + +.. code-block:: console + + $ ros2 topic echo --qos-reliability best_effort /talker std_msgs/String \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Testing.rst b/source/Developer-Tools/Testing/Testing.rst index 6615811ece9..96a710c58a7 100644 --- a/source/Developer-Tools/Testing/Testing.rst +++ b/source/Developer-Tools/Testing/Testing.rst @@ -1,154 +1,155 @@ -.. redirect-from:: - - Installation/Prerelease-Testing - -Testing with pre-release binaries -================================= - -Many ROS packages are provided as pre-built binaries. -Usually, you will get the released version of binaries when following :doc:`../Installation`. -There are also pre-released versions of binaries that are useful for testing before making an official release. -This article describes several options if you would like to try out pre-released versions of ROS binaries. - -When packages are released into a ROS distribution (using bloom), the buildfarm builds them into deb packages which are stored temporarily in the **building** apt repository. -As dependent packages are rebuilt, an automatic process periodically synchronizes the packages in **building** to a secondary repository called **ros-testing**. -**ros-testing** is intended as a soaking area where developers and bleeding-edge users may give the packages extra testing, before they are manually synced into the public ros repository from which users typically install packages. - -Approximately every two weeks, the rosdistro's release manager manually synchronizes the contents of **ros-testing** into the **main** ROS repository. - -deb testing repository ----------------------- - -For Debian-based operating systems, you can install binary packages from the **ros-testing** repository. - -1. Make sure you have a working ROS 2 installation from deb packages (see :doc:`../Installation`). - -2. Install the ros2-testing-apt-source package. - This will automatically uninstall the ros2-apt-source package since only one repository may be enabled at a time. - - .. code-block:: console - - $ sudo apt install -y ros2-testing-apt-source - -3. Update the apt index: - - .. code-block:: console - - $ sudo apt update - -4. You can now install individual packages from the testing repository, for example: - - .. code-block:: console - - $ sudo apt install ros-{DISTRO}-my-just-released-package - -5. Alternatively, you can move your entire ROS 2 installation to the testing repository: - - .. code-block:: console - - $ sudo apt dist-upgrade - -6. Once you are finished testing, you can switch back to the normal repository by re-installing the ros-apt-source package: - - .. code-block:: console - - $ sudo apt install -y ros2-apt-source - - and doing an update and upgrade: - - .. code-block:: console - - $ sudo apt update - $ sudo apt dist-upgrade - - -RHEL testing repository ------------------------ - -For RHEL you can install binary packages from the **ros-testing** repository, by enabling the testing repository on the source configuration: - -1. Make sure you have a working ROS 2 installation for rpm packages (see the :doc:`RHEL installation instructions `). - -2. Enable testing and disable main repository: - - .. code-block:: console - - $ sudo dnf config-manager --set-enabled ros2-testing - $ sudo dnf config-manager --set-disabled ros2 - -3. Update the dnf index: - - .. code-block:: console - - $ sudo dnf update - -4. You can now install individual packages from the testing repository, for example: - - .. code-block:: console - - $ sudo dnf install ros-{DISTRO}-my-just-released-package - -5. Once you are finished testing, you can switch back to the normal repository by re-enabling the main repository: - - .. code-block:: console - - $ sudo dnf config-manager --set-disabled ros2-testing - $ sudo dnf config-manager --set-enabled ros2 - - and doing an update and upgrade: - - .. code-block:: console - - $ sudo dnf update - $ sudo dnf system-upgrade - -.. _Prerelease_binaries: - -Binary archives ---------------- - -For core packages, we run nightly packaging jobs for Ubuntu Linux, RHEL, and Windows. -These packaging jobs produce archives with pre-built binaries that can be downloaded and extracted to your filesystem. - -1. Make sure you have all dependencies installed according to the :doc:`latest development setup ` for your platform. - -2. Go to https://ci.ros2.org/view/packaging/ and select a packaging job from the list corresponding to your platform. - -3. Under the heading "Last Successful Artifacts" you should see a download link (e.g. for Windows, ``ros2-package-windows-AMD64.zip``). - -4. Download and extract the archive to your file system. - -5. To use the binary archive installation, source the ``setup.*`` file that can be found in the root of the archive. - - .. tabs:: - - .. group-tab:: Ubuntu Linux and RHEL - - .. code-block:: console - - $ source path/to/extracted/archive/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call path\to\extracted\archive\setup.bat - -Docker ------- - -For Ubuntu Linux, there is also a nightly Docker image based on the nightly binary archive. - -1. Pull the Docker image: - - .. code-block:: console - - $ docker pull osrf/ros2:nightly - -2. Start an interactive container: - - .. code-block:: console - - $ docker run -it osrf/ros2:nightly - -For support on running GUI applications in Docker, take a look at the tutorial `User GUI's with Docker `_ or the tool `rocker `_. +.. redirect-from:: + + Installation/Prerelease-Testing + Installation/Testing + +Testing with pre-release binaries +================================= + +Many ROS packages are provided as pre-built binaries. +Usually, you will get the released version of binaries when following :doc:`../../Get-Started/Installation`. +There are also pre-released versions of binaries that are useful for testing before making an official release. +This article describes several options if you would like to try out pre-released versions of ROS binaries. + +When packages are released into a ROS distribution (using bloom), the buildfarm builds them into deb packages which are stored temporarily in the **building** apt repository. +As dependent packages are rebuilt, an automatic process periodically synchronizes the packages in **building** to a secondary repository called **ros-testing**. +**ros-testing** is intended as a soaking area where developers and bleeding-edge users may give the packages extra testing, before they are manually synced into the public ros repository from which users typically install packages. + +Approximately every two weeks, the rosdistro's release manager manually synchronizes the contents of **ros-testing** into the **main** ROS repository. + +deb testing repository +---------------------- + +For Debian-based operating systems, you can install binary packages from the **ros-testing** repository. + +1. Make sure you have a working ROS 2 installation from deb packages (see :doc:`../../Get-Started/Installation`). + +2. Install the ros2-testing-apt-source package. + This will automatically uninstall the ros2-apt-source package since only one repository may be enabled at a time. + + .. code-block:: console + + $ sudo apt install -y ros2-testing-apt-source + +3. Update the apt index: + + .. code-block:: console + + $ sudo apt update + +4. You can now install individual packages from the testing repository, for example: + + .. code-block:: console + + $ sudo apt install ros-{DISTRO}-my-just-released-package + +5. Alternatively, you can move your entire ROS 2 installation to the testing repository: + + .. code-block:: console + + $ sudo apt dist-upgrade + +6. Once you are finished testing, you can switch back to the normal repository by re-installing the ros-apt-source package: + + .. code-block:: console + + $ sudo apt install -y ros2-apt-source + + and doing an update and upgrade: + + .. code-block:: console + + $ sudo apt update + $ sudo apt dist-upgrade + + +RHEL testing repository +----------------------- + +For RHEL you can install binary packages from the **ros-testing** repository, by enabling the testing repository on the source configuration: + +1. Make sure you have a working ROS 2 installation for rpm packages (see the :doc:`RHEL installation instructions `). + +2. Enable testing and disable main repository: + + .. code-block:: console + + $ sudo dnf config-manager --set-enabled ros2-testing + $ sudo dnf config-manager --set-disabled ros2 + +3. Update the dnf index: + + .. code-block:: console + + $ sudo dnf update + +4. You can now install individual packages from the testing repository, for example: + + .. code-block:: console + + $ sudo dnf install ros-{DISTRO}-my-just-released-package + +5. Once you are finished testing, you can switch back to the normal repository by re-enabling the main repository: + + .. code-block:: console + + $ sudo dnf config-manager --set-disabled ros2-testing + $ sudo dnf config-manager --set-enabled ros2 + + and doing an update and upgrade: + + .. code-block:: console + + $ sudo dnf update + $ sudo dnf system-upgrade + +.. _Prerelease_binaries: + +Binary archives +--------------- + +For core packages, we run nightly packaging jobs for Ubuntu Linux, RHEL, and Windows. +These packaging jobs produce archives with pre-built binaries that can be downloaded and extracted to your filesystem. + +1. Make sure you have all dependencies installed according to the :doc:`latest development setup ` for your platform. + +2. Go to https://ci.ros2.org/view/packaging/ and select a packaging job from the list corresponding to your platform. + +3. Under the heading "Last Successful Artifacts" you should see a download link (e.g. for Windows, ``ros2-package-windows-AMD64.zip``). + +4. Download and extract the archive to your file system. + +5. To use the binary archive installation, source the ``setup.*`` file that can be found in the root of the archive. + + .. tabs:: + + .. group-tab:: Ubuntu Linux and RHEL + + .. code-block:: console + + $ source path/to/extracted/archive/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call path\to\extracted\archive\setup.bat + +Docker +------ + +For Ubuntu Linux, there is also a nightly Docker image based on the nightly binary archive. + +1. Pull the Docker image: + + .. code-block:: console + + $ docker pull osrf/ros2:nightly + +2. Start an interactive container: + + .. code-block:: console + + $ docker run -it osrf/ros2:nightly + +For support on running GUI applications in Docker, take a look at the tutorial `User GUI's with Docker `_ or the tool `rocker `_. \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst b/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst index d8d178c0b51..8c1ff213f1c 100644 --- a/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst +++ b/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst @@ -1,65 +1,69 @@ -.. BuildFarmTesting: - -Testing Your Code with the ROS Build Farm -========================================= - -The `ROS 2 Build Farm `_ is incredibly powerful. -In addition to creating binaries, it will also test pull requests by compiling and running all the tests for your ROS packages before the PR is merged. - -There are four prerequisites. - - * The GitHub user `@ros-pull-request-builder `_ must have access to the repository. - * The GitHub repository must have the webhooks set up. - * `Your package must be indexed in rosdistro ` - * The ``test_pull_requests`` flag must be true. - - -GitHub Access -------------- - -You can give access to the PR Builder either at the GitHub organization level OR just to the single GitHub repository. - -GitHub Organization -^^^^^^^^^^^^^^^^^^^ - -#. Open `https://github.com/orgs/%YOUR_ORG%/people `_ - (while replacing ``%YOUR_ORG%`` with the appropriate organization) -#. Click ``Invite Member`` and enter ``ros-pull-request-builder`` - - -GitHub Repository -^^^^^^^^^^^^^^^^^ - -#. Open `https://github.com/%YOUR_ORG%/%YOUR_REPO%/settings/access `_ - (while replacing ``%YOUR_ORG%/%YOUR_REPO$`` with the appropriate organization/repo) -#. Click ``Add people`` and enter ``ros-pull-request-builder`` -#. Select ``Admin`` or ``Write`` for their role. - (see next section) - - -WebHooks --------- - -If you grant full administrative rights to ``ros-pull-request-builder``, it will automatically setup the hooks. - -Alternatively, you can avoid the need for full administrative rights by setting them up with only **write** permissions. - -#. Open `https://github.com/%YOUR_ORG%/%YOUR_REPO%/settings/hooks/new `_) -#. Enter ``"https://build.ros2.org/ghprbhook/`` as the Payload URL -#. Check the following options: - * Let me select individual events. - * Issue comments - * Pull requests - - -test_pull_requests ------------------- - -For each ROS distro that you want pull request testing for, you must enable the ``test_pull_requests`` flag in the appropriate section of the `rosdistro `_. - - * **Option 1** - You have the option when running `bloom ` to turn on pull request testing. - * **Option 2** - You can **carefully** manually edit the appropriate file in the rosdistro repo, and make a new pull request. - `Example `_. - `Documented in REP 143 `_. - -Note that after the pull request has been added, the job will usually not be created until the nightly Jenkins reconfiguration. +.. redirect-from:: + + Tutorials/Intermediate/Testing/BuildFarmTesting + +.. BuildFarmTesting: + +Testing Your Code with the ROS Build Farm +========================================= + +The `ROS 2 Build Farm `_ is incredibly powerful. +In addition to creating binaries, it will also test pull requests by compiling and running all the tests for your ROS packages before the PR is merged. + +There are four prerequisites. + + * The GitHub user `@ros-pull-request-builder `_ must have access to the repository. + * The GitHub repository must have the webhooks set up. + * `Your package must be indexed in rosdistro ` + * The ``test_pull_requests`` flag must be true. + + +GitHub Access +------------- + +You can give access to the PR Builder either at the GitHub organization level OR just to the single GitHub repository. + +GitHub Organization +^^^^^^^^^^^^^^^^^^^ + +#. Open `https://github.com/orgs/%YOUR_ORG%/people `_ + (while replacing ``%YOUR_ORG%`` with the appropriate organization) +#. Click ``Invite Member`` and enter ``ros-pull-request-builder`` + + +GitHub Repository +^^^^^^^^^^^^^^^^^ + +#. Open `https://github.com/%YOUR_ORG%/%YOUR_REPO%/settings/access `_ + (while replacing ``%YOUR_ORG%/%YOUR_REPO$`` with the appropriate organization/repo) +#. Click ``Add people`` and enter ``ros-pull-request-builder`` +#. Select ``Admin`` or ``Write`` for their role. + (see next section) + + +WebHooks +-------- + +If you grant full administrative rights to ``ros-pull-request-builder``, it will automatically setup the hooks. + +Alternatively, you can avoid the need for full administrative rights by setting them up with only **write** permissions. + +#. Open `https://github.com/%YOUR_ORG%/%YOUR_REPO%/settings/hooks/new `_) +#. Enter ``"https://build.ros2.org/ghprbhook/`` as the Payload URL +#. Check the following options: + * Let me select individual events. + * Issue comments + * Pull requests + + +test_pull_requests +------------------ + +For each ROS distro that you want pull request testing for, you must enable the ``test_pull_requests`` flag in the appropriate section of the `rosdistro `_. + + * **Option 1** - You have the option when running `bloom ` to turn on pull request testing. + * **Option 2** - You can **carefully** manually edit the appropriate file in the rosdistro repo, and make a new pull request. + `Example `_. + `Documented in REP 143 `_. + +Note that after the pull request has been added, the job will usually not be created until the nightly Jenkins reconfiguration. \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Testing/CLI.rst b/source/Developer-Tools/Testing/Testing/CLI.rst index 78215729217..ef9b1e13ea3 100644 --- a/source/Developer-Tools/Testing/Testing/CLI.rst +++ b/source/Developer-Tools/Testing/Testing/CLI.rst @@ -1,44 +1,48 @@ -.. TestingCLI: - -Running Tests in ROS 2 from the Command Line -============================================ - -Prerequisites -^^^^^^^^^^^^^ - -You will need a workspace setup with packages that have tests in them. - -Build and run your tests -^^^^^^^^^^^^^^^^^^^^^^^^ - -To compile and run the tests, simply run the `test `__ verb from ``colcon`` at the root of your workspace. - -.. code-block:: console - - $ colcon test --ctest-args tests [package_selection_args] - -Where ``package_selection_args`` are optional package selection arguments for ``colcon`` to limit which packages are built and run. -Find more info in the `colcon documentation on Package selection arguments `__ - -:ref:`Sourcing the workspace ` before testing should not be necessary. -``colcon test`` makes sure that the tests run with the right environment, have access to their dependencies, etc. - -Examine Test Results -^^^^^^^^^^^^^^^^^^^^ - -To see the results, simply run the `test-result `__ verb from ``colcon``. - -.. code-block:: console - - $ colcon test-result --all - -To see the exact test cases which fail, use the ``--verbose`` flag: - -.. code-block:: console - - $ colcon test-result --all --verbose - -Debugging tests with GDB -^^^^^^^^^^^^^^^^^^^^^^^^ - -For detailed guidance on debugging tests using GDB, refer to the :doc:`GDB Tutorial <../../../How-To-Guides/Getting-Backtraces-in-ROS-2>`. +.. redirect-from:: + + Tutorials/Intermediate/Testing/CLI + +.. TestingCLI: + +Running Tests in ROS 2 from the Command Line +============================================ + +Prerequisites +^^^^^^^^^^^^^ + +You will need a workspace setup with packages that have tests in them. + +Build and run your tests +^^^^^^^^^^^^^^^^^^^^^^^^ + +To compile and run the tests, simply run the `test `__ verb from ``colcon`` at the root of your workspace. + +.. code-block:: console + + $ colcon test --ctest-args tests [package_selection_args] + +Where ``package_selection_args`` are optional package selection arguments for ``colcon`` to limit which packages are built and run. +Find more info in the `colcon documentation on Package selection arguments `__ + +:ref:`Sourcing the workspace ` before testing should not be necessary. +``colcon test`` makes sure that the tests run with the right environment, have access to their dependencies, etc. + +Examine Test Results +^^^^^^^^^^^^^^^^^^^^ + +To see the results, simply run the `test-result `__ verb from ``colcon``. + +.. code-block:: console + + $ colcon test-result --all + +To see the exact test cases which fail, use the ``--verbose`` flag: + +.. code-block:: console + + $ colcon test-result --all --verbose + +Debugging tests with GDB +^^^^^^^^^^^^^^^^^^^^^^^^ + +For detailed guidance on debugging tests using GDB, refer to the :doc:`GDB Tutorial <../../Debugging/Getting-Backtraces-in-ROS-2>`. \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Testing/Integration.rst b/source/Developer-Tools/Testing/Testing/Integration.rst index cb6862df90c..8e7ea856aa4 100644 --- a/source/Developer-Tools/Testing/Testing/Integration.rst +++ b/source/Developer-Tools/Testing/Testing/Integration.rst @@ -1,274 +1,278 @@ -Writing Basic Integration Tests with launch_testing -=================================================== - -**Goal:** Create and run integration tests on the ROS 2 turtlesim node. - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Prerequisites -------------- - -Before starting this tutorial, it is recommended to have completed the following tutorials on launching nodes: - -* :doc:`Launching Multiple Nodes <../../Beginner-CLI-Tools/Launching-Multiple-Nodes/Launching-Multiple-Nodes>` -* :doc:`Creating Launch files <../../Intermediate/Launch/Creating-Launch-Files>` - -Background ----------- - -Where unit tests focus on validating a very specific piece of functionality, integration tests focus on validating the interaction between pieces of code. -In ROS 2 this is often accomplished by launching a system of one or several nodes, for example the `Gazebo simulator `__ and the `Nav2 navigation `__ stack. -As a result, these tests are more complex both to set up and to run. - -A key aspect of ROS 2 integration testing is that nodes that are part of different tests shouldn't communicate with each other, even when run in parallel. -This will be achieved here using a specific test runner that picks unique :doc:`ROS domain IDs <../../../Concepts/Intermediate/About-Domain-ID>`. -In addition, integration tests have to fit in the overall testing workflow. -A standardized approach is to ensure each test outputs an XUnit file, which are easily parsed using common test tooling. - -Overview --------- - -The main tool in use here is the `launch_testing `_ package -(`launch_testing repository `_). -This ROS-agnostic functionality can extend a Python launch file with both active tests (that run while the nodes are also running) and post-shutdown tests (which run once after all nodes have exited). -``launch_testing`` relies on the Python standard module `unittest `_ for the actual testing. -To get our integration tests run as part of ``colcon test``, we register the launch file in the ``CMakeLists.txt``. - -Steps ------ - -1 Describe the test in the test launch file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Both the nodes under test and the tests themselves are launched using a Python launch file, which resembles a ROS 2 Python launch file. -It is customary to make the integration test launch file names follow the pattern ``test/test_*.py``. - -There are two common types of tests in integration testing: active tests, which run while the nodes under test are running, and post-shutdown tests, which are run after exiting the nodes. -We will cover both in this tutorial. - -1.1 Imports -~~~~~~~~~~~ - -We first start by importing the Python modules we will be using. -Only two modules are specific to testing: the general-purpose ``unittest``, and ``launch_testing``. - -.. code-block:: python - - import os - import sys - import time - import unittest - - import launch - import launch_ros - import launch_testing.actions - import rclpy - from turtlesim_msgs.msg import Pose - -1.2 Generate the test description -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The function ``generate_test_description`` describes what to launch, similar to ``generate_launch_description`` in a ROS 2 Python launch file. -In the example below, we launch the turtlesim node and half a second later our tests. - -In more complex integration test setups, you will probably want to launch a system of several nodes, together with additional nodes that perform mocking or must otherwise interact with the nodes under test. - -.. code-block:: python - - def generate_test_description(): - return ( - launch.LaunchDescription( - [ - # Nodes under test - launch_ros.actions.Node( - package='turtlesim', - namespace='', - executable='turtlesim_node', - name='turtle1', - ), - # Launch tests 0.5 s later - launch.actions.TimerAction( - period=0.5, actions=[launch_testing.actions.ReadyToTest()]), - ] - ), {}, - ) - -1.3 Active tests -~~~~~~~~~~~~~~~~ - -The active tests interact with the running nodes. -In this tutorial, we will check whether the turtlesim node publishes pose messages (by listening to the node's 'turtle1/pose' topic) and whether it logs that it spawned the turtle (by listening to stderr). - -The active tests are defined as methods of a class inheriting from `unittest.TestCase `_. -The child class, here ``TestTurtleSim``, contains the following methods: - -- ``test_*``: the test methods, each performing some ROS communication with the nodes under test and/or listening to the process output (passed in through ``proc_output``). - They are executed sequentially. -- ``setUp``, ``tearDown``: respectively run before (to prepare the test fixture) and after executing each test method. - By creating the node in the ``setUp`` method, we use a different node instance for each test to reduce the risk of tests communicating with each other. -- ``setUpClass``, ``tearDownClass``: these class methods respectively run once before and after executing all the test methods. - -It's highly recommended to go through `launch_testing's detailed documentation on this topic `_. - -.. code-block:: python - - # Active tests - class TestTurtleSim(unittest.TestCase): - @classmethod - def setUpClass(cls): - rclpy.init() - - @classmethod - def tearDownClass(cls): - rclpy.shutdown() - - def setUp(self): - self.node = rclpy.create_node('test_turtlesim') - - def tearDown(self): - self.node.destroy_node() - - def test_publishes_pose(self, proc_output): - """Check whether pose messages published""" - msgs_rx = [] - sub = self.node.create_subscription( - Pose, 'turtle1/pose', - lambda msg: msgs_rx.append(msg), 100) - try: - # Listen to the pose topic for 10 s - end_time = time.time() + 10 - while time.time() < end_time: - # spin to get subscriber callback executed - rclpy.spin_once(self.node, timeout_sec=1) - # There should have been 100 messages received - assert len(msgs_rx) > 100 - finally: - self.node.destroy_subscription(sub) - - def test_logs_spawning(self, proc_output): - """Check whether logging properly""" - proc_output.assertWaitFor( - 'Spawning turtle [turtle1] at x=', - timeout=5, stream='stderr') - -Note that the way we listen to the 'turtle1/pose' topic in ``test_publishes_pose`` differs from :doc:`the usual approach <../../Beginner-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber>`. -Instead of calling the blocking ``rclpy.spin``, we trigger the ``spin_once`` method - which executes the first available callback (our subscriber callback if a message arrived within 1 second) - until we have gathered all messages published over the last 10 seconds. -The package `launch_testing_ros `_ provides some convenience functions to achieve similar behavior, -such as `WaitForTopics `_. - -If you want to go further, you can implement a third test that publishes a twist message, asking the turtle to move, and subsequently checks that it moved by asserting that the pose message changed. -This effectively automates part of the :doc:`Turtlesim introduction tutorial <../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>`. - -1.4 Post-shutdown tests -~~~~~~~~~~~~~~~~~~~~~~~ - -The classes marked with the ``launch_testing.post_shutdown_test`` decorator are run after letting the nodes under test exit. -A typical test here is whether the nodes exited cleanly, for which ``launch_testing`` provides the method -`asserts.assertExitCodes `_. - -.. code-block:: python - - # Post-shutdown tests - @launch_testing.post_shutdown_test() - class TestTurtleSimShutdown(unittest.TestCase): - def test_exit_codes(self, proc_info): - """Check if the processes exited normally.""" - launch_testing.asserts.assertExitCodes(proc_info) - -2 Register the test in the CMakeLists.txt -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Registering the test in the ``CMakeLists.txt`` fulfills two functions: - -- it integrates it in the ``CTest`` framework ROS 2 CMake-based packages rely on - (and hence it will be called when running ``colcon test``). -- it allows to specify *how* the test is to be run - - in this case, with a unique domain id to ensure test isolation. - -This latter aspect is realized using the special test runner `run_test_isolated.py `_. -To ease adding several integration tests, we define the CMake function ``add_ros_isolated_launch_test`` such that each additional test requires only a single line. - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(app) - - ######## - # test # - ######## - - if(BUILD_TESTING) - # Integration tests - find_package(ament_cmake_ros REQUIRED) - find_package(launch_testing_ament_cmake REQUIRED) - function(add_ros_isolated_launch_test path) - set(RUNNER "${ament_cmake_ros_DIR}/run_test_isolated.py") - add_launch_test("${path}" RUNNER "${RUNNER}" ${ARGN}) - endfunction() - add_ros_isolated_launch_test(test/test_integration.py) - endif() - -3 Dependencies and package organization -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Finally, add the following dependencies to your ``package.xml``: - -.. code-block:: XML - - ament_cmake_ros - launch - launch_ros - launch_testing - launch_testing_ament_cmake - rclpy - turtlesim - turtlesim_msgs - -After following the above steps, your package (here named 'app') ought to look as follows: - -.. code-block:: - - app/ - CMakeLists.txt - package.xml - tests/ - test_integration.py - -Integration tests can be part of any ROS package. -One can dedicate one or more packages to just integration testing, or alternatively add them to the package of which they test the functionality. -In this tutorial, we go with the first option as we will test the existing turtlesim node. - -4 Running tests and report generation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For running the integration test and examining the results, see the tutorial :doc:`Running Tests in ROS 2 from the Command Line<../../Intermediate/Testing/CLI>`. - -Summary -------- - -In this tutorial, we explored the process of creating and running integration tests on the ROS 2 turtlesim node. -We discussed the integration test launch file and covered writing active tests and post-shutdown tests. -To recap, the four key elements of the integration test launch file are: - -* The function ``generate_test_description``: This launches our nodes under tests as well as our tests. -* ``launch_testing.actions.ReadyToTest()``: This alerts the test framework that the tests should be run, and ensures that the active tests and the nodes are run together. -* An undecorated class inheriting from ``unittest.TestCase``: This houses the active tests, including set up and teardown, and gives access to ROS logging through ``proc_output``. -* A second class inheriting from ``unittest.TestCase`` decorated with ``@launch_testing.post_shutdown_test()``: These are tests that run after all nodes have shutdown; it is common to assert that the nodes exited cleanly. - -The launch test is subsequently registered in the ``CMakeLists.txt`` using the custom cmake macro ``add_ros_isolated_launch_test`` which ensures that each launch test runs with a unique ``ROS_DOMAIN_ID``, -avoiding undesired cross communication. - -Related content ---------------- - -* :doc:`Why automatic tests? <../../Intermediate/Testing/Testing-Main>` -* :doc:`C++ unit testing with GTest <../../Intermediate/Testing/Cpp>` - and :doc:`Python unit testing with Pytest <../../Intermediate/Testing/Python>` -* `launch_pytest documentation `_, - an alternative launch integration testing package to ``launch_testing`` +.. redirect-from:: + + Tutorials/Intermediate/Testing/Integration + +Writing Basic Integration Tests with launch_testing +=================================================== + +**Goal:** Create and run integration tests on the ROS 2 turtlesim node. + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Prerequisites +------------- + +Before starting this tutorial, it is recommended to have completed the following tutorials on launching nodes: + +* :doc:`Launching Multiple Nodes <../../../ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes>` +* :doc:`Creating Launch files <../../Launch/Creating-Launch-Files>` + +Background +---------- + +Where unit tests focus on validating a very specific piece of functionality, integration tests focus on validating the interaction between pieces of code. +In ROS 2 this is often accomplished by launching a system of one or several nodes, for example the `Gazebo simulator `__ and the `Nav2 navigation `__ stack. +As a result, these tests are more complex both to set up and to run. + +A key aspect of ROS 2 integration testing is that nodes that are part of different tests shouldn't communicate with each other, even when run in parallel. +This will be achieved here using a specific test runner that picks unique :doc:`ROS domain IDs <../../../ROS-Framework/nodes/About-Domain-ID>`. +In addition, integration tests have to fit in the overall testing workflow. +A standardized approach is to ensure each test outputs an XUnit file, which are easily parsed using common test tooling. + +Overview +-------- + +The main tool in use here is the `launch_testing `_ package +(`launch_testing repository `_). +This ROS-agnostic functionality can extend a Python launch file with both active tests (that run while the nodes are also running) and post-shutdown tests (which run once after all nodes have exited). +``launch_testing`` relies on the Python standard module `unittest `_ for the actual testing. +To get our integration tests run as part of ``colcon test``, we register the launch file in the ``CMakeLists.txt``. + +Steps +----- + +1 Describe the test in the test launch file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Both the nodes under test and the tests themselves are launched using a Python launch file, which resembles a ROS 2 Python launch file. +It is customary to make the integration test launch file names follow the pattern ``test/test_*.py``. + +There are two common types of tests in integration testing: active tests, which run while the nodes under test are running, and post-shutdown tests, which are run after exiting the nodes. +We will cover both in this tutorial. + +1.1 Imports +~~~~~~~~~~~ + +We first start by importing the Python modules we will be using. +Only two modules are specific to testing: the general-purpose ``unittest``, and ``launch_testing``. + +.. code-block:: python + + import os + import sys + import time + import unittest + + import launch + import launch_ros + import launch_testing.actions + import rclpy + from turtlesim_msgs.msg import Pose + +1.2 Generate the test description +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The function ``generate_test_description`` describes what to launch, similar to ``generate_launch_description`` in a ROS 2 Python launch file. +In the example below, we launch the turtlesim node and half a second later our tests. + +In more complex integration test setups, you will probably want to launch a system of several nodes, together with additional nodes that perform mocking or must otherwise interact with the nodes under test. + +.. code-block:: python + + def generate_test_description(): + return ( + launch.LaunchDescription( + [ + # Nodes under test + launch_ros.actions.Node( + package='turtlesim', + namespace='', + executable='turtlesim_node', + name='turtle1', + ), + # Launch tests 0.5 s later + launch.actions.TimerAction( + period=0.5, actions=[launch_testing.actions.ReadyToTest()]), + ] + ), {}, + ) + +1.3 Active tests +~~~~~~~~~~~~~~~~ + +The active tests interact with the running nodes. +In this tutorial, we will check whether the turtlesim node publishes pose messages (by listening to the node's 'turtle1/pose' topic) and whether it logs that it spawned the turtle (by listening to stderr). + +The active tests are defined as methods of a class inheriting from `unittest.TestCase `_. +The child class, here ``TestTurtleSim``, contains the following methods: + +- ``test_*``: the test methods, each performing some ROS communication with the nodes under test and/or listening to the process output (passed in through ``proc_output``). + They are executed sequentially. +- ``setUp``, ``tearDown``: respectively run before (to prepare the test fixture) and after executing each test method. + By creating the node in the ``setUp`` method, we use a different node instance for each test to reduce the risk of tests communicating with each other. +- ``setUpClass``, ``tearDownClass``: these class methods respectively run once before and after executing all the test methods. + +It's highly recommended to go through `launch_testing's detailed documentation on this topic `_. + +.. code-block:: python + + # Active tests + class TestTurtleSim(unittest.TestCase): + @classmethod + def setUpClass(cls): + rclpy.init() + + @classmethod + def tearDownClass(cls): + rclpy.shutdown() + + def setUp(self): + self.node = rclpy.create_node('test_turtlesim') + + def tearDown(self): + self.node.destroy_node() + + def test_publishes_pose(self, proc_output): + """Check whether pose messages published""" + msgs_rx = [] + sub = self.node.create_subscription( + Pose, 'turtle1/pose', + lambda msg: msgs_rx.append(msg), 100) + try: + # Listen to the pose topic for 10 s + end_time = time.time() + 10 + while time.time() < end_time: + # spin to get subscriber callback executed + rclpy.spin_once(self.node, timeout_sec=1) + # There should have been 100 messages received + assert len(msgs_rx) > 100 + finally: + self.node.destroy_subscription(sub) + + def test_logs_spawning(self, proc_output): + """Check whether logging properly""" + proc_output.assertWaitFor( + 'Spawning turtle [turtle1] at x=', + timeout=5, stream='stderr') + +Note that the way we listen to the 'turtle1/pose' topic in ``test_publishes_pose`` differs from :doc:`the usual approach <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber>`. +Instead of calling the blocking ``rclpy.spin``, we trigger the ``spin_once`` method - which executes the first available callback (our subscriber callback if a message arrived within 1 second) - until we have gathered all messages published over the last 10 seconds. +The package `launch_testing_ros `_ provides some convenience functions to achieve similar behavior, +such as `WaitForTopics `_. + +If you want to go further, you can implement a third test that publishes a twist message, asking the turtle to move, and subsequently checks that it moved by asserting that the pose message changed. +This effectively automates part of the :doc:`Turtlesim introduction tutorial <../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +1.4 Post-shutdown tests +~~~~~~~~~~~~~~~~~~~~~~~ + +The classes marked with the ``launch_testing.post_shutdown_test`` decorator are run after letting the nodes under test exit. +A typical test here is whether the nodes exited cleanly, for which ``launch_testing`` provides the method +`asserts.assertExitCodes `_. + +.. code-block:: python + + # Post-shutdown tests + @launch_testing.post_shutdown_test() + class TestTurtleSimShutdown(unittest.TestCase): + def test_exit_codes(self, proc_info): + """Check if the processes exited normally.""" + launch_testing.asserts.assertExitCodes(proc_info) + +2 Register the test in the CMakeLists.txt +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Registering the test in the ``CMakeLists.txt`` fulfills two functions: + +- it integrates it in the ``CTest`` framework ROS 2 CMake-based packages rely on + (and hence it will be called when running ``colcon test``). +- it allows to specify *how* the test is to be run - + in this case, with a unique domain id to ensure test isolation. + +This latter aspect is realized using the special test runner `run_test_isolated.py `_. +To ease adding several integration tests, we define the CMake function ``add_ros_isolated_launch_test`` such that each additional test requires only a single line. + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(app) + + ######## + # test # + ######## + + if(BUILD_TESTING) + # Integration tests + find_package(ament_cmake_ros REQUIRED) + find_package(launch_testing_ament_cmake REQUIRED) + function(add_ros_isolated_launch_test path) + set(RUNNER "${ament_cmake_ros_DIR}/run_test_isolated.py") + add_launch_test("${path}" RUNNER "${RUNNER}" ${ARGN}) + endfunction() + add_ros_isolated_launch_test(test/test_integration.py) + endif() + +3 Dependencies and package organization +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Finally, add the following dependencies to your ``package.xml``: + +.. code-block:: XML + + ament_cmake_ros + launch + launch_ros + launch_testing + launch_testing_ament_cmake + rclpy + turtlesim + turtlesim_msgs + +After following the above steps, your package (here named 'app') ought to look as follows: + +.. code-block:: + + app/ + CMakeLists.txt + package.xml + tests/ + test_integration.py + +Integration tests can be part of any ROS package. +One can dedicate one or more packages to just integration testing, or alternatively add them to the package of which they test the functionality. +In this tutorial, we go with the first option as we will test the existing turtlesim node. + +4 Running tests and report generation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For running the integration test and examining the results, see the tutorial :doc:`Running Tests in ROS 2 from the Command Line `. + +Summary +------- + +In this tutorial, we explored the process of creating and running integration tests on the ROS 2 turtlesim node. +We discussed the integration test launch file and covered writing active tests and post-shutdown tests. +To recap, the four key elements of the integration test launch file are: + +* The function ``generate_test_description``: This launches our nodes under tests as well as our tests. +* ``launch_testing.actions.ReadyToTest()``: This alerts the test framework that the tests should be run, and ensures that the active tests and the nodes are run together. +* An undecorated class inheriting from ``unittest.TestCase``: This houses the active tests, including set up and teardown, and gives access to ROS logging through ``proc_output``. +* A second class inheriting from ``unittest.TestCase`` decorated with ``@launch_testing.post_shutdown_test()``: These are tests that run after all nodes have shutdown; it is common to assert that the nodes exited cleanly. + +The launch test is subsequently registered in the ``CMakeLists.txt`` using the custom cmake macro ``add_ros_isolated_launch_test`` which ensures that each launch test runs with a unique ``ROS_DOMAIN_ID``, +avoiding undesired cross communication. + +Related content +--------------- + +* :doc:`Why automatic tests? ` +* :doc:`C++ unit testing with GTest <../../Intermediate/Testing/Cpp>` + and :doc:`Python unit testing with Pytest ` +* `launch_pytest documentation `_, + an alternative launch integration testing package to ``launch_testing`` \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Testing/Python.rst b/source/Developer-Tools/Testing/Testing/Python.rst index 2753c871c5a..71499b6f6f6 100644 --- a/source/Developer-Tools/Testing/Testing/Python.rst +++ b/source/Developer-Tools/Testing/Testing/Python.rst @@ -1,92 +1,96 @@ -.. TestingPython: - -Writing Basic Tests with Python -=============================== - -Starting point: we'll assume you have a :ref:`basic ament_python package` set up already and you want to add some tests to it. - -If you are using ament_cmake_python, refer to the :doc:`ament_cmake_python docs<../../../How-To-Guides/Ament-CMake-Python-Documentation>` for how to make tests discoverable. -The test contents and invocation with ``colcon`` remain the same. - -Package Setup -------------- - -setup.py -^^^^^^^^ - -Your ``setup.py`` must have a test dependency on ``pytest`` within the call to ``setup(...)``: - -.. code-block:: python - - extras_require={ - 'test': ['pytest'], - }, - -Test Files and Folders -^^^^^^^^^^^^^^^^^^^^^^ - -Your test code needs to go in a folder named ``tests`` in the root of your package. - -Any file that contains tests that you want to run must have the pattern ``test_FOO.py`` where ``FOO`` can be replaced with anything. - -Example package layout: -""""""""""""""""""""""" - -.. code-block:: - - awesome_ros_package/ - awesome_ros_package/ - __init__.py - fozzie.py - package.xml - setup.cfg - setup.py - tests/ - test_init.py - test_copyright.py - test_fozzie.py - - -Test Contents -------------- - -You can now write tests to your heart's content. -There are `plenty of resources on pytest `__, but in short, you can write functions with the ``test_`` prefix and include whatever assert statements you'd like. - - -.. code-block:: python - - def test_math(): - assert 2 + 2 == 5 # This should fail for most mathematical systems - -Running Tests -------------- - -See the :doc:`tutorial on how to run tests from the command line ` for more information on running the tests and inspecting the test results. - -Special Commands ----------------- - -Beyond the :doc:`standard colcon testing commands ` you can also specify arguments to the ``pytest`` framework from the command line with the ``--pytest-args`` flag. -For example, you can specify the name of the function to run with - - -.. tabs:: - - .. group-tab:: Linux/macOS - - .. code-block:: console - - $ colcon test --packages-select --pytest-args -k name_of_the_test_function - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon test --merge-install --packages-select --pytest-args -k name_of_the_test_function - -To see the pytest output while running the tests, use these flags: - -.. code-block:: console - - $ colcon test --event-handlers console_cohesion+ +.. redirect-from:: + + Tutorials/Intermediate/Testing/Python + +.. TestingPython: + +Writing Basic Tests with Python +=============================== + +Starting point: we'll assume you have a :ref:`basic ament_python package` set up already and you want to add some tests to it. + +If you are using ament_cmake_python, refer to the :doc:`ament_cmake_python docs <../../Build/Ament-CMake-Python-Documentation>` for how to make tests discoverable. +The test contents and invocation with ``colcon`` remain the same. + +Package Setup +------------- + +setup.py +^^^^^^^^ + +Your ``setup.py`` must have a test dependency on ``pytest`` within the call to ``setup(...)``: + +.. code-block:: python + + extras_require={ + 'test': ['pytest'], + }, + +Test Files and Folders +^^^^^^^^^^^^^^^^^^^^^^ + +Your test code needs to go in a folder named ``tests`` in the root of your package. + +Any file that contains tests that you want to run must have the pattern ``test_FOO.py`` where ``FOO`` can be replaced with anything. + +Example package layout: +""""""""""""""""""""""" + +.. code-block:: + + awesome_ros_package/ + awesome_ros_package/ + __init__.py + fozzie.py + package.xml + setup.cfg + setup.py + tests/ + test_init.py + test_copyright.py + test_fozzie.py + + +Test Contents +------------- + +You can now write tests to your heart's content. +There are `plenty of resources on pytest `__, but in short, you can write functions with the ``test_`` prefix and include whatever assert statements you'd like. + + +.. code-block:: python + + def test_math(): + assert 2 + 2 == 5 # This should fail for most mathematical systems + +Running Tests +------------- + +See the :doc:`tutorial on how to run tests from the command line ` for more information on running the tests and inspecting the test results. + +Special Commands +---------------- + +Beyond the :doc:`standard colcon testing commands ` you can also specify arguments to the ``pytest`` framework from the command line with the ``--pytest-args`` flag. +For example, you can specify the name of the function to run with + + +.. tabs:: + + .. group-tab:: Linux/macOS + + .. code-block:: console + + $ colcon test --packages-select --pytest-args -k name_of_the_test_function + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon test --merge-install --packages-select --pytest-args -k name_of_the_test_function + +To see the pytest output while running the tests, use these flags: + +.. code-block:: console + + $ colcon test --event-handlers console_cohesion+ \ No newline at end of file diff --git a/source/Developer-Tools/Testing/Testing/Testing-Main.rst b/source/Developer-Tools/Testing/Testing/Testing-Main.rst index acc17f6c51b..dcc93e3864b 100644 --- a/source/Developer-Tools/Testing/Testing/Testing-Main.rst +++ b/source/Developer-Tools/Testing/Testing/Testing-Main.rst @@ -1,67 +1,71 @@ -.. _TestingMain: - -Testing -======= - -Why automatic tests? --------------------- - -Here are some of the many good reasons why should we have automated tests: - -* You can make incremental updates to your code more quickly. - ROS has hundreds of packages with many interdependencies, so it can be hard to anticipate the problems a small change might cause. - If your change passes the unit tests, you can be more confident that you haven't introduced problems — or at least the problems aren't your fault. -* You can refactor your code with greater confidence. - Passing the unit tests verifies that you haven't introduced any bugs while refactoring. - This gives you this wonderful freedom from change fear! -* It leads to better designed code. - Unit tests force you to write your code so that it can be more easily tested. - This often means keeping your underlying functions and framework separate, which is one of our design goals with ROS code. -* They prevent recurring bugs (bug regressions). - It's a good practice to write a unit test for every bug you fix. - In fact, write the unit test before you fix the bug. - This will help you to precisely, or even deterministically, reproduce the bug, and much more precisely understand what the problem is. - As a result, you will also create a better patch, which you can then test with your regression test to verify that the bug is fixed. - That way the bug won't accidentally get reintroduced if the code gets modified later on. - It also means that it will be easier to convince the reviewer of the patch that the problem is solved, and the contribution is of high quality. -* Other people can work on your code more easily (an automatic form of documentation). - It can be hard to figure out whether or not you've broken someone else's code when you make a change. - The unit tests are a tool for other developers to validate their changes. - Automatic tests document your coding decisions, and communicate to other developers automatically about their violation. - Thus tests become documentation for your code — a documentation that does not need to be read for the most time, and when it does need to be inspected the test system will precisely indicate what to read (which tests fail). - By writing automatic tests you make other contributors faster. - This improves the entire ROS project. -* It is much easier to become a contributor to ROS if we have automated unit tests. - It is very difficult for new external developers to contribute to your components. - When they make changes to code, they are often doing it in the blind, driven by a lot of guesswork. - By providing a harness of automated tests, you help them in the task. - They get immediate feedback for their changes. - It becomes easier to contribute to a project, and new contributors to join more easily. - Also their first contributions are of higher quality, which decreases the workload on maintainers. - A win-win! -* Automatic tests simplify maintainership. - Especially for mature packages, which change more slowly, and mostly need to be updated to new dependencies, an automatic test suite helps to very quickly establish whether the package still works. - This makes it much easier to decide whether the package is still supported or not. -* Automatic tests amplify the value of Continuous Integration. - Regression tests, along with normal scenario-based requirements tests, contribute to overall body of automated tests for your component. - Your component is better tested against evolution of other APIs that it depends on (CI servers will tell you better and more precisely what problems develop in your code). - -Perhaps the most important benefit of writing tests is that tests make you a good citizen. -Tests influence quality in the long term. -It is a well accepted practice in many open-source projects. -By writing regressions tests, you are contributing to long term quality of the ROS ecosystem. - -Is this all coming for free? ----------------------------- - -Of course, there is never free lunch. -To get the benefits of testing, some investment is necessary. - -* You need to develop a test, which sometimes may be difficult or costly. - Sometimes it might also be nontrivial, as the test should be automatic. - Things get particularly hairy if your tests should involve special hardware (they should not: try to use simulation, mock the hardware, or narrow down the test to a smaller software problem) or require external environment, for instance human operators. -* Regression tests and other automatic tests need to be maintained. - When the design of the component changes, a lot of tests become invalidated (for instance they no longer compile, or throw runtime exceptions related to the API design). - These tests fail not only because the redesign re-introduced bugs but also because they need to be updated to the new design. - Occasionally, with bigger redesigns, old regression tests should be dropped. -* Large bodies of tests can take a long time to run, which can increase Continuous Integration server costs. +.. redirect-from:: + + Tutorials/Intermediate/Testing/Testing-Main + +.. _TestingMain: + +Testing +======= + +Why automatic tests? +-------------------- + +Here are some of the many good reasons why should we have automated tests: + +* You can make incremental updates to your code more quickly. + ROS has hundreds of packages with many interdependencies, so it can be hard to anticipate the problems a small change might cause. + If your change passes the unit tests, you can be more confident that you haven't introduced problems — or at least the problems aren't your fault. +* You can refactor your code with greater confidence. + Passing the unit tests verifies that you haven't introduced any bugs while refactoring. + This gives you this wonderful freedom from change fear! +* It leads to better designed code. + Unit tests force you to write your code so that it can be more easily tested. + This often means keeping your underlying functions and framework separate, which is one of our design goals with ROS code. +* They prevent recurring bugs (bug regressions). + It's a good practice to write a unit test for every bug you fix. + In fact, write the unit test before you fix the bug. + This will help you to precisely, or even deterministically, reproduce the bug, and much more precisely understand what the problem is. + As a result, you will also create a better patch, which you can then test with your regression test to verify that the bug is fixed. + That way the bug won't accidentally get reintroduced if the code gets modified later on. + It also means that it will be easier to convince the reviewer of the patch that the problem is solved, and the contribution is of high quality. +* Other people can work on your code more easily (an automatic form of documentation). + It can be hard to figure out whether or not you've broken someone else's code when you make a change. + The unit tests are a tool for other developers to validate their changes. + Automatic tests document your coding decisions, and communicate to other developers automatically about their violation. + Thus tests become documentation for your code — a documentation that does not need to be read for the most time, and when it does need to be inspected the test system will precisely indicate what to read (which tests fail). + By writing automatic tests you make other contributors faster. + This improves the entire ROS project. +* It is much easier to become a contributor to ROS if we have automated unit tests. + It is very difficult for new external developers to contribute to your components. + When they make changes to code, they are often doing it in the blind, driven by a lot of guesswork. + By providing a harness of automated tests, you help them in the task. + They get immediate feedback for their changes. + It becomes easier to contribute to a project, and new contributors to join more easily. + Also their first contributions are of higher quality, which decreases the workload on maintainers. + A win-win! +* Automatic tests simplify maintainership. + Especially for mature packages, which change more slowly, and mostly need to be updated to new dependencies, an automatic test suite helps to very quickly establish whether the package still works. + This makes it much easier to decide whether the package is still supported or not. +* Automatic tests amplify the value of Continuous Integration. + Regression tests, along with normal scenario-based requirements tests, contribute to overall body of automated tests for your component. + Your component is better tested against evolution of other APIs that it depends on (CI servers will tell you better and more precisely what problems develop in your code). + +Perhaps the most important benefit of writing tests is that tests make you a good citizen. +Tests influence quality in the long term. +It is a well accepted practice in many open-source projects. +By writing regressions tests, you are contributing to long term quality of the ROS ecosystem. + +Is this all coming for free? +---------------------------- + +Of course, there is never free lunch. +To get the benefits of testing, some investment is necessary. + +* You need to develop a test, which sometimes may be difficult or costly. + Sometimes it might also be nontrivial, as the test should be automatic. + Things get particularly hairy if your tests should involve special hardware (they should not: try to use simulation, mock the hardware, or narrow down the test to a smaller software problem) or require external environment, for instance human operators. +* Regression tests and other automatic tests need to be maintained. + When the design of the component changes, a lot of tests become invalidated (for instance they no longer compile, or throw runtime exceptions related to the API design). + These tests fail not only because the redesign re-introduced bugs but also because they need to be updated to the new design. + Occasionally, with bigger redesigns, old regression tests should be dropped. +* Large bodies of tests can take a long time to run, which can increase Continuous Integration server costs. \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/About-RQt.rst b/source/Developer-Tools/Visualization/About-RQt.rst index e37b8a67d46..f6de9605a2d 100644 --- a/source/Developer-Tools/Visualization/About-RQt.rst +++ b/source/Developer-Tools/Visualization/About-RQt.rst @@ -1,83 +1,84 @@ -.. redirect-from:: - - RQt-Overview-Usage - Tutorials/RQt-Overview-Usage - Concepts/About-RQt - -Overview and usage of RQt -========================= - -.. contents:: Table of Contents - :local: - -Overview --------- - -RQt is a graphical user interface framework that implements various tools and interfaces in the form of plugins. -One can run all the existing GUI tools as dockable windows within RQt. -The tools can still run in a traditional standalone method, but RQt makes it easier to manage all the various windows in a single screen layout. - -You can run any RQt tools/plugins easily by: - -.. code-block:: console - - $ rqt - -This GUI allows you to choose any available plugins on your system. -You can also run plugins in standalone windows. -For example, RQt Python Console: - -.. code-block:: console - - $ ros2 run rqt_py_console rqt_py_console - -Users can create their own plugins for RQt with either ``Python`` or ``C++``. -To see what RQt plugins are available for your system, run: - -.. code-block:: console - - $ ros2 pkg list - -And then look for packages that start with ``rqt_``. - -System setup ------------- - -Installing From debs -^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-rqt* - - -RQt Components Structure ------------------------- - -RQt consists of two metapackages: - -* *rqt* - core infrastructure modules. -* *rqt_common_plugins* - Commonly useful debugging tools. - -Advantage of RQt framework --------------------------- - -Compared to building your own GUIs from scratch: - -* Standardized common procedures for GUI (start-shutdown hook, restore previous states). -* Multiple widgets can be docked in a single window. -* Easily turn your existing Qt widgets into RQt plugins. -* Expect support at `Robotics Stack Exchange `__ (ROS community website for the questions). - -From system architecture's perspective: - -* Support multi-platform (basically wherever `QT `__ and ROS run) and multi-language (``Python``, ``C++``). -* Manageable lifecycle: RQt plugins using a common API makes maintenance & reuse easier. - - -Further Reading ---------------- - -* ROS 2 Discourse `announcement of porting to ROS 2 `__) -* `RQt for ROS 1 documentation `__ -* Brief overview of RQt (from `a Willow Garage intern blog post `__) +.. redirect-from:: + + RQt-Overview-Usage + Tutorials/RQt-Overview-Usage + Concepts/About-RQt + Concepts/Intermediate/About-RQt + +Overview and usage of RQt +========================= + +.. contents:: Table of Contents + :local: + +Overview +-------- + +RQt is a graphical user interface framework that implements various tools and interfaces in the form of plugins. +One can run all the existing GUI tools as dockable windows within RQt. +The tools can still run in a traditional standalone method, but RQt makes it easier to manage all the various windows in a single screen layout. + +You can run any RQt tools/plugins easily by: + +.. code-block:: console + + $ rqt + +This GUI allows you to choose any available plugins on your system. +You can also run plugins in standalone windows. +For example, RQt Python Console: + +.. code-block:: console + + $ ros2 run rqt_py_console rqt_py_console + +Users can create their own plugins for RQt with either ``Python`` or ``C++``. +To see what RQt plugins are available for your system, run: + +.. code-block:: console + + $ ros2 pkg list + +And then look for packages that start with ``rqt_``. + +System setup +------------ + +Installing From debs +^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-rqt* + + +RQt Components Structure +------------------------ + +RQt consists of two metapackages: + +* *rqt* - core infrastructure modules. +* *rqt_common_plugins* - Commonly useful debugging tools. + +Advantage of RQt framework +-------------------------- + +Compared to building your own GUIs from scratch: + +* Standardized common procedures for GUI (start-shutdown hook, restore previous states). +* Multiple widgets can be docked in a single window. +* Easily turn your existing Qt widgets into RQt plugins. +* Expect support at `Robotics Stack Exchange `__ (ROS community website for the questions). + +From system architecture's perspective: + +* Support multi-platform (basically wherever `QT `__ and ROS run) and multi-language (``Python``, ``C++``). +* Manageable lifecycle: RQt plugins using a common API makes maintenance & reuse easier. + + +Further Reading +--------------- + +* ROS 2 Discourse `announcement of porting to ROS 2 `__) +* `RQt for ROS 1 documentation `__ +* Brief overview of RQt (from `a Willow Garage intern blog post `__) \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst b/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst index a83072f8fc9..f26deb39983 100644 --- a/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst +++ b/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst @@ -1,318 +1,322 @@ -Marker: Display types -===================== - -**Goal:** This tutorial explains the basic Marker types and how to use them. - -**Tutorial level:** Intermediate - -**Time:** 15 Minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- -The Markers display allows programmatic addition of various primitive shapes to the 3D view by sending a -`visualization_msgs/msg/Marker `_ or -`visualization_msgs/msg/MarkerArray `_ message. - -.. image:: images/marker_overview.png - -Start with :doc:`Marker: Sending Basic Shapes <../Marker-Sending-Basic-Shapes/Marker-Sending-Basic-Shapes>` for a minimal publisher example that introduces the marker message used throughout this page. - -The Marker Message ------------------- -1 Example Usage (C++) -^^^^^^^^^^^^^^^^^^^^^ -First we will create a simple publisher node that publishes ``Marker`` messages from the ``visualization_messages`` package to the ``visualization_marker`` topic: - -.. code-block:: C++ - - auto marker_pub = node->create_publisher("visualization_marker", 1); - -After that it is as simple as filling out a `visualization_msgs/msg/Marker `_ -message and publishing it: - -.. code-block:: C++ - - visualization_msgs::msg::Marker marker; - - marker.header.frame_id = "/my_frame"; - marker.header.stamp = rclcpp::Clock().now(); - - marker.ns = "basic_shapes"; - marker.id = 0; - - marker.type = visualization_msgs::msg::Marker::SPHERE; - - marker.action = visualization_msgs::msg::Marker::ADD; - - marker.pose.position.x = 0; - marker.pose.position.y = 0; - marker.pose.position.z = 0; - marker.pose.orientation.x = 0.0; - marker.pose.orientation.y = 0.0; - marker.pose.orientation.z = 0.0; - marker.pose.orientation.w = 1.0; - - marker.scale.x = 1.0; - marker.scale.y = 1.0; - marker.scale.z = 1.0; - - marker.color.r = 0.0f; - marker.color.g = 1.0f; - marker.color.b = 0.0f; - marker.color.a = 1.0; // Don't forget to set the alpha! - - // only if using a MESH_RESOURCE marker type: - marker.mesh_resource = "package://pr2_description/meshes/base_v0/base.dae"; - - marker.lifetime = rclcpp::Duration::from_nanoseconds(0); - - marker_pub->publish(marker); - -There is also a `visualization_msgs/msg/MarkerArray `_ message, which lets you publish many markers at once. - -2 Message Parameters -^^^^^^^^^^^^^^^^^^^^ - -The Marker message type is defined in `ROS 2 Common Interfaces `_ package. -The messages in this package include comments that are helpful in understanding each of the fields in the message. - -* ``ns``: - - Namespace for these markers. - This plus the id form a unique identifier. - -* ``id``: - - Unique id assigned to this marker. - It is your responsibility to keep these unique within your namespace. - -* ``type``: - - Type of marker (Arrow, Sphere, ...). - The available types are specified in the message definition. - -* ``action``: - - 0 = add/modify, 1 = (deprecated), 2 = delete, 3 = deleteall - -* ``pose``: - - Pose marker, specified as x/y/z position and x/y/z/w quaternion orientation. - -* ``scale``: - - Scale of the marker. - Applied before the position/orientation. - A scale of [1, 1, 1] means the object will be 1m by 1m by 1m. - -* ``color``: - - Color of the object, specified as r/g/b/a, with values in the range of [0, 1]. - The, ``a`` or alpha value, denotes the opacity of the marker with 1 indicating opaque and 0 indicating completely transparent. - The default value is 0, or completely transparent. - **You must set the a value of your marker to a non-zero value or it will be transparent by default!** - -* ``points``: - - Only used for markers of type ``Points``, ``Line strips``, and ``Line`` / ``Cube`` / ``Sphere`` -lists. - It's also used for the Arrow type, if you want to specify the arrow start and end points. - This entry represents a list of ``geometry_msgs/Point`` types for the center or each marker object you would like rendered. - -* ``colors``: - - This field is only used for markers that use the points member. - This field specifies per-vertex color r/g/b/ color (no alpha yet) for each entry in ``points``. - -* ``lifetime``: - - A `duration message value <{interface_link(builtin_interfaces/msg/Duration)}>`_ used to automatically delete the marker after this period of time. - The countdown resets if another marker of the same ``namespace`` / ``id`` is received. - -* ``frame_locked``: - - Without the ``frame_locked`` parameter the marker will be placed based on the current transform and will stay there even if the given transform changes later. - Setting this parameter tells RViz to retransform the marker to the new current location of the specified frame on every update cycle. - -* ``text``: - - The text string used for the ``TEXT_VIEW_FACING`` marker type - -* ``mesh_resource``: - - The resource location for the ``MESH_RESOURCE`` marker type. - Can be any mesh type supported by RViz (``.stl`` or Ogre ``.mesh`` in 1.0, with the addition of COLLADA in 1.1). - The format is the URI-form used by `resource_retriever `_, including the package:// syntax. - -3 Object types -^^^^^^^^^^^^^^ - -.. _RVizMarkerObjectTypes: - -3.1 Arrow (ARROW=0) -~~~~~~~~~~~~~~~~~~~ - -.. image:: images/ArrowMarker.png - -The arrow type provides two different ways of specifying where the arrow should begin/end: - -* ``Position/Orientation``: - - Pivot point is around the tip of its tail. - Identity orientation points it along the +X axis. - ``scale.x`` is the arrow length, ``scale.y`` is the arrow width and ``scale.z`` is the arrow height. - -* ``Start/End Points``: - - You can also specify a start/end point for the arrow, using the points member. - If you put points into the points member, it will assume you want to do things this way. - - * The point at index 0 is assumed to be the start point, and the point at index 1 is assumed to be the end. - * ``scale.x`` is the shaft diameter, and ``scale.y`` is the head diameter. - If ``scale.z`` is not zero, it specifies the head length. - -3.2 Cube (CUBE=1) -~~~~~~~~~~~~~~~~~ - -.. image:: images/CubeMarker.png - -Pivot point is at the center of the cube. - -3.3 Sphere (SPHERE=2) -~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/SphereMarker.png - -Pivot point is at the center of the sphere. - -``scale.x`` is diameter in x direction, ``scale.y`` in y direction, ``scale.z`` in z direction. -By setting these to different values you get an ellipsoid instead of a sphere. - -3.4 Cylinder (CYLINDER=3) -~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/CylinderMarker.png - -Pivot point is at the center of the cylinder. - -``scale.x`` is diameter in x direction, ``scale.y`` in y direction, by setting these to different values you get an ellipse instead of a circle. -Use ``scale.z`` to specify the height. - -3.5 Line Strip (LINE_STRIP=4) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/LineStripMarker.png - -Line strips use the points member of the `visualization_msgs/msg/Marker `_ message. -It will draw a line between every two consecutive points, so 0-1, 1-2, 2-3, 3-4, 4-5... - -Line strips also have some special handling for scale: only ``scale.x`` is used and it controls the width of the line segments. - -Note that ``pose`` is still used (the points in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. - -3.6 Line List (LINE_LIST=5) -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/LineListMarker.png - -Line lists use the points member of the `visualization_msgs/msg/Marker `_ message. -It will draw a line between each pair of points, so 0-1, 2-3, 4-5, ... - -Line lists also have some special handling for scale: only ``scale.x`` is used and it controls the width of the line segments. - -Note that ``pose`` is still used (the points in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. - -3.7 Cube List (CUBE_LIST=6) -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/CubeListMarker.png - -A cube list is a list of cubes with all the same properties except their positions. -Using this object type instead of a `visualization_msgs/msg/MarkerArray `_ allows RViz to batch-up rendering, -which causes them to render much faster. -The caveat is that they all must have the same scale. - -The ``points`` member of the `visualization_msgs/msg/Marker `_ message is used for the position of each cube. - -3.8 Sphere List (SPHERE_LIST=7) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/SphereListMarker.png - -A sphere list is a list of spheres with all the same properties except their positions. -Using this object type instead of a `visualization_msgs/msg/MarkerArray `_ allows RViz to batch-up rendering, -which causes them to render much faster. -The caveat is that they all must have the same scale. - -The ``points`` member of the `visualization_msgs/msg/Marker `_ message is used for the position of each sphere. - -Note that ``pose`` is still used (the ``points`` in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. - -3.9 Points (POINTS=8) -~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/PointsMarker.png - -Uses the ``points`` member of the `visualization_msgs/msg/Marker `_ message. - -``Points`` have some special handling for scale: ``scale.x`` is point width, ``scale.y`` is point height - -Note that ``pose`` is still used (the ``points`` in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. - -3.10 View-Oriented Text (TEXT_VIEW_FACING=9) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/text_view_facing_marker.png - -This marker displays text in a 3D spot in the world. -The text always appears oriented correctly for the RViZ user to see the included text. -Uses the ``text`` field in the marker. - -Only ``scale.z`` is used. -``scale.z`` specifies the height of an uppercase "A". - -3.11 Mesh Resource (MESH_RESOURCE=10) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/mesh_resource_marker.png - -Uses the ``mesh_resource`` field in the marker. -Can be any mesh type supported by RViz (binary ``.stl`` or Ogre ``.mesh`` in 1.0, with the addition of COLLADA (``.dae``) in 1.1). -The format is the URI-form used by `resource_retriever `_, including the ``package://`` syntax. - -An example of a mesh an its use is: - -.. code-block:: C++ - - marker.type = visualization_msgs::Marker::MESH_RESOURCE; - marker.mesh_resource = "package://pr2_description/meshes/base_v0/base.dae"; - -Scale on a mesh is relative. -A scale of (1.0, 1.0, 1.0) means the mesh will display as the exact size specified in the mesh file. -A scale of (1.0, 1.0, 2.0) means the mesh will show up twice as tall, but the same width/depth. - -If the ``mesh_use_embedded_materials`` flag is set to true and the mesh is of a type which supports embedded materials (such as COLLADA), -the material defined in that file will be used instead of the color defined in the marker. - -Since version [1.8], even when ``mesh_use_embedded_materials`` is true, -if the marker ``color`` is set to anything other than ``r=0``, ``g=0``, ``b=0``, ``a=0`` the marker ``color`` and ``alpha`` will be used to tint the mesh with the embedded material. - -3.12 Triangle List (TRIANGLE_LIST=11) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. image:: images/triangle_list_marker.png - -Uses the points and optionally colors members. -Every set of 3 points is treated as a triangle, so indices 0-1-2, 3-4-5, etc. - -Note that ``pose`` and ``scale`` are still used (the points in the line will be transformed by them), -and the lines will be correct relative to the ``frame id`` specified in the header. - -4 Rendering Complexity Notes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -A single marker is always less expensive to render than many markers. -For example, a single cube list can handle thousands of cubes, where we will not be able to render thousands of individual cube markers. +.. redirect-from:: + + Tutorials/Intermediate/RViz/Marker-Display-types/Marker-Display-types + +Marker: Display types +===================== + +**Goal:** This tutorial explains the basic Marker types and how to use them. + +**Tutorial level:** Intermediate + +**Time:** 15 Minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- +The Markers display allows programmatic addition of various primitive shapes to the 3D view by sending a +`visualization_msgs/msg/Marker `_ or +`visualization_msgs/msg/MarkerArray `_ message. + +.. image:: images/marker_overview.png + +Start with :doc:`Marker: Sending Basic Shapes <../Marker-Sending-Basic-Shapes/Marker-Sending-Basic-Shapes>` for a minimal publisher example that introduces the marker message used throughout this page. + +The Marker Message +------------------ +1 Example Usage (C++) +^^^^^^^^^^^^^^^^^^^^^ +First we will create a simple publisher node that publishes ``Marker`` messages from the ``visualization_messages`` package to the ``visualization_marker`` topic: + +.. code-block:: C++ + + auto marker_pub = node->create_publisher("visualization_marker", 1); + +After that it is as simple as filling out a `visualization_msgs/msg/Marker `_ +message and publishing it: + +.. code-block:: C++ + + visualization_msgs::msg::Marker marker; + + marker.header.frame_id = "/my_frame"; + marker.header.stamp = rclcpp::Clock().now(); + + marker.ns = "basic_shapes"; + marker.id = 0; + + marker.type = visualization_msgs::msg::Marker::SPHERE; + + marker.action = visualization_msgs::msg::Marker::ADD; + + marker.pose.position.x = 0; + marker.pose.position.y = 0; + marker.pose.position.z = 0; + marker.pose.orientation.x = 0.0; + marker.pose.orientation.y = 0.0; + marker.pose.orientation.z = 0.0; + marker.pose.orientation.w = 1.0; + + marker.scale.x = 1.0; + marker.scale.y = 1.0; + marker.scale.z = 1.0; + + marker.color.r = 0.0f; + marker.color.g = 1.0f; + marker.color.b = 0.0f; + marker.color.a = 1.0; // Don't forget to set the alpha! + + // only if using a MESH_RESOURCE marker type: + marker.mesh_resource = "package://pr2_description/meshes/base_v0/base.dae"; + + marker.lifetime = rclcpp::Duration::from_nanoseconds(0); + + marker_pub->publish(marker); + +There is also a `visualization_msgs/msg/MarkerArray `_ message, which lets you publish many markers at once. + +2 Message Parameters +^^^^^^^^^^^^^^^^^^^^ + +The Marker message type is defined in `ROS 2 Common Interfaces `_ package. +The messages in this package include comments that are helpful in understanding each of the fields in the message. + +* ``ns``: + + Namespace for these markers. + This plus the id form a unique identifier. + +* ``id``: + + Unique id assigned to this marker. + It is your responsibility to keep these unique within your namespace. + +* ``type``: + + Type of marker (Arrow, Sphere, ...). + The available types are specified in the message definition. + +* ``action``: + + 0 = add/modify, 1 = (deprecated), 2 = delete, 3 = deleteall + +* ``pose``: + + Pose marker, specified as x/y/z position and x/y/z/w quaternion orientation. + +* ``scale``: + + Scale of the marker. + Applied before the position/orientation. + A scale of [1, 1, 1] means the object will be 1m by 1m by 1m. + +* ``color``: + + Color of the object, specified as r/g/b/a, with values in the range of [0, 1]. + The, ``a`` or alpha value, denotes the opacity of the marker with 1 indicating opaque and 0 indicating completely transparent. + The default value is 0, or completely transparent. + **You must set the a value of your marker to a non-zero value or it will be transparent by default!** + +* ``points``: + + Only used for markers of type ``Points``, ``Line strips``, and ``Line`` / ``Cube`` / ``Sphere`` -lists. + It's also used for the Arrow type, if you want to specify the arrow start and end points. + This entry represents a list of ``geometry_msgs/Point`` types for the center or each marker object you would like rendered. + +* ``colors``: + + This field is only used for markers that use the points member. + This field specifies per-vertex color r/g/b/ color (no alpha yet) for each entry in ``points``. + +* ``lifetime``: + + A `duration message value <{interface_link(builtin_interfaces/msg/Duration)}>`_ used to automatically delete the marker after this period of time. + The countdown resets if another marker of the same ``namespace`` / ``id`` is received. + +* ``frame_locked``: + + Without the ``frame_locked`` parameter the marker will be placed based on the current transform and will stay there even if the given transform changes later. + Setting this parameter tells RViz to retransform the marker to the new current location of the specified frame on every update cycle. + +* ``text``: + + The text string used for the ``TEXT_VIEW_FACING`` marker type + +* ``mesh_resource``: + + The resource location for the ``MESH_RESOURCE`` marker type. + Can be any mesh type supported by RViz (``.stl`` or Ogre ``.mesh`` in 1.0, with the addition of COLLADA in 1.1). + The format is the URI-form used by `resource_retriever `_, including the package:// syntax. + +3 Object types +^^^^^^^^^^^^^^ + +.. _RVizMarkerObjectTypes: + +3.1 Arrow (ARROW=0) +~~~~~~~~~~~~~~~~~~~ + +.. image:: images/ArrowMarker.png + +The arrow type provides two different ways of specifying where the arrow should begin/end: + +* ``Position/Orientation``: + + Pivot point is around the tip of its tail. + Identity orientation points it along the +X axis. + ``scale.x`` is the arrow length, ``scale.y`` is the arrow width and ``scale.z`` is the arrow height. + +* ``Start/End Points``: + + You can also specify a start/end point for the arrow, using the points member. + If you put points into the points member, it will assume you want to do things this way. + + * The point at index 0 is assumed to be the start point, and the point at index 1 is assumed to be the end. + * ``scale.x`` is the shaft diameter, and ``scale.y`` is the head diameter. + If ``scale.z`` is not zero, it specifies the head length. + +3.2 Cube (CUBE=1) +~~~~~~~~~~~~~~~~~ + +.. image:: images/CubeMarker.png + +Pivot point is at the center of the cube. + +3.3 Sphere (SPHERE=2) +~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/SphereMarker.png + +Pivot point is at the center of the sphere. + +``scale.x`` is diameter in x direction, ``scale.y`` in y direction, ``scale.z`` in z direction. +By setting these to different values you get an ellipsoid instead of a sphere. + +3.4 Cylinder (CYLINDER=3) +~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/CylinderMarker.png + +Pivot point is at the center of the cylinder. + +``scale.x`` is diameter in x direction, ``scale.y`` in y direction, by setting these to different values you get an ellipse instead of a circle. +Use ``scale.z`` to specify the height. + +3.5 Line Strip (LINE_STRIP=4) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/LineStripMarker.png + +Line strips use the points member of the `visualization_msgs/msg/Marker `_ message. +It will draw a line between every two consecutive points, so 0-1, 1-2, 2-3, 3-4, 4-5... + +Line strips also have some special handling for scale: only ``scale.x`` is used and it controls the width of the line segments. + +Note that ``pose`` is still used (the points in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. + +3.6 Line List (LINE_LIST=5) +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/LineListMarker.png + +Line lists use the points member of the `visualization_msgs/msg/Marker `_ message. +It will draw a line between each pair of points, so 0-1, 2-3, 4-5, ... + +Line lists also have some special handling for scale: only ``scale.x`` is used and it controls the width of the line segments. + +Note that ``pose`` is still used (the points in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. + +3.7 Cube List (CUBE_LIST=6) +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/CubeListMarker.png + +A cube list is a list of cubes with all the same properties except their positions. +Using this object type instead of a `visualization_msgs/msg/MarkerArray `_ allows RViz to batch-up rendering, +which causes them to render much faster. +The caveat is that they all must have the same scale. + +The ``points`` member of the `visualization_msgs/msg/Marker `_ message is used for the position of each cube. + +3.8 Sphere List (SPHERE_LIST=7) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/SphereListMarker.png + +A sphere list is a list of spheres with all the same properties except their positions. +Using this object type instead of a `visualization_msgs/msg/MarkerArray `_ allows RViz to batch-up rendering, +which causes them to render much faster. +The caveat is that they all must have the same scale. + +The ``points`` member of the `visualization_msgs/msg/Marker `_ message is used for the position of each sphere. + +Note that ``pose`` is still used (the ``points`` in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. + +3.9 Points (POINTS=8) +~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/PointsMarker.png + +Uses the ``points`` member of the `visualization_msgs/msg/Marker `_ message. + +``Points`` have some special handling for scale: ``scale.x`` is point width, ``scale.y`` is point height + +Note that ``pose`` is still used (the ``points`` in the line will be transformed by them), and the lines will be correct relative to the ``frame id`` specified in the header. + +3.10 View-Oriented Text (TEXT_VIEW_FACING=9) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/text_view_facing_marker.png + +This marker displays text in a 3D spot in the world. +The text always appears oriented correctly for the RViZ user to see the included text. +Uses the ``text`` field in the marker. + +Only ``scale.z`` is used. +``scale.z`` specifies the height of an uppercase "A". + +3.11 Mesh Resource (MESH_RESOURCE=10) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/mesh_resource_marker.png + +Uses the ``mesh_resource`` field in the marker. +Can be any mesh type supported by RViz (binary ``.stl`` or Ogre ``.mesh`` in 1.0, with the addition of COLLADA (``.dae``) in 1.1). +The format is the URI-form used by `resource_retriever `_, including the ``package://`` syntax. + +An example of a mesh an its use is: + +.. code-block:: C++ + + marker.type = visualization_msgs::Marker::MESH_RESOURCE; + marker.mesh_resource = "package://pr2_description/meshes/base_v0/base.dae"; + +Scale on a mesh is relative. +A scale of (1.0, 1.0, 1.0) means the mesh will display as the exact size specified in the mesh file. +A scale of (1.0, 1.0, 2.0) means the mesh will show up twice as tall, but the same width/depth. + +If the ``mesh_use_embedded_materials`` flag is set to true and the mesh is of a type which supports embedded materials (such as COLLADA), +the material defined in that file will be used instead of the color defined in the marker. + +Since version [1.8], even when ``mesh_use_embedded_materials`` is true, +if the marker ``color`` is set to anything other than ``r=0``, ``g=0``, ``b=0``, ``a=0`` the marker ``color`` and ``alpha`` will be used to tint the mesh with the embedded material. + +3.12 Triangle List (TRIANGLE_LIST=11) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. image:: images/triangle_list_marker.png + +Uses the points and optionally colors members. +Every set of 3 points is treated as a triangle, so indices 0-1-2, 3-4-5, etc. + +Note that ``pose`` and ``scale`` are still used (the points in the line will be transformed by them), +and the lines will be correct relative to the ``frame id`` specified in the header. + +4 Rendering Complexity Notes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +A single marker is always less expensive to render than many markers. +For example, a single cube list can handle thousands of cubes, where we will not be able to render thousands of individual cube markers. \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst index 144ab98e7bc..4a2f3b1dd98 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst @@ -1,454 +1,458 @@ -Building a Custom RViz Display -============================== - -Background ----------- -There are many types of data that have existing visualizations in RViz. -However, if there is a message type that does -not yet have a plugin to display it, there are two choices to see it in RViz. - - 1. Convert the message to another type, such as ``visualization_msgs/Marker``. - 2. Write a Custom RViz Display. - -With the first option, there is more network traffic and limitations to how the data can be represented. -It is also quick and flexible. -The latter option is explained in this tutorial. -It takes a bit of work, but can lead to much richer visualizations. - -All of the code for this tutorial can be found in `this repository `__. -In order to see the incremental progress of the plugin written in this tutorial, -the repository has different branches (``step2``, ``step3``...) that can each be compiled and run as you go. - - -Point2D Message ---------------- - -We'll be playing with a toy message defined in the ``rviz_plugin_tutorial_msgs`` package: ``Point2D.msg``: - -.. code-block:: - - std_msgs/Header header - float64 x - float64 y - -Boilerplate for Basic Plugin ----------------------------- - -Strap in, there's a lot of code. -You can view the full version of this code with the branch name ``step1``. - -Header File -^^^^^^^^^^^ - -Here are the contents of ``point_display.hpp`` - -.. code-block:: c++ - - #ifndef RVIZ_PLUGIN_TUTORIAL__POINT_DISPLAY_HPP_ - #define RVIZ_PLUGIN_TUTORIAL__POINT_DISPLAY_HPP_ - - #include - #include - - namespace rviz_plugin_tutorial - { - class PointDisplay - : public rviz_common::MessageFilterDisplay - { - Q_OBJECT - - protected: - void processMessage(const rviz_plugin_tutorial_msgs::msg::Point2D::ConstSharedPtr msg) override; - }; - } // namespace rviz_plugin_tutorial - - #endif // RVIZ_PLUGIN_TUTORIAL__POINT_DISPLAY_HPP_ - -* We're implementing the `MessageFilterDisplay `__ class which can be used with any message with a ``std_msgs/Header``. -* The class is templated with our ``Point2D`` message type. -* `For reasons outside the scope of this tutorial `__, you need the ``Q_OBJECT`` macro in there to get the QT parts of the GUI to work. -* ``processMessage`` is the only method that needs to be implemented, which we'll do in the cpp file. - -Source File -^^^^^^^^^^^ - -``point_display.cpp`` - -.. code-block:: c++ - - #include - #include - - namespace rviz_plugin_tutorial - { - void PointDisplay::processMessage(const rviz_plugin_tutorial_msgs::msg::Point2D::ConstSharedPtr msg) - { - RVIZ_COMMON_LOG_INFO_STREAM("We got a message with frame " << msg->header.frame_id); - } - } // namespace rviz_plugin_tutorial - - #include - PLUGINLIB_EXPORT_CLASS(rviz_plugin_tutorial::PointDisplay, rviz_common::Display) - - -* The logging is not strictly necessary, but helps with debugging. -* In order for RViz to find our plugin, we need this ``PLUGINLIB`` invocation in our code (as well as other things below). - -package.xml -^^^^^^^^^^^ - -We need the following three dependencies in our package.xml: - -.. code-block:: xml - - pluginlib - rviz_common - rviz_plugin_tutorial_msgs - -rviz_common_plugins.xml -^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: xml - - - - - - - - -* This is standard ``pluginlib`` code. - - * The library ``path`` is the name of the library we'll assign in the CMake. - * The class should match the ``PLUGINLIB`` invocation from above. - -* We'll come back to the description later, I promise. - -CMakeLists.txt -^^^^^^^^^^^^^^ - -Add the following lines to the top of the standard boilerplate. - -.. code-block:: cmake - - find_package(ament_cmake_ros REQUIRED) - find_package(pluginlib REQUIRED) - find_package(rviz_common REQUIRED) - find_package(rviz_plugin_tutorial_msgs REQUIRED) - - set(CMAKE_AUTOMOC ON) - qt6_wrap_cpp(MOC_FILES - include/rviz_plugin_tutorial/point_display.hpp - ) - - add_library(point_display src/point_display.cpp ${MOC_FILES}) - target_include_directories(point_display PUBLIC - $ - $ - ) - target_link_libraries(point_display PUBLIC - pluginlib::pluginlib - rviz_common::rviz_common - rviz_plugin_tutorial_msgs::rviz_plugin_tutorial_msgs - ) - install(TARGETS point_display - EXPORT export_rviz_plugin_tutorial - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - install(DIRECTORY include/ - DESTINATION include - ) - install(FILES rviz_common_plugins.xml - DESTINATION share/${PROJECT_NAME} - ) - ament_export_include_directories(include) - ament_export_targets(export_rviz_plugin_tutorial) - pluginlib_export_plugin_description_file(rviz_common rviz_common_plugins.xml) - - -* To generate the proper Qt files, we need to - - * Turn ``CMAKE_AUTOMOC`` on. - * Wrap the headers by calling ``qt5_wrap_cpp`` with each header that has ``Q_OBJECT`` in it. - * Include the ``MOC_FILES`` in the library alongside our other cpp files. - -* Note that if you do NOT wrap your header files, you may get an error message when attempting to load the plugin at runtime, along the lines of: - - .. code-block:: - - [ERROR] [1746734178.883047840] [rviz2]: PluginlibFactory: The plugin for class 'Point2D' failed to load. Error: Failed to load library /root/ros2_ws/install/rviz_plugin_tutorial/lib/libpoint_display.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library dlopen error: /root/ros2_ws/install/rviz_plugin_tutorial/lib/libpoint_display.so: undefined symbol: _ZTVN20rviz_plugin_tutorial12PointDisplayE, at ./src/shared_library.c:96 - -* A lot of the other code ensures that the plugin portion works. - Namely, calling ``pluginlib_export_plugin_description_file`` is essential to getting RViz to find your new plugin. - -Testing it out -^^^^^^^^^^^^^^ - -Compile your code and run ``rviz2``. -You should be able to add your new plugin by clicking ``Add`` in the bottom left, and then selecting your package/plugin. - - -.. image:: images/Step1A.png - :target: ../../../../_images/Step1A.png - :alt: screenshot of adding display - - -Initially, the display will be in an error state because you have yet to assign a topic. - -.. image:: images/Step1B.png - :target: ../../../../_images/Step1B.png - :alt: screenshot of error state - - -If we put the topic ``/point`` in, it should load fine but not display anything. - -.. image:: images/Step1C.png - :target: ../../../../_images/Step1C.png - :alt: screenshot of functioning empty display - - -You can publish messages with the following command: - -.. code-block:: console - - $ ros2 topic pub /point rviz_plugin_tutorial_msgs/msg/Point2D "{header: {frame_id: map}, x: 1, y: 2}" -r 0.5 - -That should result in the "We got a message" logging to appear in the ``stdout`` of RViz. - -Actual Visualization --------------------- - -You can view the full version of this step with the branch name ``step2``. - -First, you need to add a dependency in ``CMakeLists.txt`` and ``package.xml`` on the package ``rviz_rendering``. - -We need to add three lines to the header file: - - -* ``#include `` - There's `lots of options in the rviz_rendering package `_ for objects to build your visualization on. - Here we're using a simple shape. -* In the class, we'll add a new ``protected`` virtual method: ``void onInitialize() override;`` -* We also add a pointer to our shape object: ``std::unique_ptr point_shape_;`` - -Then in the cpp file, we define the ``onInitialize`` method: - -.. code-block:: c++ - - void PointDisplay::onInitialize() - { - MFDClass::onInitialize(); - point_shape_ = - std::make_unique(rviz_rendering::Shape::Type::Cube, scene_manager_, - scene_node_); - } - - -* ``MFDClass`` is `aliased `_ to the templated parent class for convenience. -* The shape object must be constructed here in the ``onInitialize`` method rather than the constructor because otherwise ``scene_manager_`` and ``scene_node_`` would not be ready. - -We also update our ``processMessage`` method: - -.. code-block:: c++ - - void PointDisplay::processMessage(const rviz_plugin_tutorial_msgs::msg::Point2D::ConstSharedPtr msg) - { - RVIZ_COMMON_LOG_INFO_STREAM("We got a message with frame " << msg->header.frame_id); - - Ogre::Vector3 position; - Ogre::Quaternion orientation; - if (!context_->getFrameManager()->getTransform(msg->header, position, orientation)) { - RVIZ_COMMON_LOG_DEBUG_STREAM("Error transforming from frame '" << msg->header.frame_id << - "' to frame '" << qPrintable(fixed_frame_) << "'"); - } - - scene_node_->setPosition(position); - scene_node_->setOrientation(orientation); - - Ogre::Vector3 point_pos; - point_pos.x = msg->x; - point_pos.y = msg->y; - point_shape_->setPosition(point_pos); - } - - -* We need to get the proper frame for our message and transform the ``scene_node_`` accordingly. - This ensures that the visualization does not always appear relative to the fixed frame. -* The actual visualization that we've been building up to is in the last four lines: we set the position of the visualization to match the message's position. - -The result should look like this: - -.. image:: images/Step2A.png - :target: ../../../../_images/Step2A.png - :alt: screenshot of functioning display - - -If the box does not appear in that location, it might be because: - -* You are not publishing the topic at this time -* The message hasn't been published in the last 2 seconds. -* You did not properly set the topic in RViz. - -It's Nice to Have Options. --------------------------- - -If you want to allow users to customize different properties of the visualization, you need to add `rviz_common::Property objects `_. - -You can view the full version of this step with the branch name ``step3``. - -Header Updates -^^^^^^^^^^^^^^ - - - -Include the header file for color properties: ``#include ``. -Color is but one of many properties you can set. - -Add in the prototype for ``updateStyle``, which is called whenever the GUI is changed via Qt's SIGNAL/SLOT framework: - -.. code-block:: c++ - - private Q_SLOTS: - void updateStyle(); - -Add in a new property to store the property itself: ``std::unique_ptr color_property_;`` - -Cpp Updates -^^^^^^^^^^^ - - -* ``#include `` - Contains helper function to convert property to OGRE color. -* To our ``onInitialize`` we add - -.. code-block:: c++ - - color_property_ = std::make_unique( - "Point Color", QColor(36, 64, 142), "Color to draw the point.", this, SLOT(updateStyle())); - updateStyle(); - - -* This constructs the object with its name, default value, description and the callback. -* We call ``updateStyle`` directly so that the color is set at the beginning even before the property is changed. - -* Then we define the callback. - -.. code-block:: c++ - - void PointDisplay::updateStyle() - { - Ogre::ColourValue color = rviz_common::properties::qtToOgre(color_property_->getColor()); - point_shape_->setColor(color); - } - -The result should look like this: - -.. image:: images/Step3A.png - :target: ../../../../_images/Step3A.png - :alt: screenshot with color property - - -Ooh, pink! - -.. image:: images/Step3B.png - :target: ../../../../_images/Step3B.png - :alt: screenshot with changed color - - -Status Report -------------- - -You can view the full version of this step with the branch name ``step4``. - -You can also set the status of the display. -As an arbitrary example, let's make our display show a warning when the x coordinate is negative, because why not? -In ``processMessage``: - -.. code-block:: c++ - - if (msg->x < 0) { - setStatus(StatusProperty::Warn, "Message", - "I will complain about points with negative x values."); - } else { - setStatus(StatusProperty::Ok, "Message", "OK"); - } - - -* We're assuming a previous ``using rviz_common::properties::StatusProperty;`` declaration. -* Think of the status as Key/Value pairs, with the key being some string (here we're using ``"Message"``\ ) and the values are the status level (error/warn/ok) and the description (some other string). - - -.. image:: images/Step4A.png - :target: ../../../../_images/Step4A.png - :alt: screenshot with ok status - - - -.. image:: images/Step4B.png - :target: ../../../../_images/Step4B.png - :alt: screenshot with warning status - - -Cleanup -------- - -Now its time to clean it up a bit. -This makes things look nicer and be a little easier to use, but aren't strictly required. -You can view the full version of this step with the branch name ``step5``. - -First, we update the plugin declaration. - -.. code-block:: xml - - - - Tutorial to display a point - rviz_plugin_tutorial_msgs/msg/Point2D - - - - -* We add the ``name`` field to the ``class`` tag. - This changes the name that is displayed in RViz. - In code, it makes sense to call it a ``PointDisplay`` but in RViz, we want to simplify. -* We put actual text into the description. - Don't be lazy. -* By declaring the specific message type here, when you attempt to add a Display by Topic, it will suggest this plugin for the topics of that type. - -We also add an icon for the plugin at ``icons/classes/Point2D.png``. -The folder is hardcoded, and the filename should match the name from the plugin declaration (or the name of the class if not specified). -`[icon source] `_ - -We need to install the image file in the CMake. - -.. code-block:: cmake - - install(FILES icons/classes/Point2D.png - DESTINATION share/${PROJECT_NAME}/icons/classes - ) - -Now when you add the display, it should show up with an icon and description. - - -.. image:: images/Step5A.png - :target: ../../../../_images/Step5A.png - :alt: screenshot with added icon and description - - -Here is the display when attempting to add by topic: - - -.. image:: images/Step5B.png - :target: ../../../../_images/Step5B.png - :alt: screenshot with add by topic dialog - - -And finally, here's the icon in the standard interface: - - -.. image:: images/Step5C.png - :target: ../../../../_images/Step5C.png - :alt: screenshot with icon in standard interface - - -Note, if you change the plugins name, previous RViz configurations will no longer work. +.. redirect-from:: + + Tutorials/Intermediate/RViz/RViz-Custom-Display/RViz-Custom-Display + +Building a Custom RViz Display +============================== + +Background +---------- +There are many types of data that have existing visualizations in RViz. +However, if there is a message type that does +not yet have a plugin to display it, there are two choices to see it in RViz. + + 1. Convert the message to another type, such as ``visualization_msgs/Marker``. + 2. Write a Custom RViz Display. + +With the first option, there is more network traffic and limitations to how the data can be represented. +It is also quick and flexible. +The latter option is explained in this tutorial. +It takes a bit of work, but can lead to much richer visualizations. + +All of the code for this tutorial can be found in `this repository `__. +In order to see the incremental progress of the plugin written in this tutorial, +the repository has different branches (``step2``, ``step3``...) that can each be compiled and run as you go. + + +Point2D Message +--------------- + +We'll be playing with a toy message defined in the ``rviz_plugin_tutorial_msgs`` package: ``Point2D.msg``: + +.. code-block:: + + std_msgs/Header header + float64 x + float64 y + +Boilerplate for Basic Plugin +---------------------------- + +Strap in, there's a lot of code. +You can view the full version of this code with the branch name ``step1``. + +Header File +^^^^^^^^^^^ + +Here are the contents of ``point_display.hpp`` + +.. code-block:: c++ + + #ifndef RVIZ_PLUGIN_TUTORIAL__POINT_DISPLAY_HPP_ + #define RVIZ_PLUGIN_TUTORIAL__POINT_DISPLAY_HPP_ + + #include + #include + + namespace rviz_plugin_tutorial + { + class PointDisplay + : public rviz_common::MessageFilterDisplay + { + Q_OBJECT + + protected: + void processMessage(const rviz_plugin_tutorial_msgs::msg::Point2D::ConstSharedPtr msg) override; + }; + } // namespace rviz_plugin_tutorial + + #endif // RVIZ_PLUGIN_TUTORIAL__POINT_DISPLAY_HPP_ + +* We're implementing the `MessageFilterDisplay `__ class which can be used with any message with a ``std_msgs/Header``. +* The class is templated with our ``Point2D`` message type. +* `For reasons outside the scope of this tutorial `__, you need the ``Q_OBJECT`` macro in there to get the QT parts of the GUI to work. +* ``processMessage`` is the only method that needs to be implemented, which we'll do in the cpp file. + +Source File +^^^^^^^^^^^ + +``point_display.cpp`` + +.. code-block:: c++ + + #include + #include + + namespace rviz_plugin_tutorial + { + void PointDisplay::processMessage(const rviz_plugin_tutorial_msgs::msg::Point2D::ConstSharedPtr msg) + { + RVIZ_COMMON_LOG_INFO_STREAM("We got a message with frame " << msg->header.frame_id); + } + } // namespace rviz_plugin_tutorial + + #include + PLUGINLIB_EXPORT_CLASS(rviz_plugin_tutorial::PointDisplay, rviz_common::Display) + + +* The logging is not strictly necessary, but helps with debugging. +* In order for RViz to find our plugin, we need this ``PLUGINLIB`` invocation in our code (as well as other things below). + +package.xml +^^^^^^^^^^^ + +We need the following three dependencies in our package.xml: + +.. code-block:: xml + + pluginlib + rviz_common + rviz_plugin_tutorial_msgs + +rviz_common_plugins.xml +^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: xml + + + + + + + + +* This is standard ``pluginlib`` code. + + * The library ``path`` is the name of the library we'll assign in the CMake. + * The class should match the ``PLUGINLIB`` invocation from above. + +* We'll come back to the description later, I promise. + +CMakeLists.txt +^^^^^^^^^^^^^^ + +Add the following lines to the top of the standard boilerplate. + +.. code-block:: cmake + + find_package(ament_cmake_ros REQUIRED) + find_package(pluginlib REQUIRED) + find_package(rviz_common REQUIRED) + find_package(rviz_plugin_tutorial_msgs REQUIRED) + + set(CMAKE_AUTOMOC ON) + qt6_wrap_cpp(MOC_FILES + include/rviz_plugin_tutorial/point_display.hpp + ) + + add_library(point_display src/point_display.cpp ${MOC_FILES}) + target_include_directories(point_display PUBLIC + $ + $ + ) + target_link_libraries(point_display PUBLIC + pluginlib::pluginlib + rviz_common::rviz_common + rviz_plugin_tutorial_msgs::rviz_plugin_tutorial_msgs + ) + install(TARGETS point_display + EXPORT export_rviz_plugin_tutorial + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + install(DIRECTORY include/ + DESTINATION include + ) + install(FILES rviz_common_plugins.xml + DESTINATION share/${PROJECT_NAME} + ) + ament_export_include_directories(include) + ament_export_targets(export_rviz_plugin_tutorial) + pluginlib_export_plugin_description_file(rviz_common rviz_common_plugins.xml) + + +* To generate the proper Qt files, we need to + + * Turn ``CMAKE_AUTOMOC`` on. + * Wrap the headers by calling ``qt5_wrap_cpp`` with each header that has ``Q_OBJECT`` in it. + * Include the ``MOC_FILES`` in the library alongside our other cpp files. + +* Note that if you do NOT wrap your header files, you may get an error message when attempting to load the plugin at runtime, along the lines of: + + .. code-block:: + + [ERROR] [1746734178.883047840] [rviz2]: PluginlibFactory: The plugin for class 'Point2D' failed to load. Error: Failed to load library /root/ros2_ws/install/rviz_plugin_tutorial/lib/libpoint_display.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library dlopen error: /root/ros2_ws/install/rviz_plugin_tutorial/lib/libpoint_display.so: undefined symbol: _ZTVN20rviz_plugin_tutorial12PointDisplayE, at ./src/shared_library.c:96 + +* A lot of the other code ensures that the plugin portion works. + Namely, calling ``pluginlib_export_plugin_description_file`` is essential to getting RViz to find your new plugin. + +Testing it out +^^^^^^^^^^^^^^ + +Compile your code and run ``rviz2``. +You should be able to add your new plugin by clicking ``Add`` in the bottom left, and then selecting your package/plugin. + + +.. image:: images/Step1A.png + :target: ../../../../_images/Step1A.png + :alt: screenshot of adding display + + +Initially, the display will be in an error state because you have yet to assign a topic. + +.. image:: images/Step1B.png + :target: ../../../../_images/Step1B.png + :alt: screenshot of error state + + +If we put the topic ``/point`` in, it should load fine but not display anything. + +.. image:: images/Step1C.png + :target: ../../../../_images/Step1C.png + :alt: screenshot of functioning empty display + + +You can publish messages with the following command: + +.. code-block:: console + + $ ros2 topic pub /point rviz_plugin_tutorial_msgs/msg/Point2D "{header: {frame_id: map}, x: 1, y: 2}" -r 0.5 + +That should result in the "We got a message" logging to appear in the ``stdout`` of RViz. + +Actual Visualization +-------------------- + +You can view the full version of this step with the branch name ``step2``. + +First, you need to add a dependency in ``CMakeLists.txt`` and ``package.xml`` on the package ``rviz_rendering``. + +We need to add three lines to the header file: + + +* ``#include `` - There's `lots of options in the rviz_rendering package `_ for objects to build your visualization on. + Here we're using a simple shape. +* In the class, we'll add a new ``protected`` virtual method: ``void onInitialize() override;`` +* We also add a pointer to our shape object: ``std::unique_ptr point_shape_;`` + +Then in the cpp file, we define the ``onInitialize`` method: + +.. code-block:: c++ + + void PointDisplay::onInitialize() + { + MFDClass::onInitialize(); + point_shape_ = + std::make_unique(rviz_rendering::Shape::Type::Cube, scene_manager_, + scene_node_); + } + + +* ``MFDClass`` is `aliased `_ to the templated parent class for convenience. +* The shape object must be constructed here in the ``onInitialize`` method rather than the constructor because otherwise ``scene_manager_`` and ``scene_node_`` would not be ready. + +We also update our ``processMessage`` method: + +.. code-block:: c++ + + void PointDisplay::processMessage(const rviz_plugin_tutorial_msgs::msg::Point2D::ConstSharedPtr msg) + { + RVIZ_COMMON_LOG_INFO_STREAM("We got a message with frame " << msg->header.frame_id); + + Ogre::Vector3 position; + Ogre::Quaternion orientation; + if (!context_->getFrameManager()->getTransform(msg->header, position, orientation)) { + RVIZ_COMMON_LOG_DEBUG_STREAM("Error transforming from frame '" << msg->header.frame_id << + "' to frame '" << qPrintable(fixed_frame_) << "'"); + } + + scene_node_->setPosition(position); + scene_node_->setOrientation(orientation); + + Ogre::Vector3 point_pos; + point_pos.x = msg->x; + point_pos.y = msg->y; + point_shape_->setPosition(point_pos); + } + + +* We need to get the proper frame for our message and transform the ``scene_node_`` accordingly. + This ensures that the visualization does not always appear relative to the fixed frame. +* The actual visualization that we've been building up to is in the last four lines: we set the position of the visualization to match the message's position. + +The result should look like this: + +.. image:: images/Step2A.png + :target: ../../../../_images/Step2A.png + :alt: screenshot of functioning display + + +If the box does not appear in that location, it might be because: + +* You are not publishing the topic at this time +* The message hasn't been published in the last 2 seconds. +* You did not properly set the topic in RViz. + +It's Nice to Have Options. +-------------------------- + +If you want to allow users to customize different properties of the visualization, you need to add `rviz_common::Property objects `_. + +You can view the full version of this step with the branch name ``step3``. + +Header Updates +^^^^^^^^^^^^^^ + + + +Include the header file for color properties: ``#include ``. +Color is but one of many properties you can set. + +Add in the prototype for ``updateStyle``, which is called whenever the GUI is changed via Qt's SIGNAL/SLOT framework: + +.. code-block:: c++ + + private Q_SLOTS: + void updateStyle(); + +Add in a new property to store the property itself: ``std::unique_ptr color_property_;`` + +Cpp Updates +^^^^^^^^^^^ + + +* ``#include `` - Contains helper function to convert property to OGRE color. +* To our ``onInitialize`` we add + +.. code-block:: c++ + + color_property_ = std::make_unique( + "Point Color", QColor(36, 64, 142), "Color to draw the point.", this, SLOT(updateStyle())); + updateStyle(); + + +* This constructs the object with its name, default value, description and the callback. +* We call ``updateStyle`` directly so that the color is set at the beginning even before the property is changed. + +* Then we define the callback. + +.. code-block:: c++ + + void PointDisplay::updateStyle() + { + Ogre::ColourValue color = rviz_common::properties::qtToOgre(color_property_->getColor()); + point_shape_->setColor(color); + } + +The result should look like this: + +.. image:: images/Step3A.png + :target: ../../../../_images/Step3A.png + :alt: screenshot with color property + + +Ooh, pink! + +.. image:: images/Step3B.png + :target: ../../../../_images/Step3B.png + :alt: screenshot with changed color + + +Status Report +------------- + +You can view the full version of this step with the branch name ``step4``. + +You can also set the status of the display. +As an arbitrary example, let's make our display show a warning when the x coordinate is negative, because why not? +In ``processMessage``: + +.. code-block:: c++ + + if (msg->x < 0) { + setStatus(StatusProperty::Warn, "Message", + "I will complain about points with negative x values."); + } else { + setStatus(StatusProperty::Ok, "Message", "OK"); + } + + +* We're assuming a previous ``using rviz_common::properties::StatusProperty;`` declaration. +* Think of the status as Key/Value pairs, with the key being some string (here we're using ``"Message"``\ ) and the values are the status level (error/warn/ok) and the description (some other string). + + +.. image:: images/Step4A.png + :target: ../../../../_images/Step4A.png + :alt: screenshot with ok status + + + +.. image:: images/Step4B.png + :target: ../../../../_images/Step4B.png + :alt: screenshot with warning status + + +Cleanup +------- + +Now its time to clean it up a bit. +This makes things look nicer and be a little easier to use, but aren't strictly required. +You can view the full version of this step with the branch name ``step5``. + +First, we update the plugin declaration. + +.. code-block:: xml + + + + Tutorial to display a point + rviz_plugin_tutorial_msgs/msg/Point2D + + + + +* We add the ``name`` field to the ``class`` tag. + This changes the name that is displayed in RViz. + In code, it makes sense to call it a ``PointDisplay`` but in RViz, we want to simplify. +* We put actual text into the description. + Don't be lazy. +* By declaring the specific message type here, when you attempt to add a Display by Topic, it will suggest this plugin for the topics of that type. + +We also add an icon for the plugin at ``icons/classes/Point2D.png``. +The folder is hardcoded, and the filename should match the name from the plugin declaration (or the name of the class if not specified). +`[icon source] `_ + +We need to install the image file in the CMake. + +.. code-block:: cmake + + install(FILES icons/classes/Point2D.png + DESTINATION share/${PROJECT_NAME}/icons/classes + ) + +Now when you add the display, it should show up with an icon and description. + + +.. image:: images/Step5A.png + :target: ../../../../_images/Step5A.png + :alt: screenshot with added icon and description + + +Here is the display when attempting to add by topic: + + +.. image:: images/Step5B.png + :target: ../../../../_images/Step5B.png + :alt: screenshot with add by topic dialog + + +And finally, here's the icon in the standard interface: + + +.. image:: images/Step5C.png + :target: ../../../../_images/Step5C.png + :alt: screenshot with icon in standard interface + + +Note, if you change the plugins name, previous RViz configurations will no longer work. \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst index 6d8f1cd58a7..1d5b305c420 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst @@ -1,352 +1,356 @@ -Building a Custom RViz Panel -============================ - -This tutorial is for people who would like to work within the RViz environment to either display or interact with some data in a two-dimensional environment. - -In this tutorial you will learn how to do three things within RViz: - -* Create a new QT panel within RViz. -* Create a topic subscriber within RViz that can monitor messages published on that topic and display them within the RViz panel. -* Create a topic publisher such button presses within RViz publish to an output topic in ROS. - -All of the code for this tutorial can be found in `this repository `__. - -Boilerplate Code ----------------- - -Header File -^^^^^^^^^^^ - -Here are the contents of ``demo_panel.hpp`` - -.. code-block:: c++ - - #ifndef RVIZ_PANEL_TUTORIAL__DEMO_PANEL_HPP_ - #define RVIZ_PANEL_TUTORIAL__DEMO_PANEL_HPP_ - - #include - - namespace rviz_panel_tutorial - { - class DemoPanel - : public rviz_common::Panel - { - Q_OBJECT - public: - explicit DemoPanel(QWidget * parent = 0); - ~DemoPanel() override; - }; - } // namespace rviz_panel_tutorial - - #endif // RVIZ_PANEL_TUTORIAL__DEMO_PANEL_HPP_ - -* We're extending the `rviz_common::Panel `__ class. -* `For reasons outside the scope of this tutorial `__, you need the ``Q_OBJECT`` macro in there to get the QT parts of the GUI to work. -* We start by declaring just a constructor and destructor, implemented in the cpp file. - -Source File -^^^^^^^^^^^ - -``demo_panel.cpp`` - -.. code-block:: c++ - - #include - - namespace rviz_panel_tutorial - { - DemoPanel::DemoPanel(QWidget* parent) : Panel(parent) - { - } - - DemoPanel::~DemoPanel() = default; - } // namespace rviz_panel_tutorial - - #include - PLUGINLIB_EXPORT_CLASS(rviz_panel_tutorial::DemoPanel, rviz_common::Panel) - -* Overriding the constructor and deconstructor are not strictly necessary, but we can do more with them later. -* In order for RViz to find our plugin, we need this ``PLUGINLIB`` invocation in our code (as well as other things below). - -package.xml -^^^^^^^^^^^ - -We need the following dependencies in our package.xml: - -.. code-block:: xml - - pluginlib - rviz_common - -rviz_common_plugins.xml -^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: xml - - - - - - - -* This is standard ``pluginlib`` code. - - * The library ``path`` is the name of the library we'll assign in the CMake. - * The class should match the ``PLUGINLIB`` invocation from above. - -* We'll come back to the description later, I promise. - -CMakeLists.txt -^^^^^^^^^^^^^^ - -Add the following lines to the top of the standard boilerplate. - -.. code-block:: cmake - - find_package(ament_cmake_ros REQUIRED) - find_package(pluginlib REQUIRED) - find_package(rviz_common REQUIRED) - - set(CMAKE_AUTOMOC ON) - qt5_wrap_cpp(MOC_FILES - include/rviz_panel_tutorial/demo_panel.hpp - ) - - add_library(demo_panel src/demo_panel.cpp ${MOC_FILES}) - target_include_directories(demo_panel PUBLIC - $ - $ - ) - target_link_libraries(demo_panel PUBLIC - pluginlib::pluginlib - rviz_common::rviz_common - ) - install(TARGETS demo_panel - EXPORT export_rviz_panel_tutorial - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - install(DIRECTORY include/ - DESTINATION include - ) - install(FILES rviz_common_plugins.xml - DESTINATION share/${PROJECT_NAME} - ) - ament_export_include_directories(include) - ament_export_targets(export_rviz_panel_tutorial) - pluginlib_export_plugin_description_file(rviz_common rviz_common_plugins.xml) - - -* To generate the proper Qt files, we need to - - * Turn ``CMAKE_AUTOMOC`` on. - * Wrap the headers by calling ``qt5_wrap_cpp`` with each header that has ``Q_OBJECT`` in it. - * Include the ``MOC_FILES`` in the library alongside our other cpp files. - -* A lot of the other code ensures that the plugin portion works. - Namely, calling ``pluginlib_export_plugin_description_file`` is essential to getting RViz to find your new plugin. - -Testing it out -^^^^^^^^^^^^^^ - -Compile your code, source your workspace and run ``rviz2``. - -In the top Menu bar, there should be a "Panels" menu. -Select "Add New Panel" from that menu. - -.. image:: images/Select0.png - :target: ../../../../_images/Select0.png - :alt: screenshot of Add New Panel dialog - -A dialog will pop up showing all the panels accessible in your ROS environment, grouped into folders based on their ROS package. -Create a new instance of your panel by either double clicking on its name, or selecting it and clicking OK. - -This should create a new panel in your RViz window, albeit with nothing but a title bar with the name of your panel. - -.. image:: images/RViz0.png - :target: ../../../../_images/RViz0.png - :alt: screenshot of the whole RViz window showing the new simple panel - -Filling in the Panel --------------------- -We're going to update our panel with some very basic ROS/QT interaction. -What we will do, roughly, is access the ROS node from within RViz that can both subscribe and publish to ROS topics. -We will use our subscriber to monitor an ``/input`` topic within ROS and display the published ``String`` values in the widget. -We use our publisher to map button presses within RViz to messages published on a ROS topic named ``/output`` . - -Updated Header File -^^^^^^^^^^^^^^^^^^^ - -Update ``demo_panel.hpp`` to include the following includes and class Body. - -.. code-block:: c++ - - #include - #include - #include - #include - #include - - namespace rviz_panel_tutorial - { - class DemoPanel : public rviz_common::Panel - { - Q_OBJECT - public: - explicit DemoPanel(QWidget * parent = 0); - ~DemoPanel() override; - - void onInitialize() override; - - protected: - std::shared_ptr node_ptr_; - rclcpp::Publisher::SharedPtr publisher_; - rclcpp::Subscription::SharedPtr subscription_; - - void topicCallback(const std_msgs::msg::String & msg); - - QLabel* label_; - QPushButton* button_; - - private Q_SLOTS: - void buttonActivated(); - }; - } // namespace rviz_panel_tutorial - -* On the ROS side, we declare an abstract node pointer, which we will use to create interfaces to the wider ROS ecosystem. - We have a subscriber which will allow us to take information from ROS and use it in RViz. - The publisher allows us to publish information/events from within RViz and make them available in ROS. - We also have methods an initialization method for setting up the ROS components (``onInitialize``) and a callback for the subscriber (``topicCallback``). -* On the QT side, we declare a label and a button, as well as a callback for the button (``buttonActivated``). - -Updated Source File -^^^^^^^^^^^^^^^^^^^ - -Update ``demo_panel.cpp`` to have the following contents: - -.. code-block:: c++ - - #include - #include - #include - - namespace rviz_panel_tutorial - { - - DemoPanel::DemoPanel(QWidget* parent) : Panel(parent) - { - // Create a label and a button, displayed vertically (the V in VBox means vertical) - const auto layout = new QVBoxLayout(this); - // Create a button and a label for the button - label_ = new QLabel("[no data]"); - button_ = new QPushButton("GO!"); - // Add those elements to the GUI layout - layout->addWidget(label_); - layout->addWidget(button_); - - // Connect the event of when the button is released to our callback, - // so pressing the button results in the buttonActivated callback being called. - QObject::connect(button_, &QPushButton::released, this, &DemoPanel::buttonActivated); - } - - DemoPanel::~DemoPanel() = default; - - void DemoPanel::onInitialize() - { - // Access the abstract ROS Node and - // in the process lock it for exclusive use until the method is done. - node_ptr_ = getDisplayContext()->getRosNodeAbstraction().lock(); - - // Get a pointer to the familiar rclcpp::Node for making subscriptions/publishers - // (as per normal rclcpp code) - rclcpp::Node::SharedPtr node = node_ptr_->get_raw_node(); - - // Create a String publisher for the output - publisher_ = node->create_publisher("/output", 10); - - // Create a String subscription and bind it to the topicCallback inside this class. - subscription_ = node->create_subscription("/input", 10, std::bind(&DemoPanel::topicCallback, this, std::placeholders::_1)); - } - - // When the subscriber gets a message, this callback is triggered, - // and then we copy its data into the widget's label - void DemoPanel::topicCallback(const std_msgs::msg::String & msg) - { - label_->setText(QString(msg.data.c_str())); - } - - // When the widget's button is pressed, this callback is triggered, - // and then we publish a new message on our topic. - void DemoPanel::buttonActivated() - { - auto message = std_msgs::msg::String(); - message.data = "Button clicked!"; - publisher_->publish(message); - } - - } // namespace rviz_panel_tutorial - - #include - - PLUGINLIB_EXPORT_CLASS(rviz_panel_tutorial::DemoPanel, rviz_common::Panel) - -Testing with ROS -^^^^^^^^^^^^^^^^ -Compile and launch RViz2 with your panel again. -You should see your label and button in the panel now. - -.. image:: images/RViz1.png - :target: ../../../../_images/RViz1.png - :alt: screenshot of the RViz panel in its default state - -To change the label, we simply have to publish a message on the ``/input`` topic, which you can do with this command: - -.. code-block:: console - - $ ros2 topic pub /input std_msgs/msg/String "{data: 'Please be kind.'}" - -Since the widget is subscribed to this topic, it will trigger the callback and change the text of the label. - -.. image:: images/RViz2.png - :target: ../../../../_images/RViz2.png - :alt: screenshot of the RViz panel with custom string message displayed - - -Pressing the button will publish a message, which you can see by echoing the ``/output`` topic, like with this command. - -.. code-block:: console - - $ ros2 topic echo /output - - -Cleanup -------- - -Now its time to clean it up a bit. -This makes things look nicer and be a little easier to use, but aren't strictly required. - -First, you should update the description of your plugin in ``rviz_common_plugins.xml`` - -We also add an icon for the plugin at ``icons/classes/DemoPanel.png``. -The folder is hardcoded, and the filename should match the name from the plugin declaration (or the name of the class if not specified). - -We need to install the image file in the CMake. - -.. code-block:: cmake - - install(FILES icons/classes/DemoPanel.png - DESTINATION share/${PROJECT_NAME}/icons/classes - ) - -Now when you add the panel, it should show up with an icon and description. - -.. image:: images/Select1.png - :target: ../../../../_images/Select1.png - :alt: screenshot of Add New Panel dialog with our custom icon and description - -The panel will also have an updated icon. - -.. image:: images/RViz3.png - :target: ../../../../_images/RViz3.png - :alt: screenshot of the RViz panel with custom icon +.. redirect-from:: + + Tutorials/Intermediate/RViz/RViz-Custom-Panel/RViz-Custom-Panel + +Building a Custom RViz Panel +============================ + +This tutorial is for people who would like to work within the RViz environment to either display or interact with some data in a two-dimensional environment. + +In this tutorial you will learn how to do three things within RViz: + +* Create a new QT panel within RViz. +* Create a topic subscriber within RViz that can monitor messages published on that topic and display them within the RViz panel. +* Create a topic publisher such button presses within RViz publish to an output topic in ROS. + +All of the code for this tutorial can be found in `this repository `__. + +Boilerplate Code +---------------- + +Header File +^^^^^^^^^^^ + +Here are the contents of ``demo_panel.hpp`` + +.. code-block:: c++ + + #ifndef RVIZ_PANEL_TUTORIAL__DEMO_PANEL_HPP_ + #define RVIZ_PANEL_TUTORIAL__DEMO_PANEL_HPP_ + + #include + + namespace rviz_panel_tutorial + { + class DemoPanel + : public rviz_common::Panel + { + Q_OBJECT + public: + explicit DemoPanel(QWidget * parent = 0); + ~DemoPanel() override; + }; + } // namespace rviz_panel_tutorial + + #endif // RVIZ_PANEL_TUTORIAL__DEMO_PANEL_HPP_ + +* We're extending the `rviz_common::Panel `__ class. +* `For reasons outside the scope of this tutorial `__, you need the ``Q_OBJECT`` macro in there to get the QT parts of the GUI to work. +* We start by declaring just a constructor and destructor, implemented in the cpp file. + +Source File +^^^^^^^^^^^ + +``demo_panel.cpp`` + +.. code-block:: c++ + + #include + + namespace rviz_panel_tutorial + { + DemoPanel::DemoPanel(QWidget* parent) : Panel(parent) + { + } + + DemoPanel::~DemoPanel() = default; + } // namespace rviz_panel_tutorial + + #include + PLUGINLIB_EXPORT_CLASS(rviz_panel_tutorial::DemoPanel, rviz_common::Panel) + +* Overriding the constructor and deconstructor are not strictly necessary, but we can do more with them later. +* In order for RViz to find our plugin, we need this ``PLUGINLIB`` invocation in our code (as well as other things below). + +package.xml +^^^^^^^^^^^ + +We need the following dependencies in our package.xml: + +.. code-block:: xml + + pluginlib + rviz_common + +rviz_common_plugins.xml +^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: xml + + + + + + + +* This is standard ``pluginlib`` code. + + * The library ``path`` is the name of the library we'll assign in the CMake. + * The class should match the ``PLUGINLIB`` invocation from above. + +* We'll come back to the description later, I promise. + +CMakeLists.txt +^^^^^^^^^^^^^^ + +Add the following lines to the top of the standard boilerplate. + +.. code-block:: cmake + + find_package(ament_cmake_ros REQUIRED) + find_package(pluginlib REQUIRED) + find_package(rviz_common REQUIRED) + + set(CMAKE_AUTOMOC ON) + qt5_wrap_cpp(MOC_FILES + include/rviz_panel_tutorial/demo_panel.hpp + ) + + add_library(demo_panel src/demo_panel.cpp ${MOC_FILES}) + target_include_directories(demo_panel PUBLIC + $ + $ + ) + target_link_libraries(demo_panel PUBLIC + pluginlib::pluginlib + rviz_common::rviz_common + ) + install(TARGETS demo_panel + EXPORT export_rviz_panel_tutorial + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + install(DIRECTORY include/ + DESTINATION include + ) + install(FILES rviz_common_plugins.xml + DESTINATION share/${PROJECT_NAME} + ) + ament_export_include_directories(include) + ament_export_targets(export_rviz_panel_tutorial) + pluginlib_export_plugin_description_file(rviz_common rviz_common_plugins.xml) + + +* To generate the proper Qt files, we need to + + * Turn ``CMAKE_AUTOMOC`` on. + * Wrap the headers by calling ``qt5_wrap_cpp`` with each header that has ``Q_OBJECT`` in it. + * Include the ``MOC_FILES`` in the library alongside our other cpp files. + +* A lot of the other code ensures that the plugin portion works. + Namely, calling ``pluginlib_export_plugin_description_file`` is essential to getting RViz to find your new plugin. + +Testing it out +^^^^^^^^^^^^^^ + +Compile your code, source your workspace and run ``rviz2``. + +In the top Menu bar, there should be a "Panels" menu. +Select "Add New Panel" from that menu. + +.. image:: images/Select0.png + :target: ../../../../_images/Select0.png + :alt: screenshot of Add New Panel dialog + +A dialog will pop up showing all the panels accessible in your ROS environment, grouped into folders based on their ROS package. +Create a new instance of your panel by either double clicking on its name, or selecting it and clicking OK. + +This should create a new panel in your RViz window, albeit with nothing but a title bar with the name of your panel. + +.. image:: images/RViz0.png + :target: ../../../../_images/RViz0.png + :alt: screenshot of the whole RViz window showing the new simple panel + +Filling in the Panel +-------------------- +We're going to update our panel with some very basic ROS/QT interaction. +What we will do, roughly, is access the ROS node from within RViz that can both subscribe and publish to ROS topics. +We will use our subscriber to monitor an ``/input`` topic within ROS and display the published ``String`` values in the widget. +We use our publisher to map button presses within RViz to messages published on a ROS topic named ``/output`` . + +Updated Header File +^^^^^^^^^^^^^^^^^^^ + +Update ``demo_panel.hpp`` to include the following includes and class Body. + +.. code-block:: c++ + + #include + #include + #include + #include + #include + + namespace rviz_panel_tutorial + { + class DemoPanel : public rviz_common::Panel + { + Q_OBJECT + public: + explicit DemoPanel(QWidget * parent = 0); + ~DemoPanel() override; + + void onInitialize() override; + + protected: + std::shared_ptr node_ptr_; + rclcpp::Publisher::SharedPtr publisher_; + rclcpp::Subscription::SharedPtr subscription_; + + void topicCallback(const std_msgs::msg::String & msg); + + QLabel* label_; + QPushButton* button_; + + private Q_SLOTS: + void buttonActivated(); + }; + } // namespace rviz_panel_tutorial + +* On the ROS side, we declare an abstract node pointer, which we will use to create interfaces to the wider ROS ecosystem. + We have a subscriber which will allow us to take information from ROS and use it in RViz. + The publisher allows us to publish information/events from within RViz and make them available in ROS. + We also have methods an initialization method for setting up the ROS components (``onInitialize``) and a callback for the subscriber (``topicCallback``). +* On the QT side, we declare a label and a button, as well as a callback for the button (``buttonActivated``). + +Updated Source File +^^^^^^^^^^^^^^^^^^^ + +Update ``demo_panel.cpp`` to have the following contents: + +.. code-block:: c++ + + #include + #include + #include + + namespace rviz_panel_tutorial + { + + DemoPanel::DemoPanel(QWidget* parent) : Panel(parent) + { + // Create a label and a button, displayed vertically (the V in VBox means vertical) + const auto layout = new QVBoxLayout(this); + // Create a button and a label for the button + label_ = new QLabel("[no data]"); + button_ = new QPushButton("GO!"); + // Add those elements to the GUI layout + layout->addWidget(label_); + layout->addWidget(button_); + + // Connect the event of when the button is released to our callback, + // so pressing the button results in the buttonActivated callback being called. + QObject::connect(button_, &QPushButton::released, this, &DemoPanel::buttonActivated); + } + + DemoPanel::~DemoPanel() = default; + + void DemoPanel::onInitialize() + { + // Access the abstract ROS Node and + // in the process lock it for exclusive use until the method is done. + node_ptr_ = getDisplayContext()->getRosNodeAbstraction().lock(); + + // Get a pointer to the familiar rclcpp::Node for making subscriptions/publishers + // (as per normal rclcpp code) + rclcpp::Node::SharedPtr node = node_ptr_->get_raw_node(); + + // Create a String publisher for the output + publisher_ = node->create_publisher("/output", 10); + + // Create a String subscription and bind it to the topicCallback inside this class. + subscription_ = node->create_subscription("/input", 10, std::bind(&DemoPanel::topicCallback, this, std::placeholders::_1)); + } + + // When the subscriber gets a message, this callback is triggered, + // and then we copy its data into the widget's label + void DemoPanel::topicCallback(const std_msgs::msg::String & msg) + { + label_->setText(QString(msg.data.c_str())); + } + + // When the widget's button is pressed, this callback is triggered, + // and then we publish a new message on our topic. + void DemoPanel::buttonActivated() + { + auto message = std_msgs::msg::String(); + message.data = "Button clicked!"; + publisher_->publish(message); + } + + } // namespace rviz_panel_tutorial + + #include + + PLUGINLIB_EXPORT_CLASS(rviz_panel_tutorial::DemoPanel, rviz_common::Panel) + +Testing with ROS +^^^^^^^^^^^^^^^^ +Compile and launch RViz2 with your panel again. +You should see your label and button in the panel now. + +.. image:: images/RViz1.png + :target: ../../../../_images/RViz1.png + :alt: screenshot of the RViz panel in its default state + +To change the label, we simply have to publish a message on the ``/input`` topic, which you can do with this command: + +.. code-block:: console + + $ ros2 topic pub /input std_msgs/msg/String "{data: 'Please be kind.'}" + +Since the widget is subscribed to this topic, it will trigger the callback and change the text of the label. + +.. image:: images/RViz2.png + :target: ../../../../_images/RViz2.png + :alt: screenshot of the RViz panel with custom string message displayed + + +Pressing the button will publish a message, which you can see by echoing the ``/output`` topic, like with this command. + +.. code-block:: console + + $ ros2 topic echo /output + + +Cleanup +------- + +Now its time to clean it up a bit. +This makes things look nicer and be a little easier to use, but aren't strictly required. + +First, you should update the description of your plugin in ``rviz_common_plugins.xml`` + +We also add an icon for the plugin at ``icons/classes/DemoPanel.png``. +The folder is hardcoded, and the filename should match the name from the plugin declaration (or the name of the class if not specified). + +We need to install the image file in the CMake. + +.. code-block:: cmake + + install(FILES icons/classes/DemoPanel.png + DESTINATION share/${PROJECT_NAME}/icons/classes + ) + +Now when you add the panel, it should show up with an icon and description. + +.. image:: images/Select1.png + :target: ../../../../_images/Select1.png + :alt: screenshot of Add New Panel dialog with our custom icon and description + +The panel will also have an updated icon. + +.. image:: images/RViz3.png + :target: ../../../../_images/RViz3.png + :alt: screenshot of the RViz panel with custom icon \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/RViz/RViz-Main.rst b/source/Developer-Tools/Visualization/RViz/RViz-Main.rst index 5336842cbe1..6f4129ea743 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-Main.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-Main.rst @@ -1,18 +1,22 @@ -RViz -==== - -RViz is a 3D visualizer for the Robot Operating System (ROS) framework. - -.. contents:: Contents - :depth: 0 - :local: - -.. toctree:: - :maxdepth: 1 - - RViz-User-Guide/RViz-User-Guide - Marker-Sending-Basic-Shapes/Marker-Sending-Basic-Shapes - Marker-Points-and-Lines/Marker-Points-and-Lines - Marker-Display-types/Marker-Display-types - RViz-Custom-Display/RViz-Custom-Display - RViz-Custom-Panel/RViz-Custom-Panel +.. redirect-from:: + + Tutorials/Intermediate/RViz/RViz-Main + +RViz +==== + +RViz is a 3D visualizer for the Robot Operating System (ROS) framework. + +.. contents:: Contents + :depth: 0 + :local: + +.. toctree:: + :maxdepth: 1 + + RViz-User-Guide/RViz-User-Guide + Marker-Sending-Basic-Shapes/Marker-Sending-Basic-Shapes + Marker-Points-and-Lines/Marker-Points-and-Lines + Marker-Display-types/Marker-Display-types + RViz-Custom-Display/RViz-Custom-Display + RViz-Custom-Panel/RViz-Custom-Panel \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst b/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst index b71b5aacc09..f383764e534 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst @@ -1,375 +1,379 @@ -RViz User Guide -=============== - -**Goal:** Understanding RViz - -**Tutorial level:** Intermediate - -**Time:** 25 Minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- -RViz is a 3D visualizer for the Robot Operating System (ROS) framework. - -Install or build rviz ---------------------- -Follow the :doc:`installation instructions <../../../../Installation>` for your operating system to install RViz. - -Startup -------- -Don't forget to source the setup file. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Then start the visualizer - -.. code-block:: console - - $ ros2 run rviz2 rviz2 - -When RViz starts for the first time, you will see this window: - -.. image:: images/initial_startup.png - -The big black window in the middle is the 3D view (empty because there is nothing to see). -On the left is the Displays list, which will show any displays you have loaded. -Right now it just contains the global options and a Grid, which we'll get to later. -On the right are some of the other panels, described below. - -Displays --------- -A display is something that draws something in the 3D world, and likely has some options available in the displays list. -An example is a point cloud, the robot state, etc. - -Adding a new display -^^^^^^^^^^^^^^^^^^^^ -To add a display, click the Add button at the bottom: - -.. image:: images/add-button.png - -This will pop up the new display dialog: - -.. image:: images/add-display-dialog.png - -The list at the top contains the display type. -The type details what kind of data this display will visualize. -The text box in the middle gives a description of the selected display type. -Finally, you must give the display a unique name. -If you have, for example, two laser scanners on your robot, you might create two ``Laser Scan`` displays named "Laser Base" and "Laser Head". - -Display Properties -^^^^^^^^^^^^^^^^^^ -Each display gets its own list of properties. -For example: - -.. image:: images/display-properties.png - -Display Status -^^^^^^^^^^^^^^ -Each display gets its own status to help let you know if everything is OK or not. -The status can be one of: ``OK``, ``Warning``, ``Error``, or ``Disabled``. -The status is indicated in the display's title by the background color, -as well as in the Status category that you can see if the display is expanded: - -.. image:: images/display-status.png - -The ``Status`` category also expands to show specific status information. -This information is different for different displays, and the messages should be self explanatory. - -Built-in Display Types -^^^^^^^^^^^^^^^^^^^^^^ -.. list-table:: - :header-rows: 1 - :widths: 10 10 10 - - * - Name - - Description - - Messages Used - * - Axes - - Displays a set of Axes - - - * - Effort - - Shows the effort being put into each revolute joint of a robot - - `sensor_msgs/msg/JointStates `__ - * - Camera - - Creates a new rendering window from the perspective of a camera, and overlays the image on top of it. - - `sensor_msgs/msg/Image `__, `sensor_msgs/msg/CameraInfo `__ - * - Grid - - Displays a 2D or 3D grid along a plane - - - * - Grid Cells - - Draws cells from a grid, usually obstacles from a costmap from the `navigation `__ stack. - - `nav_msgs/msg/GridCells `__ - * - Image - - Creates a new rendering window with an Image. - Unlike the Camera display, this display does not use a CameraInfo - - `sensor_msgs/msg/Image `__ - * - InteractiveMarker - - Displays 3D objects from one or multiple Interactive Marker servers and allows mouse interaction with them - - `visualization_msgs/msg/InteractiveMarker `__ - * - Laser Scan - - Shows data from a laser scan, with different options for rendering modes, accumulation, etc. - - `sensor_msgs/msg/LaserScan `__ - * - Map - - Displays a map on the ground plane. - - `nav_msgs/msg/OccupancyGrid `__ - * - Markers - - Allows programmers to display arbitrary primitive shapes through a topic - - `visualization_msgs/msg/Marker `__, `visualization_msgs/msg/MarkerArray `__ - * - Path - - Shows a path from the `navigation `__ stack. - - `nav_msgs/msg/Path `__ - * - Point - - Draws a point as a small sphere. - - `geometry_msgs/msg/PointStamped `__ - * - Pose - - Draws a pose as either an arrow or axes. - - `geometry_msgs/msg/PoseStamped `__ - * - Pose Array - - Draws a "cloud" of arrows, one for each pose in a pose array - - `geometry_msgs/msg/PoseArray `__ - * - Point Cloud(2) - - Shows data from a point cloud, with different options for rendering modes, accumulation, etc. - - `sensor_msgs/msg/PointCloud `__, `sensor_msgs/msg/PointCloud2 `__ - * - Polygon - - Draws the outline of a polygon as lines. - - `geometry_msgs/msg/Polygon `__ - * - Odometry - - Accumulates odometry poses from over time. - - `nav_msgs/msg/Odometry `__ - * - Range - - Displays cones representing range measurements from sonar or IR range sensors. - Version: Electric+ - - `sensor_msgs/msg/Range `__ - * - RobotModel - - Shows a visual representation of a robot in the correct pose (as defined by the current TF transforms). - - - * - TF - - Displays the `tf2 `__ transform hierarchy. - - - * - Wrench - - Draws a wrench as arrow (force) and arrow + circle (torque) - - `geometry_msgs/msg/WrenchStamped `__ - * - Twist - - Draws a twist as arrow (linear) and arrow + circle (angular) - - `geometry_msgs/msg/TwistStamped `__ - -Configurations --------------- -Different configurations of displays are often useful for different uses of the visualizer. -A configuration useful for a full PR2 is not necessarily useful for a test cart, for example. -To this end, the visualizer lets you load and save different configurations. - -A configuration contains: - -* Displays + their properties -* Tool properties -* The viewpoint and settings for the 3D visualization - -Views Panel ------------ -There are a number of different camera types available in the visualizer. - -.. image:: images/camera-types.png - -Camera types consist both of different ways of controlling the camera and different types of projection (Orthographic vs. Perspective). - -Orbital Camera (default) -^^^^^^^^^^^^^^^^^^^^^^^^ -The orbital camera simply rotates around a focal point, while always looking at that point. -The focal point is visualized as a small disc while you're moving the camera: - -.. image:: images/focal-point.png - -Controls: - -* **Left mouse button**: Click and drag to rotate around the focal point. -* **Middle mouse button**: Click and drag to move the focal point in the plane formed by the camera's up and right vectors. - The distance moved depends on the focal point -- if there is an object on the focal point, and you click on top of it, it will stay under your mouse. -* **Right mouse button**: Click and drag to zoom in/out of the focal point. - Dragging up zooms in, down zooms out. -* **Scrollwheel**: Zoom in/out of the focal point - -FPS (first-person) Camera -^^^^^^^^^^^^^^^^^^^^^^^^^ -The FPS camera is a first-person camera, so it rotates as if you're looking with your head. - -Controls: - -* **Left mouse button**: Click and drag to rotate. - Control-click to pick the object under the mouse and look directly at it. -* **Middle mouse button**: Click and drag to move along the plane formed by the camera's up and right vectors. -* **Right mouse button**: Click and drag to move along the camera's forward vector. - Dragging up moves forward, down moves backward. -* **Scrollwheel**: Move forward/backward. - -Top-down Orthographic -^^^^^^^^^^^^^^^^^^^^^ -The top-down orthographic camera always looks down along the Z axis (in the robot frame), -and is an orthographic view which means things do not get smaller as they get farther away. - -Controls: - -* **Left mouse button**: Click and drag to rotate around the Z axis. -* **Middle mouse button**: Click and drag to move the camera along the XY plane. -* **Right mouse button**: Click and drag to zoom the image. -* **Scrollwheel**: Zoom the image. - -XY Orbit -^^^^^^^^ -Same as the orbital camera, with the focus point restricted to the XY plane. - -Controls: - -See orbital camera. - -Third Person Follower -^^^^^^^^^^^^^^^^^^^^^ -The camera maintains a constant viewing angle towards the target frame. -In contrast to XY Orbit the camera turns if the target frame yaws. -This could be handy if you are doing 3D mapping of a hallway with corners for example. - -Controls: - -See orbital camera. - - -Custom Views -^^^^^^^^^^^^ -The views panel also lets you create different named views, which are saved and can be switched between. -A view consists of a target frame, camera type and camera pose. -You can save a view by clicking the Save button of the views panel. - -.. image:: images/views.png - -A view consists of: - -* View controller type -* View configuration (position, orientation, etc; possibly different for each view controller type.) -* The Target Frame - -Views are saved per user, not in the config files. - -Coordinate Frames ------------------ -RViz uses the tf transform system for transforming data from the coordinate frame it arrives in into a global reference frame. -There are two coordinate frames that are important to know about in the visualizer, the target frame and the fixed frame. - -The Fixed Frame -^^^^^^^^^^^^^^^ -The more-important of the two frames is the fixed frame. -The fixed frame is the reference frame used to denote the ``world`` frame. -This is usually the ``map``, or ``world``, or something similar, but can also be, for example, your odometry frame. - -If the fixed frame is erroneously set to, say, the base of the robot, then all the objects the robot has ever seen will appear in front of the robot, at the position relative to the robot at which they were detected. -For correct results, the fixed frame should not be moving relative to the world. - -If you change the fixed frame, all data currently being shown is cleared rather than re-transformed. - -The Target Frame -^^^^^^^^^^^^^^^^ -The target frame is the reference frame for the camera view. -For example, if your target frame is the map, you'll see the robot driving around the map. -If your target frame is the base of the robot, the robot will stay in the same place while everything else moves relative to it. - -Tools ------ -The visualizer has a number of tools you can use on the toolbar. -The following sections will give a short introduction into these tools. -You can find some more information under Help -> Show Help panel. - -.. image:: images/tool.png - -Interact -^^^^^^^^ -This tool lets you interact with the visualized environment. -You can click on objects and depending on their properties simply select them, move them around and much more. - -Keyboard shortcut: ``i`` - -Move Camera -^^^^^^^^^^^ -The Move Camera tool is the default tool. -When this is selected and you click inside the 3D view, the viewpoint changes according to the options and camera type you have selected in the ``Views`` panel. -See the previous section ``Views Panel`` for more information. - -Keyboard shortcut: ``m`` - -Select -^^^^^^ -The Select tool allows you to select items being displayed in the 3D view. -It supports single-point selection as well as click/drag box selection. -You can add to a selection with the Shift key, and remove from the selection with the Ctrl key. -If you want to move the camera around while selecting without switching back to the Move Camera tool you can hold down the Alt key. -The ``f`` key will focus the camera on the current selection. - -.. image:: images/selection_highlight.png - -.. image:: images/selection_selected.png - -Keyboard shortcut: ``s`` - -Focus Camera -^^^^^^^^^^^^ -Focus camera lets you select a location in the visualizer. -The camera will then focus that point by changing its orientation but not its position. - -Keyboard shortcut: ``c`` - -Measure -^^^^^^^ -With the measure tool you can measure the distance between to points in the visualizer. -The first click after activating the tool will set the starting point and the second one the end point of the measurement. -The resulting distance will be displayed at the bottom of the RViz window. -But notice that the measurement tool only works with actually rendered objects in the visualizer, you can not use it in empty space. - -.. image:: images/measure.png - -Keyboard shortcut: ``n`` - -2D Pose Estimate -^^^^^^^^^^^^^^^^ -This tool lets you set an initial pose to seed the localization system (sent on the ``initialpose`` ROS topic). -Click on a location on the ground plane and drag to select the orientation. -The output topic can be changed in the ``Tool Properties`` panel. - -.. image:: images/set_pose.png - -This tool works with the `navigation `__ stack. - -Keyboard shortcut: ``p`` - -2D Nav Goal -^^^^^^^^^^^ -This tool lets you set a goal sent on the ``goal_pose`` ROS topic. -Click on a location on the ground plane and drag to select the orientation. -The output topic can be changed in the ``Tool Properties`` panel. - -This tool works with the `navigation `__ stack. - -Keyboard shortcut: ``g`` - -Publish Point -^^^^^^^^^^^^^ -The publish point tool lets you select an object in the visualizer -and the tool will publish the coordinates of that point based on the frame. -The results are shown at the bottom like with the measure tool but are also published on the ``clicked_point`` topic. - -Keyboard shortcut: ``u`` - -Time ----- -The Time panel is mostly useful when running in a simulator, since it allows you to see how much ROS Time has passed, vs. how much ``Wall Clock`` (aka real) time has passed. -The time panel also lets you reset the visualizer's internal time state, which resets of all the displays as well as tf's internal cache of data. - -.. image:: images/time.png - -If you are not running in simulation, the time panel is mostly useless. -In most cases it can be closed and you will probably not even notice (other than having a bit more screen real estate for the rest of rviz). +.. redirect-from:: + + Tutorials/Intermediate/RViz/RViz-User-Guide/RViz-User-Guide + +RViz User Guide +=============== + +**Goal:** Understanding RViz + +**Tutorial level:** Intermediate + +**Time:** 25 Minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- +RViz is a 3D visualizer for the Robot Operating System (ROS) framework. + +Install or build rviz +--------------------- +Follow the :doc:`installation instructions <../../../../Get-Started/Installation>` for your operating system to install RViz. + +Startup +------- +Don't forget to source the setup file. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Then start the visualizer + +.. code-block:: console + + $ ros2 run rviz2 rviz2 + +When RViz starts for the first time, you will see this window: + +.. image:: images/initial_startup.png + +The big black window in the middle is the 3D view (empty because there is nothing to see). +On the left is the Displays list, which will show any displays you have loaded. +Right now it just contains the global options and a Grid, which we'll get to later. +On the right are some of the other panels, described below. + +Displays +-------- +A display is something that draws something in the 3D world, and likely has some options available in the displays list. +An example is a point cloud, the robot state, etc. + +Adding a new display +^^^^^^^^^^^^^^^^^^^^ +To add a display, click the Add button at the bottom: + +.. image:: images/add-button.png + +This will pop up the new display dialog: + +.. image:: images/add-display-dialog.png + +The list at the top contains the display type. +The type details what kind of data this display will visualize. +The text box in the middle gives a description of the selected display type. +Finally, you must give the display a unique name. +If you have, for example, two laser scanners on your robot, you might create two ``Laser Scan`` displays named "Laser Base" and "Laser Head". + +Display Properties +^^^^^^^^^^^^^^^^^^ +Each display gets its own list of properties. +For example: + +.. image:: images/display-properties.png + +Display Status +^^^^^^^^^^^^^^ +Each display gets its own status to help let you know if everything is OK or not. +The status can be one of: ``OK``, ``Warning``, ``Error``, or ``Disabled``. +The status is indicated in the display's title by the background color, +as well as in the Status category that you can see if the display is expanded: + +.. image:: images/display-status.png + +The ``Status`` category also expands to show specific status information. +This information is different for different displays, and the messages should be self explanatory. + +Built-in Display Types +^^^^^^^^^^^^^^^^^^^^^^ +.. list-table:: + :header-rows: 1 + :widths: 10 10 10 + + * - Name + - Description + - Messages Used + * - Axes + - Displays a set of Axes + - + * - Effort + - Shows the effort being put into each revolute joint of a robot + - `sensor_msgs/msg/JointStates `__ + * - Camera + - Creates a new rendering window from the perspective of a camera, and overlays the image on top of it. + - `sensor_msgs/msg/Image `__, `sensor_msgs/msg/CameraInfo `__ + * - Grid + - Displays a 2D or 3D grid along a plane + - + * - Grid Cells + - Draws cells from a grid, usually obstacles from a costmap from the `navigation `__ stack. + - `nav_msgs/msg/GridCells `__ + * - Image + - Creates a new rendering window with an Image. + Unlike the Camera display, this display does not use a CameraInfo + - `sensor_msgs/msg/Image `__ + * - InteractiveMarker + - Displays 3D objects from one or multiple Interactive Marker servers and allows mouse interaction with them + - `visualization_msgs/msg/InteractiveMarker `__ + * - Laser Scan + - Shows data from a laser scan, with different options for rendering modes, accumulation, etc. + - `sensor_msgs/msg/LaserScan `__ + * - Map + - Displays a map on the ground plane. + - `nav_msgs/msg/OccupancyGrid `__ + * - Markers + - Allows programmers to display arbitrary primitive shapes through a topic + - `visualization_msgs/msg/Marker `__, `visualization_msgs/msg/MarkerArray `__ + * - Path + - Shows a path from the `navigation `__ stack. + - `nav_msgs/msg/Path `__ + * - Point + - Draws a point as a small sphere. + - `geometry_msgs/msg/PointStamped `__ + * - Pose + - Draws a pose as either an arrow or axes. + - `geometry_msgs/msg/PoseStamped `__ + * - Pose Array + - Draws a "cloud" of arrows, one for each pose in a pose array + - `geometry_msgs/msg/PoseArray `__ + * - Point Cloud(2) + - Shows data from a point cloud, with different options for rendering modes, accumulation, etc. + - `sensor_msgs/msg/PointCloud `__, `sensor_msgs/msg/PointCloud2 `__ + * - Polygon + - Draws the outline of a polygon as lines. + - `geometry_msgs/msg/Polygon `__ + * - Odometry + - Accumulates odometry poses from over time. + - `nav_msgs/msg/Odometry `__ + * - Range + - Displays cones representing range measurements from sonar or IR range sensors. + Version: Electric+ + - `sensor_msgs/msg/Range `__ + * - RobotModel + - Shows a visual representation of a robot in the correct pose (as defined by the current TF transforms). + - + * - TF + - Displays the `tf2 `__ transform hierarchy. + - + * - Wrench + - Draws a wrench as arrow (force) and arrow + circle (torque) + - `geometry_msgs/msg/WrenchStamped `__ + * - Twist + - Draws a twist as arrow (linear) and arrow + circle (angular) + - `geometry_msgs/msg/TwistStamped `__ + +Configurations +-------------- +Different configurations of displays are often useful for different uses of the visualizer. +A configuration useful for a full PR2 is not necessarily useful for a test cart, for example. +To this end, the visualizer lets you load and save different configurations. + +A configuration contains: + +* Displays + their properties +* Tool properties +* The viewpoint and settings for the 3D visualization + +Views Panel +----------- +There are a number of different camera types available in the visualizer. + +.. image:: images/camera-types.png + +Camera types consist both of different ways of controlling the camera and different types of projection (Orthographic vs. Perspective). + +Orbital Camera (default) +^^^^^^^^^^^^^^^^^^^^^^^^ +The orbital camera simply rotates around a focal point, while always looking at that point. +The focal point is visualized as a small disc while you're moving the camera: + +.. image:: images/focal-point.png + +Controls: + +* **Left mouse button**: Click and drag to rotate around the focal point. +* **Middle mouse button**: Click and drag to move the focal point in the plane formed by the camera's up and right vectors. + The distance moved depends on the focal point -- if there is an object on the focal point, and you click on top of it, it will stay under your mouse. +* **Right mouse button**: Click and drag to zoom in/out of the focal point. + Dragging up zooms in, down zooms out. +* **Scrollwheel**: Zoom in/out of the focal point + +FPS (first-person) Camera +^^^^^^^^^^^^^^^^^^^^^^^^^ +The FPS camera is a first-person camera, so it rotates as if you're looking with your head. + +Controls: + +* **Left mouse button**: Click and drag to rotate. + Control-click to pick the object under the mouse and look directly at it. +* **Middle mouse button**: Click and drag to move along the plane formed by the camera's up and right vectors. +* **Right mouse button**: Click and drag to move along the camera's forward vector. + Dragging up moves forward, down moves backward. +* **Scrollwheel**: Move forward/backward. + +Top-down Orthographic +^^^^^^^^^^^^^^^^^^^^^ +The top-down orthographic camera always looks down along the Z axis (in the robot frame), +and is an orthographic view which means things do not get smaller as they get farther away. + +Controls: + +* **Left mouse button**: Click and drag to rotate around the Z axis. +* **Middle mouse button**: Click and drag to move the camera along the XY plane. +* **Right mouse button**: Click and drag to zoom the image. +* **Scrollwheel**: Zoom the image. + +XY Orbit +^^^^^^^^ +Same as the orbital camera, with the focus point restricted to the XY plane. + +Controls: + +See orbital camera. + +Third Person Follower +^^^^^^^^^^^^^^^^^^^^^ +The camera maintains a constant viewing angle towards the target frame. +In contrast to XY Orbit the camera turns if the target frame yaws. +This could be handy if you are doing 3D mapping of a hallway with corners for example. + +Controls: + +See orbital camera. + + +Custom Views +^^^^^^^^^^^^ +The views panel also lets you create different named views, which are saved and can be switched between. +A view consists of a target frame, camera type and camera pose. +You can save a view by clicking the Save button of the views panel. + +.. image:: images/views.png + +A view consists of: + +* View controller type +* View configuration (position, orientation, etc; possibly different for each view controller type.) +* The Target Frame + +Views are saved per user, not in the config files. + +Coordinate Frames +----------------- +RViz uses the tf transform system for transforming data from the coordinate frame it arrives in into a global reference frame. +There are two coordinate frames that are important to know about in the visualizer, the target frame and the fixed frame. + +The Fixed Frame +^^^^^^^^^^^^^^^ +The more-important of the two frames is the fixed frame. +The fixed frame is the reference frame used to denote the ``world`` frame. +This is usually the ``map``, or ``world``, or something similar, but can also be, for example, your odometry frame. + +If the fixed frame is erroneously set to, say, the base of the robot, then all the objects the robot has ever seen will appear in front of the robot, at the position relative to the robot at which they were detected. +For correct results, the fixed frame should not be moving relative to the world. + +If you change the fixed frame, all data currently being shown is cleared rather than re-transformed. + +The Target Frame +^^^^^^^^^^^^^^^^ +The target frame is the reference frame for the camera view. +For example, if your target frame is the map, you'll see the robot driving around the map. +If your target frame is the base of the robot, the robot will stay in the same place while everything else moves relative to it. + +Tools +----- +The visualizer has a number of tools you can use on the toolbar. +The following sections will give a short introduction into these tools. +You can find some more information under Help -> Show Help panel. + +.. image:: images/tool.png + +Interact +^^^^^^^^ +This tool lets you interact with the visualized environment. +You can click on objects and depending on their properties simply select them, move them around and much more. + +Keyboard shortcut: ``i`` + +Move Camera +^^^^^^^^^^^ +The Move Camera tool is the default tool. +When this is selected and you click inside the 3D view, the viewpoint changes according to the options and camera type you have selected in the ``Views`` panel. +See the previous section ``Views Panel`` for more information. + +Keyboard shortcut: ``m`` + +Select +^^^^^^ +The Select tool allows you to select items being displayed in the 3D view. +It supports single-point selection as well as click/drag box selection. +You can add to a selection with the Shift key, and remove from the selection with the Ctrl key. +If you want to move the camera around while selecting without switching back to the Move Camera tool you can hold down the Alt key. +The ``f`` key will focus the camera on the current selection. + +.. image:: images/selection_highlight.png + +.. image:: images/selection_selected.png + +Keyboard shortcut: ``s`` + +Focus Camera +^^^^^^^^^^^^ +Focus camera lets you select a location in the visualizer. +The camera will then focus that point by changing its orientation but not its position. + +Keyboard shortcut: ``c`` + +Measure +^^^^^^^ +With the measure tool you can measure the distance between to points in the visualizer. +The first click after activating the tool will set the starting point and the second one the end point of the measurement. +The resulting distance will be displayed at the bottom of the RViz window. +But notice that the measurement tool only works with actually rendered objects in the visualizer, you can not use it in empty space. + +.. image:: images/measure.png + +Keyboard shortcut: ``n`` + +2D Pose Estimate +^^^^^^^^^^^^^^^^ +This tool lets you set an initial pose to seed the localization system (sent on the ``initialpose`` ROS topic). +Click on a location on the ground plane and drag to select the orientation. +The output topic can be changed in the ``Tool Properties`` panel. + +.. image:: images/set_pose.png + +This tool works with the `navigation `__ stack. + +Keyboard shortcut: ``p`` + +2D Nav Goal +^^^^^^^^^^^ +This tool lets you set a goal sent on the ``goal_pose`` ROS topic. +Click on a location on the ground plane and drag to select the orientation. +The output topic can be changed in the ``Tool Properties`` panel. + +This tool works with the `navigation `__ stack. + +Keyboard shortcut: ``g`` + +Publish Point +^^^^^^^^^^^^^ +The publish point tool lets you select an object in the visualizer +and the tool will publish the coordinates of that point based on the frame. +The results are shown at the bottom like with the measure tool but are also published on the ``clicked_point`` topic. + +Keyboard shortcut: ``u`` + +Time +---- +The Time panel is mostly useful when running in a simulator, since it allows you to see how much ROS Time has passed, vs. how much ``Wall Clock`` (aka real) time has passed. +The time panel also lets you reset the visualizer's internal time state, which resets of all the displays as well as tf's internal cache of data. + +.. image:: images/time.png + +If you are not running in simulation, the time panel is mostly useless. +In most cases it can be closed and you will probably not even notice (other than having a bit more screen real estate for the rest of rviz). \ No newline at end of file diff --git a/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst b/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst index 70a0df0f3dd..ec0ccf43cfa 100644 --- a/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst +++ b/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst @@ -1,382 +1,386 @@ -Create an rqt_bag Plugin -======================== - -Let's say you have bag files and you want to be able to create a custom visualization of some data. -``rqt_bag`` gives you the ability to scroll through the recorded messages and visualize the raw message values. - -.. code:: console - - $ ros2 run rqt_bag rqt_bag ~/path/to/BagFile - $ rqt_bag ~/path/to/BagFile # alternative - -This provides a standard uniform visualization: - -.. image:: images/rqtbag_plugin_base.png - :alt: screenshot of standard rqt_bag view - -However, you may sometimes want a more visual presentation, or you need to do some post-processing on the raw messages. -For that, you can write an ``rqt_bag`` plugin, using the Python plugin system. -This gives you the ability to get a customized visualization of the messages like this: - -.. image:: images/rqtbag_plugin_full.png - :alt: screenshot of rqt_bag with colored timeline and extra panel on the side - - -Some Test Data --------------- - -In this tutorial, we will be using the ``level`` field of the {interface(diagnostic_msgs/msg/DiagnosticStatus)} message. -Below is a simple script for generating diagnostic statuses with random levels. -You can record your own bag from this script, or use `this sample data `__ once you unzip it. - -.. code:: python - - from diagnostic_msgs.msg import DiagnosticStatus - import random - import rclpy - from rclpy.node import Node - - MODES = ['OK', 'WARN', 'ERROR'] - - class DiagnosticPub(Node): - def __init__(self): - super().__init__('diagnostic_pub') - self.last_status = None - self.publisher = self.create_publisher(DiagnosticStatus, '/diagnostics', 10) - self.timer = self.create_timer(1, self.callback) - - def callback(self): - if self.last_status is None: - # Random initial status - status = random.randint(0, len(MODES)) - elif random.randint(0, 5) != 0: - # Do not publish a msg every cycle - return - else: - # Random new (different) status - delta = random.randint(1, 2) - status = (self.last_status + delta) % len(MODES) - - self.get_logger().info(f'Publishing {MODES[status]} status') - self.publisher.publish(DiagnosticStatus(level=bytes(status))) - self.last_status = status - - - def main(args=None): - rclpy.init(args=args) - node = DiagnosticPub() - rclpy.spin(node) - - - if __name__ == '__main__': - main() - - -Package Setup -------------- - -We're going to create a package called ``rqt_bag_diagnostics_demo``. -Start by creating a basic ``ament_python`` package, e.g. by calling: - -.. code:: console - - $ ros2 pkg create --build-type ament_python --dependencies diagnostic_msgs python_qt_binding rqt_bag \ - --description "rqt_bag plugin for diagnostics_msgs" --license Apache-2.0 \ - --maintainer-name "My Name" --maintainer-email "my@name.robots" \ - rqt_bag_diagnostics_demo - -Edit the relevant parts of the generated ``package.xml`` to look like this: - -.. code:: xml - - diagnostic_msgs - python_qt_binding - rqt_bag - - ament_python - - - -What we're doing here is making our package depend on the rqt_bag, python_qt_binding and diagnostic_msgs packages and then exporting an XML file that defines our rqt_bag plugins. -In ``setup.py``, add the following line - -.. code:: python - - ('share/' + package_name, ['plugins.xml']), - -to the ``data_files``. - -Next, we're going to define the plugin in an XML file called ``plugins.xml`` (as referenced in ``package.xml``). -This file describes all plugins provided by this package (there can be multiple plugins per package). - -.. code:: xml - - - - Awesome Diagnostic - - - -The ``name`` attribute is the name of the plugin we create. -It has to be unique among all plugins, but you will not use it in any other way. -The ``type`` attribute is the way we would import the plugin's class in Python, i.e. ``package_name.module_name.class_name`` - -Defining the Plugin -------------------- - -Now we need to actually implement the ``the_plugin.py`` Python module (as referenced in ``plugins.xml``). -First, make sure there is an empty file ``__init__.py`` in ``rqt_bag_diagnostics_demo`` subfolder, turning it into a Python package. - -.. note:: - - Please note that according to the current Python standards in ROS, the folder with ROS package (``rqt_bag_diagnostics_demo``) contains a subfolder with the same name. - Therefore, the full path will be ``WORKSPACE/src/rqt_bag_diagnostics_demo/rqt_bag_diagnostics_demo/__init__.py``. - -Now create ``the_plugin.py`` next to ``__init__.py``. -This file will contain all code of the plugin. - -First, the core Plugin class. - -.. code:: python - - from rqt_bag.plugins.plugin import Plugin - from python_qt_binding.QtCore import Qt - from diagnostic_msgs.msg import DiagnosticStatus - - - def get_color(diagnostic): - if diagnostic.level == DiagnosticStatus.OK: - return Qt.green - elif diagnostic.level == DiagnosticStatus.WARN: - return Qt.yellow - else: # ERROR or STALE - return Qt.red - - - class DiagnosticBagPlugin(Plugin): - def __init__(self): - pass - - def get_view_class(self): - # This method is required; we will implement it later - return None - - def get_renderer_class(self): - return None - - def get_message_types(self): - return ['diagnostic_msgs/msg/DiagnosticStatus'] - -Here we have some basic imports, and helper function that we'll use later, and a class that defines the three parts of an ``rqt_bag`` plugin. - - 1. ``view_class`` - a.k.a. ``TopicMessageView`` - A separate panel that can be used for viewing individual messages. - 2. ``renderer_class`` - a.k.a. ``TimelineView`` - A tool for drawing onto the timeline view of the bag data. - 3. ``message_types`` - An array of strings that define what message types this plugin can be used for. - You can return ``['*']`` for it to apply to all messages. - -Since we return None for the first two methods, this plugin won't do anything. -We'll tackle each of these separately. - -TopicMessageView ----------------- - -Version 1 -~~~~~~~~~ - -We're going to create a class that extends the ``TopicMessageView`` class (still in ``the_plugin.py``). -First, add the import: - -.. code:: python - - from rqt_bag import TopicMessageView - -Then define this new class: - -.. code:: python - - class DiagnosticPanel(TopicMessageView): - name = 'Awesome Diagnostic' - - def message_viewed(self, bag, entry, ros_message, msg_type_name, topic): - super(DiagnosticPanel, self).message_viewed(bag=bag, entry=entry, ros_message=ros_message, msg_type_name=msg_type_name, topic=topic) - print(f'{topic}: {ros_message}') - -Here we define two things. -The ``name`` class variable defines what rqt_bag shows when right-clicking a ``DiagnosticStatus`` topic in the timeline. -The ``message_viewed`` method defines what to do when the message is selected. -So here, we'll just print the message to terminal for now. - -We need to hook this class we've created into the plugin infrastructure, and for that, we return the class object itself in the ``get_view_class`` method. - -.. code:: python - - def get_view_class(self): - return DiagnosticPanel - -.. note:: - - Do not type in ``return DiagnosticPanel()`` (with the ``()``). - Just ``return DiagnosticPanel`` is correct. - -To see this in action, run ``rqt_bag`` with your bag file, and right click on the diagnostic track. -It will give you two options under the "View": Raw, and our "Awesome Diagnostic." -Clicking this should open a panel and you can scroll through the messages and watch them print. - -.. image:: images/rqtbag_plugin_panel.png - :alt: screenshot of rqt_bag with blank extra panel - - -Version 2 -~~~~~~~~~ - -``TopicMessageView`` is itself an extension of a ``QObject``. -There's lots of things you could do with this using all the might and power of Qt. -This is not a python Qt tutorial sadly, `though there are many available online `_. -So we're going to just add a simple QWidget and draw on it. -First, add the following imports: - -.. code:: python - - from python_qt_binding.QtWidgets import QWidget - from python_qt_binding.QtGui import QBrush, QPainter - -Then update the ``DiagnosticPanel`` class to the following: - -.. code:: python - - class DiagnosticPanel(TopicMessageView): - name = 'Awesome Diagnostic' - - def __init__(self, timeline, parent, topic): - super(DiagnosticPanel, self).__init__(timeline, parent, topic) - self.widget = QWidget() - parent.layout().addWidget(self.widget) - self.msg = None - self.widget.paintEvent = self.paintEvent - - def message_viewed(self, bag, entry, ros_message, msg_type_name, topic): - super(DiagnosticPanel, self).message_viewed(bag=bag, entry=entry, - ros_message=ros_message, msg_type_name=msg_type_name, topic=topic) - self.msg = ros_message - self.widget.update() - - def paintEvent(self, event): - qp = QPainter() - qp.begin(self.widget) - - rect = event.rect() - - if self.msg is None: - qp.fillRect(0, 0, rect.width(), rect.height(), Qt.white) - else: - color = get_color(self.msg) - qp.setBrush(QBrush(color)) - qp.drawEllipse(0, 0, rect.width(), rect.height()) - qp.end() - -In the constructor, we create a ``QWidget`` and override its ``paintEvent`` method. -Now when we get a message with ``message_viewed``, we save it, and update the widget, which will in turn call our ``paintEvent``. -Do not call ``paintEvent`` manually, that has to be done by Qt. -Before a message is selected, we'll just paint a white rectangle. -Otherwise, we'll draw a circle, using our handy helper method to relate the color to what level the diagnostic is at. - -.. image:: images/rqtbag_plugin_circle.png - :alt: screenshot of rqt_bag with a circle drawn on the extra panel - - -TimelineRenderer ----------------- - -.. _version-1-1: - -Version 1 -~~~~~~~~~ - -To draw on the timeline, we extend the ``TimelineRenderer`` class (still in ``the_plugin.py``). -Add an import: - -.. code:: python - - from rqt_bag import TimelineRenderer - -Then add the new class. - -.. code:: python - - class DiagnosticTimeline(TimelineRenderer): - def __init__(self, timeline, height=80): - TimelineRenderer.__init__(self, timeline, msg_combine_px=height) - - def draw_timeline_segment(self, painter: QPainter, topic, start: float, end: float, x: float, y: int, width: float, height: int): - painter.setBrush(QBrush(Qt.blue)) - painter.drawRect(int(x), y, int(width), height) - -You can customize how tall the message's portion of the timeline is with the ``msg_combine_px`` parameter. -The key method to override is ``draw_timeline_segment()`` which gives you portions of the timeline to draw. -For now we'll just draw blue rectangles on each segment. - -Just like the message view, you also have to edit the plugin to return your class. - -.. code:: python - - def get_renderer_class(self): - return DiagnosticTimeline - -To view this, you have to enable "Thumbnails" (a misleading name) in the rqt_bag gui. - -.. image:: images/rqtbag_plugin_blue.png - :alt: screenshot of rqt_bag with blue bars drawn on the timeline - - -.. _version-2-1: - -Version 2 -~~~~~~~~~ - -Okay, now we actually want to customize how the messages are drawn in the timeline based on the messages themselves. -For that, you will need to read and deserialize the messages from the bag file. -Here are the new imports: - -.. code:: python - - from python_qt_binding.QtGui import QPen - from rclpy.time import Time - from rclpy.serialization import deserialize_message - from rqt_bag.bag_helper import to_sec - -Then update ``draw_timeline_segment()``: - -.. code:: python - - def draw_timeline_segment(self, painter: QPainter, topic, start: float, end: float, x: float, y: int, width: float, height: int): - bag_timeline = self.timeline.scene() - start_t = Time(seconds=start) - end_t = Time(seconds=end) - - for bag, entry in bag_timeline.get_entries_with_bags([topic], start_t, end_t): - topic, raw_data, t = bag_timeline.read_message(bag, entry.timestamp, topic) - msg = deserialize_message(raw_data, DiagnosticStatus) - color = get_color(msg) - painter.setBrush(QBrush(color)) - painter.setPen(QPen(color, 5)) - - t_float = to_sec(Time(nanoseconds=t)) - p_x = int(self.timeline.map_stamp_to_x(t_float)) - painter.drawLine(p_x, y, p_x, y + height - 1) - -Using the ``topic``, ``start`` and ``end`` parameters of the method, we can get the bag entries that correspond with this segment of the timeline. -We can then get the actual message and use it to draw. -Here we are drawing a line based on the level of the diagnostic message. -We can automatically figure out where to draw the message horizontally using the ``map_stamp_to_x()`` method which converts float seconds to widget pixels. - -.. image:: images/rqtbag_plugin_timeline.png - :alt: screenshot of rqt_bag with differently colored bars on the timeline - - -If computing the message representation on timeline is more computationally demanding, you should use -`Timeline Cache `__ -like the -`ImageTimelineViewer `__ -does, but figuring that out is left as an exercise to the reader. +.. redirect-from:: + + Tutorials/Advanced/Create-An-Rqtbag-Plugin + +Create an rqt_bag Plugin +======================== + +Let's say you have bag files and you want to be able to create a custom visualization of some data. +``rqt_bag`` gives you the ability to scroll through the recorded messages and visualize the raw message values. + +.. code:: console + + $ ros2 run rqt_bag rqt_bag ~/path/to/BagFile + $ rqt_bag ~/path/to/BagFile # alternative + +This provides a standard uniform visualization: + +.. image:: images/rqtbag_plugin_base.png + :alt: screenshot of standard rqt_bag view + +However, you may sometimes want a more visual presentation, or you need to do some post-processing on the raw messages. +For that, you can write an ``rqt_bag`` plugin, using the Python plugin system. +This gives you the ability to get a customized visualization of the messages like this: + +.. image:: images/rqtbag_plugin_full.png + :alt: screenshot of rqt_bag with colored timeline and extra panel on the side + + +Some Test Data +-------------- + +In this tutorial, we will be using the ``level`` field of the {interface(diagnostic_msgs/msg/DiagnosticStatus)} message. +Below is a simple script for generating diagnostic statuses with random levels. +You can record your own bag from this script, or use `this sample data `__ once you unzip it. + +.. code:: python + + from diagnostic_msgs.msg import DiagnosticStatus + import random + import rclpy + from rclpy.node import Node + + MODES = ['OK', 'WARN', 'ERROR'] + + class DiagnosticPub(Node): + def __init__(self): + super().__init__('diagnostic_pub') + self.last_status = None + self.publisher = self.create_publisher(DiagnosticStatus, '/diagnostics', 10) + self.timer = self.create_timer(1, self.callback) + + def callback(self): + if self.last_status is None: + # Random initial status + status = random.randint(0, len(MODES)) + elif random.randint(0, 5) != 0: + # Do not publish a msg every cycle + return + else: + # Random new (different) status + delta = random.randint(1, 2) + status = (self.last_status + delta) % len(MODES) + + self.get_logger().info(f'Publishing {MODES[status]} status') + self.publisher.publish(DiagnosticStatus(level=bytes(status))) + self.last_status = status + + + def main(args=None): + rclpy.init(args=args) + node = DiagnosticPub() + rclpy.spin(node) + + + if __name__ == '__main__': + main() + + +Package Setup +------------- + +We're going to create a package called ``rqt_bag_diagnostics_demo``. +Start by creating a basic ``ament_python`` package, e.g. by calling: + +.. code:: console + + $ ros2 pkg create --build-type ament_python --dependencies diagnostic_msgs python_qt_binding rqt_bag \ + --description "rqt_bag plugin for diagnostics_msgs" --license Apache-2.0 \ + --maintainer-name "My Name" --maintainer-email "my@name.robots" \ + rqt_bag_diagnostics_demo + +Edit the relevant parts of the generated ``package.xml`` to look like this: + +.. code:: xml + + diagnostic_msgs + python_qt_binding + rqt_bag + + ament_python + + + +What we're doing here is making our package depend on the rqt_bag, python_qt_binding and diagnostic_msgs packages and then exporting an XML file that defines our rqt_bag plugins. +In ``setup.py``, add the following line + +.. code:: python + + ('share/' + package_name, ['plugins.xml']), + +to the ``data_files``. + +Next, we're going to define the plugin in an XML file called ``plugins.xml`` (as referenced in ``package.xml``). +This file describes all plugins provided by this package (there can be multiple plugins per package). + +.. code:: xml + + + + Awesome Diagnostic + + + +The ``name`` attribute is the name of the plugin we create. +It has to be unique among all plugins, but you will not use it in any other way. +The ``type`` attribute is the way we would import the plugin's class in Python, i.e. ``package_name.module_name.class_name`` + +Defining the Plugin +------------------- + +Now we need to actually implement the ``the_plugin.py`` Python module (as referenced in ``plugins.xml``). +First, make sure there is an empty file ``__init__.py`` in ``rqt_bag_diagnostics_demo`` subfolder, turning it into a Python package. + +.. note:: + + Please note that according to the current Python standards in ROS, the folder with ROS package (``rqt_bag_diagnostics_demo``) contains a subfolder with the same name. + Therefore, the full path will be ``WORKSPACE/src/rqt_bag_diagnostics_demo/rqt_bag_diagnostics_demo/__init__.py``. + +Now create ``the_plugin.py`` next to ``__init__.py``. +This file will contain all code of the plugin. + +First, the core Plugin class. + +.. code:: python + + from rqt_bag.plugins.plugin import Plugin + from python_qt_binding.QtCore import Qt + from diagnostic_msgs.msg import DiagnosticStatus + + + def get_color(diagnostic): + if diagnostic.level == DiagnosticStatus.OK: + return Qt.green + elif diagnostic.level == DiagnosticStatus.WARN: + return Qt.yellow + else: # ERROR or STALE + return Qt.red + + + class DiagnosticBagPlugin(Plugin): + def __init__(self): + pass + + def get_view_class(self): + # This method is required; we will implement it later + return None + + def get_renderer_class(self): + return None + + def get_message_types(self): + return ['diagnostic_msgs/msg/DiagnosticStatus'] + +Here we have some basic imports, and helper function that we'll use later, and a class that defines the three parts of an ``rqt_bag`` plugin. + + 1. ``view_class`` - a.k.a. ``TopicMessageView`` - A separate panel that can be used for viewing individual messages. + 2. ``renderer_class`` - a.k.a. ``TimelineView`` - A tool for drawing onto the timeline view of the bag data. + 3. ``message_types`` - An array of strings that define what message types this plugin can be used for. + You can return ``['*']`` for it to apply to all messages. + +Since we return None for the first two methods, this plugin won't do anything. +We'll tackle each of these separately. + +TopicMessageView +---------------- + +Version 1 +~~~~~~~~~ + +We're going to create a class that extends the ``TopicMessageView`` class (still in ``the_plugin.py``). +First, add the import: + +.. code:: python + + from rqt_bag import TopicMessageView + +Then define this new class: + +.. code:: python + + class DiagnosticPanel(TopicMessageView): + name = 'Awesome Diagnostic' + + def message_viewed(self, bag, entry, ros_message, msg_type_name, topic): + super(DiagnosticPanel, self).message_viewed(bag=bag, entry=entry, ros_message=ros_message, msg_type_name=msg_type_name, topic=topic) + print(f'{topic}: {ros_message}') + +Here we define two things. +The ``name`` class variable defines what rqt_bag shows when right-clicking a ``DiagnosticStatus`` topic in the timeline. +The ``message_viewed`` method defines what to do when the message is selected. +So here, we'll just print the message to terminal for now. + +We need to hook this class we've created into the plugin infrastructure, and for that, we return the class object itself in the ``get_view_class`` method. + +.. code:: python + + def get_view_class(self): + return DiagnosticPanel + +.. note:: + + Do not type in ``return DiagnosticPanel()`` (with the ``()``). + Just ``return DiagnosticPanel`` is correct. + +To see this in action, run ``rqt_bag`` with your bag file, and right click on the diagnostic track. +It will give you two options under the "View": Raw, and our "Awesome Diagnostic." +Clicking this should open a panel and you can scroll through the messages and watch them print. + +.. image:: images/rqtbag_plugin_panel.png + :alt: screenshot of rqt_bag with blank extra panel + + +Version 2 +~~~~~~~~~ + +``TopicMessageView`` is itself an extension of a ``QObject``. +There's lots of things you could do with this using all the might and power of Qt. +This is not a python Qt tutorial sadly, `though there are many available online `_. +So we're going to just add a simple QWidget and draw on it. +First, add the following imports: + +.. code:: python + + from python_qt_binding.QtWidgets import QWidget + from python_qt_binding.QtGui import QBrush, QPainter + +Then update the ``DiagnosticPanel`` class to the following: + +.. code:: python + + class DiagnosticPanel(TopicMessageView): + name = 'Awesome Diagnostic' + + def __init__(self, timeline, parent, topic): + super(DiagnosticPanel, self).__init__(timeline, parent, topic) + self.widget = QWidget() + parent.layout().addWidget(self.widget) + self.msg = None + self.widget.paintEvent = self.paintEvent + + def message_viewed(self, bag, entry, ros_message, msg_type_name, topic): + super(DiagnosticPanel, self).message_viewed(bag=bag, entry=entry, + ros_message=ros_message, msg_type_name=msg_type_name, topic=topic) + self.msg = ros_message + self.widget.update() + + def paintEvent(self, event): + qp = QPainter() + qp.begin(self.widget) + + rect = event.rect() + + if self.msg is None: + qp.fillRect(0, 0, rect.width(), rect.height(), Qt.white) + else: + color = get_color(self.msg) + qp.setBrush(QBrush(color)) + qp.drawEllipse(0, 0, rect.width(), rect.height()) + qp.end() + +In the constructor, we create a ``QWidget`` and override its ``paintEvent`` method. +Now when we get a message with ``message_viewed``, we save it, and update the widget, which will in turn call our ``paintEvent``. +Do not call ``paintEvent`` manually, that has to be done by Qt. +Before a message is selected, we'll just paint a white rectangle. +Otherwise, we'll draw a circle, using our handy helper method to relate the color to what level the diagnostic is at. + +.. image:: images/rqtbag_plugin_circle.png + :alt: screenshot of rqt_bag with a circle drawn on the extra panel + + +TimelineRenderer +---------------- + +.. _version-1-1: + +Version 1 +~~~~~~~~~ + +To draw on the timeline, we extend the ``TimelineRenderer`` class (still in ``the_plugin.py``). +Add an import: + +.. code:: python + + from rqt_bag import TimelineRenderer + +Then add the new class. + +.. code:: python + + class DiagnosticTimeline(TimelineRenderer): + def __init__(self, timeline, height=80): + TimelineRenderer.__init__(self, timeline, msg_combine_px=height) + + def draw_timeline_segment(self, painter: QPainter, topic, start: float, end: float, x: float, y: int, width: float, height: int): + painter.setBrush(QBrush(Qt.blue)) + painter.drawRect(int(x), y, int(width), height) + +You can customize how tall the message's portion of the timeline is with the ``msg_combine_px`` parameter. +The key method to override is ``draw_timeline_segment()`` which gives you portions of the timeline to draw. +For now we'll just draw blue rectangles on each segment. + +Just like the message view, you also have to edit the plugin to return your class. + +.. code:: python + + def get_renderer_class(self): + return DiagnosticTimeline + +To view this, you have to enable "Thumbnails" (a misleading name) in the rqt_bag gui. + +.. image:: images/rqtbag_plugin_blue.png + :alt: screenshot of rqt_bag with blue bars drawn on the timeline + + +.. _version-2-1: + +Version 2 +~~~~~~~~~ + +Okay, now we actually want to customize how the messages are drawn in the timeline based on the messages themselves. +For that, you will need to read and deserialize the messages from the bag file. +Here are the new imports: + +.. code:: python + + from python_qt_binding.QtGui import QPen + from rclpy.time import Time + from rclpy.serialization import deserialize_message + from rqt_bag.bag_helper import to_sec + +Then update ``draw_timeline_segment()``: + +.. code:: python + + def draw_timeline_segment(self, painter: QPainter, topic, start: float, end: float, x: float, y: int, width: float, height: int): + bag_timeline = self.timeline.scene() + start_t = Time(seconds=start) + end_t = Time(seconds=end) + + for bag, entry in bag_timeline.get_entries_with_bags([topic], start_t, end_t): + topic, raw_data, t = bag_timeline.read_message(bag, entry.timestamp, topic) + msg = deserialize_message(raw_data, DiagnosticStatus) + color = get_color(msg) + painter.setBrush(QBrush(color)) + painter.setPen(QPen(color, 5)) + + t_float = to_sec(Time(nanoseconds=t)) + p_x = int(self.timeline.map_stamp_to_x(t_float)) + painter.drawLine(p_x, y, p_x, y + height - 1) + +Using the ``topic``, ``start`` and ``end`` parameters of the method, we can get the bag entries that correspond with this segment of the timeline. +We can then get the actual message and use it to draw. +Here we are drawing a line based on the level of the diagnostic message. +We can automatically figure out where to draw the message horizontally using the ``map_stamp_to_x()`` method which converts float seconds to widget pixels. + +.. image:: images/rqtbag_plugin_timeline.png + :alt: screenshot of rqt_bag with differently colored bars on the timeline + + +If computing the message representation on timeline is more computationally demanding, you should use +`Timeline Cache `__ +like the +`ImageTimelineViewer `__ +does, but figuring that out is left as an exercise to the reader. \ No newline at end of file diff --git a/source/Get-Started/About-ROS.rst b/source/Get-Started/About-ROS.rst index 05fe7db14e9..c84ac3674c7 100644 --- a/source/Get-Started/About-ROS.rst +++ b/source/Get-Started/About-ROS.rst @@ -1,140 +1,144 @@ -.. _AboutROS: - -About ROS -========= - -ROS (Robot Operating System) is an open-source ecosystem that provides the framework, tools, and libraries for building, deploying, running, and maintaining robotic applications. -This article introduces the main areas of the ecosystem and outlines their intended use. - -**Area: ROS-framework, ROS-tools, ROS-capabilities | Content-type: about | Experience: beginner** - -.. contents:: Table of Contents - :depth: 2 - :local: - -Summary -------- - -ROS is used in many areas of robotics. -In logistics, it helps robots move goods in warehouses by providing navigation, mapping, motion control, and coordination between multiple robots. -In manufacturing, it enables advanced tasks such as automated pick-and-place operations using vision systems for accurate handling. -In healthcare, ROS supports robotic systems that assist with patient care and improve efficiency in clinical workflows. - -Watch the `ROS video`_ for a quick introduction. - -.. _ROS video: https://vimeo.com/237016358 - -The ecosystem -------------- - -Despite its name, ROS is actually not an operating system in the traditional sense, but a set of tools and libraries that help developers create robots using various platforms and programming languages. - -.. image:: images/ROS-ecosystem.gif - :alt: Animated high level diagram of the ROS ecosystem - -Framework ---------- - -The ROS framework is the “plumbing” which allows for communication between parts of a robot, and within parts of a robot. -It includes messaging, standard interfaces, and support for multiple programming languages and platforms. - -For example, the framework handles sending data from a camera to a processing node or passing commands from a planning system to a motor controller. -It also provides the structure for sharing software across systems, so developers can build modular and reusable solutions. - -ROS consists of the following basic components: - -* Nodes -* Interfaces (topics, services and actions) -* Parameters -* Client libraries - -Tools ------ - -Tools in ROS help developers build, test, and monitor robotic systems. -They do not add new robot behaviours but make development easier. - -For example, visualisation tools can be used to display a robot's sensors, position, and environment in 3D during testing, which is common in projects involving drones or mobile robots. -With launch control tools, developers can define and verify how a robot starts up and manages its operation before actual deployment. -Data recording and playback tools allow you to register robot behaviour for later inspection, which is particularly useful when debugging why the robot did something wrong. - -The core set of tools provided by ROS allows you to handle the following elements of the development workflow: - -* Introspection -* Analysis -* Node management -* Debugging -* Builds -* Visualization -* Package documentation - -Capabilities ------------- - -Capabilities in ROS are ready-to-use packages that offer common functions for robots, such as manipulation, motion planning, and perception. -These packages allow developers to add advanced behaviours without starting from scratch. - -For example, manipulation packages can control robotic arms for tasks like picking and placing objects in automated workflows. -Motion planning packages allow robots to move from one point to another by calculating safe paths in their environment. -Perception packages enable robots to detect and recognise objects or people, supporting tasks such as retrieving objects or working in environments where the robot needs to respond to what it sees. -Different implementations of the same capabilities allow developers to switch implementations and experiment to find the best implementation for their needs. - -.. note:: - Apart from the packages maintained by Open Robotics, you can also choose from many packages contributed by the ROS community. - -ROS offers the following core capabilities either out of the box, or through supported third-party solutions: - -* Simulation -* Motion planning -* Navigation -* Manipulation -* Perception - -Community ---------- - -Community in ROS is the global network of developers, researchers, companies, and contributors who help our library of open-source software grow and improve. -People can contribute to plumbing, tools, and capabilities, and thanks to the community, it is easy to share code, exchange ideas, and work together on projects. - -Integrations ------------- - -ROS works with other Open Robotics platforms to make development and deployment easier. - -* `Gazebo`_: Offers physics-based simulation, so developers can test robots in a virtual environment before using real hardware. -* `Open-RMF`_ (Robotics Middleware Framework): Helps different robots work together and interact with building systems like lifts and doors. -* `ros-controls`_: Enables real-time control of robots using ROS. - -.. _Gazebo: https://gazebosim.org/home -.. _Open-RMF: https://www.open-rmf.org/ -.. _ros-controls: https://control.ros.org/rolling/index.html - -These integrations make it simpler to design, test, and manage robots in complex environments on any budget and with any team size. - -ROS distributions ------------------ - -A ROS distribution is a packaged set of ROS software released on a regular schedule. -Each distribution provides a stable version of the core libraries and tools, plus many community packages. -This makes it easier for developers to work with a consistent codebase and keep projects compatible. - -ROS has two main versions: - -* `ROS 1`_: The original framework. -* ROS 2: The current and actively developed version. - -.. _ROS 1: https://index.ros.org/ - -ROS 1 has reached the end of development, with no new releases planned, while ROS 2 continues to be developed and releases new distributions every year. -These distributions include updates and improvements, so developers can choose between stability and the latest features. - -Supported systems ------------------ - -ROS runs on Ubuntu, Windows, and macOS, but we strongly recommend that you use a Tier 1 platform for your ROS distribution. -ROS on macOS is supported by the community, and we do not recommended it for new users. - -Ubuntu support depends on the ROS distribution, with each distribution requiring a specific Ubuntu LTS (long-term support) release. -Other platforms may require building from source or using containers. - -:doc:`See full details of currently supported platforms and support tiers <./Releases/Release-Rolling-Ridley>` +.. redirect-from:: + + About-ROS + +.. _AboutROS: + +About ROS +========= + +ROS (Robot Operating System) is an open-source ecosystem that provides the framework, tools, and libraries for building, deploying, running, and maintaining robotic applications. +This article introduces the main areas of the ecosystem and outlines their intended use. + +**Area: ROS-framework, ROS-tools, ROS-capabilities | Content-type: about | Experience: beginner** + +.. contents:: Table of Contents + :depth: 2 + :local: + +Summary +------- + +ROS is used in many areas of robotics. +In logistics, it helps robots move goods in warehouses by providing navigation, mapping, motion control, and coordination between multiple robots. +In manufacturing, it enables advanced tasks such as automated pick-and-place operations using vision systems for accurate handling. +In healthcare, ROS supports robotic systems that assist with patient care and improve efficiency in clinical workflows. + +Watch the `ROS video`_ for a quick introduction. + +.. _ROS video: https://vimeo.com/237016358 + +The ecosystem +------------- + +Despite its name, ROS is actually not an operating system in the traditional sense, but a set of tools and libraries that help developers create robots using various platforms and programming languages. + +.. image:: images/ROS-ecosystem.gif + :alt: Animated high level diagram of the ROS ecosystem + +Framework +--------- + +The ROS framework is the “plumbing” which allows for communication between parts of a robot, and within parts of a robot. +It includes messaging, standard interfaces, and support for multiple programming languages and platforms. + +For example, the framework handles sending data from a camera to a processing node or passing commands from a planning system to a motor controller. +It also provides the structure for sharing software across systems, so developers can build modular and reusable solutions. + +ROS consists of the following basic components: + +* Nodes +* Interfaces (topics, services and actions) +* Parameters +* Client libraries + +Tools +----- + +Tools in ROS help developers build, test, and monitor robotic systems. +They do not add new robot behaviours but make development easier. + +For example, visualisation tools can be used to display a robot's sensors, position, and environment in 3D during testing, which is common in projects involving drones or mobile robots. +With launch control tools, developers can define and verify how a robot starts up and manages its operation before actual deployment. +Data recording and playback tools allow you to register robot behaviour for later inspection, which is particularly useful when debugging why the robot did something wrong. + +The core set of tools provided by ROS allows you to handle the following elements of the development workflow: + +* Introspection +* Analysis +* Node management +* Debugging +* Builds +* Visualization +* Package documentation + +Capabilities +------------ + +Capabilities in ROS are ready-to-use packages that offer common functions for robots, such as manipulation, motion planning, and perception. +These packages allow developers to add advanced behaviours without starting from scratch. + +For example, manipulation packages can control robotic arms for tasks like picking and placing objects in automated workflows. +Motion planning packages allow robots to move from one point to another by calculating safe paths in their environment. +Perception packages enable robots to detect and recognise objects or people, supporting tasks such as retrieving objects or working in environments where the robot needs to respond to what it sees. +Different implementations of the same capabilities allow developers to switch implementations and experiment to find the best implementation for their needs. + +.. note:: + Apart from the packages maintained by Open Robotics, you can also choose from many packages contributed by the ROS community. + +ROS offers the following core capabilities either out of the box, or through supported third-party solutions: + +* Simulation +* Motion planning +* Navigation +* Manipulation +* Perception + +Community +--------- + +Community in ROS is the global network of developers, researchers, companies, and contributors who help our library of open-source software grow and improve. +People can contribute to plumbing, tools, and capabilities, and thanks to the community, it is easy to share code, exchange ideas, and work together on projects. + +Integrations +------------ + +ROS works with other Open Robotics platforms to make development and deployment easier. + +* `Gazebo`_: Offers physics-based simulation, so developers can test robots in a virtual environment before using real hardware. +* `Open-RMF`_ (Robotics Middleware Framework): Helps different robots work together and interact with building systems like lifts and doors. +* `ros-controls`_: Enables real-time control of robots using ROS. + +.. _Gazebo: https://gazebosim.org/home +.. _Open-RMF: https://www.open-rmf.org/ +.. _ros-controls: https://control.ros.org/rolling/index.html + +These integrations make it simpler to design, test, and manage robots in complex environments on any budget and with any team size. + +ROS distributions +----------------- + +A ROS distribution is a packaged set of ROS software released on a regular schedule. +Each distribution provides a stable version of the core libraries and tools, plus many community packages. +This makes it easier for developers to work with a consistent codebase and keep projects compatible. + +ROS has two main versions: + +* `ROS 1`_: The original framework. +* ROS 2: The current and actively developed version. + +.. _ROS 1: https://index.ros.org/ + +ROS 1 has reached the end of development, with no new releases planned, while ROS 2 continues to be developed and releases new distributions every year. +These distributions include updates and improvements, so developers can choose between stability and the latest features. + +Supported systems +----------------- + +ROS runs on Ubuntu, Windows, and macOS, but we strongly recommend that you use a Tier 1 platform for your ROS distribution. +ROS on macOS is supported by the community, and we do not recommended it for new users. + +Ubuntu support depends on the ROS distribution, with each distribution requiring a specific Ubuntu LTS (long-term support) release. +Other platforms may require building from source or using containers. + +:doc:`See full details of currently supported platforms and support tiers ` \ No newline at end of file diff --git a/source/Get-Started/Configuring-ROS2-Environment.rst b/source/Get-Started/Configuring-ROS2-Environment.rst index eae0fb57d67..8beff50028d 100644 --- a/source/Get-Started/Configuring-ROS2-Environment.rst +++ b/source/Get-Started/Configuring-ROS2-Environment.rst @@ -1,226 +1,227 @@ -.. redirect-from:: - - Tutorials/Configuring-ROS2-Environment - -.. _ConfigROS2: - -Configuring environment -======================= - -**Goal:** This tutorial will show you how to prepare your ROS 2 environment. - -**Tutorial level:** Beginner - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -ROS 2 relies on the notion of combining workspaces using the shell environment. -"Workspace" is a ROS term for the location on your system where you're developing with ROS 2. -The core ROS 2 workspace is called the underlay. -Subsequent local workspaces are called overlays. -When developing with ROS 2, you will typically have several workspaces active concurrently. - -Combining workspaces makes developing against different versions of ROS 2, or against different sets of packages, easier. -It also allows the installation of several ROS 2 distributions (or "distros", e.g. Dashing and Eloquent) on the same computer and switching between them. - -This is accomplished by sourcing setup files every time you open a new shell, or by adding the source command to your shell startup script once. -Without sourcing the setup files, you won't be able to access ROS 2 commands, or find or use ROS 2 packages. -In other words, you won't be able to use ROS 2. - -Prerequisites -------------- - -Before starting these tutorials, install ROS 2 by following the instructions on the ROS 2 :doc:`../../Installation` page. - -The commands used in this tutorial assume you followed the binary packages installation guide for your operating system (deb packages for Linux). -You can still follow along if you built from source, but the path to your setup files will likely be different. -You also won't be able to use the ``sudo apt install ros--`` command (used frequently in the beginner level tutorials) if you install from source. - -If you are using Linux or macOS, but are not already familiar with the shell, `this tutorial `__ will help. - -Tasks ------ - -1 Source the setup files -^^^^^^^^^^^^^^^^^^^^^^^^ - -You will need to run this command on every new shell you open to have access to the ROS 2 commands, like so: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - -.. note:: - The exact command depends on where you installed ROS 2. - If you're having problems, ensure the file path leads to your installation. - -2 Add sourcing to your shell startup script -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you don't want to have to source the setup file every time you open a new shell (skipping task 1), then you can add the command to your shell startup script: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ echo "source /opt/ros/{DISTRO}/setup.bash" >> ~/.bashrc - - To undo this, locate your system's shell startup script and remove the appended source command. - - .. group-tab:: macOS - - .. code-block:: console - - $ echo "source ~/ros2_install/ros2-osx/setup.bash" >> ~/.bash_profile - - To undo this, locate your system's shell startup script and remove the appended source command. - - .. group-tab:: Windows - - Only for PowerShell users, create a folder in 'My Documents' called 'WindowsPowerShell'. - Within 'WindowsPowerShell', create file 'Microsoft.PowerShell_profile.ps1'. - Inside the file, paste: - - .. code-block:: console - - $ C:\dev\ros2_{DISTRO}\local_setup.ps1 - - PowerShell will request permission to run this script every time a new shell is opened. - To avoid that issue you can run: - - .. code-block:: console - - $ Unblock-File C:\dev\ros2_{DISTRO}\local_setup.ps1 - - To undo this, remove the new 'Microsoft.PowerShell_profile.ps1' file. - -3 Check environment variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sourcing ROS 2 setup files will set several environment variables necessary for operating ROS 2. -If you ever have problems finding or using your ROS 2 packages, make sure that your environment is properly set up using the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ printenv | grep -i ROS - - .. group-tab:: macOS - - .. code-block:: console - - $ printenv | grep -i ROS - - .. group-tab:: Windows - - .. code-block:: console - - $ set | findstr -i ROS - -Check that variables like ``ROS_DISTRO`` and ``ROS_VERSION`` are set. - -:: - - ROS_VERSION=2 - ROS_PYTHON_VERSION=3 - ROS_DISTRO={DISTRO} - -If the environment variables are not set correctly, return to the ROS 2 package installation section of the installation guide you followed. -If you need more specific help (because environment setup files can come from different places), you can `get answers `__ from the community. - -3.1 The ``ROS_DOMAIN_ID`` variable -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -See the `domain ID <../../Concepts/Intermediate/About-Domain-ID>` article for details on ROS domain IDs. - -Once you have determined a unique integer for your group of ROS 2 nodes, you can set the environment variable with the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DOMAIN_ID= - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_DOMAIN_ID=" >> ~/.bashrc - - .. group-tab:: macOS - - .. code-block:: console - - $ export ROS_DOMAIN_ID= - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_DOMAIN_ID=" >> ~/.bash_profile - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DOMAIN_ID= - - If you want to make this permanent between shell sessions, also run: - - .. code-block:: console - - $ setx ROS_DOMAIN_ID - -3.2 The ``ROS_AUTOMATIC_DISCOVERY_RANGE`` variable -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -By default, ROS 2 communication is not limited to localhost. -``ROS_AUTOMATIC_DISCOVERY_RANGE`` environment variable allows you to limit ROS 2 discovery range. -Using ``ROS_AUTOMATIC_DISCOVERY_RANGE`` is helpful in certain settings, such as classrooms, where multiple robots may publish to the same topic causing strange behaviors. -See :ref:`Improved Dynamic Discovery ` for more details. - -Summary -------- - -The ROS 2 development environment needs to be correctly configured before use. -This can be done in two ways: either sourcing the setup files in every new shell you open, or adding the source command to your startup script. - -If you ever face any problems locating or using packages with ROS 2, the first thing you should do is check your environment variables and ensure they are set to the version and distro you intended. - -Next steps ----------- - -Now that you have a working ROS 2 installation and you know how to source its setup files, you can start learning the ins and outs of ROS 2 with the :doc:`turtlesim tool <./Introducing-Turtlesim/Introducing-Turtlesim>`. +.. redirect-from:: + + Tutorials/Configuring-ROS2-Environment + Tutorials/Beginner-CLI-Tools/Configuring-ROS2-Environment + +.. _ConfigROS2: + +Configuring environment +======================= + +**Goal:** This tutorial will show you how to prepare your ROS 2 environment. + +**Tutorial level:** Beginner + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +ROS 2 relies on the notion of combining workspaces using the shell environment. +"Workspace" is a ROS term for the location on your system where you're developing with ROS 2. +The core ROS 2 workspace is called the underlay. +Subsequent local workspaces are called overlays. +When developing with ROS 2, you will typically have several workspaces active concurrently. + +Combining workspaces makes developing against different versions of ROS 2, or against different sets of packages, easier. +It also allows the installation of several ROS 2 distributions (or "distros", e.g. Dashing and Eloquent) on the same computer and switching between them. + +This is accomplished by sourcing setup files every time you open a new shell, or by adding the source command to your shell startup script once. +Without sourcing the setup files, you won't be able to access ROS 2 commands, or find or use ROS 2 packages. +In other words, you won't be able to use ROS 2. + +Prerequisites +------------- + +Before starting these tutorials, install ROS 2 by following the instructions on the ROS 2 :doc:`Installation` page. + +The commands used in this tutorial assume you followed the binary packages installation guide for your operating system (deb packages for Linux). +You can still follow along if you built from source, but the path to your setup files will likely be different. +You also won't be able to use the ``sudo apt install ros--`` command (used frequently in the beginner level tutorials) if you install from source. + +If you are using Linux or macOS, but are not already familiar with the shell, `this tutorial `__ will help. + +Tasks +----- + +1 Source the setup files +^^^^^^^^^^^^^^^^^^^^^^^^ + +You will need to run this command on every new shell you open to have access to the ROS 2 commands, like so: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + +.. note:: + The exact command depends on where you installed ROS 2. + If you're having problems, ensure the file path leads to your installation. + +2 Add sourcing to your shell startup script +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you don't want to have to source the setup file every time you open a new shell (skipping task 1), then you can add the command to your shell startup script: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ echo "source /opt/ros/{DISTRO}/setup.bash" >> ~/.bashrc + + To undo this, locate your system's shell startup script and remove the appended source command. + + .. group-tab:: macOS + + .. code-block:: console + + $ echo "source ~/ros2_install/ros2-osx/setup.bash" >> ~/.bash_profile + + To undo this, locate your system's shell startup script and remove the appended source command. + + .. group-tab:: Windows + + Only for PowerShell users, create a folder in 'My Documents' called 'WindowsPowerShell'. + Within 'WindowsPowerShell', create file 'Microsoft.PowerShell_profile.ps1'. + Inside the file, paste: + + .. code-block:: console + + $ C:\dev\ros2_{DISTRO}\local_setup.ps1 + + PowerShell will request permission to run this script every time a new shell is opened. + To avoid that issue you can run: + + .. code-block:: console + + $ Unblock-File C:\dev\ros2_{DISTRO}\local_setup.ps1 + + To undo this, remove the new 'Microsoft.PowerShell_profile.ps1' file. + +3 Check environment variables +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sourcing ROS 2 setup files will set several environment variables necessary for operating ROS 2. +If you ever have problems finding or using your ROS 2 packages, make sure that your environment is properly set up using the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ printenv | grep -i ROS + + .. group-tab:: macOS + + .. code-block:: console + + $ printenv | grep -i ROS + + .. group-tab:: Windows + + .. code-block:: console + + $ set | findstr -i ROS + +Check that variables like ``ROS_DISTRO`` and ``ROS_VERSION`` are set. + +:: + + ROS_VERSION=2 + ROS_PYTHON_VERSION=3 + ROS_DISTRO={DISTRO} + +If the environment variables are not set correctly, return to the ROS 2 package installation section of the installation guide you followed. +If you need more specific help (because environment setup files can come from different places), you can `get answers `__ from the community. + +3.1 The ``ROS_DOMAIN_ID`` variable +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +See the `domain ID <../../Concepts/Intermediate/About-Domain-ID>` article for details on ROS domain IDs. + +Once you have determined a unique integer for your group of ROS 2 nodes, you can set the environment variable with the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DOMAIN_ID= + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_DOMAIN_ID=" >> ~/.bashrc + + .. group-tab:: macOS + + .. code-block:: console + + $ export ROS_DOMAIN_ID= + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_DOMAIN_ID=" >> ~/.bash_profile + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DOMAIN_ID= + + If you want to make this permanent between shell sessions, also run: + + .. code-block:: console + + $ setx ROS_DOMAIN_ID + +3.2 The ``ROS_AUTOMATIC_DISCOVERY_RANGE`` variable +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default, ROS 2 communication is not limited to localhost. +``ROS_AUTOMATIC_DISCOVERY_RANGE`` environment variable allows you to limit ROS 2 discovery range. +Using ``ROS_AUTOMATIC_DISCOVERY_RANGE`` is helpful in certain settings, such as classrooms, where multiple robots may publish to the same topic causing strange behaviors. +See :ref:`Improved Dynamic Discovery ` for more details. + +Summary +------- + +The ROS 2 development environment needs to be correctly configured before use. +This can be done in two ways: either sourcing the setup files in every new shell you open, or adding the source command to your startup script. + +If you ever face any problems locating or using packages with ROS 2, the first thing you should do is check your environment variables and ensure they are set to the version and distro you intended. + +Next steps +---------- + +Now that you have a working ROS 2 installation and you know how to source its setup files, you can start learning the ins and outs of ROS 2 with the :doc:`turtlesim tool `. \ No newline at end of file diff --git a/source/Get-Started/Installation.rst b/source/Get-Started/Installation.rst index 45fddfc1e9d..5d1ccd8415b 100644 --- a/source/Get-Started/Installation.rst +++ b/source/Get-Started/Installation.rst @@ -1,86 +1,90 @@ -.. _InstallationGuide: -.. _RollingInstall: - -Installation -============ - -Options for installing ROS 2 {DISTRO_TITLE_FULL}: - -.. toctree:: - :maxdepth: 1 - - Installation/Ubuntu-Install-Debs - Installation/Windows-Install-Binary - Installation/RHEL-Install-RPMs - Installation/Alternatives - Installation/RMW-Implementations - Installation/ROS-2-Mirrors - Installation/Installation-on-Raspberry-Pi - Installation/Installation-Troubleshooting - -.. _binary-package-platforms: - -Binary packages ---------------- - -Binaries are only created for the Tier 1 operating systems listed in :doc:`Lyrical Luth release docs `. -If you are not running any of the following operating systems you may need to build from source or use a :doc:`container solution ` to run ROS 2 on your platform. - -We provide ROS 2 binary packages for the following platforms: - -* Ubuntu Linux (amd64 / aarch64) - Resolute Raccoon (26.04) - - * :doc:`deb packages ` (recommended) - * :doc:`binary archive ` - -* Red Hat Enterprise Linux 10 (amd64) - - * :doc:`RPM packages ` (recommended) - * :doc:`binary archive ` - -* Windows 11 (amd64) - - * :doc:`Windows Binary (VS 2019) ` - -.. _building-from-source: - -Building from source --------------------- - -We support building ROS 2 from source on the following platforms: - -* :doc:`Ubuntu Linux 26.04 ` -* :doc:`Ubuntu Linux 26.04 (Pixi) ` -* :doc:`Windows 11 ` -* :doc:`RHEL-10/Fedora ` -* :doc:`macOS ` - -Which install should you choose? --------------------------------- - -Installing from binary packages or from source will both result in a fully-functional and usable ROS 2 install. -Differences between the options depend on what you plan to do with ROS 2. - -**Binary packages** are for general use and provide an already-built install of ROS 2. -This is great for people who want to dive in and start using ROS 2 as-is, right away. - -Linux users have two options for installing binary packages: - -- Packages (debs or RPMS, depending on the platform) -- binary archive - -Installing from packages is the recommended method, as it installs necessary dependencies automatically and also updates alongside regular system updates. -However, you need root access in order to install deb packages. -If you don't have root access, the binary archive is the next best choice. - -Windows users who choose to install from binary packages only have the binary archive option -(deb packages are exclusive to Ubuntu/Debian). - -**Building from source** is meant for developers looking to alter or explicitly omit parts of ROS 2's base. -It is also recommended for platforms that don't support binaries. -Building from source also gives you the option to install the absolute latest version of ROS 2. - -Contributing to ROS 2 core? -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you plan to contribute directly to ROS 2 core packages, you can install the :doc:`latest development from source ` which shares installation instructions with the :ref:`Rolling distribution `. +.. redirect-from:: + + Installation + +.. _InstallationGuide: +.. _RollingInstall: + +Installation +============ + +Options for installing ROS 2 {DISTRO_TITLE_FULL}: + +.. toctree:: + :maxdepth: 1 + + Installation/Ubuntu-Install-Debs + Installation/Windows-Install-Binary + Installation/RHEL-Install-RPMs + Installation/Alternatives + Installation/RMW-Implementations + Installation/ROS-2-Mirrors + Installation/Installation-on-Raspberry-Pi + Installation/Installation-Troubleshooting + +.. _binary-package-platforms: + +Binary packages +--------------- + +Binaries are only created for the Tier 1 operating systems listed in :doc:`Lyrical Luth release docs `. +If you are not running any of the following operating systems you may need to build from source or use a :doc:`container solution <../Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers>` to run ROS 2 on your platform. + +We provide ROS 2 binary packages for the following platforms: + +* Ubuntu Linux (amd64 / aarch64) - Resolute Raccoon (26.04) + + * :doc:`deb packages ` (recommended) + * :doc:`binary archive ` + +* Red Hat Enterprise Linux 10 (amd64) + + * :doc:`RPM packages ` (recommended) + * :doc:`binary archive ` + +* Windows 11 (amd64) + + * :doc:`Windows Binary (VS 2019) ` + +.. _building-from-source: + +Building from source +-------------------- + +We support building ROS 2 from source on the following platforms: + +* :doc:`Ubuntu Linux 26.04 ` +* :doc:`Ubuntu Linux 26.04 (Pixi) ` +* :doc:`Windows 11 ` +* :doc:`RHEL-10/Fedora ` +* :doc:`macOS ` + +Which install should you choose? +-------------------------------- + +Installing from binary packages or from source will both result in a fully-functional and usable ROS 2 install. +Differences between the options depend on what you plan to do with ROS 2. + +**Binary packages** are for general use and provide an already-built install of ROS 2. +This is great for people who want to dive in and start using ROS 2 as-is, right away. + +Linux users have two options for installing binary packages: + +- Packages (debs or RPMS, depending on the platform) +- binary archive + +Installing from packages is the recommended method, as it installs necessary dependencies automatically and also updates alongside regular system updates. +However, you need root access in order to install deb packages. +If you don't have root access, the binary archive is the next best choice. + +Windows users who choose to install from binary packages only have the binary archive option +(deb packages are exclusive to Ubuntu/Debian). + +**Building from source** is meant for developers looking to alter or explicitly omit parts of ROS 2's base. +It is also recommended for platforms that don't support binaries. +Building from source also gives you the option to install the absolute latest version of ROS 2. + +Contributing to ROS 2 core? +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you plan to contribute directly to ROS 2 core packages, you can install the :doc:`latest development from source ` which shares installation instructions with the :ref:`Rolling distribution `. \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives.rst b/source/Get-Started/Installation/Alternatives.rst index 439b200c3a3..cc79b4db892 100644 --- a/source/Get-Started/Installation/Alternatives.rst +++ b/source/Get-Started/Installation/Alternatives.rst @@ -1,17 +1,21 @@ -Advanced installation options -============ - -A list of alternative ways to install ROS 2 – whether it's by building from source or installing a binary. - -.. toctree:: - :maxdepth: 1 - - Alternatives/Ubuntu-Development-Setup - Alternatives/Ubuntu-Development-Setup-Pixi - Alternatives/Ubuntu-Install-Binary - Alternatives/Windows-Development-Setup - Alternatives/RHEL-Development-Setup - Alternatives/RHEL-Install-Binary - Alternatives/macOS-Development-Setup - Alternatives/Latest-Development-Setup - Alternatives/Maintaining-a-Source-Checkout +.. redirect-from:: + + Installation/Alternatives + +Advanced installation options +============ + +A list of alternative ways to install ROS 2 – whether it's by building from source or installing a binary. + +.. toctree:: + :maxdepth: 1 + + Alternatives/Ubuntu-Development-Setup + Alternatives/Ubuntu-Development-Setup-Pixi + Alternatives/Ubuntu-Install-Binary + Alternatives/Windows-Development-Setup + Alternatives/RHEL-Development-Setup + Alternatives/RHEL-Install-Binary + Alternatives/macOS-Development-Setup + Alternatives/Latest-Development-Setup + Alternatives/Maintaining-a-Source-Checkout \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst index 6ef490f4115..e919f0bd9ab 100644 --- a/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst @@ -1,28 +1,32 @@ -Latest development (source) -=========================== - -If you plan to contribute directly to the latest ROS 2 development, you can install ROS 2 by building it from source or installing testing binaries. -This will give you the latest bug fixes and features. - -Testing binaries ----------------- - -See :doc:`Testing <../Testing>`. - -Build from source ------------------ - -.. note:: - - The latest development does not go through the same rigorous testing as releases and is not recommended if you are looking for a stable version of ROS 2. - Instead, choose a :doc:`ROS distribution <../../Installation>` that has already been released. - -Follow the links below for the latest setup instructions for your platform: - -* :doc:`Ubuntu Linux ` -* :doc:`Ubuntu Linux (Pixi) ` -* :doc:`Windows ` -* :doc:`RHEL ` -* :doc:`macOS ` - -For keeping your source code up-to-date, see :doc:`Maintain a source checkout <../Maintaining-a-Source-Checkout>`. +.. redirect-from:: + + Installation/Alternatives/Latest-Development-Setup + +Latest development (source) +=========================== + +If you plan to contribute directly to the latest ROS 2 development, you can install ROS 2 by building it from source or installing testing binaries. +This will give you the latest bug fixes and features. + +Testing binaries +---------------- + +See :doc:`Testing <../../../Developer-Tools/Testing/Testing>`. + +Build from source +----------------- + +.. note:: + + The latest development does not go through the same rigorous testing as releases and is not recommended if you are looking for a stable version of ROS 2. + Instead, choose a :doc:`ROS distribution <../../Installation>` that has already been released. + +Follow the links below for the latest setup instructions for your platform: + +* :doc:`Ubuntu Linux ` +* :doc:`Ubuntu Linux (Pixi) ` +* :doc:`Windows ` +* :doc:`RHEL ` +* :doc:`macOS ` + +For keeping your source code up-to-date, see :doc:`Maintain a source checkout `. \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst b/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst index 9aced9b7082..f7307b21992 100644 --- a/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst +++ b/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst @@ -1,152 +1,156 @@ -.. _MaintainingSource: - -Maintain source checkout -======================== - -.. ifconfig:: smv_current_version != '' and smv_current_version != 'rolling' - - .. note:: - - For instructions on maintaining a source checkout of the **latest development version** of ROS 2, refer to - `Maintaining a source checkout of ROS 2 Rolling <../../rolling/Installation/Maintaining-a-Source-Checkout.html>`__ - -.. contents:: - :depth: 2 - :local: - -If you have installed ROS 2 from source, there may have been changes made to the source code since the time that you checked it out. -To keep your source checkout up to date, you will have to periodically update your ``ros2.repos`` file, download the latest sources, and rebuild your workspace. - -Update your repository list ---------------------------- - -Each ROS 2 release includes a ``ros2.repos`` file that contains the list of repositories and their version for that release. - - -Latest ROS 2 {DISTRO_TITLE} branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you wish to checkout the latest code for ROS 2 {DISTRO_TITLE}, you can get the relevant repository list by running: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_{DISTRO} - $ mv -i ros2.repos ros2.repos.old - $ wget https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_{DISTRO} - $ mv -i ros2.repos ros2.repos.old - $ wget https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos - - .. group-tab:: Windows - - Use a Windows command line interface: - - .. code-block:: console - - $ cd \dev\ros2_{DISTRO} - $ curl -sk https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos -o ros2.repos - - Or a powershell: - - .. code-block:: console - - $ cd \dev\ros2_{DISTRO} - $ curl https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos -o ros2.repos - - -Update your repositories ------------------------- - -You will notice that in the `ros2.repos `__ file, each repository has a ``version`` associated with it that points to a particular commit hash, tag, or branch name. -It is possible that these versions refer to new tags/branches that your local copy of the repositories will not recognize as they are out-of-date. -Because of this, you should update the repositories that you have already checked out with the following command: - -.. code-block:: console - - $ vcs custom --args remote update - -Download the new source code ----------------------------- - -You should now be able to download the sources associated with the new repository list with: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ vcs import src < ros2.repos - $ vcs pull src - - .. group-tab:: macOS - - .. code-block:: console - - $ vcs import src < ros2.repos - $ vcs pull src - - .. group-tab:: Windows - - In a Windows command line interface: - - .. code-block:: console - - $ vcs import --input ros2.repos src - $ vcs pull src - - Or in powershell: - - .. code-block:: console - - $ vcs import --input ros2.repos src - $ vcs pull src - -Rebuild your workspace ----------------------- - -Now that the workspace is up to date with the latest sources, remove your previous install and rebuild your workspace with, for example: - -.. code-block:: console - - $ colcon build --symlink-install - -Inspect your source checkout ----------------------------- - -During your development you may have deviated from the original state of your workspace from when you imported the repository list. -If you wish to know the versions of the set of repositories in your workspace, you can export the information using the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_{DISTRO} - $ vcs export src > my_ros2.repos - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_{DISTRO} - $ vcs export src > my_ros2.repos - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \dev\ros2_{DISTRO} - $ vcs export src > my_ros2.repos - -This ``my_ros2.repos`` file can then be shared with others so that they can reproduce the state of the repositories in your workspace. +.. redirect-from:: + + Installation/Maintaining-a-Source-Checkout + +.. _MaintainingSource: + +Maintain source checkout +======================== + +.. ifconfig:: smv_current_version != '' and smv_current_version != 'rolling' + + .. note:: + + For instructions on maintaining a source checkout of the **latest development version** of ROS 2, refer to + `Maintaining a source checkout of ROS 2 Rolling <../../rolling/Installation/Maintaining-a-Source-Checkout.html>`__ + +.. contents:: + :depth: 2 + :local: + +If you have installed ROS 2 from source, there may have been changes made to the source code since the time that you checked it out. +To keep your source checkout up to date, you will have to periodically update your ``ros2.repos`` file, download the latest sources, and rebuild your workspace. + +Update your repository list +--------------------------- + +Each ROS 2 release includes a ``ros2.repos`` file that contains the list of repositories and their version for that release. + + +Latest ROS 2 {DISTRO_TITLE} branches +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you wish to checkout the latest code for ROS 2 {DISTRO_TITLE}, you can get the relevant repository list by running: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_{DISTRO} + $ mv -i ros2.repos ros2.repos.old + $ wget https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_{DISTRO} + $ mv -i ros2.repos ros2.repos.old + $ wget https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos + + .. group-tab:: Windows + + Use a Windows command line interface: + + .. code-block:: console + + $ cd \dev\ros2_{DISTRO} + $ curl -sk https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos -o ros2.repos + + Or a powershell: + + .. code-block:: console + + $ cd \dev\ros2_{DISTRO} + $ curl https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos -o ros2.repos + + +Update your repositories +------------------------ + +You will notice that in the `ros2.repos `__ file, each repository has a ``version`` associated with it that points to a particular commit hash, tag, or branch name. +It is possible that these versions refer to new tags/branches that your local copy of the repositories will not recognize as they are out-of-date. +Because of this, you should update the repositories that you have already checked out with the following command: + +.. code-block:: console + + $ vcs custom --args remote update + +Download the new source code +---------------------------- + +You should now be able to download the sources associated with the new repository list with: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ vcs import src < ros2.repos + $ vcs pull src + + .. group-tab:: macOS + + .. code-block:: console + + $ vcs import src < ros2.repos + $ vcs pull src + + .. group-tab:: Windows + + In a Windows command line interface: + + .. code-block:: console + + $ vcs import --input ros2.repos src + $ vcs pull src + + Or in powershell: + + .. code-block:: console + + $ vcs import --input ros2.repos src + $ vcs pull src + +Rebuild your workspace +---------------------- + +Now that the workspace is up to date with the latest sources, remove your previous install and rebuild your workspace with, for example: + +.. code-block:: console + + $ colcon build --symlink-install + +Inspect your source checkout +---------------------------- + +During your development you may have deviated from the original state of your workspace from when you imported the repository list. +If you wish to know the versions of the set of repositories in your workspace, you can export the information using the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_{DISTRO} + $ vcs export src > my_ros2.repos + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_{DISTRO} + $ vcs export src > my_ros2.repos + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \dev\ros2_{DISTRO} + $ vcs export src > my_ros2.repos + +This ``my_ros2.repos`` file can then be shared with others so that they can reproduce the state of the repositories in your workspace. \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst index 2a13b02b261..9e1f5280330 100644 --- a/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst @@ -1,212 +1,213 @@ -.. redirect-from:: - - Installation/Alternatives/Fedora-Development-Setup - Installation/Fedora-Development-Setup - Installation/RHEL-Development-Setup - -RHEL (source) -============= - -.. contents:: Table of Contents - :depth: 2 - :local: - - -System requirements -------------------- -The current target Red Hat platforms for {DISTRO_TITLE_FULL} are: - -- Tier 2: RHEL 10 64-bit - -As defined in `REP 2000 `_. - -System setup ------------- - -Set locale -^^^^^^^^^^ - -.. include:: ../_RHEL-Set-Locale.rst - -Enable required repositories -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: RHEL - - The rosdep database contains packages from the EPEL and PowerTools repositories, which are not enabled by default. - They can be enabled by running: - - .. code-block:: console - - $ sudo dnf install 'dnf-command(config-manager)' epel-release -y - $ sudo dnf config-manager --set-enabled crb - - .. note:: This step may be slightly different depending on the distribution you are using. - `Check the EPEL documentation `_ - - .. group-tab:: Fedora - - No additional setup required. - - -Install development tools -^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ sudo dnf install -y \ - cmake \ - gcc-c++ \ - git \ - make \ - patch \ - python3-colcon-common-extensions \ - python3-mypy \ - python3-pip \ - python3-pytest \ - python3-pytest-cov \ - python3-pytest-mock \ - python3-pytest-repeat \ - python3-pytest-rerunfailures \ - python3-pytest-runner \ - python3-rosdep \ - python3-setuptools \ - python3-vcstool \ - wget - -Build ROS 2 ------------ - -Get ROS 2 code -^^^^^^^^^^^^^^ - -Create a workspace and clone all repos: - -.. code-block:: console - - $ mkdir -p ~/ros2_{DISTRO}/src - $ cd ~/ros2_{DISTRO} - $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src - -Install dependencies using rosdep -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: ../_Dnf-Update-Admonition.rst - -.. code-block:: console - - $ sudo rosdep init - $ rosdep update - $ rosdep install --from-paths src --ignore-src -y --skip-keys "fastcdr rti-connext-dds-7.7.0 urdfdom_headers" - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Build the code in the workspace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have already installed ROS 2 another way (either via RPMs or the binary distribution), make sure that you run the below commands in a fresh environment that does not have those other installations sourced. -Also ensure that you do not have ``source /opt/ros/${ROS_DISTRO}/setup.bash`` in your ``.bashrc``. -You can make sure that ROS 2 is not sourced with the command ``printenv | grep -i ROS``. -The output should be empty. - -More info on working with a ROS workspace can be found in :doc:`this tutorial <../../Tutorials/Beginner-Client-Libraries/Colcon-Tutorial>`. - -.. code-block:: console - - $ cd ~/ros2_{DISTRO}/ - $ colcon build --symlink-install - -.. note:: - - If you are having trouble compiling all examples and this is preventing you from completing a successful build, you can use the ``--packages-skip`` colcon flag to ignore the package that is causing problems. - For instance, if you don't want to install the large OpenCV library, you could skip building the packages that depend on it using the command: - - .. code-block:: console - - $ colcon build --symlink-install --packages-skip image_tools intra_process_demo - -Setup environment ------------------ - -Set up your environment by sourcing the following file. - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/local_setup.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - -Try some examples ------------------ - -In one terminal, source the setup file and then run a C++ ``talker``\ : - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/local_setup.bash - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``\ : - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/local_setup.bash - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Alternate compilers -------------------- - -Using a different compiler besides gcc to compile ROS 2 is easy. -If you set the environment variables ``CC`` and ``CXX`` to executables for a working C and C++ compiler, respectively, and retrigger CMake configuration (by using ``--force-cmake-config`` or by deleting the packages you want to be affected), CMake will reconfigure and use the different compiler. - -Clang -^^^^^ - -To configure CMake to detect and use Clang: - -.. code-block:: console - - $ sudo dnf install clang - $ export CC=clang - $ export CXX=clang++ - $ colcon build --cmake-force-configure - -Stay up to date ---------------- - -See :doc:`../Maintaining-a-Source-Checkout` to periodically refresh your source installation. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :ref:`here `. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rm -rf ~/ros2_{DISTRO} +.. redirect-from:: + + Installation/Alternatives/Fedora-Development-Setup + Installation/Fedora-Development-Setup + Installation/RHEL-Development-Setup + Installation/Alternatives/RHEL-Development-Setup + +RHEL (source) +============= + +.. contents:: Table of Contents + :depth: 2 + :local: + + +System requirements +------------------- +The current target Red Hat platforms for {DISTRO_TITLE_FULL} are: + +- Tier 2: RHEL 10 64-bit + +As defined in `REP 2000 `_. + +System setup +------------ + +Set locale +^^^^^^^^^^ + +.. include:: ../_RHEL-Set-Locale.rst + +Enable required repositories +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: RHEL + + The rosdep database contains packages from the EPEL and PowerTools repositories, which are not enabled by default. + They can be enabled by running: + + .. code-block:: console + + $ sudo dnf install 'dnf-command(config-manager)' epel-release -y + $ sudo dnf config-manager --set-enabled crb + + .. note:: This step may be slightly different depending on the distribution you are using. + `Check the EPEL documentation `_ + + .. group-tab:: Fedora + + No additional setup required. + + +Install development tools +^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ sudo dnf install -y \ + cmake \ + gcc-c++ \ + git \ + make \ + patch \ + python3-colcon-common-extensions \ + python3-mypy \ + python3-pip \ + python3-pytest \ + python3-pytest-cov \ + python3-pytest-mock \ + python3-pytest-repeat \ + python3-pytest-rerunfailures \ + python3-pytest-runner \ + python3-rosdep \ + python3-setuptools \ + python3-vcstool \ + wget + +Build ROS 2 +----------- + +Get ROS 2 code +^^^^^^^^^^^^^^ + +Create a workspace and clone all repos: + +.. code-block:: console + + $ mkdir -p ~/ros2_{DISTRO}/src + $ cd ~/ros2_{DISTRO} + $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src + +Install dependencies using rosdep +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: ../_Dnf-Update-Admonition.rst + +.. code-block:: console + + $ sudo rosdep init + $ rosdep update + $ rosdep install --from-paths src --ignore-src -y --skip-keys "fastcdr rti-connext-dds-7.7.0 urdfdom_headers" + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. +See the :doc:`guide <../RMW-Implementations/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. + +Build the code in the workspace +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have already installed ROS 2 another way (either via RPMs or the binary distribution), make sure that you run the below commands in a fresh environment that does not have those other installations sourced. +Also ensure that you do not have ``source /opt/ros/${ROS_DISTRO}/setup.bash`` in your ``.bashrc``. +You can make sure that ROS 2 is not sourced with the command ``printenv | grep -i ROS``. +The output should be empty. + +More info on working with a ROS workspace can be found in :doc:`this tutorial <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>`. + +.. code-block:: console + + $ cd ~/ros2_{DISTRO}/ + $ colcon build --symlink-install + +.. note:: + + If you are having trouble compiling all examples and this is preventing you from completing a successful build, you can use the ``--packages-skip`` colcon flag to ignore the package that is causing problems. + For instance, if you don't want to install the large OpenCV library, you could skip building the packages that depend on it using the command: + + .. code-block:: console + + $ colcon build --symlink-install --packages-skip image_tools intra_process_demo + +Setup environment +----------------- + +Set up your environment by sourcing the following file. + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/local_setup.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + +Try some examples +----------------- + +In one terminal, source the setup file and then run a C++ ``talker``\ : + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/local_setup.bash + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``\ : + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/local_setup.bash + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Alternate compilers +------------------- + +Using a different compiler besides gcc to compile ROS 2 is easy. +If you set the environment variables ``CC`` and ``CXX`` to executables for a working C and C++ compiler, respectively, and retrigger CMake configuration (by using ``--force-cmake-config`` or by deleting the packages you want to be affected), CMake will reconfigure and use the different compiler. + +Clang +^^^^^ + +To configure CMake to detect and use Clang: + +.. code-block:: console + + $ sudo dnf install clang + $ export CC=clang + $ export CXX=clang++ + $ colcon build --cmake-force-configure + +Stay up to date +--------------- + +See :doc:`Maintaining-a-Source-Checkout` to periodically refresh your source installation. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :ref:`here `. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst b/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst index 9481e4f933b..869634d67db 100644 --- a/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst +++ b/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst @@ -1,170 +1,174 @@ -RHEL (binary) -============= - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page explains how to install ROS 2 on RHEL from a pre-built binary package. - -.. note:: - - The pre-built binary does not include all ROS 2 packages. - All packages in the `ROS base variant `_ are included, and only a subset of packages in the `ROS desktop variant `_ are included. - The exact list of packages are described by the repositories listed in `this ros2.repos file `_. - -There are also :doc:`RPM packages <../RHEL-Install-RPMs>` available. - -System requirements -------------------- - -We currently support RHEL 10 64-bit. -The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. -Most people will want to use a stable ROS distribution. - -System setup ------------- - -Set locale -^^^^^^^^^^ - -.. include:: ../_RHEL-Set-Locale.rst - -Enable required repositories -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The rosdep database contains packages from the EPEL and PowerTools repositories, which are not enabled by default. -They can be enabled by running: - -.. code-block:: console - - $ sudo dnf install 'dnf-command(config-manager)' epel-release -y - $ sudo dnf config-manager --set-enabled crb - -.. note:: This step may be slightly different depending on the distribution you are using. - `Check the EPEL documentation `_ - -Install prerequisites -^^^^^^^^^^^^^^^^^^^^^ - -There are a few packages that must be installed in order to get and unpack the binary release. - -.. code-block:: console - - $ sudo dnf install tar bzip2 wget -y - -Install development tools (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you are going to build ROS packages or otherwise do development, you can also install the development tools: - -.. code-block:: console - - $ sudo dnf install -y \ - cmake \ - gcc-c++ \ - git \ - make \ - patch \ - python3-colcon-common-extensions \ - python3-mypy \ - python3-pip \ - python3-pytest \ - python3-pytest-repeat \ - python3-pytest-rerunfailures \ - python3-rosdep \ - python3-setuptools \ - python3-vcstool \ - wget - -Install ROS 2 -------------- - -Binary releases of Rolling Ridley are not provided. -Instead you may download nightly :ref:`prerelease binaries `. - -* Download the latest package for RHEL; let's assume that it ends up at ``~/Downloads/ros2-package-linux-x86_64.tar.bz2``. - - * Note: there may be more than one binary download option which might cause the file name to differ. - -* Unpack it: - - .. code-block:: console - - $ mkdir -p ~/ros2_{DISTRO} - $ cd ~/ros2_{DISTRO} - $ tar xf ~/Downloads/ros2-package-linux-x86_64.tar.bz2 - -Install dependencies using rosdep -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: ../_Dnf-Update-Admonition.rst - -.. code-block:: console - - $ sudo rosdep init - $ rosdep update - $ rosdep install --from-paths ~/ros2_{DISTRO}/ros2-linux/share --ignore-src -y --skip-keys "cyclonedds fastcdr fastdds iceoryx_binding_c rti-connext-dds-7.7.0 urdfdom_headers" - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Setup environment ------------------ - -Set up your environment by sourcing the following file. - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - -Try some examples ------------------ - -In one terminal, source the setup file and then run a C++ ``talker``: - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``: - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :doc:`here <../../How-To-Guides/Installation-Troubleshooting>`. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rm -rf ~/ros2_{DISTRO} +.. redirect-from:: + + Installation/Alternatives/RHEL-Install-Binary + +RHEL (binary) +============= + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page explains how to install ROS 2 on RHEL from a pre-built binary package. + +.. note:: + + The pre-built binary does not include all ROS 2 packages. + All packages in the `ROS base variant `_ are included, and only a subset of packages in the `ROS desktop variant `_ are included. + The exact list of packages are described by the repositories listed in `this ros2.repos file `_. + +There are also :doc:`RPM packages <../RHEL-Install-RPMs>` available. + +System requirements +------------------- + +We currently support RHEL 10 64-bit. +The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. +Most people will want to use a stable ROS distribution. + +System setup +------------ + +Set locale +^^^^^^^^^^ + +.. include:: ../_RHEL-Set-Locale.rst + +Enable required repositories +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The rosdep database contains packages from the EPEL and PowerTools repositories, which are not enabled by default. +They can be enabled by running: + +.. code-block:: console + + $ sudo dnf install 'dnf-command(config-manager)' epel-release -y + $ sudo dnf config-manager --set-enabled crb + +.. note:: This step may be slightly different depending on the distribution you are using. + `Check the EPEL documentation `_ + +Install prerequisites +^^^^^^^^^^^^^^^^^^^^^ + +There are a few packages that must be installed in order to get and unpack the binary release. + +.. code-block:: console + + $ sudo dnf install tar bzip2 wget -y + +Install development tools (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you are going to build ROS packages or otherwise do development, you can also install the development tools: + +.. code-block:: console + + $ sudo dnf install -y \ + cmake \ + gcc-c++ \ + git \ + make \ + patch \ + python3-colcon-common-extensions \ + python3-mypy \ + python3-pip \ + python3-pytest \ + python3-pytest-repeat \ + python3-pytest-rerunfailures \ + python3-rosdep \ + python3-setuptools \ + python3-vcstool \ + wget + +Install ROS 2 +------------- + +Binary releases of Rolling Ridley are not provided. +Instead you may download nightly :ref:`prerelease binaries `. + +* Download the latest package for RHEL; let's assume that it ends up at ``~/Downloads/ros2-package-linux-x86_64.tar.bz2``. + + * Note: there may be more than one binary download option which might cause the file name to differ. + +* Unpack it: + + .. code-block:: console + + $ mkdir -p ~/ros2_{DISTRO} + $ cd ~/ros2_{DISTRO} + $ tar xf ~/Downloads/ros2-package-linux-x86_64.tar.bz2 + +Install dependencies using rosdep +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: ../_Dnf-Update-Admonition.rst + +.. code-block:: console + + $ sudo rosdep init + $ rosdep update + $ rosdep install --from-paths ~/ros2_{DISTRO}/ros2-linux/share --ignore-src -y --skip-keys "cyclonedds fastcdr fastdds iceoryx_binding_c rti-connext-dds-7.7.0 urdfdom_headers" + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. +See the :doc:`guide <../RMW-Implementations/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. + +Setup environment +----------------- + +Set up your environment by sourcing the following file. + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + +Try some examples +----------------- + +In one terminal, source the setup file and then run a C++ ``talker``: + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``: + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :doc:`here <../Installation-Troubleshooting>`. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst index 1578d965203..6f690ff9ec7 100644 --- a/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst @@ -1,201 +1,202 @@ -.. redirect-from:: - - Installation/Linux-Development-Setup - Installation/Ubuntu-Development-Setup - -Ubuntu (source) -=============== - -.. contents:: Table of Contents - :depth: 2 - :local: - - -System requirements -------------------- -The current Debian-based target platforms for {DISTRO_TITLE_FULL} are: - -- Tier 1: Ubuntu Linux - Resolute (26.04) 64-bit -- Tier 3: Ubuntu Linux - Noble (24.04) 64-bit -- Tier 3: Debian Linux - Trixie (13) 64-bit - -As defined in `REP 2000 `_. - -System setup ------------- - -Set locale -^^^^^^^^^^ - -.. include:: ../_Ubuntu-Set-Locale.rst - -Enable required repositories -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: ../_Apt-Repositories.rst - -Install development tools -^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ sudo apt update && sudo apt install -y \ - python3-mypy \ - python3-pip \ - python3-pytest \ - python3-pytest-cov \ - python3-pytest-mock \ - python3-pytest-repeat \ - python3-pytest-rerunfailures \ - python3-pytest-runner \ - python3-pytest-timeout \ - ros-dev-tools - -Build ROS 2 ------------ - -Get ROS 2 code -^^^^^^^^^^^^^^ - -Create a workspace and clone all repos: - -.. code-block:: console - - $ mkdir -p ~/ros2_{DISTRO}/src - $ cd ~/ros2_{DISTRO} - $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src - -.. _linux-development-setup-install-dependencies-using-rosdep: - -Install dependencies using rosdep -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: ../_Apt-Upgrade-Admonition.rst - -.. code-block:: console - - $ sudo rosdep init - $ rosdep update - $ rosdep install --from-paths src --ignore-src -y --skip-keys "fastcdr rti-connext-dds-7.7.0 urdfdom_headers" - -.. include:: ../_rosdep_Linux_Mint.rst - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Install colcon mixins -^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ colcon mixin add default https://github.com/colcon/colcon-defaults/raw/master/index.yaml - $ colcon mixin update default - -Build the code in the workspace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have already installed ROS 2 another way (either via debs or the binary distribution), make sure that you run the below commands in a fresh environment that does not have those other installations sourced. -Also ensure that you do not have ``source /opt/ros/${ROS_DISTRO}/setup.bash`` in your ``.bashrc``. -You can make sure that ROS 2 is not sourced with the command ``printenv | grep -i ROS``. -The output should be empty. - -More info on working with a ROS workspace can be found in :doc:`this tutorial <../../Tutorials/Beginner-Client-Libraries/Colcon-Tutorial>`. - -.. code-block:: console - - $ cd ~/ros2_{DISTRO}/ - $ colcon build --symlink-install --mixin release - -.. note:: - - If you are having trouble compiling all examples and this is preventing you from completing a successful build, you can use the ``--packages-skip`` colcon flag to ignore the package that is causing problems. - For instance, if you don't want to install the large OpenCV library, you could skip building the packages that depend on it using the command: - - .. code-block:: console - - $ colcon build --symlink-install --packages-skip image_tools intra_process_demo - -Setup environment ------------------ - -Set up your environment by sourcing the following file. - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/local_setup.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - -.. _talker-listener: - -Try some examples ------------------ - -In one terminal, source the setup file and then run a C++ ``talker``\ : - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/local_setup.bash - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``\ : - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/local_setup.bash - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Alternate compilers -------------------- - -Using a different compiler besides gcc to compile ROS 2 is easy. -If you set the environment variables ``CC`` and ``CXX`` to executables for a working C and C++ compiler, respectively, and retrigger CMake configuration (by using ``--cmake-force-configure`` or by deleting the packages you want to be affected), CMake will reconfigure and use the different compiler. - -Clang -^^^^^ - -To configure CMake to detect and use Clang: - -.. code-block:: console - - $ sudo apt install clang - $ export CC=clang - $ export CXX=clang++ - $ colcon build --cmake-force-configure - -Stay up to date ---------------- - -See :doc:`../Maintaining-a-Source-Checkout` to periodically refresh your source installation. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :ref:`here `. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rm -rf ~/ros2_{DISTRO} +.. redirect-from:: + + Installation/Linux-Development-Setup + Installation/Ubuntu-Development-Setup + Installation/Alternatives/Ubuntu-Development-Setup + +Ubuntu (source) +=============== + +.. contents:: Table of Contents + :depth: 2 + :local: + + +System requirements +------------------- +The current Debian-based target platforms for {DISTRO_TITLE_FULL} are: + +- Tier 1: Ubuntu Linux - Resolute (26.04) 64-bit +- Tier 3: Ubuntu Linux - Noble (24.04) 64-bit +- Tier 3: Debian Linux - Trixie (13) 64-bit + +As defined in `REP 2000 `_. + +System setup +------------ + +Set locale +^^^^^^^^^^ + +.. include:: ../_Ubuntu-Set-Locale.rst + +Enable required repositories +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: ../_Apt-Repositories.rst + +Install development tools +^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ sudo apt update && sudo apt install -y \ + python3-mypy \ + python3-pip \ + python3-pytest \ + python3-pytest-cov \ + python3-pytest-mock \ + python3-pytest-repeat \ + python3-pytest-rerunfailures \ + python3-pytest-runner \ + python3-pytest-timeout \ + ros-dev-tools + +Build ROS 2 +----------- + +Get ROS 2 code +^^^^^^^^^^^^^^ + +Create a workspace and clone all repos: + +.. code-block:: console + + $ mkdir -p ~/ros2_{DISTRO}/src + $ cd ~/ros2_{DISTRO} + $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src + +.. _linux-development-setup-install-dependencies-using-rosdep: + +Install dependencies using rosdep +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: ../_Apt-Upgrade-Admonition.rst + +.. code-block:: console + + $ sudo rosdep init + $ rosdep update + $ rosdep install --from-paths src --ignore-src -y --skip-keys "fastcdr rti-connext-dds-7.7.0 urdfdom_headers" + +.. include:: ../_rosdep_Linux_Mint.rst + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. +See the :doc:`guide <../RMW-Implementations/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. + +Install colcon mixins +^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ colcon mixin add default https://github.com/colcon/colcon-defaults/raw/master/index.yaml + $ colcon mixin update default + +Build the code in the workspace +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have already installed ROS 2 another way (either via debs or the binary distribution), make sure that you run the below commands in a fresh environment that does not have those other installations sourced. +Also ensure that you do not have ``source /opt/ros/${ROS_DISTRO}/setup.bash`` in your ``.bashrc``. +You can make sure that ROS 2 is not sourced with the command ``printenv | grep -i ROS``. +The output should be empty. + +More info on working with a ROS workspace can be found in :doc:`this tutorial <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>`. + +.. code-block:: console + + $ cd ~/ros2_{DISTRO}/ + $ colcon build --symlink-install --mixin release + +.. note:: + + If you are having trouble compiling all examples and this is preventing you from completing a successful build, you can use the ``--packages-skip`` colcon flag to ignore the package that is causing problems. + For instance, if you don't want to install the large OpenCV library, you could skip building the packages that depend on it using the command: + + .. code-block:: console + + $ colcon build --symlink-install --packages-skip image_tools intra_process_demo + +Setup environment +----------------- + +Set up your environment by sourcing the following file. + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/local_setup.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + +.. _talker-listener: + +Try some examples +----------------- + +In one terminal, source the setup file and then run a C++ ``talker``\ : + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/local_setup.bash + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``\ : + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/local_setup.bash + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Alternate compilers +------------------- + +Using a different compiler besides gcc to compile ROS 2 is easy. +If you set the environment variables ``CC`` and ``CXX`` to executables for a working C and C++ compiler, respectively, and retrigger CMake configuration (by using ``--cmake-force-configure`` or by deleting the packages you want to be affected), CMake will reconfigure and use the different compiler. + +Clang +^^^^^ + +To configure CMake to detect and use Clang: + +.. code-block:: console + + $ sudo apt install clang + $ export CC=clang + $ export CXX=clang++ + $ colcon build --cmake-force-configure + +Stay up to date +--------------- + +See :doc:`Maintaining-a-Source-Checkout` to periodically refresh your source installation. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :ref:`here `. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst index 162146d5e31..471a7cbf0b1 100644 --- a/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst +++ b/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst @@ -1,157 +1,158 @@ -.. redirect-from:: - - Installation/Linux-Install-Binary - -Ubuntu (binary) -=============== - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page explains how to install ROS 2 on Ubuntu Linux from a pre-built binary package. - -.. note:: - - The pre-built binary does not include all ROS 2 packages. - All packages in the `ROS base variant `_ are included, and only a subset of packages in the `ROS desktop variant `_ are included. - The exact list of packages are described by the repositories listed in `this ros2.repos file `_. - -There are also :doc:`deb packages <../Ubuntu-Install-Debs>` available. - -System requirements -------------------- - -We currently support Ubuntu Resolute (26.04) 64-bit x86 and 64-bit ARM. -The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. -Most people will want to use a stable ROS distribution. - -System setup ------------- - -Set locale -^^^^^^^^^^ - -.. include:: ../_Ubuntu-Set-Locale.rst - -Enable required repositories -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: ../_Apt-Repositories.rst - -Install prerequisites -^^^^^^^^^^^^^^^^^^^^^ - -There are a few packages that must be installed in order to get and unpack the binary release. - -.. code-block:: console - - $ sudo apt install tar bzip2 wget -y - -Install development tools (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you are going to build ROS packages or otherwise do development, you can also install the development tools: - -.. code-block:: console - - $ sudo apt update && sudo apt install ros-dev-tools - -Install ROS 2 -------------- - -Binary releases of Rolling Ridley are not provided. -Instead you may download nightly :ref:`prerelease binaries `. - -* Download the latest package for Ubuntu; let's assume that it ends up at ``~/Downloads/ros2-package-linux-x86_64.tar.bz2``. - - * Note: there may be more than one binary download option which might cause the file name to differ. - -* - Unpack it: - - .. code-block:: console - - $ mkdir -p ~/ros2_{DISTRO} - $ cd ~/ros2_{DISTRO} - $ tar xf ~/Downloads/ros2-package-linux-x86_64.tar.bz2 - -.. _linux-install-binary-install-missing-dependencies: - -Install dependencies using rosdep -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: ../_Apt-Upgrade-Admonition.rst - -.. code-block:: console - - $ sudo apt update - $ sudo apt install -y python3-rosdep - $ sudo rosdep init - $ rosdep update - $ rosdep install --from-paths ~/ros2_{DISTRO}/ros2-linux/share --ignore-src -y --skip-keys "cyclonedds fastcdr fastdds iceoryx_binding_c rmw_connextdds rti-connext-dds-7.7.0 urdfdom_headers" - -.. include:: ../_rosdep_Linux_Mint.rst - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Setup environment ------------------ - -Set up your environment by sourcing the following file. - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - -Try some examples ------------------ - -In one terminal, source the setup file and then run a C++ ``talker``: - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``: - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :doc:`here <../../How-To-Guides/Installation-Troubleshooting>`. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rm -rf ~/ros2_{DISTRO} +.. redirect-from:: + + Installation/Linux-Install-Binary + Installation/Alternatives/Ubuntu-Install-Binary + +Ubuntu (binary) +=============== + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page explains how to install ROS 2 on Ubuntu Linux from a pre-built binary package. + +.. note:: + + The pre-built binary does not include all ROS 2 packages. + All packages in the `ROS base variant `_ are included, and only a subset of packages in the `ROS desktop variant `_ are included. + The exact list of packages are described by the repositories listed in `this ros2.repos file `_. + +There are also :doc:`deb packages <../Ubuntu-Install-Debs>` available. + +System requirements +------------------- + +We currently support Ubuntu Resolute (26.04) 64-bit x86 and 64-bit ARM. +The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. +Most people will want to use a stable ROS distribution. + +System setup +------------ + +Set locale +^^^^^^^^^^ + +.. include:: ../_Ubuntu-Set-Locale.rst + +Enable required repositories +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: ../_Apt-Repositories.rst + +Install prerequisites +^^^^^^^^^^^^^^^^^^^^^ + +There are a few packages that must be installed in order to get and unpack the binary release. + +.. code-block:: console + + $ sudo apt install tar bzip2 wget -y + +Install development tools (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you are going to build ROS packages or otherwise do development, you can also install the development tools: + +.. code-block:: console + + $ sudo apt update && sudo apt install ros-dev-tools + +Install ROS 2 +------------- + +Binary releases of Rolling Ridley are not provided. +Instead you may download nightly :ref:`prerelease binaries `. + +* Download the latest package for Ubuntu; let's assume that it ends up at ``~/Downloads/ros2-package-linux-x86_64.tar.bz2``. + + * Note: there may be more than one binary download option which might cause the file name to differ. + +* + Unpack it: + + .. code-block:: console + + $ mkdir -p ~/ros2_{DISTRO} + $ cd ~/ros2_{DISTRO} + $ tar xf ~/Downloads/ros2-package-linux-x86_64.tar.bz2 + +.. _linux-install-binary-install-missing-dependencies: + +Install dependencies using rosdep +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: ../_Apt-Upgrade-Admonition.rst + +.. code-block:: console + + $ sudo apt update + $ sudo apt install -y python3-rosdep + $ sudo rosdep init + $ rosdep update + $ rosdep install --from-paths ~/ros2_{DISTRO}/ros2-linux/share --ignore-src -y --skip-keys "cyclonedds fastcdr fastdds iceoryx_binding_c rmw_connextdds rti-connext-dds-7.7.0 urdfdom_headers" + +.. include:: ../_rosdep_Linux_Mint.rst + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. +See the :doc:`guide <../RMW-Implementations/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. + +Setup environment +----------------- + +Set up your environment by sourcing the following file. + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + +Try some examples +----------------- + +In one terminal, source the setup file and then run a C++ ``talker``: + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``: + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/ros2-linux/setup.bash + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :doc:`here <../Installation-Troubleshooting>`. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst index 3e99a47d6da..3e43d252348 100644 --- a/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst @@ -1,277 +1,278 @@ -.. redirect-from:: - - Installation/Windows-Development-Setup - -Windows (source) -================ - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page explains how to setup a development environment for ROS 2 on Windows. - -System requirements -------------------- - -Language support -^^^^^^^^^^^^^^^^ - -Make sure you have a locale which supports ``UTF-8``. -For example, for a Chinese-language Windows installation, you may need to install an `English language pack `_. - -Create a location for the ROS 2 installation --------------------------------------------- - -This location will contain both the installed binary packages, plus the ROS 2 installation itself. - -Start an Administrator Command Prompt session (usually by clicking on the start menu, then typing ``command prompt``, then right-click and ``Run as administrator``). - -Then create a directory to store the installation. -Because of Windows path-length limitations, this should be as short as possible. -We'll use ``C:\dev`` for the rest of these instructions. - -.. code-block:: console - - $ mkdir C:\dev - -Increase the Windows maximum path length ----------------------------------------- - -By default, Windows is restricted to a maximum path length (MAX_PATH) of 260 characters. -The ROS 2 build will use significantly longer path lengths, so we will increase that. -Using the session you started above, run the following: - -.. code-block:: console - - $ powershell New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force -.. note:: - - Execute as administrator. - -You can read more about this limitation in `Microsoft's documentation `__. - -Close the administrator terminal and follow using a new Command Prompt session. - -Install prerequisites ---------------------- - -Install MSVC -^^^^^^^^^^^^ - -In order to compile the ROS 2 code, the MSVC compiler must be installed. -Currently it is recommended to use MSVC 2022. - -Continue using the previous session, and run the following command to download it: - -.. code-block:: console - - $ powershell irm https://aka.ms/vs/17/release/vs_buildtools.exe -OutFile vs_buildtools_2022.exe - -Now install MSVC 2022: - -.. code-block:: console - - $ .\vs_buildtools_2022.exe --quiet --wait --norestart --add Microsoft.Component.MSBuild --add Microsoft.Net.Component.4.6.1.TargetingPack --add Microsoft.Net.Component.4.8.SDK --add Microsoft.VisualStudio.Component.CoreBuildTools --add Microsoft.VisualStudio.Component.Roslyn.Compiler --add Microsoft.VisualStudio.Component.TextTemplating --add Microsoft.VisualStudio.Component.VC.CLI.Support --add Microsoft.VisualStudio.Component.VC.CoreBuildTools --add Microsoft.VisualStudio.Component.VC.CoreIde --add Microsoft.VisualStudio.Component.VC.Redist.14.Latest --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.Windows11SDK --add Microsoft.VisualStudio.Component.Windows11SDK.22621 --add Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core --add Microsoft.VisualStudio.Workload.MSBuildTools --add Microsoft.VisualStudio.Workload.VCTools - -.. note:: - - The installation of MSVC can take a long time, and there is no feedback while it is progressing. - -Install pixi -^^^^^^^^^^^^ - -ROS 2 uses `conda-forge `__ as a backend for packages, with `pixi `__ as the frontend. - -.. note:: - - The installation of conda-forge may trigger Windows Defender to treat it as a threat, but this can be safely ignored by clicking "More info" and "Run anyway". - -Use use the instructions on https://pixi.sh/latest/ to install ``pixi`` either with the Windows Installer or using command line in your opened Command Prompt terminal. - -Once ``pixi`` has been installed, close the Command Prompt session and start it again, which will ensure ``pixi`` is on the PATH. - -Install dependencies -^^^^^^^^^^^^^^^^^^^^ - -Download the pixi configuration file in the existing Command Prompt session: - -.. code-block:: console - - $ cd C:\dev - $ powershell irm https://raw.githubusercontent.com/ros2/ros2/refs/heads/{REPOS_FILE_BRANCH}/pixi.toml -OutFile pixi.toml - -Install dependencies: - -.. code-block:: console - - $ pixi install - - -Build ROS 2 ------------ - -You can use the same Windows Command Prompt for the build. - -Source the MSVC compiler -^^^^^^^^^^^^^^^^^^^^^^^^ - -This is required in the Command Prompt you'll use to compile ROS 2, but it is *not* required when running: - -.. code-block:: console - - $ call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64 - -Source the pixi environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This is required in every Command Prompt you open to set up paths to the dependencies: - -.. code-block:: console - - $ cd C:\dev - $ pixi shell - -Get ROS 2 code -^^^^^^^^^^^^^^ - -Now that we have the development tools we can get the ROS 2 source code. - -Setup a development folder, for example ``C:\dev\{DISTRO}``: - -.. code-block:: console - - $ md C:\dev\{DISTRO}\src - $ cd C:\dev\{DISTRO} - -Get the ``ros2.repos`` file which defines the repositories to clone from: - -.. code-block:: console - - $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Build the code in the workspace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. _windows-dev-build-ros2: - -To build the ``\{DISTRO}`` folder tree: - -.. code-block:: console - - $ colcon build --merge-install - -.. note:: - - We're using ``--merge-install`` here to avoid a ``PATH`` variable that is too long at the end of the build. - If you're adapting these instructions to build a smaller workspace then you might be able to use the default behavior which is isolated install, i.e. where each package is installed to a different folder. - -.. note:: - - Source installation can take a long time given the large number of packages being pulled into the workspace. - -Setup environment ------------------ - -Start a new Windows Command Prompt, which will be used in the examples. - -Source the pixi environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This is required in every Command Prompt you open to set up paths to the dependencies: - -.. code-block:: console - - $ cd C:\dev - $ pixi shell - -Source the ROS 2 environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This is required in every Command Prompt you open to setup the ROS 2 workspace: - -.. code-block:: console - - $ call C:\dev\{DISTRO}\install\local_setup.bat - -This will automatically set up the environment for any DDS vendors that support was built for. - -It is normal that the previous command, if nothing else went wrong, outputs ``The system cannot find the path specified.`` exactly once. - -Try some examples ------------------ - -Note that the first time you run any executable you will have to allow access to the network through a Windows Firewall popup. - -You can run the tests using this command: - -.. code-block:: console - - $ cd C:\dev\{DISTRO} - $ colcon test --merge-install - -.. note:: - - ``--merge-install`` should only be used if it was also used in the build step. - -Afterwards you can get a summary of the tests using this command: - -.. code-block:: console - - $ colcon test-result - -To run the examples, first open a clean new Command Prompt and set up the workspace by sourcing the ``local_setup.bat`` file. -Then, run a C++ ``talker``\ : - -.. code-block:: console - - $ call install\local_setup.bat - $ ros2 run demo_nodes_cpp talker - -In a separate Command Prompt you can do the same, but instead run a Python ``listener``\ : - -.. code-block:: console - - $ call install\local_setup.bat - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -.. note:: - - It is not recommended to build in the same Command Prompt that you've sourced the ``local_setup.bat``. - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Stay up to date ---------------- - -See :doc:`../Maintaining-a-Source-Checkout` to periodically refresh your source installation. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :ref:`here `. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rmdir /s /q C:\dev\{DISTRO} +.. redirect-from:: + + Installation/Windows-Development-Setup + Installation/Alternatives/Windows-Development-Setup + +Windows (source) +================ + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page explains how to setup a development environment for ROS 2 on Windows. + +System requirements +------------------- + +Language support +^^^^^^^^^^^^^^^^ + +Make sure you have a locale which supports ``UTF-8``. +For example, for a Chinese-language Windows installation, you may need to install an `English language pack `_. + +Create a location for the ROS 2 installation +-------------------------------------------- + +This location will contain both the installed binary packages, plus the ROS 2 installation itself. + +Start an Administrator Command Prompt session (usually by clicking on the start menu, then typing ``command prompt``, then right-click and ``Run as administrator``). + +Then create a directory to store the installation. +Because of Windows path-length limitations, this should be as short as possible. +We'll use ``C:\dev`` for the rest of these instructions. + +.. code-block:: console + + $ mkdir C:\dev + +Increase the Windows maximum path length +---------------------------------------- + +By default, Windows is restricted to a maximum path length (MAX_PATH) of 260 characters. +The ROS 2 build will use significantly longer path lengths, so we will increase that. +Using the session you started above, run the following: + +.. code-block:: console + + $ powershell New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force +.. note:: + + Execute as administrator. + +You can read more about this limitation in `Microsoft's documentation `__. + +Close the administrator terminal and follow using a new Command Prompt session. + +Install prerequisites +--------------------- + +Install MSVC +^^^^^^^^^^^^ + +In order to compile the ROS 2 code, the MSVC compiler must be installed. +Currently it is recommended to use MSVC 2022. + +Continue using the previous session, and run the following command to download it: + +.. code-block:: console + + $ powershell irm https://aka.ms/vs/17/release/vs_buildtools.exe -OutFile vs_buildtools_2022.exe + +Now install MSVC 2022: + +.. code-block:: console + + $ .\vs_buildtools_2022.exe --quiet --wait --norestart --add Microsoft.Component.MSBuild --add Microsoft.Net.Component.4.6.1.TargetingPack --add Microsoft.Net.Component.4.8.SDK --add Microsoft.VisualStudio.Component.CoreBuildTools --add Microsoft.VisualStudio.Component.Roslyn.Compiler --add Microsoft.VisualStudio.Component.TextTemplating --add Microsoft.VisualStudio.Component.VC.CLI.Support --add Microsoft.VisualStudio.Component.VC.CoreBuildTools --add Microsoft.VisualStudio.Component.VC.CoreIde --add Microsoft.VisualStudio.Component.VC.Redist.14.Latest --add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --add Microsoft.VisualStudio.Component.Windows11SDK --add Microsoft.VisualStudio.Component.Windows11SDK.22621 --add Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core --add Microsoft.VisualStudio.Workload.MSBuildTools --add Microsoft.VisualStudio.Workload.VCTools + +.. note:: + + The installation of MSVC can take a long time, and there is no feedback while it is progressing. + +Install pixi +^^^^^^^^^^^^ + +ROS 2 uses `conda-forge `__ as a backend for packages, with `pixi `__ as the frontend. + +.. note:: + + The installation of conda-forge may trigger Windows Defender to treat it as a threat, but this can be safely ignored by clicking "More info" and "Run anyway". + +Use use the instructions on https://pixi.sh/latest/ to install ``pixi`` either with the Windows Installer or using command line in your opened Command Prompt terminal. + +Once ``pixi`` has been installed, close the Command Prompt session and start it again, which will ensure ``pixi`` is on the PATH. + +Install dependencies +^^^^^^^^^^^^^^^^^^^^ + +Download the pixi configuration file in the existing Command Prompt session: + +.. code-block:: console + + $ cd C:\dev + $ powershell irm https://raw.githubusercontent.com/ros2/ros2/refs/heads/{REPOS_FILE_BRANCH}/pixi.toml -OutFile pixi.toml + +Install dependencies: + +.. code-block:: console + + $ pixi install + + +Build ROS 2 +----------- + +You can use the same Windows Command Prompt for the build. + +Source the MSVC compiler +^^^^^^^^^^^^^^^^^^^^^^^^ + +This is required in the Command Prompt you'll use to compile ROS 2, but it is *not* required when running: + +.. code-block:: console + + $ call "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64 + +Source the pixi environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is required in every Command Prompt you open to set up paths to the dependencies: + +.. code-block:: console + + $ cd C:\dev + $ pixi shell + +Get ROS 2 code +^^^^^^^^^^^^^^ + +Now that we have the development tools we can get the ROS 2 source code. + +Setup a development folder, for example ``C:\dev\{DISTRO}``: + +.. code-block:: console + + $ md C:\dev\{DISTRO}\src + $ cd C:\dev\{DISTRO} + +Get the ``ros2.repos`` file which defines the repositories to clone from: + +.. code-block:: console + + $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. +See the :doc:`guide <../RMW-Implementations/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. + +Build the code in the workspace +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. _windows-dev-build-ros2: + +To build the ``\{DISTRO}`` folder tree: + +.. code-block:: console + + $ colcon build --merge-install + +.. note:: + + We're using ``--merge-install`` here to avoid a ``PATH`` variable that is too long at the end of the build. + If you're adapting these instructions to build a smaller workspace then you might be able to use the default behavior which is isolated install, i.e. where each package is installed to a different folder. + +.. note:: + + Source installation can take a long time given the large number of packages being pulled into the workspace. + +Setup environment +----------------- + +Start a new Windows Command Prompt, which will be used in the examples. + +Source the pixi environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is required in every Command Prompt you open to set up paths to the dependencies: + +.. code-block:: console + + $ cd C:\dev + $ pixi shell + +Source the ROS 2 environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is required in every Command Prompt you open to setup the ROS 2 workspace: + +.. code-block:: console + + $ call C:\dev\{DISTRO}\install\local_setup.bat + +This will automatically set up the environment for any DDS vendors that support was built for. + +It is normal that the previous command, if nothing else went wrong, outputs ``The system cannot find the path specified.`` exactly once. + +Try some examples +----------------- + +Note that the first time you run any executable you will have to allow access to the network through a Windows Firewall popup. + +You can run the tests using this command: + +.. code-block:: console + + $ cd C:\dev\{DISTRO} + $ colcon test --merge-install + +.. note:: + + ``--merge-install`` should only be used if it was also used in the build step. + +Afterwards you can get a summary of the tests using this command: + +.. code-block:: console + + $ colcon test-result + +To run the examples, first open a clean new Command Prompt and set up the workspace by sourcing the ``local_setup.bat`` file. +Then, run a C++ ``talker``\ : + +.. code-block:: console + + $ call install\local_setup.bat + $ ros2 run demo_nodes_cpp talker + +In a separate Command Prompt you can do the same, but instead run a Python ``listener``\ : + +.. code-block:: console + + $ call install\local_setup.bat + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +.. note:: + + It is not recommended to build in the same Command Prompt that you've sourced the ``local_setup.bat``. + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Stay up to date +--------------- + +See :doc:`Maintaining-a-Source-Checkout` to periodically refresh your source installation. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :ref:`here `. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rmdir /s /q C:\dev\{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst index 93cad3652a5..3c48f3869ed 100644 --- a/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst @@ -1,217 +1,218 @@ -.. redirect-from:: - - Installation/Rolling/OSX-Development-Setup - Installation/macOS-Development-Setup - -macOS (source) -============== - -.. contents:: Table of Contents - :depth: 2 - :local: - -System requirements -------------------- - -We currently support macOS Mojave (10.14). -The Rolling Ridley distribution will change target platforms from time to time as new platforms become available. -Most people will want to use a stable ROS distribution. - -System setup ------------- - -Install prerequisites -^^^^^^^^^^^^^^^^^^^^^ - -You need the following things installed to build ROS 2: - - -#. - **Xcode** - - * If you don't already have it installed, install `Xcode `_. - * Note: Versions of Xcode later than 11.3.1 can no longer be installed on macOS Mojave, so you will need to install an older version manually, see: https://stackoverflow.com/a/61046761 - * Also, if you don't already have it installed, install the Command Line Tools: - - .. code-block:: console - - $ xcode-select --install - $ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer - - .. note:: - - If you installed Xcode.app manually, you need to accept the Xcode.app license. - You can do this by opening Xcode.app or running: - - .. code-block:: console - - $ sudo xcodebuild -license - -#. - **brew** *(needed to install more stuff; you probably already have this)*: - - - * Follow installation instructions at http://brew.sh/ - * - *Optional*: Check that ``brew`` is happy with your system configuration by running: - - .. code-block:: console - - $ brew doctor - - Fix any problems that it identifies. - -#. - Use ``brew`` to install more stuff: - - .. code-block:: console - - $ brew install asio assimp bison bullet cmake console_bridge cppcheck \ - cunit eigen freetype graphviz opencv openssl orocos-kdl pcre poco \ - pyqt@5 python qt@5 sip spdlog tinyxml2 - -#. - Setup some environment variables: - - .. code-block:: console - - ~ Add the openssl dir for DDS-Security - ~ if you are using BASH, then replace '.zshrc' with '.bashrc' - $ echo "export OPENSSL_ROOT_DIR=$(brew --prefix openssl)" >> ~/.zshrc - - ~ Add the Qt directory to the PATH and CMAKE_PREFIX_PATH - $ export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$(brew --prefix qt@5) - $ export PATH=$PATH:$(brew --prefix qt@5)/bin - -#. - Use ``python3 -m pip`` (just ``pip`` may install Python3 or Python2) to install more stuff: - - .. code-block:: console - - $ python3 -m pip install --upgrade pip - - $ python3 -m pip install -U \ - --config-settings="--global-option=build_ext" \ - --config-settings="--global-option=-I$(brew --prefix graphviz)/include/" \ - --config-settings="--global-option=-L$(brew --prefix graphviz)/lib/" \ - argcomplete catkin_pkg colcon-common-extensions coverage \ - cryptography empy flake8 flake8-blind-except==0.1.1 flake8-builtins \ - flake8-class-newline flake8-comprehensions flake8-deprecated \ - flake8-import-order flake8-quotes \ - importlib-metadata jsonschema lark==1.1.1 lxml matplotlib mock mypy==0.931 netifaces \ - psutil pydot pygraphviz pyparsing==2.4.7 \ - pytest-mock rosdep rosdistro setuptools==59.6.0 vcstool - - Please ensure that the ``$PATH`` environment variable contains the install location of the binaries (``$(brew --prefix)/bin``) - -#. - *Optional*: if you want to build the ROS 1<->2 bridge, then you must also install ROS 1: - - - * Start with the normal install instructions: http://wiki.ros.org/kinetic/Installation/OSX/Homebrew/Source - * - When you get to the step where you call ``rosinstall_generator`` to get the source code, here's an alternate invocation that brings in just the minimum required to produce a useful bridge: - - .. code-block:: console - - $ rosinstall_generator catkin common_msgs roscpp rosmsg --rosdistro kinetic --deps --wet-only --tar > kinetic-ros2-bridge-deps.rosinstall - $ wstool init -j8 src kinetic-ros2-bridge-deps.rosinstall - - - Otherwise, just follow the normal instructions, then source the resulting ``install_isolated/setup.bash`` before proceeding here to build ROS 2. - -Disable System Integrity Protection (SIP) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -macOS/OS X versions >=10.11 have System Integrity Protection enabled by default. -So that SIP doesn't prevent processes from inheriting dynamic linker environment variables, such as ``DYLD_LIBRARY_PATH``, you'll need to disable it `following these instructions `__. - -Build ROS 2 ------------ - -Get ROS 2 code -^^^^^^^^^^^^^^ - -Create a workspace and clone all repos: - -.. code-block:: console - - $ mkdir -p ~/ros2_{DISTRO}/src - $ cd ~/ros2_{DISTRO} - $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Build the code in the workspace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Run the ``colcon`` tool to build everything (more on using ``colcon`` in :doc:`this tutorial <../../Tutorials/Beginner-Client-Libraries/Colcon-Tutorial>`): - -.. code-block:: console - - $ cd ~/ros2_{DISTRO}/ - $ colcon build --symlink-install --packages-skip-by-dep python_qt_binding - -Note: due to an unresolved issue with SIP, Qt@5, and PyQt5, we need to disable ``python_qt_binding`` to have the build succeed. -This will be removed when the issue is resolved, see: https://github.com/ros-visualization/python_qt_binding/issues/103 - -Setup environment ------------------ - -Source the ROS 2 setup file: - -.. code-block:: console - - $ . ~/ros2_{DISTRO}/install/setup.zsh - -This will automatically set up the environment for any DDS vendors that support was built for. - -Try some examples ------------------ - -In one terminal, set up the ROS 2 environment as described above and then run a C++ ``talker``: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``: - -.. code-block:: console - - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -Next steps ----------- - -Continue with the `tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Stay up to date ---------------- - -See :doc:`../Maintaining-a-Source-Checkout` to periodically refresh your source installation. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :ref:`here `. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rm -rf ~/ros2_{DISTRO} +.. redirect-from:: + + Installation/Rolling/OSX-Development-Setup + Installation/macOS-Development-Setup + Installation/Alternatives/macOS-Development-Setup + +macOS (source) +============== + +.. contents:: Table of Contents + :depth: 2 + :local: + +System requirements +------------------- + +We currently support macOS Mojave (10.14). +The Rolling Ridley distribution will change target platforms from time to time as new platforms become available. +Most people will want to use a stable ROS distribution. + +System setup +------------ + +Install prerequisites +^^^^^^^^^^^^^^^^^^^^^ + +You need the following things installed to build ROS 2: + + +#. + **Xcode** + + * If you don't already have it installed, install `Xcode `_. + * Note: Versions of Xcode later than 11.3.1 can no longer be installed on macOS Mojave, so you will need to install an older version manually, see: https://stackoverflow.com/a/61046761 + * Also, if you don't already have it installed, install the Command Line Tools: + + .. code-block:: console + + $ xcode-select --install + $ sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer + + .. note:: + + If you installed Xcode.app manually, you need to accept the Xcode.app license. + You can do this by opening Xcode.app or running: + + .. code-block:: console + + $ sudo xcodebuild -license + +#. + **brew** *(needed to install more stuff; you probably already have this)*: + + + * Follow installation instructions at http://brew.sh/ + * + *Optional*: Check that ``brew`` is happy with your system configuration by running: + + .. code-block:: console + + $ brew doctor + + Fix any problems that it identifies. + +#. + Use ``brew`` to install more stuff: + + .. code-block:: console + + $ brew install asio assimp bison bullet cmake console_bridge cppcheck \ + cunit eigen freetype graphviz opencv openssl orocos-kdl pcre poco \ + pyqt@5 python qt@5 sip spdlog tinyxml2 + +#. + Setup some environment variables: + + .. code-block:: console + + ~ Add the openssl dir for DDS-Security + ~ if you are using BASH, then replace '.zshrc' with '.bashrc' + $ echo "export OPENSSL_ROOT_DIR=$(brew --prefix openssl)" >> ~/.zshrc + + ~ Add the Qt directory to the PATH and CMAKE_PREFIX_PATH + $ export CMAKE_PREFIX_PATH=$CMAKE_PREFIX_PATH:$(brew --prefix qt@5) + $ export PATH=$PATH:$(brew --prefix qt@5)/bin + +#. + Use ``python3 -m pip`` (just ``pip`` may install Python3 or Python2) to install more stuff: + + .. code-block:: console + + $ python3 -m pip install --upgrade pip + + $ python3 -m pip install -U \ + --config-settings="--global-option=build_ext" \ + --config-settings="--global-option=-I$(brew --prefix graphviz)/include/" \ + --config-settings="--global-option=-L$(brew --prefix graphviz)/lib/" \ + argcomplete catkin_pkg colcon-common-extensions coverage \ + cryptography empy flake8 flake8-blind-except==0.1.1 flake8-builtins \ + flake8-class-newline flake8-comprehensions flake8-deprecated \ + flake8-import-order flake8-quotes \ + importlib-metadata jsonschema lark==1.1.1 lxml matplotlib mock mypy==0.931 netifaces \ + psutil pydot pygraphviz pyparsing==2.4.7 \ + pytest-mock rosdep rosdistro setuptools==59.6.0 vcstool + + Please ensure that the ``$PATH`` environment variable contains the install location of the binaries (``$(brew --prefix)/bin``) + +#. + *Optional*: if you want to build the ROS 1<->2 bridge, then you must also install ROS 1: + + + * Start with the normal install instructions: http://wiki.ros.org/kinetic/Installation/OSX/Homebrew/Source + * + When you get to the step where you call ``rosinstall_generator`` to get the source code, here's an alternate invocation that brings in just the minimum required to produce a useful bridge: + + .. code-block:: console + + $ rosinstall_generator catkin common_msgs roscpp rosmsg --rosdistro kinetic --deps --wet-only --tar > kinetic-ros2-bridge-deps.rosinstall + $ wstool init -j8 src kinetic-ros2-bridge-deps.rosinstall + + + Otherwise, just follow the normal instructions, then source the resulting ``install_isolated/setup.bash`` before proceeding here to build ROS 2. + +Disable System Integrity Protection (SIP) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +macOS/OS X versions >=10.11 have System Integrity Protection enabled by default. +So that SIP doesn't prevent processes from inheriting dynamic linker environment variables, such as ``DYLD_LIBRARY_PATH``, you'll need to disable it `following these instructions `__. + +Build ROS 2 +----------- + +Get ROS 2 code +^^^^^^^^^^^^^^ + +Create a workspace and clone all repos: + +.. code-block:: console + + $ mkdir -p ~/ros2_{DISTRO}/src + $ cd ~/ros2_{DISTRO} + $ vcs import --input https://raw.githubusercontent.com/ros2/ros2/{REPOS_FILE_BRANCH}/ros2.repos src + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at build or runtime. +See the :doc:`guide <../RMW-Implementations/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. + +Build the code in the workspace +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Run the ``colcon`` tool to build everything (more on using ``colcon`` in :doc:`this tutorial <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>`): + +.. code-block:: console + + $ cd ~/ros2_{DISTRO}/ + $ colcon build --symlink-install --packages-skip-by-dep python_qt_binding + +Note: due to an unresolved issue with SIP, Qt@5, and PyQt5, we need to disable ``python_qt_binding`` to have the build succeed. +This will be removed when the issue is resolved, see: https://github.com/ros-visualization/python_qt_binding/issues/103 + +Setup environment +----------------- + +Source the ROS 2 setup file: + +.. code-block:: console + + $ . ~/ros2_{DISTRO}/install/setup.zsh + +This will automatically set up the environment for any DDS vendors that support was built for. + +Try some examples +----------------- + +In one terminal, set up the ROS 2 environment as described above and then run a C++ ``talker``: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``: + +.. code-block:: console + + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +Next steps +---------- + +Continue with the `tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Stay up to date +--------------- + +See :doc:`Maintaining-a-Source-Checkout` to periodically refresh your source installation. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :ref:`here `. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/Installation-Troubleshooting.rst b/source/Get-Started/Installation/Installation-Troubleshooting.rst index d47bfba4bc1..d7105b67c9a 100644 --- a/source/Get-Started/Installation/Installation-Troubleshooting.rst +++ b/source/Get-Started/Installation/Installation-Troubleshooting.rst @@ -1,363 +1,364 @@ -.. redirect-from:: - - Guides/Installation-Troubleshooting - Troubleshooting/Installation-Troubleshooting - -Installation troubleshooting -============================ - -Troubleshooting techniques for installation are sorted by the platforms they apply to. - -.. contents:: Platforms - :depth: 2 - :local: - -General -------- - -General troubleshooting techniques apply to all platforms. - -Enable multicast -^^^^^^^^^^^^^^^^ - -In order to communicate successfully via DDS, the used network interface has to be multicast enabled. -We've seen in past experiences that this might not necessarily be enabled by default (on Ubuntu or OSX) when using the loopback adapter. -See the `original issue `__ or a `conversation on ros-answers `__. -You can verify that your current setup allows multicast with the ROS 2 tool: - -In Terminal 1: - -.. code-block:: console - - $ ros2 multicast receive - -In Terminal 2: - -.. code-block:: console - - $ ros2 multicast send - -If the first command did not return a response similar to: - -.. code-block:: bash - - Received from xx.xxx.xxx.xx:43751: 'Hello World!' - -then you will need to update your firewall configuration to allow multicast using `ufw `__. - -.. code-block:: console - - $ sudo ufw allow in proto udp to 224.0.0.0/4 - $ sudo ufw allow in proto udp from 224.0.0.0/4 - - -You can check if the multicast flag is enabled for your network interface using the :code:`ifconfig` tool and looking for :code:`MULTICAST` in the flags section: - -.. code-block:: bash - - eno1: flags=4163<...,MULTICAST> - ... - -Import failing without library present on the system -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sometimes ``rclpy`` fails to be imported because the expected C extension libraries are not found. -If so, compare the libraries present in the directory with the one mentioned in the error message. -Assuming a file with a similar name exists (same prefix like ``_rclpy.`` and same suffix like ``.so`` but a different Python version / architecture) you are using a different Python interpreter than which was used to build the C extension. -Be sure to use the same Python interpreter as the one used to build the binary. - -For example, such a mismatch can crop up after an update of the OS. -Then, rebuilding the workspace may fix the issue. - -.. _linux-troubleshooting: - -Linux ------ - -Internal compiler error -^^^^^^^^^^^^^^^^^^^^^^^ - -If you experience an ICE when trying to compile on a memory constrained platform like a Raspberry PI you might want to build single threaded (prefix the build invocation with ``MAKEFLAGS=-j1``). - -Multiple host interference -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you're running multiple instances on the same network you may get interference. -To avoid this you can set the environment variable ``ROS_DOMAIN_ID`` to a different integer, the default is zero. -This will define the DDS domain id for your system. - -Exception sourcing setup.bash -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. only relevant to Eloquent and Foxy - -If you encounter exceptions when trying to source the environment after building from source, try to upgrade ``colcon`` related packages using - -.. code-block:: console - - $ colcon version-check # check if newer versions available - $ sudo apt install python3-colcon* --only-upgrade # upgrade installed colcon packages to latest version - -Mixing conda and apt Python Conflict -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While using ROS 2, mixing packages installed with ``apt`` with packages installed with ``conda`` does not work. -If you are using the official ``apt`` binaries for ROS 2, make sure that your ``PATH`` environment variable does not have any conda paths in it. -You may have to check your ``.bashrc`` for this line and comment it out. - -On the other hand on Windows, the official ROS 2 installation procedure uses ``conda`` packages via the ``pixi`` package manager, and that works fine as there is no mix of different package managers - -``conda`` packages for ROS 2 may be built (such as the one provided by the community-mantained `RoboStack `_ project) but no official conda packages for ROS 2 are provided. - -Cannot start rviz2 -^^^^^^^^^^^^^^^^^^ - -``rviz2`` may fail to start on a Wayland display system with errors like: - -.. code-block:: - - QSocketNotifier: Can only be used with threads started with QThread - [INFO] [1714730141.758659580] [rviz2]: Stereo is NOT SUPPORTED - [INFO] [1714730141.758813709] [rviz2]: OpenGl version: 3.1 (GLSL 1.4) - [ERROR] [1714730141.797879232] [rviz2]: rviz::RenderSystem: error creating render window: RenderingAPIException: Invalid parentWindowHandle (wrong server or screen) in GLXWindow::create at ./.obj-aarch64-linux-gnu/ogre_vendor-prefix/src/ogre_vendor/RenderSystems/GLSupport/src/GLX/OgreGLXWindow.cpp (line 246) - ... - [ERROR] [1714730141.808124283] [rviz2]: Unable to create the rendering window after 100 tries - terminate called after throwing an instance of 'std::runtime_error' - what(): Unable to create the rendering window after 100 tries - Aborted (core dumped) - -This is due to an incompatibility between Wayland and RViz2. -You may be able to workaround this problem by running RViz2 in X11 compatibility mode: - -.. code-block:: - - QT_QPA_PLATFORM=xcb rviz2 - -.. _macOS-troubleshooting: - -macOS ------ - -Segmentation fault when using ``pyenv`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``pyenv`` seems to default to building Python with ``.a`` files, but that causes issues with ``rclpy``, so it's recommended to build Python with Frameworks enabled on macOS when using ``pyenv``: - -https://github.com/pyenv/pyenv/wiki#how-to-build-cpython-with-framework-support-on-os-x - -Library not loaded; image not found -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you are seeing library loading issues at runtime (either running tests or running nodes), such as the following: - -.. code-block:: bash - - ImportError: dlopen(.../ros2_/ros2-osx/lib/python3.7/site-packages/rclpy/_rclpy.cpython-37m-darwin.so, 2): Library not loaded: @rpath/librcl_interfaces__rosidl_typesupport_c.dylib - Referenced from: .../ros2_/ros2-osx/lib/python3.7/site-packages/rclpy/_rclpy.cpython-37m-darwin.so - Reason: image not found - -Then you probably have System Integrity Protection enabled. -Follow `these instructions `__ to disable System Integrity Protection (SIP). - -Qt build error: ``unknown type name 'Q_ENUM'`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you see build errors related to Qt, e.g.: - -.. code-block:: bash - - In file included from /usr/local/opt/qt/lib/QtGui.framework/Headers/qguiapplication.h:46: - /usr/local/opt/qt/lib/QtGui.framework/Headers/qinputmethod.h:87:5: error: - unknown type name 'Q_ENUM' - Q_ENUM(Action) - ^ - -you may be using qt4 instead of qt5: see https://github.com/ros2/ros2/issues/441 - -Missing symbol when opencv (and therefore libjpeg, libtiff, and libpng) are installed with Homebrew -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have opencv installed you might get this: - -.. code-block:: bash - - dyld: Symbol not found: __cg_jpeg_resync_to_restart - Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO - Expected in: /usr/local/lib/libJPEG.dylib - in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO - /bin/sh: line 1: 25274 Trace/BPT trap: 5 /usr/local/bin/cmake - -If so, to build you'll have to do this: - -.. code-block:: console - - $ brew unlink libpng libtiff libjpeg - -But this will break opencv, so you'll also need to update it to continue working: - -.. code-block:: console - - $ sudo install_name_tool -change /usr/local/lib/libjpeg.8.dylib /usr/local/opt/jpeg/lib/libjpeg.8.dylib /usr/local/lib/libopencv_highgui.2.4.dylib - $ sudo install_name_tool -change /usr/local/lib/libpng16.16.dylib /usr/local/opt/libpng/lib/libpng16.16.dylib /usr/local/lib/libopencv_highgui.2.4.dylib - $ sudo install_name_tool -change /usr/local/lib/libtiff.5.dylib /usr/local/opt/libtiff/lib/libtiff.5.dylib /usr/local/lib/libopencv_highgui.2.4.dylib - $ sudo install_name_tool -change /usr/local/lib/libjpeg.8.dylib /usr/local/opt/jpeg/lib/libjpeg.8.dylib /usr/local/Cellar/libtiff/4.0.4/lib/libtiff.5.dylib - -The first command is necessary to avoid things built against the system libjpeg (etc.) from getting the version in /usr/local/lib. -The others are updating things built by Homebrew so that they can find the version of libjpeg (etc.) without having them in /usr/local/lib. - -Xcode-select error: tool ``xcodebuild`` requires Xcode, but active developer directory is a command line instance -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. only relevant to Eloquent and Foxy - -If you recently installed Xcode, you may encounter this error: - -.. code-block:: bash - - Xcode: xcode-select: error: tool 'xcodebuild' requires Xcode, - but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance - -To resolve this error, you will need to: - -1. Double check that you have the command line tool installed: - -.. code-block:: console - - $ xcode-select --install - -2. Accept the terms and conditions of Xcode by typing in terminal: - -.. code-block:: console - - $ sudo xcodebuild -license accept - -3. Ensure Xcode app is in the ``/Applications`` directory (NOT ``/Users/{user}/Applications``) - -4. Point ``xcode-select`` to the Xcode app Developer directory using the following command: - -.. code-block:: console - - $ sudo xcode-select -s /Applications/Xcode.app/Contents/Developer - -rosdep install error ``homebrew: Failed to detect successful installation of [qt5]`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -While following the :doc:`Creating a workspace <../Tutorials/Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` tutorial, you might encounter the following error stating that ``rosdep`` fails to install Qt5. - -.. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - executing command [brew install qt5] - Warning: qt 5.15.0 is already installed and up-to-date - To reinstall 5.15.0, run `brew reinstall qt` - ERROR: the following rosdeps failed to install - homebrew: Failed to detect successful installation of [qt5] - -This error seems to stem from a `linking issue `__ and can be resolved by running the following command. - -.. code-block:: console - - $ cd /usr/local/Cellar - $ sudo ln -s qt qt5 - -Running the ``rosdep`` command should now execute normally: - -.. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - -The command should return: - -.. code-block:: text - - #All required rosdeps installed successfully - -.. _windows-troubleshooting: - -Windows -------- - -Import failing even with library present on the system -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sometimes ``rclpy`` fails to be imported because of some missing DLLs on your system. -If so, make sure to install all the dependencies listed in the "Installing prerequisites" sections of the :ref:`installation instructions `). - -If you are installing from binaries, you may need to update your dependencies: they must be the same version as those used to build the binaries. - -If you are still having issues, you can use the `Dependencies `_ tool to determine which dependencies are missing on your system. -Use the tool to load the corresponding ``.pyd`` file, and it should report unavailable ``DLL`` modules. -Be sure that the current workspace is sourced before you execute the tool, otherwise there will be unresolved ROS DLL files. -Use this information to install additional dependencies or adjust your path as necessary. - -CMake error setting modification time -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you run into the CMake error ``file INSTALL cannot set modification time on ...`` when installing files it is likely that an anti virus software or Windows Defender are interfering with the build. -E.g. for Windows Defender you can list the workspace location to be excluded to prevent it from scanning those files. - -260 character path limit -^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: bash - - The input line is too long. - The syntax of the command is incorrect. - -Depending on your directory hierarchy, you may see path length limit errors when building ROS 2 from source or your own libraries. - -To allow deeper path lengths: - -Run ``regedit.exe``, navigate to ``Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem``, and set ``LongPathsEnabled`` to 0x00000001 (1). - -Hit the windows key and type ``Edit Group Policy``. -Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem. -Right click ``Enable Win32 long paths``, click Edit. -In the dialog, select Enabled and click OK. - -Close and open your terminal to reset the environment and try building again. - -Failed to load Fast RTPS shared library -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Fast RTPS requires ``msvcr20.dll``, which is part of the ``Visual C++ Redistributable Packages for Visual Studio 2013``. -Although it is usually installed by default in Windows 10, we know that some Windows 10-like versions don't have it installed by default (e.g.: Windows Server 2019). -In case you don't have it installed, you can download it from `here `_. - -Failed to create process -^^^^^^^^^^^^^^^^^^^^^^^^ - -If running a ROS binary gives the error: - -.. code-block:: - - | failed to create process. - -It is likely the Python interpreter was not found. -For each executable, the shebang (first line) of the accompanying script is used, so make sure Python is available under the expected path (default: ``C:\Python38\``). - -Binary installation specific -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* If your example does not start because of missing DLLs, please verify that all libraries from external dependencies such as OpenCV are located inside your ``PATH`` variable. -* If you forget to call the ``local_setup.bat`` file from your terminal, the demo programs will most likely crash immediately. - -Running RViz with WSL2 -^^^^^^^^^^^^^^^^^^^^^^ - -If you are using `WSL2 `__ to run ROS 2 on Windows, you may run into an issue running RViz that looks like: - -.. code-block:: console - - $ rviz2 - [INFO] [1695823660.091830699] [rviz2]: Stereo is NOT SUPPORTED - [INFO] [1695823660.091943524] [rviz2]: OpenGl version: 4.1 (GLSL 4.1) - D3D12: Removing Device. - Segmentation fault - -One possible solution to this is to force RViz to use software rendering: - -.. code-block:: console - - $ export LIBGL_ALWAYS_SOFTWARE=true - $ rviz2 - [INFO] [1695823660.091830699] [rviz2]: Stereo is NOT SUPPORTED +.. redirect-from:: + + Guides/Installation-Troubleshooting + Troubleshooting/Installation-Troubleshooting + How-To-Guides/Installation-Troubleshooting + +Installation troubleshooting +============================ + +Troubleshooting techniques for installation are sorted by the platforms they apply to. + +.. contents:: Platforms + :depth: 2 + :local: + +General +------- + +General troubleshooting techniques apply to all platforms. + +Enable multicast +^^^^^^^^^^^^^^^^ + +In order to communicate successfully via DDS, the used network interface has to be multicast enabled. +We've seen in past experiences that this might not necessarily be enabled by default (on Ubuntu or OSX) when using the loopback adapter. +See the `original issue `__ or a `conversation on ros-answers `__. +You can verify that your current setup allows multicast with the ROS 2 tool: + +In Terminal 1: + +.. code-block:: console + + $ ros2 multicast receive + +In Terminal 2: + +.. code-block:: console + + $ ros2 multicast send + +If the first command did not return a response similar to: + +.. code-block:: bash + + Received from xx.xxx.xxx.xx:43751: 'Hello World!' + +then you will need to update your firewall configuration to allow multicast using `ufw `__. + +.. code-block:: console + + $ sudo ufw allow in proto udp to 224.0.0.0/4 + $ sudo ufw allow in proto udp from 224.0.0.0/4 + + +You can check if the multicast flag is enabled for your network interface using the :code:`ifconfig` tool and looking for :code:`MULTICAST` in the flags section: + +.. code-block:: bash + + eno1: flags=4163<...,MULTICAST> + ... + +Import failing without library present on the system +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sometimes ``rclpy`` fails to be imported because the expected C extension libraries are not found. +If so, compare the libraries present in the directory with the one mentioned in the error message. +Assuming a file with a similar name exists (same prefix like ``_rclpy.`` and same suffix like ``.so`` but a different Python version / architecture) you are using a different Python interpreter than which was used to build the C extension. +Be sure to use the same Python interpreter as the one used to build the binary. + +For example, such a mismatch can crop up after an update of the OS. +Then, rebuilding the workspace may fix the issue. + +.. _linux-troubleshooting: + +Linux +----- + +Internal compiler error +^^^^^^^^^^^^^^^^^^^^^^^ + +If you experience an ICE when trying to compile on a memory constrained platform like a Raspberry PI you might want to build single threaded (prefix the build invocation with ``MAKEFLAGS=-j1``). + +Multiple host interference +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you're running multiple instances on the same network you may get interference. +To avoid this you can set the environment variable ``ROS_DOMAIN_ID`` to a different integer, the default is zero. +This will define the DDS domain id for your system. + +Exception sourcing setup.bash +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. only relevant to Eloquent and Foxy + +If you encounter exceptions when trying to source the environment after building from source, try to upgrade ``colcon`` related packages using + +.. code-block:: console + + $ colcon version-check # check if newer versions available + $ sudo apt install python3-colcon* --only-upgrade # upgrade installed colcon packages to latest version + +Mixing conda and apt Python Conflict +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While using ROS 2, mixing packages installed with ``apt`` with packages installed with ``conda`` does not work. +If you are using the official ``apt`` binaries for ROS 2, make sure that your ``PATH`` environment variable does not have any conda paths in it. +You may have to check your ``.bashrc`` for this line and comment it out. + +On the other hand on Windows, the official ROS 2 installation procedure uses ``conda`` packages via the ``pixi`` package manager, and that works fine as there is no mix of different package managers + +``conda`` packages for ROS 2 may be built (such as the one provided by the community-mantained `RoboStack `_ project) but no official conda packages for ROS 2 are provided. + +Cannot start rviz2 +^^^^^^^^^^^^^^^^^^ + +``rviz2`` may fail to start on a Wayland display system with errors like: + +.. code-block:: + + QSocketNotifier: Can only be used with threads started with QThread + [INFO] [1714730141.758659580] [rviz2]: Stereo is NOT SUPPORTED + [INFO] [1714730141.758813709] [rviz2]: OpenGl version: 3.1 (GLSL 1.4) + [ERROR] [1714730141.797879232] [rviz2]: rviz::RenderSystem: error creating render window: RenderingAPIException: Invalid parentWindowHandle (wrong server or screen) in GLXWindow::create at ./.obj-aarch64-linux-gnu/ogre_vendor-prefix/src/ogre_vendor/RenderSystems/GLSupport/src/GLX/OgreGLXWindow.cpp (line 246) + ... + [ERROR] [1714730141.808124283] [rviz2]: Unable to create the rendering window after 100 tries + terminate called after throwing an instance of 'std::runtime_error' + what(): Unable to create the rendering window after 100 tries + Aborted (core dumped) + +This is due to an incompatibility between Wayland and RViz2. +You may be able to workaround this problem by running RViz2 in X11 compatibility mode: + +.. code-block:: + + QT_QPA_PLATFORM=xcb rviz2 + +.. _macOS-troubleshooting: + +macOS +----- + +Segmentation fault when using ``pyenv`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``pyenv`` seems to default to building Python with ``.a`` files, but that causes issues with ``rclpy``, so it's recommended to build Python with Frameworks enabled on macOS when using ``pyenv``: + +https://github.com/pyenv/pyenv/wiki#how-to-build-cpython-with-framework-support-on-os-x + +Library not loaded; image not found +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you are seeing library loading issues at runtime (either running tests or running nodes), such as the following: + +.. code-block:: bash + + ImportError: dlopen(.../ros2_/ros2-osx/lib/python3.7/site-packages/rclpy/_rclpy.cpython-37m-darwin.so, 2): Library not loaded: @rpath/librcl_interfaces__rosidl_typesupport_c.dylib + Referenced from: .../ros2_/ros2-osx/lib/python3.7/site-packages/rclpy/_rclpy.cpython-37m-darwin.so + Reason: image not found + +Then you probably have System Integrity Protection enabled. +Follow `these instructions `__ to disable System Integrity Protection (SIP). + +Qt build error: ``unknown type name 'Q_ENUM'`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you see build errors related to Qt, e.g.: + +.. code-block:: bash + + In file included from /usr/local/opt/qt/lib/QtGui.framework/Headers/qguiapplication.h:46: + /usr/local/opt/qt/lib/QtGui.framework/Headers/qinputmethod.h:87:5: error: + unknown type name 'Q_ENUM' + Q_ENUM(Action) + ^ + +you may be using qt4 instead of qt5: see https://github.com/ros2/ros2/issues/441 + +Missing symbol when opencv (and therefore libjpeg, libtiff, and libpng) are installed with Homebrew +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have opencv installed you might get this: + +.. code-block:: bash + + dyld: Symbol not found: __cg_jpeg_resync_to_restart + Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO + Expected in: /usr/local/lib/libJPEG.dylib + in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO + /bin/sh: line 1: 25274 Trace/BPT trap: 5 /usr/local/bin/cmake + +If so, to build you'll have to do this: + +.. code-block:: console + + $ brew unlink libpng libtiff libjpeg + +But this will break opencv, so you'll also need to update it to continue working: + +.. code-block:: console + + $ sudo install_name_tool -change /usr/local/lib/libjpeg.8.dylib /usr/local/opt/jpeg/lib/libjpeg.8.dylib /usr/local/lib/libopencv_highgui.2.4.dylib + $ sudo install_name_tool -change /usr/local/lib/libpng16.16.dylib /usr/local/opt/libpng/lib/libpng16.16.dylib /usr/local/lib/libopencv_highgui.2.4.dylib + $ sudo install_name_tool -change /usr/local/lib/libtiff.5.dylib /usr/local/opt/libtiff/lib/libtiff.5.dylib /usr/local/lib/libopencv_highgui.2.4.dylib + $ sudo install_name_tool -change /usr/local/lib/libjpeg.8.dylib /usr/local/opt/jpeg/lib/libjpeg.8.dylib /usr/local/Cellar/libtiff/4.0.4/lib/libtiff.5.dylib + +The first command is necessary to avoid things built against the system libjpeg (etc.) from getting the version in /usr/local/lib. +The others are updating things built by Homebrew so that they can find the version of libjpeg (etc.) without having them in /usr/local/lib. + +Xcode-select error: tool ``xcodebuild`` requires Xcode, but active developer directory is a command line instance +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. only relevant to Eloquent and Foxy + +If you recently installed Xcode, you may encounter this error: + +.. code-block:: bash + + Xcode: xcode-select: error: tool 'xcodebuild' requires Xcode, + but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance + +To resolve this error, you will need to: + +1. Double check that you have the command line tool installed: + +.. code-block:: console + + $ xcode-select --install + +2. Accept the terms and conditions of Xcode by typing in terminal: + +.. code-block:: console + + $ sudo xcodebuild -license accept + +3. Ensure Xcode app is in the ``/Applications`` directory (NOT ``/Users/{user}/Applications``) + +4. Point ``xcode-select`` to the Xcode app Developer directory using the following command: + +.. code-block:: console + + $ sudo xcode-select -s /Applications/Xcode.app/Contents/Developer + +rosdep install error ``homebrew: Failed to detect successful installation of [qt5]`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +While following the :doc:`Creating a workspace <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` tutorial, you might encounter the following error stating that ``rosdep`` fails to install Qt5. + +.. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + executing command [brew install qt5] + Warning: qt 5.15.0 is already installed and up-to-date + To reinstall 5.15.0, run `brew reinstall qt` + ERROR: the following rosdeps failed to install + homebrew: Failed to detect successful installation of [qt5] + +This error seems to stem from a `linking issue `__ and can be resolved by running the following command. + +.. code-block:: console + + $ cd /usr/local/Cellar + $ sudo ln -s qt qt5 + +Running the ``rosdep`` command should now execute normally: + +.. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + +The command should return: + +.. code-block:: text + + #All required rosdeps installed successfully + +.. _windows-troubleshooting: + +Windows +------- + +Import failing even with library present on the system +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sometimes ``rclpy`` fails to be imported because of some missing DLLs on your system. +If so, make sure to install all the dependencies listed in the "Installing prerequisites" sections of the :ref:`installation instructions `). + +If you are installing from binaries, you may need to update your dependencies: they must be the same version as those used to build the binaries. + +If you are still having issues, you can use the `Dependencies `_ tool to determine which dependencies are missing on your system. +Use the tool to load the corresponding ``.pyd`` file, and it should report unavailable ``DLL`` modules. +Be sure that the current workspace is sourced before you execute the tool, otherwise there will be unresolved ROS DLL files. +Use this information to install additional dependencies or adjust your path as necessary. + +CMake error setting modification time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you run into the CMake error ``file INSTALL cannot set modification time on ...`` when installing files it is likely that an anti virus software or Windows Defender are interfering with the build. +E.g. for Windows Defender you can list the workspace location to be excluded to prevent it from scanning those files. + +260 character path limit +^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: bash + + The input line is too long. + The syntax of the command is incorrect. + +Depending on your directory hierarchy, you may see path length limit errors when building ROS 2 from source or your own libraries. + +To allow deeper path lengths: + +Run ``regedit.exe``, navigate to ``Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem``, and set ``LongPathsEnabled`` to 0x00000001 (1). + +Hit the windows key and type ``Edit Group Policy``. +Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem. +Right click ``Enable Win32 long paths``, click Edit. +In the dialog, select Enabled and click OK. + +Close and open your terminal to reset the environment and try building again. + +Failed to load Fast RTPS shared library +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Fast RTPS requires ``msvcr20.dll``, which is part of the ``Visual C++ Redistributable Packages for Visual Studio 2013``. +Although it is usually installed by default in Windows 10, we know that some Windows 10-like versions don't have it installed by default (e.g.: Windows Server 2019). +In case you don't have it installed, you can download it from `here `_. + +Failed to create process +^^^^^^^^^^^^^^^^^^^^^^^^ + +If running a ROS binary gives the error: + +.. code-block:: + + | failed to create process. + +It is likely the Python interpreter was not found. +For each executable, the shebang (first line) of the accompanying script is used, so make sure Python is available under the expected path (default: ``C:\Python38\``). + +Binary installation specific +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* If your example does not start because of missing DLLs, please verify that all libraries from external dependencies such as OpenCV are located inside your ``PATH`` variable. +* If you forget to call the ``local_setup.bat`` file from your terminal, the demo programs will most likely crash immediately. + +Running RViz with WSL2 +^^^^^^^^^^^^^^^^^^^^^^ + +If you are using `WSL2 `__ to run ROS 2 on Windows, you may run into an issue running RViz that looks like: + +.. code-block:: console + + $ rviz2 + [INFO] [1695823660.091830699] [rviz2]: Stereo is NOT SUPPORTED + [INFO] [1695823660.091943524] [rviz2]: OpenGl version: 4.1 (GLSL 4.1) + D3D12: Removing Device. + Segmentation fault + +One possible solution to this is to force RViz to use software rendering: + +.. code-block:: console + + $ export LIBGL_ALWAYS_SOFTWARE=true + $ rviz2 + [INFO] [1695823660.091830699] [rviz2]: Stereo is NOT SUPPORTED \ No newline at end of file diff --git a/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst b/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst index 0c606c598b5..8a988de65d6 100644 --- a/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst +++ b/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst @@ -1,66 +1,70 @@ -ROS 2 on Raspberry Pi -===================== - -ROS 2 is supported on both 32 bit (arm32) and 64 bit (arm64) ARM processors. -However, you can see `here `__ that arm64 receives Tier 1 support, while arm32 is Tier 3. -Tier 1 support means distribution specific packages and binary archives are available, while Tier 3 requires the user to compile ROS 2 from source. - -The fastest and simplest way to use ROS 2 is to use a Tier 1 supported configuration. - -This would mean either installing 64 bit Ubuntu on to the Raspberry Pi, or using the 64 bit version of Raspberry Pi OS and running ROS 2 in Docker. - -Ubuntu Linux on Raspberry Pi with binary ROS 2 install ------------------------------------------------------- - -Ubuntu for Raspberry Pi is available `here `__. - -Make sure to confirm that you have selected the correct version as described in `REP-2000 `__. - -Ubuntu for Raspberry Pi doesn't include the *backports* and *updates* software suites by default, which are required for the ROS 2 binary install to work. - -So, please check and edit the ``/etc/apt/sources.list.d/ubuntu.sources`` file on your Raspberry Pi before installing ROS 2. - -For example, the Ubuntu 24.04 "Noble Numbat" release should have an entry that looks like this: - -.. code-block:: console - - Types: deb - URIs: http://ports.ubuntu.com/ubuntu-ports/ - Suites: noble noble-updates noble-backports # <-- IMPORTANT LINE - Components: main universe restricted multiverse - Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg - -You can now install ROS 2 using the normal binary installation instructions for Ubuntu Linux. - -Raspberry Pi OS with ROS 2 in docker ------------------------------------- - -Raspberry Pi OS 64 bit version is `available here `__. - -Raspberry Pi OS is based on Debian which receives Tier 3 support, but it can run Ubuntu docker containers for Tier 1 support. - -After flashing the OS, `install Docker `__. - -The official ROS 2 Docker images can be found `here `__. - -You may choose from ros-core, ros-base, or perception. -See `here `__ for more information on these variants. - -Fetch and run an image: - -.. code-block:: console - - $ docker pull ros:{DISTRO}-ros-core - $ docker run -it --rm ros:{DISTRO}-ros-core - -You can also build images yourself: - -Clone the `docker_images git repo `__ onto the Raspberry Pi, change in to the directory linked above, then to the directory with your preferred variant. - -Inside of the directory, build the container with: - -.. code-block:: console - - $ docker build -t ros_docker . - -On a supported system it will only take a minute or two to build the docker containers, as the source code is already built in to binaries. +.. redirect-from:: + + How-To-Guides/Installing-on-Raspberry-Pi + +ROS 2 on Raspberry Pi +===================== + +ROS 2 is supported on both 32 bit (arm32) and 64 bit (arm64) ARM processors. +However, you can see `here `__ that arm64 receives Tier 1 support, while arm32 is Tier 3. +Tier 1 support means distribution specific packages and binary archives are available, while Tier 3 requires the user to compile ROS 2 from source. + +The fastest and simplest way to use ROS 2 is to use a Tier 1 supported configuration. + +This would mean either installing 64 bit Ubuntu on to the Raspberry Pi, or using the 64 bit version of Raspberry Pi OS and running ROS 2 in Docker. + +Ubuntu Linux on Raspberry Pi with binary ROS 2 install +------------------------------------------------------ + +Ubuntu for Raspberry Pi is available `here `__. + +Make sure to confirm that you have selected the correct version as described in `REP-2000 `__. + +Ubuntu for Raspberry Pi doesn't include the *backports* and *updates* software suites by default, which are required for the ROS 2 binary install to work. + +So, please check and edit the ``/etc/apt/sources.list.d/ubuntu.sources`` file on your Raspberry Pi before installing ROS 2. + +For example, the Ubuntu 24.04 "Noble Numbat" release should have an entry that looks like this: + +.. code-block:: console + + Types: deb + URIs: http://ports.ubuntu.com/ubuntu-ports/ + Suites: noble noble-updates noble-backports # <-- IMPORTANT LINE + Components: main universe restricted multiverse + Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg + +You can now install ROS 2 using the normal binary installation instructions for Ubuntu Linux. + +Raspberry Pi OS with ROS 2 in docker +------------------------------------ + +Raspberry Pi OS 64 bit version is `available here `__. + +Raspberry Pi OS is based on Debian which receives Tier 3 support, but it can run Ubuntu docker containers for Tier 1 support. + +After flashing the OS, `install Docker `__. + +The official ROS 2 Docker images can be found `here `__. + +You may choose from ros-core, ros-base, or perception. +See `here `__ for more information on these variants. + +Fetch and run an image: + +.. code-block:: console + + $ docker pull ros:{DISTRO}-ros-core + $ docker run -it --rm ros:{DISTRO}-ros-core + +You can also build images yourself: + +Clone the `docker_images git repo `__ onto the Raspberry Pi, change in to the directory linked above, then to the directory with your preferred variant. + +Inside of the directory, build the container with: + +.. code-block:: console + + $ docker build -t ros_docker . + +On a supported system it will only take a minute or two to build the docker containers, as the source code is already built in to binaries. \ No newline at end of file diff --git a/source/Get-Started/Installation/RHEL-Install-RPMs.rst b/source/Get-Started/Installation/RHEL-Install-RPMs.rst index 7811d6918ca..bbdbe7c6bac 100644 --- a/source/Get-Started/Installation/RHEL-Install-RPMs.rst +++ b/source/Get-Started/Installation/RHEL-Install-RPMs.rst @@ -1,165 +1,169 @@ -RHEL (RPM packages) -=================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -RPM packages for ROS 2 {DISTRO_TITLE_FULL} are currently available for RHEL 10. -The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. -The target platforms are defined in `REP 2000 `__. -Most people will want to use a stable ROS distribution. - -Resources ---------- - -* Status Page: - - * ROS 2 {DISTRO_TITLE} (RHEL 10): `amd64 `__ -* `Jenkins Instance `__ -* `Repositories `__ - -System setup ------------- - -Set locale -^^^^^^^^^^ - -.. include:: _RHEL-Set-Locale.rst - -Enable required repositories -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You will need to enable the EPEL repositories and the PowerTools repository: - -.. code-block:: console - - $ sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E %rhel).noarch.rpm - $ sudo env FORCE_DNF=1 crb enable - -.. note:: This step may be slightly different depending on the distribution you are using. - `Check the EPEL documentation `_ - -Next, download the ``ros2-release`` package and install it: - -.. code-block:: console - - $ sudo dnf install curl - $ export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}') - $ sudo dnf install "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-release-${ROS_APT_SOURCE_VERSION}-1.noarch.rpm" - -The `ros2-release `_ package provides keys and repo configuration for the various ROS repositories. -Updates to repository configuration will occur automatically when new versions of this package are released to the ROS repositories. - -Install development tools (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you are going to build ROS packages or otherwise do development, you can also install the development tools: - -.. code-block:: console - - $ sudo dnf install -y \ - cmake \ - gcc-c++ \ - git \ - make \ - patch \ - python3-colcon-common-extensions \ - python3-mypy \ - python3-pip \ - python3-pytest \ - python3-pytest-repeat \ - python3-pytest-rerunfailures \ - python3-rosdep \ - python3-setuptools \ - python3-vcstool \ - wget - -Install ROS 2 -------------- - -.. include:: _Dnf-Update-Admonition.rst - -Desktop Install (Recommended): ROS, RViz, demos, tutorials. - -.. code-block:: console - - $ sudo dnf install ros-{DISTRO}-desktop - -ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. -No GUI tools. - -.. code-block:: console - - $ sudo dnf install ros-{DISTRO}-ros-base - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. -See the :doc:`guide <../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Setup environment ------------------ - -Set up your environment by sourcing the following file. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using console. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - -Try some examples ------------------ - -If you installed ``ros-{DISTRO}-desktop`` above you can try some examples. - -In one terminal, source the setup file and then run a C++ ``talker``\ : - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``\ : - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -If you want to use other RMW implementations, you can check the :doc:`guide <./RMW-Implementations>`. - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :doc:`here <../How-To-Guides/Installation-Troubleshooting>`. - -Uninstall ---------- - -If you need to uninstall ROS 2 or switch to a source-based install once you -have already installed from binaries, run the following command: - -.. code-block:: console - - $ sudo dnf remove ros-{DISTRO}-* - -To remove the repository configuration run - -.. code-block:: console - - $ sudo dnf remove ros2-release +.. redirect-from:: + + Installation/RHEL-Install-RPMs + +RHEL (RPM packages) +=================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +RPM packages for ROS 2 {DISTRO_TITLE_FULL} are currently available for RHEL 10. +The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. +The target platforms are defined in `REP 2000 `__. +Most people will want to use a stable ROS distribution. + +Resources +--------- + +* Status Page: + + * ROS 2 {DISTRO_TITLE} (RHEL 10): `amd64 `__ +* `Jenkins Instance `__ +* `Repositories `__ + +System setup +------------ + +Set locale +^^^^^^^^^^ + +.. include:: _RHEL-Set-Locale.rst + +Enable required repositories +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You will need to enable the EPEL repositories and the PowerTools repository: + +.. code-block:: console + + $ sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E %rhel).noarch.rpm + $ sudo env FORCE_DNF=1 crb enable + +.. note:: This step may be slightly different depending on the distribution you are using. + `Check the EPEL documentation `_ + +Next, download the ``ros2-release`` package and install it: + +.. code-block:: console + + $ sudo dnf install curl + $ export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}') + $ sudo dnf install "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-release-${ROS_APT_SOURCE_VERSION}-1.noarch.rpm" + +The `ros2-release `_ package provides keys and repo configuration for the various ROS repositories. +Updates to repository configuration will occur automatically when new versions of this package are released to the ROS repositories. + +Install development tools (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you are going to build ROS packages or otherwise do development, you can also install the development tools: + +.. code-block:: console + + $ sudo dnf install -y \ + cmake \ + gcc-c++ \ + git \ + make \ + patch \ + python3-colcon-common-extensions \ + python3-mypy \ + python3-pip \ + python3-pytest \ + python3-pytest-repeat \ + python3-pytest-rerunfailures \ + python3-rosdep \ + python3-setuptools \ + python3-vcstool \ + wget + +Install ROS 2 +------------- + +.. include:: _Dnf-Update-Admonition.rst + +Desktop Install (Recommended): ROS, RViz, demos, tutorials. + +.. code-block:: console + + $ sudo dnf install ros-{DISTRO}-desktop + +ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. +No GUI tools. + +.. code-block:: console + + $ sudo dnf install ros-{DISTRO}-ros-base + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. +See the :doc:`guide ` on how to work with multiple RMWs. + +Setup environment +----------------- + +Set up your environment by sourcing the following file. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using console. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + +Try some examples +----------------- + +If you installed ``ros-{DISTRO}-desktop`` above you can try some examples. + +In one terminal, source the setup file and then run a C++ ``talker``\ : + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``\ : + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +If you want to use other RMW implementations, you can check the :doc:`guide `. + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :doc:`here `. + +Uninstall +--------- + +If you need to uninstall ROS 2 or switch to a source-based install once you +have already installed from binaries, run the following command: + +.. code-block:: console + + $ sudo dnf remove ros-{DISTRO}-* + +To remove the repository configuration run + +.. code-block:: console + + $ sudo dnf remove ros2-release \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations.rst index bb225eed256..b7022903d57 100644 --- a/source/Get-Started/Installation/RMW-Implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations.rst @@ -1,27 +1,28 @@ -.. redirect-from:: - - Installation/DDS-Implementations - -RMW implementations -=================== - -By default, ROS 2 uses DDS as its `middleware `__. -It is compatible with multiple DDS or RTPS (the DDS wire protocol) vendors. -There is currently support for eProsima's Fast DDS, RTI's Connext DDS, Eclipse Cyclone DDS, and GurumNetworks GurumDDS. - -It also supports non DDS RMW implementations such as Zenoh. - -See `REP-2000 `__ for supported RMW vendors by distribution. - -The default RMW vendor is eProsima's Fast DDS. - -Review all the possible options: - -.. toctree:: - :hidden: - :glob: - - RMW-Implementations/* - -* :doc:`DDS implementations ` explains how to use DDS. -* :doc:`Non DDS implementations ` explains how to use non DDS implementations. +.. redirect-from:: + + Installation/DDS-Implementations + Installation/RMW-Implementations + +RMW implementations +=================== + +By default, ROS 2 uses DDS as its `middleware `__. +It is compatible with multiple DDS or RTPS (the DDS wire protocol) vendors. +There is currently support for eProsima's Fast DDS, RTI's Connext DDS, Eclipse Cyclone DDS, and GurumNetworks GurumDDS. + +It also supports non DDS RMW implementations such as Zenoh. + +See `REP-2000 `__ for supported RMW vendors by distribution. + +The default RMW vendor is eProsima's Fast DDS. + +Review all the possible options: + +.. toctree:: + :hidden: + :glob: + + RMW-Implementations/* + +* :doc:`DDS implementations ` explains how to use DDS. +* :doc:`Non DDS implementations ` explains how to use non DDS implementations. \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst index 445c2faf3b1..ffeeab57834 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst @@ -1,20 +1,24 @@ -DDS implementations -=================== - -These are the available DDS implementations: - -* :doc:`Working with Eclipse Cyclone DDS ` explains how to utilize Cyclone DDS. -* :doc:`Working with eProsima Fast DDS ` explains how to utilize Fast DDS. -* :doc:`Working with RTI Connext DDS ` explains how to utilize RTI Connext DDS. -* :doc:`Working with GurumNetworks GurumDDS ` explains how to utilize GurumDDS. - -.. toctree:: - :hidden: - :glob: - - DDS-Implementations/* - -If you would like to use one of the other vendors you will need to install their software separately before building. -The ROS 2 build will automatically build support for vendors that have been installed and sourced correctly. - -Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations <../../How-To-Guides/Working-with-multiple-RMW-implementations>`. +.. redirect-from:: + + Installation/RMW-Implementations/DDS-Implementations + +DDS implementations +=================== + +These are the available DDS implementations: + +* :doc:`Working with Eclipse Cyclone DDS ` explains how to utilize Cyclone DDS. +* :doc:`Working with eProsima Fast DDS ` explains how to utilize Fast DDS. +* :doc:`Working with RTI Connext DDS ` explains how to utilize RTI Connext DDS. +* :doc:`Working with GurumNetworks GurumDDS ` explains how to utilize GurumDDS. + +.. toctree:: + :hidden: + :glob: + + DDS-Implementations/* + +If you would like to use one of the other vendors you will need to install their software separately before building. +The ROS 2 build will automatically build support for vendors that have been installed and sourced correctly. + +Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations `. \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst index 2941724a619..197a8671449 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst @@ -1,86 +1,87 @@ -.. redirect-from:: - - Working-with-Eclipse-CycloneDDS - -Eclipse Cyclone DDS -=================== - -Eclipse Cyclone DDS is a very performant and robust open-source DDS implementation. -Cyclone DDS is developed completely in the open as an Eclipse IoT project. -See also: https://projects.eclipse.org/projects/iot.cyclonedds - - -Prerequisites -------------- - -Have :doc:`rosdep installed <../../../Tutorials/Intermediate/Rosdep>`. - -Install packages ----------------- - -The easiest way is to install from ROS 2 apt repository. - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-rmw-cyclonedds-cpp - -Build from source code ----------------------- - -Building from source code is also another way to install. - -First, clone Cyclone DDS and rmw_cyclonedds in the ROS 2 workspace source directory. -To determine the correct branches to checkout, you need to find what versions are specified in your `ROS distribution's ros2.repos file `_. - -Alternatively, you can run the following code to fetch the correct branch/tag needed for Cyclone DDS: - -.. code-block:: console - - $ CYCLONEDDS_BRANCH=$(curl -s https://raw.githubusercontent.com/ros2/ros2/refs/heads/{DISTRO}/ros2.repos | grep -A 3 "eclipse-cyclonedds/cyclonedds:" | grep "version:" | awk '{print $2}') - -And now, clone and checkout the code: - -.. code-block:: console - - $ cd ros2_ws/src - $ git clone https://github.com/ros2/rmw_cyclonedds ros2/rmw_cyclonedds -b {DISTRO} - $ git clone https://github.com/eclipse-cyclonedds/cyclonedds eclipse-cyclonedds/cyclonedds -b ${CYCLONEDDS_BRANCH} - -Then, install necessary packages for Cyclone DDS. - -.. code-block:: console - - $ cd .. - $ rosdep install --from src -i - -Finally, run colcon build. - -.. code-block:: console - - $ colcon build --symlink-install - -Switch to rmw_cyclonedds ------------------------- - -Switch from other rmw to rmw_cyclonedds by specifying the environment variable. - -.. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp - -See also: :doc:`Working with multiple RMW implementations <../../../How-To-Guides/Working-with-multiple-RMW-implementations>` - -Run the talker and listener ---------------------------- - -Now run ``talker`` and ``listener`` to test Cyclone DDS. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener +.. redirect-from:: + + Working-with-Eclipse-CycloneDDS + Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS + +Eclipse Cyclone DDS +=================== + +Eclipse Cyclone DDS is a very performant and robust open-source DDS implementation. +Cyclone DDS is developed completely in the open as an Eclipse IoT project. +See also: https://projects.eclipse.org/projects/iot.cyclonedds + + +Prerequisites +------------- + +Have :doc:`rosdep installed <../../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep>`. + +Install packages +---------------- + +The easiest way is to install from ROS 2 apt repository. + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-rmw-cyclonedds-cpp + +Build from source code +---------------------- + +Building from source code is also another way to install. + +First, clone Cyclone DDS and rmw_cyclonedds in the ROS 2 workspace source directory. +To determine the correct branches to checkout, you need to find what versions are specified in your `ROS distribution's ros2.repos file `_. + +Alternatively, you can run the following code to fetch the correct branch/tag needed for Cyclone DDS: + +.. code-block:: console + + $ CYCLONEDDS_BRANCH=$(curl -s https://raw.githubusercontent.com/ros2/ros2/refs/heads/{DISTRO}/ros2.repos | grep -A 3 "eclipse-cyclonedds/cyclonedds:" | grep "version:" | awk '{print $2}') + +And now, clone and checkout the code: + +.. code-block:: console + + $ cd ros2_ws/src + $ git clone https://github.com/ros2/rmw_cyclonedds ros2/rmw_cyclonedds -b {DISTRO} + $ git clone https://github.com/eclipse-cyclonedds/cyclonedds eclipse-cyclonedds/cyclonedds -b ${CYCLONEDDS_BRANCH} + +Then, install necessary packages for Cyclone DDS. + +.. code-block:: console + + $ cd .. + $ rosdep install --from src -i + +Finally, run colcon build. + +.. code-block:: console + + $ colcon build --symlink-install + +Switch to rmw_cyclonedds +------------------------ + +Switch from other rmw to rmw_cyclonedds by specifying the environment variable. + +.. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp + +See also: :doc:`Working with multiple RMW implementations <../Working-with-multiple-RMW-implementations>` + +Run the talker and listener +--------------------------- + +Now run ``talker`` and ``listener`` to test Cyclone DDS. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp listener \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst index 015aed98022..5fbb5ab83b1 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst @@ -1,93 +1,94 @@ -.. redirect-from:: - - Working-with-GurumNetworks-GurumDDS - -GurumNetworks GurumDDS -====================== -``rmw_gurumdds`` is an implementation of the ROS middleware interface using GurumNetworks GurumDDS. -For more information about GurumDDS, visit the `GurumNetworks website `_. - - -Prerequisites -------------- -This guide assumes you have completed the ROS 2 environment setup process, either by :doc:`Installing ROS 2 via Deb Packages <../../Ubuntu-Install-Debs>` or :doc:`Building ROS 2 from source on Ubuntu <../../Alternatives/Ubuntu-Development-Setup>`. - -Version Requirements (`see the README for details `_): - -================ ================ -ROS 2 Distro GurumDDS Version -================ ================ -rolling ``>= 3.2.0`` -jazzy ``>= 3.2.0`` -humble ``3.1.x`` -================ ================ - -Deb packages of GurumDDS are provided in the ROS 2 apt repositories on Ubuntu. -Windows binary installer of GurumDDS will be available soon. - -You can obtain a free trial license from the `GurumDDS Free Trial page `_. - -After acquiring a license, place it in the following location: ``/etc/gurumnet`` - - -Installation ------------- -Option 1: Install from the ROS 2 apt repository (Recommended) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-rmw-gurumdds-cpp - -This installs both ``rmw_gurumdds_cpp`` and ``gurumdds``. - -Option 2: Build from source code -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -1. Clone the repository - -.. code-block:: console - - $ cd ros2_ws/src - $ git clone https://github.com/ros2/rmw_gurumdds -b {DISTRO} ros2/rmw_gurumdds - -2. Install dependencies: - -.. code-block:: console - - $ cd .. - $ rosdep install --from src -i --rosdistro {DISTRO} - -3. Build the workspace using Colcon: - -.. code-block:: console - - $ colcon build --symlink-install - - -Switch to rmw_gurumdds ----------------------- -Switch from other RMW implementations to rmw_gurumdds by setting the environment variable: - -.. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_gurumdds_cpp - -For more information on working with multiple RMW implementations, see :doc:`Working with multiple RMW implementations <../../../How-To-Guides/Working-with-multiple-RMW-implementations>`. - -Testing the installation ------------------------- -Run the ``talker`` and ``listener`` nodes to verify your installation: - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener - -If the nodes communicate successfully, your installation is working correctly. - -.. note:: Remember to source your ROS 2 setup script before running these commands. +.. redirect-from:: + + Working-with-GurumNetworks-GurumDDS + Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS + +GurumNetworks GurumDDS +====================== +``rmw_gurumdds`` is an implementation of the ROS middleware interface using GurumNetworks GurumDDS. +For more information about GurumDDS, visit the `GurumNetworks website `_. + + +Prerequisites +------------- +This guide assumes you have completed the ROS 2 environment setup process, either by :doc:`Installing ROS 2 via Deb Packages <../../Ubuntu-Install-Debs>` or :doc:`Building ROS 2 from source on Ubuntu <../../Alternatives/Ubuntu-Development-Setup>`. + +Version Requirements (`see the README for details `_): + +================ ================ +ROS 2 Distro GurumDDS Version +================ ================ +rolling ``>= 3.2.0`` +jazzy ``>= 3.2.0`` +humble ``3.1.x`` +================ ================ + +Deb packages of GurumDDS are provided in the ROS 2 apt repositories on Ubuntu. +Windows binary installer of GurumDDS will be available soon. + +You can obtain a free trial license from the `GurumDDS Free Trial page `_. + +After acquiring a license, place it in the following location: ``/etc/gurumnet`` + + +Installation +------------ +Option 1: Install from the ROS 2 apt repository (Recommended) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-rmw-gurumdds-cpp + +This installs both ``rmw_gurumdds_cpp`` and ``gurumdds``. + +Option 2: Build from source code +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +1. Clone the repository + +.. code-block:: console + + $ cd ros2_ws/src + $ git clone https://github.com/ros2/rmw_gurumdds -b {DISTRO} ros2/rmw_gurumdds + +2. Install dependencies: + +.. code-block:: console + + $ cd .. + $ rosdep install --from src -i --rosdistro {DISTRO} + +3. Build the workspace using Colcon: + +.. code-block:: console + + $ colcon build --symlink-install + + +Switch to rmw_gurumdds +---------------------- +Switch from other RMW implementations to rmw_gurumdds by setting the environment variable: + +.. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_gurumdds_cpp + +For more information on working with multiple RMW implementations, see :doc:`Working with multiple RMW implementations <../Working-with-multiple-RMW-implementations>`. + +Testing the installation +------------------------ +Run the ``talker`` and ``listener`` nodes to verify your installation: + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp listener + +If the nodes communicate successfully, your installation is working correctly. + +.. note:: Remember to source your ROS 2 setup script before running these commands. \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst index c73f0e2075a..e9d476b01b1 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst @@ -1,157 +1,161 @@ -RTI Connext DDS -================= - -RTI Connext DDS is trusted in over 2000 of the world's most demanding system designs, distributing critical real-time data with the highest levels of performance, reliability, and security. -It is free-of-charge for prototyping, research, non-commercial and academic use. -Visit the `RTI website `__ for more information and to learn about options for support and commercial licenses. - - -Prerequisites -------------- - -Install RTI Connext DDS -^^^^^^^^^^^^^^^^^^^^^^^ - To build and use ``rmw_connextdds`` requires a version of Connext DDS compatible with the distribution of ROS 2 in use. - Connext DDS is included when installing ``rmw_connextdds`` using apt, or can be installed manually for building from source. - The following table details which Connext DDS versions are installed using ``apt``, and which versions are required for building from source: - - ================== =================== ==================== - ROS 2 Distribution Installed using apt To Build from Source - ================== =================== ==================== - rolling n/a ``7.7.0`` - kilted ``7.3.0`` ``7.3.0`` - jazzy ``6.0.1`` ``6.0.1`` - humble ``6.0.1`` ``6.0.1`` - ================== =================== ==================== - -RTI Connext Pro is available through a variety of channels: - -**ROS 2 apt repositories** - ROS 2 users can install a non-commercial-use version of the RTI Connext DDS libraries from the ROS apt repository using the following command: - - .. tabs:: - - .. group-tab:: v7.7.0 - - .. code-block:: console - - $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.7.0-ros - - .. group-tab:: v7.3.0 - - .. code-block:: console - - $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.3.0-ros - - .. group-tab:: v6.0.1 - - .. code-block:: console - - $ sudo apt update && sudo apt install -q -y rti-connext-dds-6.0.1 - - This package includes the RTI Connext core DDS libraries only; it does not include the full Connext Professional suite of tools and run-time services. - Note that these Connext libraries are automatically installed when installing ``rmw_connextdds`` using apt. - -**Other Installation Options** -The `Connext Robotics Toolkit `__ includes the full suite of Connext tools and infrastructure services. -It provides a single step installation of ROS and Connext using apt. -It is free for prototype development, research, non-commercial and academic use. - -Detailed instructions for building and tuning the RMW and ROS 2 applications for a variety of platforms, and enabling DDS Security are available on the `RTI ROS Community `__ pages. - - -Install rmw_connextdds binary packages --------------------------------------- - -To install the binary packages for ``rmw_connextdds`` and the Connext libraries from the ROS 2 apt repositories, use the following command: - -.. code-block:: console - - $ sudo apt update && sudo apt install -q -y ros-{DISTRO}-rmw-connextdds - - -Building rmw_connextdds from source code ----------------------------------------- - -Building from source code can ensure the RMW is matched to your system and installed correctly. -The following instructions assume a Linux x86_64 build host and target; the `RTI ROS Community `__ -pages have instructions for building for other platforms and targets, including Arm, Windows, and macOS. - -Clone the repository for ``rmw_connextdds`` into your ROS 2 workspace and select the branch that matches the ROS 2 distribution in use: - -.. code-block:: console - - $ mkdir -p ros2_ws/src - $ cd ros2_ws - $ git clone -b {DISTRO} https://github.com/ros2/rmw_connextdds src/rmw_connextdds - -Then, install necessary packages for RTI Connext DDS. - -.. code-block:: console - - $ cd .. - $ rosdep install --from src -i - -Set up the environment to help colcon discover where RTI Connext is installed. -This can be done by manually setting the environment variable ``NDDSHOME`` to the location of the RTI Connext installation, or by using a script that comes with the RTI Connext installation. -For example, for version 7.7.0, you can run the following code to execute the helper script: - -.. code-block:: console - - $ source /opt/rti.com/rti_connext_dds-7.7.0/resource/scripts/rtisetenv_x64Linux4gcc8.5.0.bash - -If the previous command failed, and you can't find the location of the RTI Connext installation, run this to find all Connext installations (and their corresponding helper scripts) in your system: - -.. code-block:: console - - $ find /opt -name rtisetenv*.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``rtisetenv*.bash``, ``rtisetenv*.sh``, ``rtisetenv*.zsh``, ``rtisetenv*.tcsh``. - -Make sure you have the ROS 2 environment set up: - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Build the RMW using colcon: - -.. code-block:: console - - $ colcon build --symlink-install - -After the build completes successfully, be sure to source the setup file for the workspace: - -.. code-block:: console - - $ source install/setup.bash - - -Use the resulting rmw_connextdds --------------------------------- - -Set the environment variable ``RMW_IMPLEMENTATION`` to tell ROS 2 which RMW to use: - -.. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_connextdds - -See also: :doc:`Working with multiple RMW implementations <../../../How-To-Guides/Working-with-multiple-RMW-implementations>` - -Run the talker and listener ---------------------------- - -Now run ``talker`` and ``listener`` to test RTI Connext DDS - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener +.. redirect-from:: + + Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS + +RTI Connext DDS +================= + +RTI Connext DDS is trusted in over 2000 of the world's most demanding system designs, distributing critical real-time data with the highest levels of performance, reliability, and security. +It is free-of-charge for prototyping, research, non-commercial and academic use. +Visit the `RTI website `__ for more information and to learn about options for support and commercial licenses. + + +Prerequisites +------------- + +Install RTI Connext DDS +^^^^^^^^^^^^^^^^^^^^^^^ + To build and use ``rmw_connextdds`` requires a version of Connext DDS compatible with the distribution of ROS 2 in use. + Connext DDS is included when installing ``rmw_connextdds`` using apt, or can be installed manually for building from source. + The following table details which Connext DDS versions are installed using ``apt``, and which versions are required for building from source: + + ================== =================== ==================== + ROS 2 Distribution Installed using apt To Build from Source + ================== =================== ==================== + rolling n/a ``7.7.0`` + kilted ``7.3.0`` ``7.3.0`` + jazzy ``6.0.1`` ``6.0.1`` + humble ``6.0.1`` ``6.0.1`` + ================== =================== ==================== + +RTI Connext Pro is available through a variety of channels: + +**ROS 2 apt repositories** + ROS 2 users can install a non-commercial-use version of the RTI Connext DDS libraries from the ROS apt repository using the following command: + + .. tabs:: + + .. group-tab:: v7.7.0 + + .. code-block:: console + + $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.7.0-ros + + .. group-tab:: v7.3.0 + + .. code-block:: console + + $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.3.0-ros + + .. group-tab:: v6.0.1 + + .. code-block:: console + + $ sudo apt update && sudo apt install -q -y rti-connext-dds-6.0.1 + + This package includes the RTI Connext core DDS libraries only; it does not include the full Connext Professional suite of tools and run-time services. + Note that these Connext libraries are automatically installed when installing ``rmw_connextdds`` using apt. + +**Other Installation Options** +The `Connext Robotics Toolkit `__ includes the full suite of Connext tools and infrastructure services. +It provides a single step installation of ROS and Connext using apt. +It is free for prototype development, research, non-commercial and academic use. + +Detailed instructions for building and tuning the RMW and ROS 2 applications for a variety of platforms, and enabling DDS Security are available on the `RTI ROS Community `__ pages. + + +Install rmw_connextdds binary packages +-------------------------------------- + +To install the binary packages for ``rmw_connextdds`` and the Connext libraries from the ROS 2 apt repositories, use the following command: + +.. code-block:: console + + $ sudo apt update && sudo apt install -q -y ros-{DISTRO}-rmw-connextdds + + +Building rmw_connextdds from source code +---------------------------------------- + +Building from source code can ensure the RMW is matched to your system and installed correctly. +The following instructions assume a Linux x86_64 build host and target; the `RTI ROS Community `__ +pages have instructions for building for other platforms and targets, including Arm, Windows, and macOS. + +Clone the repository for ``rmw_connextdds`` into your ROS 2 workspace and select the branch that matches the ROS 2 distribution in use: + +.. code-block:: console + + $ mkdir -p ros2_ws/src + $ cd ros2_ws + $ git clone -b {DISTRO} https://github.com/ros2/rmw_connextdds src/rmw_connextdds + +Then, install necessary packages for RTI Connext DDS. + +.. code-block:: console + + $ cd .. + $ rosdep install --from src -i + +Set up the environment to help colcon discover where RTI Connext is installed. +This can be done by manually setting the environment variable ``NDDSHOME`` to the location of the RTI Connext installation, or by using a script that comes with the RTI Connext installation. +For example, for version 7.7.0, you can run the following code to execute the helper script: + +.. code-block:: console + + $ source /opt/rti.com/rti_connext_dds-7.7.0/resource/scripts/rtisetenv_x64Linux4gcc8.5.0.bash + +If the previous command failed, and you can't find the location of the RTI Connext installation, run this to find all Connext installations (and their corresponding helper scripts) in your system: + +.. code-block:: console + + $ find /opt -name rtisetenv*.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``rtisetenv*.bash``, ``rtisetenv*.sh``, ``rtisetenv*.zsh``, ``rtisetenv*.tcsh``. + +Make sure you have the ROS 2 environment set up: + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Build the RMW using colcon: + +.. code-block:: console + + $ colcon build --symlink-install + +After the build completes successfully, be sure to source the setup file for the workspace: + +.. code-block:: console + + $ source install/setup.bash + + +Use the resulting rmw_connextdds +-------------------------------- + +Set the environment variable ``RMW_IMPLEMENTATION`` to tell ROS 2 which RMW to use: + +.. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_connextdds + +See also: :doc:`Working with multiple RMW implementations <../Working-with-multiple-RMW-implementations>` + +Run the talker and listener +--------------------------- + +Now run ``talker`` and ``listener`` to test RTI Connext DDS + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp listener \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst index 2a35c3b5d75..85a7c364983 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst @@ -1,72 +1,76 @@ -eProsima Fast DDS -================= - -eProsima Fast DDS is a complete open-source DDS implementation for real time embedded architectures and operating systems. -See also: https://www.eprosima.com/index.php/products-all/eprosima-fast-dds - - -Prerequisites -------------- - -Have :doc:`rosdep installed <../../../Tutorials/Intermediate/Rosdep>`. - -Install packages ----------------- - -The easiest way is to install from ROS 2 apt repository. - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-rmw-fastrtps-cpp - -Build from source code ----------------------- - -Building from source code is also another way to install. - -First, clone Fast DDS and rmw_fastrtps in the ROS 2 workspace source directory. - -.. code-block:: console - - $ cd ros2_ws/src - $ git clone https://github.com/ros2/rmw_fastrtps ros2/rmw_fastrtps -b {REPOS_FILE_BRANCH} - $ git clone https://github.com/eProsima/Fast-DDS eProsima/fastrtps - -Then, install necessary packages for Fast DDS. - -.. code-block:: console - - $ cd .. - $ rosdep install --from src -i - -Finally, run colcon build. - -.. code-block:: console - - $ colcon build --symlink-install - -Switch to rmw_fastrtps ----------------------- - -The eProsima Fast DDS RMW can be selected by specifying the environment variable: - -.. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - -See also: :doc:`Working with multiple RMW implementations <../../../How-To-Guides/Working-with-multiple-RMW-implementations>` - -Run the talker and listener ---------------------------- - -Now run ``talker`` and ``listener`` to test Fast DDS. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener +.. redirect-from:: + + Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS + +eProsima Fast DDS +================= + +eProsima Fast DDS is a complete open-source DDS implementation for real time embedded architectures and operating systems. +See also: https://www.eprosima.com/index.php/products-all/eprosima-fast-dds + + +Prerequisites +------------- + +Have :doc:`rosdep installed <../../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep>`. + +Install packages +---------------- + +The easiest way is to install from ROS 2 apt repository. + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-rmw-fastrtps-cpp + +Build from source code +---------------------- + +Building from source code is also another way to install. + +First, clone Fast DDS and rmw_fastrtps in the ROS 2 workspace source directory. + +.. code-block:: console + + $ cd ros2_ws/src + $ git clone https://github.com/ros2/rmw_fastrtps ros2/rmw_fastrtps -b {REPOS_FILE_BRANCH} + $ git clone https://github.com/eProsima/Fast-DDS eProsima/fastrtps + +Then, install necessary packages for Fast DDS. + +.. code-block:: console + + $ cd .. + $ rosdep install --from src -i + +Finally, run colcon build. + +.. code-block:: console + + $ colcon build --symlink-install + +Switch to rmw_fastrtps +---------------------- + +The eProsima Fast DDS RMW can be selected by specifying the environment variable: + +.. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + +See also: :doc:`Working with multiple RMW implementations <../Working-with-multiple-RMW-implementations>` + +Run the talker and listener +--------------------------- + +Now run ``talker`` and ``listener`` to test Fast DDS. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp listener \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst index 33f8fcecf0b..480b73b6b63 100644 --- a/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst @@ -1,15 +1,19 @@ -Non-DDS-Implementations -======================= - -* :doc:`Working with Zenoh ` explains how to utilize Zenoh. - -.. toctree:: - :hidden: - :glob: - - Non-DDS-Implementations/* - -If you would like to use one of the other vendors you will need to install their software separately before building. -The ROS 2 build will automatically build support for vendors that have been installed and sourced correctly. - -Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations <../../How-To-Guides/Working-with-multiple-RMW-implementations>`. +.. redirect-from:: + + Installation/RMW-Implementations/Non-DDS-Implementations + +Non-DDS-Implementations +======================= + +* :doc:`Working with Zenoh ` explains how to utilize Zenoh. + +.. toctree:: + :hidden: + :glob: + + Non-DDS-Implementations/* + +If you would like to use one of the other vendors you will need to install their software separately before building. +The ROS 2 build will automatically build support for vendors that have been installed and sourced correctly. + +Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations `. \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst index d75ac974548..8ff0fd93921 100644 --- a/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst +++ b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh.rst @@ -1,98 +1,101 @@ -Zenoh -===== - -Zenoh is an open source communication protocol and middleware designed to facilitate efficient data distribution across heterogeneous systems. -It provides location-transparent abstractions for high performance pub/sub and distributed queries. -See also: https://zenoh.io/docs/getting-started/first-app/ - -Prerequisites -------------- - -Have :doc:`rosdep installed <../../../Tutorials/Intermediate/Rosdep>`. - -Installation packages ---------------------- - -The rmw implementation Zenoh can be installed via binaries, recommended for stable development. - -Binary packages for supported ROS 2 distributions (see distro branches) are available on respective Tier-1 platforms for the distributions. -First ensure that your system is set up to install ROS 2 binaries by following the instructions here. - -Then install rmw_zenoh binaries using the command - -.. code-block:: bash - - sudo apt install ros-{DISTRO}-rmw-zenoh-cpp - -Build from source code ----------------------- - -Building from source is only recommended if latest features are needed. - -By default, we vendor and compile ``zenoh-cpp`` with a subset of zenoh features. -The ``ZENOHC_CARGO_FLAGS`` CMake argument may be overwritten with other features included if required. -See `zenoh_cpp_vendor/CMakeLists.txt `__ for more details. - -1. Clone the repository - -.. code-block:: bash - - mkdir ~/ws_rmw_zenoh/src -p && cd ~/ws_rmw_zenoh/src - git clone https://github.com/ros2/rmw_zenoh.git -b {DISTRO} - -1. Install dependencies: - -.. code-block:: bash - - cd ~/ws_rmw_zenoh - rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} -y - -3. Build the workspace using Colcon: - -.. code-block:: bash - - source /opt/ros/{DISTRO}/setup.bash - colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release - - -Switch to rmw_zenoh_cpp ------------------------- - -Switch from other rmw to rmw_zenoh_cpp by specifying the environment variable. - -.. code-block:: bash - - export RMW_IMPLEMENTATION=rmw_zenoh_cpp - -Run the talker and listener ---------------------------- - -Now run ``talker`` and ``listener`` to test Zenoh. - -Start the Zenoh router - -.. code-block:: bash - - # terminal 1 - source /opt/ros/{DISTRO}/setup.bash - ros2 run rmw_zenoh_cpp rmw_zenohd - -.. note:: Without the Zenoh router, nodes will not be able to discover each other since multicast discovery is disabled by default in the node's session config. - Instead, nodes will receive discovery information about other peers via the Zenoh router's gossip functionality. - -.. code-block:: bash - - # terminal 2 - export RMW_IMPLEMENTATION=rmw_zenoh_cpp - source /opt/ros/{DISTRO}/setup.bash - ros2 run demo_nodes_cpp talker - -.. code-block:: bash - - # terminal 3 - export RMW_IMPLEMENTATION=rmw_zenoh_cpp - source /opt/ros/{DISTRO}/setup.bash - ros2 run demo_nodes_cpp listener - -.. note:: Remember to source your ROS 2 setup script before running these commands. - +.. redirect-from:: + + Installation/RMW-Implementations/Non-DDS-Implementations/Working-with-Zenoh + +Zenoh +===== + +Zenoh is an open source communication protocol and middleware designed to facilitate efficient data distribution across heterogeneous systems. +It provides location-transparent abstractions for high performance pub/sub and distributed queries. +See also: https://zenoh.io/docs/getting-started/first-app/ + +Prerequisites +------------- + +Have :doc:`rosdep installed <../../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep>`. + +Installation packages +--------------------- + +The rmw implementation Zenoh can be installed via binaries, recommended for stable development. + +Binary packages for supported ROS 2 distributions (see distro branches) are available on respective Tier-1 platforms for the distributions. +First ensure that your system is set up to install ROS 2 binaries by following the instructions here. + +Then install rmw_zenoh binaries using the command + +.. code-block:: bash + + sudo apt install ros-{DISTRO}-rmw-zenoh-cpp + +Build from source code +---------------------- + +Building from source is only recommended if latest features are needed. + +By default, we vendor and compile ``zenoh-cpp`` with a subset of zenoh features. +The ``ZENOHC_CARGO_FLAGS`` CMake argument may be overwritten with other features included if required. +See `zenoh_cpp_vendor/CMakeLists.txt `__ for more details. + +1. Clone the repository + +.. code-block:: bash + + mkdir ~/ws_rmw_zenoh/src -p && cd ~/ws_rmw_zenoh/src + git clone https://github.com/ros2/rmw_zenoh.git -b {DISTRO} + +1. Install dependencies: + +.. code-block:: bash + + cd ~/ws_rmw_zenoh + rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} -y + +3. Build the workspace using Colcon: + +.. code-block:: bash + + source /opt/ros/{DISTRO}/setup.bash + colcon build --cmake-args -DCMAKE_BUILD_TYPE=Release + + +Switch to rmw_zenoh_cpp +------------------------ + +Switch from other rmw to rmw_zenoh_cpp by specifying the environment variable. + +.. code-block:: bash + + export RMW_IMPLEMENTATION=rmw_zenoh_cpp + +Run the talker and listener +--------------------------- + +Now run ``talker`` and ``listener`` to test Zenoh. + +Start the Zenoh router + +.. code-block:: bash + + # terminal 1 + source /opt/ros/{DISTRO}/setup.bash + ros2 run rmw_zenoh_cpp rmw_zenohd + +.. note:: Without the Zenoh router, nodes will not be able to discover each other since multicast discovery is disabled by default in the node's session config. + Instead, nodes will receive discovery information about other peers via the Zenoh router's gossip functionality. + +.. code-block:: bash + + # terminal 2 + export RMW_IMPLEMENTATION=rmw_zenoh_cpp + source /opt/ros/{DISTRO}/setup.bash + ros2 run demo_nodes_cpp talker + +.. code-block:: bash + + # terminal 3 + export RMW_IMPLEMENTATION=rmw_zenoh_cpp + source /opt/ros/{DISTRO}/setup.bash + ros2 run demo_nodes_cpp listener + +.. note:: Remember to source your ROS 2 setup script before running these commands. diff --git a/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst b/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst index 1dd73e6ed16..e04fce048ea 100644 --- a/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst @@ -1,194 +1,195 @@ -.. redirect-from:: - - Working-with-multiple-RMW-implementations - Guides/Working-with-multiple-RMW-implementations - Tutorials/Working-with-multiple-RMW-implementations - -Working with multiple ROS 2 middleware implementations -====================================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page explains the default RMW implementation and how to specify an alternative. - -Prerequisites --------------- - -You should have already read the :doc:`DDS and ROS middleware implementations page <../Concepts/Intermediate/About-Different-Middleware-Vendors>`. - -Specifying RMW implementations ------------------------------- - -To have multiple RMW implementations available for use you must have installed the ROS 2 binaries and any additional dependencies for specific RMW implementations, or built ROS 2 from source with multiple RMW implementations in the workspace (the RMW implementations are included in the build by default if their compile-time dependencies are met). -See :doc:`Install RMW implementations <../Installation/RMW-Implementations>`. - ----- - -Both C++ and Python nodes support an environment variable ``RMW_IMPLEMENTATION`` that allows the user to select the RMW implementation to use when running ROS 2 applications. - -The user may set this variable to a specific implementation identifier, such as ``rmw_cyclonedds_cpp``, ``rmw_fastrtps_cpp``, ``rmw_connextdds``, or ``rmw_gurumdds_cpp``. - -For example, to run the talker demo using the C++ talker and Python listener with the Connext RMW implementation: - -.. tabs:: - - .. group-tab:: Linux - - - Run in one terminal: - - .. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_cpp talker - - Run in another terminal: - - .. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_py listener - - .. group-tab:: macOS - - Run in one terminal: - - .. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_cpp talker - - Run in another terminal: - - .. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_py listener - - .. group-tab:: Windows - - Run in one terminal: - - .. code-block:: console - - $ set RMW_IMPLEMENTATION=rmw_connextdds - $ ros2 run demo_nodes_cpp talker - - Run in another terminal: - - .. code-block:: console - - $ set RMW_IMPLEMENTATION=rmw_connextdds - $ ros2 run demo_nodes_py listener - -Adding RMW implementations to your workspace --------------------------------------------- - -Additional DDS and RMW implementations can be added to your workspace by installing the necessary dependencies and rebuilding the workspace. -See the :doc:`RMW implementations <../Installation/RMW-Implementations>` page for more information about installing the available DDS options. - -Suppose that you have built your ROS 2 workspace with only Fast DDS installed and therefore only the Fast DDS RMW implementation built. -The last time your workspace was built, any other RMW implementation packages, ``rmw_connextdds`` for example, were probably unable to find installations of the relevant DDS implementations. -If you then install an additional DDS implementation, Connext for example, you will need to re-trigger the check for a Connext installation that occurs when the Connext RMW implementation is being built. -You can do this by specifying the ``--cmake-clean-cache`` flag on your next workspace build, and you should see that the RMW implementation package then gets built for the newly installed DDS implementation. - -It is possible to run into a problem when "rebuilding" the workspace with an additional RMW implementation using the ``--cmake-clean-cache`` option where the build complains about the default RMW implementation changing. -To resolve this, you can either set the default implementation to what is was before with the ``RMW_IMPLEMENTATION`` CMake argument or you can delete the build folder for packages that complain and continue the build with ``--packages-start ``. - -Troubleshooting ---------------- - -Checking the Current RMW -^^^^^^^^^^^^^^^^^^^^^^^^ - -To check the RMW that is currently in use you simply check the ``RMW_IMPLEMENTATION`` environment variable. -On Linux systems ``printenv`` prints the full list of environment variables. -Other operating systems will have other procedures for viewing environment variables. -If ``RMW_IMPLEMENTATION`` is not in the environment it is safe to assume you are using the default for your ROS distro, otherwise the current RMW is the value listed. -The default RMW for each ROS Distro can be found in `REP-2000 `_. - -Ensuring use of a particular RMW implementation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If the ``RMW_IMPLEMENTATION`` environment variable is set to an RMW implementation for which support is not installed, you will see an error message similar to the following if you have only one implementation installed: - -.. code-block:: bash - - Expected RMW implementation identifier of 'rmw_connextdds' but instead found 'rmw_fastrtps_cpp', exiting with 102. - -If you have support for multiple RMW implementations installed and you request use of one that is not installed, you will see something similar to: - -.. code-block:: bash - - Error getting RMW implementation identifier / RMW implementation not installed (expected identifier of 'rmw_connextdds'), exiting with 1. - -If this occurs, double check that your ROS 2 installation includes support for the RMW implementation that you have specified in the ``RMW_IMPLEMENTATION`` environment variable. - -If you want to switch between RMW implementations, verify that the ROS 2 daemon process is not running with the previous RMW implementation to avoid any issues between nodes and command line tools such as ``ros2 node``. -For example, if you run: - -.. code-block:: bash - - RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_cpp talker - -and - -.. code-block:: console - - $ ros2 node list - -it will generate a daemon with a Fast DDS implementation: - -.. code-block:: bash - - 21318 22.0 0.6 535896 55044 pts/8 Sl 16:14 0:00 /usr/bin/python3 /opt/ros/{DISTRO}/bin/_ros2_daemon --rmw-implementation rmw_fastrtps_cpp --ros-domain-id 0 - -Even if you run the command line tool again with the correct RMW implementation, the daemon's RMW implementation will not change and the ROS 2 command line tools will fail. - -To solve this, simply stop the daemon process: - -.. code-block:: console - - $ ros2 daemon stop - -and rerun the ROS 2 command line tool with the correct RMW implementation. - -RTI Connext on OSX: Failure due to insufficient shared memory kernel settings -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you receive an error message similar to below when running RTI Connext on OSX: - -.. code-block:: console - - [D0062|ENABLE]DDS_DomainParticipantPresentation_reserve_participant_index_entryports:!enable reserve participant index - [D0062|ENABLE]DDS_DomainParticipant_reserve_participant_index_entryports:Unusable shared memory transport. For a more in- depth explanation of the possible problem and solution, please visit https://community.rti.com/kb/osx510. - -This error is caused by an insufficient number or size of shared memory segments allowed by the operating system. -As a result, the ``DomainParticipant`` is unable to allocate enough resources and calculate its participant index which causes the error. - -You can increase the shared memory resources of your machine either temporarily or permanently. - -To increase the settings temporarily, you can run the following commands as user root: - -.. code-block:: console - - $ /usr/sbin/sysctl -w kern.sysv.shmmax=419430400 - $ /usr/sbin/sysctl -w kern.sysv.shmmin=1 - $ /usr/sbin/sysctl -w kern.sysv.shmmni=128 - $ /usr/sbin/sysctl -w kern.sysv.shmseg=1024 - $ /usr/sbin/sysctl -w kern.sysv.shmall=262144 - -To increase the settings permanently, you will need to edit or create the file ``/etc/sysctl.conf``. -Creating or editing this file will require root permissions. -Either add to your existing ``etc/sysctl.conf`` file or create ``/etc/sysctl.conf`` with the following lines: - -.. code-block:: bash - - kern.sysv.shmmax=419430400 - kern.sysv.shmmin=1 - kern.sysv.shmmni=128 - kern.sysv.shmseg=1024 - kern.sysv.shmall=262144 - -You will need to reboot the machine after modifying this file to have the changes take effect. - -This solution is edited from the RTI Connext community forum. -See the `original post `__ for a more detailed explanation. +.. redirect-from:: + + Working-with-multiple-RMW-implementations + Guides/Working-with-multiple-RMW-implementations + Tutorials/Working-with-multiple-RMW-implementations + How-To-Guides/Working-with-multiple-RMW-implementations + +Working with multiple ROS 2 middleware implementations +====================================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page explains the default RMW implementation and how to specify an alternative. + +Prerequisites +-------------- + +You should have already read the :doc:`DDS and ROS middleware implementations page <../../../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`. + +Specifying RMW implementations +------------------------------ + +To have multiple RMW implementations available for use you must have installed the ROS 2 binaries and any additional dependencies for specific RMW implementations, or built ROS 2 from source with multiple RMW implementations in the workspace (the RMW implementations are included in the build by default if their compile-time dependencies are met). +See :doc:`Install RMW implementations <../RMW-Implementations>`. + +---- + +Both C++ and Python nodes support an environment variable ``RMW_IMPLEMENTATION`` that allows the user to select the RMW implementation to use when running ROS 2 applications. + +The user may set this variable to a specific implementation identifier, such as ``rmw_cyclonedds_cpp``, ``rmw_fastrtps_cpp``, ``rmw_connextdds``, or ``rmw_gurumdds_cpp``. + +For example, to run the talker demo using the C++ talker and Python listener with the Connext RMW implementation: + +.. tabs:: + + .. group-tab:: Linux + + + Run in one terminal: + + .. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_cpp talker + + Run in another terminal: + + .. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_py listener + + .. group-tab:: macOS + + Run in one terminal: + + .. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_cpp talker + + Run in another terminal: + + .. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_py listener + + .. group-tab:: Windows + + Run in one terminal: + + .. code-block:: console + + $ set RMW_IMPLEMENTATION=rmw_connextdds + $ ros2 run demo_nodes_cpp talker + + Run in another terminal: + + .. code-block:: console + + $ set RMW_IMPLEMENTATION=rmw_connextdds + $ ros2 run demo_nodes_py listener + +Adding RMW implementations to your workspace +-------------------------------------------- + +Additional DDS and RMW implementations can be added to your workspace by installing the necessary dependencies and rebuilding the workspace. +See the :doc:`RMW implementations <../RMW-Implementations>` page for more information about installing the available DDS options. + +Suppose that you have built your ROS 2 workspace with only Fast DDS installed and therefore only the Fast DDS RMW implementation built. +The last time your workspace was built, any other RMW implementation packages, ``rmw_connextdds`` for example, were probably unable to find installations of the relevant DDS implementations. +If you then install an additional DDS implementation, Connext for example, you will need to re-trigger the check for a Connext installation that occurs when the Connext RMW implementation is being built. +You can do this by specifying the ``--cmake-clean-cache`` flag on your next workspace build, and you should see that the RMW implementation package then gets built for the newly installed DDS implementation. + +It is possible to run into a problem when "rebuilding" the workspace with an additional RMW implementation using the ``--cmake-clean-cache`` option where the build complains about the default RMW implementation changing. +To resolve this, you can either set the default implementation to what is was before with the ``RMW_IMPLEMENTATION`` CMake argument or you can delete the build folder for packages that complain and continue the build with ``--packages-start ``. + +Troubleshooting +--------------- + +Checking the Current RMW +^^^^^^^^^^^^^^^^^^^^^^^^ + +To check the RMW that is currently in use you simply check the ``RMW_IMPLEMENTATION`` environment variable. +On Linux systems ``printenv`` prints the full list of environment variables. +Other operating systems will have other procedures for viewing environment variables. +If ``RMW_IMPLEMENTATION`` is not in the environment it is safe to assume you are using the default for your ROS distro, otherwise the current RMW is the value listed. +The default RMW for each ROS Distro can be found in `REP-2000 `_. + +Ensuring use of a particular RMW implementation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If the ``RMW_IMPLEMENTATION`` environment variable is set to an RMW implementation for which support is not installed, you will see an error message similar to the following if you have only one implementation installed: + +.. code-block:: bash + + Expected RMW implementation identifier of 'rmw_connextdds' but instead found 'rmw_fastrtps_cpp', exiting with 102. + +If you have support for multiple RMW implementations installed and you request use of one that is not installed, you will see something similar to: + +.. code-block:: bash + + Error getting RMW implementation identifier / RMW implementation not installed (expected identifier of 'rmw_connextdds'), exiting with 1. + +If this occurs, double check that your ROS 2 installation includes support for the RMW implementation that you have specified in the ``RMW_IMPLEMENTATION`` environment variable. + +If you want to switch between RMW implementations, verify that the ROS 2 daemon process is not running with the previous RMW implementation to avoid any issues between nodes and command line tools such as ``ros2 node``. +For example, if you run: + +.. code-block:: bash + + RMW_IMPLEMENTATION=rmw_connextdds ros2 run demo_nodes_cpp talker + +and + +.. code-block:: console + + $ ros2 node list + +it will generate a daemon with a Fast DDS implementation: + +.. code-block:: bash + + 21318 22.0 0.6 535896 55044 pts/8 Sl 16:14 0:00 /usr/bin/python3 /opt/ros/{DISTRO}/bin/_ros2_daemon --rmw-implementation rmw_fastrtps_cpp --ros-domain-id 0 + +Even if you run the command line tool again with the correct RMW implementation, the daemon's RMW implementation will not change and the ROS 2 command line tools will fail. + +To solve this, simply stop the daemon process: + +.. code-block:: console + + $ ros2 daemon stop + +and rerun the ROS 2 command line tool with the correct RMW implementation. + +RTI Connext on OSX: Failure due to insufficient shared memory kernel settings +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you receive an error message similar to below when running RTI Connext on OSX: + +.. code-block:: console + + [D0062|ENABLE]DDS_DomainParticipantPresentation_reserve_participant_index_entryports:!enable reserve participant index + [D0062|ENABLE]DDS_DomainParticipant_reserve_participant_index_entryports:Unusable shared memory transport. For a more in- depth explanation of the possible problem and solution, please visit https://community.rti.com/kb/osx510. + +This error is caused by an insufficient number or size of shared memory segments allowed by the operating system. +As a result, the ``DomainParticipant`` is unable to allocate enough resources and calculate its participant index which causes the error. + +You can increase the shared memory resources of your machine either temporarily or permanently. + +To increase the settings temporarily, you can run the following commands as user root: + +.. code-block:: console + + $ /usr/sbin/sysctl -w kern.sysv.shmmax=419430400 + $ /usr/sbin/sysctl -w kern.sysv.shmmin=1 + $ /usr/sbin/sysctl -w kern.sysv.shmmni=128 + $ /usr/sbin/sysctl -w kern.sysv.shmseg=1024 + $ /usr/sbin/sysctl -w kern.sysv.shmall=262144 + +To increase the settings permanently, you will need to edit or create the file ``/etc/sysctl.conf``. +Creating or editing this file will require root permissions. +Either add to your existing ``etc/sysctl.conf`` file or create ``/etc/sysctl.conf`` with the following lines: + +.. code-block:: bash + + kern.sysv.shmmax=419430400 + kern.sysv.shmmin=1 + kern.sysv.shmmni=128 + kern.sysv.shmseg=1024 + kern.sysv.shmall=262144 + +You will need to reboot the machine after modifying this file to have the changes take effect. + +This solution is edited from the RTI Connext community forum. +See the `original post `__ for a more detailed explanation. \ No newline at end of file diff --git a/source/Get-Started/Installation/ROS-2-Mirrors.rst b/source/Get-Started/Installation/ROS-2-Mirrors.rst index 73b152a8e01..de171811406 100644 --- a/source/Get-Started/Installation/ROS-2-Mirrors.rst +++ b/source/Get-Started/Installation/ROS-2-Mirrors.rst @@ -1,120 +1,124 @@ -======= -Mirrors -======= - -.. contents:: Table of Contents - :depth: 3 - -Docs Mirrors ------------- - -Mirrors of the ROS Docs act as a backup when the `main site `_ is unavailable, and may provide faster access to users who are geographically closer to the mirror. - -Debian/Ubuntu (APT) Repository Mirrors --------------------------------------- - -To use these mirrors, replace the official ROS repository URL with the one listed below in your APT configuration. - -Asia -^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - Tsinghua University (TUNA) - - China - - `https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu/ `_ - * - USTC - - China - - `https://mirrors.ustc.edu.cn/ros2/ubuntu/ `_ - * - Alibaba Cloud (Aliyun) - - China - - `https://mirrors.aliyun.com/ros2/ubuntu/ `_ - * - Qilu University of Technology (QLU) - - China - - `https://mirrors.qlu.edu.cn/ros2/ubuntu/ `_ - -Europe -^^^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - Delft University of Technology - - the Netherlands - - `http://ftp.tudelft.nl/ros2/ubuntu/ `_ - -North America -^^^^^^^^^^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - University of Maryland (UMD) - - USA - - `http://mirror.umd.edu/packages.ros.org/ros2/ubuntu/ `_ - -Oceania -^^^^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - AARNet - - Australia - - `https://mirror.aarnet.edu.au/pub/ros2-packages/ubuntu/ `_ - -South America and Africa -^^^^^^^^^^^^^^^^^^^^^^^^ - -There are currently no officially verified ROS 2 mirrors for these regions. -If you are hosting a mirror in South America or Africa and would like it listed here, please see the **Hosting a Mirror** section below. - -Creating a mirror ------------------ - -If you are maintaining a mirror please join the Mirrors category on discourse.openrobotics.org: `https://discourse.openrobotics.org/c/infrastructure-project/infra-mirrors/ `_ for both feedback and prompt updates. - -Using a Mirror -^^^^^^^^^^^^^^ - -To use a mirror, replace ``packages.ros.org`` with the mirror URL in your ``ros2-latest.list`` file: - -.. code-block:: bash - - # Example for TUNA mirror - sudo sed -i 's|http://packages.ros.org/ros2/ubuntu|https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu|g' /etc/apt/sources.list.d/ros2-latest.list - sudo apt update - -Setting up a Mirror -------------------- - -The ROS infrastructure uses ``rsync`` to distribute packages. -To create a local mirror of the ROS 2 repositories: - -1. **Storage Requirement:** Ensure you have at least 500GB of available disk space. -2. **Sync Command:** Use ``rsync`` to pull from the official OSUOSL endpoints: - -.. code-block:: bash - - # Sync the main ROS 2 repository - rsync -azv rsync.osuosl.org::ros2-main /your/local/path --delete - -3. **Maintenance:** Set up a ``cron`` job to sync every 6-12 hours. - -Adding your mirror to this list -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To be officially listed, your mirror must meet the following requirements: - -* Support **HTTPS**. -* Sync at least once every 24 hours. -* Provide a contact email for infrastructure alerts. - -Once verified, please open a Pull Request against this page or post in the `Mirrors Discourse `_. - -Mirroring docs.ros.org ----------------------- - -Mirroring the documentation site requires specific configuration to prevent search engine fragmentation. -If you are interested in hosting a regional mirror of the documentation, please **contact the infrastructure team** via Discourse before proceeding. +.. redirect-from:: + + Installation/ROS-2-Mirrors + +======= +Mirrors +======= + +.. contents:: Table of Contents + :depth: 3 + +Docs Mirrors +------------ + +Mirrors of the ROS Docs act as a backup when the `main site `_ is unavailable, and may provide faster access to users who are geographically closer to the mirror. + +Debian/Ubuntu (APT) Repository Mirrors +-------------------------------------- + +To use these mirrors, replace the official ROS repository URL with the one listed below in your APT configuration. + +Asia +^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - Tsinghua University (TUNA) + - China + - `https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu/ `_ + * - USTC + - China + - `https://mirrors.ustc.edu.cn/ros2/ubuntu/ `_ + * - Alibaba Cloud (Aliyun) + - China + - `https://mirrors.aliyun.com/ros2/ubuntu/ `_ + * - Qilu University of Technology (QLU) + - China + - `https://mirrors.qlu.edu.cn/ros2/ubuntu/ `_ + +Europe +^^^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - Delft University of Technology + - the Netherlands + - `http://ftp.tudelft.nl/ros2/ubuntu/ `_ + +North America +^^^^^^^^^^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - University of Maryland (UMD) + - USA + - `http://mirror.umd.edu/packages.ros.org/ros2/ubuntu/ `_ + +Oceania +^^^^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - AARNet + - Australia + - `https://mirror.aarnet.edu.au/pub/ros2-packages/ubuntu/ `_ + +South America and Africa +^^^^^^^^^^^^^^^^^^^^^^^^ + +There are currently no officially verified ROS 2 mirrors for these regions. +If you are hosting a mirror in South America or Africa and would like it listed here, please see the **Hosting a Mirror** section below. + +Creating a mirror +----------------- + +If you are maintaining a mirror please join the Mirrors category on discourse.openrobotics.org: `https://discourse.openrobotics.org/c/infrastructure-project/infra-mirrors/ `_ for both feedback and prompt updates. + +Using a Mirror +^^^^^^^^^^^^^^ + +To use a mirror, replace ``packages.ros.org`` with the mirror URL in your ``ros2-latest.list`` file: + +.. code-block:: bash + + # Example for TUNA mirror + sudo sed -i 's|http://packages.ros.org/ros2/ubuntu|https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu|g' /etc/apt/sources.list.d/ros2-latest.list + sudo apt update + +Setting up a Mirror +------------------- + +The ROS infrastructure uses ``rsync`` to distribute packages. +To create a local mirror of the ROS 2 repositories: + +1. **Storage Requirement:** Ensure you have at least 500GB of available disk space. +2. **Sync Command:** Use ``rsync`` to pull from the official OSUOSL endpoints: + +.. code-block:: bash + + # Sync the main ROS 2 repository + rsync -azv rsync.osuosl.org::ros2-main /your/local/path --delete + +3. **Maintenance:** Set up a ``cron`` job to sync every 6-12 hours. + +Adding your mirror to this list +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To be officially listed, your mirror must meet the following requirements: + +* Support **HTTPS**. +* Sync at least once every 24 hours. +* Provide a contact email for infrastructure alerts. + +Once verified, please open a Pull Request against this page or post in the `Mirrors Discourse `_. + +Mirroring docs.ros.org +---------------------- + +Mirroring the documentation site requires specific configuration to prevent search engine fragmentation. +If you are interested in hosting a regional mirror of the documentation, please **contact the infrastructure team** via Discourse before proceeding. \ No newline at end of file diff --git a/source/Get-Started/Installation/Ubuntu-Install-Debs.rst b/source/Get-Started/Installation/Ubuntu-Install-Debs.rst index a48e88d4ca2..d1e6081cae5 100644 --- a/source/Get-Started/Installation/Ubuntu-Install-Debs.rst +++ b/source/Get-Started/Installation/Ubuntu-Install-Debs.rst @@ -1,147 +1,148 @@ -.. redirect-from:: - - Installation/Linux-Install-Debians - Installation/Ubuntu-Install-Debians - -Ubuntu (deb packages) -===================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Deb packages for ROS 2 {DISTRO_TITLE_FULL} are currently available for Ubuntu Resolute (26.04). -The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. -The target platforms are defined in `REP 2000 `__. -Most people will want to use a stable ROS distribution. - -Resources ---------- - -* Status Page: - - * ROS 2 {DISTRO_TITLE} (Ubuntu Resolute Raccoon 26.04): `amd64 `__\ , `arm64 `__ -* `Jenkins Instance `__ -* `Repositories `__ - -System setup ------------- - -Set locale -^^^^^^^^^^ - -.. include:: _Ubuntu-Set-Locale.rst - -Enable required repositories -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. include:: _Apt-Repositories.rst - -.. _linux-install-debs-install-ros-2-packages: - -Install development tools (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you are going to build ROS packages or otherwise do development, you can also install the development tools: - -.. code-block:: console - - $ sudo apt update && sudo apt install ros-dev-tools - -Install ROS 2 -------------- - -Update your apt repository caches after setting up the repositories. - -.. code-block:: console - - $ sudo apt update - -.. include:: _Apt-Upgrade-Admonition.rst - -Desktop Install (Recommended): ROS, RViz, demos, tutorials. - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-desktop - -ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. -No GUI tools. - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-ros-base - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. -See the :doc:`guide <../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - -Setup environment ------------------ - -Set up your environment by sourcing the following file. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - -Try some examples ------------------ - -If you installed ``ros-{DISTRO}-desktop`` above you can try some examples. - -In one terminal, source the setup file and then run a C++ ``talker``\ : - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -In another terminal source the setup file and then run a Python ``listener``\ : - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - -If you want to use other RMW implementations, you can check the :doc:`guide <./RMW-Implementations>`. - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :doc:`here <../How-To-Guides/Installation-Troubleshooting>`. - -Uninstall ---------- - -If you need to uninstall ROS 2 or switch to a source-based install once you -have already installed from binaries, run the following command: - -.. code-block:: console - - $ sudo apt remove '~nros-{DISTRO}-*' && sudo apt autoremove - -You may also want to remove the repository: - -.. code-block:: console - - $ sudo apt remove ros2-apt-source - $ sudo apt update - $ sudo apt autoremove - $ sudo apt upgrade # Consider upgrading for packages previously shadowed. +.. redirect-from:: + + Installation/Linux-Install-Debians + Installation/Ubuntu-Install-Debians + Installation/Ubuntu-Install-Debs + +Ubuntu (deb packages) +===================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Deb packages for ROS 2 {DISTRO_TITLE_FULL} are currently available for Ubuntu Resolute (26.04). +The Rolling Ridley distribution will change target platforms from time to time as new platforms are selected for development. +The target platforms are defined in `REP 2000 `__. +Most people will want to use a stable ROS distribution. + +Resources +--------- + +* Status Page: + + * ROS 2 {DISTRO_TITLE} (Ubuntu Resolute Raccoon 26.04): `amd64 `__\ , `arm64 `__ +* `Jenkins Instance `__ +* `Repositories `__ + +System setup +------------ + +Set locale +^^^^^^^^^^ + +.. include:: _Ubuntu-Set-Locale.rst + +Enable required repositories +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. include:: _Apt-Repositories.rst + +.. _linux-install-debs-install-ros-2-packages: + +Install development tools (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you are going to build ROS packages or otherwise do development, you can also install the development tools: + +.. code-block:: console + + $ sudo apt update && sudo apt install ros-dev-tools + +Install ROS 2 +------------- + +Update your apt repository caches after setting up the repositories. + +.. code-block:: console + + $ sudo apt update + +.. include:: _Apt-Upgrade-Admonition.rst + +Desktop Install (Recommended): ROS, RViz, demos, tutorials. + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-desktop + +ROS-Base Install (Bare Bones): Communication libraries, message packages, command line tools. +No GUI tools. + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-ros-base + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. +See the :doc:`guide ` on how to work with multiple RMWs. + +Setup environment +----------------- + +Set up your environment by sourcing the following file. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + +Try some examples +----------------- + +If you installed ``ros-{DISTRO}-desktop`` above you can try some examples. + +In one terminal, source the setup file and then run a C++ ``talker``\ : + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +In another terminal source the setup file and then run a Python ``listener``\ : + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it's ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + +If you want to use other RMW implementations, you can check the :doc:`guide `. + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :doc:`here `. + +Uninstall +--------- + +If you need to uninstall ROS 2 or switch to a source-based install once you +have already installed from binaries, run the following command: + +.. code-block:: console + + $ sudo apt remove '~nros-{DISTRO}-*' && sudo apt autoremove + +You may also want to remove the repository: + +.. code-block:: console + + $ sudo apt remove ros2-apt-source + $ sudo apt update + $ sudo apt autoremove + $ sudo apt upgrade # Consider upgrading for packages previously shadowed. \ No newline at end of file diff --git a/source/Get-Started/Installation/Windows-Install-Binary.rst b/source/Get-Started/Installation/Windows-Install-Binary.rst index 2fd6b039859..28cd277a5d8 100644 --- a/source/Get-Started/Installation/Windows-Install-Binary.rst +++ b/source/Get-Started/Installation/Windows-Install-Binary.rst @@ -1,158 +1,162 @@ -Windows (binary) -================ - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page explains how to install ROS 2 on Windows from a pre-built binary package. - -.. note:: - - The pre-built binary does not include all ROS 2 packages. - All packages in the `ROS base variant `_ are included, and only a subset of packages in the `ROS desktop variant `_ are included. - The exact list of packages are described by the repositories listed in `this ros2.repos file `_. - -System requirements -------------------- - -Only Windows 11 is supported. - -.. _windows-install-binary-installing-prerequisites: - -Create a location for the ROS 2 installation --------------------------------------------- - -This location will contain both the installed binary packages, plus the ROS 2 installation itself. - -Start a Command Prompt session (usually by clicking on the start menu, then typing ``Command Prompt``). - -Then create a directory to store the installation. -Because of Windows path-length limitations, this should be as short as possible. -We'll use ``C:\dev`` for the rest of these instructions. - -.. code-block:: console - - $ md C:\dev - -Install prerequisites ---------------------- - -ROS 2 uses `conda-forge `__ as a backend for packages, with `pixi `__ as the frontend. - -.. note:: - - The installation of conda-forge may trigger Windows Defender to treat it as a threat, but this can be safely ignored by clicking "More info" and "Run anyway". - -Install pixi -^^^^^^^^^^^^ - -Use use the instructions on https://pixi.sh/latest/ to install ``pixi`` either with the Windows Installer or using command line in your opened Command Prompt terminal. - -Once ``pixi`` has been installed, close the Command Prompt session and start it again, which will ensure ``pixi`` is on the PATH. - - -Install ROS 2 -------------- - -Binary releases of {DISTRO_TITLE_FULL} are not provided. -Instead you may download nightly :ref:`prerelease binaries `. - -* Download the latest package for Windows, e.g., ``ros2-package-windows-AMD64.zip``. -* Unpack the zip file somewhere on your system (we'll assume ``C:\dev\``). -* Change the name of the extracted folder to match the distro (we'll assume ``C:\dev\{DISTRO}``) - - -Install Pixi dependencies -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Go to the folder where you unzipped the ROS 2 prereleased binaries and install the dependencies - -.. code-block:: console - - $ cd C:\dev\{DISTRO} - $ pixi install - -Run preinstall installation script -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Run the preinstall installation setup script to make sure that the zipped file are able to run in the current folder the ROS 2 binaries have been exctrated to: - -.. code-block:: console - - $ pixi run python preinstall_setup_windows.py - - -Install additional RMW implementations (optional) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. -See the :doc:`guide <../How-To-Guides/Working-with-multiple-RMW-implementations>` on how to work with multiple RMWs. - - -Setup environment ------------------ - -In either the same Command Prompt terminal or a new one, you can source the ROS 2 environment - -Source the pixi environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Source the pixi environment to set up dependencies: - -.. code-block:: console - - $ cd C:\dev\{DISTRO} - -Source the ROS 2 environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This is required in every Command Prompt you open to setup the ROS 2 workspace: - -.. code-block:: console - - $ call C:\dev\{DISTRO}\local_setup.bat - -If you do not have RTI Connext DDS installed on your computer, it is normal to receive a warning that it is missing. - -Try some examples ------------------ - -In a Command Prompt, set up the ROS 2 environment as described above and then run a C++ ``talker``\ : - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker - -Start another Command Prompt terminal and run a Python ``listener``\ : - -.. code-block:: console - - $ ros2 run demo_nodes_py listener - -You should see the ``talker`` saying that it is ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. -This verifies both the C++ and Python APIs are working properly. -Hooray! - - -Next steps ----------- - -Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. - -Troubleshoot ------------- - -Troubleshooting techniques can be found :ref:`here `. - -Uninstall ---------- - -1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. - This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. - -2. If you're also trying to free up space, you can delete the entire workspace directory with: - - .. code-block:: console - - $ rmdir /s /q C:\dev\{DISTRO} +.. redirect-from:: + + Installation/Windows-Install-Binary + +Windows (binary) +================ + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page explains how to install ROS 2 on Windows from a pre-built binary package. + +.. note:: + + The pre-built binary does not include all ROS 2 packages. + All packages in the `ROS base variant `_ are included, and only a subset of packages in the `ROS desktop variant `_ are included. + The exact list of packages are described by the repositories listed in `this ros2.repos file `_. + +System requirements +------------------- + +Only Windows 11 is supported. + +.. _windows-install-binary-installing-prerequisites: + +Create a location for the ROS 2 installation +-------------------------------------------- + +This location will contain both the installed binary packages, plus the ROS 2 installation itself. + +Start a Command Prompt session (usually by clicking on the start menu, then typing ``Command Prompt``). + +Then create a directory to store the installation. +Because of Windows path-length limitations, this should be as short as possible. +We'll use ``C:\dev`` for the rest of these instructions. + +.. code-block:: console + + $ md C:\dev + +Install prerequisites +--------------------- + +ROS 2 uses `conda-forge `__ as a backend for packages, with `pixi `__ as the frontend. + +.. note:: + + The installation of conda-forge may trigger Windows Defender to treat it as a threat, but this can be safely ignored by clicking "More info" and "Run anyway". + +Install pixi +^^^^^^^^^^^^ + +Use use the instructions on https://pixi.sh/latest/ to install ``pixi`` either with the Windows Installer or using command line in your opened Command Prompt terminal. + +Once ``pixi`` has been installed, close the Command Prompt session and start it again, which will ensure ``pixi`` is on the PATH. + + +Install ROS 2 +------------- + +Binary releases of {DISTRO_TITLE_FULL} are not provided. +Instead you may download nightly :ref:`prerelease binaries `. + +* Download the latest package for Windows, e.g., ``ros2-package-windows-AMD64.zip``. +* Unpack the zip file somewhere on your system (we'll assume ``C:\dev\``). +* Change the name of the extracted folder to match the distro (we'll assume ``C:\dev\{DISTRO}``) + + +Install Pixi dependencies +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Go to the folder where you unzipped the ROS 2 prereleased binaries and install the dependencies + +.. code-block:: console + + $ cd C:\dev\{DISTRO} + $ pixi install + +Run preinstall installation script +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Run the preinstall installation setup script to make sure that the zipped file are able to run in the current folder the ROS 2 binaries have been exctrated to: + +.. code-block:: console + + $ pixi run python preinstall_setup_windows.py + + +Install additional RMW implementations (optional) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default middleware that ROS 2 uses is ``Fast DDS``, but the middleware (RMW) can be replaced at runtime. +See the :doc:`guide ` on how to work with multiple RMWs. + + +Setup environment +----------------- + +In either the same Command Prompt terminal or a new one, you can source the ROS 2 environment + +Source the pixi environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Source the pixi environment to set up dependencies: + +.. code-block:: console + + $ cd C:\dev\{DISTRO} + +Source the ROS 2 environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This is required in every Command Prompt you open to setup the ROS 2 workspace: + +.. code-block:: console + + $ call C:\dev\{DISTRO}\local_setup.bat + +If you do not have RTI Connext DDS installed on your computer, it is normal to receive a warning that it is missing. + +Try some examples +----------------- + +In a Command Prompt, set up the ROS 2 environment as described above and then run a C++ ``talker``\ : + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker + +Start another Command Prompt terminal and run a Python ``listener``\ : + +.. code-block:: console + + $ ros2 run demo_nodes_py listener + +You should see the ``talker`` saying that it is ``Publishing`` messages and the ``listener`` saying ``I heard`` those messages. +This verifies both the C++ and Python APIs are working properly. +Hooray! + + +Next steps +---------- + +Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your environment, create your own workspace and packages, and learn ROS 2 core concepts. + +Troubleshoot +------------ + +Troubleshooting techniques can be found :ref:`here `. + +Uninstall +--------- + +1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. + This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. + +2. If you're also trying to free up space, you can delete the entire workspace directory with: + + .. code-block:: console + + $ rmdir /s /q C:\dev\{DISTRO} \ No newline at end of file diff --git a/source/Get-Started/Installation/_Apt-Repositories.rst b/source/Get-Started/Installation/_Apt-Repositories.rst index f6c9d51ea84..a797e6ceca3 100644 --- a/source/Get-Started/Installation/_Apt-Repositories.rst +++ b/source/Get-Started/Installation/_Apt-Repositories.rst @@ -1,20 +1,24 @@ -You will need to add the ROS 2 apt repository to your system. - -First ensure that the `Ubuntu Universe repository `_ is enabled. - -.. code-block:: console - - $ sudo apt install software-properties-common - $ sudo add-apt-repository universe - -The `ros-apt-source `_ packages provide keys and apt source configuration for the various ROS repositories. - -Installing the ros2-apt-source package will configure ROS 2 repositories for your system. -Updates to repository configuration will occur automatically when new versions of this package are released to the ROS repositories. - -.. code-block:: console - - $ sudo apt update && sudo apt install curl -y - $ export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}') - $ curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb" - $ sudo dpkg -i /tmp/ros2-apt-source.deb +.. redirect-from:: + + Installation/_Apt-Repositories + +You will need to add the ROS 2 apt repository to your system. + +First ensure that the `Ubuntu Universe repository `_ is enabled. + +.. code-block:: console + + $ sudo apt install software-properties-common + $ sudo add-apt-repository universe + +The `ros-apt-source `_ packages provide keys and apt source configuration for the various ROS repositories. + +Installing the ros2-apt-source package will configure ROS 2 repositories for your system. +Updates to repository configuration will occur automatically when new versions of this package are released to the ROS repositories. + +.. code-block:: console + + $ sudo apt update && sudo apt install curl -y + $ export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}') + $ curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb" + $ sudo dpkg -i /tmp/ros2-apt-source.deb \ No newline at end of file diff --git a/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst b/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst index 4a81d13095f..30a656b66c9 100644 --- a/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst +++ b/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst @@ -1,6 +1,10 @@ -ROS 2 packages are built on frequently updated Ubuntu systems. -It is always recommended that you ensure your system is up to date before installing new packages. - -.. code-block:: console - - $ sudo apt upgrade +.. redirect-from:: + + Installation/_Apt-Upgrade-Admonition + +ROS 2 packages are built on frequently updated Ubuntu systems. +It is always recommended that you ensure your system is up to date before installing new packages. + +.. code-block:: console + + $ sudo apt upgrade \ No newline at end of file diff --git a/source/Get-Started/Installation/_Dnf-Update-Admonition.rst b/source/Get-Started/Installation/_Dnf-Update-Admonition.rst index bdff3f3e33b..00886edb704 100644 --- a/source/Get-Started/Installation/_Dnf-Update-Admonition.rst +++ b/source/Get-Started/Installation/_Dnf-Update-Admonition.rst @@ -1,6 +1,10 @@ -ROS 2 packages are built on frequently updated RHEL systems. -It is always recommended that you ensure your system is up to date before installing new packages. - -.. code-block:: console - - $ sudo dnf update +.. redirect-from:: + + Installation/_Dnf-Update-Admonition + +ROS 2 packages are built on frequently updated RHEL systems. +It is always recommended that you ensure your system is up to date before installing new packages. + +.. code-block:: console + + $ sudo dnf update \ No newline at end of file diff --git a/source/Get-Started/Installation/_RHEL-Set-Locale.rst b/source/Get-Started/Installation/_RHEL-Set-Locale.rst index 0edf4f21c28..d5ae721dc2c 100644 --- a/source/Get-Started/Installation/_RHEL-Set-Locale.rst +++ b/source/Get-Started/Installation/_RHEL-Set-Locale.rst @@ -1,13 +1,17 @@ -Make sure you have a locale which supports ``UTF-8``. -If you are in a minimal environment (such as a docker container), the locale may be something minimal like ``C``. -We test with the following settings. -However, it should be fine if you're using a different UTF-8 supported locale. - -.. code-block:: console - - $ locale # check for UTF-8 - - $ sudo dnf install langpacks-en glibc-langpack-en - $ export LANG=en_US.UTF-8 - - $ locale # verify settings +.. redirect-from:: + + Installation/_RHEL-Set-Locale + +Make sure you have a locale which supports ``UTF-8``. +If you are in a minimal environment (such as a docker container), the locale may be something minimal like ``C``. +We test with the following settings. +However, it should be fine if you're using a different UTF-8 supported locale. + +.. code-block:: console + + $ locale # check for UTF-8 + + $ sudo dnf install langpacks-en glibc-langpack-en + $ export LANG=en_US.UTF-8 + + $ locale # verify settings \ No newline at end of file diff --git a/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst b/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst index 751639b1285..631729616d3 100644 --- a/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst +++ b/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst @@ -1,15 +1,19 @@ -Make sure you have a locale which supports ``UTF-8``. -If you are in a minimal environment (such as a docker container), the locale may be something minimal like ``POSIX``. -We test with the following settings. -However, it should be fine if you're using a different UTF-8 supported locale. - -.. code-block:: console - - $ locale # check for UTF-8 - - $ sudo apt update && sudo apt install locales - $ sudo locale-gen en_US en_US.UTF-8 - $ sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 - $ export LANG=en_US.UTF-8 - - $ locale # verify settings +.. redirect-from:: + + Installation/_Ubuntu-Set-Locale + +Make sure you have a locale which supports ``UTF-8``. +If you are in a minimal environment (such as a docker container), the locale may be something minimal like ``POSIX``. +We test with the following settings. +However, it should be fine if you're using a different UTF-8 supported locale. + +.. code-block:: console + + $ locale # check for UTF-8 + + $ sudo apt update && sudo apt install locales + $ sudo locale-gen en_US en_US.UTF-8 + $ sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 + $ export LANG=en_US.UTF-8 + + $ locale # verify settings \ No newline at end of file diff --git a/source/Get-Started/Installation/_rosdep_Linux_Mint.rst b/source/Get-Started/Installation/_rosdep_Linux_Mint.rst index 9b86573ffe8..144c1cd9fae 100644 --- a/source/Get-Started/Installation/_rosdep_Linux_Mint.rst +++ b/source/Get-Started/Installation/_rosdep_Linux_Mint.rst @@ -1,2 +1,6 @@ -**Note**: If you're using a distribution that is based on Ubuntu (like Linux Mint) but does not identify itself as such, you'll get an error message like ``Unsupported OS [mint]``. -In this case append ``--os=ubuntu:resolute`` to the above command. +.. redirect-from:: + + Installation/_rosdep_Linux_Mint + +**Note**: If you're using a distribution that is based on Ubuntu (like Linux Mint) but does not identify itself as such, you'll get an error message like ``Unsupported OS [mint]``. +In this case append ``--os=ubuntu:resolute`` to the above command. \ No newline at end of file diff --git a/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst b/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst index 23755c0e920..66148829c95 100644 --- a/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst +++ b/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst @@ -1,271 +1,272 @@ -.. redirect-from:: - - Tutorials/Turtlesim/Introducing-Turtlesim - -.. _Turtlesim: - -Using ``turtlesim``, ``ros2``, and ``rqt`` -========================================== - -**Goal:** Install and use the turtlesim package and rqt tools to prepare for upcoming tutorials. - -**Tutorial level:** Beginner - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Turtlesim is a lightweight simulator for learning ROS 2. -It illustrates what ROS 2 does at the most basic level to give you an idea of what you will do with a real robot or a robot simulation later on. - -The ros2 tool is how the user manages, introspects, and interacts with a ROS system. -It supports multiple commands that target different aspects of the system and its operation. -One might use it to start a node, set a parameter, listen to a topic, and many more. -The ros2 tool is part of the core ROS 2 installation. - -rqt is a graphical user interface (GUI) tool for ROS 2. -Everything done in rqt can be done on the command line, but rqt provides a more user-friendly way to manipulate ROS 2 elements. - -This tutorial touches upon core ROS 2 concepts, like nodes, topics, and services. -All of these concepts will be elaborated on in later tutorials; for now, you will simply set up the tools and get a feel for them. - -Prerequisites -------------- - -The previous tutorial, :doc:`../Configuring-ROS2-Environment`, will show you how to set up your environment. - -Tasks ------ - -1 Install turtlesim -^^^^^^^^^^^^^^^^^^^ - -As always, start by sourcing your setup files in a new terminal, as described in the :doc:`previous tutorial <../Configuring-ROS2-Environment>`. - -Install the turtlesim package for your ROS 2 distro: - -.. tabs:: - - .. group-tab:: Ubuntu - - .. code-block:: console - - $ sudo apt update - $ sudo apt install ros-{DISTRO}-turtlesim - - .. group-tab:: RHEL - - .. code-block:: console - - $ sudo dnf install ros-{DISTRO}-turtlesim - - .. group-tab:: macOS - - As long as the archive you installed ROS 2 from contains the ``ros_tutorials`` repository, you should already have turtlesim installed. - - .. group-tab:: Windows - - As long as the archive you installed ROS 2 from contains the ``ros_tutorials`` repository, you should already have turtlesim installed. - -To check if the package is installed, run the following command, which should return a list of turtlesim's executables: - -.. code-block:: console - - $ ros2 pkg executables turtlesim - turtlesim draw_square - turtlesim mimic - turtlesim turtle_teleop_key - turtlesim turtlesim_node - -2 Start turtlesim -^^^^^^^^^^^^^^^^^ - -To start turtlesim, enter the following command in your terminal: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - [INFO] [turtlesim]: Starting turtlesim with node name /turtlesim - [INFO] [turtlesim]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - -Under the command, you will see messages from the node. -There you can see the default turtle's name and the coordinates where it spawns. - -The simulator window should appear, with a random turtle in the center. - -.. image:: images/turtlesim.png - - -3 Use turtlesim -^^^^^^^^^^^^^^^ - -Open a new terminal and source ROS 2 again. - -Now you will run a new node to control the turtle in the first node: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -At this point you should have three windows open: a terminal running ``turtlesim_node``, a terminal running ``turtle_teleop_key`` and the turtlesim window. -Arrange these windows so that you can see the turtlesim window, but also have the terminal running ``turtle_teleop_key`` active so that you can control the turtle in turtlesim. - -Use the arrow keys on your keyboard to control the turtle. -It will move around the screen, using its attached "pen" to draw the path it followed so far. - -.. note:: - - Pressing an arrow key will only cause the turtle to move a short distance and then stop. - This is because, realistically, you wouldn't want a robot to continue carrying on an instruction if, for example, the operator lost the connection to the robot. - -You can see the nodes, and their associated topics, services, and actions, using the ``list`` subcommands of the respective commands: - -.. code-block:: console - - $ ros2 node list - $ ros2 topic list - $ ros2 service list - $ ros2 action list - -You will learn more about these concepts in the coming tutorials. -Since the goal of this tutorial is only to get a general overview of turtlesim, you will use rqt to call some of the turtlesim services and interact with ``turtlesim_node``. - -4 Install rqt -^^^^^^^^^^^^^ - -Open a new terminal to install ``rqt`` and its plugins: - -.. tabs:: - - .. group-tab:: Ubuntu - - .. code-block:: console - - $ sudo apt update - $ sudo apt install ros-{DISTRO}-rqt ros-{DISTRO}-rqt-common-plugins - - .. group-tab:: RHEL - - .. code-block:: console - - $ sudo dnf install 'ros-{DISTRO}-rqt*' - - .. group-tab:: macOS - - The standard archive for installing ROS 2 on macOS contains ``rqt`` and its plugins, so you should already have ``rqt`` installed. - - .. group-tab:: Windows - - The standard archive for installing ROS 2 on Windows contains ``rqt`` and its plugins, so you should already have ``rqt`` installed. - -To run rqt: - -.. code-block:: console - - $ rqt - -5 Use rqt -^^^^^^^^^ - -When running rqt for the first time, the window will be blank. -No worries; just select **Plugins** > **Services** > **Service Caller** from the menu bar at the top. - -.. note:: - - It may take some time for rqt to locate all the plugins. - If you click on **Plugins** but don't see **Services** or any other options, you should close rqt and enter the command ``rqt --force-discover`` in your terminal. - -.. image:: images/rqt.png - -Use the refresh button to the left of the **Service** dropdown list to ensure all the services of your turtlesim node are available. - -Click on the **Service** dropdown list to see turtlesim's services, and select the ``/spawn`` service. - -5.1 Try the spawn service -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Let's use rqt to call the ``/spawn`` service. -You can guess from its name that ``/spawn`` will create another turtle in the turtlesim window. - -Give the new turtle a unique name, like ``turtle2``, by double-clicking between the empty single quotes in the **Expression** column. -You can see that this expression corresponds to the value of **name** and is of type **string**. - -Next enter some valid coordinates at which to spawn the new turtle, like ``x = 1.0`` and ``y = 1.0``. - -.. image:: images/spawn.png - -.. note:: - - If you try to spawn a new turtle with the same name as an existing turtle, like the default ``turtle1``, you will get an error message in the terminal running ``turtlesim_node``: - - .. code-block:: console - - [ERROR] [turtlesim]: A turtle named [turtle1] already exists - -To spawn ``turtle2``, you then need to call the service by clicking the **Call** button on the upper right side of the rqt window. - -If the service call was successful, you should see a new turtle (again with a random design) spawn at the coordinates you input for **x** and **y**. - -If you refresh the service list in rqt, you will also see that now there are services related to the new turtle, ``/turtle2/...``, in addition to ``/turtle1/...``. - -5.2 Try the set_pen service -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now let's give ``turtle1`` a unique pen using the ``/set_pen`` service: - -.. image:: images/set_pen.png - -The values for **r**, **g** and **b**, which are between 0 and 255, set the color of the pen ``turtle1`` draws with, and **width** sets the thickness of the line. - -To have ``turtle1`` draw with a distinct red line, change the value of **r** to 255, and the value of **width** to 5. -Don't forget to call the service after updating the values. - -If you return to the terminal where ``turtle_teleop_key`` is running and press the arrow keys, you will see ``turtle1``'s pen has changed. - -.. image:: images/new_pen.png - -You've probably also noticed that there's no way to move ``turtle2``. -That's because there is no teleop node for ``turtle2``. - -6 Remapping -^^^^^^^^^^^ - -You need a second teleop node in order to control ``turtle2``. -However, if you try to run the same command as before, you will notice that this one also controls ``turtle1``. -The way to change this behavior is by remapping the ``cmd_vel`` topic and the ``rotate_absolute`` action. - -In a new terminal, source ROS 2, and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key --ros-args --remap turtle1/cmd_vel:=turtle2/cmd_vel --remap turtle1/rotate_absolute:=turtle2/rotate_absolute - - -Now, you can move ``turtle2`` when this terminal is active, and ``turtle1`` when the other terminal running ``turtle_teleop_key`` is active. - -.. image:: images/remap.png - -7 Close turtlesim -^^^^^^^^^^^^^^^^^ - -To stop the simulation, you can enter ``Ctrl + C`` in the ``turtlesim_node`` terminal, and ``q`` in the ``turtle_teleop_key`` terminals. - -Summary -------- - -Using turtlesim and rqt is a great way to learn the core concepts of ROS 2. - -Next steps ----------- - -Now that you have turtlesim and rqt up and running, and an idea of how they work, let's dive into the first core ROS 2 concept with the next tutorial, :doc:`../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes`. - -Related content ---------------- - -The turtlesim package can be found in the `ros_tutorials `_ repo. +.. redirect-from:: + + Tutorials/Turtlesim/Introducing-Turtlesim + Tutorials/Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim + +.. _Turtlesim: + +Using ``turtlesim``, ``ros2``, and ``rqt`` +========================================== + +**Goal:** Install and use the turtlesim package and rqt tools to prepare for upcoming tutorials. + +**Tutorial level:** Beginner + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Turtlesim is a lightweight simulator for learning ROS 2. +It illustrates what ROS 2 does at the most basic level to give you an idea of what you will do with a real robot or a robot simulation later on. + +The ros2 tool is how the user manages, introspects, and interacts with a ROS system. +It supports multiple commands that target different aspects of the system and its operation. +One might use it to start a node, set a parameter, listen to a topic, and many more. +The ros2 tool is part of the core ROS 2 installation. + +rqt is a graphical user interface (GUI) tool for ROS 2. +Everything done in rqt can be done on the command line, but rqt provides a more user-friendly way to manipulate ROS 2 elements. + +This tutorial touches upon core ROS 2 concepts, like nodes, topics, and services. +All of these concepts will be elaborated on in later tutorials; for now, you will simply set up the tools and get a feel for them. + +Prerequisites +------------- + +The previous tutorial, :doc:`../Configuring-ROS2-Environment`, will show you how to set up your environment. + +Tasks +----- + +1 Install turtlesim +^^^^^^^^^^^^^^^^^^^ + +As always, start by sourcing your setup files in a new terminal, as described in the :doc:`previous tutorial <../Configuring-ROS2-Environment>`. + +Install the turtlesim package for your ROS 2 distro: + +.. tabs:: + + .. group-tab:: Ubuntu + + .. code-block:: console + + $ sudo apt update + $ sudo apt install ros-{DISTRO}-turtlesim + + .. group-tab:: RHEL + + .. code-block:: console + + $ sudo dnf install ros-{DISTRO}-turtlesim + + .. group-tab:: macOS + + As long as the archive you installed ROS 2 from contains the ``ros_tutorials`` repository, you should already have turtlesim installed. + + .. group-tab:: Windows + + As long as the archive you installed ROS 2 from contains the ``ros_tutorials`` repository, you should already have turtlesim installed. + +To check if the package is installed, run the following command, which should return a list of turtlesim's executables: + +.. code-block:: console + + $ ros2 pkg executables turtlesim + turtlesim draw_square + turtlesim mimic + turtlesim turtle_teleop_key + turtlesim turtlesim_node + +2 Start turtlesim +^^^^^^^^^^^^^^^^^ + +To start turtlesim, enter the following command in your terminal: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + [INFO] [turtlesim]: Starting turtlesim with node name /turtlesim + [INFO] [turtlesim]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + +Under the command, you will see messages from the node. +There you can see the default turtle's name and the coordinates where it spawns. + +The simulator window should appear, with a random turtle in the center. + +.. image:: images/turtlesim.png + + +3 Use turtlesim +^^^^^^^^^^^^^^^ + +Open a new terminal and source ROS 2 again. + +Now you will run a new node to control the turtle in the first node: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +At this point you should have three windows open: a terminal running ``turtlesim_node``, a terminal running ``turtle_teleop_key`` and the turtlesim window. +Arrange these windows so that you can see the turtlesim window, but also have the terminal running ``turtle_teleop_key`` active so that you can control the turtle in turtlesim. + +Use the arrow keys on your keyboard to control the turtle. +It will move around the screen, using its attached "pen" to draw the path it followed so far. + +.. note:: + + Pressing an arrow key will only cause the turtle to move a short distance and then stop. + This is because, realistically, you wouldn't want a robot to continue carrying on an instruction if, for example, the operator lost the connection to the robot. + +You can see the nodes, and their associated topics, services, and actions, using the ``list`` subcommands of the respective commands: + +.. code-block:: console + + $ ros2 node list + $ ros2 topic list + $ ros2 service list + $ ros2 action list + +You will learn more about these concepts in the coming tutorials. +Since the goal of this tutorial is only to get a general overview of turtlesim, you will use rqt to call some of the turtlesim services and interact with ``turtlesim_node``. + +4 Install rqt +^^^^^^^^^^^^^ + +Open a new terminal to install ``rqt`` and its plugins: + +.. tabs:: + + .. group-tab:: Ubuntu + + .. code-block:: console + + $ sudo apt update + $ sudo apt install ros-{DISTRO}-rqt ros-{DISTRO}-rqt-common-plugins + + .. group-tab:: RHEL + + .. code-block:: console + + $ sudo dnf install 'ros-{DISTRO}-rqt*' + + .. group-tab:: macOS + + The standard archive for installing ROS 2 on macOS contains ``rqt`` and its plugins, so you should already have ``rqt`` installed. + + .. group-tab:: Windows + + The standard archive for installing ROS 2 on Windows contains ``rqt`` and its plugins, so you should already have ``rqt`` installed. + +To run rqt: + +.. code-block:: console + + $ rqt + +5 Use rqt +^^^^^^^^^ + +When running rqt for the first time, the window will be blank. +No worries; just select **Plugins** > **Services** > **Service Caller** from the menu bar at the top. + +.. note:: + + It may take some time for rqt to locate all the plugins. + If you click on **Plugins** but don't see **Services** or any other options, you should close rqt and enter the command ``rqt --force-discover`` in your terminal. + +.. image:: images/rqt.png + +Use the refresh button to the left of the **Service** dropdown list to ensure all the services of your turtlesim node are available. + +Click on the **Service** dropdown list to see turtlesim's services, and select the ``/spawn`` service. + +5.1 Try the spawn service +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Let's use rqt to call the ``/spawn`` service. +You can guess from its name that ``/spawn`` will create another turtle in the turtlesim window. + +Give the new turtle a unique name, like ``turtle2``, by double-clicking between the empty single quotes in the **Expression** column. +You can see that this expression corresponds to the value of **name** and is of type **string**. + +Next enter some valid coordinates at which to spawn the new turtle, like ``x = 1.0`` and ``y = 1.0``. + +.. image:: images/spawn.png + +.. note:: + + If you try to spawn a new turtle with the same name as an existing turtle, like the default ``turtle1``, you will get an error message in the terminal running ``turtlesim_node``: + + .. code-block:: console + + [ERROR] [turtlesim]: A turtle named [turtle1] already exists + +To spawn ``turtle2``, you then need to call the service by clicking the **Call** button on the upper right side of the rqt window. + +If the service call was successful, you should see a new turtle (again with a random design) spawn at the coordinates you input for **x** and **y**. + +If you refresh the service list in rqt, you will also see that now there are services related to the new turtle, ``/turtle2/...``, in addition to ``/turtle1/...``. + +5.2 Try the set_pen service +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now let's give ``turtle1`` a unique pen using the ``/set_pen`` service: + +.. image:: images/set_pen.png + +The values for **r**, **g** and **b**, which are between 0 and 255, set the color of the pen ``turtle1`` draws with, and **width** sets the thickness of the line. + +To have ``turtle1`` draw with a distinct red line, change the value of **r** to 255, and the value of **width** to 5. +Don't forget to call the service after updating the values. + +If you return to the terminal where ``turtle_teleop_key`` is running and press the arrow keys, you will see ``turtle1``'s pen has changed. + +.. image:: images/new_pen.png + +You've probably also noticed that there's no way to move ``turtle2``. +That's because there is no teleop node for ``turtle2``. + +6 Remapping +^^^^^^^^^^^ + +You need a second teleop node in order to control ``turtle2``. +However, if you try to run the same command as before, you will notice that this one also controls ``turtle1``. +The way to change this behavior is by remapping the ``cmd_vel`` topic and the ``rotate_absolute`` action. + +In a new terminal, source ROS 2, and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key --ros-args --remap turtle1/cmd_vel:=turtle2/cmd_vel --remap turtle1/rotate_absolute:=turtle2/rotate_absolute + + +Now, you can move ``turtle2`` when this terminal is active, and ``turtle1`` when the other terminal running ``turtle_teleop_key`` is active. + +.. image:: images/remap.png + +7 Close turtlesim +^^^^^^^^^^^^^^^^^ + +To stop the simulation, you can enter ``Ctrl + C`` in the ``turtlesim_node`` terminal, and ``q`` in the ``turtle_teleop_key`` terminals. + +Summary +------- + +Using turtlesim and rqt is a great way to learn the core concepts of ROS 2. + +Next steps +---------- + +Now that you have turtlesim and rqt up and running, and an idea of how they work, let's dive into the first core ROS 2 concept with the next tutorial, :doc:`../../ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes`. + +Related content +--------------- + +The turtlesim package can be found in the `ros_tutorials `_ repo. \ No newline at end of file diff --git a/source/Get-Started/Releases.rst b/source/Get-Started/Releases.rst index 7007cc415fe..119b27ad4f0 100644 --- a/source/Get-Started/Releases.rst +++ b/source/Get-Started/Releases.rst @@ -1,235 +1,239 @@ -.. _Releases: - -Distributions -============= - -What is a Distribution? ------------------------ - -A ROS distribution is a versioned set of ROS packages. -These are akin to Linux distributions (e.g. Ubuntu). -The purpose of the ROS distributions is to let developers work against a relatively stable codebase until they are ready to roll everything forward. -Therefore once a distribution is released, we try to limit changes to bug fixes and non-breaking improvements for the core packages (every thing under ros-desktop-full). -That generally applies to the whole community, but for "higher" level packages, the rules are less strict, and so it falls to the maintainers of a given package to avoid breaking changes. - -.. _list_of_distributions: - -List of Distributions ---------------------- - -Below is a list of current and historic ROS 2 distributions. -Rows in the table marked in blue are the currently supported distributions. - -.. toctree:: - :hidden: - - Get-Started/Releases/Release-Process - Get-Started/Releases/Release-Kilted-Kaiju - Get-Started/Releases/Release-Jazzy-Jalisco - Get-Started/Releases/Release-Humble-Hawksbill - Get-Started/Releases/Release-Rolling-Ridley - Get-Started/Releases/Development - Get-Started/Releases/End-of-Life - -.. raw:: html - - - - -.. |rolling| image:: Releases/rolling-small.png - :alt: Rolling logo - -.. |kilted| image:: Releases/kilted-small.png - :alt: Kilted logo - -.. |jazzy| image:: Releases/jazzy-small.png - :alt: Jazzy logo - -.. |iron| image:: Releases/iron-small.png - :alt: Iron logo - -.. |humble| image:: Releases/humble-small.png - :alt: Humble logo - -.. |galactic| image:: Releases/galactic-small.png - :alt: Galactic logo - -.. |foxy| image:: Releases/foxy-small.png - :alt: Foxy logo - -.. |eloquent| image:: Releases/eloquent-small.png - :alt: Eloquent logo - -.. |dashing| image:: Releases/dashing-small.png - :alt: Dashing logo - -.. |crystal| image:: Releases/crystal-small.png - :alt: Crystal logo - -.. |bouncy| image:: Releases/bouncy-small.png - :alt: Bouncy logo - -.. |ardent| image:: Releases/ardent-small.png - :alt: Ardent logo - -.. list-table:: - :class: distros - :header-rows: 1 - :widths: 35 25 30 20 10 - - * - Distro - - Release date - - Logo - - EOL date - - ROS Boss - * - :doc:`Kilted Kaiju ` - - May 23, 2025 - - |kilted| - - December 2026 - - `Scott K Logan `_ - * - :doc:`Jazzy Jalisco ` - - May 23, 2024 - - |jazzy| - - May 2029 - - `Marco A. Gutiérrez `_ - * - :doc:`Iron Irwini ` - - May 23, 2023 - - |iron| - - December 4, 2024 - - `Yadunund Vijay `_ - * - :doc:`Humble Hawksbill ` - - May 23, 2022 - - |humble| - - May 2027 - - `Christophe Bédard `_ / `Audrow Nash `_ - * - :doc:`Galactic Geochelone ` - - May 23, 2021 - - |galactic| - - December 9, 2022 - - `Scott Logan `_ - * - :doc:`Foxy Fitzroy ` - - June 5, 2020 - - |foxy| - - June 20, 2023 - - `Jacob Perron `_ / `Dharini Dutia `_ - * - :doc:`Eloquent Elusor ` - - November 22, 2019 - - |eloquent| - - November 2020 - - `Michael Carroll `_ - * - :doc:`Dashing Diademata ` - - May 31, 2019 - - |dashing| - - May 2021 - - `Steven! Ragnarök `_ - * - :doc:`Crystal Clemmys ` - - December 14, 2018 - - |crystal| - - December 2019 - - `Steven! Ragnarök `_ - * - :doc:`Bouncy Bolson ` - - July 2, 2018 - - |bouncy| - - July 2019 - - `Mikael Arguedas `_ / `Steven! Ragnarök `_ - * - :doc:`Ardent Apalone ` - - December 8, 2017 - - |ardent| - - December 2018 - - `Steven! Ragnarök `_ - * - :doc:`beta3 ` - - September 13, 2017 - - - - December 2017 - - - * - :doc:`beta2 ` - - July 5, 2017 - - - - September 2017 - - - * - :doc:`beta1 ` - - December 19, 2016 - - - - Jul 2017 - - - * - :doc:`alpha1 - alpha8 ` - - August 31, 2015 - - - - December 2016 - - - -Future Distributions --------------------- - -For details on upcoming features see the :doc:`roadmap `. - -There is a new ROS 2 distribution released yearly on May 23rd (`World Turtle Day `_). - -.. list-table:: - :class: future-distros - :header-rows: 1 - :widths: 35 30 20 15 - - * - Distro - - Release date - - Logo - - EOL date - * - :doc:`Lyrical Luth ` - - May 2026 - - TBD - - May 2031 - - -.. _rolling_distribution: - -Rolling Distribution --------------------- - -:doc:`ROS 2 Rolling Ridley ` is the rolling development distribution of ROS 2. -It is described in `REP 2002 `_ and was first introduced in June 2020. - -The Rolling distribution of ROS 2 serves two purposes: - -1. it is a staging area for future stable distributions of ROS 2, and -2. it is a collection of the most recent development releases. - -As the name implies, Rolling is continuously updated and **can have in-place updates that include breaking changes**. -We recommend that most people use the most recent stable distribution instead (see :ref:`list_of_distributions`). - -Packages released into the Rolling distribution will be automatically released into future stable distributions of ROS 2. -:doc:`Releasing a ROS 2 package <../How-To-Guides/Releasing/Releasing-a-Package>` into the Rolling distribution follows the same procedures as all other ROS 2 distributions. - -Cross-Distribution Communications ---------------------------------- - -Nodes are not guaranteed to be able to communicate across distributions. -For example, a node built & running against Humble is not guaranteed to be able to communicate correctly with a node built & running against Iron. -It may or may not work, but it is not supported and should not be relied upon. -Note that :ref:`cross-vendor (single-distro) communications are also not guaranteed `. +.. redirect-from:: + + Releases + +.. _Releases: + +Distributions +============= + +What is a Distribution? +----------------------- + +A ROS distribution is a versioned set of ROS packages. +These are akin to Linux distributions (e.g. Ubuntu). +The purpose of the ROS distributions is to let developers work against a relatively stable codebase until they are ready to roll everything forward. +Therefore once a distribution is released, we try to limit changes to bug fixes and non-breaking improvements for the core packages (every thing under ros-desktop-full). +That generally applies to the whole community, but for "higher" level packages, the rules are less strict, and so it falls to the maintainers of a given package to avoid breaking changes. + +.. _list_of_distributions: + +List of Distributions +--------------------- + +Below is a list of current and historic ROS 2 distributions. +Rows in the table marked in blue are the currently supported distributions. + +.. toctree:: + :hidden: + + Get-Started/Releases/Release-Process + Get-Started/Releases/Release-Kilted-Kaiju + Get-Started/Releases/Release-Jazzy-Jalisco + Get-Started/Releases/Release-Humble-Hawksbill + Get-Started/Releases/Release-Rolling-Ridley + Get-Started/Releases/Development + Get-Started/Releases/End-of-Life + +.. raw:: html + + + + +.. |rolling| image:: Releases/rolling-small.png + :alt: Rolling logo + +.. |kilted| image:: Releases/kilted-small.png + :alt: Kilted logo + +.. |jazzy| image:: Releases/jazzy-small.png + :alt: Jazzy logo + +.. |iron| image:: Releases/iron-small.png + :alt: Iron logo + +.. |humble| image:: Releases/humble-small.png + :alt: Humble logo + +.. |galactic| image:: Releases/galactic-small.png + :alt: Galactic logo + +.. |foxy| image:: Releases/foxy-small.png + :alt: Foxy logo + +.. |eloquent| image:: Releases/eloquent-small.png + :alt: Eloquent logo + +.. |dashing| image:: Releases/dashing-small.png + :alt: Dashing logo + +.. |crystal| image:: Releases/crystal-small.png + :alt: Crystal logo + +.. |bouncy| image:: Releases/bouncy-small.png + :alt: Bouncy logo + +.. |ardent| image:: Releases/ardent-small.png + :alt: Ardent logo + +.. list-table:: + :class: distros + :header-rows: 1 + :widths: 35 25 30 20 10 + + * - Distro + - Release date + - Logo + - EOL date + - ROS Boss + * - :doc:`Kilted Kaiju ` + - May 23, 2025 + - |kilted| + - December 2026 + - `Scott K Logan `_ + * - :doc:`Jazzy Jalisco ` + - May 23, 2024 + - |jazzy| + - May 2029 + - `Marco A. Gutiérrez `_ + * - :doc:`Iron Irwini ` + - May 23, 2023 + - |iron| + - December 4, 2024 + - `Yadunund Vijay `_ + * - :doc:`Humble Hawksbill ` + - May 23, 2022 + - |humble| + - May 2027 + - `Christophe Bédard `_ / `Audrow Nash `_ + * - :doc:`Galactic Geochelone ` + - May 23, 2021 + - |galactic| + - December 9, 2022 + - `Scott Logan `_ + * - :doc:`Foxy Fitzroy ` + - June 5, 2020 + - |foxy| + - June 20, 2023 + - `Jacob Perron `_ / `Dharini Dutia `_ + * - :doc:`Eloquent Elusor ` + - November 22, 2019 + - |eloquent| + - November 2020 + - `Michael Carroll `_ + * - :doc:`Dashing Diademata ` + - May 31, 2019 + - |dashing| + - May 2021 + - `Steven! Ragnarök `_ + * - :doc:`Crystal Clemmys ` + - December 14, 2018 + - |crystal| + - December 2019 + - `Steven! Ragnarök `_ + * - :doc:`Bouncy Bolson ` + - July 2, 2018 + - |bouncy| + - July 2019 + - `Mikael Arguedas `_ / `Steven! Ragnarök `_ + * - :doc:`Ardent Apalone ` + - December 8, 2017 + - |ardent| + - December 2018 + - `Steven! Ragnarök `_ + * - :doc:`beta3 ` + - September 13, 2017 + - + - December 2017 + - + * - :doc:`beta2 ` + - July 5, 2017 + - + - September 2017 + - + * - :doc:`beta1 ` + - December 19, 2016 + - + - Jul 2017 + - + * - :doc:`alpha1 - alpha8 ` + - August 31, 2015 + - + - December 2016 + - + +Future Distributions +-------------------- + +For details on upcoming features see the :doc:`roadmap <../The-ROS2-Project/Roadmap>`. + +There is a new ROS 2 distribution released yearly on May 23rd (`World Turtle Day `_). + +.. list-table:: + :class: future-distros + :header-rows: 1 + :widths: 35 30 20 15 + + * - Distro + - Release date + - Logo + - EOL date + * - :doc:`Lyrical Luth ` + - May 2026 + - TBD + - May 2031 + + +.. _rolling_distribution: + +Rolling Distribution +-------------------- + +:doc:`ROS 2 Rolling Ridley ` is the rolling development distribution of ROS 2. +It is described in `REP 2002 `_ and was first introduced in June 2020. + +The Rolling distribution of ROS 2 serves two purposes: + +1. it is a staging area for future stable distributions of ROS 2, and +2. it is a collection of the most recent development releases. + +As the name implies, Rolling is continuously updated and **can have in-place updates that include breaking changes**. +We recommend that most people use the most recent stable distribution instead (see :ref:`list_of_distributions`). + +Packages released into the Rolling distribution will be automatically released into future stable distributions of ROS 2. +:doc:`Releasing a ROS 2 package <../How-To-Guides/Releasing/Releasing-a-Package>` into the Rolling distribution follows the same procedures as all other ROS 2 distributions. + +Cross-Distribution Communications +--------------------------------- + +Nodes are not guaranteed to be able to communicate across distributions. +For example, a node built & running against Humble is not guaranteed to be able to communicate correctly with a node built & running against Iron. +It may or may not work, but it is not supported and should not be relied upon. +Note that :ref:`cross-vendor (single-distro) communications are also not guaranteed `. \ No newline at end of file diff --git a/source/Get-Started/Releases/Alpha-Overview.rst b/source/Get-Started/Releases/Alpha-Overview.rst index 514cec769ed..c288075a166 100644 --- a/source/Get-Started/Releases/Alpha-Overview.rst +++ b/source/Get-Started/Releases/Alpha-Overview.rst @@ -1,411 +1,412 @@ -.. redirect-from:: - - Alpha-Overview - -Alphas -====== - -.. contents:: Table of Contents - :depth: 2 - :local: - -This is a merged version of the previously separated pages for the 8 alpha releases of ROS 2. - -We hope that you try them out and `provide feedback <../../Contact>`. - -ROS 2 alpha8 release (code name *Hook-and-Loop*; October 2016) ----------------------------------------------------------------- - -Changes to supported DDS vendors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 supports multiple middleware implementations (see `this page <../../Concepts/Intermediate/About-Different-Middleware-Vendors>` for more details). -Until Alpha 8, ROS 2 was supporting ROS middleware implementations for eProsima's Fast RTPS, RTI's Connext and PrismTech's OpenSplice. -To streamline our efforts, as of Alpha 8, Fast RTPS and Connext (static) will be supported, with Fast RTPS (`now Apache 2.0-licensed `__) shipped as the default. - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from complete. -You should not expect to switch from ROS 1 to ROS 2, nor should you expect to build a new robot control system with ROS 2. -Rather, you should expect to try out some demos, explore the code, and perhaps write your own demos. - -The improvements included in this release are: - - -* Several improvements to Fast RTPS and its rmw implementation - - * Support for large (image) messages in Fast RTPS - * ``wait_for_service`` functionality in Fast RTPS - -* Support for all ROS 2 message types in Python and C -* Added support for Quality of Service (QoS) settings in Python -* Fixed various bugs with the previous alpha release - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha7 release (code name *Glue Gun*\ ; July 2016) --------------------------------------------------------- - -.. contents:: Table of Contents - :local: - -New version of Ubuntu required -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Until Alpha 6 ROS 2 was targeting Ubuntu Trusty Tahr (14.04). As of this Alpha ROS 2 is targeting Ubuntu Xenial Xerus (16.04) to benefit from newer versions of the compiler, CMake, Python, etc. - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from complete. -You should not expect to switch from ROS 1 to ROS 2, nor should you expect to build a new robot control system with ROS 2. -Rather, you should expect to try out some demos, explore the code, and perhaps write your own demos. - -The major features included in this release are: - - -* Graph API functionality: wait_for_service - - * Added interfaces in rclcpp and make use of them in examples, demos, and tests - -* Improved support for large messages in both Connext and Fast-RTPS (partial for Fast-RTPS) -* Turtlebot demo using ported code from ROS 1 - - * See: https://github.com/ros2/turtlebot2_demo - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha6 release (code name *Fastener*; June 2016) ------------------------------------------------------- - -.. contents:: Table of Contents - :local: - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from -complete. -You should not expect to switch from ROS 1 to ROS 2, nor should -you expect to build a new robot control system with ROS 2. -Rather, you -should expect to try out some demos, explore the code, and perhaps write -your own demos. - -The major features included in this release are: - - -* Graph API functionality: wait_for_service - - * Added graph guard condition to nodes for waiting on graph changes - * Added ``rmw_service_server_is_available`` for verifying if a service is available - -* Refactored ``rclcpp`` to use ``rcl`` -* Improved support for complex message types in Python - - * Nested messages - * Arrays - * Strings - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha5 release (code name *Epoxy*; April 2016) ------------------------------------------------------- - -.. contents:: Table of Contents - :local: - - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from -complete. -You should not expect to switch from ROS 1 to ROS 2, nor should -you expect to build a new robot control system with ROS 2. -Rather, you -should expect to try out some demos, explore the code, and perhaps write -your own demos. - -The major features included in this release are: - - -* Support for C data structures in Fast RTPS and Connext Dynamic rmw implementations. -* Support services in C. -* Added 32-bit and 64-bit ARM as experimentally supported platforms. - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha4 release (code name *Duct tape*; February 2016) ------------------------------------------------------------ - -.. contents:: Table of Contents - :local: - -Background -^^^^^^^^^^ - -As explained in a `design article `__, -we are engaged in the development of a new major version of ROS, called "ROS 2." -While the underlying concepts (e.g., publish / subscribe messaging) and goals -(e.g., flexibility and reusability) are the same as for ROS 1, we are taking this -opportunity to make substantial changes to the system, including changing -some of the core APIs. -For a deeper treatment of those changes and their rationale, consult the other -`ROS 2 design articles `__. - -Status -^^^^^^ - -On February 17, 2016, we are releasing ROS 2 alpha4, -code-named **Duct tape**. -Our primary goal with this release is to add more features, while also addressing the feedback we received for the previous releases. -To that end, we built a set of `demos <../../Tutorials>` that -show some of the key features of ROS 2. -We encourage you to try out those -demos, look at the code that implements them, and `provide -feedback <../../Contact>`. -We're especially interested to know how well (or -poorly) we're addressing use cases that are important to you. - -Intended audience -^^^^^^^^^^^^^^^^^ - -While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. -At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from -complete. -You should not expect to switch from ROS 1 to ROS 2, nor should -you expect to build a new robot control system with ROS 2. -Rather, you -should expect to try out some demos, explore the code, and perhaps write -your own demos. - -The major features included in this release are: - - -* Improved type support infrastructure, including support for C -* Preliminary Python client library, only publishers and subscriptions are supported. Beware, the API is subject to change and is far from complete! -* Added structures for ROS time in C API (still needs C++ API) - - * New concept of extensible "time sources" for ROS Time, the default time source will be like ROS 1 (implementation pending) - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha3 release (code name *Cement*; December 2015) ----------------------------------------------------------- - -.. contents:: Table of Contents - :local: - - -Background -^^^^^^^^^^ - -As explained in a `design article `__, -we are engaged in the development of a new major version of ROS, called "ROS 2." -While the underlying concepts (e.g., publish / subscribe messaging) and goals -(e.g., flexibility and reusability) are the same as for ROS 1, we are taking this -opportunity to make substantial changes to the system, including changing -some of the core APIs. -For a deeper treatment of those changes and their rationale, consult the other -`ROS 2 design articles `__. - -Status -^^^^^^ - -On December 18, 2015, we are releasing ROS 2 alpha3, -code-named **Cement**. -Our primary goal with this release is to add more features, while also addressing the feedback we received for the previous releases. -To that end, we built a set of `demos <../../Tutorials>` that -show some of the key features of ROS 2. -We encourage you to try out those -demos, look at the code that implements them, and `provide -feedback <../../Contact>`. -We're especially interested to know how well (or -poorly) we're addressing use cases that are important to you. - -Intended audience -^^^^^^^^^^^^^^^^^ - -While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. -At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from -complete. -You should not expect to switch from ROS 1 to ROS 2, nor should -you expect to build a new robot control system with ROS 2. -Rather, you -should expect to try out some demos, explore the code, and perhaps write -your own demos. - -The major features included in this release are: - - -* Updated ``rcl`` interface. - - * This interface will be wrapped in order to create language bindings, e.g. ``rclpy``. - * This interface has improved documentation and test coverage over existing interfaces we currently have, e.g. ``rmw`` and ``rclcpp``. - * See `rcl headers `__. - -* Added support in rclcpp for using the TLSF (two-level segregate fit) allocator, a memory allocator design for embedded and real-time systems. -* Improved efficiency of MultiThreadedExecutor and fixed numerous bugs with multi-threaded execution, which is now test on CI. -* Added ability to cancel an Executor from within a callback called in spin. -* Added ability for a timer to cancel itself by supporting a Timer callback that accepts a reference to itself as a function parameter. -* Added checks for disallowing multiple threads to enter Executor::spin. -* Improved reliability of numerous tests that had been sporadically failing. -* Added support for using Fast RTPS (instead of, e.g., OpenSplice or Connext). -* A partial port of tf2 including the core libraries and core command line tools. - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha2 release (code name *Baling wire*; October 2015) --------------------------------------------------------------- - -.. contents:: Table of Contents - :local: - -Background -^^^^^^^^^^ - -As explained in a `design -article `__, we are engaged in -the development of a new major version of ROS, called "ROS 2." While the -underlying concepts (e.g., publish / subscribe messaging) and goals (e.g., -flexibility and reusability) are the same as for ROS 1, we are taking this -opportunity to make substantial changes to the system, including changing -some of the core APIs. -For a deeper treatment of those changes and their -rationale, consult the other `ROS 2 design -articles `__. - - -Status -^^^^^^ - -On November 3, 2015, we are releasing ROS 2 alpha2, -code-named **Baling wire**. -Our primary goal with this release is to add more features, while also addressing the feedback we received for the previous alpha 1 release. -To that end, we built a set of `demos <../../Tutorials>` that -show some of the key features of ROS 2. -We encourage you to try out those -demos, look at the code that implements them, and `provide -feedback <../../Contact>`. -We're especially interested to know how well (or -poorly) we're addressing use cases that are important to you. - - -Intended audience -^^^^^^^^^^^^^^^^^ - -While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. -At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. - - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from -complete. -You should not expect to switch from ROS 1 to ROS 2, nor should -you expect to build a new robot control system with ROS 2. -Rather, you -should expect to try out some demos, explore the code, and perhaps write -your own demos. - -The major features included in this release are: - - -* Support for custom allocators in rclcpp, useful for real-time messaging -* Feature parity of Windows with Linux/OSX, including workspace management, services and parameters -* rclcpp API improvements -* FreeRTPS improvements - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. - -ROS 2 alpha1 release (code name *Anchor*; August 2015) --------------------------------------------------------- - -.. contents:: Table of Contents - :local: - -Background -^^^^^^^^^^ - -As explained in a `design -article `__, we are engaged in -the development of a new major version of ROS, called "ROS 2." While the -underlying concepts (e.g., publish / subscribe messaging) and goals (e.g., -flexibility and reusability) are the same as for ROS 1, we are taking this -opportunity to make substantial changes to the system, including changing -some of the core APIs. -For a deeper treatment of those changes and their -rationale, consult the other `ROS 2 design -articles `__. - - -Status -^^^^^^ - -On August 31, 2015, we are releasing ROS 2 alpha1, -code-named **Anchor**. -Our primary goal with this release is to give -you the opportunity to understand how ROS 2 works, in particular how it -differs from ROS 1. -To that end, we built a set of `demos <../../Tutorials>` that -show some of the key features of ROS 2. -We encourage you to try out those -demos, look at the code that implements them, and `provide -feedback <../../Contact>`. -We're especially interested to know how well (or -poorly) we're addressing use cases that are important to you. - - -Intended audience -^^^^^^^^^^^^^^^^^ - -While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. -At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. - - -Scope -^^^^^ - -As the "alpha" qualifier suggests, this release of ROS 2 is far from -complete. -You should not expect to switch from ROS 1 to ROS 2, nor should -you expect to build a new robot control system with ROS 2. -Rather, you -should expect to try out some demos, explore the code, and perhaps write -your own demos. - -The major features included in this release are: - - -* Discovery, transport, and serialization `use DDS `__ -* Support `multiple DDS vendors `__ -* Support messaging primitives: topics (publish / subscribe), services (request / response), and parameters -* Support Linux (Ubuntu Trusty), OS X (Yosemite) and Windows (8) -* `Use quality-of-service settings to handle lossy networks <../Tutorials/Demos/Quality-of-Service>` -* `Communicate inter-process or intra-process with the same API <../Tutorials/Demos/Intra-Process-Communication>` -* `Write real-time safe code that uses the ROS 2 APIs <../Tutorials/Demos/Real-Time-Programming>` -* `Run ROS 2 on "bare-metal" microcontrollers (no operating system) `__ -* `Bridge communication between ROS 1 and ROS 2 `__ - -Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. +.. redirect-from:: + + Alpha-Overview + Releases/Alpha-Overview + +Alphas +====== + +.. contents:: Table of Contents + :depth: 2 + :local: + +This is a merged version of the previously separated pages for the 8 alpha releases of ROS 2. + +We hope that you try them out and `provide feedback <../../Contact>`. + +ROS 2 alpha8 release (code name *Hook-and-Loop*; October 2016) +---------------------------------------------------------------- + +Changes to supported DDS vendors +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 supports multiple middleware implementations (see `this page <../../Concepts/Intermediate/About-Different-Middleware-Vendors>` for more details). +Until Alpha 8, ROS 2 was supporting ROS middleware implementations for eProsima's Fast RTPS, RTI's Connext and PrismTech's OpenSplice. +To streamline our efforts, as of Alpha 8, Fast RTPS and Connext (static) will be supported, with Fast RTPS (`now Apache 2.0-licensed `__) shipped as the default. + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from complete. +You should not expect to switch from ROS 1 to ROS 2, nor should you expect to build a new robot control system with ROS 2. +Rather, you should expect to try out some demos, explore the code, and perhaps write your own demos. + +The improvements included in this release are: + + +* Several improvements to Fast RTPS and its rmw implementation + + * Support for large (image) messages in Fast RTPS + * ``wait_for_service`` functionality in Fast RTPS + +* Support for all ROS 2 message types in Python and C +* Added support for Quality of Service (QoS) settings in Python +* Fixed various bugs with the previous alpha release + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha7 release (code name *Glue Gun*\ ; July 2016) +-------------------------------------------------------- + +.. contents:: Table of Contents + :local: + +New version of Ubuntu required +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Until Alpha 6 ROS 2 was targeting Ubuntu Trusty Tahr (14.04). As of this Alpha ROS 2 is targeting Ubuntu Xenial Xerus (16.04) to benefit from newer versions of the compiler, CMake, Python, etc. + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from complete. +You should not expect to switch from ROS 1 to ROS 2, nor should you expect to build a new robot control system with ROS 2. +Rather, you should expect to try out some demos, explore the code, and perhaps write your own demos. + +The major features included in this release are: + + +* Graph API functionality: wait_for_service + + * Added interfaces in rclcpp and make use of them in examples, demos, and tests + +* Improved support for large messages in both Connext and Fast-RTPS (partial for Fast-RTPS) +* Turtlebot demo using ported code from ROS 1 + + * See: https://github.com/ros2/turtlebot2_demo + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha6 release (code name *Fastener*; June 2016) +------------------------------------------------------ + +.. contents:: Table of Contents + :local: + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from +complete. +You should not expect to switch from ROS 1 to ROS 2, nor should +you expect to build a new robot control system with ROS 2. +Rather, you +should expect to try out some demos, explore the code, and perhaps write +your own demos. + +The major features included in this release are: + + +* Graph API functionality: wait_for_service + + * Added graph guard condition to nodes for waiting on graph changes + * Added ``rmw_service_server_is_available`` for verifying if a service is available + +* Refactored ``rclcpp`` to use ``rcl`` +* Improved support for complex message types in Python + + * Nested messages + * Arrays + * Strings + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha5 release (code name *Epoxy*; April 2016) +------------------------------------------------------ + +.. contents:: Table of Contents + :local: + + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from +complete. +You should not expect to switch from ROS 1 to ROS 2, nor should +you expect to build a new robot control system with ROS 2. +Rather, you +should expect to try out some demos, explore the code, and perhaps write +your own demos. + +The major features included in this release are: + + +* Support for C data structures in Fast RTPS and Connext Dynamic rmw implementations. +* Support services in C. +* Added 32-bit and 64-bit ARM as experimentally supported platforms. + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha4 release (code name *Duct tape*; February 2016) +----------------------------------------------------------- + +.. contents:: Table of Contents + :local: + +Background +^^^^^^^^^^ + +As explained in a `design article `__, +we are engaged in the development of a new major version of ROS, called "ROS 2." +While the underlying concepts (e.g., publish / subscribe messaging) and goals +(e.g., flexibility and reusability) are the same as for ROS 1, we are taking this +opportunity to make substantial changes to the system, including changing +some of the core APIs. +For a deeper treatment of those changes and their rationale, consult the other +`ROS 2 design articles `__. + +Status +^^^^^^ + +On February 17, 2016, we are releasing ROS 2 alpha4, +code-named **Duct tape**. +Our primary goal with this release is to add more features, while also addressing the feedback we received for the previous releases. +To that end, we built a set of `demos <../../Tutorials>` that +show some of the key features of ROS 2. +We encourage you to try out those +demos, look at the code that implements them, and `provide +feedback <../../Contact>`. +We're especially interested to know how well (or +poorly) we're addressing use cases that are important to you. + +Intended audience +^^^^^^^^^^^^^^^^^ + +While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. +At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from +complete. +You should not expect to switch from ROS 1 to ROS 2, nor should +you expect to build a new robot control system with ROS 2. +Rather, you +should expect to try out some demos, explore the code, and perhaps write +your own demos. + +The major features included in this release are: + + +* Improved type support infrastructure, including support for C +* Preliminary Python client library, only publishers and subscriptions are supported. Beware, the API is subject to change and is far from complete! +* Added structures for ROS time in C API (still needs C++ API) + + * New concept of extensible "time sources" for ROS Time, the default time source will be like ROS 1 (implementation pending) + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha3 release (code name *Cement*; December 2015) +---------------------------------------------------------- + +.. contents:: Table of Contents + :local: + + +Background +^^^^^^^^^^ + +As explained in a `design article `__, +we are engaged in the development of a new major version of ROS, called "ROS 2." +While the underlying concepts (e.g., publish / subscribe messaging) and goals +(e.g., flexibility and reusability) are the same as for ROS 1, we are taking this +opportunity to make substantial changes to the system, including changing +some of the core APIs. +For a deeper treatment of those changes and their rationale, consult the other +`ROS 2 design articles `__. + +Status +^^^^^^ + +On December 18, 2015, we are releasing ROS 2 alpha3, +code-named **Cement**. +Our primary goal with this release is to add more features, while also addressing the feedback we received for the previous releases. +To that end, we built a set of `demos <../../Tutorials>` that +show some of the key features of ROS 2. +We encourage you to try out those +demos, look at the code that implements them, and `provide +feedback <../../Contact>`. +We're especially interested to know how well (or +poorly) we're addressing use cases that are important to you. + +Intended audience +^^^^^^^^^^^^^^^^^ + +While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. +At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from +complete. +You should not expect to switch from ROS 1 to ROS 2, nor should +you expect to build a new robot control system with ROS 2. +Rather, you +should expect to try out some demos, explore the code, and perhaps write +your own demos. + +The major features included in this release are: + + +* Updated ``rcl`` interface. + + * This interface will be wrapped in order to create language bindings, e.g. ``rclpy``. + * This interface has improved documentation and test coverage over existing interfaces we currently have, e.g. ``rmw`` and ``rclcpp``. + * See `rcl headers `__. + +* Added support in rclcpp for using the TLSF (two-level segregate fit) allocator, a memory allocator design for embedded and real-time systems. +* Improved efficiency of MultiThreadedExecutor and fixed numerous bugs with multi-threaded execution, which is now test on CI. +* Added ability to cancel an Executor from within a callback called in spin. +* Added ability for a timer to cancel itself by supporting a Timer callback that accepts a reference to itself as a function parameter. +* Added checks for disallowing multiple threads to enter Executor::spin. +* Improved reliability of numerous tests that had been sporadically failing. +* Added support for using Fast RTPS (instead of, e.g., OpenSplice or Connext). +* A partial port of tf2 including the core libraries and core command line tools. + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha2 release (code name *Baling wire*; October 2015) +-------------------------------------------------------------- + +.. contents:: Table of Contents + :local: + +Background +^^^^^^^^^^ + +As explained in a `design +article `__, we are engaged in +the development of a new major version of ROS, called "ROS 2." While the +underlying concepts (e.g., publish / subscribe messaging) and goals (e.g., +flexibility and reusability) are the same as for ROS 1, we are taking this +opportunity to make substantial changes to the system, including changing +some of the core APIs. +For a deeper treatment of those changes and their +rationale, consult the other `ROS 2 design +articles `__. + + +Status +^^^^^^ + +On November 3, 2015, we are releasing ROS 2 alpha2, +code-named **Baling wire**. +Our primary goal with this release is to add more features, while also addressing the feedback we received for the previous alpha 1 release. +To that end, we built a set of `demos <../../Tutorials>` that +show some of the key features of ROS 2. +We encourage you to try out those +demos, look at the code that implements them, and `provide +feedback <../../Contact>`. +We're especially interested to know how well (or +poorly) we're addressing use cases that are important to you. + + +Intended audience +^^^^^^^^^^^^^^^^^ + +While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. +At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. + + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from +complete. +You should not expect to switch from ROS 1 to ROS 2, nor should +you expect to build a new robot control system with ROS 2. +Rather, you +should expect to try out some demos, explore the code, and perhaps write +your own demos. + +The major features included in this release are: + + +* Support for custom allocators in rclcpp, useful for real-time messaging +* Feature parity of Windows with Linux/OSX, including workspace management, services and parameters +* rclcpp API improvements +* FreeRTPS improvements + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. + +ROS 2 alpha1 release (code name *Anchor*; August 2015) +-------------------------------------------------------- + +.. contents:: Table of Contents + :local: + +Background +^^^^^^^^^^ + +As explained in a `design +article `__, we are engaged in +the development of a new major version of ROS, called "ROS 2." While the +underlying concepts (e.g., publish / subscribe messaging) and goals (e.g., +flexibility and reusability) are the same as for ROS 1, we are taking this +opportunity to make substantial changes to the system, including changing +some of the core APIs. +For a deeper treatment of those changes and their +rationale, consult the other `ROS 2 design +articles `__. + + +Status +^^^^^^ + +On August 31, 2015, we are releasing ROS 2 alpha1, +code-named **Anchor**. +Our primary goal with this release is to give +you the opportunity to understand how ROS 2 works, in particular how it +differs from ROS 1. +To that end, we built a set of `demos <../../Tutorials>` that +show some of the key features of ROS 2. +We encourage you to try out those +demos, look at the code that implements them, and `provide +feedback <../../Contact>`. +We're especially interested to know how well (or +poorly) we're addressing use cases that are important to you. + + +Intended audience +^^^^^^^^^^^^^^^^^ + +While everyone is welcome to try out the demos and look through the code, we're aiming this release at people who are already experienced with ROS 1 development. +At this point, the ROS 2 documentation is pretty sparse and much of the system is explained by way of how it compares to ROS 1. + + +Scope +^^^^^ + +As the "alpha" qualifier suggests, this release of ROS 2 is far from +complete. +You should not expect to switch from ROS 1 to ROS 2, nor should +you expect to build a new robot control system with ROS 2. +Rather, you +should expect to try out some demos, explore the code, and perhaps write +your own demos. + +The major features included in this release are: + + +* Discovery, transport, and serialization `use DDS `__ +* Support `multiple DDS vendors `__ +* Support messaging primitives: topics (publish / subscribe), services (request / response), and parameters +* Support Linux (Ubuntu Trusty), OS X (Yosemite) and Windows (8) +* `Use quality-of-service settings to handle lossy networks <../Tutorials/Demos/Quality-of-Service>` +* `Communicate inter-process or intra-process with the same API <../Tutorials/Demos/Intra-Process-Communication>` +* `Write real-time safe code that uses the ROS 2 APIs <../Tutorials/Demos/Real-Time-Programming>` +* `Run ROS 2 on "bare-metal" microcontrollers (no operating system) `__ +* `Bridge communication between ROS 1 and ROS 2 `__ + +Pretty much anything not listed above is not included in this release. +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. \ No newline at end of file diff --git a/source/Get-Started/Releases/Beta1-Overview.rst b/source/Get-Started/Releases/Beta1-Overview.rst index 058f80c167b..1605726deb9 100644 --- a/source/Get-Started/Releases/Beta1-Overview.rst +++ b/source/Get-Started/Releases/Beta1-Overview.rst @@ -1,65 +1,66 @@ -.. redirect-from:: - - Beta1-Overview - -Beta 1 (``Asphalt``) -==================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Supported Platforms -------------------- - -We support ROS 2 Beta 1 on three platforms: Ubuntu 16.04 (Xenial), Mac OS X 10.11 (El Capitan), and Windows 8.1 and 10. We provide both binary packages and instructions for how to compile from source for all 3 platforms. - -Features --------- - -Improvements since Alpha 8 release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support for node composition at compile, link, or runtime. -* A standard lifecycle for managed nodes. -* Improved support for Quality of Service tuning and tests. -* `New and updated design documents `__ -* More `tutorials <../../Tutorials>` and `examples `__ -* Bridging services to / from ROS 1 (in addition to topics) - -Selected features from previous Alpha releases -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For the complete list, see `earlier release notes <../index>`. - - -* C++ and Python implementations of ROS 2 client libraries including APIs for: - - * Publishing and subscribing to ROS topics - * Requesting and replying ROS services (synchronous (C++ only) and asynchronous) - * Getting and setting ROS parameters (C++ only, synchronous and asynchronous) - * Timer callbacks - * Support for interoperability between multiple DDS/RTPS implementations - * eProsima Fast RTPS is our default implementation, and is included in the binary packages - * RTI Connext is supported: build from source to try it out - * We initially supported PrismTech OpenSplice but eventually decided to drop it - -* A graph API for network events -* Distributed discovery -* Realtime safe code paths for publish and subscribe with compatible DDS implementation (only Connext at the moment) - - * Support for custom allocators - -* ROS 1 <-> ROS 2 dynamic bridge node -* Executor threading model in C++ -* Extended ``.msg`` format with new features: - - * Bounded arrays - * Default values - -Known issues -^^^^^^^^^^^^ - -* We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker `__ -* We'd like to highlight a `known issue `__ that we are working with eProsima to fix that results in significantly degrated performance for large messages under FastRTPS. - This will be observed when running some of the demos with larger image resolutions. +.. redirect-from:: + + Beta1-Overview + Releases/Beta1-Overview + +Beta 1 (``Asphalt``) +==================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Supported Platforms +------------------- + +We support ROS 2 Beta 1 on three platforms: Ubuntu 16.04 (Xenial), Mac OS X 10.11 (El Capitan), and Windows 8.1 and 10. We provide both binary packages and instructions for how to compile from source for all 3 platforms. + +Features +-------- + +Improvements since Alpha 8 release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support for node composition at compile, link, or runtime. +* A standard lifecycle for managed nodes. +* Improved support for Quality of Service tuning and tests. +* `New and updated design documents `__ +* More `tutorials <../../Tutorials>` and `examples `__ +* Bridging services to / from ROS 1 (in addition to topics) + +Selected features from previous Alpha releases +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For the complete list, see `earlier release notes <../index>`. + + +* C++ and Python implementations of ROS 2 client libraries including APIs for: + + * Publishing and subscribing to ROS topics + * Requesting and replying ROS services (synchronous (C++ only) and asynchronous) + * Getting and setting ROS parameters (C++ only, synchronous and asynchronous) + * Timer callbacks + * Support for interoperability between multiple DDS/RTPS implementations + * eProsima Fast RTPS is our default implementation, and is included in the binary packages + * RTI Connext is supported: build from source to try it out + * We initially supported PrismTech OpenSplice but eventually decided to drop it + +* A graph API for network events +* Distributed discovery +* Realtime safe code paths for publish and subscribe with compatible DDS implementation (only Connext at the moment) + + * Support for custom allocators + +* ROS 1 <-> ROS 2 dynamic bridge node +* Executor threading model in C++ +* Extended ``.msg`` format with new features: + + * Bounded arrays + * Default values + +Known issues +^^^^^^^^^^^^ + +* We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker `__ +* We'd like to highlight a `known issue `__ that we are working with eProsima to fix that results in significantly degrated performance for large messages under FastRTPS. + This will be observed when running some of the demos with larger image resolutions. \ No newline at end of file diff --git a/source/Get-Started/Releases/Beta2-Overview.rst b/source/Get-Started/Releases/Beta2-Overview.rst index 08835eaa423..3baba02f405 100644 --- a/source/Get-Started/Releases/Beta2-Overview.rst +++ b/source/Get-Started/Releases/Beta2-Overview.rst @@ -1,91 +1,92 @@ -.. redirect-from:: - - Beta2-Overview - -Beta 2 (``r2b2``) -================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -Supported Platforms -------------------- - -We support ROS 2 Beta 2 on three platforms: Ubuntu 16.04 (Xenial), macOS 10.12 (Sierra), and Windows 10. -We provide both binary packages and instructions for how to compile from source for all 3 platforms (see `install instructions <../../Installation>` as well as `documentation `__). - -Features --------- - -Improvements since Beta 1 release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* DDS_Security support (aka SROS2, see `sros2 `__) -* Debian packages for Ubuntu Xenial -* Typesupport has been redesigned so that you only build a single executable and can choose one of the available RMW implementations by setting an environment variable (see `documentation <../../How-To-Guides/Working-with-multiple-RMW-implementations>`). -* Namespace support for nodes and topics (see `design article `__, see known issues below). -* A set of command-line tools using the extensible ``ros2`` command (see `conceptual article <../../Concepts/Basic/About-Command-Line-Tools>`). -* A set of macros for logging messages in C / C++ (see API docs of `rcutils `__). - -New demo application -^^^^^^^^^^^^^^^^^^^^ - -* `Turtlebot 2 demos `__ using the following repositories that have been (partially) converted to ROS 2 (Linux only): - - * `ros_astra_camera `__ - * `depthimage_to_laserscan `__ - * `pcl_conversions `__ - * `cartographer `__ - * `cartographer_ros `__ - * `ceres-solver `__ - * `navigation `__ - * `teleop_twist_keyboard `__ - * `joystick_drivers `__ - * `teleop_twist_joy `__ - -* `Dummy_robot demo <../Tutorials/Demos/dummy-robot-demo>`: - - * `robot_model `__ - * `robot_state_publisher `__ - -Selected features from previous Alpha/Beta releases -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For the complete list, see `earlier release notes <../index>`. - - -* C++ and Python implementations of ROS 2 client libraries including APIs for: - - * Publishing and subscribing to ROS topics - * Requesting and replying ROS services (synchronous (C++ only) and asynchronous) - * Getting and setting ROS parameters (C++ only, synchronous and asynchronous) - * Timer callbacks - -* Support for interoperability between multiple DDS/RTPS implementations - - * eProsima Fast RTPS is our default implementation, and is included in the binary packages - * RTI Connext is supported: build from source to try it out - * We initially supported PrismTech OpenSplice but support for it is currently on hold - -* A graph API for network events -* Distributed discovery -* Realtime safe code paths for publish and subscribe with compatible DDS implementation (only Connext at the moment) - - * Support for custom allocators - -* ROS 1 <-> ROS 2 dynamic bridge node -* Executor threading model (C++ only) -* Component model to compose nodes at compile / link / runtime -* Managed component using a standard lifecycle -* Extended ``.msg`` format with new features: - - * Bounded arrays - * Default values - -Known issues -^^^^^^^^^^^^ - -* We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker `__ -* We'd like to highlight a `known issue `__ that we are looking into which doesn't allow two topics with the same base name but different namespaces to have a different type when using ``rmw_connext_cpp``. -* Services with long responses are not working with Fast-RTPS. The fix, while not being part of beta2, is available upstream so you can work around this issue by building from source using Fast-RTPS master branch. +.. redirect-from:: + + Beta2-Overview + Releases/Beta2-Overview + +Beta 2 (``r2b2``) +================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +Supported Platforms +------------------- + +We support ROS 2 Beta 2 on three platforms: Ubuntu 16.04 (Xenial), macOS 10.12 (Sierra), and Windows 10. +We provide both binary packages and instructions for how to compile from source for all 3 platforms (see `install instructions <../../Installation>` as well as `documentation `__). + +Features +-------- + +Improvements since Beta 1 release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* DDS_Security support (aka SROS2, see `sros2 `__) +* Debian packages for Ubuntu Xenial +* Typesupport has been redesigned so that you only build a single executable and can choose one of the available RMW implementations by setting an environment variable (see `documentation <../../How-To-Guides/Working-with-multiple-RMW-implementations>`). +* Namespace support for nodes and topics (see `design article `__, see known issues below). +* A set of command-line tools using the extensible ``ros2`` command (see `conceptual article <../../Concepts/Basic/About-Command-Line-Tools>`). +* A set of macros for logging messages in C / C++ (see API docs of `rcutils `__). + +New demo application +^^^^^^^^^^^^^^^^^^^^ + +* `Turtlebot 2 demos `__ using the following repositories that have been (partially) converted to ROS 2 (Linux only): + + * `ros_astra_camera `__ + * `depthimage_to_laserscan `__ + * `pcl_conversions `__ + * `cartographer `__ + * `cartographer_ros `__ + * `ceres-solver `__ + * `navigation `__ + * `teleop_twist_keyboard `__ + * `joystick_drivers `__ + * `teleop_twist_joy `__ + +* `Dummy_robot demo <../Tutorials/Demos/dummy-robot-demo>`: + + * `robot_model `__ + * `robot_state_publisher `__ + +Selected features from previous Alpha/Beta releases +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For the complete list, see `earlier release notes <../index>`. + + +* C++ and Python implementations of ROS 2 client libraries including APIs for: + + * Publishing and subscribing to ROS topics + * Requesting and replying ROS services (synchronous (C++ only) and asynchronous) + * Getting and setting ROS parameters (C++ only, synchronous and asynchronous) + * Timer callbacks + +* Support for interoperability between multiple DDS/RTPS implementations + + * eProsima Fast RTPS is our default implementation, and is included in the binary packages + * RTI Connext is supported: build from source to try it out + * We initially supported PrismTech OpenSplice but support for it is currently on hold + +* A graph API for network events +* Distributed discovery +* Realtime safe code paths for publish and subscribe with compatible DDS implementation (only Connext at the moment) + + * Support for custom allocators + +* ROS 1 <-> ROS 2 dynamic bridge node +* Executor threading model (C++ only) +* Component model to compose nodes at compile / link / runtime +* Managed component using a standard lifecycle +* Extended ``.msg`` format with new features: + + * Bounded arrays + * Default values + +Known issues +^^^^^^^^^^^^ + +* We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker `__ +* We'd like to highlight a `known issue `__ that we are looking into which doesn't allow two topics with the same base name but different namespaces to have a different type when using ``rmw_connext_cpp``. +* Services with long responses are not working with Fast-RTPS. The fix, while not being part of beta2, is available upstream so you can work around this issue by building from source using Fast-RTPS master branch. \ No newline at end of file diff --git a/source/Get-Started/Releases/Beta3-Overview.rst b/source/Get-Started/Releases/Beta3-Overview.rst index d5b22b6ee5c..eccffa6db0e 100644 --- a/source/Get-Started/Releases/Beta3-Overview.rst +++ b/source/Get-Started/Releases/Beta3-Overview.rst @@ -1,79 +1,80 @@ -.. redirect-from:: - - Beta3-Overview - -Beta 3 (``r2b3``) -================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -Supported Platforms -------------------- - -We support ROS 2 Beta 3 on three platforms: Ubuntu 16.04 (Xenial), macOS 10.12 (Sierra), and Windows 10. -We provide both binary packages and instructions for how to compile from source for all 3 platforms (see `install instructions <../../Installation>` as well as `documentation `__). - -Features --------- - -Improvements since Beta 2 release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Execution model in Python, many fixes to memory management in Python C extension -* Experimental rewrite of `ros_control `__ -* Exposure of DDS implementation-specific symbols to users (for Fast RTPS and Connext) (see `example `__) -* Logging `API `__ in Python -* Fixed several memory leaks and race conditions in various packages -* Readded support for OpenSplice (on Linux and Windows atm) provided by PrismTech -* Use bloom (without patches) to make ROS 2 releases - -New demo application -^^^^^^^^^^^^^^^^^^^^ - -* `HSR demo `__ - - * Remote control a HSR robot using a ROS 2 joystick controller - * Running the ``ros1_bridge`` in a Docker container on the HSR (since the robot is running ROS 1 on Ubuntu Trusty) - * Run a ROS 2 development version of `rviz `__ to visualize sensor data from the robot etc. (see `video `__) - -Selected features from previous Alpha/Beta releases -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For the complete list, see `earlier release notes <../index>`. - -* C++ and Python implementations of ROS 2 client libraries including APIs for: - - * Publishing and subscribing to ROS topics - * Requesting and replying ROS services (synchronous (C++ only) and asynchronous) - * Getting and setting ROS parameters (C++ only, synchronous and asynchronous) - * Timer callbacks - -* Support for interoperability between multiple DDS/RTPS implementations - - * eProsima Fast RTPS is our default implementation, and is included in the binary packages - * RTI Connext is supported: build from source to try it out - * PrismTech OpenSplice: see limitations below - -* A graph API for network events -* Distributed discovery -* Realtime safe code paths for publish and subscribe with compatible DDS implementation (only Connext at the moment) - - * Support for custom allocators - -* ROS 1 <-> ROS 2 dynamic bridge node -* Executor threading model (C++ and Python) -* Component model to compose nodes at compile / link / runtime -* Managed component using a standard lifecycle -* Extended ``.msg`` format with new features: - - * Bounded arrays - * Default values - -Known issues ------------- - -* On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. -* OpenSplice support is currently not available for MacOS. Also `access to native handles `__ is not yet implemented. -* Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). +.. redirect-from:: + + Beta3-Overview + Releases/Beta3-Overview + +Beta 3 (``r2b3``) +================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +Supported Platforms +------------------- + +We support ROS 2 Beta 3 on three platforms: Ubuntu 16.04 (Xenial), macOS 10.12 (Sierra), and Windows 10. +We provide both binary packages and instructions for how to compile from source for all 3 platforms (see `install instructions <../../Installation>` as well as `documentation `__). + +Features +-------- + +Improvements since Beta 2 release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Execution model in Python, many fixes to memory management in Python C extension +* Experimental rewrite of `ros_control `__ +* Exposure of DDS implementation-specific symbols to users (for Fast RTPS and Connext) (see `example `__) +* Logging `API `__ in Python +* Fixed several memory leaks and race conditions in various packages +* Readded support for OpenSplice (on Linux and Windows atm) provided by PrismTech +* Use bloom (without patches) to make ROS 2 releases + +New demo application +^^^^^^^^^^^^^^^^^^^^ + +* `HSR demo `__ + + * Remote control a HSR robot using a ROS 2 joystick controller + * Running the ``ros1_bridge`` in a Docker container on the HSR (since the robot is running ROS 1 on Ubuntu Trusty) + * Run a ROS 2 development version of `rviz `__ to visualize sensor data from the robot etc. (see `video `__) + +Selected features from previous Alpha/Beta releases +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For the complete list, see `earlier release notes <../index>`. + +* C++ and Python implementations of ROS 2 client libraries including APIs for: + + * Publishing and subscribing to ROS topics + * Requesting and replying ROS services (synchronous (C++ only) and asynchronous) + * Getting and setting ROS parameters (C++ only, synchronous and asynchronous) + * Timer callbacks + +* Support for interoperability between multiple DDS/RTPS implementations + + * eProsima Fast RTPS is our default implementation, and is included in the binary packages + * RTI Connext is supported: build from source to try it out + * PrismTech OpenSplice: see limitations below + +* A graph API for network events +* Distributed discovery +* Realtime safe code paths for publish and subscribe with compatible DDS implementation (only Connext at the moment) + + * Support for custom allocators + +* ROS 1 <-> ROS 2 dynamic bridge node +* Executor threading model (C++ and Python) +* Component model to compose nodes at compile / link / runtime +* Managed component using a standard lifecycle +* Extended ``.msg`` format with new features: + + * Bounded arrays + * Default values + +Known issues +------------ + +* On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. +* OpenSplice support is currently not available for MacOS. Also `access to native handles `__ is not yet implemented. +* Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). \ No newline at end of file diff --git a/source/Get-Started/Releases/Development.rst b/source/Get-Started/Releases/Development.rst index a1dfe5faf5a..31058df7f35 100644 --- a/source/Get-Started/Releases/Development.rst +++ b/source/Get-Started/Releases/Development.rst @@ -1,9 +1,13 @@ -Development Distribution -======================== - -Below is the ROS 2 distribution that is currently in development. - -.. toctree:: - :maxdepth: 1 - - Release-Lyrical-Luth +.. redirect-from:: + + Releases/Development + +Development Distribution +======================== + +Below is the ROS 2 distribution that is currently in development. + +.. toctree:: + :maxdepth: 1 + + Release-Lyrical-Luth \ No newline at end of file diff --git a/source/Get-Started/Releases/End-of-Life.rst b/source/Get-Started/Releases/End-of-Life.rst index 2e1304c1c8b..52bc864f98e 100644 --- a/source/Get-Started/Releases/End-of-Life.rst +++ b/source/Get-Started/Releases/End-of-Life.rst @@ -1,20 +1,24 @@ -End-of-Life Distributions -========================= - -Below is a list of historic ROS 2 distributions that are no longer supported. - -.. toctree:: - :maxdepth: 1 - - Release-Iron-Irwini - Release-Galactic-Geochelone - Release-Foxy-Fitzroy - Release-Eloquent-Elusor - Release-Dashing-Diademata - Release-Crystal-Clemmys - Release-Bouncy-Bolson - Release-Ardent-Apalone - Beta3-Overview - Beta2-Overview - Beta1-Overview - Alpha-Overview +.. redirect-from:: + + Releases/End-of-Life + +End-of-Life Distributions +========================= + +Below is a list of historic ROS 2 distributions that are no longer supported. + +.. toctree:: + :maxdepth: 1 + + Release-Iron-Irwini + Release-Galactic-Geochelone + Release-Foxy-Fitzroy + Release-Eloquent-Elusor + Release-Dashing-Diademata + Release-Crystal-Clemmys + Release-Bouncy-Bolson + Release-Ardent-Apalone + Beta3-Overview + Beta2-Overview + Beta1-Overview + Alpha-Overview \ No newline at end of file diff --git a/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst b/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst index 0b61f7670e8..44d4bb1ada2 100644 --- a/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst @@ -1,5135 +1,5139 @@ -Galactic Geochelone changelog -============================= - -This page is a list of the complete changes in all ROS 2 core packages since the previous release. - -.. contents:: Table of Contents - :local: - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#122 `__) -* Updating Quality Declaration (`#120 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update logging macros (`#476 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Update goal response callback signature (`#463 `__) -* Contributors: Audrow Nash, Jacob Perron, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#502 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Ivan Santiago Paunovic, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`actionlib_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#132 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Add clang-format-version option to ament_clang_format (`#282 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan, Tyler Weaver - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Add multiprocessing support to ament_clang_tidy (`#288 `__) * add multiprocessing support * fix stylistic lint issues -* Add --packages-select argument to ament_clang_tidy (`#287 `__) Add comment explaining handling quoted list of space separated package names Update documentation for ament_clang_tidy -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, M. Mei, Tyler Weaver - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* add TIMEOUT argument to ament_cmake_clang_tidy (`#298 `__) -* Add Audrow as a maintainer (`#294 `__) -* Fix documentation for ament_cmake_clang_tidy (`#285 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, M. Mei, Tyler Weaver - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* increase default timeout for CMake copyright linter to 120s (`#261 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Merge pull request `#287 `__ from ament/mjeronimo/add-condition-support * Check condition attr in package.xml dependencies The condition attribute was already parsed when reading the XML file. Just needed to check the condition when adding dependencies to the list for a particular key/target. Fixes `#266 `__ * Address Dirk's code review feedback -* Address Dirk's code review feedback -* Check condition attr in package.xml dependencies The condition attribute was already parsed when reading the XML file. Just needed to check the condition when adding dependencies to the list for a particular key/target. Fixes `#266 `__ -* Update package maintainers. (`#286 `__) -* Contributors: Michael Jeronimo, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Increase the ament_cppcheck timeout to 5 minutes. (`#271 `__) This will avoid timeouts on some slower platforms that we've started to see. -* parse LANGUAGE argument case insensitive (`#255 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Karsten Knese, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_definitions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix cmake list(TRANSFORM ) is only available from version 3.12, (`#296 `__) convert to string instead -* fix imported targets with multiple configuration (`#290 `__) * fix imported targets with multiple configuration * taking into account DEBUG_CONFIGURATIONS global variable -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo, siposcsaba89 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix variable name in ament_export_libraries.cmake (`#314 `__) -* Update package maintainers. (`#286 `__) -* Contributors: Alejandro Hernández Cordero, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_link_flags `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_targets `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gmock `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_google_benchmark `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Serialize benchmarks within CTest by default (`#308 `__) -* Handle runtime failures in Google Benchmark (`#294 `__) This change will handle runtime failures in Google Benchmark by propagating error information from Google Benchmark to both CTest and the Jenkins benchmark plugin. -* Use consistent string format and resolve flake8 (`#295 `__) Follow-up to a5fb3112b5c46c42b1824c96af4171d469eb13bf -* Make ament_cmake_test a dep of ament_cmake_google_benchmark (`#293 `__) -* Catch JSONDecodeError and printout some debug info (`#291 `__) -* Update package maintainers. (`#286 `__) -* Make AMENT_RUN_PERFORMANCE_TESTS a CMake option (`#280 `__) -* Skip performance tests using a CMake variable (`#278 `__) These tests can be fairly heavy, so we don't want to run them by default. It would be better if there was a way to skip the tests by default in such a way that they could be specifically un-skipped at runtime, but I can't find a mechanism in CMake or CTest that would allow us to achieve that behavior without leveraging environment variables. -* Handle Google Benchmark 'aggregate' results (`#276 `__) Previously, I assumed all results generated by Google Benchmark were of 'iteration' type. Now that I have more experience with Google Benchmark, I've started generating aggregate results, which contain some different properties. This change adds support for aggregate results and should make it easy to add any other result schemas we encounter in the future. For forward-compatibility, unsupported types will generate a warning message but will not fail the test. This makes the conversion tolerant to Google Benchmark adding new measures for existing mechanisms. -* Initial Google Benchmark results conversion (`#275 `__) -* Handle missing results file for Google Benchmark (`#265 `__) -* Initial ament_cmake_google_benchmark package (`#261 `__) -* Contributors: Michel Hidalgo, Scott K Logan, brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gtest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable gtest warning when building in Release (`#298 `__) https://github.com/google/googletest/issues/1303 -* Update package maintainers. (`#286 `__) -* [ament_cmake_gtest] ensure gtest to consume the correct headers. (`#267 `__) * ensure gtest to consume the correct headers. * add another patch. -* Contributors: Michel Hidalgo, Sean Yen, Victor Lopez - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* ament_lint_cmake: default linelength in argumentparser for consistency (`#306 `__) -* 0.10.3 -* Fix ament_lint_cmake line length expression (`#236 `__) This regular expression is using the re.VERBOSE flag, meaning that characters after an un-escaped '#' character are interpreted as a comment and are not part of the expression. Also set the default maximum line length to 140 columns. -* Add Audrow as a maintainer (`#294 `__) -* Make CMake linter line length configurable (`#235 `__) Co-authored-by: Miaofei -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Emerson Knapp, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_nose `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix ament_get_pytest_cov_version for newer versions of pytest (`#315 `__) -* Update package maintainers. (`#286 `__) -* Contributors: Christophe Bedard, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Symlink setup.cfg and sources before building Python egg-info (`#327 `__) -* Simplify ament_python_install_package() macro. (`#326 `__) Do not delegate to setuptools, install egg-info manually. -* Escape $ENV{DESTDIR} everywhere in ament_python_install_package() (`#324 `__) Follow up after f80071e2216e766f7bf1b0792493a5f6523e9226 -* Use DESTDIR on ament_python_install_package() (`#323 `__) * Use DESTDIR on ament_python_install_package() -* Make ament_python_install_package() install a flat Python egg (`#316 `__) -* [ament_cmake_python] ament_cmake_python_get_python_install_dir public (`#300 `__) * [ament_cmake_python] make the ament_cmake_python_get_python_install_dir a public interface. -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo, Naveau - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#11 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_target_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Force SYSTEM keyword in ament_target_dependencies() at the start. (`#303 `__) -* Add SYSTEM keyword option to ament_target_dependencies (`#297 `__) * Add SYSTEM keyword option to ament_target_dependencies * Add documentation of SYSTEM keyword for ament_target_dependencies -* Update package maintainers. (`#286 `__) -* ordered interface include dirs and use privately to ensure workspace order (`#260 `__) -* Contributors: Andre Nguyen, Dirk Thomas, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Fix skipped test reporting in CTest (`#279 `__) This is a follow-up to c67cdf2. When the SKIP_RETURN_CODE gets set to 0, the value is interpreted as 'false', and the test property is never actually added. -* limit test time to three decimals (`#271 `__) -* Add actual test time to xUnit result files (`#270 `__) * Add actual test time to xUnit result files Fixes `#269 `__ * Report test_time even with skipped test * Set time attribute for testcase element -* Add SKIP_RETURN_CODE argument to ament_add_test (`#264 `__) This makes the ``run_test.py`` wrapper aware of the ``SKIP_RETURN_CODE`` property on CTest tests. In the existing implementation, the wrapper detects that no result file was generated and overrides the special return code coming from the test, making the the CTest feature fail completely. This change makes the wrapper script aware of the special return code, and when detected, will write a 'skipped' result file instead of a 'failed' result file, and pass along the special return code as-is. Now the gtest result and the ctest results both show the test as 'skipped' when the special return flag is used. Note that none of this behavior is enabled by default, which is important because we wouldn't want a test to fail and return a code which we've decided is the special 'skip' return code. Only tests which are aware of this feature should use it. -* Contributors: Dirk Thomas, Michel Hidalgo, Ruffin, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* parse LANGUAGE argument case insensitive (`#255 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Karsten Knese, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_version `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#286 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* Use non-blind except for open() (`#307 `__) -* Add optional file header style (`#304 `__) * Add optional file header style * Fix test on ament_copyright -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* add mit-0 as a valid license to ament_copyright (`#284 `__) -* Support Python 3.8-provided importlib.metadata (`#290 `__) The importlib_metadata package is a backport of the importlib.metadata module from Python 3.8. Fedora (and possibly others) no longer package importlib_metadata because they ship Python versions which have the functionality built-in. -* Update maintainer (`#274 `__) * update maintainer * add authors -* added bsd 2 clause simplified license to ament_copyright (`#267 `__) * added bsd 2 clause simplified license to ament_copyright -* Remove use of pkg_resources from ament_lint. (`#260 `__) Replace it with the use of the more modern importlib_metadata library. There are a couple of reasons to do this: 1. pkg_resources is quite slow to import; on my machine, just firing up the python interpreter takes ~35ms, while firing up the python interpreter and importing pkg_resources takes ~175ms. Firing up the python interpreter and importing importlib_metadata takes ~70ms. Removing 100ms per invocation of the command-line both makes it speedier for users, and will speed up our tests (which call out to the command-line quite a lot). 2. pkg_resources is somewhat deprecated and being replaced by importlib. https://importlib-metadata.readthedocs.io/en/latest/using.html describes some of it Note: By itself, this change is not enough to completely remove our dependence on pkg_resources. We'll also have to do something about the console_scripts that setup.py generates. That will be a separate effort. -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Alfi Maulana, Audrow Nash, Chris Lalancette, Christophe Bedard, Claire Wang, Evan Flynn, M. Mei, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Fix file exclusion behavior in ament_cppcheck and ament_cpplint (`#299 `__) * fix exclude behavior in ament_cppcheck and ament_cpplint * fix flake8 errors * add missing realpath() conversion -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Suppress unknownMacro (`#268 `__) cppcheck creates an unknownMacro error when it cannot resolve a macro. Since we don't pass in all dependent headers, we don't expect all macros to be discoverable by cppcheck. -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Dan Rose, M. Mei, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Fix file exclusion behavior in ament_cppcheck and ament_cpplint (`#299 `__) * fix exclude behavior in ament_cppcheck and ament_cpplint * fix flake8 errors * add missing realpath() conversion -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, M. Mei, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as the maintainer. (`#71 `__) -* Change links from index.ros.org -> docs.ros.org (`#70 `__) -* Add Audrow as a maintainer (`#68 `__) -* update maintainers (`#67 `__) -* Update QD to Quality Level 1 (`#66 `__) -* add rational why ament_index pkgs don't have explicit performance tests (`#65 `__) -* Fixed Doxygen warnings (`#63 `__) -* Remove the Quality Level from the README.md. (`#62 `__) -* Update QD ament_index_cpp to QL 2 (`#59 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#57 `__) -* [Quality Declaration] Update Version Stability to stable version (`#58 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as the maintainer. (`#71 `__) -* Change links from index.ros.org -> docs.ros.org (`#70 `__) -* Add Audrow as a maintainer (`#68 `__) -* update maintainers (`#67 `__) -* add rational why ament_index pkgs don't have explicit performance tests (`#65 `__) -* Remove the Quality Level from the README.md. (`#62 `__) -* Fix document link (`#61 `__) -* [Quality Declaration] Update Version Stability to stable version (`#58 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, Matthijs van der Burgh - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Use correct lint package dependencies (`#278 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Esteve Fernandez, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* ament_lint_cmake: default linelength in argumentparser for consistency (`#306 `__) -* 0.10.3 -* Fix ament_lint_cmake line length expression (`#236 `__) This regular expression is using the re.VERBOSE flag, meaning that characters after an un-escaped '#' character are interpreted as a comment and are not part of the expression. Also set the default maximum line length to 140 columns. -* Add Audrow as a maintainer (`#294 `__) -* Make CMake linter line length configurable (`#235 `__) Co-authored-by: Miaofei -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Emerson Knapp, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Generate Setuptools Dict Helper Method (`#126 `__)" (`#131 `__) -* Generate Setuptools Dict Helper Method (`#126 `__) -* Add Audrow as a maintainer (`#127 `__) -* Support Python 3.8-provided importlib.metadata (`#124 `__) -* Declare missing dependency on python3-importlib-resources (`#123 `__) -* make AMENT_TRACE_SETUP_FILES output sourceable (`#120 `__) -* update maintainers -* Switch ament_package to using importlib. (`#118 `__) -* Add pytest.ini so local tests don't display warning (`#117 `__) -* add configure-time flag to skip parent_prefix_path (`#115 `__) -* Contributors: Audrow Nash, Chris Lalancette, David V. Lu!!, Dirk Thomas, Mabel Zhang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Add pytest marks to ament_pclint tests. (`#202 `__) * Add pytest marks to ament_pclint tests. * fix failed tests Co-authored-by: Miaofei -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan, Steven! Ragnarök - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* remove use of "extend" action in argparse (`#262 `__) -* Expand ignores to pep257 definition. (`#241 `__) * Expand ignores to pep257 definition. (ament `#240 `__) * add '--allow-undocumented' flag to enforce pep257 * restore existing default error codes to check * fix no-ignores logic * expose options from pydocstyle * allow user to explicitly set convention to "ament" * fix typo in populating argv for pydocstyle * reformat ament convention list * Add help info for ament convention -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* remove match args to allow pydocstyle defaults (`#243 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan, Ted Kern - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Allow 'C++' as language, but convert it to 'CPP' (`#302 `__) -* Allow correct languages on uncrustify (`#272 `__) * Allow correct languages on uncrustify. * Update dictionary. -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Miguel Company, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. -* 0.10.3 -* Add Audrow as a maintainer (`#294 `__) -* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 -* Update maintainer (`#274 `__) * update maintainer * add authors -* Add pytest.ini so local tests don't display warning. (`#259 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`builtin_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#122 `__) -* Updating Quality Declaration (`#120 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Document that Time and Duration are explictly ROS Time (`#103 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, Tully Foote, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_calibration_parsers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix formatting and include paths for linters (`#157 `__) -* ROS2 Using the filesystem helper in rcpputils (`#133 `__) -* [Windows][ros2] Avoid build break for Visual Studio 2019 v16.3 (`#135 `__) -* Camera Calibration Parsers ROS2 Port (`#105 `__) -* Image Transport ROS2 port (`#84 `__) -* Use Boost_LIBRARIES instead of Boost_PYTHON_LIBRARY This was causing issues when building with python3 since then ``Boost_PYTHON_LIBRARY`` is not set, instead cmake sets ``Boost_PYTHON3_LIBRARY``. So instead of adding each library separately, using ``Boost_LIBRARIES`` seems to be better. For reference, from the cmake docs: ``` Boost_LIBRARIES - Boost component libraries to be linked Boost\__LIBRARY - Libraries to link for component ``` -* Properly detect Boost Python 2 or 3 This fixes `#59 `__ -* 1.11.11 -* update changelogs -* Add install target for python wrapper library -* Only link against needed Boost libraries 9829b02 introduced a python dependency into find_package(Boost..) which results in ${Boost_LIBRARIES} containing boost_python and such a dependency to libpython at link time. With this patch we only link against the needed libraries. -* Add python wrapper for readCalibration. Reads .ini or .yaml calibration file and returns camera name and sensor_msgs/cameraInfo. -* Use $catkin_EXPORTED_TARGETS -* Remove no-longer-neccessary flags to allow OS X to use 0.3 and 0.5 of yaml-cpp. -* remove buggy CMake message -* fix `#39 `__ -* make sure test does not fail -* [camera_calibration_parsers] Better error message when calib file can't be written -* add rosbash as a test dependency -* add a test dependency now that we have tests -* parse distortion of arbitraty length in INI This fixes `#33 `__ -* add a test to parse INI calibration files with 5 or 8 D param -* Add yaml-cpp case for building on Android -* Fix catkin_make failure (due to yaml-cpp deps) for mac os -* fix bad yaml-cpp usage in certain conditions fixes `#24 `__ -* add a dependency on pkg-config to have it work on Indigo -* fix YAML CPP 0.5.x compatibility -* Contributors: Andreas Klintberg, Gary Servin, Helen Oleynikova, Isaac IY Saito, Jochen Sprickerhof, Kartik Mohta, Markus Roth, Martin Idel, Michael Carroll, Sean Yen, Vincent Rabaud, Yifei Zhang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_info_manager `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix formatting and include paths for linters (`#157 `__) -* Enable Windows build. (`#159 `__) -* Fix abort criteria for setCameraInfoService callback (`#132 `__) -* camera_info_manager ROS2 port (`#94 `__) -* Image Transport ROS2 port (`#84 `__) -* Fix the find_package(catkin) redundancy -* Add a dependency between the test and the test executable -* Add camera_calibration_parsers dependency to camera_info_manager -* 1.11.11 -* update changelogs -* Return empty CameraInfo when !ros::ok() -* Return empty CameraInfo when !ros::ok() -* fix compilation on Fedora, fixes `#42 `__ -* simplify target_link_libraries That should fix `#35 `__ -* Add public member function to manually set camera info (`#19 `__) -* make rostest in CMakeLists optional (`ros/rosdistro#3010 `__) -* check for CATKIN_ENABLE_TESTING -* add Jack as maintainer -* add gtest libraries linkage -* fix the rostest dependency -* fix catkin gtest and rostest problem -* fix unit test dependencies -* Removed duplicated test dependancy Test dependencies should never duplicate build or run dependencies. -* fix the urls -* Updated package.xml file(s) to handle new catkin buildtool_depend requirement -* remove the brief attribute -* fix bad folder/libraries -* add missing rostest dependency -* fix bad dependency -* fix dependencies -* add catkin as a dependency -* comply to the catkin API -* add missing linkage -* install the include directories -* fix build issues -* make the libraries public -* API documentation review update -* suppress misleading camera_info_manager error messages [#5273] -* remove deprecated global CameraInfoManager symbol for Fuerte (#4971) -* Revert to using boost::mutex, not boost::recursive_mutex. -* Hack saveCalibrationFile() to stat() the containing directory and attempt to create it if necessary. Test for this case. -* Reload camera info when camera name changes. -* Implement most new Electric API changes, with test cases. -* Add ${ROS_HOME} expansion, with unit test cases. Do not use "$$" for a single '$', look for "${" instead. -* Use case-insensitive comparisons for parsing URL tags (#4761). Add unit test cases to cover this. Add unit test case for camera name containing video mode. -* add test for resolving an empty URL -* Deprecate use of global CameraInfoManager symbol in E-turtle (#4786). Modify unit tests accordingly. -* provide camera_info_manager namespace, fixes #4760 -* Add support for "package://" URLs. -* Fixed tests to work with new CameraInfo. -* Moved image_common from camera_drivers. -* Contributors: Aaron Blasdel, Enrique Fernandez, Jack O'Quin, Jonathan Bohren, Joseph Schornak, Lukas Bulwahn, Martin Idel, Max Schettler, Michael Carroll, Sean Yen, Vincent Rabaud, blaise, mihelich, mirzashah - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`class_loader `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove travis. (`#182 `__) -* Change index.ros.org -> docs.ros.org. (`#181 `__) -* Fix ternary null check found by clang static analysis (`#176 `__) -* Update QD to QL 1 (`#177 `__) -* Updated console_bridge QL in QD -* Update package maintainers. (`#169 `__) -* enable building a static library (`#163 `__) -* Update Quality Declaration to reflect QL 2 (`#160 `__). -* Increase coverage with a graveyard behavior test and unmanaged instance test (`#159 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#157 `__) -* Clean up and improve documentation (`#156 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Michel Hidalgo, Stephen Brawner, ahcorde, brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`common_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#132 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix leak(`#480 `__) (`#481 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo, y-okumura-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#122 `__) -* Updating Quality Declaration (`#120 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`cyclonedds `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* DATA_AVAILABLE was not always triggered when by a dispose and sometimes triggered in the absence of an observable state change (arrival of a dispose for an already-disposed instance where the dispose had not yet been read); -* Restores functionality of the "raw ethernet" mode as well as IPv6 with link-local addresses, both accidentally broken in 0.6.0; -* Fixes a crash in processing endpoint discovery data containing unrecognised locator kinds; -* Fixes type conversion for local historical data (e.g., mixed use of ROS 2 C/C++ type supports in combination with transient-local endpoints within a single process); -* Fixes a use-after-free of "lease" objects with manual-by-topic writers; -* Mark instance as "alive" in the reader history and generate an invalid sample to notify the application even if the sample itself is dropped because the same or a later one is present already (e.g., on reconnecting to a transient-local writer); -* Fix a crash when doing an instance lookup on a built-in topic using the key value; -* No longer auto-dispose instances as soon as some registered writer disappears, instead do it only when all of them have unregistered it; -* Fix performance of read_instance and take_instance by performing a proper instance lookup. - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix small print issue in allocator tutorial. (`#509 `__) (`#512 `__) -* Small fixes for even_parameters_node. (`#500 `__) -* change ParameterEventHandler to take events as const ref instead of shared pointer (`#494 `__) -* Fix integer type in RCLCPP\_* macro printf. (`#492 `__) -* Add a demo for the new ParameterEventHandler class (`#486 `__) -* Filter qos overrides in paramter events demos (`#491 `__) -* Update code now that parameter types are static by default (`#487 `__) -* Update logging macros (`#476 `__) -* Make sure to wait for the service before declaring events. (`#473 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Michael Jeronimo, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp_native `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update demo_nodes_cpp_native to new Fast DDS API (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo, Miguel Company - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#502 `__) -* Update deprecated qos policy value names (`#468 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Ivan Santiago Paunovic, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`diagnostic_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`domain_coordinator `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#11 `__) -* Add pytest.ini to suppress warning output locally. (`#8 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_map_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_robot_bringup `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_sensors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`example_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change links from index.ros.org -> docs.ros.org. (`#13 `__) -* Update maintainer. (`#12 `__) -* Contributors: Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_cbg_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix clang warnings about type mismatches. (`#309 `__) -* Support for cbg_executor package on QNX (`#305 `__) -* Demo for callback-group-level executor concept. (`#302 `__) -* Contributors: Chris Lalancette, Ralph Lange, joshua-qnx - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#292 `__) -* Update goal response callback signature (`#291 `__) -* Make sure to include what you use in all examples. (`#284 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#292 `__) -* Make sure to include what you use in all examples. (`#284 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#292 `__) -* Make sure to include what you use in all examples. (`#284 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#292 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Unique network flows (`#296 `__) -* Update maintainers (`#292 `__) -* Make sure to include what you use in all examples. (`#284 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#292 `__) -* Make sure to include what you use in all examples. (`#284 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Unique network flows (`#296 `__) -* Update maintainers (`#292 `__) -* Make sure to include what you use in all examples. (`#284 `__) -* Remove a TODO in the not_composable demo. (`#285 `__) -* Add Topic Statistics Example (`#281 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chris Lalancette, Devin Bonnie, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_timer `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#292 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_multithreaded_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use ``char *`` in logging macros (`#295 `__) -* Update maintainers (`#292 `__) -* Added common linters (`#265 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_executors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Update maintainers (`#292 `__) -* Contributors: Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_guard_conditions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Update maintainers (`#292 `__) -* [rclpy] Create a package with an example showing how guard conditions work (`#283 `__) -* Contributors: Audrow Nash, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Using asyncio with ros2 action client (`#301 `__) -* Update maintainers (`#292 `__) -* Added missing linting tests (`#287 `__) -* Contributors: Allison Thackston, Ivan Santiago Paunovic, Shane Loretz, alemme - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Update maintainers (`#292 `__) -* Added missing linting tests (`#287 `__) -* Contributors: Allison Thackston, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Remove bare exception catching (`#299 `__) -* Update maintainers (`#292 `__) -* Contributors: Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Update maintainers (`#292 `__) -* Contributors: Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Update maintainers (`#292 `__) -* Contributors: Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* Update maintainers (`#292 `__) -* Contributors: Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_pointcloud_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#310 `__) -* add pointcloud publisher example (`#276 `__) -* Contributors: Evan Flynn, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg. (`#403 `__) (`#404 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Add pytest.ini so local tests don't display warning (`#276 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`fastrtps_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#69 `__) -* Use CMake config dirs as hint for header/library search (`#56 `__) -* Update package maintainers (`#55 `__) -* QD Update Version Stability to stable version (`#46 `__) -* Contributors: Alejandro Hernández Cordero, Dirk Thomas, Michel Hidalgo, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Port eigen_kdl.h/cpp to ROS2 (`#311 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Contributors: Chris Lalancette, Jafar Abdi - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Finish up API documentation (`#123 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`google_benchmark_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Shrink the size of the tz_offset variable. (`#13 `__) -* Update the patching to work on Windows without admin. (`#11 `__) -* Always preserve source permissions in vendor packages. (`#12 `__) -* Update package maintainers. (`#10 `__) -* Upgrade google benchmark from v1.5.1 to v1.5.2 to include QNX patch. (`#9 `__) -* Set the SOVERSION on benchmark libraries. (`#8 `__) -* Set minimum criteria for system package. (`#3 `__) -* Work around warnings building Google Benchmark w/Clang. (`#2 `__) -* Initial google_benchmark_vendor package. (`#1 `__) -* Initial commit. -* Contributors: Ahmed Sobhy, Chris Lalancette, Michel Hidalgo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [ros2] image_common metapackage (`#129 `__) -* 1.11.11 -* update changelogs -* add Jack as maintainer -* comply to REP 0127 -* add missing description -* define metapackage -* Contributors: Vincent Rabaud, chapulina - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Initialize time stamp for published image messages (`#475 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Added more parameters for camera topic examples (`#465 `__) -* Contributors: Jacob Perron, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix formatting and include paths for linters (`#157 `__) -* Fix QoS initialization from RMW QoS profile (`#158 `__) -* add missing set header (`#140 `__) -* Update to use new count APIs (`#128 `__) -* use latest ros2 API (`#127 `__) -* Update ROS2 branch to account for new NodeOptions interface (`#120 `__) -* camera_info_manager ROS2 port (`#94 `__) -* Pointer api updates (`#104 `__) -* Fix rcutils API change by just removing it. (`#103 `__) -* [ROS2] corrections to remapping for raw images (`#97 `__) -* Make ROS2 ImageTransport conform to old api (`#88 `__) -* Image Transport ROS2 Port (`#84 `__) -* Disable image publisher plugins by name (`#60 `__) * Disable publisher plugins by name * Now have per publisher blacklist instead of image_transport wide. -* update to use non deprecated pluginlib macro -* Extend documentation of ``getCameraInfoTopic`` Document the fact that the ``base_topic`` argument must be resolved in order to build the correct camera info topic. -* Added cv::waitkey(10) for blank popup Without the cv::waitkey(10), it results in a blank popup which crashes/ leads to a black popup. This change corrects that problem. ROS Kinetic, Ubuntu 16.04.3 -* Fix CMake of image_transport/tutorial and polled_camera Fix loads of problems with the CMakeLists. -* image_transport/tutorial: Add dependency on generated msg Without this, build fails on Kinetic because ResizedImage.h has not been generated yet. -* image_transport/tutorial: Add missing catkin_INCLUDE_DIRS Without this, compilation files on Kinetic because ros.h cannot be found. -* 1.11.11 -* update changelogs -* fix linkage in tutorials -* Use $catkin_EXPORTED_TARGETS -* image_transport: fix CameraSubscriber shutdown (circular shared_ptr ref) CameraSubscriber uses a private boost::shared_ptr to share an impl object between copied instances. In CameraSubscriber::CameraSubscriber(), it handed this shared_ptr to boost::bind() and saved the created wall timer in the impl object, thus creating a circular reference. The impl object was therefore never freed. Fix that by passing a plain pointer to boost::bind(). -* avoid a memory copy for the raw publisher -* add a way to publish an image with only the data pointer -* Make function inline to avoid duplicated names when linking statically -* add plugin examples for the tutorial -* update instructions for catkin -* remove uselessly linked library fixes `#28 `__ -* add a tutorial for image_transport -* add Jack as maintainer -* update my email address -* fix the urls -* use the pluginlib script to remove some warnings -* added license headers to various cpp and h files -* get rid of the deprecated class_loader interface -* CMakeLists.txt clean up -* Updated package.xml file(s) to handle new catkin buildtool_depend requirement -* add the right link libraries -* Isolated plugins into their own library to follow new class_loader/pluginlib guidelines. -* remove the brief attribute -* add xml file -* fix bad folder/libraries -* fix dependencies -* add catkin as a dependency -* comply to the catkin API -* install the include directories -* make the libraries public -* catkinize for Groovy -* Initial image_common stack check-in, containing image_transport. -* Contributors: Aaditya Saraiya, Aaron Blasdel, Carl Delsey, Gary Servin, Jacob Perron, Jochen Sprickerhof, Karsten Knese, Lucas Walter, Martin Guenther, Martin Idel, Max Schwarz, Michael Carroll, Mikael Arguedas, Mirza Shah, Thibaud Chupin, Vincent Rabaud, William Woodall, gerkey, kwc, mihelich, mirzashah, pmihelich, straszheim, vrabaud - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`interactive_markers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup bsd 3 clause license usage (`#61 `__) -* Add missing includes (`#81 `__) -* Update maintainers (`#79 `__) -* Increase test timeout necessary for Connext (`#77 `__) -* Fix clang warnings (`#75 `__) -* Remove explicit template parameter in ``spin_until_future_complete`` (`#72 `__) -* Contributors: Bjar Ne, Dirk Thomas, Jacob Perron, Sarthak Mittal, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`intra_process_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`kdl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove tinyxml dependency from kdl_parser. (`#43 `__) -* Remove unused find_library call (`#40 `__) -* Contributors: Chris Lalancette, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`laser_geometry `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use rclcpp::Duration::from_seconds (`#72 `__) -* update maintainers -* increase test timeout -* Contributors: Dirk Thomas, Ivan Santiago Paunovic, Jonathan Binney, Mabel Zhang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Only try to wrap the fd in a socket on Windows (`#498 `__) -* Close the socket pair used for signal management (`#497 `__) -* Remove is_winsock_handle() and instead test if wrapping the handle in a socket.socket() works (`#494 `__) -* Add frontend substitution for logging directory (`#490 `__) -* Add arg_choice arg to DeclareLaunchArguments (`#483 `__) -* Support Python 3.8-provided importlib.metadata (`#482 `__) -* Workaround asyncio signal handling on Unix (`#479 `__) -* Handle signals within the asyncio loop. (`#476 `__) -* Support non-interactive launch.LaunchService runs (`#475 `__) -* print stderr message when command failed (`#474 `__) -* Add frontend support for LogInfo action (`#467 `__) -* Validate unparsed attributes and subentities in launch_xml and launch_yaml (`#468 `__) -* Fix bug in launch.actions.TimerAction.parse() (`#470 `__) -* Allow configuring logging directory through environment variables (`#460 `__) -* Update package maintainers (`#465 `__) -* Expose Timer action in launch xml (`#462 `__) -* Fix dollar symbols in substitution grammar (`#461 `__) -* Add new conditions for checking launch configuration values (`#453 `__) -* Refactor launch service run_async loop to wait on futures and queued events (`#449 `__) -* Fix documentation typo (`#446 `__) -* Fix type_utils.extract_type() function. (`#445 `__) -* Handle empty strings in type coercion. (`#443 `__) -* Consolidate type_utils in a way that can be reused in substitution results that need to be coerced to a specific type (`#438 `__) -* Delete unnecessary loading of 'launch.frontend.interpolate_substitution_method' entry point that was never used (`#434 `__) -* Avoid side effect, defer until needed (`#432 `__) -* Remove pkg_resources, replace it with the use of the more modern importlib* libraries. (`#430 `__) -* Remove the asyncio.wait loop parameter. (`#429 `__) -* Add pytest.ini so local tests don't display warning (`#428 `__) -* Defer shutdown if already running (`#427 `__) -* Add respawn and respawn_delay support (`#426 `__) -* Fix up parser.py (`#414 `__) -* Contributors: CHEN, Chris Lalancette, Christophe Bedard, Dan Rose, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Michel Hidalgo, Scott K Logan, Takamasa Horibe, Victor Lopez - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support Python 3.8 importlib.metadata, declare dependency (`#229 `__) -* Add options extensions to ros2launch and extensibility to the node action (`#216 `__) -* Make sure ParameterFile __del_\_ works without exception. (`#212 `__) -* Fix docblock in LoadComposableNodes (`#207 `__) -* Validate complex attributes of 'node' action (`#198 `__) -* Node.__init_\_() executable and ComposableNode.__init_\_() plugin arguments aren't optional (`#197 `__) -* Remove constructors arguments deprecated since Foxy (`#190 `__) -* Make name and namespace mandatory in ComposableNodeContainer, remove deprecated alternatives (`#189 `__) -* Merge pull request `#183 `__ from ros2/update-maintainers Update the package.xml files with the latest Open Robotics maintainers -* Move previous maintainer to -* Update the package.xml files with the latest Open Robotics maintainers -* Fix AttributeError when accessing component container name (`#177 `__) -* Handle any substitution types for SetParameter name argument (`#182 `__) -* Asynchronously wait for load node service response (`#174 `__) -* Fix case where list of composable nodes is zero (`#173 `__) -* Do not use event handler for loading composable nodes (`#170 `__) -* Fix race with launch context changes when loading composable nodes (`#166 `__) -* Substitutions in parameter files (`#168 `__) -* Fix documentation typo (`#167 `__) -* Fix problems when parsing a ``Command`` ``Substitution`` as a parameter value (`#137 `__) -* Add a way to set remapping rules for all nodes in the same scope (`#163 `__) -* Resolve libyaml warning when loading parameters from file (`#161 `__) -* Fix ComposableNode ignoring PushRosNamespace actions (`#162 `__) -* Add a SetParameter action that sets a parameter to all nodes in the same scope (`#158 `__) -* Make namespace parameter mandatory in LifecycleNode constructor (`#157 `__) -* Avoid using a wildcard to specify parameters if possible (`#154 `__) -* Fix no specified namespace (`#153 `__) -* Add pytest.ini so local tests don't display warning (`#152 `__) -* Contributors: Chris Lalancette, Dereck Wonnacott, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use unittest.mock instead of mock (`#487 `__) -* Update package maintainers (`#465 `__) -* Disable cleanup of test cases once they have been run (`#406 `__) -* Fix max() with empty sequence (`#440 `__) -* Use unittest.TestCase.id() for pytest failure reprs. (`#436 `__) -* Use unittest.TestCase.id() to put together jUnit XML output. (`#435 `__) -* Claim ownership (`#433 `__) -* Contributors: Dirk Thomas, Michel Hidalgo, Scott K Logan, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers (`#465 `__) -* Add bsd license to launch due to files from roslaunch (`#456 `__) -* Use launch_test CMake target as output file basename (`#448 `__) -* Find Python debug interpreter on Windows (`#437 `__) -* Contributors: Dirk Thomas, Michel Hidalgo, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores in setup.cfg instead of dashes. (`#227 `__) -* Merge pull request `#183 `__ from ros2/update-maintainers -* Move Pete to author, per clalancette -* Update the package.xml files with the latest Open Robotics maintainers -* Add pytest.ini so local tests don't display warning (`#152 `__) -* Contributors: Chris Lalancette, Michael Jeronimo, Mike Purvis - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_xml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add frontend support for LogInfo action (`#467 `__) -* Validate unparsed attributes and subentities in launch_xml and launch_yaml (`#468 `__) -* Add test for launch.actions.TimerAction (`#470 `__) -* Update package maintainers (`#465 `__) -* Use new type_utils functions (`#438 `__) -* Add pytest.ini so local tests don't display warning (`#428 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_yaml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add frontend support for LogInfo action (`#467 `__) -* Validate unparsed attributes and subentities in launch_xml and launch_yaml (`#468 `__) -* Update package maintainers (`#465 `__) -* Use new type_utils functions (`#438 `__) -* Close YAML file when we're done. (`#415 `__) -* Add pytest.ini so local tests don't display warning (`#428 `__) -* Contributors: Chris Lalancette, Dan Rose, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libcurl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update libcurl_vendor to the latest version (7.75.0). (`#60 `__) -* Add an override flag to force vendored build (`#58 `__) -* Update maintainers (`#53 `__) -* bump curl version to 7.68 (`#47 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libstatistics_collector `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix: measured values after the decimal point are truncated `#79 `__ (`#80 `__) -* Update linter to run on rolling+focal (`#81 `__) -* Add automerge.yml config file (`#70 `__) -* Update QD to QL 1 (`#68 `__) -* Updated QD (`#64 `__) -* Updated QD Performance tests (`#58 `__) -* Added benchmark test to libstatistics_collector (`#57 `__) * Added benchmark test to libstatistics_collector * cppcheck supressed unknown macro warning - macos * Reset heap counters * Added feedback * Remove unknownMacro suppression from CMakeLists.txt * Added feedback * moved benchmark test to test/benchmark * Added feedback Co-authored-by: Devin Bonnie <47613035+dabonnie@users.noreply.github.com> -* Report failed workflows (`#56 `__) Allow codecov failures to be silent -* Add default CODEOWNERS file (`#55 `__) -* Remove repo activity from individual repositories in favor of centralized reporting (`#52 `__) -* Don't attempt to report if originating from a fork (`#43 `__) -* Removed doxygen warnings (`#41 `__) Co-authored-by: Anas Abou Allaban -* Add autoapprove action for dependabot (`#40 `__) -* Create Dependabot config file (`#31 `__) * Create Dependabot config file * Randomize time of run Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com> Co-authored-by: Prajakta Gokhale -* Updated QD to 3 (`#30 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#24 `__) Co-authored-by: Emerson Knapp <537409+emersonknapp@users.noreply.github.com> -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Devin Bonnie, Emerson Knapp, Lucas Han, Prajakta Gokhale, Stephen Brawner, hsgwa - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libyaml_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#38 `__) -* Update libyaml_vendor to 0.2.5. (`#37 `__) -* Fix linker flags for tests when CMake < 3.13 (`#35 `__) -* Always preserve source permissions in vendor packages (`#31 `__) -* Fix target_link_directories/link_directories in cmake (`#29 `__) -* Included benchmark tests (`#20 `__) -* Update Quality Declaration (`#23 `__) -* Update package maintainers. (`#22 `__) -* Bump QD to 3 and some minor style fixes (`#19 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#18 `__) -* Add quality declaration libyaml_vendor (`#12 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jorge Perez, Michel Hidalgo, Scott K Logan, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup the README.rst for the lifecycle demo. (`#508 `__) -* change ParameterEventHandler to take events as const ref instead of shared pointer (`#494 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Add missing required parameter in LifecycleNode launch action (`#456 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michael Jeronimo, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#122 `__) -* Updating Quality Declaration (`#120 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`logging_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update logging macros (`#476 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Audrow Nash, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`map_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update maintainers -* Contributors: Mabel Zhang, Steve Macenski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`message_filters `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Find and export dependencies properly (`#54 `__) -* Add pytest.ini so local tests don't display warning (`#47 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mimick_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Always preserve source permissions in vendor packages (`#19 `__) -* Suppress update of pinned git repository (`#17 `__) -* Don't overwrite -Wno-dev CMake argument (`#18 `__) -* Add missing build tool dependency on 'git' (`#16 `__) -* Update tag for armv7l support. (`#15 `__) -* Update tag for new cmake version requirement (`#14 `__) -* Export include directories (`#13 `__) -* Update package maintainers (`#10 `__) -* Suppress cppcheck for MMK_MANGLE\_ (`#8 `__) -* Change Mimick tagged version. (`#7 `__) -* Change tag to pull latest Mimick version (`#6 `__) -* Pin Mimick version. (`#5 `__) -* Change imported dep to match ROS 2 fork (`#4 `__) -* Avoid CMAKE_BUILD_TYPE warnings on Windows. (`#3 `__) -* Remove dep tag + add maintainer(`#2 `__) -* Configure MSVC x64 builds when appropriate. (`#1 `__) -* First iteration vendor for Mimick library -* Contributors: Jorge Perez, Michel Hidalgo, Scott K Logan, Stephen Brawner, brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`nav_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Add LoadMap service (`#129 `__) -* Update Quality levels to level 3 (`#124 `__) -* Finish up API documentation (`#123 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, Steve Macenski, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix osrf.py_common.process_utils.get_loop() implementation (`#70 `__) -* Python 2/3 version conflict (`#69 `__) -* remove jessie because we no longer support 3.4 (`#67 `__) -* Remove deprecated use of asyncio.coroutine decorator. (`#64 `__) -* Fix the __str_\_ method for windows terminal_color. (`#65 `__) -* Contributors: Chris Lalancette, Jochen Sprickerhof, Michel Hidalgo, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_testing_tools_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [osrf_testing_tools_cpp] Add warnings (`#54 `__) -* Update cmake minimum version to 2.8.12 (`#61 `__) -* Add googletest v1.10.0 (`#55 `__) -* Workarounds for Android (`#52 `__) (`#60 `__) -* Change ``WIN32`` to ``__WIN32`` (`#53 `__) -* fix execinfo.h not found for QNX (`#50 `__) -* Contributors: Ahmed Sobhy, Audrow Nash, Dan Rose, Jacob Perron, Stephen Brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_control `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace rmw_connext_cpp with rmw_connextdds (`#489 `__) -* Remove ineffective log output (`#450 `__) (`#477 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Remove deprecated warning (`#459 `__) -* Follow API/file name changes (`ros2/realtime_support#94 `__) (`#451 `__) -* Contributors: Anas Abou Allaban, Andrea Sorbini, Michael Jeronimo, y-okumura-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`performance_test_fixture `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Record calls to calloc, update tests (`#15 `__) -* Make allocation counter atomic (`#13 `__) Even if the benchmark itself isn't threaded, the process we're testing could be. In any case, this should prevent those shenanigans from messing up the measurement. -* Add methods for pausing/resuming performance metrics (`#10 `__) * Add methods for pausing/resuming performance metrics -* Add benchmarks to evaluate overhead (`#11 `__) * Add benchmarks to evaluate overhead in performance tests -* Add namespace performance_test_fixture to .cpp (`#9 `__) -* Export dependency on benchmark and osrf_testing_tools_cpp (`#8 `__) -* Update maintainers (`#7 `__) -* Expose a function for resetting the heap counters (`#6 `__) -* Stop recording memory operations sooner (`#5 `__) -* Suppress memory tools warning if tests will be skipped (`#4 `__) -* Export dependency on ament_cmake_google_benchmark (`#3 `__) -* Add missing dependency on ament_cmake_google_benchmark (`#2 `__) -* Initial 'performance_test_fixture' package (`#1 `__) -* Initial commit -* Contributors: Alejandro Hernández Cordero, Scott K Logan, brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pluginlib `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use rcpputils for the filesystem implementation. (`#212 `__) -* Check for NULL in XMLElement::Attribute -* Check for NULL in XMLElement::GetText -* Check for NULL in XMLNode::Value -* Remove unused variable output_library (`#211 `__) -* Make Chris a maintainer of pluginlib. (`#210 `__) -* Add QNX C++ fs library compiler option (`#205 `__) -* Fix cmake 3.5 compatibility (`#203 `__) -* Add function for same-package pluginlib tests (`#201 `__) -* Remove deprecated boost functions (`#199 `__) -* Contributors: Ahmed Sobhy, Chris Lalancette, Jeremie Deray, Karsten Knese, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pybind11_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#7 `__) -* Merge pull request `#3 `__ from ros2/fix_windows_warning -* remove passing in CMAKE_BUILD_TYPE Signed-off-by: Mabel Zhang -* cleanup Signed-off-by: Mabel Zhang -* do not define CMAKE_BUILD_TYPE on windows Signed-off-by: Mabel Zhang -* suppress all developer warnings Signed-off-by: Mabel Zhang -* suppress warning on windows Signed-off-by: Mabel Zhang -* attempt to fix windows warning Signed-off-by: Mabel Zhang -* Disable building pybind11 tests (`#1 `__) Signed-off-by: Karsten Knese -* Update to pybind 2.5.0 (`#2 `__) Signed-off-by: Mabel Zhang -* Create pybind11 vendor package. Signed-off-by: Michael Carroll -* Contributors: Karsten Knese, Mabel Zhang, Michael Carroll, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#2 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_qt_binding `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add repo README -* Shorten some long lines of CMake (`#99 `__) -* Update maintainers (`#96 `__) (`#98 `__) -* Add pytest.ini so local tests don't display warning (`#93 `__) -* Contributors: Chris Lalancette, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_dotgraph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add API to set edge tooltip (`#237 `__) - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Always prefer 'Tango' icon theme (`#250 `__) -* Fix 'dict_keys' object not subscriptable (`#243 `__) -* allow hide title in standalone (`#235 `__) -* add logic to load qt_gui_icons on windows and macOS (`#222 `__) -* fix exporting perspective for Python 3.6 (`#228 `__) -* remove tango-icon-theme dependency (`#224 `__) -* Contributors: Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix duplicated QMap to QMultiMap (`#244 `__) -* Switch to using the filesystem implementation in rcpputils. (`#239 `__) -* avoid a warning about C++ plugins on Windows (`#232 `__) -* qt_gui_cpp_sip: declare private assignment operator for SIP (`#226 `__) -* Contributors: Chris Lalancette, Homalozoa X - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add demo of how to use qos overrides (`#474 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Update comments in quality_of_service_demo_cpp message_lost_talker and message_lost_listener (`#458 `__) -* Add message lost status event demo using rclcpp (`#453 `__) -* Contributors: Ivan Santiago Paunovic, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#502 `__) -* QoS overrides demo in python (`#479 `__) -* Update deprecated qos policy value names (`#468 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Add rclpy message lost status event demo (`#457 `__) -* Contributors: Ivan Santiago Paunovic, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix up test_network_flow_endpoints. (`#912 `__) -* Make test_two_timers_ready_before_timeout less flaky (`#911 `__) -* Add publishing instrumentation (`#905 `__) -* Unique network flows (`#880 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) -* Add functions for waiting for publishers and subscribers (`#907 `__) -* Revert "Mark cyclonedds test_service test as flakey (`#648 `__)" (`#904 `__) -* Guard against returning NULL or empty node names (`#570 `__) -* Remove exceptions for rmw_connext_cpp tests. (`#903 `__) -* Add support for rmw_connextdds (`#895 `__) -* Put an argument list of 'void' where no arguments are expected. (`#899 `__) -* Cleanup documentation for doxygen. (`#896 `__) -* Reference test resources directly from source tree (`#554 `__) -* Re-add "Improve trigger test for graph guard condition (`#811 `__)" (`#884 `__) -* Revert "Improve trigger test for graph guard condition (`#811 `__)" (`#883 `__) -* Move the guard condition cleanup after removing callback. (`#877 `__) -* Make test_subscription_nominal_string_sequence more reliable (`#881 `__) -* Improve trigger test for graph guard condition (`#811 `__) -* Add NULL check in remap.c (`#879 `__) -* Add const to constant rcl_context functions (`#872 `__) -* Fix another failing test on CentOS 7 (`#863 `__) -* Update QDs to QL 1 (`#866 `__) -* Address clang static analysis issues (`#865 `__) -* Fix flaky test_info_by_topic (`#859 `__) -* Update QL (`#858 `__) -* Refactor for removing unnecessary source code (`#857 `__) -* Clarify storing of current_time (`#850 `__) -* Make tests in test_graph.cpp more reliable (`#854 `__) -* Fix for external log segfault after SIGINT (`#844 `__) -* Update tracetools QL and add to rcl_lifecycle's QD (`#845 `__) -* Make test logging rosout more reliable (`#846 `__) -* Return OK when finalizing zero-initialized contexts (`#842 `__) -* Zero initialize events an size_of_events members of rcl_wait_set_t (`#841 `__) -* Update deprecated gtest macros (`#818 `__) -* Make sure to check the return value of rcl APIs. (`#838 `__) -* Add convenient node method to get a final topic/service name (`#835 `__) -* Remove redundant error formatting (`#834 `__) -* Fix memory leak in rcl_subscription_init()/rcl_publisher_init() (`#794 `__) -* Update maintainers (`#825 `__) -* Add a semicolon to RCUTILS_LOGGING_AUTOINIT. (`#816 `__) -* Improve error messages in rcl_lifecycle (`#742 `__) -* Fix memory leak on serialized message in test_publisher/subscription.cpp (`#801 `__) -* Fix memory leak because of mock test (`#800 `__) -* Spelling correction (`#798 `__) -* Fix that not to deallocate event impl in some failure case (`#790 `__) -* calling fini functions to avoid memory leak (`#791 `__) -* Bump rcl arguments' API test coverage (`#777 `__) -* Fix rcl arguments' API memory leaks and bugs (`#778 `__) -* Add coverage tests wait module (`#769 `__) -* Fix wait set allocation cleanup (`#770 `__) -* Improve test coverage in rcl (`#764 `__) -* Check if rcutils_strdup() outcome immediately (`#768 `__) -* Cleanup rcl_get_secure_root() implementation (`#762 `__) -* Add fault injection macros to rcl functions (`#727 `__) -* Yield rcl_context_fini() error codes (`#763 `__) -* Do not invalidate context before successful shutdown (`#761 `__) -* Zero initialize guard condition on failed init (`#760 `__) -* Adding tests to arguments API (`#752 `__) -* Extend rcl_expand_topic_name() API test coverage (`#758 `__) -* Add coverage tests 94% to service API (`#756 `__) -* Clean up rcl_expand_topic_name() implementation (`#757 `__) -* Complete rcl enclave validation API coverage (`#751 `__) -* Cope with base function restrictions in mocks (`#753 `__) -* Fix allocation when copying arguments (`#748 `__) -* Complete rcl package's logging API test coverage (`#747 `__) -* Improve coverage to 95% in domain id, init option, rmw implementation id and log level modules (`#744 `__) -* Fix rcl package's logging API error code documentation and handling (`#746 `__) -* Fix bug error handling in get_param_files (`#743 `__) -* Complete subscription API test coverage (`#734 `__) -* increase timeouts in test_services fixtures for Connext (`#745 `__) -* Tweaks to client.c and subscription.c for cleaner init/fini (`#728 `__) -* Improve error checking and handling in subscription APIs (`#739 `__) -* Add deallocate calls to free strdup allocated memory (`#737 `__) -* Add missing calls to rcl_convert_rmw_ret_to_rcl_ret (`#738 `__) -* Add mock tests, publisher 95% coverage (`#732 `__) -* Restore env variables set in the test_failing_configuration. (`#733 `__) -* Expose qos setting for /rosout (`#722 `__) -* Reformat rmw_impl_id_check to call a testable function (`#725 `__) -* Add extra check for invalid event implementation (`#726 `__) -* Consolidate macro duplication (`#653 `__) -* Add test for subscription message lost event (`#705 `__) -* Add function rcl_event_is_valid (`#720 `__) -* Move actual domain id from node to context (`#718 `__) -* Removed doxygen warnings (`#712 `__) -* Remove some dead code. -* Make sure to call rcl_arguments_fini at the end of the test. -* Add remap needed null check (`#711 `__) -* Make public init/fini rosout publisher (`#704 `__) -* Move rcl_remap_copy to public header (`#709 `__) -* Implement a generic way to change logging levels (`#664 `__) -* Remove domain_id and localhost_only from node_options (`#708 `__) -* Add coverage tests (`#703 `__) -* Add bad arguments tests for coverage (`#698 `__) -* Remove unused internal prototypes (`#699 `__) -* Update quality declaration and coverage (`#674 `__) -* Add setter and getter for domain_id in rcl_init_options_t (`#678 `__) -* Remove unused pytest dependency from rcl. (`#695 `__) -* Fix link to latest API docs (`#692 `__) -* Keep domain id if ROS_DOMAIN_ID is invalid. (`#689 `__) -* Remove unused check context.c (`#691 `__) -* Add check rcl_node_options_copy invalid out (`#671 `__) -* Update tracetools' QL to 2 in rcl's QD (`#690 `__) -* Improve subscription coverage (`#681 `__) -* Improve rcl timer test coverage (`#680 `__) -* Improve wait sets test coverage (`#683 `__) -* Improve rcl init test coverage. (`#684 `__) -* Improve clock test coverage. (`#685 `__) -* Add message lost event (`#673 `__) -* Minor fixes to rcl clock implementation. (`#688 `__) -* Improve enclave validation test coverage. (`#682 `__) -* Use RCL_RET\_* codes only. (`#686 `__) -* Fixed doxygen warnings (`#677 `__) -* Add tests for rcl package (`#668 `__) -* Remove logging_external_interface.h, provided by rcl_logging_interface package now (`#676 `__) -* Print RCL_LOCALHOST_ENV_VAR if error happens via rcutils_get_env. (`#672 `__) -* Contributors: Ada-King, Alejandro Hernández Cordero, Ananya Muddukrishna, Andrea Sorbini, Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Dan Rose, Dirk Thomas, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Lei Liu, Michel Hidalgo, Nikolai Morin, Scott K Logan, Stephen Brawner, Thijs Raymakers, brawner, shonigmann, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) -* Don't expect RCL_RET_TIMEOUT to set an error string (`#900 `__) -* Add support for rmw_connextdds (`#895 `__) -* Avoid setting error message twice. (`#887 `__) -* Address various clang static analysis fixes (`#864 `__) -* Update QDs to QL 1 (`#866 `__) -* Update QL (`#858 `__) -* Make sure to always check return values (`#840 `__) -* Update deprecated gtest macros (`#818 `__) -* Make sure to check the return value of rcl APIs. (`#838 `__) -* Update maintainers (`#825 `__) -* Store reference to rcl_clock_t instead of copy (`#797 `__) -* Use valid clock in case of issue in rcl_timer_init (`#795 `__) -* Add fault injection macros and unit tests to rcl_action (`#730 `__) -* Change some EXPECT_EQ to ASSERT_EQ in test_action_server. (`#759 `__) -* Removed doxygen warnings (`#712 `__) -* Address issue 716 by zero initializing pointers and freeing memory (`#717 `__) -* Update quality declaration and coverage (`#674 `__) -* Fixed doxygen warnings (`#677 `__) -* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Audrow Nash, Chen Lihui, Chris Lalancette, Ivan Santiago Paunovic, Shane Loretz, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#122 `__) -* Updating Quality Declaration (`#120 `__) -* Add field to the parameter description to specify dynamic/static typing. (`#118 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) -* make rcl_lifecycle_com_interface optional in lifecycle nodes (`#882 `__) -* Update QDs to QL 1 (`#866 `__) -* Update QL (`#858 `__) -* Make sure to always check return values (`#840 `__) -* Update tracetools QL and add to rcl_lifecycle's QD (`#845 `__) -* Add compiler warnings (`#830 `__) -* Make sure to check the return value of rcl APIs. (`#838 `__) -* Add lifecycle node state transition instrumentation (`#804 `__) -* Update maintainers (`#825 `__) -* Improve error messages in rcl_lifecycle (`#742 `__) -* Fix test_rcl_lifecycle (`#788 `__) -* Add fault injection macros and unit tests to rcl_lifecycle (`#731 `__) -* Remove std::cout line from test_rcl_lifecycle.cpp (`#773 `__) -* Set transition_map->states/transition size to 0 on fini (`#729 `__) -* Topic fix rcl lifecycle test issue (`#715 `__) -* Removed doxygen warnings (`#712 `__) -* Update quality declaration and coverage (`#674 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Barry Xu, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Karsten Knese, Lei Liu, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update QD to QL 1 (`#66 `__) -* Use rcutils_expand_user in rcl_logging_get_logging_directory (`#59 `__) -* Allow configuring logging directory through environment variables (`#53 `__) -* Update the maintainers. (`#55 `__) -* Add new package with rcl logging interface (`#41 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Stephen Brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_log4cxx `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow configuring logging directory through environment variables (`#53 `__) -* Update the maintainers. (`#55 `__) -* Remove unused pytest dependency. (`#43 `__) -* Use new package with rcl logging interface (`#41 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_noop `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make internal dependencies private (`#60 `__) -* Update the maintainers. (`#55 `__) -* Remove unused pytest dependency. (`#43 `__) -* Use new package with rcl logging interface (`#41 `__) -* Contributors: Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_spdlog `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#73 `__) -* Include what you use (`#71 `__) -* Update QD to QL 1 (`#66 `__) -* Make sure to check return value from external_initialize. (`#65 `__) -* updated QD section 3.i and 3ii and spelling error (`#63 `__) -* rcl_logging_spdlog: Increased QL to 2 in QD -* Updated spdlog QL in QD -* Make internal dependencies private (`#60 `__) -* [rcl_logging_spdlog] Add warnings (`#54 `__) -* Allow configuring logging directory through environment variables (`#53 `__) -* Update the maintainers. (`#55 `__) -* Added benchmark test to rcl_logging_spdlog (`#52 `__) -* Used current_path() function from rcpputils (`#51 `__) -* Add fault injection unittest to increase coverage (`#49 `__) -* Bump QD to level 3 and updated QD (`#44 `__) -* Added Doxyfile and fixed related warnings (`#42 `__) -* Use new package with rcl logging interface (`#41 `__) -* Increased test coverage (`#40 `__) -* Add Security Vulnerability Policy pointing to REP-2006. -* Rename Quality_Declaration.md -> QUALITY_DECLARATION.md -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Scott K Logan, Shane Loretz, Stephen Brawner, ahcorde, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_yaml_param_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) -* Enable compiler warnings (`#831 `__) -* Update QDs to QL 1 (`#866 `__) -* Rearrange test logic to avoid reference to null (`#862 `__) -* Update QL (`#858 `__) -* Make sure to initialize the end_mark for yaml_event_t (`#849 `__) -* Check for valid node names in parameters files (`#809 `__) -* Update maintainers (`#825 `__) -* Updated performance section QD (`#817 `__) -* Several memory-related fixes for rcl_variant_t benchmarks (`#813 `__) -* Improved rcl_yaml_param_parser benchmark test (`#810 `__) -* Added benchmark test to rcl_yaml_param_parser (`#803 `__) -* Remove MAX_NUM_PARAMS_PER_NODE and MAX_NUM_NODE_ENTRIES limitation. (`#802 `__) -* Add mocking unit tests for rcl_yaml_param_parser (coverage part 3/3) (`#772 `__) -* Add fault-injection unit tests (coverage part 2/3) (`#766 `__) -* Add basic unit tests for refactored functions in rcl_yaml_param_parser (coverage part 1/3) (`#771 `__) -* Fix yaml parser error when meets .nan (refactor on `#754 `__) (`#781 `__) -* Refactor parser.c for better testability (`#754 `__) -* Don't overwrite cur_ns pointer if reallocation fails (`#780 `__) -* Fix mem leaks in unit test from 776 (`#779 `__) -* Fix rcl_parse_yaml_file() error handling. (`#776 `__) -* Don't overwrite string_array pointer on reallocation failure (`#775 `__) -* Set yaml_variant values to NULL on finalization (`#765 `__) -* Remove debugging statements. (`#755 `__) -* Removed doxygen warnings (`#712 `__) -* Update quality declaration and coverage (`#674 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chen Lihui, Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, Stephen Brawner, brawner, shonigmann, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use OnShutdown callback handle instead of OnShutdown callback (`#1639 `__) (`#1650 `__) -* use dynamic_pointer_cast to detect allocator mismatch in intra process manager (`#1643 `__) (`#1644 `__) -* Increase cppcheck timeout to 500s (`#1634 `__) -* Clarify node parameters docs (`#1631 `__) -* Avoid returning loan when none was obtained. (`#1629 `__) -* Use a different implementation of mutex two priorities (`#1628 `__) -* Do not test the value of the history policy when testing the get_publishers/subscriptions_info_by_topic() methods (`#1626 `__) -* Check first parameter type and range before calling the user validation callbacks (`#1627 `__) -* Restore test exception for Connext (`#1625 `__) -* Fix race condition in TimeSource clock thread setup (`#1623 `__) -* remove deprecated code which was deprecated in foxy and should be removed in galactic (`#1622 `__) -* Change index.ros.org -> docs.ros.org. (`#1620 `__) -* Unique network flows (`#1496 `__) -* Add spin_some support to the StaticSingleThreadedExecutor (`#1338 `__) -* Add publishing instrumentation (`#1600 `__) -* Create load_parameters and delete_parameters methods (`#1596 `__) -* refactor AnySubscriptionCallback and add/deprecate callback signatures (`#1598 `__) -* Add generic publisher and generic subscription for serialized messages (`#1452 `__) -* use context from ``node_base\_`` for clock executor. (`#1617 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) -* Initialize integers in test_parameter_event_handler.cpp to avoid undefined behavior (`#1609 `__) -* Namespace tracetools C++ functions (`#1608 `__) -* Revert "Namespace tracetools C++ functions (`#1603 `__)" (`#1607 `__) -* Namespace tracetools C++ functions (`#1603 `__) -* Clock subscription callback group spins in its own thread (`#1556 `__) -* Remove rmw_connext_cpp references. (`#1595 `__) -* Add API for checking QoS profile compatibility (`#1554 `__) -* Document misuse of parameters callback (`#1590 `__) -* use const auto & to iterate over parameters (`#1593 `__) -* Guard against integer overflow in duration conversion (`#1584 `__) -* get_parameters service should return empty if undeclared parameters are allowed (`#1514 `__) -* Made 'Context::shutdown_reason' function a const function (`#1578 `__) -* Document design decisions that were made for statically typed parameters (`#1568 `__) -* Fix doc typo in CallbackGroup constructor (`#1582 `__) -* Enable qos parameter overrides for the /parameter_events topic (`#1532 `__) -* Add support for rmw_connextdds (`#1574 `__) -* Remove 'struct' from the rcl_time_jump_t. (`#1577 `__) -* Add tests for declaring statically typed parameters when undeclared parameters are allowed (`#1575 `__) -* Quiet clang memory leak warning on "DoNotOptimize". (`#1571 `__) -* Add ParameterEventsSubscriber class (`#829 `__) -* When a parameter change is rejected, the parameters map shouldn't be updated. (`#1567 `__) -* Fix when to throw the NoParameterOverrideProvided exception. (`#1567 `__) -* Fix SEGV caused by order of destruction of Node sub-interfaces (`#1469 `__) -* Fix benchmark test failure introduced in `#1522 `__ (`#1564 `__) -* Fix documented example in create_publisher (`#1558 `__) -* Enforce static parameter types (`#1522 `__) -* Allow timers to keep up the intended rate in MultiThreadedExecutor (`#1516 `__) -* Fix UBSAN warnings in any_subscription_callback. (`#1551 `__) -* Fix runtime error: reference binding to null pointer of type (`#1547 `__) -* Reference test resources directly from source tree (`#1543 `__) -* clear statistics after window reset (`#1531 `__) (`#1535 `__) -* Fix a minor string error in the topic_statistics test. (`#1541 `__) -* Avoid ``Resource deadlock avoided`` if use intra_process_comms (`#1530 `__) -* Avoid an object copy in parameter_value.cpp. (`#1538 `__) -* Assert that the publisher_list size is 1. (`#1537 `__) -* Don't access objects after they have been std::move (`#1536 `__) -* Update for checking correct variable (`#1534 `__) -* Destroy msg extracted from LoanedMessage. (`#1305 `__) -* Add instrumentation for linking a timer to a node (`#1500 `__) -* Fix error when using IPC with StaticSingleThreadExecutor (`#1520 `__) -* Change to using unique_ptrs for DummyExecutor. (`#1517 `__) -* Allow reconfiguring 'clock' topic qos (`#1512 `__) -* Allow to add/remove nodes thread safely in rclcpp::Executor (`#1505 `__) -* Call rclcpp::shutdown in test_node for clean shutdown on Windows (`#1515 `__) -* Reapply "Add get_logging_directory method to rclcpp::Logger (`#1509 `__)" (`#1513 `__) -* use describe_parameters of parameter client for test (`#1499 `__) -* Revert "Add get_logging_directory method to rclcpp::Logger (`#1509 `__)" (`#1511 `__) -* Add get_logging_directory method to rclcpp::Logger (`#1509 `__) -* Better documentation for the QoS class (`#1508 `__) -* Modify excluding callback duration from topic statistics (`#1492 `__) -* Make the test of graph users more robust. (`#1504 `__) -* Make sure to wait for graph change events in test_node_graph. (`#1503 `__) -* add timeout to SyncParametersClient methods (`#1493 `__) -* Fix wrong test expectations (`#1497 `__) -* Update create_publisher/subscription documentation, clarifying when a parameters interface is required (`#1494 `__) -* Fix string literal warnings (`#1442 `__) -* support describe_parameters methods to parameter client. (`#1453 `__) -* Add getters to rclcpp::qos and rclcpp::Policy enum classes (`#1467 `__) -* Change nullptr checks to use ASSERT_TRUE. (`#1486 `__) -* Adjust logic around finding and erasing guard_condition (`#1474 `__) -* Update QDs to QL 1 (`#1477 `__) -* Add performance tests for parameter transport (`#1463 `__) -* Move ownership of shutdown_guard_condition to executors/graph_listener (`#1404 `__) -* Add options to automatically declare qos parameters when creating a publisher/subscription (`#1465 `__) -* Add ``take_data`` to ``Waitable`` and ``data`` to ``AnyExecutable`` (`#1241 `__) -* Add benchmarks for node parameters interface (`#1444 `__) -* Remove allocation from executor::remove_node() (`#1448 `__) -* Fix test crashes on CentOS 7 (`#1449 `__) -* Bump rclcpp packages to Quality Level 2 (`#1445 `__) -* Added executor benchmark tests (`#1413 `__) -* Add fully-qualified namespace to WeakCallbackGroupsToNodesMap (`#1435 `__) -* Deprecate Duration(rcl_duration_value_t) in favor of static Duration::from_nanoseconds(rcl_duration_value_t) (`#1432 `__) -* Avoid parsing arguments twice in ``rclcpp::init_and_remove_ros_arguments`` (`#1415 `__) -* Add service and client benchmarks (`#1425 `__) -* Set CMakeLists to only use default rmw for benchmarks (`#1427 `__) -* Update tracetools' QL in rclcpp's QD (`#1428 `__) -* Add missing locking to the rclcpp_action::ServerBase. (`#1421 `__) -* Initial benchmark tests for rclcpp::init/shutdown create/destroy node (`#1411 `__) -* Refactor test CMakeLists in prep for benchmarks (`#1422 `__) -* Add methods in topic and service interface to resolve a name (`#1410 `__) -* Update deprecated gtest macros (`#1370 `__) -* Clear members for StaticExecutorEntitiesCollector to avoid shared_ptr dependency (`#1303 `__) -* Increase test timeouts of slow running tests with rmw_connext_cpp (`#1400 `__) -* Avoid self dependency that not destoryed (`#1301 `__) -* Update maintainers (`#1384 `__) -* Add clock qos to node options (`#1375 `__) -* Fix NodeOptions copy constructor (`#1376 `__) -* Make sure to clean the external client/service handle. (`#1296 `__) -* Increase coverage of WaitSetTemplate (`#1368 `__) -* Increase coverage of guard_condition.cpp to 100% (`#1369 `__) -* Add coverage statement (`#1367 `__) -* Tests for LoanedMessage with mocked loaned message publisher (`#1366 `__) -* Add unit tests for qos and qos_event files (`#1352 `__) -* Finish coverage of publisher API (`#1365 `__) -* Finish API coverage on executors. (`#1364 `__) -* Add test for ParameterService (`#1355 `__) -* Add time API coverage tests (`#1347 `__) -* Add timer coverage tests (`#1363 `__) -* Add in additional tests for parameter_client.cpp coverage. -* Minor fixes to the parameter_service.cpp file. -* reset rcl_context shared_ptr after calling rcl_init sucessfully (`#1357 `__) -* Improved test publisher - zero qos history depth value exception (`#1360 `__) -* Covered resolve_use_intra_process (`#1359 `__) -* Improve test_subscription_options (`#1358 `__) -* Add in more tests for init_options coverage. (`#1353 `__) -* Test the remaining node public API (`#1342 `__) -* Complete coverage of Parameter and ParameterValue API (`#1344 `__) -* Add in more tests for the utilities. (`#1349 `__) -* Add in two more tests for expand_topic_or_service_name. (`#1350 `__) -* Add tests for node_options API (`#1343 `__) -* Add in more coverage for expand_topic_or_service_name. (`#1346 `__) -* Test exception in spin_until_future_complete. (`#1345 `__) -* Add coverage tests graph_listener (`#1330 `__) -* Add in unit tests for the Executor class. -* Allow mimick patching of methods with up to 9 arguments. -* Improve the error messages in the Executor class. -* Add coverage for client API (`#1329 `__) -* Increase service coverage (`#1332 `__) -* Make more of the static entity collector API private. -* Const-ify more of the static executor. -* Add more tests for the static single threaded executor. -* Many more tests for the static_executor_entities_collector. -* Get one more line of code coverage in memory_strategy.cpp -* Bugfix when adding callback group. -* Fix typos in comments. -* Remove deprecated executor::FutureReturnCode APIs. (`#1327 `__) -* Increase coverage of publisher/subscription API (`#1325 `__) -* Not finalize guard condition while destructing SubscriptionIntraProcess (`#1307 `__) -* Expose qos setting for /rosout (`#1247 `__) -* Add coverage for missing API (except executors) (`#1326 `__) -* Include topic name in QoS mismatch warning messages (`#1286 `__) -* Add coverage tests context functions (`#1321 `__) -* Increase coverage of node_interfaces, including with mocking rcl errors (`#1322 `__) -* Make node_graph::count_graph_users() const (`#1320 `__) -* Add coverage for wait_set_policies (`#1316 `__) -* Only exchange intra_process waitable if nonnull (`#1317 `__) -* Check waitable for nullptr during constructor (`#1315 `__) -* Call vector.erase with end iterator overload (`#1314 `__) -* Use best effort, keep last, history depth 1 QoS Profile for '/clock' subscriptions (`#1312 `__) -* Add tests type_support module (`#1308 `__) -* Replace std_msgs with test_msgs in executors test (`#1310 `__) -* Add set_level for rclcpp::Logger (`#1284 `__) -* Remove unused private function (rclcpp::Node and rclcpp_lifecycle::Node) (`#1294 `__) -* Adding tests basic getters (`#1291 `__) -* Adding callback groups in executor (`#1218 `__) -* Refactor Subscription Topic Statistics Tests (`#1281 `__) -* Add operator!= for duration (`#1236 `__) -* Fix clock thread issue (`#1266 `__) (`#1267 `__) -* Fix topic stats test, wait for more messages, only check the ones with samples (`#1274 `__) -* Add get_domain_id method to rclcpp::Context (`#1271 `__) -* Fixes for unit tests that fail under cyclonedds (`#1270 `__) -* initialize_logging\_ should be copied (`#1272 `__) -* Use static_cast instead of C-style cast for instrumentation (`#1263 `__) -* Make parameter clients use template constructors (`#1249 `__) -* Ability to configure domain_id via InitOptions. (`#1165 `__) -* Simplify and fix allocator memory strategy unit test for connext (`#1252 `__) -* Use global namespace for parameter events subscription topic (`#1257 `__) -* Increase timeouts for connext for long tests (`#1253 `__) -* Adjust test_static_executor_entities_collector for rmw_connext_cpp (`#1251 `__) -* Fix failing test with Connext since it doesn't wait for discovery (`#1246 `__) -* Fix node graph test with Connext and CycloneDDS returning actual data (`#1245 `__) -* Warn about unused result of add_on_set_parameters_callback (`#1238 `__) -* Unittests for memory strategy files, except allocator_memory_strategy (`#1189 `__) -* EXPECT_THROW_EQ and ASSERT_THROW_EQ macros for unittests (`#1232 `__) -* Add unit test for static_executor_entities_collector (`#1221 `__) -* Parameterize test executors for all executor types (`#1222 `__) -* Unit tests for allocator_memory_strategy.cpp part 2 (`#1198 `__) -* Unit tests for allocator_memory_strategy.hpp (`#1197 `__) -* Derive and throw exception in spin_some spin_all for StaticSingleThreadedExecutor (`#1220 `__) -* Make ring buffer thread-safe (`#1213 `__) -* Add missing RCLCPP_PUBLIC to ~StaticExecutorEntitiesCollector (`#1227 `__) -* Document graph functions don't apply remap rules (`#1225 `__) -* Remove recreation of entities_collector (`#1217 `__) -* Fix rclcpp::NodeOptions::operator= (`#1211 `__) -* Link against thread library where necessary (`#1210 `__) -* Unit tests for node interfaces (`#1202 `__) -* Remove usage of domain id in node options (`#1205 `__) -* Remove deprecated set_on_parameters_set_callback function (`#1199 `__) -* Fix conversion of negative durations to messages (`#1188 `__) -* Fix implementation of NodeOptions::use_global_arguments() (`#1176 `__) -* Bump to QD to level 3 and fixed links (`#1158 `__) -* Fix pub/sub count API tests (`#1203 `__) -* Update tracetools' QL to 2 in rclcpp's QD (`#1187 `__) -* Fix exception message on rcl_clock_init (`#1182 `__) -* Throw exception if rcl_timer_init fails (`#1179 `__) -* Unit tests for some header-only functions/classes (`#1181 `__) -* Callback should be perfectly-forwarded (`#1183 `__) -* Add unit tests for logging functionality (`#1184 `__) -* Add create_publisher include to create_subscription (`#1180 `__) -* Check period duration in create_wall_timer (`#1178 `__) -* Fix get_node_time_source_interface() docstring (`#988 `__) -* Add message lost subscription event (`#1164 `__) -* Add spin_all method to Executor (`#1156 `__) -* Reorganize test directory and split CMakeLists.txt (`#1173 `__) -* Check if context is valid when looping in spin_some (`#1167 `__) -* Add check for invalid topic statistics publish period (`#1151 `__) -* Fix spin_until_future_complete: check spinning value (`#1023 `__) -* Fix doxygen warnings (`#1163 `__) -* Fix reference to rclcpp in its Quality declaration (`#1161 `__) -* Allow spin_until_future_complete to accept any future like object (`#1113 `__) -* Contributors: Ada-King, Alejandro Hernández Cordero, Ananya Muddukrishna, Andrea Sorbini, Audrow Nash, Barry Xu, BriceRenaudeau, Chen Lihui, Chris Lalancette, Christophe Bedard, Claire Wang, Colin MacKenzie, Daisuke Sato, Devin Bonnie, Dirk Thomas, DongheeYe, Ivan Santiago Paunovic, Jacob Perron, Jannik Abbenseth, Johannes Meyer, Jorge Perez, Karsten Knese, Louise Poubel, Miaofei Mei, Michel Hidalgo, Miguel Company, Morgan Quigley, Nikolai Morin, Pedro Pena, Sarthak Mittal, Scott K Logan, Shane Loretz, Stephen Brawner, Steven! Ragnarök, Tomoya Fujita, William Woodall, anaelle-sw, bpwilcox, brawner, eboasson, hsgwa, mauropasse, shonigmann, suab321321, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Returns CancelResponse::REJECT while goal handle failed to transit to CANCELING state (`#1641 `__) (`#1653 `__) -* Fix action server deadlock issue that caused by other mutexes locked in CancelCallback (`#1635 `__) (`#1646 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) -* Add support for rmw_connextdds (`#1574 `__) -* node_handle must be destroyed after client_handle to prevent memory leak (`#1562 `__) -* Finalize rcl_handle to prevent leak (`#1528 `__) (`#1529 `__) -* Fix `#1526 `__. (`#1527 `__) -* Fix action server deadlock (`#1285 `__) (`#1313 `__) -* Goal response callback compatibility shim with deprecation of old signature (`#1495 `__) -* [rclcpp_action] Add warnings (`#1405 `__) -* Update QDs to QL 1 (`#1477 `__) -* Add ``take_data`` to ``Waitable`` and ``data`` to ``AnyExecutable`` (`#1241 `__) -* Fix test crashes on CentOS 7 (`#1449 `__) -* Bump rclcpp packages to Quality Level 2 (`#1445 `__) -* Add rclcpp_action action_server benchmarks (`#1433 `__) -* Benchmark rclcpp_action action_client (`#1429 `__) -* Add missing locking to the rclcpp_action::ServerBase. (`#1421 `__) -* Increase test timeouts of slow running tests with rmw_connext_cpp (`#1400 `__) -* Update maintainers (`#1384 `__) -* Increase coverage rclcpp_action to 95% (`#1290 `__) -* Pass goal handle to goal response callback instead of a future (`#1311 `__) -* Remove deprecated client goal handle method for getting result (`#1309 `__) -* Increase test timeout necessary for Connext (`#1256 `__) -* Bump to QD to level 3 and fixed links (`#1158 `__) -* Add rcl_action_client_options when creating action client. (`#1133 `__) -* Fix doxygen warnings (`#1163 `__) -* Increase rclcpp_action test coverage (`#1153 `__) -* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Audrow Nash, Chris Lalancette, Daisuke Sato, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Kaven Yau, Louise Poubel, Michel Hidalgo, Stephen Brawner, Tomoya Fujita, William Woodall, brawner, shonigmann, tomoya, y-okumura-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_components `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) -* Use std compliant non-method std::filesystem::exists function (`#1502 `__) -* Fix string literal warnings (`#1442 `__) -* Update QDs to QL 1 (`#1477 `__) -* Add benchmarks for components (`#1476 `__) -* Bump rclcpp packages to Quality Level 2 (`#1445 `__) -* Update maintainers (`#1384 `__) -* ComponentManager: switch off parameter services and event publisher (`#1333 `__) -* Bump to QD to level 3 and fixed links (`#1158 `__) -* Include original exception in ComponentManagerException (`#1157 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Ivan Santiago Paunovic, Josh Langsfeld, Louise Poubel, Martijn Buijs, Scott K Logan, Stephen Brawner, Tomoya Fujita, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add generic publisher and generic subscription for serialized messages (`#1452 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) -* Fix flaky lifecycle node tests (`#1606 `__) -* Clock subscription callback group spins in its own thread (`#1556 `__) -* Delete debug messages (`#1602 `__) -* add automatically_add_executor_with_node option (`#1594 `__) -* make rcl_lifecyle_com_interface optional in lifecycle nodes (`#1507 `__) -* Add support for rmw_connextdds (`#1574 `__) -* Fix SEGV caused by order of destruction of Node sub-interfaces (`#1469 `__) -* Enforce static parameter types (`#1522 `__) -* add LifecycleNode::get_transition_graph to match services. (`#1472 `__) -* Update QDs to QL 1 (`#1477 `__) -* Benchmark lifecycle features (`#1462 `__) -* Reserve vector capacities and use emplace_back for constructing vectors (`#1464 `__) -* [rclcpp_lifecycle] Change uint8_t iterator variables to size_t (`#1461 `__) -* Bump rclcpp packages to Quality Level 2 (`#1445 `__) -* Increase test timeouts of slow running tests with rmw_connext_cpp (`#1400 `__) -* Update maintainers (`#1384 `__) -* Add clock qos to node options (`#1375 `__) -* Increase test coverage of rclcpp_lifecycle to 96% (`#1298 `__) -* Log error instead of throwing exception in Transition and State reset(), mark no except (`#1297 `__) -* Remove unused private function (rclcpp::Node and rclcpp_lifecycle::Node) (`#1294 `__) -* Remove rmw-dependent unit-test checks (`#1293 `__) -* Added missing tests for rclcpp lifecycle (`#1240 `__) -* Warn about unused result of add_on_set_parameters_callback (`#1238 `__) -* Remove deprecated set_on_parameters_set_callback function (`#1199 `__) -* Bump to QD to level 3 and fixed links (`#1158 `__) -* Fix race in test_lifecycle_service_client (`#1204 `__) -* Fix doxygen warnings (`#1163 `__) -* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, BriceRenaudeau, Claire Wang, Colin MacKenzie, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Karsten Knese, Louise Poubel, Nikolai Morin, Stephen Brawner, anaelle-sw, brawner, shonigmann, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Break log function execution ASAP if configured severity is too high (`#776 `__) (`#783 `__) -* typo fix. (`#768 `__) -* Restore exceptions for Connext and message timestamps on Windows (`#765 `__) -* Use correct type when creating test publisher (`#764 `__) -* Add a test for destroy_node while spinning (`#663 `__) -* Add __enter_\_ and __exit_\_ to Waitable (`#761 `__) -* Check if shutdown callback weak method is valid before calling it (`#754 `__) -* Change index.ros.org -> docs.ros.org. (`#755 `__) -* Use py::class\_ for rcl_event_t (`#750 `__) -* Convert Clock to use a C++ Class (`#749 `__) -* Convert Service to use C++ Class (`#747 `__) -* Fix windows warning by using consistent types (`#753 `__) -* Use py::class\_ for rmw_service_info_t and rmw_request_id_t (`#748 `__) -* Convert Timer to use a C++ Class (`#745 `__) -* Add PythonAllocator (`#746 `__) -* Use py::class\_ for rmw_qos_profile_t (`#741 `__) -* Combine pybind11 modules into one (`#743 `__) -* Use py::class\_ for rcl_duration_t (`#744 `__) -* Fix bug in unique_ptr type argument (`#742 `__) -* Convert Client to use C++ Class (`#739 `__) -* Converting last of _rclpy.c to pybind11 (`#738 `__) -* Make sure only non-empty std::vector of arguments are indexed (`#740 `__) -* Use py::class\_ for rcl_time_point_t (`#737 `__) -* Convert logging mutex functions to pybind11 (`#735 `__) -* Document misuse of of parameter callbacks (`#734 `__) -* Convert QoS APIs to pybind11 (`#736 `__) -* Add API for checking QoS profile compatibility (`#708 `__) -* Replace rmw_connext_cpp with rmw_connextdds (`#698 `__) -* Convert last of pub/sub getters to pybind11 (`#733 `__) -* Pybind 11: count_subscribers and count_publishers (`#732 `__) -* Convert more node accessors to pybind11 (`#730 `__) -* Pybind11-ify rclpy_get_node_parameters (`#718 `__) -* Modify parameter service behavior when allow_undeclared_parameters is false and the requested parameter doesn't exist (`#661 `__) -* Include pybind11 first to fix windows debug warning (`#731 `__) -* Convert init/shutdown to pybind11 (`#715 `__) -* Convert take API to pybind11 (`#721 `__) -* Migrate qos event APIs to pybind11 (`#723 `__) -* Remove pybind11 from rclpy common (`#727 `__) -* Look up pybind11 package once (`#726 `__) -* typo fix. (`#729 `__) -* [pybind11] Node Accessors (`#719 `__) -* Convert serialize/deserialize to pybind11 (`#712 `__) -* Convert names_and_types graph APIs to pybind11 (`#717 `__) -* Use Pybind11 for name functions (`#709 `__) -* Better checks for valid msg and srv types (`#714 `__) -* Convert duration to pybind11 (`#716 `__) -* Convert wait_set functions to pybind11 (`#706 `__) -* Explicitly populate tuple with None (`#711 `__) -* Change the time jump time type to just rcl_time_jump_t. (`#707 `__) -* Convert rclpy service functions to pybind11 (`#703 `__) -* Bump the cppcheck timeout by 2 minutes (`#705 `__) -* Convert subscription functions to pybind11 (`#696 `__) -* Convert rclpy client functions to pybind11 (`#701 `__) -* Fix static typing when allow undeclared (`#702 `__) -* Convert publisher functions to pybind11 (`#695 `__) -* Convert clock and time functions to pybind11 (`#699 `__) -* Set destructor on QoS Profile struct (`#700 `__) -* Convert timer functions to pybind11 (`#693 `__) -* Convert guard conditions functions to pybind11 (`#692 `__) -* Convert service info functions to pybind11 (`#694 `__) -* Enforce static parameter types when dynamic typing is not specified (`#683 `__) -* rclpy_ok and rclpy_create_context to pybind11 (`#691 `__) -* Include Pybind11 before Python.h (`#690 `__) -* Clean up exceptions in _rclpy_action (`#685 `__) -* Clean windows flags on _rclpy_pybind11 and _rclpy_action (`#688 `__) -* Use pybind11 for _rclpy_handle (`#668 `__) -* Split rclpy module for easier porting to pybind11 (`#675 `__) -* Use Pybind11 to generate _rclpy_logging (`#659 `__) -* Copy windows debug fixes for pybind11 (`#681 `__) -* Use pybind11 for _rclpy_action (`#678 `__) -* Update just pycapsule lib to use pybind11 (`#652 `__) -* remove maintainer (`#682 `__) -* Use Pybind11's CMake code (`#667 `__) -* Don't call destroy_node while spinning (`#674 `__) -* Check the rcl_action return value on cleanup. (`#672 `__) -* Fix the NULL check for destroy_ros_message. (`#677 `__) -* Use Py_XDECREF for pynode_names_and_namespaces (`#673 `__) -* Use Py_XDECREF for pyresult_list. (`#670 `__) -* Fix dead stores. (`#669 `__) -* Fix two clang static analysis warnings. (`#664 `__) -* Add method to get the current logging directory (`#657 `__) -* Fix docstring indent error in create_node (`#655 `__) -* use only True to avoid confusion in autodoc config -* document QoS profile constants -* Merge pull request `#649 `__ from ros2/clalancette/dont-except-while-sleep -* Fixes from review/CI. -* Make sure to catch the ROSInterruptException when calling rate.sleep. -* memory leak (`#643 `__) (`#645 `__) -* Don't throw an exception if timer canceled while sleeping. -* Wake executor in Node.create_subscription() (`#647 `__) -* Fix Enum not being comparable with ints in get_parameter_types service -* Qos configurability (`#635 `__) -* Use Py_XDECREF for pytopic_names_and_types. (`#638 `__) -* qos_policy_name_from_kind() should accept either a QoSPolicyKind or an int (`#637 `__) -* Add method in Node to resolve a topic or service name (`#636 `__) -* Deprecate verbose qos policy value names (`#634 `__) -* Remove deprecated set_parameters_callback (`#633 `__) -* Make sure to use Py_XDECREF in rclpy_get_service_names_and_types (`#632 `__) -* Update maintainers (`#627 `__) -* Add in semicolon on RCUTILS_LOGGING_AUTOINIT. (`#624 `__) -* Add in the topic name when QoS events are fired. (`#621 `__) -* Use best effort, keep last, history depth 1 QoS Profile for '/clock' subscriptions (`#619 `__) -* PARAM_REL_TOL documentation fix (`#559 `__) -* Node get fully qualified name (`#598 `__) -* MultiThreadedExecutor spin_until_future complete should not continue waiting when the future is done (`#605 `__) -* skip test relying on source timestamps with Connext (`#615 `__) -* Use the rpyutils shared import_c_library function. (`#610 `__) -* Add ability to configure domain ID (`#596 `__) -* Use absolute parameter events topic name (`#612 `__) -* Destroy event handlers owned by publishers/subscriptions when calling publisher.destroy()/subscription.destroy() (`#603 `__) -* Default incompatible qos callback should be set when there's no user specified callback (`#601 `__) -* relax rate jitter test for individual periods (`#602 `__) -* add QoSProfile.__str_\_ (`#593 `__) -* Add useful debug info when trying to publish the wrong type (`#581 `__) -* Pass rcutils_include_dirs to cppcheck (`#577 `__) -* wrap lines to shorten line length (`#586 `__) -* fix moved troubleshooting url (`#579 `__) -* improve error message if rclpy C extensions are not found (`#580 `__) -* Add message lost subscription event (`#572 `__) -* Fix executor behavior on shutdown (`#574 `__) -* Add missing rcutils/macros.h header (`#573 `__) -* Add ``topic_name`` property to Subscription (`#571 `__) -* Add ``topic_name`` property to publisher (`#568 `__) -* Fix and document rclpy_handle_get_pointer_from_capsule() (`#569 `__) -* Fix docstrings (`#566 `__) -* Contributors: Addisu Z. Taddese, Alejandro Hernández Cordero, Andrea Sorbini, Audrow, Audrow Nash, Barry Xu, Chris Lalancette, Claire Wang, Dereck Wonnacott, Dirk Thomas, Emerson Knapp, Greg Balke, Gökçe Aydos, Ivan Santiago Paunovic, Jacob Perron, Loy, Michel Hidalgo, Scott K Logan, Shane Loretz, Tomoya Fujita, Tully Foote, Zhen Ju, ksuszka, ssumoo, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcpputils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update quality declaration links (`#130 `__) -* Add functions for getting library path and filename (`#128 `__) -* Add path equality operators (`#127 `__) -* Add create_temp_directory filesystem helper (`#126 `__) -* Use new noexcept specifier. (`#123 `__) -* Add stream operator for paths to make it easier to log (`#120 `__) -* Path join operator is const (`#119 `__) -* No windows.h in header files (`#118 `__) -* Fix rcpputils::SharedLibrary tests. (`#117 `__) -* Update QD to QL 1 (`#114 `__) -* Make sure to not try to index into an empty path. (`#113 `__) -* Fix working with filesystem parent paths. (`#112 `__) -* Cleanup mislabeled BSD license (`#37 `__) -* overload functions for has_symbol and get_symbol with raw string literal (`#110 `__) -* Add an ASSERT to the pointer traits tests. (`#111 `__) -* replace custom get env login into rcutils_get_env(). (`#99 `__) -* Removed Github Actions (`#105 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#102 `__) -* Make sure that an existing path is a directory for create_directories (`#98 `__) -* Transfer ownership to Open Robotics (`#100 `__) -* Ensure -fPIC is used when building a static lib (`#93 `__) -* Removed doxygen warnings (`#86 `__) (`#87 `__) -* Add clamp header (`#85 `__) -* Removed doxygen warnings (`#86 `__) -* Split get_env_var() into header and implementation (`#83 `__) -* Add cstring include for strcmp (`#81 `__) -* filesystem helpers: adding remove_all to remove non-empty directories (`#79 `__) -* Add scope_exit helper (`#78 `__) -* Bump setup-ros to 0.0.23, action-ros-lint to 0.0.6, action-ros-ci to 0.0.17 (`#77 `__) -* Fix parent_path() for empty paths and paths of length one (`#73 `__) -* Add get_executable_name() function (`#70 `__) -* Address memory leak in remove pointer test (`#72 `__) -* Add current_path to filesystem_helpers (`#63 `__) -* Align path combine behavior with C++17 (`#68 `__) -* Update quality declaration to QL 2 (`#71 `__) -* Contributors: Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Christophe Bedard, Devin Bonnie, Dirk Thomas, Emerson Knapp, Hunter L. Allen, Ivan Santiago Paunovic, Jacob Perron, Karsten Knese, Louise Poubel, Michael Jeronimo, Michel Hidalgo, Nikolai Morin, Scott K Logan, Simon Honigmann, Stephen Brawner, Tully Foote, Victor Lopez, William Woodall, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Declare dependency on libatomic (`#338 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#335 `__) -* Quiet down a warning in release mode. (`#334 `__) -* Make the logging separate char an implementation detail. (`#332 `__) -* Performance tests demo (`#288 `__) -* Remove references of __xstat (`#330 `__) -* Update the documentation to be more consistent. (`#331 `__) -* Shorten some excessively long lines of CMake (`#328 `__) -* qnx-support: include sys/link.h & avoid using dlinfo (`#327 `__) -* QNX uses XSI-compliant (`#326 `__) -* Add an API for directory iteration (`#323 `__) -* Fix a leak during error handling in dir size calculation (`#324 `__) -* Fix rcutils_shared_library_t path on Windows. (`#322 `__) -* Check linker flags instead of assuming compiler correlation. (`#321 `__) -* Improve shared library relative paths handling (`#320 `__) -* Update rcutils_calculate_directory_size() to support recursion (`#306 `__) -* Updating QD to QL 1 (`#317 `__) -* Address unused return values found in scan-build (`#316 `__) -* use one copy for continuous area instead of loop copy (`#312 `__) -* use a better way to check whether string is empty (`#315 `__) -* Use helper funciton to copy string (`#314 `__) -* Disable a Windows platform warning. (`#311 `__) -* Fix format of code description on document (`#313 `__) -* Make sure to check the return values of rcutils APIs. (`#302 `__) -* Add rcutils_expand_user() to expand user directory in path (`#298 `__) -* Update the maintainers. (`#299 `__) -* Remove the temporary variable in RCUTILS_LOGGING_AUTOINIT (`#290 `__) -* Add RCUTILS_NO_FAULT_INJECTION() macro. (`#295 `__) -* Inject faults on rcutils_get_env() and rcutils_set_env() call. (`#292 `__) -* env.h and get_env.h docblock fixes (`#291 `__) -* Introduce rcutils_strcasecmp, case insensitive string compare. (`#280 `__) -* Stop using fprintf to avoid using file handles by changing as few lines of code as possible. (`#289 `__) -* Defines QNX implementation for rcutils_get_platform_library_name (`#287 `__) -* Add RCUTILS_CAN_SET_ERROR_MSG_AND_RETURN_WITH_ERROR_OF() macro. (`#284 `__) To fault inject error messages as well as return codes. -* Change rcutils_fault_injection_set_count to use int64_t (`#283 `__) -* adds QNX support for rcutils_get_executable_name (`#282 `__) -* Add fault injection hooks to default allocator (`#277 `__) -* Fault injection macros and functionality (plus example) (`#264 `__) -* ensure -fPIC is used when building a static lib (`#276 `__) -* Drop vsnprintf mocks entirely. (`#275 `__) Binary API is not portable across platforms and compilation config. -* Fix vsnprintf mocks for Release builds. (`#274 `__) -* Improve test coverage mocking system calls (`#272 `__) -* Use mimick/mimick.h header (`#273 `__) -* Add mock test for rcutils/strerror (`#265 `__) -* Add compiler option -Wconversion and add explicit casts for conversions that may alter the value or change the sign (`#263 `__) See https://github.com/ros2/rcutils/pull/263#issuecomment-663252537. -* Removed doxygen warnings (`#266 `__) (`#268 `__) -* Removed doxygen warnings (`#266 `__) -* Force _GNU_SOURCE if glibc is used. (`#267 `__) -* Add parenthesis around the argument in time conversion macros defined in time.h (`#261 `__) -* Add token join macros (`#262 `__) -* Add rcutils_string_array_sort function (`#248 `__) -* Add rcutils_string_array_resize function (`#247 `__) -* Increase testing coverage of rcutils to 95% (`#258 `__) -* Update QUALITY_DECLARATION to reflect QL 2 status (`#260 `__) -* Update version stability section of quality declaration for 1.0 (`#256 `__) -* Contributors: Ahmed Sobhy, Alejandro Hernández Cordero, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Dirk Thomas, Felix Endres, Homalozoa X, Ivan Santiago Paunovic, Johannes Meyer, Jorge Perez, Karsten Knese, Michel Hidalgo, Scott K Logan, Stephen Brawner, Steven! Ragnarök, brawner, shonigmann, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`resource_retriever `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Throw exception if package name is empty (`#54 `__) -* Update maintainers (`#53 `__) -* Add .hpp header and deprecate .h (`#51 `__) -* Add pytest.ini so local tests don't display warning (`#48 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Document which QoS policies are correctly read by rmw_get_publishers/subscriptions_info_by_topic (`#308 `__) -* Unique network flows (`#294 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#307 `__) -* Introduce RMW_DURATION_INFINITE constant and API return value promise (`#301 `__) -* Add declaration for function to check QoS profile compatibility (`#299 `__) -* Update the rmw_take_sequence documentation. (`#297 `__) -* Update rmw QD to QL 1 (`#289 `__) -* Extend rmw_qos_policy_kind_t, add functions to convert it to/from a string (`#285 `__) -* Add functions to convert between qos policy values and strings (`#284 `__) -* Update maintainers (`#282 `__) -* Update service request/response API documentation (`#279 `__) -* Update rmw_get_serialized_message_size docblock (`#281 `__) -* Update rmw_service_server_is_available doc (`#280 `__) -* Update wait and wait sets' API documentation (`#275 `__) -* Update graph API documentation (`#272 `__) -* Update service server/client creation/destruction API documentation. (`#276 `__) -* Update rmw\_*_*_allocation return values (`#278 `__) -* Update gid API documentation (`#274 `__) -* Do not link against pthread on Android (`#267 `__) -* Update taking API documentation (`#271 `__) -* Update publishing API documentation (`#270 `__) -* Add fault injection macros for use in other packages (`#254 `__) -* Add bad_alloc return to topic_endpoint_info functions (`#269 `__) -* Update publisher/subscription matched count API documentation (`#262 `__) -* Update publisher/subscription QoS query API documentation (`#263 `__) -* Extend rmw_serialized_message_t tests (`#261 `__) -* Update serialization/deserialization API documentation (`#258 `__) -* Update subscription API documentation (`#256 `__) -* Update publisher creation/destruction API documentation (`#252 `__) -* Add actual domain id to rmw_context_t (`#251 `__) -* Update node creation/destruction API documentation. (`#249 `__) -* Correct parameter names to match documentation (`#250 `__) -* Remove domain_id and localhost_only from node API (`#248 `__) -* Require enclave upon rmw_init() call. (`#247 `__) -* Update init/shutdown API documentation. (`#243 `__) -* Update init options API documentation. (`#244 `__) -* Add message lost subscription event (`#232 `__) -* Move statuses definitions to rmw/events_statuses/\*.h (`#232 `__) -* Increase rmw testing coverage above 95% (`#238 `__) -* Handle zero-length names_and_types properly (`#239 `__) -* Add missing RMW_PUBLIC to security_options_set_root_path (`#236 `__) -* Update Quality Declaration for QL 2 (`#233 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#230 `__) -* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Karsten Knese, Michel Hidalgo, Scott K Logan, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use rmw_qos_profile_unknown when adding entity to graph (`#28 `__) -* Resolve issues identified while investigating `#21 `__ (`#22 `__) -* Use Rolling in README's Quick Start -* Improved implementation of client::is_service_available for Connext Pro -* Only add request header to typecode with Basic req/rep profile -* Remove commented/unused code -* Avoid topic name validation in get_info functions -* Reduce shutdown period to 10ms -* Pass HistoryQosPolicy to graph cache -* Reset error string after looking up type support -* Remove DDS-based WaitSet implementation -* Merge pull request `#13 `__ from Ericsson/unique_network_flows -* Refactor common API -* Update branch ``master`` to support Rolling only (`#15 `__) -* Add ability to override of endpoint qos settings based on topic name. -* Optimize QoS for reliable large data. -* Only trigger data condition if samples were loaned from reader. -* Alternative WaitSet implementation based on C++ std, selectable at compile-time. -* Add ```` for ``ament_cmake``. -* Use default ``dds.transport.UDPv4.builtin.ignore_loopback_interface``. -* Renamed environment variables (``RMW_CONNEXT_USE_DEFAULT_PUBLISH_MODE``, ``RMW_CONNEXT_LEGACY_RMW_COMPATIBILITY_MODE``). -* Support a list of initial peers via ``RMW_CONNEXT_INITIAL_PEERS``. -* Initial release. -* Contributors: Ananya Muddukrishna, Andrea Sorbini, Ivan Santiago Paunovic, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Correctly detect empty messages (`#33 `__) -* Use rmw_qos_profile_unknown when adding entity to graph (`#28 `__) -* Resolve issues identified while investigating `#21 `__ (`#22 `__) -* Use Rolling in README's Quick Start -* Improved implementation of client::is_service_available for Connext Pro -* Only add request header to typecode with Basic req/rep profile -* Remove commented/unused code -* Avoid topic name validation in get_info functions -* Reduce shutdown period to 10ms -* Pass HistoryQosPolicy to graph cache -* Reset error string after looking up type support -* Remove DDS-based WaitSet implementation -* Merge pull request `#13 `__ from Ericsson/unique_network_flows -* Remove superfluous header inclusion -* Remove conflicting linkage -* Further remove feature-based exclusion -* Remove feature-based exclusion -* Uncrustify -* Refactor common API -* Include required headers if feature is enabled -* Add conditional compilation support -* Prefer more generic file name -* Restrict unique flow endpoint check to versions beyond Foxy -* Indicate missing support for unique network flows -* Update branch ``master`` to support Rolling only (`#15 `__) -* Add ability to override of endpoint qos settings based on topic name (Pro). -* Optimize QoS for reliable large data (Pro). -* Only trigger data condition if samples were loaned from reader. -* Alternative WaitSet implementation based on C++ std, selectable at compile-time. -* Add ```` for ``ament_cmake``. -* Use default ``dds.transport.UDPv4.builtin.ignore_loopback_interface``. -* Don't log an error on WaitSet::wait() timeout. -* Initial release. -* Contributors: Ananya Muddukrishna, Andrea Sorbini, Ivan Santiago Paunovic, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextddsmicro `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use rmw_qos_profile_unknown when adding entity to graph (`#28 `__) -* Resolve issues identified while investigating `#21 `__ (`#22 `__) -* Use Rolling in README's Quick Start -* Remove commented/unused code -* Avoid topic name validation in get_info functions -* Pass HistoryQosPolicy to graph cache -* Reset error string after looking up type support -* Remove DDS-based WaitSet implementation -* Merge pull request `#13 `__ from Ericsson/unique_network_flows -* Refactor common API -* Update branch ``master`` to support Rolling only (`#15 `__) -* Only trigger data condition if samples were loaned from reader. -* Alternative WaitSet implementation based on C++ std, selectable at compile-time. -* Add ```` for ``ament_cmake``. -* Initial release. -* Contributors: Ananya Muddukrishna, Andrea Sorbini, Ivan Santiago Paunovic, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_cyclonedds_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix the history depth for KEEP_ALL. (`#305 `__) -* Use the macros from Cyclone DDS to work with sample payload when using SHM (`#300 `__) -* Add loaned sample zero-copy API support (`#297 `__) -* Indicate missing support for unique network flows (`#282 `__) -* Take and return new RMW_DURATION_INFINITE correctly (`#288 `__) -* Add RMW function to check QoS compatibility (`#286 `__) -* Fix use-after-free in error handling bug -* Drop compatibility with ancient cyclone versions -* Update to use Cyclone's renamed ddsi_sertype -* Use init-on-first-use for global state (`#275 `__) -* Make sure to reset the error when a typesupport can't be found. -* Switch to using the generic functions for the typesupport handles. -* Handle typesupport errors on fetch. (`#271 `__) -* Handle potential divide by 0 (`#267 `__) -* Fix incorrect log message(rmw_fastrtps_shared_cpp -> rmw_cylonedds_cpp) (`#260 `__) -* Update maintainers (`#254 `__) -* Change wrong use of %ld to print std::size_t to %zu -* Return RMW_RET_UNSUPPORTED in rmw_get_serialized_message_size (`#250 `__) -* Update service/client request/response API error returns (`#249 `__) -* Updated publisher/subscription allocation and wait set API return codes (`#246 `__) -* Fix array ``get_function`` semantics (`#248 `__) -* Update service/client construction/destruction API return codes. (`#247 `__) -* Update gid API return codes. (`#244 `__) -* Update graph API return codes. (`#243 `__) -* Check for message_info on take where appropriate. (`#245 `__) Fix for regression introduced in `#241 `__. -* Updated error returns on rmw_take_serialized() and rmw_take_with_message_info() (`#242 `__) -* Updated error returns on rmw_take() (`#241 `__) -* Add quality declaration for Cyclone DDS (`#218 `__) -* Fix that not to delete some objects after destroying functions (`#236 `__) -* Update rmw_publish_serialized_message() error returns (`#240 `__) -* Update rmw_publish() error returns (`#239 `__) -* Remove public declarations (`#230 `__) -* Use quotes for non-system includes (`#231 `__) -* Use correct functions to resize and get an item, avoiding memory leaks in typesupport code (`#228 `__) -* Fix context cleanup. (`#227 `__) -* Fix memory leak that type support not deleted. (`#225 `__) -* Ensure compliant matched pub/sub count API. (`#223 `__) -* Fix memory leak that string not deleted. (`#224 `__) -* Change RET_WRONG_IMPLID() to return RMW_RET_INCORRECT_IMPLEMENTATION (`#226 `__) -* Fix bad conditional in rmw_serialize(). (`#217 `__) -* Ensure compliant subscription API. (`#214 `__) -* Ensure compliant publisher API (`#210 `__) -* rmw_destroy_node must remove node from graph cache (`#213 `__) -* Add space between 'ROS' and '2' (`#195 `__) -* Set context actual domain id (`#208 `__) -* Ensure compliant node construction/destruction API (`#206 `__) -* Remove domain_id and localhost_only from node API (`#205 `__) -* Amend rmw_init() implementation: require enclave. (`#204 `__) -* Ensure compliant init/shutdown API implementations. (`#202 `__) -* Ensure compliant init options API implementations. (`#200 `__) -* Finalize context iff shutdown. (`#196 `__) -* Handle RMW_DEFAULT_DOMAIN_ID. (`#194 `__) -* Add support to message lost event (`#192 `__) -* Mitigate lost service responses discovery issue (`#187 `__) -* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chen Lihui, Chris Lalancette, Christophe Bedard, Dan Rose, Emerson Knapp, Erik Boasson, Ivan Santiago Paunovic, Jacob Perron, Joe Speed, Jose Tomas Lorente, Lobotuerk, Michel Hidalgo, Scott K Logan, Stephen Brawner, Sumanth Nirmal, Sven Brinkmann, eboasson, pluris - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_dds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix one more instance of index.ros.org. (`#49 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#46 `__) -* Add function for checking QoS profile compatibility (`#45 `__) -* Shorten some excessively long lines of CMake (`#44 `__) -* Fix test_graph_cache ASAN errors (`#41 `__) (`#42 `__) -* Update QD to QL 1 (`#38 `__) -* Create a utility function to limit rmw_time_t to 32-bit values (`#37 `__) -* Update maintainers (`#34 `__) -* Updated performance section QD (`#30 `__) -* Update Quality Declaration to QL2 (`#31 `__) -* Added benchmark test to rmw_dds_common (`#29 `__) -* Fix potential memory leak (`#28 `__) -* Add fault injection macro unit tests (`#27 `__) -* Fixed some doxygen warnings (`#26 `__) -* Update Quality Declaration to QL3 (`#24 `__) -* Update QD and documentation (`#23 `__) -* Contributors: Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michael Jeronimo, Michel Hidalgo, Scott K Logan, Stephen Brawner, shonigmann, y-okumura-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Refactor to use DDS standard API (`#518 `__) -* Unique network flows (`#502 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#520 `__) -* Add RMW function to check QoS compatibility (`#511 `__) -* Capture cdr exceptions (`#505 `__) -* Load profiles based on topic names (`#335 `__) -* Set rmw_dds_common::GraphCache callback after init succeeds. (`#496 `__) -* Handle typesupport errors on fetch. (`#495 `__) -* Check for correct context shutdown (`#486 `__) -* New environment variable to change easily the publication mode (`#470 `__) -* Discriminate when the Client has gone from when the Client has not completely matched (`#467 `__) * Workaround when the client is gone before server sends response * Change add to the map to listener callback -* Update the package.xml files with the latest Open Robotics maintainers (`#459 `__) -* Update Quality Declarations and READMEs (`#455 `__) * Add QD links for dependencies to rmw_fastrtps_cpp QD * Provide external dependencies QD links * Update rmw_fastrtps README to use Fast DDS * Update rmw_fastrtps_cpp QD: Fast DDS & unit test * Update README rmw_fastrtps_cpp to QL2 -* Perform fault injection in all creation/destruction APIs. (`#453 `__) -* Ensure rmw_destroy_node() completes despite run-time errors. (`#458 `__) -* Update rmw_fastrtps_cpp and rmw_fastrtps_shared_cpp QDs to QL2. (`#456 `__) -* Return RMW_RET_UNSUPPORTED in rmw_get_serialized_message_size (`#452 `__) -* Updated publisher/subscription allocation and wait set API return codes (`#443 `__) -* Added rmw_logging tests (`#442 `__) -* Make service/client construction/destruction implementation compliant (`#445 `__) -* Make sure type can be unregistered successfully (`#437 `__) -* Add tests for native entity getters. (`#439 `__) -* Avoid deadlock if graph update fails. (`#438 `__) -* Call Domain::removePublisher while failure occurs in create_publisher (`#434 `__) -* Ensure compliant matched pub/sub count API. (`#424 `__) -* Ensure compliant publisher QoS queries. (`#425 `__) -* Ensure compliant subscription API. (`#419 `__) -* Ensure compliant publisher API. (`#414 `__) -* Set context actual domain id (`#410 `__) -* Ensure compliant node construction/destruction API. (`#408 `__) -* Remove domain_id and localhost_only from node API (`#407 `__) -* Amend rmw_init() implementation: require enclave. (`#406 `__) -* Update Quality Declarations to QL3. (`#404 `__) -* Ensure compliant init/shutdown API implementation. (`#401 `__) -* Update Quality Declaration to QL3. (`#403 `__) -* Finalize context iff shutdown. (`#396 `__) -* Make service wait for response reader (`#390 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Eduardo Ponz Segrelles, Ignacio Montesino Valle, Ivan Santiago Paunovic, JLBuenoLopez-eProsima, Jacob Perron, Jaime Martin Losa, José Luis Bueno López, Michael Jeronimo, Michel Hidalgo, Miguel Company, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_dynamic_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Refactor to use DDS standard API (`#518 `__) -* Unique network flows (`#502 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#520 `__) -* Add RMW function to check QoS compatibility (`#511 `__) -* Capture cdr exceptions (`#505 `__) -* Load profiles based on topic names in rmw_fastrtps_dynamic_cpp (`#497 `__) -* Set rmw_dds_common::GraphCache callback after init succeeds. (`#496 `__) -* Handle typesupport errors on fetch. (`#495 `__) -* Check for correct context shutdown (`#486 `__) -* New environment variable to change easily the publication mode (`#470 `__) -* Discriminate when the Client has gone from when the Client has not completely matched (`#467 `__) * Workaround when the client is gone before server sends response * Change add to the map to listener callback -* Update the package.xml files with the latest Open Robotics maintainers (`#459 `__) -* Update Quality Declarations and READMEs (`#455 `__) * Add QL of external dependencies to rmw_fastrtps_dynamic_cpp QD * Add QD links for dependencies to rmw_fastrtps_dynamic_cpp QD * Provide external dependencies QD links * Add README to rmw_fastrtps_dynamic * Add QD for rmw_fastrtps_dynamic -* Ensure rmw_destroy_node() completes despite run-time errors. (`#458 `__) -* Return RMW_RET_UNSUPPORTED in rmw_get_serialized_message_size (`#452 `__) -* Updated publisher/subscription allocation and wait set API return codes (`#443 `__) -* Added rmw_logging tests (`#442 `__) -* Fix array ``get_function`` semantics (`#448 `__) -* Make service/client construction/destruction implementation compliant (`#445 `__) -* Make sure type can be unregistered successfully (`#437 `__) -* Add tests for native entity getters. (`#439 `__) -* Avoid deadlock if graph update fails. (`#438 `__) -* Call Domain::removePublisher while failure occurs in create_publisher (`#434 `__) -* Avoid memory leaks and undefined behavior in rmw_fastrtps_dynamic_cpp typesupport code (`#429 `__) -* Ensure compliant matched pub/sub count API. (`#424 `__) -* Ensure compliant publisher QoS queries. (`#425 `__) -* Ensure compliant subscription API. (`#419 `__) -* Ensure compliant publisher API. (`#414 `__) -* Set context actual domain id (`#410 `__) -* Ensure compliant node construction/destruction API. (`#408 `__) -* Remove domain_id and localhost_only from node API (`#407 `__) -* Amend rmw_init() implementation: require enclave. (`#406 `__) -* Ensure compliant init/shutdown API implementation. (`#401 `__) -* Finalize context iff shutdown. (`#396 `__) -* Make service wait for response reader (`#390 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Eduardo Ponz Segrelles, Ignacio Montesino Valle, Ivan Santiago Paunovic, JLBuenoLopez-eProsima, Jacob Perron, Jaime Martin Losa, José Luis Bueno López, Michael Jeronimo, Michel Hidalgo, Miguel Company, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_shared_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Refactor to use DDS standard API (`#518 `__) -* Unique network flows (`#502 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#520 `__) -* Take and return new RMW_DURATION_INFINITE correctly (`#515 `__) -* Add RMW function to check QoS compatibility (`#511 `__) -* Capture cdr exceptions (`#505 `__) -* Make sure to lock the mutex protecting client_endpoints\_. (`#492 `__) -* Use interface whitelist for localhost only (`#476 `__) -* Make use of error return value in decrement_context_impl_ref_count (`#488 `__) -* Remove unnecessary includes (`#487 `__) -* Use new time_utils function to limit rmw_time_t values to 32-bits (`#485 `__) -* New environment variable to change easily the publication mode (`#470 `__) -* Remove unused headers MessageTypeSupport.hpp and ServiceTypeSupport.hpp (`#481 `__) -* Discriminate when the Client has gone from when the Client has not completely matched (`#467 `__) * Workaround when the client is gone before server sends response * Change add to the map to listener callback -* Update the package.xml files with the latest Open Robotics maintainers (`#459 `__) -* Update Quality Declarations and READMEs (`#455 `__) * Add QD links for dependencies to rmw_fastrtps_shared_cpp QD. * Provide external dependencies QD links. * Update rmw_fastrtps_shared_cpp QD: Fast DDS * Update README rmw_fastrtps_shared_cpp to QL2 -* Perform fault injection in all creation/destruction APIs. (`#453 `__) -* Ensure rmw_destroy_node() completes despite run-time errors. (`#458 `__) -* Handle too large QoS queue depths. (`#457 `__) -* Update rmw_fastrtps_cpp and rmw_fastrtps_shared_cpp QDs to QL2. (`#456 `__) -* checked client implementation and return RMW_RET_INCORRECT_RMW_IMPLEMENTATION (`#451 `__) -* Update service/client request/response API error returns (`#450 `__) -* Updated publisher/subscription allocation and wait set API return codes (`#443 `__) -* Added rmw_logging tests (`#442 `__) -* Add tests for RMW QoS to DDS attribute conversion. (`#449 `__) -* Make service/client construction/destruction implementation compliant (`#445 `__) -* Inject faults on __rmw_publish() and run_listener_thread() call. (`#441 `__) -* Update gid API return codes. (`#440 `__) -* Update graph API return codes. (`#436 `__) -* Update rmw_take_serialized() and rmw_take_with_message_info() error returns (`#435 `__) -* Update rmw_take() error returns (`#432 `__) -* Update rmw_publish() error returns (`#430 `__) -* Update rmw_publish_serialized_message() error returns (`#431 `__) -* Improve __rmw_create_wait_set() implementation. (`#427 `__) -* Ensure compliant matched pub/sub count API. (`#424 `__) -* Ensure compliant publisher QoS queries. (`#425 `__) -* Fix memory leak that wait_set might be not destoryed in some case. (`#423 `__) -* Avoid unused identifier variable warnings. (`#422 `__) -* Fix trying to get topic data that was already removed. (`#417 `__) -* Ensure compliant subscription API. (`#419 `__) -* Use package path to TypeSupport.hpp headers in ServiceTypeSupport and MessageTypeSupport (`#415 `__) Use package in path to TypeSupport header for ServiceTypeSupport/MessageTypeSupport -* Ensure compliant publisher API. (`#414 `__) -* Set context actual domain id (`#410 `__) -* Add missing thread-safety annotation in ServicePubListener (`#409 `__) -* Ensure compliant node construction/destruction API. (`#408 `__) -* Update Quality Declarations to QL3. (`#404 `__) -* Do not use string literals as implementation identifiers in tests. (`#402 `__) -* Ensure compliant init options API implementations. (`#399 `__) -* Finalize context iff shutdown. (`#396 `__) -* Handle RMW_DEFAULT_DOMAIN_ID. (`#394 `__) -* Make service wait for response reader (`#390 `__) -* Contributors: Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, JLBuenoLopez-eProsima, Jacob Perron, Jaime Martin Losa, Jose Luis Rivero, Jose Tomas Lorente, José Luis Bueno López, Lobotuerk, Michael Jeronimo, Michel Hidalgo, Miguel Company, Stephen Brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Unique network flows (`#170 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#185 `__) -* Remove rmw_connext_cpp. (`#183 `__) -* Add support for rmw_connextdds (`#182 `__) -* Add function for checking QoS profile compatibility (`#180 `__) -* Shorten some excessively long lines of CMake (`#179 `__) -* Add rmw_fastrtps_dynamic_cpp to the explicit group deps (`#177 `__) -* Accept any RMW implementation, not just the default (`#172 `__) -* Defer path resolution of rmw implementation libraries to dynamic linker. (`#169 `__) -* Update QD to QL 1 (`#166 `__) -* Fix up C functions to never throw. (`#149 `__) -* Restored Dirk as author (`#155 `__) -* Update maintainers (`#154 `__) -* Updated performance QD section (`#153 `__) -* Update Quality Declaration to QL2. (`#151 `__) -* Add nominal test for symbol prefetch() and unload. (`#145 `__) -* Added benchmark test to rmw_implementation (`#127 `__) -* Test load and lookup functionality. (`#135 `__) -* Remove domain_id and localhost_only from node API (`#114 `__) -* Move the quality declaration into the rmw_implementation subdirectory. (`#111 `__) -* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Andrea Sorbini, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Scott K Logan, Stephen Brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Shorten some excessively long lines of CMake (`#300 `__) -* Change default RMW vendor to CycloneDDS. (`#293 `__) -* Update rmw QD to QL 1 (`#289 `__) -* Update maintainers (`#282 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Scott K Logan, Stephen Brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`robot_state_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Stop rejecting unknown parameters. (`#161 `__) -* clean up license to be standard bsd 3 clause (`#130 `__) -* Update the maintainers. (`#151 `__) -* fix types in range loops to avoid copy due to different type (`#143 `__) -* Make sure not to crash on an invalid URDF. (`#141 `__) -* Don't export exe as library (`#25 `__) (`ros2 #28 `__) -* Contributors: Chris Lalancette, Dirk Thomas, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros1_bridge `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix logging for updated rclcpp interface (`#303 `__) -* Fix typo in comments (`#297 `__) -* Update to use rosidl_parser and .idl files rather than rosidl_adapter and .msg files (`#296 `__) -* Update maintainers (`#286 `__) -* use hardcoded QoS (keep all, transient local) for /tf_static topic in dynamic_bridge (`#282 `__) -* document explicitly passing the topic type to 'ros2 topic echo' (`#279 `__) -* Fix multiple definition if message with same name as service exists (`#272 `__) -* Contributors: Dirk Thomas, Jacob Perron, Michael Carroll, Vicidel, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* /clock publisher in Player (`#695 `__) -* Introducing Reindexer CLI (`#699 `__) -* rosbag2_py pybind wrapper for "record" - remove rosbag2_transport_py (`#702 `__) -* Add rosbag2_py::Player::play to replace rosbag2_transport_python version (`#693 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* use rosbag2_py for ros2 bag info (`#673 `__) -* CLI query rosbag2_py for available storage implementations (`#659 `__) -* Recorder --regex and --exclude options (`#604 `__) -* Fix the tests on cyclonedds by translating qos duration values (`#606 `__) -* SQLite storage optimized by default (`#568 `__) -* Fix a bug on parsing wrong description in plugin xml file (`#578 `__) -* Compress bag files in separate threads (`#506 `__) -* Sqlite storage double buffering (`#546 `__) * Double buffers * Circular queue and FLUSH option as define * Minor naming and lexical fixes. * Removed FLUSH_BUFFERS define check. * Sqlite3 storage logging fixes. * Sqlite3 storage circular buffer with pre allocated memory. * Sqlite3 storage buffers moved to shared_ptrs. * Uncrustify * Moved double buffers to writer * Buffer layer reset in seq compression writer in rosbag2 cpp * Buffer layer for rosbag2 writer refactor * Changed buffers in BufferLayer to std vectors. * BufferLayer uncrustify * Removed non-applicable test for writer cache. * BufferLayer review fixes * Rosbag metadata msgs count fixed for BufferLayer * Condition variable for buffer layer sync. * Fixed buffer locks * Buffers in BufferLayer refactored, moved into new class * Buffer layer split bags fixed. * Storage options include fix in buffer layer header. * Mutex around swapping buffers in buffer layer. * Fixed cache 0 bug in buffer layer. * Minor buffer layer refactor. * Counting messages in writer refactored. * Changed default cache size to 100Mb and updated parameter description * Applied review remarks: - significant refactoring: separation of cache classes - applied suggested improvements - some renaming - reduce code duplication that would otherwise increase with cache refactor, between compression and plain writers * Applied review comments - cache consumer now takes a callback and is independent of storage - namespace changes, renaming, cleaning - counting and logging messages by topic * linter * Changes after review: fixing flushing, topic counts, and more * Fix for splitting - flushing state now correctly turns off * cache classes documentation * simplified signature * a couple of tests for cache * address review: explicit constructor and doxygen styling * Windows warnings fix * fixed type mismatch warning on Windows * added minor comment Co-authored-by: Piotr Jaroszek -* read yaml config file (`#497 `__) -* List all storage plugins in plugin xml file (`#554 `__) -* add storage_config_uri (`#493 `__) -* Update deprecated qos policy value names (`#548 `__) -* Add record test for ros2bag (`#523 `__) -* Removed duplicated code in record (`#534 `__) -* Change default cache size for sequential_writer to a non zero value (`#533 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* [ros2bag test_record] Gets rid of time.sleep and move to using command.wait_for_output (`#525 `__) -* Add pytest.ini back to ros2bag. (`#492 `__) -* performance testing packages (`#442 `__) -* Validate QoS profile values are not negative. (`#483 `__) -* catch parent exception (`#472 `__) -* add wait for closed file handles on Windows (`#470 `__) -* introduce ros2 bag list (`#468 `__) -* move wait_for_shutdown() call out of the context manager (`#466 `__) -* Adding db directory creation to rosbag2_cpp (`#450 `__) -* use a single temp dir for the test class (`#462 `__) -* Add per-message ZSTD compression (`#418 `__) -* Add split by time to recording (`#409 `__) -* Add pytest.ini so local tests don't display warning (`#446 `__) -* Contributors: Adam Dąbrowski, Barry Xu, Chris Lalancette, Dirk Thomas, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jaison Titus, Jesse Ikawa, Karsten Knese, Marwan Taher, Michael Jeronimo, P. J. Reed, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Ensure only one daemon can run at a time. (`#622 `__) -* Remove maintainer. (`#597 `__) -* Add option to support use_sim_time. (`#581 `__) -* Bugfix for `#563 `__. (`#570 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Support Python 3.8-provided importlib.metadata. (`#585 `__) -* Update maintainers. (`#568 `__) -* Added dependency to python3-argcomplete to ros2cli. (`#564 `__) -* Remove use of pkg_resources from ros2cli. (`#537 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Daisuke Sato, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, Tomoya Fujita, Yoan Mollard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli_common_extensions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* remove maintainer (`#5 `__) -* update maintainer (`#4 `__) -* First implementation (`#2 `__) -* Contributors: Bo Sun, Claire Wang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli_test_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Make ros2cli_test_interfaces version equal to other packages. -* Remove ros2interface test dependencies on builtin interface. (`#579 `__) -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2component `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Ensure consistent timeout in ros2component list. (`#526 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2doctor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve ros2 doctor on Windows. (`#631 `__) (`#634 `__) -* Add changelog. (`#636 `__) -* Continue to next iteration after exceptions in generate_reports. (`#623 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Support Python 3.8-provided importlib.metadata. (`#585 `__) -* Update maintainers. (`#568 `__) -* Remove pkg_resources from ros2doctor. (`#537 `__) -* Make ros2doctor depend on ros_environment and fix platform.py bug on error. (`#538 `__) -* Refactor ros2doctor hello verb. (`#521 `__) -* Contributors: Alberto Soragna, Audrow Nash, Chris Lalancette, Claire Wang, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Remove ros2interface test dependencies on builtin interface. (`#579 `__) -* Update maintainers. (`#568 `__) -* Handle inline comments on constants correctly. (`#548 `__) -* Update quoted comments in the test (`#540 `__) -* Add option to include/remove whitespace and comments. (`#527 `__) -* Show "expanded" message definition. (`#524 `__) -* Contributors: Audrow, Audrow Nash, Claire Wang, Ivan Santiago Paunovic, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add options extensions to ros2launch and extensibility to the node action (`#216 `__) -* Support non-interactive ros2 launch executions (`#210 `__) -* Merge pull request `#183 `__ from ros2/update-maintainers -* Move previous maintainer to -* Update the package.xml files with the latest Open Robotics maintainers -* Add pytest.ini so local tests don't display warning (`#152 `__) -* Contributors: Chris Lalancette, Geoffrey Biggs, Michael Jeronimo, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle_test_fixtures `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Depend on rclcpp::rclcpp target. (`#618 `__) Contributors: Audrow Nash -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2multicast `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2node `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2param `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Make the ros2param --filter test more reliable. (`#606 `__) -* Add wildcard loading to ros2 param load. (`#602 `__) -* Ros2 param dump/load should use fully qualified node names. (`#600 `__) -* Add --filter options for 'ros2 param list'. (`#592 `__) -* Remove maintainer. (`#597 `__) -* Add rosparam verb load. (`#590 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Add "--param-type" option to ros2param list. (`#572 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic, Victor Lopez, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2pkg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Use underscores in setup.cfg.em instead of dashes. (`#627 `__) -* Add space for "ROS 2". (`#617 `__) -* Use target_compile_features for c/c++ standards. (`#615 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Declare missing dependency on python3-importlib-resources. (`#584 `__) -* Update maintainers. (`#568 `__) -* Fix incorrect EXPORT for executables. (`#545 `__) -* Switch ros2pkg to using importlib. -* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, Ivan Santiago Paunovic, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2run `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Remove maintainer. (`#597 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Update maintainers. (`#568 `__) -* Check that passed type is actually a service. (`#559 `__) -* Contributors: Audrow Nash, Claire Wang, Dirk Thomas, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add pytest.ini so local tests don't display warning (`#8 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog. (`#636 `__) -* Add verbose info for topic list. (`#351 `__) -* Remove maintainer. (`#597 `__) -* Add option to support use_sim_time. (`#581 `__) -* Add Audrow as a maintainer. (`#591 `__) -* Add filter option to ros2topic . (`#575 `__) -* Update deprecated qos policy value names. (`#571 `__) -* Update maintainers. (`#568 `__) -* Fix the test to use the topic name. (`#566 `__) -* Improve the error message for invalid message types. (`#558 `__) -* Use reliable QoS for ros2topic tests. (`#555 `__) -* Add option to echo serialized messages. (`#470 `__) -* Enable --no-daemon flag for some cli tools. (`#514 `__) -* Use transient_local and longer keep-alive for pub tests. (`#546 `__) -* Add --keep-alive option to 'topic pub'. (`#544 `__) -* Add option to ros2 topic echo to report lost messages. (`#542 `__) -* Support QoS Depth and History via ros2 topic pub/echo. (`#528 `__) -* Contributors: Audrow Nash, ChenYing Kuo, Chris Lalancette, Claire Wang, Dereck Wonnacott, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Scott K Logan, Tomoya Fujita, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use rostest CMake target as output file basename. (`#9 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly add emersonknapp as maintainer (`#692 `__) -* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) -* Move zstd compressor to its own package (`#636 `__) -* add storage_config_uri (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* AMENT_IGNORE rosbag2_py for now (`#509 `__) -* rosbag2_py reader and writer (`#308 `__) -* Contributors: Emerson Knapp, Karsten Knese, Mabel Zhang, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. -* CLI query rosbag2_py for available storage implementations (`#659 `__) -* Move zstd compressor to its own package (`#636 `__) -* Remove rosbag2_compression test dependencies on zstd implementation in prep for moving it into a separate package (`#637 `__) -* Make compressor implementations into a plugin via pluginlib (`#624 `__) -* Use ZSTD's streaming interface for [de]compressing files (`#543 `__) -* Fix build issues when rosbag2_storage is binary installed (`#585 `__) -* Fix relative metadata paths in SequentialCompressionWriter (`#613 `__) -* Fix deadlock race condition on compression shutdown (`#616 `__) -* Deduplicate SequentialCompressionReader business logic, add fallback to find bagfiles in incorrectly-written metadata (`#612 `__) -* Compress bag files in separate threads (`#506 `__) -* Sqlite storage double buffering (`#546 `__) -* add storage_config_uri (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Do not expect empty StorageOptions URI to work in CompressionWriterTest (`#526 `__) -* Remove some code duplication between SequentialWriter and SequentialCompressionWriter (`#527 `__) -* Fix exception thrown given invalid arguments with compression enabled (`#488 `__) -* Adding db directory creation to rosbag2_cpp (`#450 `__) -* Consolidate ZSTD utility functions (`#459 `__) -* Add per-message ZSTD compression (`#418 `__) -* Contributors: Adam Dąbrowski, Christophe Bedard, Devin Bonnie, Emerson Knapp, Jaison Titus, Karsten Knese, Marwan Taher, Michael Jeronimo, P. J. Reed, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression_zstd `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_depend ament_cmake_gmock (`#639 `__) -* Move zstd compressor to its own package (`#636 `__) -* Contributors: Emerson Knapp, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add set_rate to PlayerClock (`#727 `__) -* Enforce non-null now_fn in TimeControllerClock (`#731 `__) -* Fix pause snapshot behavior and add regression test (`#730 `__) -* Pause/resume PlayerClock (`#704 `__) -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* Enable thread safety analysis for rosbag2_cpp and add annotations in TimeControllerClock (`#710 `__) -* PlayerClock initial implementation - Player functionally unchanged (`#689 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. -* use rclcpp serialized messages to write data (`#457 `__) -* alternative write api (`#676 `__) -* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) -* CLI query rosbag2_py for available storage implementations (`#659 `__) -* Fix --topics flag for ros2 bag play being ignored for all bags after the first one. (`#619 `__) -* Fix a crash in test_message_cache. (`#635 `__) -* Fix build issues when rosbag2_storage is binary installed (`#585 `__) -* Deduplicate SequentialCompressionReader business logic, add fallback to find bagfiles in incorrectly-written metadata (`#612 `__) -* include what you use (`#600 `__) -* Only dereference the data pointer if it is valid. (`#581 `__) -* Add back rosbag2_cpp::StorageOptions as deprecated (`#563 `__) -* Sqlite storage double buffering (`#546 `__) -* correct master build (`#552 `__) -* add storage_config_uri (`#493 `__) -* Mutex around writer access in recorder (`#491 `__) -* if cache data exists, it needs to flush the data into the storage before shutdown (`#541 `__) -* Change default cache size for sequential_writer to a non zero value (`#533 `__) -* SequentialWriter to cache by message size instead of message count (`#530 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Remove some code duplication between SequentialWriter and SequentialCompressionWriter (`#527 `__) -* disable sanitizer by default (`#517 `__) -* Fix typo in error message (`#475 `__) -* introduce defaults for the C++ API (`#452 `__) -* Adding db directory creation to rosbag2_cpp (`#450 `__) -* comment out unused variable (`#460 `__) -* minimal c++ API test (`#451 `__) -* Add split by time to recording (`#409 `__) -* Contributors: Adam Dąbrowski, Alexander, Chris Lalancette, Dirk Thomas, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jaison Titus, Karsten Knese, Marwan Taher, Michael Jeronimo, P. J. Reed, Patrick Spieler, Tomoya Fujita, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add rosbag2_interfaces package with playback service definitions (`#728 `__) -* Contributors: Emerson Knapp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_performance_benchmarking `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fixed a memory leak in no-transport benchmark (`#674 `__) -* report of performance improvements in rosbag2 (roughly since Foxy) (`#651 `__) -* Performance benchmarking improvements (`#634 `__) -* Performance benchmarking refactor (`#594 `__) -* Sqlite storage double buffering (`#546 `__) -* read yaml config file (`#497 `__) -* add storage_config_uri (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* performance testing packages (`#442 `__) -* Contributors: Adam Dąbrowski, Karsten Knese, Michael Jeronimo, Piotr Jaroszek - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* Split Rosbag2Transport into Player and Recorder classes - first pass to enable further progress (`#721 `__) -* /clock publisher in Player (`#695 `__) -* Introducing Reindexer CLI (`#699 `__) -* Fix rosbag2_py transport test for py capsule (`#707 `__) -* rosbag2_py pybind wrapper for "record" - remove rosbag2_transport_py (`#702 `__) -* Add rosbag2_py::Player::play to replace rosbag2_transport_python version (`#693 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) -* use rosbag2_py for ros2 bag info (`#673 `__) -* CLI query rosbag2_py for available storage implementations (`#659 `__) -* Fix build issues when rosbag2_storage is binary installed (`#585 `__) -* Fix the tests on cyclonedds by translating qos duration values (`#606 `__) -* add storage_config_uri (`#493 `__) -* Workaround pybind11 bug on Windows when CMAKE_BUILD_TYPE=RelWithDebInfo (`#538 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Fix rosbag2_py on Windows debug and stop ignoring the package (`#531 `__) -* Fix rosbag2_py bug when using libc++ (`#529 `__) -* AMENT_IGNORE rosbag2_py for now (`#509 `__) -* rosbag2_py reader and writer (`#308 `__) -* Contributors: Emerson Knapp, Ivan Santiago Paunovic, Karsten Knese, Mabel Zhang, Michael Jeronimo, P. J. Reed, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* PlayerClock initial implementation - Player functionally unchanged (`#689 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. -* Remove outdated pluginlib cmake script from rosbag2_storage (`#661 `__) -* CLI query rosbag2_py for available storage implementations (`#659 `__) -* Shorten some excessively long lines of CMake (`#648 `__) -* SQLite storage optimized by default (`#568 `__) * Use optimized pragmas by default in sqlite storage. Added option to use former behavior -* Use std::filesystem compliant non-member ``exists`` function for path object (`#593 `__) -* Update codes since rcutils_calculate_directory_size() is changed (`#567 `__) -* add storage_config_uri (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Add split by time to recording (`#409 `__) -* Contributors: Adam Dąbrowski, Barry Xu, Emerson Knapp, Josh Langsfeld, Karsten Knese, Michael Jeronimo, Scott K Logan, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. -* Fix build issues when rosbag2_storage is binary installed (`#585 `__) -* Mutex protection for db writing and stl collections in writer & storage (`#603 `__) -* SQLite storage optimized by default (`#568 `__) -* read yaml config file (`#497 `__) -* add storage_config_uri (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Contributors: Adam Dąbrowski, Emerson Knapp, Karsten Knese, Michael Jeronimo, P. J. Reed, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* Fix bad_function_call by replacing rclcpp::spin_some with SingleThreadedExecutor (`#705 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Remove temporary directory platform-specific logic from test fixture (`#660 `__) -* Stabilize test_record by reducing copies of executors and messages (`#576 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Contributors: Emerson Knapp, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. -* use rclcpp serialized messages to write data (`#457 `__) -* Alternative write api (`#676 `__) -* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) -* Use rosbag2_py for ros2 bag info (`#673 `__) -* Remove temporary directory platform-specific logic from test fixture (`#660 `__) -* Fix --topics flag for ros2 bag play being ignored for all bags after the first one. (`#619 `__) -* Move zstd compressor to its own package (`#636 `__) -* Fix relative metadata paths in SequentialCompressionWriter (`#613 `__) -* Recorder --regex and --exclude options (`#604 `__) -* Fix the tests on cyclonedds by translating qos duration values (`#606 `__) -* add storage_config_uri (`#493 `__) -* Removed duplicated code in record (`#534 `__) -* Change default cache size for sequential_writer to a non zero value (`#533 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Mark flaky tests as xfail for now (`#520 `__) -* introduce defaults for the C++ API (`#452 `__) -* Adding db directory creation to rosbag2_cpp (`#450 `__) -* minimal c++ API test (`#451 `__) -* Add split by time to recording (`#409 `__) -* Contributors: Adam Dąbrowski, Alexander, Emerson Knapp, Jaison Titus, Karsten Knese, Marwan Taher, Michael Jeronimo, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* cleanup cmakelists (`#726 `__) -* turn recorder into a node (`#724 `__) -* turn player into a node (`#723 `__) -* Remove -Werror from builds, enable it in Action CI (`#722 `__) -* Split Rosbag2Transport into Player and Recorder classes - first pass to enable further progress (`#721 `__) -* /clock publisher in Player (`#695 `__) -* use rclcpp logging macros (`#715 `__) -* use rclcpp::Node for generic pub/sub (`#714 `__) -* PlayerClock initial implementation - Player functionally unchanged (`#689 `__) -* Fix bad_function_call by replacing rclcpp::spin_some with SingleThreadedExecutor (`#705 `__) -* rosbag2_py pybind wrapper for "record" - remove rosbag2_transport_py (`#702 `__) -* Add rosbag2_py::Player::play to replace rosbag2_transport_python version (`#693 `__) -* Fix and clarify logic in test_play filter test (`#690 `__) -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Add QoS decoding translation for infinite durations to RMW_DURATION_INFINITE (`#684 `__) -* Add support for rmw_connextdds (`#671 `__) -* Use rosbag2_py for ros2 bag info (`#673 `__) -* Fix build issues when rosbag2_storage is binary installed (`#585 `__) -* Regex and exclude fix for rosbag recorder (`#620 `__) -* Recorder --regex and --exclude options (`#604 `__) -* SQLite storage optimized by default (`#568 `__) -* Fixed playing if unknown message types exist (`#592 `__) -* Compress bag files in separate threads (`#506 `__) -* Stabilize test_record by reducing copies of executors and messages (`#576 `__) -* add storage_config_uri (`#493 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* resolve memory leak for serialized message (`#502 `__) -* Use shared logic for importing the rosbag2_transport_py library in Python (`#482 `__) -* fix missing target dependencies (`#479 `__) -* reenable cppcheck for rosbag2_transport (`#461 `__) -* More reliable topic remapping test (`#456 `__) -* Add split by time to recording (`#409 `__) -* export shared_queues_vendor (`#434 `__) -* Contributors: Adam Dąbrowski, Andrea Sorbini, Chen Lihui, Dirk Thomas, Emerson Knapp, Karsten Knese, Michael Jeronimo, P. J. Reed, Piotr Jaroszek, jhdcs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosgraph_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#122 `__) -* Updating Quality Declaration (`#120 `__) -* Update README.md (`#119 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_adapter `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose .msg/.srv/.action to .idl conversion via rosidl translate CLI (`#576 `__) -* Support hex constants in msg files (`#559 `__) -* Treat \t as whitespace (`#557 `__) -* Update the maintainers of this repository. (`#536 `__) -* Refactor regex for valid package/field names (`#508 `__) -* Add pytest.ini so tests succeed locally (`#502 `__) -* Contributors: Chris Lalancette, Dereck Wonnacott, Dirk Thomas, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Align rosidl_cli package version with the rest of the repo. (`#579 `__) -* Expose an API for each rosidl CLI command. (`#577 `__) -* Add rosidl translate CLI. (`#575 `__) -* Add rosidl generate CLI. (`#567 `__) -* Contributors: Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Shorten some excessively long lines of CMake (`#571 `__) -* Update the maintainers of this repository. (`#536 `__) -* Modifications to python generator lib to return generated files (`#511 `__) -* Contributors: Alex Tyshka, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_generators `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#13 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_runtime `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#18 `__) -* Update QD to QL 1 (`#15 `__) -* Update maintainers (`#13 `__) -* Updated QD to 2 in README.md (`#12 `__) -* Update rosidl_default_runtime QD to QL2. (`#11 `__) -* Bump the QUALITY_DECLARATION to level 3. (`#10 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#9 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Shane Loretz, Stephen Brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose C code generation via rosidl generate CLI (`#569 `__) -* Strip action service suffixes from C include prefix (`#538 `__) -* Update the maintainers of this repository. (`#536 `__) -* Fix the declared language for a few packages (`#530 `__) -* Do not depend on rosidl_runtime_c when tests are disabled (`#503 `__) -* Contributors: Ben Wolsieffer, Chris Lalancette, Jacob Perron, Michel Hidalgo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose C++ code generation via rosidl generate CLI (`#570 `__) -* Switch to std::allocator_traits. (`#564 `__) -* Remove unnecessary assert on pointer created with new (`#555 `__) -* Use ASSERT_TRUE to check for nullptr. (`#543 `__) -* Update the maintainers of this repository. (`#536 `__) -* Add to_yaml() function for C++ messages (`#527 `__) -* Add function for getting a types fully qualified name (`#514 `__) -* Declaring is_message in namespace rosidl_generator_traits (`#512 `__) -* Contributors: Chris Lalancette, Devin Bonnie, Dirk Thomas, Jacob Perron, Michel Hidalgo, Sebastian Höffner, Stephen Brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_dds_idl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose .idl to DDS .idl conversion via rosidl translate CLI. (`#55 `__) -* Update maintainers. (`#54 `__) -* Contributors: Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove dependency from rosidl_typesupport_connext_c (`#127 `__) -* Expose Python code generation via rosidl generate CLI (`#123 `__) -* remove maintainer (`#126 `__) -* Update maintainers (`#119 `__) -* Fix too early decref of WString when converting from Python to C (`#117 `__) -* Add pytest.ini so tests succeed locally. (`#116 `__) -* Contributors: Andrea Sorbini, Chris Lalancette, Claire Wang, Dirk Thomas, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update and add package.xml descriptions to README (`#553 `__) -* Finish support for fixed-point literals. -* Fix parsing of small floats. -* Update the maintainers of this repository. (`#536 `__) -* Allow zero length string constants (`#507 `__) -* Add pytest.ini so tests succeed locally (`#502 `__) -* Contributors: Chris Lalancette, Dirk Thomas, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#581 `__) -* Shorten some excessively long lines of CMake (`#571 `__) -* Update and add package.xml descriptions to README (`#553 `__) -* Fix item number in QD (`#546 `__) -* Update the maintainers of this repository. (`#536 `__) -* Add rcutils dependency. (`#534 `__) -* QD: Add links to hosted API docs (`#533 `__) -* Updated Quality Level to 1 (`#532 `__) -* Add benchmarks for rosidl_runtime\_* packages (`#521 `__) -* Fix the declared language for a few packages (`#530 `__) -* Add fault injection macros and test (`#509 `__) -* Update rosidl_runtime_c QD to QL 2 (`#500 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Louise Poubel, Scott K Logan, Shane Loretz, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#581 `__) -* Fix typo of package name in README heading (`#561 `__) -* Update and add package.xml descriptions to README (`#553 `__) -* Fix item number in QD (`#546 `__) -* Update the maintainers of this repository. (`#536 `__) -* QD: Add links to hosted API docs (`#533 `__) -* Updated Quality Level to 1 (`#532 `__) -* Add benchmarks for rosidl_runtime\_* packages (`#521 `__) -* Add to_yaml() function for C++ messages (`#527 `__) -* Add function for getting a types fully qualified name (`#514 `__) -* Fix misuses of input iterators in BoundedVector (`#493 `__) -* Update QD to reflect QL 2 statuses (`#499 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Devin Bonnie, Dirk Thomas, Jacob Perron, Jonathan Wakely, Louise Poubel, Scott K Logan, Shane Loretz, Stephen Brawner, Tully Foote, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add pytest.ini so local tests don't display warning (`#12 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#108 `__) -* Remove dependencies from Connext type support (`#106 `__) -* Expose C typesupport generation via rosidl generate CLI (`#105 `__) -* Typo typesupport_identidentifier (`#103 `__) -* Remove type_support_dispatch.cpp files. (`#101 `__) -* Defer path resolution of rosidl typesupport libraries to dynamic linker. (`#98 `__) -* Ensure typesupport handle functions do not throw. (`#99 `__) -* Explicitly check lib pointer for null (`#95 `__) -* Update Quality Declaration to QL 1 (`#96 `__) -* Add mock for rcutils_get_symbol failure (`#93 `__) -* Update the maintainers (`#89 `__) -* Catch exception from has_symbol (`#86 `__) -* Added benchmark test to rosidl_typesupport_c/cpp (`#84 `__) -* Handle rcpputils::find_library_path() failure (`#85 `__) -* Add fault injection macros and unit tests (`#80 `__) -* Remove rethrow in extern c code (`#82 `__) -* Add Security Vulnerability Policy pointing to REP-2006 (`#76 `__) -* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Chris Lalancette, Jose Luis Rivero, Jose Tomas Lorente, Louise Poubel, Michel Hidalgo, Shane Loretz, Stephen Brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#108 `__) -* Remove dependencies from Connext type support (`#106 `__) -* Expose C++ typesupport generation via rosidl generate CLI (`#104 `__) -* Remove type_support_dispatch.cpp files. (`#101 `__) -* Defer path resolution of rosidl typesupport libraries to dynamic linker. (`#98 `__) -* Ensure typesupport handle functions do not throw. (`#99 `__) -* Explicitly check lib pointer for null (`#95 `__) -* Update Quality Declaration to QL 1 (`#96 `__) -* Update the maintainers (`#89 `__) -* Added benchmark test to rosidl_typesupport_c/cpp (`#84 `__) -* Handle rcpputils::find_library_path() failure (`#85 `__) -* De-duplicate type_support_map.h header (`#81 `__) -* Add fault injection macros and unit tests (`#80 `__) -* Add Security Vulnerability Policy pointing to REP-2006 (`#76 `__) -* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Chris Lalancette, Jose Luis Rivero, Louise Poubel, Michel Hidalgo, Stephen Brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#69 `__) -* Expose FastRTPS C typesupport generation via rosidl generate CLI (`#65 `__) -* Update QDs with up-to-date content (`#64 `__) -* Fix item number in QD (`#59 `__) -* Update QL to 2 -* Update package maintainers (`#55 `__) -* Updat QD (`#53 `__) -* Fix invalid return on deserialize function (`#51 `__) -* Added benchmark test to rosidl_typesupport_fastrtps_c/cpp (`#52 `__) -* Update exec dependencies (`#50 `__) -* Add Security Vulnerability Policy pointing to REP-2006 (`#44 `__) -* QD Update Version Stability to stable version (`#46 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jorge Perez, Louise Poubel, Michel Hidalgo, Stephen Brawner, shonigmann, sung-goo-kim - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#69 `__) -* Expose FastRTPS C++ typesupport generation via rosidl generate CLI (`#66 `__) -* Update QDs with up-to-date content (`#64 `__) -* Fix item number in QD (`#59 `__) -* Update QL to 2 -* Update package maintainers (`#55 `__) -* Update QD (`#53 `__) -* Add benchmark test to rosidl_typesupport_fastrtps_c/cpp (`#52 `__) -* Update exec dependencies (`#50 `__) -* Add Security Vulnerability Policy pointing to REP-2006 (`#44 `__) -* QD Update Version Stability to stable version (`#46 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jorge Perez, Louise Poubel, Michel Hidalgo, Stephen Brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#581 `__) -* Fix item number in QD (`#546 `__) -* Update the maintainers of this repository. (`#536 `__) -* QD: Add links to hosted API docs (`#533 `__) -* Update Quality Declaration to QL 1 for rosidl_typesupport_interface (`#519 `__) -* Update QD to reflect QL 2 statuses (`#499 `__) -* Contributors: Chris Lalancette, Louise Poubel, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose C introspection typesupport generation via rosidl generate CLI (`#572 `__) -* Update the maintainers of this repository. (`#536 `__) -* Fix get_function and get_const_function semantics for arrays (`#531 `__) -* Fix the declared language for a few packages (`#530 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose C++ introspection typesupport generation via rosidl generate CLI (`#573 `__) -* Update the maintainers of this repository. (`#536 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rpyutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Create a shared function for importing c libraries (`#4 `__) -* Add pytest.ini so local tests don't display warning (`#3 `__) -* Contributors: Chris Lalancette, Emerson Knapp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* 1.0.7 (`#243 `__) -* Remove Dirk from maintainers in package.xml files per request. (`#236 `__) -* Update maintainers for the crystal-devel branch (`#234 `__) -* Contributors: Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated Open Robotics maintainer -* Fixed package to run with ros2 run (`#8 `__) -* Contributors: Alejandro Hernández Cordero, Mabel Zhang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove an invalid import statement (`#101 `__) -* Reset timeline zoom after loading a new bag. (`#98 `__) -* Refactor the Rosbag2 class (`#91 `__) -* Fix exec_depend (`#89 `__) -* Use updated HistoryPolicy values to avoid deprecation warnings (`#88 `__) -* Enable recording for ROS2 (`#87 `__) -* Enable the playback functionality for ROS2 (`#85 `__) -* Port the topic and node selection dialogs to ROS2 (`#86 `__) -* Save the serialization format and offered_qos_profiles when exporting (`#84 `__) -* Enable the export/save bag functionality for ROS2 (`#82 `__) -* Update known message types and associated colors (`#81 `__) -* Open the bag directory instead of a single file (`#80 `__) -* Port the image_view plugin to ROS2 (`#78 `__) -* Clean up widgets in plot_view layout correctly (`#69 `__) (`#77 `__) -* Fix tuples for bisect calls (`#67 `__) (`#76 `__) -* Fix issue: no vertical scroll bar until window is resized (`#63 `__) (`#75 `__) -* Update the basic plugins for ROS2 (`#72 `__) -* Update the rosbag2 python module (`#71 `__) -* Dynamically resize the timeline when recording (`#66 `__) -* Starting point for resuming the ROS2 port (`#70 `__) -* Fix a bug with the status line progress bar (`#62 `__) -* Update a few minor status bar-related items (`#61 `__) -* Make the tree controls in the Raw View and Plot View consistent (`#57 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#58 `__) -* fix Python 3 issue: long/int (`#52 `__) -* save last directory opened to load a bag file (`#40 `__) -* fix shebang line for Python 3 (`#48 `__) -* bump CMake minimum version to avoid CMP0048 warning -* fix Python 3 exception, wrap filter call in list() (`#46 `__) -* add Python 3 conditional dependencies (`#44 `__) -* autopep8 (`#30 `__) -* add support for opening multiple bag files at once (`#25 `__) -* fix debug/warning messages for unicode filenames (`#26 `__) -* fix regression from version 0.4.10 (`#17 `__) -* fix regression from version 0.4.9 (`#16 `__) -* handle errors happening while loading a bag (`#14 `__) -* add rqt_bag.launch file (`#440 `__) -* fix Python 2 regression from version 0.4.4 (`#424 `__) -* use Python 3 compatible syntax (`#421 `__) -* fix race condition reading bag files (`#412 `__) -* add "From nodes" button to record mode (`#348 `__) -* show file size of bag file in the status bar (`#347 `__) -* fix mouse wheel delta in Qt 5 (`#376 `__) -* Support Qt 5 (in Kinetic and higher) as well as Qt 4 (in Jade and earlier) (`#359 `__) -* fix publishing wrong topic after scrolling (`#362 `__) -* RQT_BAG: Ensure monotonic clock publishing. Due to parallelism issues, a message can be published with a simulated timestamp in the past. This lead to undesired behaviors when using TF for example. -* Added step-by-step playback capability -* fix viewer plugin relocation issue (`#306 `__) -* fix topic type retrieval for multiple bag files (`#279 `__) -* fix region_changed signal emission when no start/end stamps are set -* improve right-click menu -* improve popup management (`#280 `__) -* implement recording of topic subsets -* sort the list of topics -* update plugin scripts to use full name to avoid future naming collisions -* fix visibility with dark Qt theme (`#263 `__) -* fix compatibility with Groovy, use queue_size for Python publishers only when available (`#243 `__) -* use thread for loading bag files, emit region changed signal used by plotting plugin (`#239 `__) -* export architecture_independent flag in package.xml (`#254 `__) -* fix closing and reopening topic views -* use queue_size for Python publishers -* fix raw view not showing fields named 'msg' (`#226 `__) -* add option to publish clock tim from bag (`#204 `__) -* add groups for rqt plugins, renamed some plugins (`#167 `__) -* fix high cpu load when idle (`#194 `__) -* update rqt_bag plugin interface to work with qt_gui_core 0.2.18 -* fix rendering of icons on OS X (`ros-visualization/rqt#83 `__) -* fix shutdown of plugin (`#31 `__) -* fix saving parts of a bag (`#96 `__) -* fix long topic names (`#114 `__) -* fix zoom behavior (`#76 `__) -* Fix; skips time when resuming playback (`#5 `__) -* Fix; timestamp printing issue (`#6 `__) -* expose command line arguments to rqt_bag script -* added fix to set play/pause button correctly when fastforwarding/rewinding, adjusted time headers to 0m00s instead of 0:00m for ease of reading -* support passing bagfiles on the command line (currently behind --args) -* first release of this package into Groovy -* Contributors: Aaron Blasdel, Chris Lalancette, Michael Grupp, Michael Jeronimo, lsouchet, sambrose - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Refactor the Rosbag2 class (`#91 `__) -* Port the plot view to ROS2 (`#79 `__) -* Port the image_view plugin to ROS2 (`#78 `__) -* Starting point for resuming the ROS2 port (`#70 `__) -* Make the tree controls in the Raw View and Plot View consistent (`#57 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#58 `__) -* initialize pil_mode when image is compressed (`#54 `__) -* support 16-bit bayer images (`#45 `__) -* maintain image aspect ratio (`#32 `__) -* fix Python 3 issue: long/int (`#51 `__) -* fix Python 3 issue: ensure str is encoded before decoding (`#50 `__) -* bump CMake minimum version to avoid CMP0048 warning -* add Python 3 conditional dependencies (`#44 `__) -* add cairocffi as the fallback module (`#43 `__) -* autopep8 (`#30 `__) -* fix Python 2 regression from version 0.4.4 (`#426 `__) -* use Python 3 compatible syntax (`#421 `__) -* fix crash when toggling thumbnail (`#380 `__) -* lock bag when reading for plotting (`#382 `__) -* Support Qt 5 (in Kinetic and higher) as well as Qt 4 (in Jade and earlier) (`#359 `__) -* add missing dependency on rqt_plot (`#316 `__) -* work around Pillow segfault if PyQt5 is installed (`#289 `__, `#290 `__) -* add displaying of depth image thumbnails -* add missing dependency on python-cairo (`#269 `__) -* fix missing installation of resource subfolder -* add plotting plugin (`#239 `__) -* fix rqt_bag to plot array members (`#253 `__) -* export architecture_independent flag in package.xml (`#254 `__) -* fix PIL/Pillow error (`#224 `__) -* first release of this package into Groovy -* Contributors: John Stechschulte, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores in setup.cfg instead of dashes (`#31 `__) -* Fix regression introduced in `#21 `__ (`#28 `__) -* Changed the build type to ament_python and added setup.cfg (`#21 `__) -* Contributors: Alejandro Hernández Cordero, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_graph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make topics that have qos incompatibilities red in the graph, add information to the node tooltip (`#61 `__) -* Add node name, topic name, and endpoint kind to the qos edge tooltip (`#60 `__) -* Update maintainers for ROS2 branches (`#55 `__) -* add edge tooltip with QoS of publishers and subscribers (`#53 `__) -* install executable rqt_graph (`#49 `__) -* add setup.cfg with script install directories (`#42 `__) -* add pytest.ini so local tests don't display warning (`#48 `__) -* Contributors: Ivan Santiago Paunovic, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* getiterator() renamed to iter() in Python 3.9 (`#239 `__) -* Contributors: goekce - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* use tgt compile features (`#247 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix a crash at shutdown (`#248 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_msg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#8 `__) -* Use rosidl_runtype_py instead of message_helpers where possible (`#11 `__) -* Contributors: Alejandro Hernández Cordero, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_plot `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#58 `__) -* Fix plots of array items (`#71 `__) -* Update maintainers -* Contributors: Alejandro Hernández Cordero, Ivan Santiago Paunovic, Mabel Zhang - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#18 `__) -* Drop numpy.float128 references (`#26 `__) -* Use rosidl_runtime_py instead of rqt_py_common where possible (`#24 `__) -* Add now() to evaluation (`#22 `__) -* fix setting expressions on sequence items (`#16 `__) -* Contributors: Alejandro Hernández Cordero, Ivan Santiago Paunovic, Michel Hidalgo, Yossi Ovcharik - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Avoid installing test interfaces (`#228 `__) -* Contributors: Dirk Thomas - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#8 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_reconfigure `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanups to the install scripts. (`#103 `__) -* Fix a flake8 warning. (`#99 `__) -* Use timeouts in service calls to avoid hangs (`#98 `__) -* Add maintainer to package.xml (`#95 `__) -* Save instance state in rqt settings (`#90 `__) -* Use safe YAML loader (`#89 `__) -* Don't process scroll events unless specifically focused (`#88 `__) -* Fix node selection from command line (`#87 `__) -* Add pytest.ini so local tests don't display warning (`#91 `__) -* Support PEP 338 invocation of rqt_reconfigure (`#85 `__) -* Fixed package to run with ros2 run (`#81 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_service_caller `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#13 `__) -* ignore services that don't use the SRV_MODE ('srv') (`#20 `__) -* Contributors: Alejandro Hernández Cordero, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_shell `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#11 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_srv `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#4 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_top `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed the build type to ament_python and fixed package to run with ros2 run (`#8 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add pytest.ini to silence warnings when running locally. -* Fix warnings pointed out by flake8. -* Created an entry-point for rqt_topic in setup.py (`#16 `__) -* Fix flake8 errors and add linter tests (`#28 `__) -* Update Open Robotics Maintainer (`#26 `__) -* Use raw / non-string value for ordering (`#23 `__) -* Support order fields as defined in message (`#22 `__) -* Fix the type cell value for sequence items (`#21 `__) -* Updated version package and license in setup.py (`#17 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rti_connext_dds_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Pass ``-Wl,--no-as-needed`` for system dependencies of Connext 5.3.1. -* Set ``IMPORTED_NO_SONAME true`` for Connext 5.3.1 imported library target. -* Add ```` for ``ament_cmake``. -* Add ```` for ``rti-connext-dds-5.3.1`` -* Add dependency from rti-connext-dds-5.3.1. -* Initial release. - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rttest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix up nonsensical handling of NULL in rttest_get\_{params,statistics} (`#107 `__) -* Remove "struct" from rttest_sample_buffer variable declaration. (`#105 `__) -* Convert the sample buffer to a vector. (`#104 `__) -* Use strdup instead of strlen/strcpy dance. (`#100 `__) -* Enable basic warnings in rttest (`#99 `__) -* Only copy an rttest_sample_buffer if it is not nullptr. (`#98 `__) -* Convert timespec to uint64 not long and vice versa (`#94 `__) (`#96 `__) -* Fix standard deviation overflow(`#95 `__) (`#97 `__) -* Contributors: Audrow Nash, Chris Lalancette, y-okumura-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use "%s" as format string literal in logging macros (`#633 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* Move and update documentation for ROS 2 (`#600 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_assimp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Always preserve source permissions in vendor packages (`#647 `__) -* Add an override flag to force vendored build (`#642 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* Updated a hack to avoid CMake warning with assimp 5.0.1 and older, applying it cross platforms (`#565 `__) -* Contributors: Dirk Thomas, Jacob Perron, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add visualization_frame to the public API (`#660 `__) -* Add ViewPicker::get3DPatch to the public API (`#657 `__) -* Fix byte indexing for depth patch pixels (`#661 `__) -* fix toolbar vanishing when pressing escape (`#656 `__) -* Expose VisualizationManager and YamlConfigReader to the public API (`#649 `__) -* Use the stack for the classes in the property test. (`#644 `__) -* Check that the views_man\_ and views_man\_->getCurrent() are not nullptr. (`#634 `__) -* Fix for mousewheel to zoom in/out (`#623 `__) -* Ensure rviz_common::MessageFilterDisplay processes messages in the main thread (`#620 `__) -* Fix render window disppearing after saving image (`#611 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* TimePanel port (`#599 `__) -* Upgrade to tinyxml2 for rviz (`#418 `__) -* Fix segfault on changing filter size for non-existent topic (`#597 `__) -* improve color support for themes (`#590 `__) -* Fix topic IntProperty number ranges (`#596 `__) -* Switch to nullptr everywhere. (`#592 `__) -* Expose MessageFilterDisplay's queue size (`#593 `__) -* Filter topics in drop down menu (`#591 `__) -* rviz_common: Remove variadic macro warning check (`#421 `__) -* Use retriever.hpp (`#589 `__) -* Fix the order of destructors (`#572 `__) -* Changed to not install test header files in rviz_rendering. (`#564 `__) -* Fixed alphabetical include order (`#563 `__) -* Changed to avoid trying to moc generate ``env_config.hpp`` file. (`#550 `__) -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Jacob Perron, Jafar Abdi, Joseph Schornak, Karsten Knese, Martin Idel, Michael Ferguson, Michael Jeronimo, Michel Hidalgo, Nico Neumann, Rich Mattes, Shane Loretz, ipa-fez, spiralray - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ViewPicker::get3DPatch to the public API (`#657 `__) -* Allow to zoom more with orbit controller (`#654 `__) -* Fix possible nullptr access in robot_joint.cpp. (`#636 `__) -* Fix for mousewheel to zoom in/out (`#623 `__) -* Make the types explicit in quaternion_helper.hpp. (`#625 `__) -* Update status message by removing colon or adjust colon position (`#624 `__) -* Do not use assume every RenderPanel has a ViewController. (`#613 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* TimePanel port (`#599 `__) -* Upgrade to tinyxml2 for rviz (`#418 `__) -* Use retriever.hpp (`#589 `__) -* Added covariance settings to set pose estimate (`#569 `__) -* use reference in range loops to avoid copy (`#577 `__) -* Changed to not install test header files in rviz_rendering. (`#564 `__) -* Changed to use a dedicated TransformListener thread. (`#551 `__) -* Suppressed warnings when building with older Qt versions. (`#562 `__) -* Restored compatibility with older Qt versions (`#561 `__) -* Contributors: Chen Lihui, Chris Lalancette, Dirk Thomas, Jacob Perron, Joseph Schornak, Martin Idel, Matthijs den Toom, Michel Hidalgo, Nico Neumann, Shane Loretz, Victor Lamoine, ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_ogre_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Always preserve source permissions in vendor packages (`#647 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* Pass through CMAKE\_{C,CXX}_FLAGS to OGRE build (`#587 `__) -* Contributors: Jacob Perron, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* reset current line width when calculating text width (`#655 `__) -* Silence a dead store warning. (`#643 `__) -* Fix a memory leak when using the ResourceIOSystem. (`#641 `__) -* Revert "Support loading meshes other than .mesh and .stl with package URIs (`#610 `__)" (`#638 `__) -* Prevent rviz_rendering::AssimpLoader from loading materials twice. (`#622 `__) -* Support loading meshes other than .mesh and .stl with package URIs (`#610 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* Switch to nullptr everywhere. (`#592 `__) -* Use retriever.hpp (`#589 `__) -* Avoid hidding base class getRenderOperation in PointCloudRenderable (`#586 `__) -* Changed to not install test header files in rviz_rendering. (`#564 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, ipa-fez - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* Use retriever.hpp (`#589 `__) -* Changed to not install test header files in rviz_rendering. (`#564 `__) -* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_visual_testing_framework `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Quiet a clang warning about a Qt memory leak. (`#651 `__) -* use rcutils_get_env. (`#609 `__) -* Add linters and use ament_lint_auto (`#608 `__) -* Update maintainers (`#607 `__) -* Contributors: Chris Lalancette, Jacob Perron, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Fix PointCloud2Iterator namespacing in docs (`#139 `__) -* Add coverage/performance to qd for sensor_msgs (`#137 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Missing cstring header for memcpy in fill_image.hpp (`#126 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Andre Nguyen, Chris Lalancette, Jose Luis Rivero, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg (`#150 `__) -* Port of point_cloud2.py from ROS1 to ROS2. As seperate pkg. (`#128 `__) -* Contributors: Ivan Santiago Paunovic, Sebastian Grans - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shape_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shared_queues_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Contributors: Emerson Knapp, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`spdlog_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#24 `__) -* Update to spdlog 1.8.2 (`#23 `__) -* Remove a stale TODO (`#22 `__) -* Always preserve source permissions in vendor packages (`#20 `__) -* Remove unnecessary call to find_package(PATCH) (`#18 `__) -* Updated QD to 1 (`#16 `__) -* bump spdlog version to 1.6.1 (`#15 `__) -* Bump QD to level 3 and updated QD (`#14 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#13 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Scott K Logan, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sqlite3_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Always preserve source permissions in vendor packages (`#645 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* use interface_include_directories (`#426 `__) -* Contributors: Emerson Knapp, Karsten Knese, Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sros2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Skip mypy test on platforms using importlib_resources (`#258 `__) -* Enable topic "ros_discovery_info" for rmw_connextdds (`#253 `__) -* Declare missing dependency on python3-importlib-resources (`#249 `__) Co-authored-by: -* Fix namedtuple names. (`#250 `__) -* parameter_events topic is now absolute (#233) Signed-off-by: Mikael Arguedas -* Expose keystore operations in public API (`#241 `__) -* add cyclonedds to the list of rmw using graph info topics (`#231 `__) -* Add scope parameter (`#230 `__) -* Fix name of argument passed to NodeStrategy (`#227 `__) -* Remove the use of pkg_resources. (`#225 `__) -* Make use of ros_testing to test policy generation. (`#214 `__) -* Add pytest.ini so local tests don't display warning (`#224 `__) -* Fix list keys verb (`#219 `__) -* Contributors: Andrea Sorbini, Chris Lalancette, Jacob Perron, Jose Luis Rivero, Kyle Fazzari, Michel Hidalgo, Mikael Arguedas, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`statistics_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updating Quality Declaration (`#120 `__) -* Update quality declaration to QL 1. (`#116 `__) -* Update package maintainers. (`#112 `__) -* Increase Quality level of packages to 3 (`#108 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) -* Updating QD to reflect package versions (`#107 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) Co-authored-by: Simon Honigmann -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_srvs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`stereo_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tango_icons_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add exec_depend on tango-icon-theme system package (`#8 `__) -* Added common linters (`#7 `__) * Added common linters * Fixed license in package.xml -* Remaned package qt_gui_icons -> tango_icons_vendor (`#4 `__) * Remaned package qt_gui_icons -> tango_icons_vendor * Updated CMake var to install tango icons: INSTALL_TANGO_ICONS * Added cmake option INSTALL_TANGO_ICONS * Fixed logic * set INSTALL_TANGO_ICONS_DEFAULT_VALUE to option * Make linters happy -* Updated link on the description (`#6 `__) -* Updated the maintainer (`#5 `__) -* Version 0.0.0 this package was never released (`#3 `__) -* Install icons by default on macOS too (`#1 `__) -* Updating package.xml -* fixup! Install tango icons -* Adding icons -* Install tango icons -* Contributors: Alejandro Hernández Cordero, Scott K Logan, Stephen, Stephen Brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers. (`#450 `__) -* Enable -Wall, -Wextra, and -Wpedantic. (`#447 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli_remapping `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix test_cli_remapping flaky test. (`#470 `__) -* Update maintainers. (`#450 `__) -* Enable -Wall, -Wextra, and -Wpedantic. (`#448 `__) -* Contributors: Audrow Nash, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_communication `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for rmw_connextdds. (`#463 `__) -* Kill off the ros2 daemon before running tests. (`#460 `__) -* Remove Opensplice from test_communication. (`#460 `__) -* Make TestMessageSerialization robust to missed messages. (`#456 `__) -* Add corresponding rclcpp::shutdown. (`#455 `__) -* Update maintainers. (`#450 `__) -* Contributors: Andrea Sorbini, Chris Lalancette, Jacob Perron, Stephen Brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_interface_files `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer (`#13 `__) -* Contributors: Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add a package marker to test_launch_ros. (`#226 `__) -* Re-order shutdown vs node destruction (`#213 `__) -* Increase test_composable_node_container timeout (`#195 `__) -* Remove constructors arguments deprecated since Foxy (`#190 `__) -* Merge pull request `#183 `__ from ros2/update-maintainers -* Move previous maintainer to -* Update the package.xml files with the latest Open Robotics maintainers -* Handle any substitution types for SetParameter name argument (`#182 `__) -* Address security bug in yaml loading (`#175 `__) -* Resolve TODO in test (`#172 `__) -* Fix case where list of composable nodes is zero (`#173 `__) -* Do not use event handler for loading composable nodes (`#170 `__) -* Fix race with launch context changes when loading composable nodes (`#166 `__) -* Substitutions in parameter files (`#168 `__) -* Fix problems when parsing a ``Command`` ``Substitution`` as a parameter value (`#137 `__) -* Drop double single-quoted params. (`#164 `__) -* Add a way to set remapping rules for all nodes in the same scope (`#163 `__) -* Fix ComposableNode ignoring PushRosNamespace actions (`#162 `__) -* Add a SetParameter action that sets a parameter to all nodes in the same scope (`#158 `__) -* Make namespace parameter mandatory in LifecycleNode constructor (`#157 `__) -* Avoid using a wildcard to specify parameters if possible (`#154 `__) -* Remove the loop parameter from async.sleep. (`#155 `__) -* Fix no specified namespace (`#153 `__) -* Fix test_node_frontend (`#146 `__) -* Add pytest.ini so local tests don't display warning (`#152 `__) -* Contributors: Chris Lalancette, Dan Rose, Ivan Santiago Paunovic, Jacob Perron, Michael Jeronimo, Michel Hidalgo, Scott K Logan, Víctor Mayoral Vilches - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers (`#465 `__) -* Add pytest.ini to test_launch_testing so tests succeed locally. (`#431 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update package maintainers. (`#112 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_quality_of_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for rmw_connextdds. (`#463 `__) -* Run QoS tests. (`#441 `__) -* Update maintainers. (`#450 `__) -* Contributors: Andrea Sorbini, Jacob Perron, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Reenable test that used to be flaky. (`#467 `__) -* Get_parameters_service\_ should return empty if allow_undeclared\_ is false. (`#466 `__) -* Make test pass after rclcpp#1532. (`#465 `__) -* Adapt tests to statically typed parameters. (`#462 `__) -* Guard against TOCTTOU with rclcpp::ok and rclcpp:spin_some. (`#459 `__) -* Update parameter client test with timeout. (`#457 `__) -* Call rclcpp::init and rclcpp::shutdown in each test for test_rclcpp. (`#454 `__) -* Set cppcheck timeout to 400 seconds. (`#453 `__) -* Modify to match Waitable interface adding take_data. (`#444 `__) -* Update maintainers. (`#450 `__) -* Fix rclcpp timeout subscriber test. (`#440 `__) * Use nonzero lower bound for timeout checks. * Relax time tolerance. -* Show numbers of nanseconds in EXPECT with durations. (`#438 `__) * Show numbers of nanseconds in expect with durations * Fix syntax -* Remove ament_pytest dependency from test_rclcpp. (`#437 `__) It is not used in test_rclcpp anywhere. -* Contributors: Audrow Nash, Chris Lalancette, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, Stephen Brawner, Tomoya Fujita, tomoya - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Implement test for subscription loaned messages (`#186 `__) -* Remove rmw_connext_cpp. (`#183 `__) -* Add support for rmw_connextdds (`#182 `__) -* Add function for checking QoS profile compatibility (`#180 `__) -* Make sure to initialize the rmw_message_sequence after init. (`#175 `__) -* Set the value of is_available before entering the loop (`#173 `__) -* Set the return value of rmw_ret_t before entering the loop. (`#171 `__) -* Add some additional checking that cleanup happens. (`#168 `__) -* Add test to check rmw_send_response when the client is gone (`#162 `__) -* Update maintainers (`#154 `__) -* Add fault injection tests to construction/destroy APIs. (`#144 `__) -* Add tests bad type_support implementation (`#152 `__) -* Add tests for localhost-only node creation (`#150 `__) -* Added rmw_service_server_is_available tests (`#140 `__) -* Use 10x the intraprocess delay to wait for sent requests. (`#148 `__) -* Added rmw_wait, rmw_create_wait_set, and rmw_destroy_wait_set tests (`#139 `__) -* Add tests service/client request/response with bad arguments (`#141 `__) -* Added test for rmw_get_serialized_message_size (`#142 `__) -* Add service/client construction/destruction API test coverage. (`#138 `__) -* Added rmw_publisher_allocation and rmw_subscription_allocation related tests (`#137 `__) -* Add tests take serialized with info bad arguments (`#130 `__) -* Add gid API test coverage. (`#134 `__) -* Add tests take bad arguments (`#125 `__) -* Bump graph API test coverage. (`#132 `__) -* Add tests take sequence serialized with bad arguments (`#129 `__) -* Add tests take sequence + take sequence with bad arguments (`#128 `__) -* Add tests take with info bad arguments (`#126 `__) -* Add tests for non-implemented rmw_take\_* functions (`#131 `__) -* Add tests publish serialized bad arguments (`#124 `__) -* Add tests publish bad arguments (`#123 `__) -* Add tests non-implemented functions + loan bad arguments (`#122 `__) -* Add missing empty topic name tests. (`#136 `__) -* Add rmw_get_serialization_format() smoke test. (`#133 `__) -* Complete publisher/subscription QoS query API test coverage. (`#120 `__) -* Remove duplicate assertions (`#121 `__) -* Add publisher/subscription matched count API test coverage. (`#119 `__) -* Add serialize/deserialize API test coverage. (`#118 `__) -* Add subscription API test coverage. (`#117 `__) -* Extend publisher API test coverage (`#115 `__) -* Add node construction/destruction API test coverage. (`#112 `__) -* Check that rmw_init() fails if no enclave is given. (`#113 `__) -* Add init options API test coverage. (`#108 `__) -* Complete init/shutdown API test coverage. (`#107 `__) -* Add dependency on ament_cmake_gtest (`#109 `__) -* Add test_rmw_implementation package. (`#106 `__) -* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Chris Lalancette, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Jose Tomas Lorente, José Luis Bueno López, Michel Hidalgo, Miguel Company, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_security `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for rmw_connextdds. (`#463 `__) -* Update deprecated gtest macros. (`#449 `__) -* Update maintainers. (`#450 `__) -* Run test_security on CycloneDDS as well. (`#408 `__) -* Remove invalid cert folder to force regeneration of certificates. (`#434 `__) -* Contributors: Andrea Sorbini, Audrow Nash, Jacob Perron, Mikael Arguedas - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Fix a TOCTTOU race in tf2. (`#307 `__) -* Fixed memory leak in Buffer::waitForTransform (`#281 `__) -* relax test timings to pass with Connext (`#304 `__) -* Explicitly initialize instances of tf2::Duration (`#291 `__) -* Generate callbacks after updating message\_ (`#274 `__) -* fix test_static_publisher in macos (`#284 `__) -* Fix up the dependencies in test_tf2. (`#277 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Ivan Santiago Paunovic, Martin Ganeff, Michael Carroll, ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#394 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Active usual compiler warnings in tf2 (`#322 `__) -* Cleanups in buffer_core.cpp. (`#301 `__) -* Add PoseWithCovarianceStamped transform support (`#312 `__) -* Fix a TOCTTOU race in tf2. (`#307 `__) -* Fixed memory leak in Buffer::waitForTransform (`#281 `__) -* Add common linters to tf2. (`#258 `__) -* Provide more available error messaging for nonexistent and invalid frames in canTransform (`ros2 #187 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ivan Santiago Paunovic, Joshua Whitley, Martin Ganeff - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_bullet `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Suppress compiler warning on Centos (`#290 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix linter errors (`#385 `__) -* Fix up the style in tf2_eigen. (`#378 `__) -* Fix doTransform with Eigen Quaternion (`#369 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Contributors: Audrow Nash, Bjar Ne, Chris Lalancette, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix order of find eigen3_cmake_module & find eigen3 (`#344 `__) -* Update package.xml (`#333 `__) -* Port eigen_kdl.h/cpp to ROS2 (`#311 `__) -* Contributors: Ahmed Sobhy, Jafar Abdi - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix doTransform with Eigen Quaternion (`#369 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Add PoseWithCovarianceStamped transform support (`#312 `__) -* Don't install python tf2_geometry_msgs (`#299 `__) It hasn't been ported yet. Closes https://github.com/ros2/geometry2/issues/285 -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) * Split tf2_ros in tf2_ros and tf2_ros_py -* Contributors: Alejandro Hernández Cordero, Bjar Ne, Chris Lalancette, Ivan Santiago Paunovic, Joshua Whitley, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Adapt to Python 3.9 (`#362 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Add in pytest.ini so tests succeed locally. (`#280 `__) -* Contributors: Chris Lalancette, Homalozoa X - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Guard against access to null node pointer (`#393 `__) -* Allow to reconfigure durability for /tf topic broadcaster/listener (`#383 `__) -* Fix the rcl type used in the time jump. (`#391 `__) -* Fix linter errors (`#385 `__) -* fix accessing freed resources (`#386 `__) -* Allow reconfiguring qos of tf and tf_static topics through parameters (`#381 `__) -* Replace ROS\_* logging macros and use RCLCPP\_* instead (`#380 `__) -* Improve message filters error messages (`#364 `__) -* Clarify the role of child_frame_id and header.frame_id in the documentation. (`#345 `__) -* Remove usage of deprecated rclcpp::Duration constructor (`#340 `__) -* Remove messages_count member from tf2_ros::MessageFilter. (`#335 `__) -* Style fixup in tf2_ros. (`#325 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Update goal response callback signature (`#323 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Fixed memory leak in Buffer::waitForTransform (`#281 `__) -* fix time-reset test with Connext (`#306 `__) -* reenable FrameGraph server (`#198 `__) -* Use the usual style of parameters for static_transform_program (`#300 `__) -* Make static_transform_broadcaster consistent with its command line description (`#294 `__) -* Avoid using invalid std::list iterators (`#293 `__) -* Generate callbacks after updating message\_ (`#274 `__) -* Moved unique_lock of messages_mutex\_ to guarantee pointer (`#279 `__) -* Fix dependencies in tf2_ros. (`#269 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Dirk Thomas, Hunter L. Allen, Ivan Santiago Paunovic, Jacob Perron, Kazunari Tanaka, Martin Ganeff, Michael Carroll, Vikas Dhiman, ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg. (`#403 `__) (`#404 `__) -* Use global namespace for TransformListener topics (`#390 `__) -* Fix indentation of a comment in buffer.py (`#371 `__) -* Update rclpy.Rate TODO with url to issue (`#324 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Add deprecation warnings to lookup_transform to handle the passing of the incorrect Time object. (`#319 `__) -* change signature to show true arguments (`#321 `__) -* Handle when None passed to qos argument in the constructor of TransformBroadcaster. (`#320 `__) -* Add type hints to tf2_ros_py code(`#275 `__) (`#315 `__) -* Clear callbacks_to_remove variable after removing (`#303 `__) -* Fix cache_time None check in buffer.py (`#297 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Matthijs den Toom, ScottMcMichael, surfertas - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Activate usual compiler warnings and fix errors (`#270 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use underscores instead of dashes in setup.cfg. (`#403 `__) (`#404 `__) -* Add wait time option to view_frames (`#374 `__) -* Cleanup tf2_tools to be more modern. (`#351 `__) -* Update maintainers of the ros2/geometry2 fork. (`#328 `__) -* Address security bug in yaml loading (`#313 `__) -* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Víctor Mayoral Vilches - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to standard __VA_ARGS_\_. (`#9 `__) -* Enable basic warnings (`#8 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in the Apache license to tlsf_cpp. (`#108 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_monitor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use is_alive for threads. (`#510 `__) (`#513 `__) -* Use underscores instead of dashes in setup.cfg (`#502 `__) -* Change index.ros.org -> docs.ros.org. (`#496 `__) -* Update deprecated qos policy value names (`#468 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_statistics_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#496 `__) -* Update logging macros (`#476 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) -* Create new topic statistics demo package (`#454 `__) -* Contributors: Audrow Nash, Chris Lalancette, Michael Jeronimo, Prajakta Gokhale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update QD to be more specific about public API -* Namespace tracetools C++ functions and macros and deprecate current ones -* Add support for rcl_publish and rclcpp_publish tracepoints -* Add instrumentation support for linking a timer to a node -* Bring tracetools up to quality level 1 -* Add lifecycle node state transition instrumentation -* Do not export tracetools if empty -* Allow disabling tracetools status app -* Contributors: Christophe Bedard, Ingo Lütkebohle, José Antonio Moral - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow configuring tracing directory through environment variables -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update after namespacing C++ tracetools functions and macros -* Add tests for rcl_publish and rclcpp_publish tracepoints -* Allow asserting order of list of events -* Allow skipping test trace cleanup by setting an environment variable -* Add test for timer-node linking instrumentation -* Increased code coverage > 94% as part of QL1 -* Add lifecycle node state transition instrumentation test -* Contributors: Alejandro Hernández Cordero, Christophe Bedard, Ingo Lütkebohle - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for rcl_publish and rclcpp_publish tracepoints -* Fix flake8 blind except error by using more concrete types -* Allow configuring tracing directory through environment variables -* Cleanly stop ros2trace/tracetools_trace tracing on SIGINT -* Add instrumentation support for linking a timer to a node -* Add lifecycle node state transition instrumentation -* Contributors: Christophe Bedard, Ingo Lütkebohle - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`trajectory_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Finish up API documentation (`#123 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`turtlesim `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Ignore key up events in teleop_turtle_key on Windows (`#118 `__) -* Update maintainers (`#106 `__) -* Update goal response callback signature (`#100 `__) -* add holonomic motion for turtlesim (`#98 `__) -* add step value to turtlesim color parameters (`#91 `__) -* update Foxy turtle (`#90 `__) -* Contributors: Jacob Perron, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`unique_identifier_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org (`#21 `__) -* Update QD to QL 1 (`#17 `__) -* Update Quality Declaration to QL2. (`#15 `__) -* Update Quality level to level 3 (`#13 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#11 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Work around Windows min/max bug. (`#21 `__) -* Enable -Wall -Wextra -Wpedantic (`#20 `__) -* Add dependency on TinyXML2 (`#19 `__) -* Remove TinyXML dependency from urdf. (`#17 `__) -* Make urdf plugable and revive urdf_parser_plugin (`#13 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf_parser_plugin `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Export urdfdom_headers as urdf_parser_plugin dependency. (`#25 `__) -* Make urdf plugable and revive urdf_parser_plugin (`#13 `__) -* Contributors: Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`visualization_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change index.ros.org -> docs.ros.org. (`#149 `__) -* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) -* Update QDs to QL 1 (`#135 `__) -* Update package maintainers. (`#132 `__) -* Updated Quality Level to 2 (`#131 `__) -* Update Quality levels to level 3 (`#124 `__) -* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`yaml_cpp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Always preserve source permissions in vendor packages (`#22 `__) -* Add an override flag to force vendored build (`#21 `__) -* Reapply "Use system installed yaml-cpp 0.6 if available (`#8 `__)" (`#16 `__) -* Revert "Use system installed yaml-cpp 0.6 if available (`#8 `__)" (`#15 `__) -* Use system installed yaml-cpp 0.6 if available (`#8 `__) -* Contributors: Ivan Santiago Paunovic, Scott K Logan, Sean Yen - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`zstd_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly add emersonknapp as maintainer (`#692 `__) -* Always preserve source permissions in vendor packages (`#645 `__) -* Zstd should not install internal headers - some of them try include others that aren't installed. We don't use them. Avoid the situation (`#631 `__) -* Patch zstd 1.4.4 to include cmake_minimum_version bump to 2.8.12 (`#579 `__) -* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Contributors: Emerson Knapp, Michael Jeronimo, Scott K Logan +.. redirect-from:: + + Releases/Galactic-Geochelone-Complete-Changelog + +Galactic Geochelone changelog +============================= + +This page is a list of the complete changes in all ROS 2 core packages since the previous release. + +.. contents:: Table of Contents + :local: + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#122 `__) +* Updating Quality Declaration (`#120 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update logging macros (`#476 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Update goal response callback signature (`#463 `__) +* Contributors: Audrow Nash, Jacob Perron, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#502 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Ivan Santiago Paunovic, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`actionlib_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#132 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Add clang-format-version option to ament_clang_format (`#282 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan, Tyler Weaver + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Add multiprocessing support to ament_clang_tidy (`#288 `__) * add multiprocessing support * fix stylistic lint issues +* Add --packages-select argument to ament_clang_tidy (`#287 `__) Add comment explaining handling quoted list of space separated package names Update documentation for ament_clang_tidy +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, M. Mei, Tyler Weaver + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* add TIMEOUT argument to ament_cmake_clang_tidy (`#298 `__) +* Add Audrow as a maintainer (`#294 `__) +* Fix documentation for ament_cmake_clang_tidy (`#285 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, M. Mei, Tyler Weaver + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* increase default timeout for CMake copyright linter to 120s (`#261 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Merge pull request `#287 `__ from ament/mjeronimo/add-condition-support * Check condition attr in package.xml dependencies The condition attribute was already parsed when reading the XML file. Just needed to check the condition when adding dependencies to the list for a particular key/target. Fixes `#266 `__ * Address Dirk's code review feedback +* Address Dirk's code review feedback +* Check condition attr in package.xml dependencies The condition attribute was already parsed when reading the XML file. Just needed to check the condition when adding dependencies to the list for a particular key/target. Fixes `#266 `__ +* Update package maintainers. (`#286 `__) +* Contributors: Michael Jeronimo, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Increase the ament_cppcheck timeout to 5 minutes. (`#271 `__) This will avoid timeouts on some slower platforms that we've started to see. +* parse LANGUAGE argument case insensitive (`#255 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Karsten Knese, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_definitions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix cmake list(TRANSFORM ) is only available from version 3.12, (`#296 `__) convert to string instead +* fix imported targets with multiple configuration (`#290 `__) * fix imported targets with multiple configuration * taking into account DEBUG_CONFIGURATIONS global variable +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo, siposcsaba89 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix variable name in ament_export_libraries.cmake (`#314 `__) +* Update package maintainers. (`#286 `__) +* Contributors: Alejandro Hernández Cordero, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_link_flags `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_targets `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gmock `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_google_benchmark `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Serialize benchmarks within CTest by default (`#308 `__) +* Handle runtime failures in Google Benchmark (`#294 `__) This change will handle runtime failures in Google Benchmark by propagating error information from Google Benchmark to both CTest and the Jenkins benchmark plugin. +* Use consistent string format and resolve flake8 (`#295 `__) Follow-up to a5fb3112b5c46c42b1824c96af4171d469eb13bf +* Make ament_cmake_test a dep of ament_cmake_google_benchmark (`#293 `__) +* Catch JSONDecodeError and printout some debug info (`#291 `__) +* Update package maintainers. (`#286 `__) +* Make AMENT_RUN_PERFORMANCE_TESTS a CMake option (`#280 `__) +* Skip performance tests using a CMake variable (`#278 `__) These tests can be fairly heavy, so we don't want to run them by default. It would be better if there was a way to skip the tests by default in such a way that they could be specifically un-skipped at runtime, but I can't find a mechanism in CMake or CTest that would allow us to achieve that behavior without leveraging environment variables. +* Handle Google Benchmark 'aggregate' results (`#276 `__) Previously, I assumed all results generated by Google Benchmark were of 'iteration' type. Now that I have more experience with Google Benchmark, I've started generating aggregate results, which contain some different properties. This change adds support for aggregate results and should make it easy to add any other result schemas we encounter in the future. For forward-compatibility, unsupported types will generate a warning message but will not fail the test. This makes the conversion tolerant to Google Benchmark adding new measures for existing mechanisms. +* Initial Google Benchmark results conversion (`#275 `__) +* Handle missing results file for Google Benchmark (`#265 `__) +* Initial ament_cmake_google_benchmark package (`#261 `__) +* Contributors: Michel Hidalgo, Scott K Logan, brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gtest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable gtest warning when building in Release (`#298 `__) https://github.com/google/googletest/issues/1303 +* Update package maintainers. (`#286 `__) +* [ament_cmake_gtest] ensure gtest to consume the correct headers. (`#267 `__) * ensure gtest to consume the correct headers. * add another patch. +* Contributors: Michel Hidalgo, Sean Yen, Victor Lopez + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* ament_lint_cmake: default linelength in argumentparser for consistency (`#306 `__) +* 0.10.3 +* Fix ament_lint_cmake line length expression (`#236 `__) This regular expression is using the re.VERBOSE flag, meaning that characters after an un-escaped '#' character are interpreted as a comment and are not part of the expression. Also set the default maximum line length to 140 columns. +* Add Audrow as a maintainer (`#294 `__) +* Make CMake linter line length configurable (`#235 `__) Co-authored-by: Miaofei +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Emerson Knapp, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_nose `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix ament_get_pytest_cov_version for newer versions of pytest (`#315 `__) +* Update package maintainers. (`#286 `__) +* Contributors: Christophe Bedard, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Symlink setup.cfg and sources before building Python egg-info (`#327 `__) +* Simplify ament_python_install_package() macro. (`#326 `__) Do not delegate to setuptools, install egg-info manually. +* Escape $ENV{DESTDIR} everywhere in ament_python_install_package() (`#324 `__) Follow up after f80071e2216e766f7bf1b0792493a5f6523e9226 +* Use DESTDIR on ament_python_install_package() (`#323 `__) * Use DESTDIR on ament_python_install_package() +* Make ament_python_install_package() install a flat Python egg (`#316 `__) +* [ament_cmake_python] ament_cmake_python_get_python_install_dir public (`#300 `__) * [ament_cmake_python] make the ament_cmake_python_get_python_install_dir a public interface. +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo, Naveau + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#11 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_target_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Force SYSTEM keyword in ament_target_dependencies() at the start. (`#303 `__) +* Add SYSTEM keyword option to ament_target_dependencies (`#297 `__) * Add SYSTEM keyword option to ament_target_dependencies * Add documentation of SYSTEM keyword for ament_target_dependencies +* Update package maintainers. (`#286 `__) +* ordered interface include dirs and use privately to ensure workspace order (`#260 `__) +* Contributors: Andre Nguyen, Dirk Thomas, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Fix skipped test reporting in CTest (`#279 `__) This is a follow-up to c67cdf2. When the SKIP_RETURN_CODE gets set to 0, the value is interpreted as 'false', and the test property is never actually added. +* limit test time to three decimals (`#271 `__) +* Add actual test time to xUnit result files (`#270 `__) * Add actual test time to xUnit result files Fixes `#269 `__ * Report test_time even with skipped test * Set time attribute for testcase element +* Add SKIP_RETURN_CODE argument to ament_add_test (`#264 `__) This makes the ``run_test.py`` wrapper aware of the ``SKIP_RETURN_CODE`` property on CTest tests. In the existing implementation, the wrapper detects that no result file was generated and overrides the special return code coming from the test, making the the CTest feature fail completely. This change makes the wrapper script aware of the special return code, and when detected, will write a 'skipped' result file instead of a 'failed' result file, and pass along the special return code as-is. Now the gtest result and the ctest results both show the test as 'skipped' when the special return flag is used. Note that none of this behavior is enabled by default, which is important because we wouldn't want a test to fail and return a code which we've decided is the special 'skip' return code. Only tests which are aware of this feature should use it. +* Contributors: Dirk Thomas, Michel Hidalgo, Ruffin, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* parse LANGUAGE argument case insensitive (`#255 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Karsten Knese, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_version `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#286 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* Use non-blind except for open() (`#307 `__) +* Add optional file header style (`#304 `__) * Add optional file header style * Fix test on ament_copyright +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* add mit-0 as a valid license to ament_copyright (`#284 `__) +* Support Python 3.8-provided importlib.metadata (`#290 `__) The importlib_metadata package is a backport of the importlib.metadata module from Python 3.8. Fedora (and possibly others) no longer package importlib_metadata because they ship Python versions which have the functionality built-in. +* Update maintainer (`#274 `__) * update maintainer * add authors +* added bsd 2 clause simplified license to ament_copyright (`#267 `__) * added bsd 2 clause simplified license to ament_copyright +* Remove use of pkg_resources from ament_lint. (`#260 `__) Replace it with the use of the more modern importlib_metadata library. There are a couple of reasons to do this: 1. pkg_resources is quite slow to import; on my machine, just firing up the python interpreter takes ~35ms, while firing up the python interpreter and importing pkg_resources takes ~175ms. Firing up the python interpreter and importing importlib_metadata takes ~70ms. Removing 100ms per invocation of the command-line both makes it speedier for users, and will speed up our tests (which call out to the command-line quite a lot). 2. pkg_resources is somewhat deprecated and being replaced by importlib. https://importlib-metadata.readthedocs.io/en/latest/using.html describes some of it Note: By itself, this change is not enough to completely remove our dependence on pkg_resources. We'll also have to do something about the console_scripts that setup.py generates. That will be a separate effort. +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Alfi Maulana, Audrow Nash, Chris Lalancette, Christophe Bedard, Claire Wang, Evan Flynn, M. Mei, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Fix file exclusion behavior in ament_cppcheck and ament_cpplint (`#299 `__) * fix exclude behavior in ament_cppcheck and ament_cpplint * fix flake8 errors * add missing realpath() conversion +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Suppress unknownMacro (`#268 `__) cppcheck creates an unknownMacro error when it cannot resolve a macro. Since we don't pass in all dependent headers, we don't expect all macros to be discoverable by cppcheck. +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Dan Rose, M. Mei, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Fix file exclusion behavior in ament_cppcheck and ament_cpplint (`#299 `__) * fix exclude behavior in ament_cppcheck and ament_cpplint * fix flake8 errors * add missing realpath() conversion +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, M. Mei, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as the maintainer. (`#71 `__) +* Change links from index.ros.org -> docs.ros.org (`#70 `__) +* Add Audrow as a maintainer (`#68 `__) +* update maintainers (`#67 `__) +* Update QD to Quality Level 1 (`#66 `__) +* add rational why ament_index pkgs don't have explicit performance tests (`#65 `__) +* Fixed Doxygen warnings (`#63 `__) +* Remove the Quality Level from the README.md. (`#62 `__) +* Update QD ament_index_cpp to QL 2 (`#59 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#57 `__) +* [Quality Declaration] Update Version Stability to stable version (`#58 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as the maintainer. (`#71 `__) +* Change links from index.ros.org -> docs.ros.org (`#70 `__) +* Add Audrow as a maintainer (`#68 `__) +* update maintainers (`#67 `__) +* add rational why ament_index pkgs don't have explicit performance tests (`#65 `__) +* Remove the Quality Level from the README.md. (`#62 `__) +* Fix document link (`#61 `__) +* [Quality Declaration] Update Version Stability to stable version (`#58 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, Matthijs van der Burgh + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Use correct lint package dependencies (`#278 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Esteve Fernandez, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* ament_lint_cmake: default linelength in argumentparser for consistency (`#306 `__) +* 0.10.3 +* Fix ament_lint_cmake line length expression (`#236 `__) This regular expression is using the re.VERBOSE flag, meaning that characters after an un-escaped '#' character are interpreted as a comment and are not part of the expression. Also set the default maximum line length to 140 columns. +* Add Audrow as a maintainer (`#294 `__) +* Make CMake linter line length configurable (`#235 `__) Co-authored-by: Miaofei +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Emerson Knapp, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Generate Setuptools Dict Helper Method (`#126 `__)" (`#131 `__) +* Generate Setuptools Dict Helper Method (`#126 `__) +* Add Audrow as a maintainer (`#127 `__) +* Support Python 3.8-provided importlib.metadata (`#124 `__) +* Declare missing dependency on python3-importlib-resources (`#123 `__) +* make AMENT_TRACE_SETUP_FILES output sourceable (`#120 `__) +* update maintainers +* Switch ament_package to using importlib. (`#118 `__) +* Add pytest.ini so local tests don't display warning (`#117 `__) +* add configure-time flag to skip parent_prefix_path (`#115 `__) +* Contributors: Audrow Nash, Chris Lalancette, David V. Lu!!, Dirk Thomas, Mabel Zhang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Add pytest marks to ament_pclint tests. (`#202 `__) * Add pytest marks to ament_pclint tests. * fix failed tests Co-authored-by: Miaofei +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan, Steven! Ragnarök + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* remove use of "extend" action in argparse (`#262 `__) +* Expand ignores to pep257 definition. (`#241 `__) * Expand ignores to pep257 definition. (ament `#240 `__) * add '--allow-undocumented' flag to enforce pep257 * restore existing default error codes to check * fix no-ignores logic * expose options from pydocstyle * allow user to explicitly set convention to "ament" * fix typo in populating argv for pydocstyle * reformat ament convention list * Add help info for ament convention +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* remove match args to allow pydocstyle defaults (`#243 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan, Ted Kern + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Allow 'C++' as language, but convert it to 'CPP' (`#302 `__) +* Allow correct languages on uncrustify (`#272 `__) * Allow correct languages on uncrustify. * Update dictionary. +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Miguel Company, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove Claire as a maintainer. (`#312 `__) * Remove Claire as a maintainer. * Remove dead email addresses. * Remove more dead email addresses. * Switch setup.py maintainer to Audrow. +* 0.10.3 +* Add Audrow as a maintainer (`#294 `__) +* Drop trailing tab from package manifests (`#291 `__) Follow-up to 8bf194aa1ac282db5483dd0d3fefff8f325b0db8 +* Update maintainer (`#274 `__) * update maintainer * add authors +* Add pytest.ini so local tests don't display warning. (`#259 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`builtin_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#122 `__) +* Updating Quality Declaration (`#120 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Document that Time and Duration are explictly ROS Time (`#103 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, Tully Foote, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_calibration_parsers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix formatting and include paths for linters (`#157 `__) +* ROS2 Using the filesystem helper in rcpputils (`#133 `__) +* [Windows][ros2] Avoid build break for Visual Studio 2019 v16.3 (`#135 `__) +* Camera Calibration Parsers ROS2 Port (`#105 `__) +* Image Transport ROS2 port (`#84 `__) +* Use Boost_LIBRARIES instead of Boost_PYTHON_LIBRARY This was causing issues when building with python3 since then ``Boost_PYTHON_LIBRARY`` is not set, instead cmake sets ``Boost_PYTHON3_LIBRARY``. So instead of adding each library separately, using ``Boost_LIBRARIES`` seems to be better. For reference, from the cmake docs: ``` Boost_LIBRARIES - Boost component libraries to be linked Boost\__LIBRARY - Libraries to link for component ``` +* Properly detect Boost Python 2 or 3 This fixes `#59 `__ +* 1.11.11 +* update changelogs +* Add install target for python wrapper library +* Only link against needed Boost libraries 9829b02 introduced a python dependency into find_package(Boost..) which results in ${Boost_LIBRARIES} containing boost_python and such a dependency to libpython at link time. With this patch we only link against the needed libraries. +* Add python wrapper for readCalibration. Reads .ini or .yaml calibration file and returns camera name and sensor_msgs/cameraInfo. +* Use $catkin_EXPORTED_TARGETS +* Remove no-longer-neccessary flags to allow OS X to use 0.3 and 0.5 of yaml-cpp. +* remove buggy CMake message +* fix `#39 `__ +* make sure test does not fail +* [camera_calibration_parsers] Better error message when calib file can't be written +* add rosbash as a test dependency +* add a test dependency now that we have tests +* parse distortion of arbitraty length in INI This fixes `#33 `__ +* add a test to parse INI calibration files with 5 or 8 D param +* Add yaml-cpp case for building on Android +* Fix catkin_make failure (due to yaml-cpp deps) for mac os +* fix bad yaml-cpp usage in certain conditions fixes `#24 `__ +* add a dependency on pkg-config to have it work on Indigo +* fix YAML CPP 0.5.x compatibility +* Contributors: Andreas Klintberg, Gary Servin, Helen Oleynikova, Isaac IY Saito, Jochen Sprickerhof, Kartik Mohta, Markus Roth, Martin Idel, Michael Carroll, Sean Yen, Vincent Rabaud, Yifei Zhang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_info_manager `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix formatting and include paths for linters (`#157 `__) +* Enable Windows build. (`#159 `__) +* Fix abort criteria for setCameraInfoService callback (`#132 `__) +* camera_info_manager ROS2 port (`#94 `__) +* Image Transport ROS2 port (`#84 `__) +* Fix the find_package(catkin) redundancy +* Add a dependency between the test and the test executable +* Add camera_calibration_parsers dependency to camera_info_manager +* 1.11.11 +* update changelogs +* Return empty CameraInfo when !ros::ok() +* Return empty CameraInfo when !ros::ok() +* fix compilation on Fedora, fixes `#42 `__ +* simplify target_link_libraries That should fix `#35 `__ +* Add public member function to manually set camera info (`#19 `__) +* make rostest in CMakeLists optional (`ros/rosdistro#3010 `__) +* check for CATKIN_ENABLE_TESTING +* add Jack as maintainer +* add gtest libraries linkage +* fix the rostest dependency +* fix catkin gtest and rostest problem +* fix unit test dependencies +* Removed duplicated test dependancy Test dependencies should never duplicate build or run dependencies. +* fix the urls +* Updated package.xml file(s) to handle new catkin buildtool_depend requirement +* remove the brief attribute +* fix bad folder/libraries +* add missing rostest dependency +* fix bad dependency +* fix dependencies +* add catkin as a dependency +* comply to the catkin API +* add missing linkage +* install the include directories +* fix build issues +* make the libraries public +* API documentation review update +* suppress misleading camera_info_manager error messages [#5273] +* remove deprecated global CameraInfoManager symbol for Fuerte (#4971) +* Revert to using boost::mutex, not boost::recursive_mutex. +* Hack saveCalibrationFile() to stat() the containing directory and attempt to create it if necessary. Test for this case. +* Reload camera info when camera name changes. +* Implement most new Electric API changes, with test cases. +* Add ${ROS_HOME} expansion, with unit test cases. Do not use "$$" for a single '$', look for "${" instead. +* Use case-insensitive comparisons for parsing URL tags (#4761). Add unit test cases to cover this. Add unit test case for camera name containing video mode. +* add test for resolving an empty URL +* Deprecate use of global CameraInfoManager symbol in E-turtle (#4786). Modify unit tests accordingly. +* provide camera_info_manager namespace, fixes #4760 +* Add support for "package://" URLs. +* Fixed tests to work with new CameraInfo. +* Moved image_common from camera_drivers. +* Contributors: Aaron Blasdel, Enrique Fernandez, Jack O'Quin, Jonathan Bohren, Joseph Schornak, Lukas Bulwahn, Martin Idel, Max Schettler, Michael Carroll, Sean Yen, Vincent Rabaud, blaise, mihelich, mirzashah + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`class_loader `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove travis. (`#182 `__) +* Change index.ros.org -> docs.ros.org. (`#181 `__) +* Fix ternary null check found by clang static analysis (`#176 `__) +* Update QD to QL 1 (`#177 `__) +* Updated console_bridge QL in QD +* Update package maintainers. (`#169 `__) +* enable building a static library (`#163 `__) +* Update Quality Declaration to reflect QL 2 (`#160 `__). +* Increase coverage with a graveyard behavior test and unmanaged instance test (`#159 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#157 `__) +* Clean up and improve documentation (`#156 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Michel Hidalgo, Stephen Brawner, ahcorde, brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`common_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#132 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix leak(`#480 `__) (`#481 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo, y-okumura-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#122 `__) +* Updating Quality Declaration (`#120 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`cyclonedds `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* DATA_AVAILABLE was not always triggered when by a dispose and sometimes triggered in the absence of an observable state change (arrival of a dispose for an already-disposed instance where the dispose had not yet been read); +* Restores functionality of the "raw ethernet" mode as well as IPv6 with link-local addresses, both accidentally broken in 0.6.0; +* Fixes a crash in processing endpoint discovery data containing unrecognised locator kinds; +* Fixes type conversion for local historical data (e.g., mixed use of ROS 2 C/C++ type supports in combination with transient-local endpoints within a single process); +* Fixes a use-after-free of "lease" objects with manual-by-topic writers; +* Mark instance as "alive" in the reader history and generate an invalid sample to notify the application even if the sample itself is dropped because the same or a later one is present already (e.g., on reconnecting to a transient-local writer); +* Fix a crash when doing an instance lookup on a built-in topic using the key value; +* No longer auto-dispose instances as soon as some registered writer disappears, instead do it only when all of them have unregistered it; +* Fix performance of read_instance and take_instance by performing a proper instance lookup. + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix small print issue in allocator tutorial. (`#509 `__) (`#512 `__) +* Small fixes for even_parameters_node. (`#500 `__) +* change ParameterEventHandler to take events as const ref instead of shared pointer (`#494 `__) +* Fix integer type in RCLCPP\_* macro printf. (`#492 `__) +* Add a demo for the new ParameterEventHandler class (`#486 `__) +* Filter qos overrides in paramter events demos (`#491 `__) +* Update code now that parameter types are static by default (`#487 `__) +* Update logging macros (`#476 `__) +* Make sure to wait for the service before declaring events. (`#473 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Michael Jeronimo, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp_native `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update demo_nodes_cpp_native to new Fast DDS API (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo, Miguel Company + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#502 `__) +* Update deprecated qos policy value names (`#468 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Ivan Santiago Paunovic, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`diagnostic_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`domain_coordinator `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#11 `__) +* Add pytest.ini to suppress warning output locally. (`#8 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_map_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_robot_bringup `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_sensors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`example_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change links from index.ros.org -> docs.ros.org. (`#13 `__) +* Update maintainer. (`#12 `__) +* Contributors: Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_cbg_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix clang warnings about type mismatches. (`#309 `__) +* Support for cbg_executor package on QNX (`#305 `__) +* Demo for callback-group-level executor concept. (`#302 `__) +* Contributors: Chris Lalancette, Ralph Lange, joshua-qnx + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#292 `__) +* Update goal response callback signature (`#291 `__) +* Make sure to include what you use in all examples. (`#284 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#292 `__) +* Make sure to include what you use in all examples. (`#284 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#292 `__) +* Make sure to include what you use in all examples. (`#284 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#292 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Unique network flows (`#296 `__) +* Update maintainers (`#292 `__) +* Make sure to include what you use in all examples. (`#284 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#292 `__) +* Make sure to include what you use in all examples. (`#284 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Unique network flows (`#296 `__) +* Update maintainers (`#292 `__) +* Make sure to include what you use in all examples. (`#284 `__) +* Remove a TODO in the not_composable demo. (`#285 `__) +* Add Topic Statistics Example (`#281 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chris Lalancette, Devin Bonnie, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_timer `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#292 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_multithreaded_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use ``char *`` in logging macros (`#295 `__) +* Update maintainers (`#292 `__) +* Added common linters (`#265 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_executors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Update maintainers (`#292 `__) +* Contributors: Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_guard_conditions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Update maintainers (`#292 `__) +* [rclpy] Create a package with an example showing how guard conditions work (`#283 `__) +* Contributors: Audrow Nash, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Using asyncio with ros2 action client (`#301 `__) +* Update maintainers (`#292 `__) +* Added missing linting tests (`#287 `__) +* Contributors: Allison Thackston, Ivan Santiago Paunovic, Shane Loretz, alemme + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Update maintainers (`#292 `__) +* Added missing linting tests (`#287 `__) +* Contributors: Allison Thackston, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Remove bare exception catching (`#299 `__) +* Update maintainers (`#292 `__) +* Contributors: Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Update maintainers (`#292 `__) +* Contributors: Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Update maintainers (`#292 `__) +* Contributors: Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* Update maintainers (`#292 `__) +* Contributors: Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_pointcloud_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#310 `__) +* add pointcloud publisher example (`#276 `__) +* Contributors: Evan Flynn, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg. (`#403 `__) (`#404 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Add pytest.ini so local tests don't display warning (`#276 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`fastrtps_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#69 `__) +* Use CMake config dirs as hint for header/library search (`#56 `__) +* Update package maintainers (`#55 `__) +* QD Update Version Stability to stable version (`#46 `__) +* Contributors: Alejandro Hernández Cordero, Dirk Thomas, Michel Hidalgo, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Port eigen_kdl.h/cpp to ROS2 (`#311 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Contributors: Chris Lalancette, Jafar Abdi + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Finish up API documentation (`#123 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`google_benchmark_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Shrink the size of the tz_offset variable. (`#13 `__) +* Update the patching to work on Windows without admin. (`#11 `__) +* Always preserve source permissions in vendor packages. (`#12 `__) +* Update package maintainers. (`#10 `__) +* Upgrade google benchmark from v1.5.1 to v1.5.2 to include QNX patch. (`#9 `__) +* Set the SOVERSION on benchmark libraries. (`#8 `__) +* Set minimum criteria for system package. (`#3 `__) +* Work around warnings building Google Benchmark w/Clang. (`#2 `__) +* Initial google_benchmark_vendor package. (`#1 `__) +* Initial commit. +* Contributors: Ahmed Sobhy, Chris Lalancette, Michel Hidalgo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [ros2] image_common metapackage (`#129 `__) +* 1.11.11 +* update changelogs +* add Jack as maintainer +* comply to REP 0127 +* add missing description +* define metapackage +* Contributors: Vincent Rabaud, chapulina + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Initialize time stamp for published image messages (`#475 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Added more parameters for camera topic examples (`#465 `__) +* Contributors: Jacob Perron, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix formatting and include paths for linters (`#157 `__) +* Fix QoS initialization from RMW QoS profile (`#158 `__) +* add missing set header (`#140 `__) +* Update to use new count APIs (`#128 `__) +* use latest ros2 API (`#127 `__) +* Update ROS2 branch to account for new NodeOptions interface (`#120 `__) +* camera_info_manager ROS2 port (`#94 `__) +* Pointer api updates (`#104 `__) +* Fix rcutils API change by just removing it. (`#103 `__) +* [ROS2] corrections to remapping for raw images (`#97 `__) +* Make ROS2 ImageTransport conform to old api (`#88 `__) +* Image Transport ROS2 Port (`#84 `__) +* Disable image publisher plugins by name (`#60 `__) * Disable publisher plugins by name * Now have per publisher blacklist instead of image_transport wide. +* update to use non deprecated pluginlib macro +* Extend documentation of ``getCameraInfoTopic`` Document the fact that the ``base_topic`` argument must be resolved in order to build the correct camera info topic. +* Added cv::waitkey(10) for blank popup Without the cv::waitkey(10), it results in a blank popup which crashes/ leads to a black popup. This change corrects that problem. ROS Kinetic, Ubuntu 16.04.3 +* Fix CMake of image_transport/tutorial and polled_camera Fix loads of problems with the CMakeLists. +* image_transport/tutorial: Add dependency on generated msg Without this, build fails on Kinetic because ResizedImage.h has not been generated yet. +* image_transport/tutorial: Add missing catkin_INCLUDE_DIRS Without this, compilation files on Kinetic because ros.h cannot be found. +* 1.11.11 +* update changelogs +* fix linkage in tutorials +* Use $catkin_EXPORTED_TARGETS +* image_transport: fix CameraSubscriber shutdown (circular shared_ptr ref) CameraSubscriber uses a private boost::shared_ptr to share an impl object between copied instances. In CameraSubscriber::CameraSubscriber(), it handed this shared_ptr to boost::bind() and saved the created wall timer in the impl object, thus creating a circular reference. The impl object was therefore never freed. Fix that by passing a plain pointer to boost::bind(). +* avoid a memory copy for the raw publisher +* add a way to publish an image with only the data pointer +* Make function inline to avoid duplicated names when linking statically +* add plugin examples for the tutorial +* update instructions for catkin +* remove uselessly linked library fixes `#28 `__ +* add a tutorial for image_transport +* add Jack as maintainer +* update my email address +* fix the urls +* use the pluginlib script to remove some warnings +* added license headers to various cpp and h files +* get rid of the deprecated class_loader interface +* CMakeLists.txt clean up +* Updated package.xml file(s) to handle new catkin buildtool_depend requirement +* add the right link libraries +* Isolated plugins into their own library to follow new class_loader/pluginlib guidelines. +* remove the brief attribute +* add xml file +* fix bad folder/libraries +* fix dependencies +* add catkin as a dependency +* comply to the catkin API +* install the include directories +* make the libraries public +* catkinize for Groovy +* Initial image_common stack check-in, containing image_transport. +* Contributors: Aaditya Saraiya, Aaron Blasdel, Carl Delsey, Gary Servin, Jacob Perron, Jochen Sprickerhof, Karsten Knese, Lucas Walter, Martin Guenther, Martin Idel, Max Schwarz, Michael Carroll, Mikael Arguedas, Mirza Shah, Thibaud Chupin, Vincent Rabaud, William Woodall, gerkey, kwc, mihelich, mirzashah, pmihelich, straszheim, vrabaud + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`interactive_markers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup bsd 3 clause license usage (`#61 `__) +* Add missing includes (`#81 `__) +* Update maintainers (`#79 `__) +* Increase test timeout necessary for Connext (`#77 `__) +* Fix clang warnings (`#75 `__) +* Remove explicit template parameter in ``spin_until_future_complete`` (`#72 `__) +* Contributors: Bjar Ne, Dirk Thomas, Jacob Perron, Sarthak Mittal, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`intra_process_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`kdl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove tinyxml dependency from kdl_parser. (`#43 `__) +* Remove unused find_library call (`#40 `__) +* Contributors: Chris Lalancette, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`laser_geometry `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use rclcpp::Duration::from_seconds (`#72 `__) +* update maintainers +* increase test timeout +* Contributors: Dirk Thomas, Ivan Santiago Paunovic, Jonathan Binney, Mabel Zhang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Only try to wrap the fd in a socket on Windows (`#498 `__) +* Close the socket pair used for signal management (`#497 `__) +* Remove is_winsock_handle() and instead test if wrapping the handle in a socket.socket() works (`#494 `__) +* Add frontend substitution for logging directory (`#490 `__) +* Add arg_choice arg to DeclareLaunchArguments (`#483 `__) +* Support Python 3.8-provided importlib.metadata (`#482 `__) +* Workaround asyncio signal handling on Unix (`#479 `__) +* Handle signals within the asyncio loop. (`#476 `__) +* Support non-interactive launch.LaunchService runs (`#475 `__) +* print stderr message when command failed (`#474 `__) +* Add frontend support for LogInfo action (`#467 `__) +* Validate unparsed attributes and subentities in launch_xml and launch_yaml (`#468 `__) +* Fix bug in launch.actions.TimerAction.parse() (`#470 `__) +* Allow configuring logging directory through environment variables (`#460 `__) +* Update package maintainers (`#465 `__) +* Expose Timer action in launch xml (`#462 `__) +* Fix dollar symbols in substitution grammar (`#461 `__) +* Add new conditions for checking launch configuration values (`#453 `__) +* Refactor launch service run_async loop to wait on futures and queued events (`#449 `__) +* Fix documentation typo (`#446 `__) +* Fix type_utils.extract_type() function. (`#445 `__) +* Handle empty strings in type coercion. (`#443 `__) +* Consolidate type_utils in a way that can be reused in substitution results that need to be coerced to a specific type (`#438 `__) +* Delete unnecessary loading of 'launch.frontend.interpolate_substitution_method' entry point that was never used (`#434 `__) +* Avoid side effect, defer until needed (`#432 `__) +* Remove pkg_resources, replace it with the use of the more modern importlib* libraries. (`#430 `__) +* Remove the asyncio.wait loop parameter. (`#429 `__) +* Add pytest.ini so local tests don't display warning (`#428 `__) +* Defer shutdown if already running (`#427 `__) +* Add respawn and respawn_delay support (`#426 `__) +* Fix up parser.py (`#414 `__) +* Contributors: CHEN, Chris Lalancette, Christophe Bedard, Dan Rose, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Michel Hidalgo, Scott K Logan, Takamasa Horibe, Victor Lopez + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support Python 3.8 importlib.metadata, declare dependency (`#229 `__) +* Add options extensions to ros2launch and extensibility to the node action (`#216 `__) +* Make sure ParameterFile __del_\_ works without exception. (`#212 `__) +* Fix docblock in LoadComposableNodes (`#207 `__) +* Validate complex attributes of 'node' action (`#198 `__) +* Node.__init_\_() executable and ComposableNode.__init_\_() plugin arguments aren't optional (`#197 `__) +* Remove constructors arguments deprecated since Foxy (`#190 `__) +* Make name and namespace mandatory in ComposableNodeContainer, remove deprecated alternatives (`#189 `__) +* Merge pull request `#183 `__ from ros2/update-maintainers Update the package.xml files with the latest Open Robotics maintainers +* Move previous maintainer to +* Update the package.xml files with the latest Open Robotics maintainers +* Fix AttributeError when accessing component container name (`#177 `__) +* Handle any substitution types for SetParameter name argument (`#182 `__) +* Asynchronously wait for load node service response (`#174 `__) +* Fix case where list of composable nodes is zero (`#173 `__) +* Do not use event handler for loading composable nodes (`#170 `__) +* Fix race with launch context changes when loading composable nodes (`#166 `__) +* Substitutions in parameter files (`#168 `__) +* Fix documentation typo (`#167 `__) +* Fix problems when parsing a ``Command`` ``Substitution`` as a parameter value (`#137 `__) +* Add a way to set remapping rules for all nodes in the same scope (`#163 `__) +* Resolve libyaml warning when loading parameters from file (`#161 `__) +* Fix ComposableNode ignoring PushRosNamespace actions (`#162 `__) +* Add a SetParameter action that sets a parameter to all nodes in the same scope (`#158 `__) +* Make namespace parameter mandatory in LifecycleNode constructor (`#157 `__) +* Avoid using a wildcard to specify parameters if possible (`#154 `__) +* Fix no specified namespace (`#153 `__) +* Add pytest.ini so local tests don't display warning (`#152 `__) +* Contributors: Chris Lalancette, Dereck Wonnacott, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use unittest.mock instead of mock (`#487 `__) +* Update package maintainers (`#465 `__) +* Disable cleanup of test cases once they have been run (`#406 `__) +* Fix max() with empty sequence (`#440 `__) +* Use unittest.TestCase.id() for pytest failure reprs. (`#436 `__) +* Use unittest.TestCase.id() to put together jUnit XML output. (`#435 `__) +* Claim ownership (`#433 `__) +* Contributors: Dirk Thomas, Michel Hidalgo, Scott K Logan, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers (`#465 `__) +* Add bsd license to launch due to files from roslaunch (`#456 `__) +* Use launch_test CMake target as output file basename (`#448 `__) +* Find Python debug interpreter on Windows (`#437 `__) +* Contributors: Dirk Thomas, Michel Hidalgo, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores in setup.cfg instead of dashes. (`#227 `__) +* Merge pull request `#183 `__ from ros2/update-maintainers +* Move Pete to author, per clalancette +* Update the package.xml files with the latest Open Robotics maintainers +* Add pytest.ini so local tests don't display warning (`#152 `__) +* Contributors: Chris Lalancette, Michael Jeronimo, Mike Purvis + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_xml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add frontend support for LogInfo action (`#467 `__) +* Validate unparsed attributes and subentities in launch_xml and launch_yaml (`#468 `__) +* Add test for launch.actions.TimerAction (`#470 `__) +* Update package maintainers (`#465 `__) +* Use new type_utils functions (`#438 `__) +* Add pytest.ini so local tests don't display warning (`#428 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_yaml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add frontend support for LogInfo action (`#467 `__) +* Validate unparsed attributes and subentities in launch_xml and launch_yaml (`#468 `__) +* Update package maintainers (`#465 `__) +* Use new type_utils functions (`#438 `__) +* Close YAML file when we're done. (`#415 `__) +* Add pytest.ini so local tests don't display warning (`#428 `__) +* Contributors: Chris Lalancette, Dan Rose, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libcurl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update libcurl_vendor to the latest version (7.75.0). (`#60 `__) +* Add an override flag to force vendored build (`#58 `__) +* Update maintainers (`#53 `__) +* bump curl version to 7.68 (`#47 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libstatistics_collector `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix: measured values after the decimal point are truncated `#79 `__ (`#80 `__) +* Update linter to run on rolling+focal (`#81 `__) +* Add automerge.yml config file (`#70 `__) +* Update QD to QL 1 (`#68 `__) +* Updated QD (`#64 `__) +* Updated QD Performance tests (`#58 `__) +* Added benchmark test to libstatistics_collector (`#57 `__) * Added benchmark test to libstatistics_collector * cppcheck supressed unknown macro warning - macos * Reset heap counters * Added feedback * Remove unknownMacro suppression from CMakeLists.txt * Added feedback * moved benchmark test to test/benchmark * Added feedback Co-authored-by: Devin Bonnie <47613035+dabonnie@users.noreply.github.com> +* Report failed workflows (`#56 `__) Allow codecov failures to be silent +* Add default CODEOWNERS file (`#55 `__) +* Remove repo activity from individual repositories in favor of centralized reporting (`#52 `__) +* Don't attempt to report if originating from a fork (`#43 `__) +* Removed doxygen warnings (`#41 `__) Co-authored-by: Anas Abou Allaban +* Add autoapprove action for dependabot (`#40 `__) +* Create Dependabot config file (`#31 `__) * Create Dependabot config file * Randomize time of run Co-authored-by: dependabot-preview[bot] <27856297+dependabot-preview[bot]@users.noreply.github.com> Co-authored-by: Prajakta Gokhale +* Updated QD to 3 (`#30 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#24 `__) Co-authored-by: Emerson Knapp <537409+emersonknapp@users.noreply.github.com> +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Devin Bonnie, Emerson Knapp, Lucas Han, Prajakta Gokhale, Stephen Brawner, hsgwa + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libyaml_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#38 `__) +* Update libyaml_vendor to 0.2.5. (`#37 `__) +* Fix linker flags for tests when CMake < 3.13 (`#35 `__) +* Always preserve source permissions in vendor packages (`#31 `__) +* Fix target_link_directories/link_directories in cmake (`#29 `__) +* Included benchmark tests (`#20 `__) +* Update Quality Declaration (`#23 `__) +* Update package maintainers. (`#22 `__) +* Bump QD to 3 and some minor style fixes (`#19 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#18 `__) +* Add quality declaration libyaml_vendor (`#12 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jorge Perez, Michel Hidalgo, Scott K Logan, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup the README.rst for the lifecycle demo. (`#508 `__) +* change ParameterEventHandler to take events as const ref instead of shared pointer (`#494 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Add missing required parameter in LifecycleNode launch action (`#456 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michael Jeronimo, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#122 `__) +* Updating Quality Declaration (`#120 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`logging_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update logging macros (`#476 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Audrow Nash, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`map_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update maintainers +* Contributors: Mabel Zhang, Steve Macenski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`message_filters `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Find and export dependencies properly (`#54 `__) +* Add pytest.ini so local tests don't display warning (`#47 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mimick_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Always preserve source permissions in vendor packages (`#19 `__) +* Suppress update of pinned git repository (`#17 `__) +* Don't overwrite -Wno-dev CMake argument (`#18 `__) +* Add missing build tool dependency on 'git' (`#16 `__) +* Update tag for armv7l support. (`#15 `__) +* Update tag for new cmake version requirement (`#14 `__) +* Export include directories (`#13 `__) +* Update package maintainers (`#10 `__) +* Suppress cppcheck for MMK_MANGLE\_ (`#8 `__) +* Change Mimick tagged version. (`#7 `__) +* Change tag to pull latest Mimick version (`#6 `__) +* Pin Mimick version. (`#5 `__) +* Change imported dep to match ROS 2 fork (`#4 `__) +* Avoid CMAKE_BUILD_TYPE warnings on Windows. (`#3 `__) +* Remove dep tag + add maintainer(`#2 `__) +* Configure MSVC x64 builds when appropriate. (`#1 `__) +* First iteration vendor for Mimick library +* Contributors: Jorge Perez, Michel Hidalgo, Scott K Logan, Stephen Brawner, brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`nav_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Add LoadMap service (`#129 `__) +* Update Quality levels to level 3 (`#124 `__) +* Finish up API documentation (`#123 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, Steve Macenski, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix osrf.py_common.process_utils.get_loop() implementation (`#70 `__) +* Python 2/3 version conflict (`#69 `__) +* remove jessie because we no longer support 3.4 (`#67 `__) +* Remove deprecated use of asyncio.coroutine decorator. (`#64 `__) +* Fix the __str_\_ method for windows terminal_color. (`#65 `__) +* Contributors: Chris Lalancette, Jochen Sprickerhof, Michel Hidalgo, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_testing_tools_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [osrf_testing_tools_cpp] Add warnings (`#54 `__) +* Update cmake minimum version to 2.8.12 (`#61 `__) +* Add googletest v1.10.0 (`#55 `__) +* Workarounds for Android (`#52 `__) (`#60 `__) +* Change ``WIN32`` to ``__WIN32`` (`#53 `__) +* fix execinfo.h not found for QNX (`#50 `__) +* Contributors: Ahmed Sobhy, Audrow Nash, Dan Rose, Jacob Perron, Stephen Brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_control `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace rmw_connext_cpp with rmw_connextdds (`#489 `__) +* Remove ineffective log output (`#450 `__) (`#477 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Remove deprecated warning (`#459 `__) +* Follow API/file name changes (`ros2/realtime_support#94 `__) (`#451 `__) +* Contributors: Anas Abou Allaban, Andrea Sorbini, Michael Jeronimo, y-okumura-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`performance_test_fixture `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Record calls to calloc, update tests (`#15 `__) +* Make allocation counter atomic (`#13 `__) Even if the benchmark itself isn't threaded, the process we're testing could be. In any case, this should prevent those shenanigans from messing up the measurement. +* Add methods for pausing/resuming performance metrics (`#10 `__) * Add methods for pausing/resuming performance metrics +* Add benchmarks to evaluate overhead (`#11 `__) * Add benchmarks to evaluate overhead in performance tests +* Add namespace performance_test_fixture to .cpp (`#9 `__) +* Export dependency on benchmark and osrf_testing_tools_cpp (`#8 `__) +* Update maintainers (`#7 `__) +* Expose a function for resetting the heap counters (`#6 `__) +* Stop recording memory operations sooner (`#5 `__) +* Suppress memory tools warning if tests will be skipped (`#4 `__) +* Export dependency on ament_cmake_google_benchmark (`#3 `__) +* Add missing dependency on ament_cmake_google_benchmark (`#2 `__) +* Initial 'performance_test_fixture' package (`#1 `__) +* Initial commit +* Contributors: Alejandro Hernández Cordero, Scott K Logan, brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pluginlib `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use rcpputils for the filesystem implementation. (`#212 `__) +* Check for NULL in XMLElement::Attribute +* Check for NULL in XMLElement::GetText +* Check for NULL in XMLNode::Value +* Remove unused variable output_library (`#211 `__) +* Make Chris a maintainer of pluginlib. (`#210 `__) +* Add QNX C++ fs library compiler option (`#205 `__) +* Fix cmake 3.5 compatibility (`#203 `__) +* Add function for same-package pluginlib tests (`#201 `__) +* Remove deprecated boost functions (`#199 `__) +* Contributors: Ahmed Sobhy, Chris Lalancette, Jeremie Deray, Karsten Knese, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pybind11_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#7 `__) +* Merge pull request `#3 `__ from ros2/fix_windows_warning +* remove passing in CMAKE_BUILD_TYPE Signed-off-by: Mabel Zhang +* cleanup Signed-off-by: Mabel Zhang +* do not define CMAKE_BUILD_TYPE on windows Signed-off-by: Mabel Zhang +* suppress all developer warnings Signed-off-by: Mabel Zhang +* suppress warning on windows Signed-off-by: Mabel Zhang +* attempt to fix windows warning Signed-off-by: Mabel Zhang +* Disable building pybind11 tests (`#1 `__) Signed-off-by: Karsten Knese +* Update to pybind 2.5.0 (`#2 `__) Signed-off-by: Mabel Zhang +* Create pybind11 vendor package. Signed-off-by: Michael Carroll +* Contributors: Karsten Knese, Mabel Zhang, Michael Carroll, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#2 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_qt_binding `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add repo README +* Shorten some long lines of CMake (`#99 `__) +* Update maintainers (`#96 `__) (`#98 `__) +* Add pytest.ini so local tests don't display warning (`#93 `__) +* Contributors: Chris Lalancette, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_dotgraph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add API to set edge tooltip (`#237 `__) + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Always prefer 'Tango' icon theme (`#250 `__) +* Fix 'dict_keys' object not subscriptable (`#243 `__) +* allow hide title in standalone (`#235 `__) +* add logic to load qt_gui_icons on windows and macOS (`#222 `__) +* fix exporting perspective for Python 3.6 (`#228 `__) +* remove tango-icon-theme dependency (`#224 `__) +* Contributors: Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix duplicated QMap to QMultiMap (`#244 `__) +* Switch to using the filesystem implementation in rcpputils. (`#239 `__) +* avoid a warning about C++ plugins on Windows (`#232 `__) +* qt_gui_cpp_sip: declare private assignment operator for SIP (`#226 `__) +* Contributors: Chris Lalancette, Homalozoa X + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add demo of how to use qos overrides (`#474 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Update comments in quality_of_service_demo_cpp message_lost_talker and message_lost_listener (`#458 `__) +* Add message lost status event demo using rclcpp (`#453 `__) +* Contributors: Ivan Santiago Paunovic, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#502 `__) +* QoS overrides demo in python (`#479 `__) +* Update deprecated qos policy value names (`#468 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Add rclpy message lost status event demo (`#457 `__) +* Contributors: Ivan Santiago Paunovic, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix up test_network_flow_endpoints. (`#912 `__) +* Make test_two_timers_ready_before_timeout less flaky (`#911 `__) +* Add publishing instrumentation (`#905 `__) +* Unique network flows (`#880 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) +* Add functions for waiting for publishers and subscribers (`#907 `__) +* Revert "Mark cyclonedds test_service test as flakey (`#648 `__)" (`#904 `__) +* Guard against returning NULL or empty node names (`#570 `__) +* Remove exceptions for rmw_connext_cpp tests. (`#903 `__) +* Add support for rmw_connextdds (`#895 `__) +* Put an argument list of 'void' where no arguments are expected. (`#899 `__) +* Cleanup documentation for doxygen. (`#896 `__) +* Reference test resources directly from source tree (`#554 `__) +* Re-add "Improve trigger test for graph guard condition (`#811 `__)" (`#884 `__) +* Revert "Improve trigger test for graph guard condition (`#811 `__)" (`#883 `__) +* Move the guard condition cleanup after removing callback. (`#877 `__) +* Make test_subscription_nominal_string_sequence more reliable (`#881 `__) +* Improve trigger test for graph guard condition (`#811 `__) +* Add NULL check in remap.c (`#879 `__) +* Add const to constant rcl_context functions (`#872 `__) +* Fix another failing test on CentOS 7 (`#863 `__) +* Update QDs to QL 1 (`#866 `__) +* Address clang static analysis issues (`#865 `__) +* Fix flaky test_info_by_topic (`#859 `__) +* Update QL (`#858 `__) +* Refactor for removing unnecessary source code (`#857 `__) +* Clarify storing of current_time (`#850 `__) +* Make tests in test_graph.cpp more reliable (`#854 `__) +* Fix for external log segfault after SIGINT (`#844 `__) +* Update tracetools QL and add to rcl_lifecycle's QD (`#845 `__) +* Make test logging rosout more reliable (`#846 `__) +* Return OK when finalizing zero-initialized contexts (`#842 `__) +* Zero initialize events an size_of_events members of rcl_wait_set_t (`#841 `__) +* Update deprecated gtest macros (`#818 `__) +* Make sure to check the return value of rcl APIs. (`#838 `__) +* Add convenient node method to get a final topic/service name (`#835 `__) +* Remove redundant error formatting (`#834 `__) +* Fix memory leak in rcl_subscription_init()/rcl_publisher_init() (`#794 `__) +* Update maintainers (`#825 `__) +* Add a semicolon to RCUTILS_LOGGING_AUTOINIT. (`#816 `__) +* Improve error messages in rcl_lifecycle (`#742 `__) +* Fix memory leak on serialized message in test_publisher/subscription.cpp (`#801 `__) +* Fix memory leak because of mock test (`#800 `__) +* Spelling correction (`#798 `__) +* Fix that not to deallocate event impl in some failure case (`#790 `__) +* calling fini functions to avoid memory leak (`#791 `__) +* Bump rcl arguments' API test coverage (`#777 `__) +* Fix rcl arguments' API memory leaks and bugs (`#778 `__) +* Add coverage tests wait module (`#769 `__) +* Fix wait set allocation cleanup (`#770 `__) +* Improve test coverage in rcl (`#764 `__) +* Check if rcutils_strdup() outcome immediately (`#768 `__) +* Cleanup rcl_get_secure_root() implementation (`#762 `__) +* Add fault injection macros to rcl functions (`#727 `__) +* Yield rcl_context_fini() error codes (`#763 `__) +* Do not invalidate context before successful shutdown (`#761 `__) +* Zero initialize guard condition on failed init (`#760 `__) +* Adding tests to arguments API (`#752 `__) +* Extend rcl_expand_topic_name() API test coverage (`#758 `__) +* Add coverage tests 94% to service API (`#756 `__) +* Clean up rcl_expand_topic_name() implementation (`#757 `__) +* Complete rcl enclave validation API coverage (`#751 `__) +* Cope with base function restrictions in mocks (`#753 `__) +* Fix allocation when copying arguments (`#748 `__) +* Complete rcl package's logging API test coverage (`#747 `__) +* Improve coverage to 95% in domain id, init option, rmw implementation id and log level modules (`#744 `__) +* Fix rcl package's logging API error code documentation and handling (`#746 `__) +* Fix bug error handling in get_param_files (`#743 `__) +* Complete subscription API test coverage (`#734 `__) +* increase timeouts in test_services fixtures for Connext (`#745 `__) +* Tweaks to client.c and subscription.c for cleaner init/fini (`#728 `__) +* Improve error checking and handling in subscription APIs (`#739 `__) +* Add deallocate calls to free strdup allocated memory (`#737 `__) +* Add missing calls to rcl_convert_rmw_ret_to_rcl_ret (`#738 `__) +* Add mock tests, publisher 95% coverage (`#732 `__) +* Restore env variables set in the test_failing_configuration. (`#733 `__) +* Expose qos setting for /rosout (`#722 `__) +* Reformat rmw_impl_id_check to call a testable function (`#725 `__) +* Add extra check for invalid event implementation (`#726 `__) +* Consolidate macro duplication (`#653 `__) +* Add test for subscription message lost event (`#705 `__) +* Add function rcl_event_is_valid (`#720 `__) +* Move actual domain id from node to context (`#718 `__) +* Removed doxygen warnings (`#712 `__) +* Remove some dead code. +* Make sure to call rcl_arguments_fini at the end of the test. +* Add remap needed null check (`#711 `__) +* Make public init/fini rosout publisher (`#704 `__) +* Move rcl_remap_copy to public header (`#709 `__) +* Implement a generic way to change logging levels (`#664 `__) +* Remove domain_id and localhost_only from node_options (`#708 `__) +* Add coverage tests (`#703 `__) +* Add bad arguments tests for coverage (`#698 `__) +* Remove unused internal prototypes (`#699 `__) +* Update quality declaration and coverage (`#674 `__) +* Add setter and getter for domain_id in rcl_init_options_t (`#678 `__) +* Remove unused pytest dependency from rcl. (`#695 `__) +* Fix link to latest API docs (`#692 `__) +* Keep domain id if ROS_DOMAIN_ID is invalid. (`#689 `__) +* Remove unused check context.c (`#691 `__) +* Add check rcl_node_options_copy invalid out (`#671 `__) +* Update tracetools' QL to 2 in rcl's QD (`#690 `__) +* Improve subscription coverage (`#681 `__) +* Improve rcl timer test coverage (`#680 `__) +* Improve wait sets test coverage (`#683 `__) +* Improve rcl init test coverage. (`#684 `__) +* Improve clock test coverage. (`#685 `__) +* Add message lost event (`#673 `__) +* Minor fixes to rcl clock implementation. (`#688 `__) +* Improve enclave validation test coverage. (`#682 `__) +* Use RCL_RET\_* codes only. (`#686 `__) +* Fixed doxygen warnings (`#677 `__) +* Add tests for rcl package (`#668 `__) +* Remove logging_external_interface.h, provided by rcl_logging_interface package now (`#676 `__) +* Print RCL_LOCALHOST_ENV_VAR if error happens via rcutils_get_env. (`#672 `__) +* Contributors: Ada-King, Alejandro Hernández Cordero, Ananya Muddukrishna, Andrea Sorbini, Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Dan Rose, Dirk Thomas, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Lei Liu, Michel Hidalgo, Nikolai Morin, Scott K Logan, Stephen Brawner, Thijs Raymakers, brawner, shonigmann, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) +* Don't expect RCL_RET_TIMEOUT to set an error string (`#900 `__) +* Add support for rmw_connextdds (`#895 `__) +* Avoid setting error message twice. (`#887 `__) +* Address various clang static analysis fixes (`#864 `__) +* Update QDs to QL 1 (`#866 `__) +* Update QL (`#858 `__) +* Make sure to always check return values (`#840 `__) +* Update deprecated gtest macros (`#818 `__) +* Make sure to check the return value of rcl APIs. (`#838 `__) +* Update maintainers (`#825 `__) +* Store reference to rcl_clock_t instead of copy (`#797 `__) +* Use valid clock in case of issue in rcl_timer_init (`#795 `__) +* Add fault injection macros and unit tests to rcl_action (`#730 `__) +* Change some EXPECT_EQ to ASSERT_EQ in test_action_server. (`#759 `__) +* Removed doxygen warnings (`#712 `__) +* Address issue 716 by zero initializing pointers and freeing memory (`#717 `__) +* Update quality declaration and coverage (`#674 `__) +* Fixed doxygen warnings (`#677 `__) +* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Audrow Nash, Chen Lihui, Chris Lalancette, Ivan Santiago Paunovic, Shane Loretz, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#122 `__) +* Updating Quality Declaration (`#120 `__) +* Add field to the parameter description to specify dynamic/static typing. (`#118 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) +* make rcl_lifecycle_com_interface optional in lifecycle nodes (`#882 `__) +* Update QDs to QL 1 (`#866 `__) +* Update QL (`#858 `__) +* Make sure to always check return values (`#840 `__) +* Update tracetools QL and add to rcl_lifecycle's QD (`#845 `__) +* Add compiler warnings (`#830 `__) +* Make sure to check the return value of rcl APIs. (`#838 `__) +* Add lifecycle node state transition instrumentation (`#804 `__) +* Update maintainers (`#825 `__) +* Improve error messages in rcl_lifecycle (`#742 `__) +* Fix test_rcl_lifecycle (`#788 `__) +* Add fault injection macros and unit tests to rcl_lifecycle (`#731 `__) +* Remove std::cout line from test_rcl_lifecycle.cpp (`#773 `__) +* Set transition_map->states/transition size to 0 on fini (`#729 `__) +* Topic fix rcl lifecycle test issue (`#715 `__) +* Removed doxygen warnings (`#712 `__) +* Update quality declaration and coverage (`#674 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Barry Xu, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Karsten Knese, Lei Liu, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update QD to QL 1 (`#66 `__) +* Use rcutils_expand_user in rcl_logging_get_logging_directory (`#59 `__) +* Allow configuring logging directory through environment variables (`#53 `__) +* Update the maintainers. (`#55 `__) +* Add new package with rcl logging interface (`#41 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Stephen Brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_log4cxx `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow configuring logging directory through environment variables (`#53 `__) +* Update the maintainers. (`#55 `__) +* Remove unused pytest dependency. (`#43 `__) +* Use new package with rcl logging interface (`#41 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_noop `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make internal dependencies private (`#60 `__) +* Update the maintainers. (`#55 `__) +* Remove unused pytest dependency. (`#43 `__) +* Use new package with rcl logging interface (`#41 `__) +* Contributors: Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_spdlog `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#73 `__) +* Include what you use (`#71 `__) +* Update QD to QL 1 (`#66 `__) +* Make sure to check return value from external_initialize. (`#65 `__) +* updated QD section 3.i and 3ii and spelling error (`#63 `__) +* rcl_logging_spdlog: Increased QL to 2 in QD +* Updated spdlog QL in QD +* Make internal dependencies private (`#60 `__) +* [rcl_logging_spdlog] Add warnings (`#54 `__) +* Allow configuring logging directory through environment variables (`#53 `__) +* Update the maintainers. (`#55 `__) +* Added benchmark test to rcl_logging_spdlog (`#52 `__) +* Used current_path() function from rcpputils (`#51 `__) +* Add fault injection unittest to increase coverage (`#49 `__) +* Bump QD to level 3 and updated QD (`#44 `__) +* Added Doxyfile and fixed related warnings (`#42 `__) +* Use new package with rcl logging interface (`#41 `__) +* Increased test coverage (`#40 `__) +* Add Security Vulnerability Policy pointing to REP-2006. +* Rename Quality_Declaration.md -> QUALITY_DECLARATION.md +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Scott K Logan, Shane Loretz, Stephen Brawner, ahcorde, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_yaml_param_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#909 `__) +* Enable compiler warnings (`#831 `__) +* Update QDs to QL 1 (`#866 `__) +* Rearrange test logic to avoid reference to null (`#862 `__) +* Update QL (`#858 `__) +* Make sure to initialize the end_mark for yaml_event_t (`#849 `__) +* Check for valid node names in parameters files (`#809 `__) +* Update maintainers (`#825 `__) +* Updated performance section QD (`#817 `__) +* Several memory-related fixes for rcl_variant_t benchmarks (`#813 `__) +* Improved rcl_yaml_param_parser benchmark test (`#810 `__) +* Added benchmark test to rcl_yaml_param_parser (`#803 `__) +* Remove MAX_NUM_PARAMS_PER_NODE and MAX_NUM_NODE_ENTRIES limitation. (`#802 `__) +* Add mocking unit tests for rcl_yaml_param_parser (coverage part 3/3) (`#772 `__) +* Add fault-injection unit tests (coverage part 2/3) (`#766 `__) +* Add basic unit tests for refactored functions in rcl_yaml_param_parser (coverage part 1/3) (`#771 `__) +* Fix yaml parser error when meets .nan (refactor on `#754 `__) (`#781 `__) +* Refactor parser.c for better testability (`#754 `__) +* Don't overwrite cur_ns pointer if reallocation fails (`#780 `__) +* Fix mem leaks in unit test from 776 (`#779 `__) +* Fix rcl_parse_yaml_file() error handling. (`#776 `__) +* Don't overwrite string_array pointer on reallocation failure (`#775 `__) +* Set yaml_variant values to NULL on finalization (`#765 `__) +* Remove debugging statements. (`#755 `__) +* Removed doxygen warnings (`#712 `__) +* Update quality declaration and coverage (`#674 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chen Lihui, Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, Stephen Brawner, brawner, shonigmann, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use OnShutdown callback handle instead of OnShutdown callback (`#1639 `__) (`#1650 `__) +* use dynamic_pointer_cast to detect allocator mismatch in intra process manager (`#1643 `__) (`#1644 `__) +* Increase cppcheck timeout to 500s (`#1634 `__) +* Clarify node parameters docs (`#1631 `__) +* Avoid returning loan when none was obtained. (`#1629 `__) +* Use a different implementation of mutex two priorities (`#1628 `__) +* Do not test the value of the history policy when testing the get_publishers/subscriptions_info_by_topic() methods (`#1626 `__) +* Check first parameter type and range before calling the user validation callbacks (`#1627 `__) +* Restore test exception for Connext (`#1625 `__) +* Fix race condition in TimeSource clock thread setup (`#1623 `__) +* remove deprecated code which was deprecated in foxy and should be removed in galactic (`#1622 `__) +* Change index.ros.org -> docs.ros.org. (`#1620 `__) +* Unique network flows (`#1496 `__) +* Add spin_some support to the StaticSingleThreadedExecutor (`#1338 `__) +* Add publishing instrumentation (`#1600 `__) +* Create load_parameters and delete_parameters methods (`#1596 `__) +* refactor AnySubscriptionCallback and add/deprecate callback signatures (`#1598 `__) +* Add generic publisher and generic subscription for serialized messages (`#1452 `__) +* use context from ``node_base\_`` for clock executor. (`#1617 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) +* Initialize integers in test_parameter_event_handler.cpp to avoid undefined behavior (`#1609 `__) +* Namespace tracetools C++ functions (`#1608 `__) +* Revert "Namespace tracetools C++ functions (`#1603 `__)" (`#1607 `__) +* Namespace tracetools C++ functions (`#1603 `__) +* Clock subscription callback group spins in its own thread (`#1556 `__) +* Remove rmw_connext_cpp references. (`#1595 `__) +* Add API for checking QoS profile compatibility (`#1554 `__) +* Document misuse of parameters callback (`#1590 `__) +* use const auto & to iterate over parameters (`#1593 `__) +* Guard against integer overflow in duration conversion (`#1584 `__) +* get_parameters service should return empty if undeclared parameters are allowed (`#1514 `__) +* Made 'Context::shutdown_reason' function a const function (`#1578 `__) +* Document design decisions that were made for statically typed parameters (`#1568 `__) +* Fix doc typo in CallbackGroup constructor (`#1582 `__) +* Enable qos parameter overrides for the /parameter_events topic (`#1532 `__) +* Add support for rmw_connextdds (`#1574 `__) +* Remove 'struct' from the rcl_time_jump_t. (`#1577 `__) +* Add tests for declaring statically typed parameters when undeclared parameters are allowed (`#1575 `__) +* Quiet clang memory leak warning on "DoNotOptimize". (`#1571 `__) +* Add ParameterEventsSubscriber class (`#829 `__) +* When a parameter change is rejected, the parameters map shouldn't be updated. (`#1567 `__) +* Fix when to throw the NoParameterOverrideProvided exception. (`#1567 `__) +* Fix SEGV caused by order of destruction of Node sub-interfaces (`#1469 `__) +* Fix benchmark test failure introduced in `#1522 `__ (`#1564 `__) +* Fix documented example in create_publisher (`#1558 `__) +* Enforce static parameter types (`#1522 `__) +* Allow timers to keep up the intended rate in MultiThreadedExecutor (`#1516 `__) +* Fix UBSAN warnings in any_subscription_callback. (`#1551 `__) +* Fix runtime error: reference binding to null pointer of type (`#1547 `__) +* Reference test resources directly from source tree (`#1543 `__) +* clear statistics after window reset (`#1531 `__) (`#1535 `__) +* Fix a minor string error in the topic_statistics test. (`#1541 `__) +* Avoid ``Resource deadlock avoided`` if use intra_process_comms (`#1530 `__) +* Avoid an object copy in parameter_value.cpp. (`#1538 `__) +* Assert that the publisher_list size is 1. (`#1537 `__) +* Don't access objects after they have been std::move (`#1536 `__) +* Update for checking correct variable (`#1534 `__) +* Destroy msg extracted from LoanedMessage. (`#1305 `__) +* Add instrumentation for linking a timer to a node (`#1500 `__) +* Fix error when using IPC with StaticSingleThreadExecutor (`#1520 `__) +* Change to using unique_ptrs for DummyExecutor. (`#1517 `__) +* Allow reconfiguring 'clock' topic qos (`#1512 `__) +* Allow to add/remove nodes thread safely in rclcpp::Executor (`#1505 `__) +* Call rclcpp::shutdown in test_node for clean shutdown on Windows (`#1515 `__) +* Reapply "Add get_logging_directory method to rclcpp::Logger (`#1509 `__)" (`#1513 `__) +* use describe_parameters of parameter client for test (`#1499 `__) +* Revert "Add get_logging_directory method to rclcpp::Logger (`#1509 `__)" (`#1511 `__) +* Add get_logging_directory method to rclcpp::Logger (`#1509 `__) +* Better documentation for the QoS class (`#1508 `__) +* Modify excluding callback duration from topic statistics (`#1492 `__) +* Make the test of graph users more robust. (`#1504 `__) +* Make sure to wait for graph change events in test_node_graph. (`#1503 `__) +* add timeout to SyncParametersClient methods (`#1493 `__) +* Fix wrong test expectations (`#1497 `__) +* Update create_publisher/subscription documentation, clarifying when a parameters interface is required (`#1494 `__) +* Fix string literal warnings (`#1442 `__) +* support describe_parameters methods to parameter client. (`#1453 `__) +* Add getters to rclcpp::qos and rclcpp::Policy enum classes (`#1467 `__) +* Change nullptr checks to use ASSERT_TRUE. (`#1486 `__) +* Adjust logic around finding and erasing guard_condition (`#1474 `__) +* Update QDs to QL 1 (`#1477 `__) +* Add performance tests for parameter transport (`#1463 `__) +* Move ownership of shutdown_guard_condition to executors/graph_listener (`#1404 `__) +* Add options to automatically declare qos parameters when creating a publisher/subscription (`#1465 `__) +* Add ``take_data`` to ``Waitable`` and ``data`` to ``AnyExecutable`` (`#1241 `__) +* Add benchmarks for node parameters interface (`#1444 `__) +* Remove allocation from executor::remove_node() (`#1448 `__) +* Fix test crashes on CentOS 7 (`#1449 `__) +* Bump rclcpp packages to Quality Level 2 (`#1445 `__) +* Added executor benchmark tests (`#1413 `__) +* Add fully-qualified namespace to WeakCallbackGroupsToNodesMap (`#1435 `__) +* Deprecate Duration(rcl_duration_value_t) in favor of static Duration::from_nanoseconds(rcl_duration_value_t) (`#1432 `__) +* Avoid parsing arguments twice in ``rclcpp::init_and_remove_ros_arguments`` (`#1415 `__) +* Add service and client benchmarks (`#1425 `__) +* Set CMakeLists to only use default rmw for benchmarks (`#1427 `__) +* Update tracetools' QL in rclcpp's QD (`#1428 `__) +* Add missing locking to the rclcpp_action::ServerBase. (`#1421 `__) +* Initial benchmark tests for rclcpp::init/shutdown create/destroy node (`#1411 `__) +* Refactor test CMakeLists in prep for benchmarks (`#1422 `__) +* Add methods in topic and service interface to resolve a name (`#1410 `__) +* Update deprecated gtest macros (`#1370 `__) +* Clear members for StaticExecutorEntitiesCollector to avoid shared_ptr dependency (`#1303 `__) +* Increase test timeouts of slow running tests with rmw_connext_cpp (`#1400 `__) +* Avoid self dependency that not destoryed (`#1301 `__) +* Update maintainers (`#1384 `__) +* Add clock qos to node options (`#1375 `__) +* Fix NodeOptions copy constructor (`#1376 `__) +* Make sure to clean the external client/service handle. (`#1296 `__) +* Increase coverage of WaitSetTemplate (`#1368 `__) +* Increase coverage of guard_condition.cpp to 100% (`#1369 `__) +* Add coverage statement (`#1367 `__) +* Tests for LoanedMessage with mocked loaned message publisher (`#1366 `__) +* Add unit tests for qos and qos_event files (`#1352 `__) +* Finish coverage of publisher API (`#1365 `__) +* Finish API coverage on executors. (`#1364 `__) +* Add test for ParameterService (`#1355 `__) +* Add time API coverage tests (`#1347 `__) +* Add timer coverage tests (`#1363 `__) +* Add in additional tests for parameter_client.cpp coverage. +* Minor fixes to the parameter_service.cpp file. +* reset rcl_context shared_ptr after calling rcl_init sucessfully (`#1357 `__) +* Improved test publisher - zero qos history depth value exception (`#1360 `__) +* Covered resolve_use_intra_process (`#1359 `__) +* Improve test_subscription_options (`#1358 `__) +* Add in more tests for init_options coverage. (`#1353 `__) +* Test the remaining node public API (`#1342 `__) +* Complete coverage of Parameter and ParameterValue API (`#1344 `__) +* Add in more tests for the utilities. (`#1349 `__) +* Add in two more tests for expand_topic_or_service_name. (`#1350 `__) +* Add tests for node_options API (`#1343 `__) +* Add in more coverage for expand_topic_or_service_name. (`#1346 `__) +* Test exception in spin_until_future_complete. (`#1345 `__) +* Add coverage tests graph_listener (`#1330 `__) +* Add in unit tests for the Executor class. +* Allow mimick patching of methods with up to 9 arguments. +* Improve the error messages in the Executor class. +* Add coverage for client API (`#1329 `__) +* Increase service coverage (`#1332 `__) +* Make more of the static entity collector API private. +* Const-ify more of the static executor. +* Add more tests for the static single threaded executor. +* Many more tests for the static_executor_entities_collector. +* Get one more line of code coverage in memory_strategy.cpp +* Bugfix when adding callback group. +* Fix typos in comments. +* Remove deprecated executor::FutureReturnCode APIs. (`#1327 `__) +* Increase coverage of publisher/subscription API (`#1325 `__) +* Not finalize guard condition while destructing SubscriptionIntraProcess (`#1307 `__) +* Expose qos setting for /rosout (`#1247 `__) +* Add coverage for missing API (except executors) (`#1326 `__) +* Include topic name in QoS mismatch warning messages (`#1286 `__) +* Add coverage tests context functions (`#1321 `__) +* Increase coverage of node_interfaces, including with mocking rcl errors (`#1322 `__) +* Make node_graph::count_graph_users() const (`#1320 `__) +* Add coverage for wait_set_policies (`#1316 `__) +* Only exchange intra_process waitable if nonnull (`#1317 `__) +* Check waitable for nullptr during constructor (`#1315 `__) +* Call vector.erase with end iterator overload (`#1314 `__) +* Use best effort, keep last, history depth 1 QoS Profile for '/clock' subscriptions (`#1312 `__) +* Add tests type_support module (`#1308 `__) +* Replace std_msgs with test_msgs in executors test (`#1310 `__) +* Add set_level for rclcpp::Logger (`#1284 `__) +* Remove unused private function (rclcpp::Node and rclcpp_lifecycle::Node) (`#1294 `__) +* Adding tests basic getters (`#1291 `__) +* Adding callback groups in executor (`#1218 `__) +* Refactor Subscription Topic Statistics Tests (`#1281 `__) +* Add operator!= for duration (`#1236 `__) +* Fix clock thread issue (`#1266 `__) (`#1267 `__) +* Fix topic stats test, wait for more messages, only check the ones with samples (`#1274 `__) +* Add get_domain_id method to rclcpp::Context (`#1271 `__) +* Fixes for unit tests that fail under cyclonedds (`#1270 `__) +* initialize_logging\_ should be copied (`#1272 `__) +* Use static_cast instead of C-style cast for instrumentation (`#1263 `__) +* Make parameter clients use template constructors (`#1249 `__) +* Ability to configure domain_id via InitOptions. (`#1165 `__) +* Simplify and fix allocator memory strategy unit test for connext (`#1252 `__) +* Use global namespace for parameter events subscription topic (`#1257 `__) +* Increase timeouts for connext for long tests (`#1253 `__) +* Adjust test_static_executor_entities_collector for rmw_connext_cpp (`#1251 `__) +* Fix failing test with Connext since it doesn't wait for discovery (`#1246 `__) +* Fix node graph test with Connext and CycloneDDS returning actual data (`#1245 `__) +* Warn about unused result of add_on_set_parameters_callback (`#1238 `__) +* Unittests for memory strategy files, except allocator_memory_strategy (`#1189 `__) +* EXPECT_THROW_EQ and ASSERT_THROW_EQ macros for unittests (`#1232 `__) +* Add unit test for static_executor_entities_collector (`#1221 `__) +* Parameterize test executors for all executor types (`#1222 `__) +* Unit tests for allocator_memory_strategy.cpp part 2 (`#1198 `__) +* Unit tests for allocator_memory_strategy.hpp (`#1197 `__) +* Derive and throw exception in spin_some spin_all for StaticSingleThreadedExecutor (`#1220 `__) +* Make ring buffer thread-safe (`#1213 `__) +* Add missing RCLCPP_PUBLIC to ~StaticExecutorEntitiesCollector (`#1227 `__) +* Document graph functions don't apply remap rules (`#1225 `__) +* Remove recreation of entities_collector (`#1217 `__) +* Fix rclcpp::NodeOptions::operator= (`#1211 `__) +* Link against thread library where necessary (`#1210 `__) +* Unit tests for node interfaces (`#1202 `__) +* Remove usage of domain id in node options (`#1205 `__) +* Remove deprecated set_on_parameters_set_callback function (`#1199 `__) +* Fix conversion of negative durations to messages (`#1188 `__) +* Fix implementation of NodeOptions::use_global_arguments() (`#1176 `__) +* Bump to QD to level 3 and fixed links (`#1158 `__) +* Fix pub/sub count API tests (`#1203 `__) +* Update tracetools' QL to 2 in rclcpp's QD (`#1187 `__) +* Fix exception message on rcl_clock_init (`#1182 `__) +* Throw exception if rcl_timer_init fails (`#1179 `__) +* Unit tests for some header-only functions/classes (`#1181 `__) +* Callback should be perfectly-forwarded (`#1183 `__) +* Add unit tests for logging functionality (`#1184 `__) +* Add create_publisher include to create_subscription (`#1180 `__) +* Check period duration in create_wall_timer (`#1178 `__) +* Fix get_node_time_source_interface() docstring (`#988 `__) +* Add message lost subscription event (`#1164 `__) +* Add spin_all method to Executor (`#1156 `__) +* Reorganize test directory and split CMakeLists.txt (`#1173 `__) +* Check if context is valid when looping in spin_some (`#1167 `__) +* Add check for invalid topic statistics publish period (`#1151 `__) +* Fix spin_until_future_complete: check spinning value (`#1023 `__) +* Fix doxygen warnings (`#1163 `__) +* Fix reference to rclcpp in its Quality declaration (`#1161 `__) +* Allow spin_until_future_complete to accept any future like object (`#1113 `__) +* Contributors: Ada-King, Alejandro Hernández Cordero, Ananya Muddukrishna, Andrea Sorbini, Audrow Nash, Barry Xu, BriceRenaudeau, Chen Lihui, Chris Lalancette, Christophe Bedard, Claire Wang, Colin MacKenzie, Daisuke Sato, Devin Bonnie, Dirk Thomas, DongheeYe, Ivan Santiago Paunovic, Jacob Perron, Jannik Abbenseth, Johannes Meyer, Jorge Perez, Karsten Knese, Louise Poubel, Miaofei Mei, Michel Hidalgo, Miguel Company, Morgan Quigley, Nikolai Morin, Pedro Pena, Sarthak Mittal, Scott K Logan, Shane Loretz, Stephen Brawner, Steven! Ragnarök, Tomoya Fujita, William Woodall, anaelle-sw, bpwilcox, brawner, eboasson, hsgwa, mauropasse, shonigmann, suab321321, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Returns CancelResponse::REJECT while goal handle failed to transit to CANCELING state (`#1641 `__) (`#1653 `__) +* Fix action server deadlock issue that caused by other mutexes locked in CancelCallback (`#1635 `__) (`#1646 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) +* Add support for rmw_connextdds (`#1574 `__) +* node_handle must be destroyed after client_handle to prevent memory leak (`#1562 `__) +* Finalize rcl_handle to prevent leak (`#1528 `__) (`#1529 `__) +* Fix `#1526 `__. (`#1527 `__) +* Fix action server deadlock (`#1285 `__) (`#1313 `__) +* Goal response callback compatibility shim with deprecation of old signature (`#1495 `__) +* [rclcpp_action] Add warnings (`#1405 `__) +* Update QDs to QL 1 (`#1477 `__) +* Add ``take_data`` to ``Waitable`` and ``data`` to ``AnyExecutable`` (`#1241 `__) +* Fix test crashes on CentOS 7 (`#1449 `__) +* Bump rclcpp packages to Quality Level 2 (`#1445 `__) +* Add rclcpp_action action_server benchmarks (`#1433 `__) +* Benchmark rclcpp_action action_client (`#1429 `__) +* Add missing locking to the rclcpp_action::ServerBase. (`#1421 `__) +* Increase test timeouts of slow running tests with rmw_connext_cpp (`#1400 `__) +* Update maintainers (`#1384 `__) +* Increase coverage rclcpp_action to 95% (`#1290 `__) +* Pass goal handle to goal response callback instead of a future (`#1311 `__) +* Remove deprecated client goal handle method for getting result (`#1309 `__) +* Increase test timeout necessary for Connext (`#1256 `__) +* Bump to QD to level 3 and fixed links (`#1158 `__) +* Add rcl_action_client_options when creating action client. (`#1133 `__) +* Fix doxygen warnings (`#1163 `__) +* Increase rclcpp_action test coverage (`#1153 `__) +* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Audrow Nash, Chris Lalancette, Daisuke Sato, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Kaven Yau, Louise Poubel, Michel Hidalgo, Stephen Brawner, Tomoya Fujita, William Woodall, brawner, shonigmann, tomoya, y-okumura-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_components `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) +* Use std compliant non-method std::filesystem::exists function (`#1502 `__) +* Fix string literal warnings (`#1442 `__) +* Update QDs to QL 1 (`#1477 `__) +* Add benchmarks for components (`#1476 `__) +* Bump rclcpp packages to Quality Level 2 (`#1445 `__) +* Update maintainers (`#1384 `__) +* ComponentManager: switch off parameter services and event publisher (`#1333 `__) +* Bump to QD to level 3 and fixed links (`#1158 `__) +* Include original exception in ComponentManagerException (`#1157 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Ivan Santiago Paunovic, Josh Langsfeld, Louise Poubel, Martijn Buijs, Scott K Logan, Stephen Brawner, Tomoya Fujita, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add generic publisher and generic subscription for serialized messages (`#1452 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#1615 `__) +* Fix flaky lifecycle node tests (`#1606 `__) +* Clock subscription callback group spins in its own thread (`#1556 `__) +* Delete debug messages (`#1602 `__) +* add automatically_add_executor_with_node option (`#1594 `__) +* make rcl_lifecyle_com_interface optional in lifecycle nodes (`#1507 `__) +* Add support for rmw_connextdds (`#1574 `__) +* Fix SEGV caused by order of destruction of Node sub-interfaces (`#1469 `__) +* Enforce static parameter types (`#1522 `__) +* add LifecycleNode::get_transition_graph to match services. (`#1472 `__) +* Update QDs to QL 1 (`#1477 `__) +* Benchmark lifecycle features (`#1462 `__) +* Reserve vector capacities and use emplace_back for constructing vectors (`#1464 `__) +* [rclcpp_lifecycle] Change uint8_t iterator variables to size_t (`#1461 `__) +* Bump rclcpp packages to Quality Level 2 (`#1445 `__) +* Increase test timeouts of slow running tests with rmw_connext_cpp (`#1400 `__) +* Update maintainers (`#1384 `__) +* Add clock qos to node options (`#1375 `__) +* Increase test coverage of rclcpp_lifecycle to 96% (`#1298 `__) +* Log error instead of throwing exception in Transition and State reset(), mark no except (`#1297 `__) +* Remove unused private function (rclcpp::Node and rclcpp_lifecycle::Node) (`#1294 `__) +* Remove rmw-dependent unit-test checks (`#1293 `__) +* Added missing tests for rclcpp lifecycle (`#1240 `__) +* Warn about unused result of add_on_set_parameters_callback (`#1238 `__) +* Remove deprecated set_on_parameters_set_callback function (`#1199 `__) +* Bump to QD to level 3 and fixed links (`#1158 `__) +* Fix race in test_lifecycle_service_client (`#1204 `__) +* Fix doxygen warnings (`#1163 `__) +* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, BriceRenaudeau, Claire Wang, Colin MacKenzie, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Karsten Knese, Louise Poubel, Nikolai Morin, Stephen Brawner, anaelle-sw, brawner, shonigmann, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Break log function execution ASAP if configured severity is too high (`#776 `__) (`#783 `__) +* typo fix. (`#768 `__) +* Restore exceptions for Connext and message timestamps on Windows (`#765 `__) +* Use correct type when creating test publisher (`#764 `__) +* Add a test for destroy_node while spinning (`#663 `__) +* Add __enter_\_ and __exit_\_ to Waitable (`#761 `__) +* Check if shutdown callback weak method is valid before calling it (`#754 `__) +* Change index.ros.org -> docs.ros.org. (`#755 `__) +* Use py::class\_ for rcl_event_t (`#750 `__) +* Convert Clock to use a C++ Class (`#749 `__) +* Convert Service to use C++ Class (`#747 `__) +* Fix windows warning by using consistent types (`#753 `__) +* Use py::class\_ for rmw_service_info_t and rmw_request_id_t (`#748 `__) +* Convert Timer to use a C++ Class (`#745 `__) +* Add PythonAllocator (`#746 `__) +* Use py::class\_ for rmw_qos_profile_t (`#741 `__) +* Combine pybind11 modules into one (`#743 `__) +* Use py::class\_ for rcl_duration_t (`#744 `__) +* Fix bug in unique_ptr type argument (`#742 `__) +* Convert Client to use C++ Class (`#739 `__) +* Converting last of _rclpy.c to pybind11 (`#738 `__) +* Make sure only non-empty std::vector of arguments are indexed (`#740 `__) +* Use py::class\_ for rcl_time_point_t (`#737 `__) +* Convert logging mutex functions to pybind11 (`#735 `__) +* Document misuse of of parameter callbacks (`#734 `__) +* Convert QoS APIs to pybind11 (`#736 `__) +* Add API for checking QoS profile compatibility (`#708 `__) +* Replace rmw_connext_cpp with rmw_connextdds (`#698 `__) +* Convert last of pub/sub getters to pybind11 (`#733 `__) +* Pybind 11: count_subscribers and count_publishers (`#732 `__) +* Convert more node accessors to pybind11 (`#730 `__) +* Pybind11-ify rclpy_get_node_parameters (`#718 `__) +* Modify parameter service behavior when allow_undeclared_parameters is false and the requested parameter doesn't exist (`#661 `__) +* Include pybind11 first to fix windows debug warning (`#731 `__) +* Convert init/shutdown to pybind11 (`#715 `__) +* Convert take API to pybind11 (`#721 `__) +* Migrate qos event APIs to pybind11 (`#723 `__) +* Remove pybind11 from rclpy common (`#727 `__) +* Look up pybind11 package once (`#726 `__) +* typo fix. (`#729 `__) +* [pybind11] Node Accessors (`#719 `__) +* Convert serialize/deserialize to pybind11 (`#712 `__) +* Convert names_and_types graph APIs to pybind11 (`#717 `__) +* Use Pybind11 for name functions (`#709 `__) +* Better checks for valid msg and srv types (`#714 `__) +* Convert duration to pybind11 (`#716 `__) +* Convert wait_set functions to pybind11 (`#706 `__) +* Explicitly populate tuple with None (`#711 `__) +* Change the time jump time type to just rcl_time_jump_t. (`#707 `__) +* Convert rclpy service functions to pybind11 (`#703 `__) +* Bump the cppcheck timeout by 2 minutes (`#705 `__) +* Convert subscription functions to pybind11 (`#696 `__) +* Convert rclpy client functions to pybind11 (`#701 `__) +* Fix static typing when allow undeclared (`#702 `__) +* Convert publisher functions to pybind11 (`#695 `__) +* Convert clock and time functions to pybind11 (`#699 `__) +* Set destructor on QoS Profile struct (`#700 `__) +* Convert timer functions to pybind11 (`#693 `__) +* Convert guard conditions functions to pybind11 (`#692 `__) +* Convert service info functions to pybind11 (`#694 `__) +* Enforce static parameter types when dynamic typing is not specified (`#683 `__) +* rclpy_ok and rclpy_create_context to pybind11 (`#691 `__) +* Include Pybind11 before Python.h (`#690 `__) +* Clean up exceptions in _rclpy_action (`#685 `__) +* Clean windows flags on _rclpy_pybind11 and _rclpy_action (`#688 `__) +* Use pybind11 for _rclpy_handle (`#668 `__) +* Split rclpy module for easier porting to pybind11 (`#675 `__) +* Use Pybind11 to generate _rclpy_logging (`#659 `__) +* Copy windows debug fixes for pybind11 (`#681 `__) +* Use pybind11 for _rclpy_action (`#678 `__) +* Update just pycapsule lib to use pybind11 (`#652 `__) +* remove maintainer (`#682 `__) +* Use Pybind11's CMake code (`#667 `__) +* Don't call destroy_node while spinning (`#674 `__) +* Check the rcl_action return value on cleanup. (`#672 `__) +* Fix the NULL check for destroy_ros_message. (`#677 `__) +* Use Py_XDECREF for pynode_names_and_namespaces (`#673 `__) +* Use Py_XDECREF for pyresult_list. (`#670 `__) +* Fix dead stores. (`#669 `__) +* Fix two clang static analysis warnings. (`#664 `__) +* Add method to get the current logging directory (`#657 `__) +* Fix docstring indent error in create_node (`#655 `__) +* use only True to avoid confusion in autodoc config +* document QoS profile constants +* Merge pull request `#649 `__ from ros2/clalancette/dont-except-while-sleep +* Fixes from review/CI. +* Make sure to catch the ROSInterruptException when calling rate.sleep. +* memory leak (`#643 `__) (`#645 `__) +* Don't throw an exception if timer canceled while sleeping. +* Wake executor in Node.create_subscription() (`#647 `__) +* Fix Enum not being comparable with ints in get_parameter_types service +* Qos configurability (`#635 `__) +* Use Py_XDECREF for pytopic_names_and_types. (`#638 `__) +* qos_policy_name_from_kind() should accept either a QoSPolicyKind or an int (`#637 `__) +* Add method in Node to resolve a topic or service name (`#636 `__) +* Deprecate verbose qos policy value names (`#634 `__) +* Remove deprecated set_parameters_callback (`#633 `__) +* Make sure to use Py_XDECREF in rclpy_get_service_names_and_types (`#632 `__) +* Update maintainers (`#627 `__) +* Add in semicolon on RCUTILS_LOGGING_AUTOINIT. (`#624 `__) +* Add in the topic name when QoS events are fired. (`#621 `__) +* Use best effort, keep last, history depth 1 QoS Profile for '/clock' subscriptions (`#619 `__) +* PARAM_REL_TOL documentation fix (`#559 `__) +* Node get fully qualified name (`#598 `__) +* MultiThreadedExecutor spin_until_future complete should not continue waiting when the future is done (`#605 `__) +* skip test relying on source timestamps with Connext (`#615 `__) +* Use the rpyutils shared import_c_library function. (`#610 `__) +* Add ability to configure domain ID (`#596 `__) +* Use absolute parameter events topic name (`#612 `__) +* Destroy event handlers owned by publishers/subscriptions when calling publisher.destroy()/subscription.destroy() (`#603 `__) +* Default incompatible qos callback should be set when there's no user specified callback (`#601 `__) +* relax rate jitter test for individual periods (`#602 `__) +* add QoSProfile.__str_\_ (`#593 `__) +* Add useful debug info when trying to publish the wrong type (`#581 `__) +* Pass rcutils_include_dirs to cppcheck (`#577 `__) +* wrap lines to shorten line length (`#586 `__) +* fix moved troubleshooting url (`#579 `__) +* improve error message if rclpy C extensions are not found (`#580 `__) +* Add message lost subscription event (`#572 `__) +* Fix executor behavior on shutdown (`#574 `__) +* Add missing rcutils/macros.h header (`#573 `__) +* Add ``topic_name`` property to Subscription (`#571 `__) +* Add ``topic_name`` property to publisher (`#568 `__) +* Fix and document rclpy_handle_get_pointer_from_capsule() (`#569 `__) +* Fix docstrings (`#566 `__) +* Contributors: Addisu Z. Taddese, Alejandro Hernández Cordero, Andrea Sorbini, Audrow, Audrow Nash, Barry Xu, Chris Lalancette, Claire Wang, Dereck Wonnacott, Dirk Thomas, Emerson Knapp, Greg Balke, Gökçe Aydos, Ivan Santiago Paunovic, Jacob Perron, Loy, Michel Hidalgo, Scott K Logan, Shane Loretz, Tomoya Fujita, Tully Foote, Zhen Ju, ksuszka, ssumoo, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcpputils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update quality declaration links (`#130 `__) +* Add functions for getting library path and filename (`#128 `__) +* Add path equality operators (`#127 `__) +* Add create_temp_directory filesystem helper (`#126 `__) +* Use new noexcept specifier. (`#123 `__) +* Add stream operator for paths to make it easier to log (`#120 `__) +* Path join operator is const (`#119 `__) +* No windows.h in header files (`#118 `__) +* Fix rcpputils::SharedLibrary tests. (`#117 `__) +* Update QD to QL 1 (`#114 `__) +* Make sure to not try to index into an empty path. (`#113 `__) +* Fix working with filesystem parent paths. (`#112 `__) +* Cleanup mislabeled BSD license (`#37 `__) +* overload functions for has_symbol and get_symbol with raw string literal (`#110 `__) +* Add an ASSERT to the pointer traits tests. (`#111 `__) +* replace custom get env login into rcutils_get_env(). (`#99 `__) +* Removed Github Actions (`#105 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#102 `__) +* Make sure that an existing path is a directory for create_directories (`#98 `__) +* Transfer ownership to Open Robotics (`#100 `__) +* Ensure -fPIC is used when building a static lib (`#93 `__) +* Removed doxygen warnings (`#86 `__) (`#87 `__) +* Add clamp header (`#85 `__) +* Removed doxygen warnings (`#86 `__) +* Split get_env_var() into header and implementation (`#83 `__) +* Add cstring include for strcmp (`#81 `__) +* filesystem helpers: adding remove_all to remove non-empty directories (`#79 `__) +* Add scope_exit helper (`#78 `__) +* Bump setup-ros to 0.0.23, action-ros-lint to 0.0.6, action-ros-ci to 0.0.17 (`#77 `__) +* Fix parent_path() for empty paths and paths of length one (`#73 `__) +* Add get_executable_name() function (`#70 `__) +* Address memory leak in remove pointer test (`#72 `__) +* Add current_path to filesystem_helpers (`#63 `__) +* Align path combine behavior with C++17 (`#68 `__) +* Update quality declaration to QL 2 (`#71 `__) +* Contributors: Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Christophe Bedard, Devin Bonnie, Dirk Thomas, Emerson Knapp, Hunter L. Allen, Ivan Santiago Paunovic, Jacob Perron, Karsten Knese, Louise Poubel, Michael Jeronimo, Michel Hidalgo, Nikolai Morin, Scott K Logan, Simon Honigmann, Stephen Brawner, Tully Foote, Victor Lopez, William Woodall, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Declare dependency on libatomic (`#338 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#335 `__) +* Quiet down a warning in release mode. (`#334 `__) +* Make the logging separate char an implementation detail. (`#332 `__) +* Performance tests demo (`#288 `__) +* Remove references of __xstat (`#330 `__) +* Update the documentation to be more consistent. (`#331 `__) +* Shorten some excessively long lines of CMake (`#328 `__) +* qnx-support: include sys/link.h & avoid using dlinfo (`#327 `__) +* QNX uses XSI-compliant (`#326 `__) +* Add an API for directory iteration (`#323 `__) +* Fix a leak during error handling in dir size calculation (`#324 `__) +* Fix rcutils_shared_library_t path on Windows. (`#322 `__) +* Check linker flags instead of assuming compiler correlation. (`#321 `__) +* Improve shared library relative paths handling (`#320 `__) +* Update rcutils_calculate_directory_size() to support recursion (`#306 `__) +* Updating QD to QL 1 (`#317 `__) +* Address unused return values found in scan-build (`#316 `__) +* use one copy for continuous area instead of loop copy (`#312 `__) +* use a better way to check whether string is empty (`#315 `__) +* Use helper funciton to copy string (`#314 `__) +* Disable a Windows platform warning. (`#311 `__) +* Fix format of code description on document (`#313 `__) +* Make sure to check the return values of rcutils APIs. (`#302 `__) +* Add rcutils_expand_user() to expand user directory in path (`#298 `__) +* Update the maintainers. (`#299 `__) +* Remove the temporary variable in RCUTILS_LOGGING_AUTOINIT (`#290 `__) +* Add RCUTILS_NO_FAULT_INJECTION() macro. (`#295 `__) +* Inject faults on rcutils_get_env() and rcutils_set_env() call. (`#292 `__) +* env.h and get_env.h docblock fixes (`#291 `__) +* Introduce rcutils_strcasecmp, case insensitive string compare. (`#280 `__) +* Stop using fprintf to avoid using file handles by changing as few lines of code as possible. (`#289 `__) +* Defines QNX implementation for rcutils_get_platform_library_name (`#287 `__) +* Add RCUTILS_CAN_SET_ERROR_MSG_AND_RETURN_WITH_ERROR_OF() macro. (`#284 `__) To fault inject error messages as well as return codes. +* Change rcutils_fault_injection_set_count to use int64_t (`#283 `__) +* adds QNX support for rcutils_get_executable_name (`#282 `__) +* Add fault injection hooks to default allocator (`#277 `__) +* Fault injection macros and functionality (plus example) (`#264 `__) +* ensure -fPIC is used when building a static lib (`#276 `__) +* Drop vsnprintf mocks entirely. (`#275 `__) Binary API is not portable across platforms and compilation config. +* Fix vsnprintf mocks for Release builds. (`#274 `__) +* Improve test coverage mocking system calls (`#272 `__) +* Use mimick/mimick.h header (`#273 `__) +* Add mock test for rcutils/strerror (`#265 `__) +* Add compiler option -Wconversion and add explicit casts for conversions that may alter the value or change the sign (`#263 `__) See https://github.com/ros2/rcutils/pull/263#issuecomment-663252537. +* Removed doxygen warnings (`#266 `__) (`#268 `__) +* Removed doxygen warnings (`#266 `__) +* Force _GNU_SOURCE if glibc is used. (`#267 `__) +* Add parenthesis around the argument in time conversion macros defined in time.h (`#261 `__) +* Add token join macros (`#262 `__) +* Add rcutils_string_array_sort function (`#248 `__) +* Add rcutils_string_array_resize function (`#247 `__) +* Increase testing coverage of rcutils to 95% (`#258 `__) +* Update QUALITY_DECLARATION to reflect QL 2 status (`#260 `__) +* Update version stability section of quality declaration for 1.0 (`#256 `__) +* Contributors: Ahmed Sobhy, Alejandro Hernández Cordero, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Dirk Thomas, Felix Endres, Homalozoa X, Ivan Santiago Paunovic, Johannes Meyer, Jorge Perez, Karsten Knese, Michel Hidalgo, Scott K Logan, Stephen Brawner, Steven! Ragnarök, brawner, shonigmann, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`resource_retriever `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Throw exception if package name is empty (`#54 `__) +* Update maintainers (`#53 `__) +* Add .hpp header and deprecate .h (`#51 `__) +* Add pytest.ini so local tests don't display warning (`#48 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Document which QoS policies are correctly read by rmw_get_publishers/subscriptions_info_by_topic (`#308 `__) +* Unique network flows (`#294 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#307 `__) +* Introduce RMW_DURATION_INFINITE constant and API return value promise (`#301 `__) +* Add declaration for function to check QoS profile compatibility (`#299 `__) +* Update the rmw_take_sequence documentation. (`#297 `__) +* Update rmw QD to QL 1 (`#289 `__) +* Extend rmw_qos_policy_kind_t, add functions to convert it to/from a string (`#285 `__) +* Add functions to convert between qos policy values and strings (`#284 `__) +* Update maintainers (`#282 `__) +* Update service request/response API documentation (`#279 `__) +* Update rmw_get_serialized_message_size docblock (`#281 `__) +* Update rmw_service_server_is_available doc (`#280 `__) +* Update wait and wait sets' API documentation (`#275 `__) +* Update graph API documentation (`#272 `__) +* Update service server/client creation/destruction API documentation. (`#276 `__) +* Update rmw\_*_*_allocation return values (`#278 `__) +* Update gid API documentation (`#274 `__) +* Do not link against pthread on Android (`#267 `__) +* Update taking API documentation (`#271 `__) +* Update publishing API documentation (`#270 `__) +* Add fault injection macros for use in other packages (`#254 `__) +* Add bad_alloc return to topic_endpoint_info functions (`#269 `__) +* Update publisher/subscription matched count API documentation (`#262 `__) +* Update publisher/subscription QoS query API documentation (`#263 `__) +* Extend rmw_serialized_message_t tests (`#261 `__) +* Update serialization/deserialization API documentation (`#258 `__) +* Update subscription API documentation (`#256 `__) +* Update publisher creation/destruction API documentation (`#252 `__) +* Add actual domain id to rmw_context_t (`#251 `__) +* Update node creation/destruction API documentation. (`#249 `__) +* Correct parameter names to match documentation (`#250 `__) +* Remove domain_id and localhost_only from node API (`#248 `__) +* Require enclave upon rmw_init() call. (`#247 `__) +* Update init/shutdown API documentation. (`#243 `__) +* Update init options API documentation. (`#244 `__) +* Add message lost subscription event (`#232 `__) +* Move statuses definitions to rmw/events_statuses/\*.h (`#232 `__) +* Increase rmw testing coverage above 95% (`#238 `__) +* Handle zero-length names_and_types properly (`#239 `__) +* Add missing RMW_PUBLIC to security_options_set_root_path (`#236 `__) +* Update Quality Declaration for QL 2 (`#233 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#230 `__) +* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Karsten Knese, Michel Hidalgo, Scott K Logan, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use rmw_qos_profile_unknown when adding entity to graph (`#28 `__) +* Resolve issues identified while investigating `#21 `__ (`#22 `__) +* Use Rolling in README's Quick Start +* Improved implementation of client::is_service_available for Connext Pro +* Only add request header to typecode with Basic req/rep profile +* Remove commented/unused code +* Avoid topic name validation in get_info functions +* Reduce shutdown period to 10ms +* Pass HistoryQosPolicy to graph cache +* Reset error string after looking up type support +* Remove DDS-based WaitSet implementation +* Merge pull request `#13 `__ from Ericsson/unique_network_flows +* Refactor common API +* Update branch ``master`` to support Rolling only (`#15 `__) +* Add ability to override of endpoint qos settings based on topic name. +* Optimize QoS for reliable large data. +* Only trigger data condition if samples were loaned from reader. +* Alternative WaitSet implementation based on C++ std, selectable at compile-time. +* Add ```` for ``ament_cmake``. +* Use default ``dds.transport.UDPv4.builtin.ignore_loopback_interface``. +* Renamed environment variables (``RMW_CONNEXT_USE_DEFAULT_PUBLISH_MODE``, ``RMW_CONNEXT_LEGACY_RMW_COMPATIBILITY_MODE``). +* Support a list of initial peers via ``RMW_CONNEXT_INITIAL_PEERS``. +* Initial release. +* Contributors: Ananya Muddukrishna, Andrea Sorbini, Ivan Santiago Paunovic, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Correctly detect empty messages (`#33 `__) +* Use rmw_qos_profile_unknown when adding entity to graph (`#28 `__) +* Resolve issues identified while investigating `#21 `__ (`#22 `__) +* Use Rolling in README's Quick Start +* Improved implementation of client::is_service_available for Connext Pro +* Only add request header to typecode with Basic req/rep profile +* Remove commented/unused code +* Avoid topic name validation in get_info functions +* Reduce shutdown period to 10ms +* Pass HistoryQosPolicy to graph cache +* Reset error string after looking up type support +* Remove DDS-based WaitSet implementation +* Merge pull request `#13 `__ from Ericsson/unique_network_flows +* Remove superfluous header inclusion +* Remove conflicting linkage +* Further remove feature-based exclusion +* Remove feature-based exclusion +* Uncrustify +* Refactor common API +* Include required headers if feature is enabled +* Add conditional compilation support +* Prefer more generic file name +* Restrict unique flow endpoint check to versions beyond Foxy +* Indicate missing support for unique network flows +* Update branch ``master`` to support Rolling only (`#15 `__) +* Add ability to override of endpoint qos settings based on topic name (Pro). +* Optimize QoS for reliable large data (Pro). +* Only trigger data condition if samples were loaned from reader. +* Alternative WaitSet implementation based on C++ std, selectable at compile-time. +* Add ```` for ``ament_cmake``. +* Use default ``dds.transport.UDPv4.builtin.ignore_loopback_interface``. +* Don't log an error on WaitSet::wait() timeout. +* Initial release. +* Contributors: Ananya Muddukrishna, Andrea Sorbini, Ivan Santiago Paunovic, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextddsmicro `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use rmw_qos_profile_unknown when adding entity to graph (`#28 `__) +* Resolve issues identified while investigating `#21 `__ (`#22 `__) +* Use Rolling in README's Quick Start +* Remove commented/unused code +* Avoid topic name validation in get_info functions +* Pass HistoryQosPolicy to graph cache +* Reset error string after looking up type support +* Remove DDS-based WaitSet implementation +* Merge pull request `#13 `__ from Ericsson/unique_network_flows +* Refactor common API +* Update branch ``master`` to support Rolling only (`#15 `__) +* Only trigger data condition if samples were loaned from reader. +* Alternative WaitSet implementation based on C++ std, selectable at compile-time. +* Add ```` for ``ament_cmake``. +* Initial release. +* Contributors: Ananya Muddukrishna, Andrea Sorbini, Ivan Santiago Paunovic, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_cyclonedds_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix the history depth for KEEP_ALL. (`#305 `__) +* Use the macros from Cyclone DDS to work with sample payload when using SHM (`#300 `__) +* Add loaned sample zero-copy API support (`#297 `__) +* Indicate missing support for unique network flows (`#282 `__) +* Take and return new RMW_DURATION_INFINITE correctly (`#288 `__) +* Add RMW function to check QoS compatibility (`#286 `__) +* Fix use-after-free in error handling bug +* Drop compatibility with ancient cyclone versions +* Update to use Cyclone's renamed ddsi_sertype +* Use init-on-first-use for global state (`#275 `__) +* Make sure to reset the error when a typesupport can't be found. +* Switch to using the generic functions for the typesupport handles. +* Handle typesupport errors on fetch. (`#271 `__) +* Handle potential divide by 0 (`#267 `__) +* Fix incorrect log message(rmw_fastrtps_shared_cpp -> rmw_cylonedds_cpp) (`#260 `__) +* Update maintainers (`#254 `__) +* Change wrong use of %ld to print std::size_t to %zu +* Return RMW_RET_UNSUPPORTED in rmw_get_serialized_message_size (`#250 `__) +* Update service/client request/response API error returns (`#249 `__) +* Updated publisher/subscription allocation and wait set API return codes (`#246 `__) +* Fix array ``get_function`` semantics (`#248 `__) +* Update service/client construction/destruction API return codes. (`#247 `__) +* Update gid API return codes. (`#244 `__) +* Update graph API return codes. (`#243 `__) +* Check for message_info on take where appropriate. (`#245 `__) Fix for regression introduced in `#241 `__. +* Updated error returns on rmw_take_serialized() and rmw_take_with_message_info() (`#242 `__) +* Updated error returns on rmw_take() (`#241 `__) +* Add quality declaration for Cyclone DDS (`#218 `__) +* Fix that not to delete some objects after destroying functions (`#236 `__) +* Update rmw_publish_serialized_message() error returns (`#240 `__) +* Update rmw_publish() error returns (`#239 `__) +* Remove public declarations (`#230 `__) +* Use quotes for non-system includes (`#231 `__) +* Use correct functions to resize and get an item, avoiding memory leaks in typesupport code (`#228 `__) +* Fix context cleanup. (`#227 `__) +* Fix memory leak that type support not deleted. (`#225 `__) +* Ensure compliant matched pub/sub count API. (`#223 `__) +* Fix memory leak that string not deleted. (`#224 `__) +* Change RET_WRONG_IMPLID() to return RMW_RET_INCORRECT_IMPLEMENTATION (`#226 `__) +* Fix bad conditional in rmw_serialize(). (`#217 `__) +* Ensure compliant subscription API. (`#214 `__) +* Ensure compliant publisher API (`#210 `__) +* rmw_destroy_node must remove node from graph cache (`#213 `__) +* Add space between 'ROS' and '2' (`#195 `__) +* Set context actual domain id (`#208 `__) +* Ensure compliant node construction/destruction API (`#206 `__) +* Remove domain_id and localhost_only from node API (`#205 `__) +* Amend rmw_init() implementation: require enclave. (`#204 `__) +* Ensure compliant init/shutdown API implementations. (`#202 `__) +* Ensure compliant init options API implementations. (`#200 `__) +* Finalize context iff shutdown. (`#196 `__) +* Handle RMW_DEFAULT_DOMAIN_ID. (`#194 `__) +* Add support to message lost event (`#192 `__) +* Mitigate lost service responses discovery issue (`#187 `__) +* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Chen Lihui, Chris Lalancette, Christophe Bedard, Dan Rose, Emerson Knapp, Erik Boasson, Ivan Santiago Paunovic, Jacob Perron, Joe Speed, Jose Tomas Lorente, Lobotuerk, Michel Hidalgo, Scott K Logan, Stephen Brawner, Sumanth Nirmal, Sven Brinkmann, eboasson, pluris + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_dds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix one more instance of index.ros.org. (`#49 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#46 `__) +* Add function for checking QoS profile compatibility (`#45 `__) +* Shorten some excessively long lines of CMake (`#44 `__) +* Fix test_graph_cache ASAN errors (`#41 `__) (`#42 `__) +* Update QD to QL 1 (`#38 `__) +* Create a utility function to limit rmw_time_t to 32-bit values (`#37 `__) +* Update maintainers (`#34 `__) +* Updated performance section QD (`#30 `__) +* Update Quality Declaration to QL2 (`#31 `__) +* Added benchmark test to rmw_dds_common (`#29 `__) +* Fix potential memory leak (`#28 `__) +* Add fault injection macro unit tests (`#27 `__) +* Fixed some doxygen warnings (`#26 `__) +* Update Quality Declaration to QL3 (`#24 `__) +* Update QD and documentation (`#23 `__) +* Contributors: Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michael Jeronimo, Michel Hidalgo, Scott K Logan, Stephen Brawner, shonigmann, y-okumura-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Refactor to use DDS standard API (`#518 `__) +* Unique network flows (`#502 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#520 `__) +* Add RMW function to check QoS compatibility (`#511 `__) +* Capture cdr exceptions (`#505 `__) +* Load profiles based on topic names (`#335 `__) +* Set rmw_dds_common::GraphCache callback after init succeeds. (`#496 `__) +* Handle typesupport errors on fetch. (`#495 `__) +* Check for correct context shutdown (`#486 `__) +* New environment variable to change easily the publication mode (`#470 `__) +* Discriminate when the Client has gone from when the Client has not completely matched (`#467 `__) * Workaround when the client is gone before server sends response * Change add to the map to listener callback +* Update the package.xml files with the latest Open Robotics maintainers (`#459 `__) +* Update Quality Declarations and READMEs (`#455 `__) * Add QD links for dependencies to rmw_fastrtps_cpp QD * Provide external dependencies QD links * Update rmw_fastrtps README to use Fast DDS * Update rmw_fastrtps_cpp QD: Fast DDS & unit test * Update README rmw_fastrtps_cpp to QL2 +* Perform fault injection in all creation/destruction APIs. (`#453 `__) +* Ensure rmw_destroy_node() completes despite run-time errors. (`#458 `__) +* Update rmw_fastrtps_cpp and rmw_fastrtps_shared_cpp QDs to QL2. (`#456 `__) +* Return RMW_RET_UNSUPPORTED in rmw_get_serialized_message_size (`#452 `__) +* Updated publisher/subscription allocation and wait set API return codes (`#443 `__) +* Added rmw_logging tests (`#442 `__) +* Make service/client construction/destruction implementation compliant (`#445 `__) +* Make sure type can be unregistered successfully (`#437 `__) +* Add tests for native entity getters. (`#439 `__) +* Avoid deadlock if graph update fails. (`#438 `__) +* Call Domain::removePublisher while failure occurs in create_publisher (`#434 `__) +* Ensure compliant matched pub/sub count API. (`#424 `__) +* Ensure compliant publisher QoS queries. (`#425 `__) +* Ensure compliant subscription API. (`#419 `__) +* Ensure compliant publisher API. (`#414 `__) +* Set context actual domain id (`#410 `__) +* Ensure compliant node construction/destruction API. (`#408 `__) +* Remove domain_id and localhost_only from node API (`#407 `__) +* Amend rmw_init() implementation: require enclave. (`#406 `__) +* Update Quality Declarations to QL3. (`#404 `__) +* Ensure compliant init/shutdown API implementation. (`#401 `__) +* Update Quality Declaration to QL3. (`#403 `__) +* Finalize context iff shutdown. (`#396 `__) +* Make service wait for response reader (`#390 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Eduardo Ponz Segrelles, Ignacio Montesino Valle, Ivan Santiago Paunovic, JLBuenoLopez-eProsima, Jacob Perron, Jaime Martin Losa, José Luis Bueno López, Michael Jeronimo, Michel Hidalgo, Miguel Company, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_dynamic_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Refactor to use DDS standard API (`#518 `__) +* Unique network flows (`#502 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#520 `__) +* Add RMW function to check QoS compatibility (`#511 `__) +* Capture cdr exceptions (`#505 `__) +* Load profiles based on topic names in rmw_fastrtps_dynamic_cpp (`#497 `__) +* Set rmw_dds_common::GraphCache callback after init succeeds. (`#496 `__) +* Handle typesupport errors on fetch. (`#495 `__) +* Check for correct context shutdown (`#486 `__) +* New environment variable to change easily the publication mode (`#470 `__) +* Discriminate when the Client has gone from when the Client has not completely matched (`#467 `__) * Workaround when the client is gone before server sends response * Change add to the map to listener callback +* Update the package.xml files with the latest Open Robotics maintainers (`#459 `__) +* Update Quality Declarations and READMEs (`#455 `__) * Add QL of external dependencies to rmw_fastrtps_dynamic_cpp QD * Add QD links for dependencies to rmw_fastrtps_dynamic_cpp QD * Provide external dependencies QD links * Add README to rmw_fastrtps_dynamic * Add QD for rmw_fastrtps_dynamic +* Ensure rmw_destroy_node() completes despite run-time errors. (`#458 `__) +* Return RMW_RET_UNSUPPORTED in rmw_get_serialized_message_size (`#452 `__) +* Updated publisher/subscription allocation and wait set API return codes (`#443 `__) +* Added rmw_logging tests (`#442 `__) +* Fix array ``get_function`` semantics (`#448 `__) +* Make service/client construction/destruction implementation compliant (`#445 `__) +* Make sure type can be unregistered successfully (`#437 `__) +* Add tests for native entity getters. (`#439 `__) +* Avoid deadlock if graph update fails. (`#438 `__) +* Call Domain::removePublisher while failure occurs in create_publisher (`#434 `__) +* Avoid memory leaks and undefined behavior in rmw_fastrtps_dynamic_cpp typesupport code (`#429 `__) +* Ensure compliant matched pub/sub count API. (`#424 `__) +* Ensure compliant publisher QoS queries. (`#425 `__) +* Ensure compliant subscription API. (`#419 `__) +* Ensure compliant publisher API. (`#414 `__) +* Set context actual domain id (`#410 `__) +* Ensure compliant node construction/destruction API. (`#408 `__) +* Remove domain_id and localhost_only from node API (`#407 `__) +* Amend rmw_init() implementation: require enclave. (`#406 `__) +* Ensure compliant init/shutdown API implementation. (`#401 `__) +* Finalize context iff shutdown. (`#396 `__) +* Make service wait for response reader (`#390 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Eduardo Ponz Segrelles, Ignacio Montesino Valle, Ivan Santiago Paunovic, JLBuenoLopez-eProsima, Jacob Perron, Jaime Martin Losa, José Luis Bueno López, Michael Jeronimo, Michel Hidalgo, Miguel Company, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_shared_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Refactor to use DDS standard API (`#518 `__) +* Unique network flows (`#502 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#520 `__) +* Take and return new RMW_DURATION_INFINITE correctly (`#515 `__) +* Add RMW function to check QoS compatibility (`#511 `__) +* Capture cdr exceptions (`#505 `__) +* Make sure to lock the mutex protecting client_endpoints\_. (`#492 `__) +* Use interface whitelist for localhost only (`#476 `__) +* Make use of error return value in decrement_context_impl_ref_count (`#488 `__) +* Remove unnecessary includes (`#487 `__) +* Use new time_utils function to limit rmw_time_t values to 32-bits (`#485 `__) +* New environment variable to change easily the publication mode (`#470 `__) +* Remove unused headers MessageTypeSupport.hpp and ServiceTypeSupport.hpp (`#481 `__) +* Discriminate when the Client has gone from when the Client has not completely matched (`#467 `__) * Workaround when the client is gone before server sends response * Change add to the map to listener callback +* Update the package.xml files with the latest Open Robotics maintainers (`#459 `__) +* Update Quality Declarations and READMEs (`#455 `__) * Add QD links for dependencies to rmw_fastrtps_shared_cpp QD. * Provide external dependencies QD links. * Update rmw_fastrtps_shared_cpp QD: Fast DDS * Update README rmw_fastrtps_shared_cpp to QL2 +* Perform fault injection in all creation/destruction APIs. (`#453 `__) +* Ensure rmw_destroy_node() completes despite run-time errors. (`#458 `__) +* Handle too large QoS queue depths. (`#457 `__) +* Update rmw_fastrtps_cpp and rmw_fastrtps_shared_cpp QDs to QL2. (`#456 `__) +* checked client implementation and return RMW_RET_INCORRECT_RMW_IMPLEMENTATION (`#451 `__) +* Update service/client request/response API error returns (`#450 `__) +* Updated publisher/subscription allocation and wait set API return codes (`#443 `__) +* Added rmw_logging tests (`#442 `__) +* Add tests for RMW QoS to DDS attribute conversion. (`#449 `__) +* Make service/client construction/destruction implementation compliant (`#445 `__) +* Inject faults on __rmw_publish() and run_listener_thread() call. (`#441 `__) +* Update gid API return codes. (`#440 `__) +* Update graph API return codes. (`#436 `__) +* Update rmw_take_serialized() and rmw_take_with_message_info() error returns (`#435 `__) +* Update rmw_take() error returns (`#432 `__) +* Update rmw_publish() error returns (`#430 `__) +* Update rmw_publish_serialized_message() error returns (`#431 `__) +* Improve __rmw_create_wait_set() implementation. (`#427 `__) +* Ensure compliant matched pub/sub count API. (`#424 `__) +* Ensure compliant publisher QoS queries. (`#425 `__) +* Fix memory leak that wait_set might be not destoryed in some case. (`#423 `__) +* Avoid unused identifier variable warnings. (`#422 `__) +* Fix trying to get topic data that was already removed. (`#417 `__) +* Ensure compliant subscription API. (`#419 `__) +* Use package path to TypeSupport.hpp headers in ServiceTypeSupport and MessageTypeSupport (`#415 `__) Use package in path to TypeSupport header for ServiceTypeSupport/MessageTypeSupport +* Ensure compliant publisher API. (`#414 `__) +* Set context actual domain id (`#410 `__) +* Add missing thread-safety annotation in ServicePubListener (`#409 `__) +* Ensure compliant node construction/destruction API. (`#408 `__) +* Update Quality Declarations to QL3. (`#404 `__) +* Do not use string literals as implementation identifiers in tests. (`#402 `__) +* Ensure compliant init options API implementations. (`#399 `__) +* Finalize context iff shutdown. (`#396 `__) +* Handle RMW_DEFAULT_DOMAIN_ID. (`#394 `__) +* Make service wait for response reader (`#390 `__) +* Contributors: Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, JLBuenoLopez-eProsima, Jacob Perron, Jaime Martin Losa, Jose Luis Rivero, Jose Tomas Lorente, José Luis Bueno López, Lobotuerk, Michael Jeronimo, Michel Hidalgo, Miguel Company, Stephen Brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Unique network flows (`#170 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#185 `__) +* Remove rmw_connext_cpp. (`#183 `__) +* Add support for rmw_connextdds (`#182 `__) +* Add function for checking QoS profile compatibility (`#180 `__) +* Shorten some excessively long lines of CMake (`#179 `__) +* Add rmw_fastrtps_dynamic_cpp to the explicit group deps (`#177 `__) +* Accept any RMW implementation, not just the default (`#172 `__) +* Defer path resolution of rmw implementation libraries to dynamic linker. (`#169 `__) +* Update QD to QL 1 (`#166 `__) +* Fix up C functions to never throw. (`#149 `__) +* Restored Dirk as author (`#155 `__) +* Update maintainers (`#154 `__) +* Updated performance QD section (`#153 `__) +* Update Quality Declaration to QL2. (`#151 `__) +* Add nominal test for symbol prefetch() and unload. (`#145 `__) +* Added benchmark test to rmw_implementation (`#127 `__) +* Test load and lookup functionality. (`#135 `__) +* Remove domain_id and localhost_only from node API (`#114 `__) +* Move the quality declaration into the rmw_implementation subdirectory. (`#111 `__) +* Contributors: Alejandro Hernández Cordero, Ananya Muddukrishna, Andrea Sorbini, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Scott K Logan, Stephen Brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Shorten some excessively long lines of CMake (`#300 `__) +* Change default RMW vendor to CycloneDDS. (`#293 `__) +* Update rmw QD to QL 1 (`#289 `__) +* Update maintainers (`#282 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Scott K Logan, Stephen Brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`robot_state_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Stop rejecting unknown parameters. (`#161 `__) +* clean up license to be standard bsd 3 clause (`#130 `__) +* Update the maintainers. (`#151 `__) +* fix types in range loops to avoid copy due to different type (`#143 `__) +* Make sure not to crash on an invalid URDF. (`#141 `__) +* Don't export exe as library (`#25 `__) (`ros2 #28 `__) +* Contributors: Chris Lalancette, Dirk Thomas, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros1_bridge `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix logging for updated rclcpp interface (`#303 `__) +* Fix typo in comments (`#297 `__) +* Update to use rosidl_parser and .idl files rather than rosidl_adapter and .msg files (`#296 `__) +* Update maintainers (`#286 `__) +* use hardcoded QoS (keep all, transient local) for /tf_static topic in dynamic_bridge (`#282 `__) +* document explicitly passing the topic type to 'ros2 topic echo' (`#279 `__) +* Fix multiple definition if message with same name as service exists (`#272 `__) +* Contributors: Dirk Thomas, Jacob Perron, Michael Carroll, Vicidel, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* /clock publisher in Player (`#695 `__) +* Introducing Reindexer CLI (`#699 `__) +* rosbag2_py pybind wrapper for "record" - remove rosbag2_transport_py (`#702 `__) +* Add rosbag2_py::Player::play to replace rosbag2_transport_python version (`#693 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* use rosbag2_py for ros2 bag info (`#673 `__) +* CLI query rosbag2_py for available storage implementations (`#659 `__) +* Recorder --regex and --exclude options (`#604 `__) +* Fix the tests on cyclonedds by translating qos duration values (`#606 `__) +* SQLite storage optimized by default (`#568 `__) +* Fix a bug on parsing wrong description in plugin xml file (`#578 `__) +* Compress bag files in separate threads (`#506 `__) +* Sqlite storage double buffering (`#546 `__) * Double buffers * Circular queue and FLUSH option as define * Minor naming and lexical fixes. * Removed FLUSH_BUFFERS define check. * Sqlite3 storage logging fixes. * Sqlite3 storage circular buffer with pre allocated memory. * Sqlite3 storage buffers moved to shared_ptrs. * Uncrustify * Moved double buffers to writer * Buffer layer reset in seq compression writer in rosbag2 cpp * Buffer layer for rosbag2 writer refactor * Changed buffers in BufferLayer to std vectors. * BufferLayer uncrustify * Removed non-applicable test for writer cache. * BufferLayer review fixes * Rosbag metadata msgs count fixed for BufferLayer * Condition variable for buffer layer sync. * Fixed buffer locks * Buffers in BufferLayer refactored, moved into new class * Buffer layer split bags fixed. * Storage options include fix in buffer layer header. * Mutex around swapping buffers in buffer layer. * Fixed cache 0 bug in buffer layer. * Minor buffer layer refactor. * Counting messages in writer refactored. * Changed default cache size to 100Mb and updated parameter description * Applied review remarks: - significant refactoring: separation of cache classes - applied suggested improvements - some renaming - reduce code duplication that would otherwise increase with cache refactor, between compression and plain writers * Applied review comments - cache consumer now takes a callback and is independent of storage - namespace changes, renaming, cleaning - counting and logging messages by topic * linter * Changes after review: fixing flushing, topic counts, and more * Fix for splitting - flushing state now correctly turns off * cache classes documentation * simplified signature * a couple of tests for cache * address review: explicit constructor and doxygen styling * Windows warnings fix * fixed type mismatch warning on Windows * added minor comment Co-authored-by: Piotr Jaroszek +* read yaml config file (`#497 `__) +* List all storage plugins in plugin xml file (`#554 `__) +* add storage_config_uri (`#493 `__) +* Update deprecated qos policy value names (`#548 `__) +* Add record test for ros2bag (`#523 `__) +* Removed duplicated code in record (`#534 `__) +* Change default cache size for sequential_writer to a non zero value (`#533 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* [ros2bag test_record] Gets rid of time.sleep and move to using command.wait_for_output (`#525 `__) +* Add pytest.ini back to ros2bag. (`#492 `__) +* performance testing packages (`#442 `__) +* Validate QoS profile values are not negative. (`#483 `__) +* catch parent exception (`#472 `__) +* add wait for closed file handles on Windows (`#470 `__) +* introduce ros2 bag list (`#468 `__) +* move wait_for_shutdown() call out of the context manager (`#466 `__) +* Adding db directory creation to rosbag2_cpp (`#450 `__) +* use a single temp dir for the test class (`#462 `__) +* Add per-message ZSTD compression (`#418 `__) +* Add split by time to recording (`#409 `__) +* Add pytest.ini so local tests don't display warning (`#446 `__) +* Contributors: Adam Dąbrowski, Barry Xu, Chris Lalancette, Dirk Thomas, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jaison Titus, Jesse Ikawa, Karsten Knese, Marwan Taher, Michael Jeronimo, P. J. Reed, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Ensure only one daemon can run at a time. (`#622 `__) +* Remove maintainer. (`#597 `__) +* Add option to support use_sim_time. (`#581 `__) +* Bugfix for `#563 `__. (`#570 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Support Python 3.8-provided importlib.metadata. (`#585 `__) +* Update maintainers. (`#568 `__) +* Added dependency to python3-argcomplete to ros2cli. (`#564 `__) +* Remove use of pkg_resources from ros2cli. (`#537 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Daisuke Sato, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, Tomoya Fujita, Yoan Mollard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli_common_extensions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* remove maintainer (`#5 `__) +* update maintainer (`#4 `__) +* First implementation (`#2 `__) +* Contributors: Bo Sun, Claire Wang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli_test_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Make ros2cli_test_interfaces version equal to other packages. +* Remove ros2interface test dependencies on builtin interface. (`#579 `__) +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2component `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Ensure consistent timeout in ros2component list. (`#526 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2doctor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve ros2 doctor on Windows. (`#631 `__) (`#634 `__) +* Add changelog. (`#636 `__) +* Continue to next iteration after exceptions in generate_reports. (`#623 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Support Python 3.8-provided importlib.metadata. (`#585 `__) +* Update maintainers. (`#568 `__) +* Remove pkg_resources from ros2doctor. (`#537 `__) +* Make ros2doctor depend on ros_environment and fix platform.py bug on error. (`#538 `__) +* Refactor ros2doctor hello verb. (`#521 `__) +* Contributors: Alberto Soragna, Audrow Nash, Chris Lalancette, Claire Wang, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Remove ros2interface test dependencies on builtin interface. (`#579 `__) +* Update maintainers. (`#568 `__) +* Handle inline comments on constants correctly. (`#548 `__) +* Update quoted comments in the test (`#540 `__) +* Add option to include/remove whitespace and comments. (`#527 `__) +* Show "expanded" message definition. (`#524 `__) +* Contributors: Audrow, Audrow Nash, Claire Wang, Ivan Santiago Paunovic, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add options extensions to ros2launch and extensibility to the node action (`#216 `__) +* Support non-interactive ros2 launch executions (`#210 `__) +* Merge pull request `#183 `__ from ros2/update-maintainers +* Move previous maintainer to +* Update the package.xml files with the latest Open Robotics maintainers +* Add pytest.ini so local tests don't display warning (`#152 `__) +* Contributors: Chris Lalancette, Geoffrey Biggs, Michael Jeronimo, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle_test_fixtures `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Depend on rclcpp::rclcpp target. (`#618 `__) Contributors: Audrow Nash +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2multicast `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2node `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2param `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Make the ros2param --filter test more reliable. (`#606 `__) +* Add wildcard loading to ros2 param load. (`#602 `__) +* Ros2 param dump/load should use fully qualified node names. (`#600 `__) +* Add --filter options for 'ros2 param list'. (`#592 `__) +* Remove maintainer. (`#597 `__) +* Add rosparam verb load. (`#590 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Add "--param-type" option to ros2param list. (`#572 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic, Victor Lopez, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2pkg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Use underscores in setup.cfg.em instead of dashes. (`#627 `__) +* Add space for "ROS 2". (`#617 `__) +* Use target_compile_features for c/c++ standards. (`#615 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Declare missing dependency on python3-importlib-resources. (`#584 `__) +* Update maintainers. (`#568 `__) +* Fix incorrect EXPORT for executables. (`#545 `__) +* Switch ros2pkg to using importlib. +* Contributors: Audrow Nash, Chris Lalancette, Claire Wang, Dirk Thomas, Ivan Santiago Paunovic, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2run `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Contributors: Audrow Nash, Claire Wang, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Remove maintainer. (`#597 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Update maintainers. (`#568 `__) +* Check that passed type is actually a service. (`#559 `__) +* Contributors: Audrow Nash, Claire Wang, Dirk Thomas, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add pytest.ini so local tests don't display warning (`#8 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog. (`#636 `__) +* Add verbose info for topic list. (`#351 `__) +* Remove maintainer. (`#597 `__) +* Add option to support use_sim_time. (`#581 `__) +* Add Audrow as a maintainer. (`#591 `__) +* Add filter option to ros2topic . (`#575 `__) +* Update deprecated qos policy value names. (`#571 `__) +* Update maintainers. (`#568 `__) +* Fix the test to use the topic name. (`#566 `__) +* Improve the error message for invalid message types. (`#558 `__) +* Use reliable QoS for ros2topic tests. (`#555 `__) +* Add option to echo serialized messages. (`#470 `__) +* Enable --no-daemon flag for some cli tools. (`#514 `__) +* Use transient_local and longer keep-alive for pub tests. (`#546 `__) +* Add --keep-alive option to 'topic pub'. (`#544 `__) +* Add option to ros2 topic echo to report lost messages. (`#542 `__) +* Support QoS Depth and History via ros2 topic pub/echo. (`#528 `__) +* Contributors: Audrow Nash, ChenYing Kuo, Chris Lalancette, Claire Wang, Dereck Wonnacott, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Scott K Logan, Tomoya Fujita, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use rostest CMake target as output file basename. (`#9 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly add emersonknapp as maintainer (`#692 `__) +* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) +* Move zstd compressor to its own package (`#636 `__) +* add storage_config_uri (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* AMENT_IGNORE rosbag2_py for now (`#509 `__) +* rosbag2_py reader and writer (`#308 `__) +* Contributors: Emerson Knapp, Karsten Knese, Mabel Zhang, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. +* CLI query rosbag2_py for available storage implementations (`#659 `__) +* Move zstd compressor to its own package (`#636 `__) +* Remove rosbag2_compression test dependencies on zstd implementation in prep for moving it into a separate package (`#637 `__) +* Make compressor implementations into a plugin via pluginlib (`#624 `__) +* Use ZSTD's streaming interface for [de]compressing files (`#543 `__) +* Fix build issues when rosbag2_storage is binary installed (`#585 `__) +* Fix relative metadata paths in SequentialCompressionWriter (`#613 `__) +* Fix deadlock race condition on compression shutdown (`#616 `__) +* Deduplicate SequentialCompressionReader business logic, add fallback to find bagfiles in incorrectly-written metadata (`#612 `__) +* Compress bag files in separate threads (`#506 `__) +* Sqlite storage double buffering (`#546 `__) +* add storage_config_uri (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Do not expect empty StorageOptions URI to work in CompressionWriterTest (`#526 `__) +* Remove some code duplication between SequentialWriter and SequentialCompressionWriter (`#527 `__) +* Fix exception thrown given invalid arguments with compression enabled (`#488 `__) +* Adding db directory creation to rosbag2_cpp (`#450 `__) +* Consolidate ZSTD utility functions (`#459 `__) +* Add per-message ZSTD compression (`#418 `__) +* Contributors: Adam Dąbrowski, Christophe Bedard, Devin Bonnie, Emerson Knapp, Jaison Titus, Karsten Knese, Marwan Taher, Michael Jeronimo, P. J. Reed, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression_zstd `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_depend ament_cmake_gmock (`#639 `__) +* Move zstd compressor to its own package (`#636 `__) +* Contributors: Emerson Knapp, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add set_rate to PlayerClock (`#727 `__) +* Enforce non-null now_fn in TimeControllerClock (`#731 `__) +* Fix pause snapshot behavior and add regression test (`#730 `__) +* Pause/resume PlayerClock (`#704 `__) +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* Enable thread safety analysis for rosbag2_cpp and add annotations in TimeControllerClock (`#710 `__) +* PlayerClock initial implementation - Player functionally unchanged (`#689 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. +* use rclcpp serialized messages to write data (`#457 `__) +* alternative write api (`#676 `__) +* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) +* CLI query rosbag2_py for available storage implementations (`#659 `__) +* Fix --topics flag for ros2 bag play being ignored for all bags after the first one. (`#619 `__) +* Fix a crash in test_message_cache. (`#635 `__) +* Fix build issues when rosbag2_storage is binary installed (`#585 `__) +* Deduplicate SequentialCompressionReader business logic, add fallback to find bagfiles in incorrectly-written metadata (`#612 `__) +* include what you use (`#600 `__) +* Only dereference the data pointer if it is valid. (`#581 `__) +* Add back rosbag2_cpp::StorageOptions as deprecated (`#563 `__) +* Sqlite storage double buffering (`#546 `__) +* correct master build (`#552 `__) +* add storage_config_uri (`#493 `__) +* Mutex around writer access in recorder (`#491 `__) +* if cache data exists, it needs to flush the data into the storage before shutdown (`#541 `__) +* Change default cache size for sequential_writer to a non zero value (`#533 `__) +* SequentialWriter to cache by message size instead of message count (`#530 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Remove some code duplication between SequentialWriter and SequentialCompressionWriter (`#527 `__) +* disable sanitizer by default (`#517 `__) +* Fix typo in error message (`#475 `__) +* introduce defaults for the C++ API (`#452 `__) +* Adding db directory creation to rosbag2_cpp (`#450 `__) +* comment out unused variable (`#460 `__) +* minimal c++ API test (`#451 `__) +* Add split by time to recording (`#409 `__) +* Contributors: Adam Dąbrowski, Alexander, Chris Lalancette, Dirk Thomas, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jaison Titus, Karsten Knese, Marwan Taher, Michael Jeronimo, P. J. Reed, Patrick Spieler, Tomoya Fujita, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add rosbag2_interfaces package with playback service definitions (`#728 `__) +* Contributors: Emerson Knapp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_performance_benchmarking `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fixed a memory leak in no-transport benchmark (`#674 `__) +* report of performance improvements in rosbag2 (roughly since Foxy) (`#651 `__) +* Performance benchmarking improvements (`#634 `__) +* Performance benchmarking refactor (`#594 `__) +* Sqlite storage double buffering (`#546 `__) +* read yaml config file (`#497 `__) +* add storage_config_uri (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* performance testing packages (`#442 `__) +* Contributors: Adam Dąbrowski, Karsten Knese, Michael Jeronimo, Piotr Jaroszek + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* Split Rosbag2Transport into Player and Recorder classes - first pass to enable further progress (`#721 `__) +* /clock publisher in Player (`#695 `__) +* Introducing Reindexer CLI (`#699 `__) +* Fix rosbag2_py transport test for py capsule (`#707 `__) +* rosbag2_py pybind wrapper for "record" - remove rosbag2_transport_py (`#702 `__) +* Add rosbag2_py::Player::play to replace rosbag2_transport_python version (`#693 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) +* use rosbag2_py for ros2 bag info (`#673 `__) +* CLI query rosbag2_py for available storage implementations (`#659 `__) +* Fix build issues when rosbag2_storage is binary installed (`#585 `__) +* Fix the tests on cyclonedds by translating qos duration values (`#606 `__) +* add storage_config_uri (`#493 `__) +* Workaround pybind11 bug on Windows when CMAKE_BUILD_TYPE=RelWithDebInfo (`#538 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Fix rosbag2_py on Windows debug and stop ignoring the package (`#531 `__) +* Fix rosbag2_py bug when using libc++ (`#529 `__) +* AMENT_IGNORE rosbag2_py for now (`#509 `__) +* rosbag2_py reader and writer (`#308 `__) +* Contributors: Emerson Knapp, Ivan Santiago Paunovic, Karsten Knese, Mabel Zhang, Michael Jeronimo, P. J. Reed, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* PlayerClock initial implementation - Player functionally unchanged (`#689 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. +* Remove outdated pluginlib cmake script from rosbag2_storage (`#661 `__) +* CLI query rosbag2_py for available storage implementations (`#659 `__) +* Shorten some excessively long lines of CMake (`#648 `__) +* SQLite storage optimized by default (`#568 `__) * Use optimized pragmas by default in sqlite storage. Added option to use former behavior +* Use std::filesystem compliant non-member ``exists`` function for path object (`#593 `__) +* Update codes since rcutils_calculate_directory_size() is changed (`#567 `__) +* add storage_config_uri (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Add split by time to recording (`#409 `__) +* Contributors: Adam Dąbrowski, Barry Xu, Emerson Knapp, Josh Langsfeld, Karsten Knese, Michael Jeronimo, Scott K Logan, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. +* Fix build issues when rosbag2_storage is binary installed (`#585 `__) +* Mutex protection for db writing and stl collections in writer & storage (`#603 `__) +* SQLite storage optimized by default (`#568 `__) +* read yaml config file (`#497 `__) +* add storage_config_uri (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Contributors: Adam Dąbrowski, Emerson Knapp, Karsten Knese, Michael Jeronimo, P. J. Reed, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* Fix bad_function_call by replacing rclcpp::spin_some with SingleThreadedExecutor (`#705 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Remove temporary directory platform-specific logic from test fixture (`#660 `__) +* Stabilize test_record by reducing copies of executors and messages (`#576 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Contributors: Emerson Knapp, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Reindexer core (`#641 `__) Add a new C++ Reindexer class for reconstructing metadata from bags that are missing it. +* use rclcpp serialized messages to write data (`#457 `__) +* Alternative write api (`#676 `__) +* RMW-implementation-searcher converter in rosbag2_cpp (`#670 `__) +* Use rosbag2_py for ros2 bag info (`#673 `__) +* Remove temporary directory platform-specific logic from test fixture (`#660 `__) +* Fix --topics flag for ros2 bag play being ignored for all bags after the first one. (`#619 `__) +* Move zstd compressor to its own package (`#636 `__) +* Fix relative metadata paths in SequentialCompressionWriter (`#613 `__) +* Recorder --regex and --exclude options (`#604 `__) +* Fix the tests on cyclonedds by translating qos duration values (`#606 `__) +* add storage_config_uri (`#493 `__) +* Removed duplicated code in record (`#534 `__) +* Change default cache size for sequential_writer to a non zero value (`#533 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Mark flaky tests as xfail for now (`#520 `__) +* introduce defaults for the C++ API (`#452 `__) +* Adding db directory creation to rosbag2_cpp (`#450 `__) +* minimal c++ API test (`#451 `__) +* Add split by time to recording (`#409 `__) +* Contributors: Adam Dąbrowski, Alexander, Emerson Knapp, Jaison Titus, Karsten Knese, Marwan Taher, Michael Jeronimo, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* cleanup cmakelists (`#726 `__) +* turn recorder into a node (`#724 `__) +* turn player into a node (`#723 `__) +* Remove -Werror from builds, enable it in Action CI (`#722 `__) +* Split Rosbag2Transport into Player and Recorder classes - first pass to enable further progress (`#721 `__) +* /clock publisher in Player (`#695 `__) +* use rclcpp logging macros (`#715 `__) +* use rclcpp::Node for generic pub/sub (`#714 `__) +* PlayerClock initial implementation - Player functionally unchanged (`#689 `__) +* Fix bad_function_call by replacing rclcpp::spin_some with SingleThreadedExecutor (`#705 `__) +* rosbag2_py pybind wrapper for "record" - remove rosbag2_transport_py (`#702 `__) +* Add rosbag2_py::Player::play to replace rosbag2_transport_python version (`#693 `__) +* Fix and clarify logic in test_play filter test (`#690 `__) +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Add QoS decoding translation for infinite durations to RMW_DURATION_INFINITE (`#684 `__) +* Add support for rmw_connextdds (`#671 `__) +* Use rosbag2_py for ros2 bag info (`#673 `__) +* Fix build issues when rosbag2_storage is binary installed (`#585 `__) +* Regex and exclude fix for rosbag recorder (`#620 `__) +* Recorder --regex and --exclude options (`#604 `__) +* SQLite storage optimized by default (`#568 `__) +* Fixed playing if unknown message types exist (`#592 `__) +* Compress bag files in separate threads (`#506 `__) +* Stabilize test_record by reducing copies of executors and messages (`#576 `__) +* add storage_config_uri (`#493 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* resolve memory leak for serialized message (`#502 `__) +* Use shared logic for importing the rosbag2_transport_py library in Python (`#482 `__) +* fix missing target dependencies (`#479 `__) +* reenable cppcheck for rosbag2_transport (`#461 `__) +* More reliable topic remapping test (`#456 `__) +* Add split by time to recording (`#409 `__) +* export shared_queues_vendor (`#434 `__) +* Contributors: Adam Dąbrowski, Andrea Sorbini, Chen Lihui, Dirk Thomas, Emerson Knapp, Karsten Knese, Michael Jeronimo, P. J. Reed, Piotr Jaroszek, jhdcs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosgraph_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#122 `__) +* Updating Quality Declaration (`#120 `__) +* Update README.md (`#119 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_adapter `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose .msg/.srv/.action to .idl conversion via rosidl translate CLI (`#576 `__) +* Support hex constants in msg files (`#559 `__) +* Treat \t as whitespace (`#557 `__) +* Update the maintainers of this repository. (`#536 `__) +* Refactor regex for valid package/field names (`#508 `__) +* Add pytest.ini so tests succeed locally (`#502 `__) +* Contributors: Chris Lalancette, Dereck Wonnacott, Dirk Thomas, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Align rosidl_cli package version with the rest of the repo. (`#579 `__) +* Expose an API for each rosidl CLI command. (`#577 `__) +* Add rosidl translate CLI. (`#575 `__) +* Add rosidl generate CLI. (`#567 `__) +* Contributors: Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Shorten some excessively long lines of CMake (`#571 `__) +* Update the maintainers of this repository. (`#536 `__) +* Modifications to python generator lib to return generated files (`#511 `__) +* Contributors: Alex Tyshka, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_generators `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#13 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_runtime `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#18 `__) +* Update QD to QL 1 (`#15 `__) +* Update maintainers (`#13 `__) +* Updated QD to 2 in README.md (`#12 `__) +* Update rosidl_default_runtime QD to QL2. (`#11 `__) +* Bump the QUALITY_DECLARATION to level 3. (`#10 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#9 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Shane Loretz, Stephen Brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose C code generation via rosidl generate CLI (`#569 `__) +* Strip action service suffixes from C include prefix (`#538 `__) +* Update the maintainers of this repository. (`#536 `__) +* Fix the declared language for a few packages (`#530 `__) +* Do not depend on rosidl_runtime_c when tests are disabled (`#503 `__) +* Contributors: Ben Wolsieffer, Chris Lalancette, Jacob Perron, Michel Hidalgo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose C++ code generation via rosidl generate CLI (`#570 `__) +* Switch to std::allocator_traits. (`#564 `__) +* Remove unnecessary assert on pointer created with new (`#555 `__) +* Use ASSERT_TRUE to check for nullptr. (`#543 `__) +* Update the maintainers of this repository. (`#536 `__) +* Add to_yaml() function for C++ messages (`#527 `__) +* Add function for getting a types fully qualified name (`#514 `__) +* Declaring is_message in namespace rosidl_generator_traits (`#512 `__) +* Contributors: Chris Lalancette, Devin Bonnie, Dirk Thomas, Jacob Perron, Michel Hidalgo, Sebastian Höffner, Stephen Brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_dds_idl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose .idl to DDS .idl conversion via rosidl translate CLI. (`#55 `__) +* Update maintainers. (`#54 `__) +* Contributors: Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove dependency from rosidl_typesupport_connext_c (`#127 `__) +* Expose Python code generation via rosidl generate CLI (`#123 `__) +* remove maintainer (`#126 `__) +* Update maintainers (`#119 `__) +* Fix too early decref of WString when converting from Python to C (`#117 `__) +* Add pytest.ini so tests succeed locally. (`#116 `__) +* Contributors: Andrea Sorbini, Chris Lalancette, Claire Wang, Dirk Thomas, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update and add package.xml descriptions to README (`#553 `__) +* Finish support for fixed-point literals. +* Fix parsing of small floats. +* Update the maintainers of this repository. (`#536 `__) +* Allow zero length string constants (`#507 `__) +* Add pytest.ini so tests succeed locally (`#502 `__) +* Contributors: Chris Lalancette, Dirk Thomas, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#581 `__) +* Shorten some excessively long lines of CMake (`#571 `__) +* Update and add package.xml descriptions to README (`#553 `__) +* Fix item number in QD (`#546 `__) +* Update the maintainers of this repository. (`#536 `__) +* Add rcutils dependency. (`#534 `__) +* QD: Add links to hosted API docs (`#533 `__) +* Updated Quality Level to 1 (`#532 `__) +* Add benchmarks for rosidl_runtime\_* packages (`#521 `__) +* Fix the declared language for a few packages (`#530 `__) +* Add fault injection macros and test (`#509 `__) +* Update rosidl_runtime_c QD to QL 2 (`#500 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Louise Poubel, Scott K Logan, Shane Loretz, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#581 `__) +* Fix typo of package name in README heading (`#561 `__) +* Update and add package.xml descriptions to README (`#553 `__) +* Fix item number in QD (`#546 `__) +* Update the maintainers of this repository. (`#536 `__) +* QD: Add links to hosted API docs (`#533 `__) +* Updated Quality Level to 1 (`#532 `__) +* Add benchmarks for rosidl_runtime\_* packages (`#521 `__) +* Add to_yaml() function for C++ messages (`#527 `__) +* Add function for getting a types fully qualified name (`#514 `__) +* Fix misuses of input iterators in BoundedVector (`#493 `__) +* Update QD to reflect QL 2 statuses (`#499 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Devin Bonnie, Dirk Thomas, Jacob Perron, Jonathan Wakely, Louise Poubel, Scott K Logan, Shane Loretz, Stephen Brawner, Tully Foote, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add pytest.ini so local tests don't display warning (`#12 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#108 `__) +* Remove dependencies from Connext type support (`#106 `__) +* Expose C typesupport generation via rosidl generate CLI (`#105 `__) +* Typo typesupport_identidentifier (`#103 `__) +* Remove type_support_dispatch.cpp files. (`#101 `__) +* Defer path resolution of rosidl typesupport libraries to dynamic linker. (`#98 `__) +* Ensure typesupport handle functions do not throw. (`#99 `__) +* Explicitly check lib pointer for null (`#95 `__) +* Update Quality Declaration to QL 1 (`#96 `__) +* Add mock for rcutils_get_symbol failure (`#93 `__) +* Update the maintainers (`#89 `__) +* Catch exception from has_symbol (`#86 `__) +* Added benchmark test to rosidl_typesupport_c/cpp (`#84 `__) +* Handle rcpputils::find_library_path() failure (`#85 `__) +* Add fault injection macros and unit tests (`#80 `__) +* Remove rethrow in extern c code (`#82 `__) +* Add Security Vulnerability Policy pointing to REP-2006 (`#76 `__) +* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Chris Lalancette, Jose Luis Rivero, Jose Tomas Lorente, Louise Poubel, Michel Hidalgo, Shane Loretz, Stephen Brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#108 `__) +* Remove dependencies from Connext type support (`#106 `__) +* Expose C++ typesupport generation via rosidl generate CLI (`#104 `__) +* Remove type_support_dispatch.cpp files. (`#101 `__) +* Defer path resolution of rosidl typesupport libraries to dynamic linker. (`#98 `__) +* Ensure typesupport handle functions do not throw. (`#99 `__) +* Explicitly check lib pointer for null (`#95 `__) +* Update Quality Declaration to QL 1 (`#96 `__) +* Update the maintainers (`#89 `__) +* Added benchmark test to rosidl_typesupport_c/cpp (`#84 `__) +* Handle rcpputils::find_library_path() failure (`#85 `__) +* De-duplicate type_support_map.h header (`#81 `__) +* Add fault injection macros and unit tests (`#80 `__) +* Add Security Vulnerability Policy pointing to REP-2006 (`#76 `__) +* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Chris Lalancette, Jose Luis Rivero, Louise Poubel, Michel Hidalgo, Stephen Brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#69 `__) +* Expose FastRTPS C typesupport generation via rosidl generate CLI (`#65 `__) +* Update QDs with up-to-date content (`#64 `__) +* Fix item number in QD (`#59 `__) +* Update QL to 2 +* Update package maintainers (`#55 `__) +* Updat QD (`#53 `__) +* Fix invalid return on deserialize function (`#51 `__) +* Added benchmark test to rosidl_typesupport_fastrtps_c/cpp (`#52 `__) +* Update exec dependencies (`#50 `__) +* Add Security Vulnerability Policy pointing to REP-2006 (`#44 `__) +* QD Update Version Stability to stable version (`#46 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jorge Perez, Louise Poubel, Michel Hidalgo, Stephen Brawner, shonigmann, sung-goo-kim + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#69 `__) +* Expose FastRTPS C++ typesupport generation via rosidl generate CLI (`#66 `__) +* Update QDs with up-to-date content (`#64 `__) +* Fix item number in QD (`#59 `__) +* Update QL to 2 +* Update package maintainers (`#55 `__) +* Update QD (`#53 `__) +* Add benchmark test to rosidl_typesupport_fastrtps_c/cpp (`#52 `__) +* Update exec dependencies (`#50 `__) +* Add Security Vulnerability Policy pointing to REP-2006 (`#44 `__) +* QD Update Version Stability to stable version (`#46 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jorge Perez, Louise Poubel, Michel Hidalgo, Stephen Brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#581 `__) +* Fix item number in QD (`#546 `__) +* Update the maintainers of this repository. (`#536 `__) +* QD: Add links to hosted API docs (`#533 `__) +* Update Quality Declaration to QL 1 for rosidl_typesupport_interface (`#519 `__) +* Update QD to reflect QL 2 statuses (`#499 `__) +* Contributors: Chris Lalancette, Louise Poubel, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose C introspection typesupport generation via rosidl generate CLI (`#572 `__) +* Update the maintainers of this repository. (`#536 `__) +* Fix get_function and get_const_function semantics for arrays (`#531 `__) +* Fix the declared language for a few packages (`#530 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose C++ introspection typesupport generation via rosidl generate CLI (`#573 `__) +* Update the maintainers of this repository. (`#536 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rpyutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Create a shared function for importing c libraries (`#4 `__) +* Add pytest.ini so local tests don't display warning (`#3 `__) +* Contributors: Chris Lalancette, Emerson Knapp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* 1.0.7 (`#243 `__) +* Remove Dirk from maintainers in package.xml files per request. (`#236 `__) +* Update maintainers for the crystal-devel branch (`#234 `__) +* Contributors: Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated Open Robotics maintainer +* Fixed package to run with ros2 run (`#8 `__) +* Contributors: Alejandro Hernández Cordero, Mabel Zhang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove an invalid import statement (`#101 `__) +* Reset timeline zoom after loading a new bag. (`#98 `__) +* Refactor the Rosbag2 class (`#91 `__) +* Fix exec_depend (`#89 `__) +* Use updated HistoryPolicy values to avoid deprecation warnings (`#88 `__) +* Enable recording for ROS2 (`#87 `__) +* Enable the playback functionality for ROS2 (`#85 `__) +* Port the topic and node selection dialogs to ROS2 (`#86 `__) +* Save the serialization format and offered_qos_profiles when exporting (`#84 `__) +* Enable the export/save bag functionality for ROS2 (`#82 `__) +* Update known message types and associated colors (`#81 `__) +* Open the bag directory instead of a single file (`#80 `__) +* Port the image_view plugin to ROS2 (`#78 `__) +* Clean up widgets in plot_view layout correctly (`#69 `__) (`#77 `__) +* Fix tuples for bisect calls (`#67 `__) (`#76 `__) +* Fix issue: no vertical scroll bar until window is resized (`#63 `__) (`#75 `__) +* Update the basic plugins for ROS2 (`#72 `__) +* Update the rosbag2 python module (`#71 `__) +* Dynamically resize the timeline when recording (`#66 `__) +* Starting point for resuming the ROS2 port (`#70 `__) +* Fix a bug with the status line progress bar (`#62 `__) +* Update a few minor status bar-related items (`#61 `__) +* Make the tree controls in the Raw View and Plot View consistent (`#57 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#58 `__) +* fix Python 3 issue: long/int (`#52 `__) +* save last directory opened to load a bag file (`#40 `__) +* fix shebang line for Python 3 (`#48 `__) +* bump CMake minimum version to avoid CMP0048 warning +* fix Python 3 exception, wrap filter call in list() (`#46 `__) +* add Python 3 conditional dependencies (`#44 `__) +* autopep8 (`#30 `__) +* add support for opening multiple bag files at once (`#25 `__) +* fix debug/warning messages for unicode filenames (`#26 `__) +* fix regression from version 0.4.10 (`#17 `__) +* fix regression from version 0.4.9 (`#16 `__) +* handle errors happening while loading a bag (`#14 `__) +* add rqt_bag.launch file (`#440 `__) +* fix Python 2 regression from version 0.4.4 (`#424 `__) +* use Python 3 compatible syntax (`#421 `__) +* fix race condition reading bag files (`#412 `__) +* add "From nodes" button to record mode (`#348 `__) +* show file size of bag file in the status bar (`#347 `__) +* fix mouse wheel delta in Qt 5 (`#376 `__) +* Support Qt 5 (in Kinetic and higher) as well as Qt 4 (in Jade and earlier) (`#359 `__) +* fix publishing wrong topic after scrolling (`#362 `__) +* RQT_BAG: Ensure monotonic clock publishing. Due to parallelism issues, a message can be published with a simulated timestamp in the past. This lead to undesired behaviors when using TF for example. +* Added step-by-step playback capability +* fix viewer plugin relocation issue (`#306 `__) +* fix topic type retrieval for multiple bag files (`#279 `__) +* fix region_changed signal emission when no start/end stamps are set +* improve right-click menu +* improve popup management (`#280 `__) +* implement recording of topic subsets +* sort the list of topics +* update plugin scripts to use full name to avoid future naming collisions +* fix visibility with dark Qt theme (`#263 `__) +* fix compatibility with Groovy, use queue_size for Python publishers only when available (`#243 `__) +* use thread for loading bag files, emit region changed signal used by plotting plugin (`#239 `__) +* export architecture_independent flag in package.xml (`#254 `__) +* fix closing and reopening topic views +* use queue_size for Python publishers +* fix raw view not showing fields named 'msg' (`#226 `__) +* add option to publish clock tim from bag (`#204 `__) +* add groups for rqt plugins, renamed some plugins (`#167 `__) +* fix high cpu load when idle (`#194 `__) +* update rqt_bag plugin interface to work with qt_gui_core 0.2.18 +* fix rendering of icons on OS X (`ros-visualization/rqt#83 `__) +* fix shutdown of plugin (`#31 `__) +* fix saving parts of a bag (`#96 `__) +* fix long topic names (`#114 `__) +* fix zoom behavior (`#76 `__) +* Fix; skips time when resuming playback (`#5 `__) +* Fix; timestamp printing issue (`#6 `__) +* expose command line arguments to rqt_bag script +* added fix to set play/pause button correctly when fastforwarding/rewinding, adjusted time headers to 0m00s instead of 0:00m for ease of reading +* support passing bagfiles on the command line (currently behind --args) +* first release of this package into Groovy +* Contributors: Aaron Blasdel, Chris Lalancette, Michael Grupp, Michael Jeronimo, lsouchet, sambrose + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Refactor the Rosbag2 class (`#91 `__) +* Port the plot view to ROS2 (`#79 `__) +* Port the image_view plugin to ROS2 (`#78 `__) +* Starting point for resuming the ROS2 port (`#70 `__) +* Make the tree controls in the Raw View and Plot View consistent (`#57 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#58 `__) +* initialize pil_mode when image is compressed (`#54 `__) +* support 16-bit bayer images (`#45 `__) +* maintain image aspect ratio (`#32 `__) +* fix Python 3 issue: long/int (`#51 `__) +* fix Python 3 issue: ensure str is encoded before decoding (`#50 `__) +* bump CMake minimum version to avoid CMP0048 warning +* add Python 3 conditional dependencies (`#44 `__) +* add cairocffi as the fallback module (`#43 `__) +* autopep8 (`#30 `__) +* fix Python 2 regression from version 0.4.4 (`#426 `__) +* use Python 3 compatible syntax (`#421 `__) +* fix crash when toggling thumbnail (`#380 `__) +* lock bag when reading for plotting (`#382 `__) +* Support Qt 5 (in Kinetic and higher) as well as Qt 4 (in Jade and earlier) (`#359 `__) +* add missing dependency on rqt_plot (`#316 `__) +* work around Pillow segfault if PyQt5 is installed (`#289 `__, `#290 `__) +* add displaying of depth image thumbnails +* add missing dependency on python-cairo (`#269 `__) +* fix missing installation of resource subfolder +* add plotting plugin (`#239 `__) +* fix rqt_bag to plot array members (`#253 `__) +* export architecture_independent flag in package.xml (`#254 `__) +* fix PIL/Pillow error (`#224 `__) +* first release of this package into Groovy +* Contributors: John Stechschulte, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores in setup.cfg instead of dashes (`#31 `__) +* Fix regression introduced in `#21 `__ (`#28 `__) +* Changed the build type to ament_python and added setup.cfg (`#21 `__) +* Contributors: Alejandro Hernández Cordero, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_graph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make topics that have qos incompatibilities red in the graph, add information to the node tooltip (`#61 `__) +* Add node name, topic name, and endpoint kind to the qos edge tooltip (`#60 `__) +* Update maintainers for ROS2 branches (`#55 `__) +* add edge tooltip with QoS of publishers and subscribers (`#53 `__) +* install executable rqt_graph (`#49 `__) +* add setup.cfg with script install directories (`#42 `__) +* add pytest.ini so local tests don't display warning (`#48 `__) +* Contributors: Ivan Santiago Paunovic, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* getiterator() renamed to iter() in Python 3.9 (`#239 `__) +* Contributors: goekce + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* use tgt compile features (`#247 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix a crash at shutdown (`#248 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_msg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#8 `__) +* Use rosidl_runtype_py instead of message_helpers where possible (`#11 `__) +* Contributors: Alejandro Hernández Cordero, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_plot `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#58 `__) +* Fix plots of array items (`#71 `__) +* Update maintainers +* Contributors: Alejandro Hernández Cordero, Ivan Santiago Paunovic, Mabel Zhang + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#18 `__) +* Drop numpy.float128 references (`#26 `__) +* Use rosidl_runtime_py instead of rqt_py_common where possible (`#24 `__) +* Add now() to evaluation (`#22 `__) +* fix setting expressions on sequence items (`#16 `__) +* Contributors: Alejandro Hernández Cordero, Ivan Santiago Paunovic, Michel Hidalgo, Yossi Ovcharik + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Avoid installing test interfaces (`#228 `__) +* Contributors: Dirk Thomas + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#8 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_reconfigure `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanups to the install scripts. (`#103 `__) +* Fix a flake8 warning. (`#99 `__) +* Use timeouts in service calls to avoid hangs (`#98 `__) +* Add maintainer to package.xml (`#95 `__) +* Save instance state in rqt settings (`#90 `__) +* Use safe YAML loader (`#89 `__) +* Don't process scroll events unless specifically focused (`#88 `__) +* Fix node selection from command line (`#87 `__) +* Add pytest.ini so local tests don't display warning (`#91 `__) +* Support PEP 338 invocation of rqt_reconfigure (`#85 `__) +* Fixed package to run with ros2 run (`#81 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_service_caller `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#13 `__) +* ignore services that don't use the SRV_MODE ('srv') (`#20 `__) +* Contributors: Alejandro Hernández Cordero, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_shell `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#11 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_srv `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#4 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_top `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed the build type to ament_python and fixed package to run with ros2 run (`#8 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add pytest.ini to silence warnings when running locally. +* Fix warnings pointed out by flake8. +* Created an entry-point for rqt_topic in setup.py (`#16 `__) +* Fix flake8 errors and add linter tests (`#28 `__) +* Update Open Robotics Maintainer (`#26 `__) +* Use raw / non-string value for ordering (`#23 `__) +* Support order fields as defined in message (`#22 `__) +* Fix the type cell value for sequence items (`#21 `__) +* Updated version package and license in setup.py (`#17 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rti_connext_dds_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Pass ``-Wl,--no-as-needed`` for system dependencies of Connext 5.3.1. +* Set ``IMPORTED_NO_SONAME true`` for Connext 5.3.1 imported library target. +* Add ```` for ``ament_cmake``. +* Add ```` for ``rti-connext-dds-5.3.1`` +* Add dependency from rti-connext-dds-5.3.1. +* Initial release. + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rttest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix up nonsensical handling of NULL in rttest_get\_{params,statistics} (`#107 `__) +* Remove "struct" from rttest_sample_buffer variable declaration. (`#105 `__) +* Convert the sample buffer to a vector. (`#104 `__) +* Use strdup instead of strlen/strcpy dance. (`#100 `__) +* Enable basic warnings in rttest (`#99 `__) +* Only copy an rttest_sample_buffer if it is not nullptr. (`#98 `__) +* Convert timespec to uint64 not long and vice versa (`#94 `__) (`#96 `__) +* Fix standard deviation overflow(`#95 `__) (`#97 `__) +* Contributors: Audrow Nash, Chris Lalancette, y-okumura-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use "%s" as format string literal in logging macros (`#633 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* Move and update documentation for ROS 2 (`#600 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_assimp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Always preserve source permissions in vendor packages (`#647 `__) +* Add an override flag to force vendored build (`#642 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* Updated a hack to avoid CMake warning with assimp 5.0.1 and older, applying it cross platforms (`#565 `__) +* Contributors: Dirk Thomas, Jacob Perron, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add visualization_frame to the public API (`#660 `__) +* Add ViewPicker::get3DPatch to the public API (`#657 `__) +* Fix byte indexing for depth patch pixels (`#661 `__) +* fix toolbar vanishing when pressing escape (`#656 `__) +* Expose VisualizationManager and YamlConfigReader to the public API (`#649 `__) +* Use the stack for the classes in the property test. (`#644 `__) +* Check that the views_man\_ and views_man\_->getCurrent() are not nullptr. (`#634 `__) +* Fix for mousewheel to zoom in/out (`#623 `__) +* Ensure rviz_common::MessageFilterDisplay processes messages in the main thread (`#620 `__) +* Fix render window disppearing after saving image (`#611 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* TimePanel port (`#599 `__) +* Upgrade to tinyxml2 for rviz (`#418 `__) +* Fix segfault on changing filter size for non-existent topic (`#597 `__) +* improve color support for themes (`#590 `__) +* Fix topic IntProperty number ranges (`#596 `__) +* Switch to nullptr everywhere. (`#592 `__) +* Expose MessageFilterDisplay's queue size (`#593 `__) +* Filter topics in drop down menu (`#591 `__) +* rviz_common: Remove variadic macro warning check (`#421 `__) +* Use retriever.hpp (`#589 `__) +* Fix the order of destructors (`#572 `__) +* Changed to not install test header files in rviz_rendering. (`#564 `__) +* Fixed alphabetical include order (`#563 `__) +* Changed to avoid trying to moc generate ``env_config.hpp`` file. (`#550 `__) +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Jacob Perron, Jafar Abdi, Joseph Schornak, Karsten Knese, Martin Idel, Michael Ferguson, Michael Jeronimo, Michel Hidalgo, Nico Neumann, Rich Mattes, Shane Loretz, ipa-fez, spiralray + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ViewPicker::get3DPatch to the public API (`#657 `__) +* Allow to zoom more with orbit controller (`#654 `__) +* Fix possible nullptr access in robot_joint.cpp. (`#636 `__) +* Fix for mousewheel to zoom in/out (`#623 `__) +* Make the types explicit in quaternion_helper.hpp. (`#625 `__) +* Update status message by removing colon or adjust colon position (`#624 `__) +* Do not use assume every RenderPanel has a ViewController. (`#613 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* TimePanel port (`#599 `__) +* Upgrade to tinyxml2 for rviz (`#418 `__) +* Use retriever.hpp (`#589 `__) +* Added covariance settings to set pose estimate (`#569 `__) +* use reference in range loops to avoid copy (`#577 `__) +* Changed to not install test header files in rviz_rendering. (`#564 `__) +* Changed to use a dedicated TransformListener thread. (`#551 `__) +* Suppressed warnings when building with older Qt versions. (`#562 `__) +* Restored compatibility with older Qt versions (`#561 `__) +* Contributors: Chen Lihui, Chris Lalancette, Dirk Thomas, Jacob Perron, Joseph Schornak, Martin Idel, Matthijs den Toom, Michel Hidalgo, Nico Neumann, Shane Loretz, Victor Lamoine, ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_ogre_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Always preserve source permissions in vendor packages (`#647 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* Pass through CMAKE\_{C,CXX}_FLAGS to OGRE build (`#587 `__) +* Contributors: Jacob Perron, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* reset current line width when calculating text width (`#655 `__) +* Silence a dead store warning. (`#643 `__) +* Fix a memory leak when using the ResourceIOSystem. (`#641 `__) +* Revert "Support loading meshes other than .mesh and .stl with package URIs (`#610 `__)" (`#638 `__) +* Prevent rviz_rendering::AssimpLoader from loading materials twice. (`#622 `__) +* Support loading meshes other than .mesh and .stl with package URIs (`#610 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* Switch to nullptr everywhere. (`#592 `__) +* Use retriever.hpp (`#589 `__) +* Avoid hidding base class getRenderOperation in PointCloudRenderable (`#586 `__) +* Changed to not install test header files in rviz_rendering. (`#564 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, ipa-fez + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* Use retriever.hpp (`#589 `__) +* Changed to not install test header files in rviz_rendering. (`#564 `__) +* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_visual_testing_framework `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Quiet a clang warning about a Qt memory leak. (`#651 `__) +* use rcutils_get_env. (`#609 `__) +* Add linters and use ament_lint_auto (`#608 `__) +* Update maintainers (`#607 `__) +* Contributors: Chris Lalancette, Jacob Perron, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Fix PointCloud2Iterator namespacing in docs (`#139 `__) +* Add coverage/performance to qd for sensor_msgs (`#137 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Missing cstring header for memcpy in fill_image.hpp (`#126 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Andre Nguyen, Chris Lalancette, Jose Luis Rivero, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg (`#150 `__) +* Port of point_cloud2.py from ROS1 to ROS2. As seperate pkg. (`#128 `__) +* Contributors: Ivan Santiago Paunovic, Sebastian Grans + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shape_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shared_queues_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Contributors: Emerson Knapp, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`spdlog_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#24 `__) +* Update to spdlog 1.8.2 (`#23 `__) +* Remove a stale TODO (`#22 `__) +* Always preserve source permissions in vendor packages (`#20 `__) +* Remove unnecessary call to find_package(PATCH) (`#18 `__) +* Updated QD to 1 (`#16 `__) +* bump spdlog version to 1.6.1 (`#15 `__) +* Bump QD to level 3 and updated QD (`#14 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#13 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Scott K Logan, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sqlite3_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Always preserve source permissions in vendor packages (`#645 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* use interface_include_directories (`#426 `__) +* Contributors: Emerson Knapp, Karsten Knese, Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sros2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Skip mypy test on platforms using importlib_resources (`#258 `__) +* Enable topic "ros_discovery_info" for rmw_connextdds (`#253 `__) +* Declare missing dependency on python3-importlib-resources (`#249 `__) Co-authored-by: +* Fix namedtuple names. (`#250 `__) +* parameter_events topic is now absolute (#233) Signed-off-by: Mikael Arguedas +* Expose keystore operations in public API (`#241 `__) +* add cyclonedds to the list of rmw using graph info topics (`#231 `__) +* Add scope parameter (`#230 `__) +* Fix name of argument passed to NodeStrategy (`#227 `__) +* Remove the use of pkg_resources. (`#225 `__) +* Make use of ros_testing to test policy generation. (`#214 `__) +* Add pytest.ini so local tests don't display warning (`#224 `__) +* Fix list keys verb (`#219 `__) +* Contributors: Andrea Sorbini, Chris Lalancette, Jacob Perron, Jose Luis Rivero, Kyle Fazzari, Michel Hidalgo, Mikael Arguedas, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`statistics_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updating Quality Declaration (`#120 `__) +* Update quality declaration to QL 1. (`#116 `__) +* Update package maintainers. (`#112 `__) +* Increase Quality level of packages to 3 (`#108 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#106 `__) +* Updating QD to reflect package versions (`#107 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) Co-authored-by: Simon Honigmann +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_srvs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`stereo_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tango_icons_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add exec_depend on tango-icon-theme system package (`#8 `__) +* Added common linters (`#7 `__) * Added common linters * Fixed license in package.xml +* Remaned package qt_gui_icons -> tango_icons_vendor (`#4 `__) * Remaned package qt_gui_icons -> tango_icons_vendor * Updated CMake var to install tango icons: INSTALL_TANGO_ICONS * Added cmake option INSTALL_TANGO_ICONS * Fixed logic * set INSTALL_TANGO_ICONS_DEFAULT_VALUE to option * Make linters happy +* Updated link on the description (`#6 `__) +* Updated the maintainer (`#5 `__) +* Version 0.0.0 this package was never released (`#3 `__) +* Install icons by default on macOS too (`#1 `__) +* Updating package.xml +* fixup! Install tango icons +* Adding icons +* Install tango icons +* Contributors: Alejandro Hernández Cordero, Scott K Logan, Stephen, Stephen Brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers. (`#450 `__) +* Enable -Wall, -Wextra, and -Wpedantic. (`#447 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli_remapping `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix test_cli_remapping flaky test. (`#470 `__) +* Update maintainers. (`#450 `__) +* Enable -Wall, -Wextra, and -Wpedantic. (`#448 `__) +* Contributors: Audrow Nash, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_communication `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for rmw_connextdds. (`#463 `__) +* Kill off the ros2 daemon before running tests. (`#460 `__) +* Remove Opensplice from test_communication. (`#460 `__) +* Make TestMessageSerialization robust to missed messages. (`#456 `__) +* Add corresponding rclcpp::shutdown. (`#455 `__) +* Update maintainers. (`#450 `__) +* Contributors: Andrea Sorbini, Chris Lalancette, Jacob Perron, Stephen Brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_interface_files `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer (`#13 `__) +* Contributors: Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add a package marker to test_launch_ros. (`#226 `__) +* Re-order shutdown vs node destruction (`#213 `__) +* Increase test_composable_node_container timeout (`#195 `__) +* Remove constructors arguments deprecated since Foxy (`#190 `__) +* Merge pull request `#183 `__ from ros2/update-maintainers +* Move previous maintainer to +* Update the package.xml files with the latest Open Robotics maintainers +* Handle any substitution types for SetParameter name argument (`#182 `__) +* Address security bug in yaml loading (`#175 `__) +* Resolve TODO in test (`#172 `__) +* Fix case where list of composable nodes is zero (`#173 `__) +* Do not use event handler for loading composable nodes (`#170 `__) +* Fix race with launch context changes when loading composable nodes (`#166 `__) +* Substitutions in parameter files (`#168 `__) +* Fix problems when parsing a ``Command`` ``Substitution`` as a parameter value (`#137 `__) +* Drop double single-quoted params. (`#164 `__) +* Add a way to set remapping rules for all nodes in the same scope (`#163 `__) +* Fix ComposableNode ignoring PushRosNamespace actions (`#162 `__) +* Add a SetParameter action that sets a parameter to all nodes in the same scope (`#158 `__) +* Make namespace parameter mandatory in LifecycleNode constructor (`#157 `__) +* Avoid using a wildcard to specify parameters if possible (`#154 `__) +* Remove the loop parameter from async.sleep. (`#155 `__) +* Fix no specified namespace (`#153 `__) +* Fix test_node_frontend (`#146 `__) +* Add pytest.ini so local tests don't display warning (`#152 `__) +* Contributors: Chris Lalancette, Dan Rose, Ivan Santiago Paunovic, Jacob Perron, Michael Jeronimo, Michel Hidalgo, Scott K Logan, Víctor Mayoral Vilches + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers (`#465 `__) +* Add pytest.ini to test_launch_testing so tests succeed locally. (`#431 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update package maintainers. (`#112 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_quality_of_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for rmw_connextdds. (`#463 `__) +* Run QoS tests. (`#441 `__) +* Update maintainers. (`#450 `__) +* Contributors: Andrea Sorbini, Jacob Perron, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Reenable test that used to be flaky. (`#467 `__) +* Get_parameters_service\_ should return empty if allow_undeclared\_ is false. (`#466 `__) +* Make test pass after rclcpp#1532. (`#465 `__) +* Adapt tests to statically typed parameters. (`#462 `__) +* Guard against TOCTTOU with rclcpp::ok and rclcpp:spin_some. (`#459 `__) +* Update parameter client test with timeout. (`#457 `__) +* Call rclcpp::init and rclcpp::shutdown in each test for test_rclcpp. (`#454 `__) +* Set cppcheck timeout to 400 seconds. (`#453 `__) +* Modify to match Waitable interface adding take_data. (`#444 `__) +* Update maintainers. (`#450 `__) +* Fix rclcpp timeout subscriber test. (`#440 `__) * Use nonzero lower bound for timeout checks. * Relax time tolerance. +* Show numbers of nanseconds in EXPECT with durations. (`#438 `__) * Show numbers of nanseconds in expect with durations * Fix syntax +* Remove ament_pytest dependency from test_rclcpp. (`#437 `__) It is not used in test_rclcpp anywhere. +* Contributors: Audrow Nash, Chris Lalancette, Dirk Thomas, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, Stephen Brawner, Tomoya Fujita, tomoya + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Implement test for subscription loaned messages (`#186 `__) +* Remove rmw_connext_cpp. (`#183 `__) +* Add support for rmw_connextdds (`#182 `__) +* Add function for checking QoS profile compatibility (`#180 `__) +* Make sure to initialize the rmw_message_sequence after init. (`#175 `__) +* Set the value of is_available before entering the loop (`#173 `__) +* Set the return value of rmw_ret_t before entering the loop. (`#171 `__) +* Add some additional checking that cleanup happens. (`#168 `__) +* Add test to check rmw_send_response when the client is gone (`#162 `__) +* Update maintainers (`#154 `__) +* Add fault injection tests to construction/destroy APIs. (`#144 `__) +* Add tests bad type_support implementation (`#152 `__) +* Add tests for localhost-only node creation (`#150 `__) +* Added rmw_service_server_is_available tests (`#140 `__) +* Use 10x the intraprocess delay to wait for sent requests. (`#148 `__) +* Added rmw_wait, rmw_create_wait_set, and rmw_destroy_wait_set tests (`#139 `__) +* Add tests service/client request/response with bad arguments (`#141 `__) +* Added test for rmw_get_serialized_message_size (`#142 `__) +* Add service/client construction/destruction API test coverage. (`#138 `__) +* Added rmw_publisher_allocation and rmw_subscription_allocation related tests (`#137 `__) +* Add tests take serialized with info bad arguments (`#130 `__) +* Add gid API test coverage. (`#134 `__) +* Add tests take bad arguments (`#125 `__) +* Bump graph API test coverage. (`#132 `__) +* Add tests take sequence serialized with bad arguments (`#129 `__) +* Add tests take sequence + take sequence with bad arguments (`#128 `__) +* Add tests take with info bad arguments (`#126 `__) +* Add tests for non-implemented rmw_take\_* functions (`#131 `__) +* Add tests publish serialized bad arguments (`#124 `__) +* Add tests publish bad arguments (`#123 `__) +* Add tests non-implemented functions + loan bad arguments (`#122 `__) +* Add missing empty topic name tests. (`#136 `__) +* Add rmw_get_serialization_format() smoke test. (`#133 `__) +* Complete publisher/subscription QoS query API test coverage. (`#120 `__) +* Remove duplicate assertions (`#121 `__) +* Add publisher/subscription matched count API test coverage. (`#119 `__) +* Add serialize/deserialize API test coverage. (`#118 `__) +* Add subscription API test coverage. (`#117 `__) +* Extend publisher API test coverage (`#115 `__) +* Add node construction/destruction API test coverage. (`#112 `__) +* Check that rmw_init() fails if no enclave is given. (`#113 `__) +* Add init options API test coverage. (`#108 `__) +* Complete init/shutdown API test coverage. (`#107 `__) +* Add dependency on ament_cmake_gtest (`#109 `__) +* Add test_rmw_implementation package. (`#106 `__) +* Contributors: Alejandro Hernández Cordero, Andrea Sorbini, Chris Lalancette, Geoffrey Biggs, Ivan Santiago Paunovic, Jacob Perron, Jose Tomas Lorente, José Luis Bueno López, Michel Hidalgo, Miguel Company, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_security `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for rmw_connextdds. (`#463 `__) +* Update deprecated gtest macros. (`#449 `__) +* Update maintainers. (`#450 `__) +* Run test_security on CycloneDDS as well. (`#408 `__) +* Remove invalid cert folder to force regeneration of certificates. (`#434 `__) +* Contributors: Andrea Sorbini, Audrow Nash, Jacob Perron, Mikael Arguedas + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Fix a TOCTTOU race in tf2. (`#307 `__) +* Fixed memory leak in Buffer::waitForTransform (`#281 `__) +* relax test timings to pass with Connext (`#304 `__) +* Explicitly initialize instances of tf2::Duration (`#291 `__) +* Generate callbacks after updating message\_ (`#274 `__) +* fix test_static_publisher in macos (`#284 `__) +* Fix up the dependencies in test_tf2. (`#277 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Dirk Thomas, Ivan Santiago Paunovic, Martin Ganeff, Michael Carroll, ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#394 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Active usual compiler warnings in tf2 (`#322 `__) +* Cleanups in buffer_core.cpp. (`#301 `__) +* Add PoseWithCovarianceStamped transform support (`#312 `__) +* Fix a TOCTTOU race in tf2. (`#307 `__) +* Fixed memory leak in Buffer::waitForTransform (`#281 `__) +* Add common linters to tf2. (`#258 `__) +* Provide more available error messaging for nonexistent and invalid frames in canTransform (`ros2 #187 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ivan Santiago Paunovic, Joshua Whitley, Martin Ganeff + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_bullet `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Suppress compiler warning on Centos (`#290 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix linter errors (`#385 `__) +* Fix up the style in tf2_eigen. (`#378 `__) +* Fix doTransform with Eigen Quaternion (`#369 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Contributors: Audrow Nash, Bjar Ne, Chris Lalancette, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix order of find eigen3_cmake_module & find eigen3 (`#344 `__) +* Update package.xml (`#333 `__) +* Port eigen_kdl.h/cpp to ROS2 (`#311 `__) +* Contributors: Ahmed Sobhy, Jafar Abdi + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix doTransform with Eigen Quaternion (`#369 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Add PoseWithCovarianceStamped transform support (`#312 `__) +* Don't install python tf2_geometry_msgs (`#299 `__) It hasn't been ported yet. Closes https://github.com/ros2/geometry2/issues/285 +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) * Split tf2_ros in tf2_ros and tf2_ros_py +* Contributors: Alejandro Hernández Cordero, Bjar Ne, Chris Lalancette, Ivan Santiago Paunovic, Joshua Whitley, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Adapt to Python 3.9 (`#362 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Add in pytest.ini so tests succeed locally. (`#280 `__) +* Contributors: Chris Lalancette, Homalozoa X + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Guard against access to null node pointer (`#393 `__) +* Allow to reconfigure durability for /tf topic broadcaster/listener (`#383 `__) +* Fix the rcl type used in the time jump. (`#391 `__) +* Fix linter errors (`#385 `__) +* fix accessing freed resources (`#386 `__) +* Allow reconfiguring qos of tf and tf_static topics through parameters (`#381 `__) +* Replace ROS\_* logging macros and use RCLCPP\_* instead (`#380 `__) +* Improve message filters error messages (`#364 `__) +* Clarify the role of child_frame_id and header.frame_id in the documentation. (`#345 `__) +* Remove usage of deprecated rclcpp::Duration constructor (`#340 `__) +* Remove messages_count member from tf2_ros::MessageFilter. (`#335 `__) +* Style fixup in tf2_ros. (`#325 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Update goal response callback signature (`#323 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Fixed memory leak in Buffer::waitForTransform (`#281 `__) +* fix time-reset test with Connext (`#306 `__) +* reenable FrameGraph server (`#198 `__) +* Use the usual style of parameters for static_transform_program (`#300 `__) +* Make static_transform_broadcaster consistent with its command line description (`#294 `__) +* Avoid using invalid std::list iterators (`#293 `__) +* Generate callbacks after updating message\_ (`#274 `__) +* Moved unique_lock of messages_mutex\_ to guarantee pointer (`#279 `__) +* Fix dependencies in tf2_ros. (`#269 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Dirk Thomas, Hunter L. Allen, Ivan Santiago Paunovic, Jacob Perron, Kazunari Tanaka, Martin Ganeff, Michael Carroll, Vikas Dhiman, ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg. (`#403 `__) (`#404 `__) +* Use global namespace for TransformListener topics (`#390 `__) +* Fix indentation of a comment in buffer.py (`#371 `__) +* Update rclpy.Rate TODO with url to issue (`#324 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Add deprecation warnings to lookup_transform to handle the passing of the incorrect Time object. (`#319 `__) +* change signature to show true arguments (`#321 `__) +* Handle when None passed to qos argument in the constructor of TransformBroadcaster. (`#320 `__) +* Add type hints to tf2_ros_py code(`#275 `__) (`#315 `__) +* Clear callbacks_to_remove variable after removing (`#303 `__) +* Fix cache_time None check in buffer.py (`#297 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Matthijs den Toom, ScottMcMichael, surfertas + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Activate usual compiler warnings and fix errors (`#270 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use underscores instead of dashes in setup.cfg. (`#403 `__) (`#404 `__) +* Add wait time option to view_frames (`#374 `__) +* Cleanup tf2_tools to be more modern. (`#351 `__) +* Update maintainers of the ros2/geometry2 fork. (`#328 `__) +* Address security bug in yaml loading (`#313 `__) +* Split tf2_ros in tf2_ros and tf2_ros_py (`#210 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Víctor Mayoral Vilches + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to standard __VA_ARGS_\_. (`#9 `__) +* Enable basic warnings (`#8 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in the Apache license to tlsf_cpp. (`#108 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_monitor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use is_alive for threads. (`#510 `__) (`#513 `__) +* Use underscores instead of dashes in setup.cfg (`#502 `__) +* Change index.ros.org -> docs.ros.org. (`#496 `__) +* Update deprecated qos policy value names (`#468 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_statistics_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#496 `__) +* Update logging macros (`#476 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#466 `__) +* Create new topic statistics demo package (`#454 `__) +* Contributors: Audrow Nash, Chris Lalancette, Michael Jeronimo, Prajakta Gokhale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update QD to be more specific about public API +* Namespace tracetools C++ functions and macros and deprecate current ones +* Add support for rcl_publish and rclcpp_publish tracepoints +* Add instrumentation support for linking a timer to a node +* Bring tracetools up to quality level 1 +* Add lifecycle node state transition instrumentation +* Do not export tracetools if empty +* Allow disabling tracetools status app +* Contributors: Christophe Bedard, Ingo Lütkebohle, José Antonio Moral + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow configuring tracing directory through environment variables +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update after namespacing C++ tracetools functions and macros +* Add tests for rcl_publish and rclcpp_publish tracepoints +* Allow asserting order of list of events +* Allow skipping test trace cleanup by setting an environment variable +* Add test for timer-node linking instrumentation +* Increased code coverage > 94% as part of QL1 +* Add lifecycle node state transition instrumentation test +* Contributors: Alejandro Hernández Cordero, Christophe Bedard, Ingo Lütkebohle + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for rcl_publish and rclcpp_publish tracepoints +* Fix flake8 blind except error by using more concrete types +* Allow configuring tracing directory through environment variables +* Cleanly stop ros2trace/tracetools_trace tracing on SIGINT +* Add instrumentation support for linking a timer to a node +* Add lifecycle node state transition instrumentation +* Contributors: Christophe Bedard, Ingo Lütkebohle + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`trajectory_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Finish up API documentation (`#123 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`turtlesim `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Ignore key up events in teleop_turtle_key on Windows (`#118 `__) +* Update maintainers (`#106 `__) +* Update goal response callback signature (`#100 `__) +* add holonomic motion for turtlesim (`#98 `__) +* add step value to turtlesim color parameters (`#91 `__) +* update Foxy turtle (`#90 `__) +* Contributors: Jacob Perron, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`unique_identifier_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org (`#21 `__) +* Update QD to QL 1 (`#17 `__) +* Update Quality Declaration to QL2. (`#15 `__) +* Update Quality level to level 3 (`#13 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#11 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Work around Windows min/max bug. (`#21 `__) +* Enable -Wall -Wextra -Wpedantic (`#20 `__) +* Add dependency on TinyXML2 (`#19 `__) +* Remove TinyXML dependency from urdf. (`#17 `__) +* Make urdf plugable and revive urdf_parser_plugin (`#13 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf_parser_plugin `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Export urdfdom_headers as urdf_parser_plugin dependency. (`#25 `__) +* Make urdf plugable and revive urdf_parser_plugin (`#13 `__) +* Contributors: Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`visualization_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change index.ros.org -> docs.ros.org. (`#149 `__) +* updating quality declaration links (re: `ros2/docs.ros2.org#52 `__) (`#145 `__) +* Update QDs to QL 1 (`#135 `__) +* Update package maintainers. (`#132 `__) +* Updated Quality Level to 2 (`#131 `__) +* Update Quality levels to level 3 (`#124 `__) +* Add Security Vulnerability Policy pointing to REP-2006. (`#120 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michel Hidalgo, Stephen Brawner, brawner, shonigmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`yaml_cpp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Always preserve source permissions in vendor packages (`#22 `__) +* Add an override flag to force vendored build (`#21 `__) +* Reapply "Use system installed yaml-cpp 0.6 if available (`#8 `__)" (`#16 `__) +* Revert "Use system installed yaml-cpp 0.6 if available (`#8 `__)" (`#15 `__) +* Use system installed yaml-cpp 0.6 if available (`#8 `__) +* Contributors: Ivan Santiago Paunovic, Scott K Logan, Sean Yen + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`zstd_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly add emersonknapp as maintainer (`#692 `__) +* Always preserve source permissions in vendor packages (`#645 `__) +* Zstd should not install internal headers - some of them try include others that aren't installed. We don't use them. Avoid the situation (`#631 `__) +* Patch zstd 1.4.4 to include cmake_minimum_version bump to 2.8.12 (`#579 `__) +* Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) +* Contributors: Emerson Knapp, Michael Jeronimo, Scott K Logan \ No newline at end of file diff --git a/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst b/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst index d4273a9d1ab..b169724ec7e 100644 --- a/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst @@ -1,3884 +1,3888 @@ -Humble Hawksbill changelog -========================== - -This page is a list of the complete changes in all ROS 2 core packages since the previous release. - -.. contents:: Table of Contents - :local: - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`actionlib_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* remove google style from clang-tidy default settings, removing need for default config file (`#337 `__) -* Improvements to ament_lint_clang_tidy. (`#316 `__) -* Contributors: Audrow Nash, Steven! Ragnarök, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Add ament_cmake_gen_version_h package (`#198 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz, serge-nikulin - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Fix typo in ament_auto_find_test_dependencies (`#363 `__) -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Add ament_auto_add_gtest (`#344 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Daisuke Nishimatsu, Joshua Whitley, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Improvements to ament_lint_clang_tidy. (`#316 `__) -* Contributors: Audrow Nash, Steven! Ragnarök - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Increase the ament_cmake_copyright default timeout. (`#355 `__) -* Update forthcoming version in changelogs -* [ament_cmake_copyright] Add file exclusion support (`#328 `__) * [ament_cmake_copyright] Add file exclusion support In the ``ament_copyright`` CMake function, the optional list argument ``EXCLUDE`` can now be used as an exclusion specifier. * [ament_cmake_copyright] Fix function header typo Remove reference to ``cppcheck`` in the ``EXCLUDE`` arg description. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Support commands with executable targets (`#352 `__) -* doc/resource_index: Indent list subitems correctly (`#342 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Michal Sojka, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* [ament_cmake_cppcheck] Fix file exclusion behavior (`#329 `__) The ``EXCLUDE`` argument of the ``ament_cppcheck`` CMake function is a list, i.e. a multi-value keyword. As such, it needs to be placed out of the one-value keywords from the ``cmake_parse_arguments`` function call. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Add cppcheck libraries option (`#323 `__) * adding ament_cppcheck libraries option * pass libraries option via CMake Co-authored-by: William Wedler -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Will - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_definitions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Add note regarding interface libraries (`#339 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Bjar Ne, Chris Lalancette, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_link_flags `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_targets `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Add custom config file support for flake8 (`#331 `__) -* Contributors: Audrow Nash, Kenji Miyake - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gen_version_h `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_generate_version_header and deprecate ament_cmake_gen_version_h (`#377 `__) -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Add ament_cmake_gen_version_h package (`#198 `__) -* Contributors: Audrow Nash, Shane Loretz, serge-nikulin - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gmock `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_google_benchmark `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gtest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Make ament_include_directories_order a function to allow paths with backslashes on windows. (`#371 `__) * Repalce backslashes with forward slashes on Windows * Typo * Replace slashes in ARGN * Don't quote * Check ARGN has values before trying to string(REPLACE them * Make ament_include_directories_order a function -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_nose `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Support commands with executable targets (`#352 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Fix misleading comment (`#361 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Support commands with executable targets (`#352 `__) -* Mention other platforms in 'pytest/pytest-cov not found' warning (`#337 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Christophe Bedard, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use sysconfig directly to determine python lib dir (`#378 `__) -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Make ament_cmake_python symlink for symlink installs only (`#357 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Make ament_python_install_package() match setuptools' egg names. (`#338 `__) -* Drop ament_cmake_python outdated tests. (`#340 `__) -* Update maintainers (`#336 `__) -* Make ament_python_install_package() install console_scripts (`#328 `__) -* Contributors: Audrow Nash, Chris Lalancette, Michel Hidalgo, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Refactor domain_coordinator API to use a context manager (`#12 `__) -* Contributors: Timo Röhling - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_target_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Fix bug packages with multiple configurations (`#318 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* [ament_cmake_uncrustify] Add file exclude support (`#330 `__) In the ``ament_uncrustify`` CMake function, the optional list argument ``EXCLUDE`` can now be used as an exclusion specifier. -* Contributors: Abrar Rahman Protyasha, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_version `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelog -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) -* Use FindPython3 instead of FindPythonInterp (`#355 `__) -* Update maintainers (`#336 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix importlib_metadata warning on Python 3.10. (`#365 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. -* Add SPDX identifiers to the licenses. (`#315 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable cppcheck 2.x. (`#345 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Add cppcheck libraries option (`#323 `__) * adding ament_cppcheck libraries option * pass libraries option via CMake Co-authored-by: William Wedler -* Contributors: Audrow Nash, Chris Lalancette, Will - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ignore NOLINT comments with categories that come from clang-tidy (`#339 `__) -* Update forthcoming version in changelogs -* Reapply patches Reapply parts of 232428752251de61e84ef013bcd643e35eb9038d that are still relevant. -* Update cpplint version Point to the fork https://github.com/cpplint/cpplint Contains updates for modern C++ standards (e.g. C++14 and C++17). -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Dirk Thomas, Jacob Perron, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove use of distutils.version.LooseVersion. (`#346 `__) -* Update forthcoming version in changelogs -* Ignore .*/_* dirs in ament_flake8 (`#335 `__) Other ament\_* linters specifically ignore directories starting with a dot or underscore when crawling for files to lint. They also do so implicitly, so this change mimics that same pattern so that the behavior is consistent. -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Ignore flake8-blind-except B902 (`#292 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/ (`#83 `__) -* Remove ament_export_include_directories and ament_export_libraries (`#81 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Print warning when get_package_share_directory() does not exist (Fix `#74 `__) (`#77 `__) -* Fail lookups on invalid resource names (`#69 `__) -* Add get_package_share_path method (`#73 `__) -* Contributors: David V. Lu, rob-clarke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. -* Contributors: Abrar Rahman Protyasha, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Fix typo in ament_lint_common/package.xml (`#336 `__) -* Contributors: Audrow Nash, Kenji Miyake - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set forthcoming for previous version -* Add support for appending to environment variables (`#130 `__) This works largely the same as 'prepend-non-duplicate', but instead puts the candidate value at the end of the target variable. -* Update maintainers to Audrow Nash (`#135 `__) -* Make python executable variable ament_package specific (`#134 `__) -* Contributors: Audrow Nash, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Remove use of distutils.version.LooseVersion. (`#346 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve documentation by clarifying the purpose of different tools (`#357 `__) -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash, Bi0T1N - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* [ament_uncrustify] Fix file exclusion behavior (`#334 `__) * [ament_uncrustify] Fix file exclusion behavior This PR fixes the file exclusion behavior reported in `#326 `__. Specifically, the exclusion list is matched against files/directories as the search path is traversed. Tries to maintain consistency with `#327 `__. * [ament_uncrustify] Add file exclusion tests * [ament_uncrustify] Remove erroneous pytest marker -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* [ament_uncrustify] Add ament_lint tests (`#338 `__) * Add ``ament_lint`` tests on ``ament_uncrustify`` * Address linter warnings in ``ament_uncrustify`` -* Contributors: Abrar Rahman Protyasha, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update forthcoming version in changelogs -* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`builtin_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_calibration_parsers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Tests depend on rcpputils (`#236 `__) -* Remove YAML_CPP_DLL define (`#231 `__) -* Export a modern CMake target instead of variables and install includes to include/${PROJECT_NAME} (`#218 `__) -* Update maintainers (`#173 `__) -* Contributors: Akash, Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_info_manager `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Export a modern CMake target instead of variables and install includes to include/${PROJECT_NAME} (`#218 `__) -* Update maintainers (`#173 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`class_loader `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/ (`#191 `__) -* Fix include order for cpplint (`#192 `__) -* Update maintainers to Geoffrey Biggs and Michael Carroll (`#190 `__) -* Fix spelling mistake (`#184 `__) -* Contributors: Audrow Nash, David V. Lu!!, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`common_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Fixing deprecated subscriber callback warnings (`#532 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Add how to fix the most vexing parse problem (`#541 `__) * use uniform initialization -* Fixing deprecated subscriber callback warnings (`#532 `__) -* Update talker_loaned_message.cpp (`#518 `__) -* Revert "Use sizeof(char) in place for sizeof(void) (`#515 `__)" (`#516 `__) -* change how serialized message works with subscription (`#497 `__) -* Use sizeof(char) in place for sizeof(void) (`#515 `__) -* Fix small print issue in allocator tutorial. (`#509 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Michel Hidalgo, Tomoya Fujita, William Woodall, Zongbao Feng - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp_native `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Fix typo in demo_nodes_cpp_native package description (`#536 `__) -* Contributors: Audrow Nash, Víctor Mayoral Vilches - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanups in demo_nodes_py. (`#555 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Fixed typo executor -> executors (`#542 `__) -* Update python nodes SIGINT handling (`#539 `__) -* Contributors: Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, ori155 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`diagnostic_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`domain_coordinator `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Michel Hidalgo (`#13 `__) -* Refactor domain_coordinator API to use a context manager (`#12 `__) -* Contributors: Audrow Nash, Timo Röhling - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_map_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_robot_bringup `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_sensors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`example_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Mabel Zhang (`#15 `__) -* Add changelog (`#14 `__) -* Contributors: Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_async_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Add example of how to prune old requests in client API (`#322 `__) -* Contributors: Aditya Pande, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_cbg_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve scheduling configuration of examples_rclcpp_cbg_executor package (`#331 `__) -* Added jitter measurement to examples_rclcpp_cbg_executor. (`#328 `__) -* Fix deprecated subscriber callbacks (`#323 `__) -* Remove use of get_callback_groups(). (`#320 `__) -* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Ralph Lange - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Add example of how to prune old requests in client API (`#322 `__) -* Contributors: Aditya Pande, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add an example about how to use wait_for_all_acked (`#316 `__) -* Updated maintainers (`#329 `__) -* Add try&catch statement to unique network flow publisher example (`#313 `__) -* Add type adaption example (`#300 `__) -* Contributors: Aditya Pande, Audrow Nash, Barry Xu, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use ``const&`` signature for read-only sub callbacks (`#337 `__) -* Updated maintainers (`#329 `__) -* Fix deprecated subscriber callbacks (`#323 `__) -* Add wait set examples (`#315 `__) -* Add type adaption example (`#300 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, carlossvg - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_timer `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_multithreaded_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#329 `__) -* Fix deprecated subscriber callbacks (`#323 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_wait_set `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add wait set examples (`#315 `__) -* Contributors: carlossvg - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_executors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Update python nodes sigint/sigterm handling (`#330 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_guard_conditions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) * Updated maintainers * Removed author -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_pointcloud_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Alejandro Hernandez Cordero and Chris Lalancette (`#481 `__) -* Use underscores instead of dashes in setup.cfg. (`#403 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`fastrtps_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Shane Loretz (`#83 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`google_benchmark_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add git buildtool dependency. -* Use git hash for google_benchmark_vendor (`#20 `__) -* Update to google benchmark version 1.6.1 (`#19 `__) -* Update maintainers to Audrow Nash (`#18 `__) -* Update google_benchmark to v1.5.3 (`#16 `__) 1. Change google_benchmark version from v1.5.2 to v1.5.3. Because v1.5.2 can not build with GCC 11 2. Removed shrink-tz-offset-size.patch because of this patch was merged in google-benchmark repo. -* Add changelog (`#15 `__) -* Shrink the size of the tz_offset variable. (`#13 `__) -* Update the patching to work on Windows without admin. (`#11 `__) -* Always preserve source permissions in vendor packages. (`#12 `__) -* Update package maintainers. (`#10 `__) -* Upgrade google benchmark from v1.5.1 to v1.5.2 to include QNX patch. (`#9 `__) -* Set the SOVERSION on benchmark libraries. (`#8 `__) -* Set minimum criteria for system package. (`#3 `__) -* Work around warnings building Google Benchmark w/Clang. (`#2 `__) -* Initial google_benchmark_vendor package. (`#1 `__) -* Initial commit. -* Contributors: Ahmed Sobhy, Audrow Nash, Chris Lalancette, Homalozoa X, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, Shane Loretz, Steven! Ragnarök - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#548 `__) -* Fix include order and relative paths for cpplint (`#551 `__) -* Reduce the number of OpenCV libraries image_tools links against. (`#549 `__) -* Adds copy constructor and assignment operator to ROSCvMatContainer (`#546 `__) -* Fixes for uncrustify 0.72 (`#545 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Fixing deprecated subscriber callback warnings (`#532 `__) -* ambigulity: unknown type name 'nullptr_t' (`#528 `__) -* Add type masquerading demos (`#482 `__) -* Add support for visualizing yuv422 (`#499 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Gonzo, Jacob Perron, Shane Loretz, William Woodall, joshua-qnx, xwnb - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Image transport publisher crash fixes (`#235 `__) -* Simple IT plugins shutdown (`#225 `__) -* Remove PLUGINLIB__DISABLE_BOOST_FUNCTIONS definition. (`#226 `__) -* Fix include order for cpplint (`#221 `__) Relates to https://github.com/ament/ament_lint/pull/324 -* Export a modern CMake target instead of variables and install includes to include/${PROJECT_NAME} (`#218 `__) -* Fix SimpleSubscriberPlugin (`#195 `__) -* Make sure to mark overridden methods as 'override'. (`#192 `__) -* Expose subscription options (`#186 `__) -* fix mistyping 'cammera_publisher.hpp -> camera_publisher.hpp' (`#177 `__) -* Update maintainers (`#173 `__) -* make CameraPublisher::getNumSubscribers() work (`#163 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Hye-Jong KIM, Ivan Santiago Paunovic, Jacob Perron, Michael Ferguson, RoboTech Vision, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`interactive_markers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Do not publish if context is invalid during shutdown (`#89 `__) -* Install includes to include/ and misc CMake fixes (`#85 `__) -* Fix deprecation warning introduced after client API update (`#83 `__) -* Fix deprecated sub callback warnings (`#84 `__) -* Include tf2_geometry_msgs.hpp instead of the h file. (`#82 `__) -* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`intra_process_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add opencv_imgproc dependency for cv::putText (`#554 `__) -* Install includes to include/${PROJECT_NAME} (`#548 `__) -* Fix include order and relative paths for cpplint (`#551 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Fixing deprecated subscriber callback warnings (`#532 `__) -* Revert "Add type masquerading demos (`#482 `__)" (`#520 `__) -* Add type masquerading demos (`#482 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Jacob Perron, Shane Loretz, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`kdl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Depend on orocos-kdl vendor packages (`#58 `__) -* Install includes to include/ and misc CMake fixes (`#61 `__) -* Update to uncrustify 0.72 (`#60 `__) -* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`laser_geometry `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} (`#86 `__) -* Explicit cast to double to prevent loss of precision -* Fix Duration casting issue leading to no undistortion -* Fix building on running on Windows Debug (`#82 `__) -* Update python code and tests for ros2 (`#80 `__) -* Contributors: Chris Lalancette, Jonathan Binney, Marco Lampacrescia, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Sandbox environment in tests to fix repeated job failures (`#609 `__) -* Start Python faster in test_execute_processs_shutdown to avoid flakey failures (`#608 `__) -* Fix warnings from importlib_metdata on Python 3.10. (`#606 `__) -* Add boolean substitutions (`#598 `__) -* Support scoping environment variables (`#601 `__) -* Fix awaiting shutdown in launch context (`#603 `__) -* Fix parse respawn var (`#569 `__) -* Make the logged command pretty in ExecuteLocal (`#594 `__) -* 'output' is expanded as a substitution in XML/YAML files (`#577 `__) -* Skip warning test if warning already happend (`#585 `__) -* Use asyncio.wait with timeout rather than sleep (`#576 `__) -* Make test_parser compatible with Python older than 3.8 (`#575 `__) -* Propagate exceptions of completed actions to launch service main loop (`#566 `__) -* Warn when loading launch extensions fails (`#572 `__) -* Add in two fixes for Jammy (`#571 `__) -* Evaluate math symbols and functions in python expression (`#557 `__) -* Document TimerAction params (`#558 `__) -* Improve launch arguments introspection (`#556 `__) -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* Updated maintainers (`#555 `__) -* First prototype of native pytest plugin for launch based tests (`#528 `__) -* Allow for raw path specification in IncludeLaunchDescription (`#544 `__) -* Adding Executable description class (`#454 `__) -* event handlers: Allow to match the target action with a callable and not only with an object instance (`#540 `__) -* Add AppendEnvironmentVariable action (`#543 `__) -* Document EnvironmentVariable substitution resolution context caveat (`#541 `__) -* Feature clear launch configs (`#515 `__) -* Add examples to ExecuteProcess docs (`#525 `__) -* Fix ``DeclareLaunchArgument`` xml parsing and constructor (`#529 `__) -* Fix pytest run on Windows (`#526 `__) -* Improving docs (`#523 `__) -* Add filtering mechanism for executable prefix application (`#522 `__) -* Make each parser extension provide a set of file extensions (`#516 `__) -* Add missing exec dependency on PyYAML (`#493 `__) -* Refactor TimerAction to allow RosTimer to extend (`#512 `__) -* Improve (Not)Equals condition type hinting (`#510 `__) -* Contributors: Aditya Pande, Audrow Nash, Cameron Miller, Chris Lalancette, Christophe Bedard, David V. Lu!!, Derek Chopp, HMellor, Immanuel Martini, Ivan Santiago Paunovic, Jacob Perron, Kenji Miyake, Khush Jain, Kosuke Takeuchi, Rebecca Butler, Scott K Logan, Shane Loretz, roger-strain, tumtom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* [launch_pytest] Modify how wait_for_output()/wait_for_stderr() work, add assert\_*() alternatives (`#553 `__) -* Updated maintainers (`#555 `__) -* * [launch_pytest] Fix issue when colcon --retest-until-fail flag is used (`#552 `__) -* First prototype of native pytest plugin for launch based tests (`#528 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix importlib_metadata warning on Python 3.10. (`#307 `__) -* Use correct namespace when evaluating parameter files for composable nodes (`#303 `__) -* Handle empty strings when evaluating parameters (`#300 `__) -* Add parameter substitution (`#297 `__) -* fix bug in warning when an entry point fails to load (`#243 `__) -* More Helpful Error Messages (`#275 `__) -* Update maintainers in setup.py (`#287 `__) -* Set parameters from file for composable nodes (`#281 `__) -* Update package maintainers (`#284 `__) -* Update node name matcher (`#282 `__) -* Support both parameter file configurations for composable nodes (`#259 `__) -* Handle substitutions in RosTimer (`#264 `__) -* Add SetParametersFromFile action (`#260 `__) -* Properly support ros_args attribute through launch frontends (`#253 `__) -* Add 'push_ros_namespace' alias to 'push-ros-namespace' (`#250 `__) -* Add ros_arguments option to Node action (`#249 `__) -* Refactor RosTimer to extend TimerAction (`#248 `__) -* ROS Timer Action (`#244 `__) -* Support container in frontend (`#235 `__) -* Fix a small typo in a comment (`#237 `__) -* Better document parameter handling in Node (`#234 `__) -* Make 'ros2 launch' work again. (`launch #201 `__) -* Added LaunchLogger class (`launch #145 `__) -* Changed logger.warn (deprecated) to logger.warning. (`launch #199 `__) -* Added Plumb rclpy.init context to get_default_launch_description. (`launch #193 `__) -* Added normalize_parameters and evaluate_paramters. (`launch #192 `__) -* Added normalize_remap_rule and types. (`launch #173 `__) -* Renamed transitions to match changes in ``lifecycle_msgs`` (`launch #153 `__) -* Added support for passing parameters as a dictionary to a Node (`launch #138 `__) -* Made various fixes and added tests for remappings passed to Node actions (`launch #137 `__) -* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Christophe Bedard, David V. Lu!!, Felix Divo, Jacob Perron, Kenji Miyake, Michel Hidalgo, Rebecca Butler, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed the deprecated ``ready_fn`` feature (`#589 `__) -* Added case for instances of ExecuteLocal in resolveProcess function (`#587 `__) -* Add compatitibility with pytest 7 (`#592 `__) -* Renamed three files from example_processes (`#573 `__) -* Fix launch_testing README.md proc keyword to process. (`#554 `__) (`#560 `__) -* Declare frontend group dependency & use explicit dependencies in launch_testing (`#520 `__) -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* Updated maintainers (`#555 `__) -* First prototype of native pytest plugin for launch based tests (`#528 `__) -* Adding Executable description class (`#454 `__) -* Add a "hello world" style example (`#532 `__) -* Contributors: Aditya Pande, Audrow Nash, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Khush Jain, Matt Lanting, Shane Loretz, William Woodall, roger-strain - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [launch_testing_ament_cmake] Add test label (`#584 `__) -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* Updated maintainers (`#555 `__) -* Contributors: Aditya Pande, Audrow Nash, Keisuke Shima - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_examples `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Readded WaitForTopics utility (`#333 `__) -* Final batch of examples (`#327 `__) -* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) -* Updated maintainers (`#329 `__) -* Reverted WaitForTopics utility usage (`#326 `__) -* Moved examples (`#324 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ``hz`` param to ``talker.py`` to fix wait_for_topic_launch_test (`#309 `__) -* Revert WaitForTopics (`#288 `__) -* Update maintainers in setup.py (`#287 `__) -* Move pytest entrypoints to own module (`#278 `__) -* Update package maintainers (`#284 `__) -* Check that future is done, and always call rclpy.shutdown (`#273 `__) -* Revert "launch testing : Wait for topics to publish (`#274 `__)" (`#276 `__) -* Add WaitForTopics utility for waiting on publishers (`#274 `__) -* Remove unused code, Future.result() already raises (`#270 `__) -* Add timeout to wait for service response in example (`#271 `__) -* Add examples (`#263 `__) -* Contributors: Aditya Pande, Audrow Nash, Jacob Perron, Jorge Perez, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_xml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix sphinx directive to cross-ref Launch method (`#605 `__) -* Add boolean substitutions (`#598 `__) -* Support scoping environment variables (`#601 `__) -* 'output' is expanded as a substitution in XML/YAML files (`#577 `__) -* Declare frontend group dependency & use explicit dependencies in launch_testing (`#520 `__) -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* Updated maintainers (`#555 `__) -* Add AppendEnvironmentVariable action (`#543 `__) -* Feature clear launch configs (`#515 `__) -* Fix ``DeclareLaunchArgument`` xml parsing and constructor (`#529 `__) -* Add 'launch' to sets of launch file extensions (`#518 `__) -* Make each parser extension provide a set of file extensions (`#516 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, Christophe Bedard, Derek Chopp, Ivan Santiago Paunovic, Jacob Perron, Kenji Miyake, Khush Jain - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_yaml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix sphinx directive to cross-ref Launch method (`#605 `__) -* Add boolean substitutions (`#598 `__) -* Support scoping environment variables (`#601 `__) -* 'output' is expanded as a substitution in XML/YAML files (`#577 `__) -* Declare frontend group dependency & use explicit dependencies in launch_testing (`#520 `__) -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* Updated maintainers (`#555 `__) -* Add AppendEnvironmentVariable action (`#543 `__) -* Feature clear launch configs (`#515 `__) -* Add 'launch' to sets of launch file extensions (`#518 `__) -* Make each parser extension provide a set of file extensions (`#516 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, Christophe Bedard, Derek Chopp, Jacob Perron, Kenji Miyake, Khush Jain - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libcurl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to curl 7.81. (`#74 `__) -* Update maintainers (`#66 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libstatistics_collector `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump pascalgn/automerge-action from 0.14.3 to 0.15.2 -* Bump ros-tooling/setup-ros from 0.2.2 to 0.3.0 -* Bump actions/upload-artifact from 2.3.1 to 3 -* Bump actions/upload-artifact from 2.2.4 to 2.3.1 -* Bump actions/checkout from 2 to 3 -* Bump ros-tooling/setup-ros from 0.2.1 to 0.2.2 (`#123 `__) -* Install includes to include/${PROJECT_NAME} (`#122 `__) -* Bump codecov/codecov-action from 2.0.3 to 2.1.0 -* Bump pascalgn/automerge-action from 0.14.2 to 0.14.3 -* Bump codecov/codecov-action from 2.0.2 to 2.0.3 -* Use rosidl_get_typesupport_target() (`#116 `__) -* Bump codecov/codecov-action from 2.0.1 to 2.0.2 -* Bump codecov/codecov-action from 1.5.2 to 2.0.1 -* Bump actions/upload-artifact from 1 to 2.2.4 -* Bump codecov/codecov-action from 1.5.1 to 1.5.2 -* Bump codecov/codecov-action from 1.3.1 to 1.5.1 -* Bump ros-tooling/setup-ros from 0.2.0 to 0.2.1 -* Bump pascalgn/automerge-action from 0.14.1 to 0.14.2 -* Bump ros-tooling/setup-ros from 0.1 to 0.2.0 -* Bump pascalgn/automerge-action from 0.13.1 to 0.14.1 -* Fix autoapprove -* Package.json explicitly owned by emerson to minimize notifications -* Bump hmarr/auto-approve-action from v2.0.0 to v2.1.0 -* Bump codecov/codecov-action from v1.2.1 to v1.3.1 -* Contributors: Chris Lalancette, Emerson Knapp, Shane Loretz, dependabot[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libyaml_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add a buildtool dependency on git. (`#48 `__) -* Install headers to include/${PROJECT_NAME} (`#46 `__) -* Merge pull request `#43 `__ from ros2/update-maintainers -* Update maintainers to Audrow Nash -* Contributors: Audrow Nash, Shane Loretz, Steven! Ragnarök - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make lifecycle demo automatically exit when done (`#558 `__) -* Use default on_activate()/on_deactivate() implemenetation of Node (`#552 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Fix use of future in lifecycle demo (`#534 `__) -* Fixing deprecated subscriber callback warnings (`#532 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Christophe Bedard, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Create changelog for lifecycle_py -* Add rclpy lifecycle demo (`#547 `__) -* Contributors: Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`logging_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Use rosidl_get_typesupport_target() (`#529 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`message_filters `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use RCL_ROS_TIME for message_traits::TimeStamp (`#72 `__) -* Install includes to include/${PROJECT_NAME} (`#71 `__) -* Update maintainers (`#67 `__) -* Suppress rclcpp deprecation warnings in unit tests (`#62 `__) -* Add missing overrides to subscriber.h (`#60 `__) -* Add lifecycle node support (`#59 `__) -* Correct package.xml and CMakeLists.txt (`#58 `__) -* Expose Subscription Options - V2 (`#56 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Hunter L. Allen, Kenji Brameld, Michel Hidalgo, Rebecca Butler, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mimick_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* support pi zero (`#24 `__) -* Update maintainers to Geoffrey Biggs (`#23 `__) -* Update to latest commit for Apple M1 support (`#20 `__) -* Contributors: Audrow Nash, Brett Downing, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`nav_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_control `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix include order and relative paths for cpplint (`#551 `__) -* Remove the malloc_hook from the pendulum_demo. (`#544 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Fix documentation for pendulum_control. (`#537 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pluginlib `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} and remove ament_target_dependencies calls (`#226 `__) -* Require (`#225 `__) -* Move LibraryLoadExceptions down a level for more accurate error messages (`#221 `__) -* Update maintainers to Chris Lalancette (`#223 `__) -* extend termination condition to avoid infinite loop if package.xml is not found (`#220 `__) -* Remove deprecated headers. (`#217 `__) -* Contributors: Alberto Soragna, Audrow Nash, Chris Lalancette, David V. Lu!!, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pybind11_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use sha256 hash instead of tag (`#12 `__) -* Install headers to include/${PROJECT_NAME} (`#11 `__) -* Update pybind11 to 2.7.1. (`#10 `__) This is the version that is shipped in Ubuntu 22.04. -* Contributors: Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* require Python 3.6 as we use format strings in various places (`#10 `__) -* Document all variables set by this module (`#5 `__) -* Add changelog (`#4 `__) -* Contributors: Ivan Santiago Paunovic, Shane Loretz, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include${PROJECT_NAME} (`#259 `__) -* Export targets instead of old-style CMake variables (`#257 `__) -* FindPython3 explicitly instead of FindPythonInterp implicitly (`#254 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#548 `__) -* Fix include order and relative paths for cpplint (`#551 `__) -* Fixes for uncrustify 0.72 (`#545 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Fixing deprecated subscriber callback warnings (`#532 `__) -* Initialize message correctly (`#522 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Update python nodes SIGINT handling (`#539 `__) -* Contributors: Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add content-filtered-topic interfaces (`#894 `__) -* Add additional null check for timer argument (`#973 `__) -* Allow forward slashes within a parameter name rule in argument parsing (`#860 `__) -* Suppress false positive from clang-tidy (`#951 `__) -* Fix missing terminating \0 in rcl_context_impl_t.argv (`#969 `__) -* test_publisher_wait_all_ack depends on rcpputils (`#968 `__) -* Micro-optimizations in rcl (`#965 `__) -* If timer canceled, rcl_timer_get_time_until_next_call returns TIMER_CANCELED (`#963 `__) -* Add Events Executor (`#839 `__) -* Remove fastrtps customization on test_events (`#960 `__) -* Add client/service QoS getters (`#941 `__) -* introduce ROS_DISABLE_LOAN_MSG to disable can_loan_messages. (`#949 `__) -* Install includes it include/${PROJECT_NAME} (`#959 `__) -* Make rcl_difference_times args const (`#955 `__) -* Update inject_on_return test skipping logic (`#953 `__) -* Fix jump callbacks being called when zero time jump thresholds used (`#948 `__) -* Only change the default logger level if default_logger_level is set (`#943 `__) -* Add Library for wait_for_entity_helpers to deduplicate compilation (`#942 `__) -* Increase Windows timeout 15 -> 25 ms (`#940 `__) -* test should check specified number of entities. (`#935 `__) -* Fix up documentation build for rcl when using rosdoc2 (`#932 `__) -* Include rmw_event_t instead of forward declaring it (`#933 `__) -* Add rcl_publisher_wait_for_all_acked support. (`#913 `__) -* Add tracing instrumentation for rcl_take. (`#930 `__) -* Fix #include in C++ typesupport example in rcl_subscription_init docblock. (`#927 `__) -* Update includes after rcutils/get_env.h deprecation. (`#917 `__) -* Use proper rcl_logging return value type and compare to constant. (`#916 `__) -* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Haowei Wen, Ivan Santiago Paunovic, Jafar Abdi, Michel Hidalgo, Miguel Company, NoyZuberi, Scott K Logan, Shane Loretz, Tomoya Fujita, William Woodall, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add Events Executor (`#839 `__) -* Install includes it include/${PROJECT_NAME} (`#959 `__) -* Fix up documentation build for rcl_action when using rosdoc2 (`#937 `__) -* Fix expired goals capacity of action server (`#931 `__) -* Wait for action server in rcl_action comm tests. (`#919 `__) -* Contributors: Michel Hidalgo, Shane Loretz, iRobot ROS, spiralray - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes it include/${PROJECT_NAME} (`#959 `__) -* [rcl_lifecycle] Do not share transition event message between nodes (`#956 `__) -* Update maintainers to Ivan Paunovic and William Woodall (`#952 `__) -* Fix up documentation build for rcl_lifecycle when using rosdoc2 (`#938 `__) -* Rename variable to fix name shadowing warning (`#929 `__) -* Contributors: Alberto Soragna, Audrow Nash, Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#85 `__) -* Fix include order for cpplint (`#84 `__) Relates to https://github.com/ament/ament_lint/pull/324 -* Update maintainers to Chris Lalancette (`#83 `__) -* Fix renamed ``rcpputils`` header (`#81 `__) -* Add Doxyfile to rcl_logging_interface package (`#80 `__) -* Update includes after rcutils/get_env.h deprecation (`#75 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Christophe Bedard, Jacob Perron, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_noop `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#83 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_spdlog `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix include order for cpplint (`#84 `__) Relates to https://github.com/ament/ament_lint/pull/324 -* Update maintainers to Chris Lalancette (`#83 `__) -* Fix renamed ``rcpputils`` header (`#81 `__) -* Update includes after rcutils/get_env.h deprecation (`#75 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Christophe Bedard, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_yaml_param_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes it include/${PROJECT_NAME} (`#959 `__) -* Update maintainers to Ivan Paunovic and William Woodall (`#952 `__) -* Tweak rcl_yaml_param_parser documentation (`#939 `__) -* Contributors: Audrow Nash, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* remove DEFINE_CONTENT_FILTER cmake option (`#1914 `__) -* remove things that were deprecated during galactic (`#1913 `__) -* add take_data_by_entity_id API to waitable (`#1892 `__) -* add content-filtered-topic interfaces (`#1561 `__) -* [NodeParameters] Set name in param info pre-check (`#1908 `__) -* Add test-dep ament_cmake_google_benchmark (`#1904 `__) -* Add publish by loaned message in GenericPublisher (`#1856 `__) -* Add missing ament dependency on rcl_interfaces (`#1903 `__) -* Update data callback tests to account for all published samples (`#1900 `__) -* Increase timeout for acknowledgments to account for slower Connext settings (`#1901 `__) -* clang-tidy: explicit constructors (`#1782 `__) -* Add client/service QoS getters (`#1784 `__) -* Fix a bunch more rosdoc2 issues in rclcpp. (`#1897 `__) -* time_until_trigger returns max time if timer is cancelled (`#1893 `__) -* Micro-optimizations in rclcpp (`#1896 `__) -* spin_all with a zero timeout. (`#1878 `__) -* Add RMW listener APIs (`#1579 `__) -* Remove fastrtps customization on tests (`#1887 `__) -* Install headers to include/${PROJECT_NAME} (`#1888 `__) -* Use ament_generate_version_header (`#1886 `__) -* use universal reference to support rvalue. (`#1883 `__) -* fix one subscription can wait_for_message twice (`#1870 `__) -* Add return value version of get_parameter_or (`#1813 `__) -* Cleanup time source object lifetimes (`#1867 `__) -* add is_spinning() method to executor base class -* Cleanup the TypeAdapt tests (`#1858 `__) -* Cleanup includes (`#1857 `__) -* Fix include order and relative paths for cpplint (`#1859 `__) -* Rename stringstream in macros to a more unique name (`#1862 `__) -* Add non transform capabilities for intra-process (`#1849 `__) -* Fix rclcpp documentation build (`#1779 `__) -* Use UninitializedStaticallyTypedParameterException (`#1689 `__) -* Add wait_for_all_acked support (`#1662 `__) -* Add tests for function templates of declare_parameter (`#1747 `__) -* Fixes for uncrustify 0.72 (`#1844 `__) -* use private member to keep the all reference underneath. (`#1845 `__) -* Make node base sharable (`#1832 `__) -* Add Clock::sleep_for() (`#1828 `__) -* Synchronize rcl and std::chrono steady clocks in Clock::sleep_until (`#1830 `__) -* Use rclcpp::guard_condition (`#1612 `__) -* Call CMake function to generate version header (`#1805 `__) -* Use parantheses around logging macro parameter (`#1820 `__) -* Remove author by request (`#1818 `__) -* Update maintainers (`#1817 `__) -* min_forward & min_backward thresholds must not be disabled (`#1815 `__) -* Re-add Clock::sleep_until (`#1814 `__) -* Fix lifetime of context so it remains alive while its dependent node handles are still in use (`#1754 `__) -* Add the interface for pre-shutdown callback (`#1714 `__) -* Take message ownership from moved LoanedMessage (`#1808 `__) -* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) -* Wait for publisher and subscription to match (`#1777 `__) -* Fix unused QoS profile for clock subscription and make ClockQoS the default (`#1801 `__) -* Fix dangerous std::bind capture in TimeSource implementation. (`#1768 `__) -* Fix dangerous std::bind capture in ParameterEventHandler implementation. (`#1770 `__) -* Handle sigterm, in the same way sigint is being handled. (`#1771 `__) -* rclcpp::Node copy constructor: make copy of node_waitables\_ member. (`#1799 `__) -* Extend NodeGraph to match what rcl provides. (`#1484 `__) -* Context::sleep_for(): replace recursion with do-while to avoid potential stack-overflow. (`#1765 `__) -* extend_sub_namespace(): Verify string::empty() before calling string::front(). (`#1764 `__) -* Deprecate the ``void shared_ptr`` subscription callback signatures. (`#1713 `__) -* Remove can_be_nullptr assignment check for QNX case. (`#1752 `__) -* Update client API to be able to remove pending requests. (`#1734 `__) -* Fix: Allow to add a node while spinning in the StaticSingleThreadedExecutor. (`#1690 `__) -* Add tracing instrumentation for executor and message taking. (`#1738 `__) -* Fix: Reset timer trigger time before execute in StaticSingleThreadedExecutor. (`#1739 `__) -* Use FindPython3 and make python3 dependency explicit. (`#1745 `__) -* Use rosidl_get_typesupport_target(). (`#1729 `__) -* Fix returning invalid namespace if sub_namespace is empty. (`#1658 `__) -* Add free function to wait for a subscription message. (`#1705 `__) -* Use rcpputils/scope_exit.hpp and remove rclcpp/scope_exit.hpp. (`#1727 `__) -* Remove unsafe get_callback_groups API. Callers should change to using for_each_callback_group(), or store the callback groups they need internally. -* Add in callback_groups_for_each. The main reason to add this method in is to make accesses to the callback_groups\_ vector thread-safe. By having a callback_groups_for_each that accepts a std::function, we can just have the callers give us the callback they are interested in, and we can take care of the locking. The rest of this fairly large PR is cleaning up all of the places that use get_callback_groups() to instead use callback_groups_for_each(). -* Use a different mechanism to avoid timers being scheduled multiple times by the MultiThreadedExecutor (`#1692 `__) -* Fix windows CI (`#1726 `__) Fix bug in AnyServiceCallback introduced in `#1709 `__. -* Support to defer to send a response in services. (`#1709 `__) Signed-off-by: Ivan Santiago Paunovic -* Fix documentation bug. (`#1719 `__) Signed-off-by: William Woodall -* Removed left over ``is_initialized()`` implementation (`#1711 `__) Leftover from https://github.com/ros2/rclcpp/pull/1622 -* Fixed declare parameter methods for int and float vectors (`#1696 `__) -* Cleaned up implementation of the intra-process manager (`#1695 `__) -* Added the node name to an executor ``runtime_error`` (`#1686 `__) -* Fixed a typo "Attack" -> "Attach" (`#1687 `__) -* Removed use of std::allocator<>::rebind (`#1678 `__) rebind is deprecated in c++17 and removed in c++20 -* Allow declare uninitialized parameters (`#1673 `__) -* Fix syntax issue with gcc (`#1674 `__) -* [service] Don't use a weak_ptr to avoid leaking (`#1668 `__) -* Fix doc typo (`#1663 `__) -* [rclcpp] Type Adaptation feature (`#1557 `__) -* Do not attempt to use void allocators for memory allocation. (`#1657 `__) -* Keep custom allocator in publisher and subscription options alive. (`#1647 `__) -* Fix get_publishers_subscriptions_info_by_topic test in test_node.cpp (`#1648 `__) -* Use OnShutdown callback handle instead of OnShutdown callback (`#1639 `__) -* use dynamic_pointer_cast to detect allocator mismatch in intra process manager (`#1643 `__) -* Contributors: Abrar Rahman Protyasha, Ahmed Sobhy, Alberto Soragna, Andrea Sorbini, Audrow Nash, Barry Xu, Bi0T1N, Chen Lihui, Chris Lalancette, Christophe Bedard, Doug Smith, Emerson Knapp, Gaël Écorchard, Geoffrey Biggs, Gonzo, Grey, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Karsten Knese, Kenji Miyake, M. Hofstätter, M. Mostafa Farzan, Mauro Passerino, Michel Hidalgo, Miguel Company, Nikolai Morin, Petter Nilsson, Scott K Logan, Shane Loretz, Steve Macenski, Tomoya Fujita, William Woodall, Yong-Hao Zou, iRobot ROS, livanov93, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* remove things that were deprecated during galactic (`#1913 `__) -* add take_data_by_entity_id API to waitable (`#1892 `__) -* Fix rosdoc2 issues (`#1897 `__) -* Add RMW listener APIs (`#1579 `__) -* Install headers to include/${PROJECT_NAME} (`#1888 `__) -* Fix include order and relative paths for cpplint (`#1859 `__) -* Fixes for uncrustify 0.72 (`#1844 `__) -* Use rclcpp::guard_condition (`#1612 `__) -* Remove author by request (`#1818 `__) -* Update maintainers (`#1817 `__) -* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) -* Deprecate the ``void shared_ptr`` subscription callback signatures (`#1713 `__) -* Use rcpputils/scope_exit.hpp and remove rclcpp/scope_exit.hpp. (`#1727 `__) -* Fixed occasionally missing goal result caused by race condition (`#1677 `__) -* Bump the benchmark timeout for benchmark_action_client (`#1671 `__) -* Returns CancelResponse::REJECT while goal handle failed to transit to CANCELING state (`#1641 `__) -* Fix action server deadlock issue that caused by other mutexes locked in CancelCallback (`#1635 `__) -* Contributors: Abrar Rahman Protyasha, Alberto Soragna, Chris Lalancette, Christophe Bedard, Jacob Perron, Kaven Yau, Shane Loretz, Tomoya Fujita, William Woodall, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_components `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Select executor in node registration (`#1898 `__) -* Fix rosdoc2 issues in rclcpp (`#1897 `__) -* Fix bugprone-exception-escape in node_main.cpp.in (`#1895 `__) -* small improvements to node_main.cpp.in -* Install headers to include/${PROJECT_NAME} (`#1888 `__) -* Use spin() in component_manager_isolated.hpp (`#1881 `__) -* add use_global_arguments for node options of component nodes (`#1776 `__) -* Add rclcpp_components::component (`#1855 `__) -* Add parameter to configure number of thread (`#1708 `__) -* remove RCLCPP_COMPONENTS_PUBLIC in class ComponentManagerIsolated (`#1843 `__) -* create component_container_isolated (`#1781 `__) -* Remove author by request (`#1818 `__) -* Update maintainers (`#1817 `__) -* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) -* Update client API to be able to remove pending requests. (`#1734 `__) -* Deprecate method names that use CamelCase in rclcpp_components. (`#1716 `__) -* Added a hook to generate node options in ComponentManager (`#1702 `__) -* Contributors: Alberto Soragna, Chris Lalancette, Daisuke Nishimatsu, Hirokazu Ishida, Ivan Santiago Paunovic, Jacob Perron, Rebecca Butler, Shane Loretz, gezp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* remove things that were deprecated during galactic (`#1913 `__) -* Fix rosdoc2 issues (`#1897 `__) -* Install headers to include/${PROJECT_NAME} (`#1888 `__) -* LifecycleNode::on_deactivate deactivate all managed entities. (`#1885 `__) -* Automatically transition lifecycle entities when node transitions (`#1863 `__) -* Remove author by request (`#1818 `__) -* Update maintainers (`#1817 `__) -* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) -* Update forward declarations of ``rcl_lifecycle`` types (`#1788 `__) -* Deprecate the ``void shared_ptr`` subscription callback signatures (`#1713 `__) -* Update client API to be able to remove pending requests. (`#1734 `__) -* Change log level for lifecycle_publisher. (`#1715 `__) -* Fix: RCLCPP_PUBLIC -> RCLCPP_LIFECYCLE_PUBLIC (`#1732 `__) -* Use rcpputils/scope_exit.hpp and remove rclcpp/scope_exit.hpp (`#1727 `__) -* Remove unsafe get_callback_groups API. Callers should change to using for_each_callback_group(), or store the callback groups they need internally. -* Add in callback_groups_for_each. The main reason to add this method in is to make accesses to the callback_groups\_ vector thread-safe. By having a callback_groups_for_each that accepts a std::function, we can just have the callers give us the callback they are interested in, and we can take care of the locking. The rest of this fairly large PR is cleaning up all of the places that use get_callback_groups() to instead use callback_groups_for_each(). -* Fix destruction order in lifecycle benchmark (`#1675 `__) -* [rclcpp] Type Adaptation feature (`#1557 `__) -* Contributors: Abrar Rahman Protyasha, Alberto Soragna, Audrow Nash, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, Tomoya Fujita, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make rclpy dependencies explicit (`#906 `__) -* Avoid exception in Node constructor when use override for 'use_sim_time' (`#896 `__) -* time_until_next_call returns max if timer is canceled. (`#910 `__) -* Properly implement action server/client handle cleanup. (`#905 `__) -* Make sure to take out contexts on Action{Client,Server}. (`#904 `__) -* Make sure to free the goal_status_array when done using it. (`#902 `__) -* Bugfix to Node.destroy_rate() result (`#901 `__) -* Remove fastrtps customization on tests (`#895 `__) -* fix typo (`#890 `__) -* Document that Future.result() may return None (`#884 `__) -* update doc release number (`#885 `__) -* Fix multi-threaded race condition in client.call_async (`#871 `__) -* Fix include order for cpplint (`#877 `__) -* Bugfix/duration to msg precision (`#876 `__) -* Update to pybind11 2.7.1 (`#874 `__) -* QoS history depth is only available with KEEP_LAST (`#869 `__) -* Implement managed nodes. (`#865 `__) -* Make rclpy.try_shutdown() behavior to follow rclpy.shutdown() more closely. (`#868 `__) -* Update TopicEndpointTypeEnum.__str_\_() method to include history kind and history depth. (`#849 `__) -* Add Clock.sleep_for() using Clock.sleep_until(). (`#864 `__) -* Add Clock.sleep_until() (`#858 `__) -* Add __enter_\_ and __exit_\_ to JumpHandle. (`#862 `__) -* Don't override rclpy._rclpy_pybind11 docs. (`#863 `__) -* Improve JumpThreshold documentation and forbid zero durations. (`#861 `__) -* Fix time.py and clock.py circular import. (`#860 `__) -* Make context.on_shutdown() allow free functions. (`#859 `__) -* Fix automatically declared parameters descriptor type. (`#853 `__) -* Shutdown asynchronously when sigint is received. (`#844 `__) -* Update maintainers. (`#845 `__) -* Add entities to callback group before making them available to the executor to avoid a race condition. (`#839 `__) -* Avoid race condition in client.call(). (`#838 `__) -* Handle sigterm. (`#830 `__) -* Use pybind11 for signal handling, and delete now unused rclpy_common, pycapsule, and handle code. (`#814 `__) -* Fix memory leak in Service::take_request() and Client::take_response(). (`#828 `__) -* Add Publisher.wait_for_all_acked(). (`#793 `__) -* Only add one done callback to a future in Executor. (`#816 `__) -* Add convert function from ParameterValue to Python builtin. (`#819 `__) -* Call Context._logging_fini() in Context.try_shutdown(). (`#800 `__) -* Lift LoggingSeverity enum as common dependency to logging and rcutils_logger modules (`#785 `__) -* Set Context.__context to None in __init_\_(). (`#812 `__) -* Remove unused function make_mock_subscription. (`#809 `__) -* Removed common.c/h (`#789 `__) -* Allow declaring uninitialized parameters (`#798 `__) -* Reject cancel request if failed to transit to CANCEL_GOAL state (`#791 `__) -* Deleted handle as it should no longer be used (`#786 `__) -* Removed some functions in common.c and replaced them in utils.cpp (`#787 `__) -* Moved exception.cpp/hpp to the _rclpy_pybind11 module (`#788 `__) -* Print 'Infinite' for infinite durations in topic endpoint info (`#722 `__) -* Break log function execution ASAP if configured severity is too high (`#776 `__) -* Convert Node and Context to use C++ Classes (`#771 `__) -* Misc action server improvements (`#774 `__) -* Misc action goal handle improvements (`#767 `__) -* Convert Guardcondition to use C++ classes (`#772 `__) -* Removed unused structs ``rclpy_client_t`` and ``rclpy_service_t`` (`#770 `__) -* Convert WaitSet to use C++ Classes (`#769 `__) -* Convert ActionServer to use C++ Classes (`#766 `__) -* Convert ActionClient to use C++ classes (`#759 `__) -* Use py::class\_ for rcl_action_goal_handle_t (`#751 `__) -* Convert Publisher and Subscription to use C++ Classes (`#756 `__) -* Rename QoS*Policy enum's to \*Policy (`#379 `__) -* Use params from node '/\*\*' from parameter YAML file (`#370 `__) -* Updated to use params from node '/\*\*' from parameter YAML file. (`#399 `__) -* Contributors: Alejandro Hernández Cordero, Anthony, Artem Shumov, Auguste Lalande, Barry Xu, Chris Lalancette, Emerson Knapp, Erki Suurjaak, Greg Balke, Ivan Santiago Paunovic, Jacob Perron, Lei Liu, Louise Poubel, Miguel Company, Shane Loretz, Tomoya Fujita, ksuszka - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcpputils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#160 `__) -* Fix include order for cpplint (`#158 `__) -* [path] Declare the default assignment operator (`#156 `__) -* Fixes for uncrustify 0.72 (`#154 `__) -* Fix the BSD license headers to use the standard one. (`#153 `__) -* Update maintainers to Chris Lalancette (`#152 `__) -* Add checked convert_to_nanoseconds() function (`#145 `__) -* Add missing sections in docs/FEATURES.md TOC (`#151 `__) -* [env] Add ``set_env_var`` function (`#150 `__) -* Add missing cstddef include (`#147 `__) -* Add accumulator test to CMakeLists.txt (`#144 `__) -* ``rcpputils::fs``: Fix doxygen parameter identifier (`#142 `__) -* Make thread safety macro C++ standards compliant (`#141 `__) -* Fix API documentation for clean ``rosdoc2`` build (`#139 `__) -* Improve ``rcppmath`` Doxygen documentation (`#138 `__) -* Improve documentation of utilities in docs/FEATURES.md (`#137 `__) -* Include ``rcppmath`` utilities in docs/FEATURES.md (`#136 `__) -* Fix ``IllegalStateException`` reference in FEATURES (`#135 `__) -* migrate rolling mean from ros2_controllers to rcppmath (`#133 `__) -* Update includes after rcutils/get_env.h deprecation (`#132 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Chris Lalancette, Christophe Bedard, Jacob Perron, Karsten Knese, Octogonapus, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update launch test for change related to enviroment variables in launch (`#354 `__) -* Remove dst_size from strlen usage (`#353 `__) -* Install headers to include\${PROJECT_NAME} (`#351 `__) -* Use static_cast instead of C-style cast (`#349 `__) -* Fixing up documentation build when using rosdoc2 (`#344 `__) -* Stop double-defining structs. (`#333 `__) -* Use FindPython3 explicitly instead of FindPythonInterp implicitly (`#345 `__) -* Fix build on Android (`#342 `__) -* Deprecate get_env.h and move content to env.{h,c} (`#340 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Shane Loretz, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`resource_retriever `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} (`#72 `__) -* Fix include order for cpplint (`#69 `__) -* Update maintainers (`#66 `__) -* Remove the deprecated retriever.h header (`#63 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add content filtered topics support. (`#302 `__) -* Add sequence numbers to rmw_message_info_t. (`#318 `__) -* Add rmw_feature_supported(). (`#318 `__) -* Add EventsExecutor (`#286 `__) -* Document that rmw_wait() SHOULD use a monotonic clock (`#316 `__) -* Install headers to include/${PROJECT_NAME} (`#317 `__) -* Update rmw_server_is_available() API documentation. (`#277 `__) -* Add client/service QoS getters. (`#314 `__) -* Fix up documentation build for rmw when using rosdoc2 (`#313 `__) -* Fix up errors in doxygen documentation (`#311 `__) -* Fix copy-paste error in API doc for rmw_get_gid_for_publisher (`#310 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#296 `__) -* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Exclude missing sample info fields when building rmw_connextddsmicro (`#79 `__) -* Update launch_testing_ros output filter prefixes for Connext6 (`#80 `__) -* Add support for user-specified content filters (`#68 `__) -* add stub for content filtered topic (`#77 `__) -* Add rmw listener apis (`#44 `__) -* Add client/service QoS getters. (`#67 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#20 `__) -* Contributors: Andrea Sorbini, Barry Xu, Chen Lihui, Ivan Santiago Paunovic, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Exclude missing sample info fields when building rmw_connextddsmicro (`#79 `__) -* Properly initialize CDR stream before using it for filtering (`#81 `__) -* Add support for user-specified content filters (`#68 `__) -* add stub for content filtered topic (`#77 `__) -* Add sequence numbers to message info structure (`#74 `__) -* Add rmw listener apis (`#44 `__) -* Fix cpplint errors (`#69 `__) -* Add client/service QoS getters. (`#67 `__) -* Update rmw_context_impl_t definition (`#65 `__) -* Use the new rmw_dds_common::get_security_files API (`#61 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#20 `__) -* Support extended signature for ``message_type_support_callbacks_t::max_serialized_size()`` from ``rosidl_typesupport_fastrtps_cpp``. (`#14 `__) -* Update includes after rcutils/get_env.h deprecation. (`#55 `__) -* Always modify UserObjectQosPolicy regardless of override policy. (`#53 `__) -* Improved conversion of time values between ROS and DDS formats. (`#43 `__) -* Allow sharing DomainParticipant with C++ applications. (`#25 `__) -* Add environment variable to control override of DomainParticipantQos. (`#41 `__) -* Contributors: Andrea Sorbini, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Miguel Company, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextddsmicro `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Exclude missing sample info fields when building rmw_connextddsmicro (`#79 `__) -* Add support for user-specified content filters (`#68 `__) -* add stub for content filtered topic (`#77 `__) -* Add sequence numbers to message info structure (`#74 `__) -* Add rmw listener apis (`#44 `__) -* Add client/service QoS getters. (`#67 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#20 `__) -* Contributors: Andrea Sorbini, Barry Xu, Chen Lihui, Ivan Santiago Paunovic, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_cyclonedds_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix get_topic_name and handling long service names -* Add serialization for SDK_DATA -* Additional checks for loan API -* Depend on just rmw_dds_common::rmw_dds_common_library (`#385 `__) -* Fix error message in rmw_init_options_copy(). (`#380 `__) -* Add content filter topic feature empty stub. (`#289 `__) -* Update to work with Cyclone 0.9.0 and Iceoryx 2.0 (`#379 `__) -* Fill message info sequence numbers as unsupported, add rmw_feature_supported() implementation. (`#381 `__) -* Fix a warning by making a pointer nullptr. (`#375 `__) -* Bump QDs to QL2 (`#371 `__) -* Add EventsExecutor (`#256 `__) -* Call dissociate_reader in rmw_destroy_subscription -* Wrap creation of new serdata_rmw within a try-catch block -* Fix memory leak in error scenario on the publish side with SHM -* Fix memory leaks on the take side with SHM -* rename _cyclonedds_has_shm to follow the convention -* Add iceoryx_binding_c as dependency to rmw_cyclonedds_cpp -* Release iox_chunk to iceoryx in serdata_free if the iox_chunk is still available -* Update iceoryx_subscriber also when constructing the serdata from the iox chunk -* Fix cpplint errors (`#363 `__) -* Updates for uncrustify 0.72 (`#358 `__) -* Export only rmw::rmw to downstream targets (`#360 `__) -* Export modern CMake targets (`#357 `__) -* Free with the same allocator in rmw_destroy_node (`#355 `__) -* Add client/service QoS getters. (`#343 `__) -* Updated version number and quality level. (`#349 `__) -* Update package maintainers. (`#351 `__) -* Fix undesired memory initialization in zero-copy data path. (`#348 `__) -* Fix QoS depth settings for clients/service being ignored. (`#340 `__) -* Link to Cyclone DDS in Quality Declaration. (`#342 `__) -* Update rmw_context_impl_t definition (`#337 `__) -* Add quality declaration for rmw_cyclonedds_cpp (`#335 `__) -* Fix use of deprecated is_loan_available (`#336 `__) -* Add -latomic for RISC-V (`#332 `__) -* Add pub/sub init, publish and take instrumentation using tracetools (`#329 `__) -* Pass the CRL down to CycloneDDS if it exists (`#325 `__) -* Use the new rmw_dds_common::get_security_files API (`#323 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#294 `__) -* Fix zero copy issues. (`#309 `__) -* Handle allocation errors during message deserialization. (`#313 `__) -* Update includes after rcutils/get_env.h deprecation. (`#312 `__) -* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Dietrich Krönke, Erik Boasson, Haowei Wen, Ivan Santiago Paunovic, Jacob Perron, Joe Speed, Michel Hidalgo, Shane Loretz, Sumanth Nirmal, eboasson, guillaume-pais-siemens, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_dds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Depend on target generated by rosidl_typesupport_cpp (`#58 `__) -* Use rosidl_get_typesupport_target() and target_link_libraries(). (`#57 `__) -* Install headers to include/${PROJECT_NAME} (`#56 `__) -* Fix include order for cpplint (`#55 `__) -* Fix up rmw_dds_common documentation when using rosdoc2 (`#54 `__) -* Add support for Certificate Revocation List files (`#52 `__) -* Silence clang warning (``range-loop-construct``) (`#53 `__) -* Add a common function for security files. (`#51 `__) -* Normalize rmw_time_t according to DDS spec (`#48 `__) -* Contributors: Andrea Sorbini, Chris Lalancette, Jacob Perron, Karsten Knese, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add pub/sub init, publish and take instrumentation using tracetools (`#591 `__) -* Add content filter topic feature (`#513 `__) -* Add sequence numbers to message info structure (`#587 `__) -* Removed some heap interactions in rmw_serialize.cpp (`#590 `__) -* Add EventsExecutor (`#468 `__) -* Install headers to include/${PROJECT_NAME} (`#578 `__) -* Add client/service QoS getters. (`#560 `__) -* Correctly recalculate serialized size on bounded sequences. (`#540 `__) -* Fix type size alignment. (`#550 `__) -* Change links from index.ros.org -> docs.ros.org (`#539 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#519 `__) -* Loan messages implementation (`#523 `__) * Added is_plain\_ attribute to base TypeSupport. * Added new methods to base TypeSupport. * Implementation of rmw_borrow_loaned_message. * Implementation of rmw_return_loaned_message_from_publisher. * Enable loan messages on publishers of plain types. * Implementation for taking loaned messages. * Enable loan messages on subscriptions of plain types. -* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Miguel Company, Shane Loretz, WideAwakeTN, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_dynamic_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add content filter topic feature (`#513 `__) -* Add sequence numbers to message info structure (`#587 `__) -* Add EventsExecutor (`#468 `__) -* Install headers to include/${PROJECT_NAME} (`#578 `__) -* Add client/service QoS getters. (`#560 `__) -* Correctly recalculate serialized size on bounded sequences. (`#540 `__) -* Fix type size alignment. (`#550 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#519 `__) -* Loan messages implementation (`#523 `__) * Added is_plain\_ attribute to base TypeSupport. * Added new methods to base TypeSupport. * Implementation of rmw_borrow_loaned_message. * Implementation of rmw_return_loaned_message_from_publisher. * Enable loan messages on publishers of plain types. * Implementation for taking loaned messages. * Enable loan messages on subscriptions of plain types. -* Contributors: Barry Xu, Chen Lihui, Ivan Santiago Paunovic, Miguel Company, Shane Loretz, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_shared_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address linter waning for windows. (`#592 `__) -* Add pub/sub init, publish and take instrumentation using tracetools (`#591 `__) -* Add content filter topic feature (`#513 `__) -* Add sequence numbers to message info structure (`#587 `__) -* Add EventsExecutor (`#468 `__) -* Complete events support (`#583 `__) -* Install headers to include/${PROJECT_NAME} (`#578 `__) -* Change default to synchronous (`#571 `__) -* Fix cpplint error (`#574 `__) -* Fixes for uncrustify 0.72 (`#572 `__) -* Add client/service QoS getters. (`#560 `__) -* Fix QoS depth settings for clients/service being ignored. (`#564 `__) -* Update rmw_context_impl_t definition. (`#558 `__) -* Update the LoanManager to do internal locking. (`#552 `__) -* Pass the CRL down to Fast-DDS if available. (`#546 `__) -* Use the new rmw_dds_common::get_security_files (`#544 `__) -* Support for SubscriptionOptions::ignore_local_publications (`#536 `__) -* Change links from index.ros.org -> docs.ros.org (`#539 `__) -* Add rmw_publisher_wait_for_all_acked support. (`#519 `__) -* Loan messages implementation (`#523 `__) * Added is_plain\_ attribute to base TypeSupport. * Added new methods to base TypeSupport. * Implementation of rmw_borrow_loaned_message. * Implementation of rmw_return_loaned_message_from_publisher. * Enable loan messages on publishers of plain types. * Implementation for taking loaned messages. * Enable loan messages on subscriptions of plain types. -* Export rmw_dds_common as an rmw_fastrtps_shared_cpp dependency (`#530 `__) -* Update includes after rcutils/get_env.h deprecation (`#529 `__) -* Contributors: Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Jose Antonio Moral, Michel Hidalgo, Miguel Company, Shane Loretz, Tomoya Fujita, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add content-filtered-topic interfaces (`#181 `__) -* Add rmw_feature_supported() (`#204 `__) -* Add EventsExecutor (`#161 `__) -* Fix relative path include syntax for cpplint (`#203 `__) -* Support and prefer exported targets from rmw implementations (`#201 `__) -* Add client/service QoS getters. (`#196 `__) -* Update maintainers to Audrow Nash and Michael Carroll. (`#199 `__) -* Fix renamed ``rcpputils`` header (`#198 `__) -* Fix rmw_implementation generated documentation (`#197 `__) -* Add rmw_publisher_wait_for_all_acked. (`#188 `__) -* Attempt to load any available RMW implementation. (`#189 `__) -* Update includes after rcutils/get_env.h deprecation (`#190 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, iRobot ROS, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use FastDDS as default DDS (`#315 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`robot_state_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Depend on orocos_kdl_vendor (`#191 `__) -* export dependencies, to use robot_state_publisher as a component (`#193 `__) -* Fix include order for cpplint (`#186 `__) -* Change how parameter updates are handled (`#180 `__) -* Install includes to instal/${PROJECT_NAME} (`#184 `__) -* Make the change_fixed_joint test more robust (`#183 `__) -* Add in a test to make sure fixed transforms change on update -* Small C++ nice-isms in the tests -* Switch to using target_include_directories for tests -* Publish new fixed transforms when URDF is updated -* Make joint_states subscription QoS configurable; default to SensorDataQoS (`#179 `__) -* Remove dependency on urdfdom_headers (`#168 `__) -* Fix deprecated subscriber callbacks (`#173 `__) -* Cleanup the documentation in the RobotStatePublisher class. (`#172 `__) -* Always publish fixed frames to /tf_static (`#158 `__) -* corrected publish_frequency default in README (`#166 `__) -* Add tf frame_prefix parameter (`#159 `__) -* Contributors: Abrar Rahman Protyasha, Anthony Deschamps, Chris Lalancette, Jacob Perron, Kenji Brameld, Nils Schulte, Russell Joyce, Shane Loretz, Steve Nogar - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* support to publish as loaned message (`#981 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* support to publish as loaned message (`#981 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Bump version number to avoid conflict -* Make sure published messages are acknowledged for play mode (`#951 `__) -* TopicFilter use regex_search instead of regex_match (`#932 `__) -* Add start-offset play option (`#931 `__) -* Expose bag_rewrite as ``ros2 bag convert`` (`#921 `__) -* Add "ignore leaf topics" option to recorder (`#925 `__) -* Auto-detect storage_id for Reader (if possible) (`#918 `__) -* Add pause/resume options to the bag recorder (`#905 `__) -* Add --start-paused option to ``ros2 bag play`` (`#904 `__) -* Update package maintainers (`#899 `__) -* Fix converter plugin choices for record (`#897 `__) -* Add missing spaces to error message (`#875 `__) -* keyboard controls for pause/resume toggle and play-next: (`#847 `__) -* Add --snapshot-mode argument to the "record" verb (`#851 `__) -* Refactor plugin query mechanism and standardize trait management (`#833 `__) -* Update ``PlayOptions::delay`` to ``rclcpp::Duration`` to get nanosecond resolution (`#843 `__) -* Load compression and serialization choices via plugin query (`#827 `__) -* Add delay option (`#789 `__) -* Avoid passing exception KeyboardInterrupt to the upper layer (`#788 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Kosuke Takeuchi, Michel Hidalgo, Sonia Jin, Tony Peng - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix importlib_metadata warning on Python 3.10. (`#706 `__) -* Add timeout to kill hanging tests (`#701 `__) -* Use try_shutdown() instead of shutdown() in DirectNode.__exit_\_() (`#683 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Reapply `#659 `__ (`#661 `__) -* Revert "Make the ros2cli output always line buffered (`#659 `__)" (`#660 `__) -* Make the ros2cli output always line buffered (`#659 `__) -* add uuid to ros2 daemon node name. (`#658 `__) -* Transfer daemon socket ownership on spawn. (`#652 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli_test_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2component `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Drop deprecated get_container_components_info() API. (`#647 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2doctor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix importlib_metadata warning on Python 3.10. (`#706 `__) -* Add timeout to kill hanging tests (`#701 `__) -* Switch ros2 doctor to using psutil for network checks. (`#687 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Improve ros2 doctor on Windows. (`#631 `__) -* Add QoS compatibility check and report. (`#621 `__) -* Contributors: Aditya Pande, Alberto Soragna, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers in setup.py (`#287 `__) -* Use frontend group dependency & explicit dependencies in ros2launch (`#256 `__) -* Update package maintainers (`#284 `__) -* Add regex filter for selective launch-prefix application (`#261 `__) -* Resolves `#37 `__ - Added --launch-prefix argument for 'ros2 launch' command (`#254 `__) -* Use sets of file extensions provided by parser extensions (`#252 `__) -* Simplify logic to fix absolute paths (`#230 `__) -* add way to include other Python launch files (`launch #122 `__) -* Contributors: Audrow Nash, Cameron Miller, Christophe Bedard, Michel Hidalgo, rob-clarke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle_test_fixtures `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2multicast `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2node `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2param `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Fix how ros2 param interprets command-line arguments. (`#684 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Removed redundant code (`#666 `__) -* Reapply `#659 `__ (`#661 `__) -* Fix flaky ros2 param list (`#656 `__) -* Skip None Result (`#646 `__) -* add '--write' option to avoid an unintentional data loss. (`#638 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Jay Wang, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2pkg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Use local git config instead of global (`#693 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* [ros2pkg] Skip copyright tests in template packages (`#676 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Generate LICENSE files on ros2 pkg create. (`#650 `__) -* Handle ValueError (`#643 `__) -* Pass package exports to template in pkg create api (`#619 `__) (`#628 `__) -* Add changelogs (`#635 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Amro Al-Baali, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Shane Loretz, rob-clarke, tim-fan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2run `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* check subprocess.returncode to print error message. (`#639 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Also provide --include-hidden-services for ``ros2 service list`` verb (`#551 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Add changelogs (`#635 `__) -* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Karsten Knese, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use new domain_coordinator API (`#10 `__) -* Contributors: Timo Röhling - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to kill hanging tests (`#701 `__) -* Add yaml dump flow style. (`#698 `__) -* support ros2topic echo once option. (`#695 `__) -* Fix special case for fastrtps incompatible QoS. (`#694 `__) -* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) -* Add QoS history and depth information if available. (`#678 `__) -* Cleanup mislabeled BSD license (`#447 `__) -* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) -* Updated maintainers (`#670 `__) -* Update lost messages test case (`#669 `__) -* Implementation of message filtering for ros2 (`#654 `__) -* Change default QoSProfile for pub (`#653 `__) -* Add option in ros2 topic pub to wait for N matching subscriptions, use N=1 by default when combined with --times (`#642 `__) -* ``ros2 topic pub`` starts publishing right away. (`#626 `__) -* Fix Topic Info Test with "Infinite" printing (`#616 `__) -* Add changelogs (`#635 `__) -* QoS autodetection (`#613 `__) -* Make Lost Messages option ON by default (`#633 `__) -* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Emerson Knapp, Gonzo, Ivan Santiago Paunovic, Jorge Perez, Shane Loretz, Tomoya Fujita, Tully Foote, matthews-jca - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix 'ros2 trace' fini() error -* Don't require kernel tracer and detect when it's not installed -* Deprecate 'context_names' param and replace with 'context_fields' -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Update package maintainers (`#899 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Remove unnecessary public definition. (`#950 `__) -* Changes for uncrustify 0.72 (`#937 `__) -* Bugfix for broken bag split when using cache (`#936 `__) -* Update package maintainers (`#899 `__) -* Don't preprocess a storage file more than once (`#895 `__) -* added seek interface (`#836 `__) -* Refactor plugin query mechanism and standardize trait management (`#833 `__) -* fix sequential reader rollover-to-next-file strategy: (`#839 `__) -* Load compression and serialization choices via plugin query (`#827 `__) -* Contributors: Cameron Miller, Chris Lalancette, Michael Orlov, Michel Hidalgo, Shane Loretz, sonia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression_zstd `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Update package maintainers (`#899 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Remove unnecessary public definition. (`#950 `__) -* Fix relative path syntax for cpplint (`#947 `__) -* Mark up the message_cache with TSA annotations (`#946 `__) -* Changes for uncrustify 0.72 (`#937 `__) -* Redesign in cache consumer and circular message cache to get rid from busy loop (`#941 `__) -* Bugfix for broken bag split when using cache (`#936 `__) -* Remove JumpHandler copy-implementation from PlayerClock/TimeControllerClock (`#935 `__) -* Auto-detect storage_id for Reader (if possible) (`#918 `__) -* Add --start-paused option to ``ros2 bag play`` (`#904 `__) -* Use the message_introspection header to get MessageMember. (`#903 `__) -* Update package maintainers (`#899 `__) -* Fix converter plugin choices for record (`#897 `__) -* Enable sanitizers only if code actually can run (`#572 `__) -* Need to pass introspection TS to converter plugin for it to be useful (`#896 `__) -* Don't preprocess a storage file more than once (`#895 `__) -* Fix a bug on invalid pointer address when using "MESSAGE" compressio… (`#866 `__) -* Metadata per file info (`#870 `__) -* Fix TSA warnings when building with clang thread analysis. (`#877 `__) -* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) -* Circular Message Cache implementation for snapshot feature (`#844 `__) -* Fix discovery silently stops after unknown msg type is found. (`#848 `__) -* added seek interface (`#836 `__) -* Refactor plugin query mechanism and standardize trait management (`#833 `__) -* fix sequential reader rollover-to-next-file strategy: (`#839 `__) -* Load compression and serialization choices via plugin query (`#827 `__) -* Workaround for false positive findings by clang thread safety analysis in time controller jump callbacks API. (`#799 `__) -* Add callbacks for PlayerClock::jump(time_point) API with CI fix (`#779 `__) -* Revert "Add callbacks for PlayerClock::jump(time_point) API (`#775 `__)" (`#778 `__) -* Add callbacks for PlayerClock::jump(time_point) API (`#775 `__) -* Contributors: Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Lei Liu, Michael Orlov, Michel Hidalgo, Shane Loretz, Tony Peng, Wojciech Jaworski, sonia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Add burst-mode to Player (`#977 `__) -* Update package maintainers (`#899 `__) -* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) * Add snapshot service to recorder node * Simplify and clarify double buffering patterns -* Contributors: Cameron Miller, Chris Lalancette, Geoffrey Biggs, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_performance_benchmarking `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) * Enable YAML encoding/decoding for RecordOptions and StorageOptions -* Update package maintainers (`#899 `__) -* Updated node declare_parameter to new syntax (`#882 `__) -* Updated benchmark package to use writer close() instead of old reset() (`#881 `__) -* Contributors: Adam Dąbrowski, Chris Lalancette, Emerson Knapp, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* support to publish as loaned message (`#981 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* support to publish as loaned message (`#981 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Bump version number to avoid conflict -* Make sure published messages are acknowledged for play mode (`#951 `__) -* Fix relative path syntax for cpplint (`#947 `__) -* Update to pybind11 2.7.1 (`#945 `__) -* Add start-offset play option (`#931 `__) -* Expose bag_rewrite as ``ros2 bag convert`` (`#921 `__) -* Add "ignore leaf topics" option to recorder (`#925 `__) -* Add a ReaderWriterFactory utility to share logic for reuse (`#923 `__) -* Add pause/resume options to the bag recorder (`#905 `__) -* Add --start-paused option to ``ros2 bag play`` (`#904 `__) -* Update package maintainers (`#899 `__) -* Fix converter plugin choices for record (`#897 `__) -* Metadata per file info (`#870 `__) -* keyboard controls for pause/resume toggle and play-next: (`#847 `__) -* Add --snapshot-mode argument to the "record" verb (`#851 `__) -* Add stopRecording into rosbag2_py (`#854 `__) -* added seek interface (`#836 `__) -* Refactor plugin query mechanism and standardize trait management (`#833 `__) -* Update ``PlayOptions::delay`` to ``rclcpp::Duration`` to get nanosecond resolution (`#843 `__) -* Load compression and serialization choices via plugin query (`#827 `__) -* Add delay option (`#789 `__) -* Handle SIGTERM gracefully in recording (`#792 `__) -* Contributors: Abrar Rahman Protyasha, Afonso da Fonseca Braga, Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Kosuke Takeuchi, Michel Hidalgo, Tony Peng, Wojciech Jaworski, sonia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Remove unnecessary public definition. (`#950 `__) -* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) -* Update package maintainers (`#899 `__) -* Provide MetadataIO interface to convert metadata to a string in memory, alongside file IO versions (`#894 `__) -* Metadata per file info (`#870 `__) -* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) -* added seek interface (`#836 `__) -* Refactor plugin query mechanism and standardize trait management (`#833 `__) -* Contributors: Audrow Nash, Cameron Miller, Chris Lalancette, Emerson Knapp, Jorge Perez, Michel Hidalgo, Shane Loretz, Tony Peng, Wojciech Jaworski, sonia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Emit a warning rather than crash when a message is too big for sqlite (`#919 `__) -* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) -* Update package maintainers (`#899 `__) -* added seek interface (`#836 `__) -* Contributors: Chris Lalancette, Emerson Knapp, Michel Hidalgo, Shane Loretz, William Woodall, sonia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Update package maintainers (`#899 `__) -* Make sure the subscription exists before publishing messages (`#804 `__) -* Handle SIGTERM gracefully in recording (`#792 `__) -* Add spin_and_wait_for_matched to PublicationManager and update test c… (`#797 `__) -* Avoid passing exception KeyboardInterrupt to the upper layer (`#788 `__) -* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) -* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) -* Bump version number to avoid conflict -* Add pause/resume options to the bag recorder (`#905 `__) -* Update package maintainers (`#899 `__) -* Fix a bug on invalid pointer address when using "MESSAGE" compressio… (`#866 `__) -* Metadata per file info (`#870 `__) -* Fix record test to reflect plugin query changes (`#838 `__) -* Make sure the subscription exists before publishing messages (`#804 `__) -* Handle SIGTERM gracefully in recording (`#792 `__) -* Add spin_and_wait_for_matched to PublicationManager and update test c… (`#797 `__) -* Remove rmw_fastrtps_cpp find_package in rosbag2_tests (`#774 `__) -* Contributors: Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jorge Perez, Michel Hidalgo, Tony Peng, Wojciech Jaworski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* support to publish as loaned message (`#981 `__) -* support to publish as loaned message (`#981 `__) -* Bump version number to avoid conflict -* Add burst-mode to Player (`#977 `__) -* Install headers to include/${PROJECT_NAME} (`#958 `__) -* Make sure published messages are acknowledged for play mode (`#951 `__) -* Changes for uncrustify 0.72 (`#937 `__) -* TopicFilter use regex_search instead of regex_match (`#932 `__) -* Add start-offset play option (`#931 `__) -* Add parentheses suggested by Clang on OSX to fix build warning (`#930 `__) -* Bag rewriter (C++) (`#920 `__) -* Add "ignore leaf topics" option to recorder (`#925 `__) -* Rewrite TopicFilter for single-call reusability (`#924 `__) -* Add a ReaderWriterFactory utility to share logic for reuse (`#923 `__) -* Add pause/resume options to the bag recorder (`#905 `__) -* Add logging macros for rosbag2_transport (`#917 `__) -* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) -* Expose the QoS object wrapper (`#910 `__) -* Add --start-paused option to ``ros2 bag play`` (`#904 `__) -* Update package maintainers (`#899 `__) -* Add a Seek service (`#874 `__) -* Add simple keyboard control for playback rate (`#893 `__) -* Fix a bug on invalid pointer address when using "MESSAGE" compressio… (`#866 `__) -* Fix typo (`#880 `__) -* Use Reader's seek() method for seeking/jumping in Player (`#873 `__) -* keyboard controls for pause/resume toggle and play-next: (`#847 `__) -* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) -* Circular Message Cache implementation for snapshot feature (`#844 `__) -* Add jump/seek API for Player class (`#826 `__) -* Restructure test_play_timing to one test per case, to see which times out (`#863 `__) -* Fix discovery silently stops after unknown msg type is found. (`#848 `__) -* Fixing deprecated subscriber callback warnings (`#852 `__) -* Bugfix for race condition in Player::peek_next_message_from_queue() (`#849 `__) -* added seek interface (`#836 `__) -* Update ``PlayOptions::delay`` to ``rclcpp::Duration`` to get nanosecond resolution (`#843 `__) -* Move notification about ready for playback inside play_messages_from_queue() (`#832 `__) -* Add wait for player to be ready for playback in Player::play_next() method (`#814 `__) -* Make sure the subscription exists before publishing messages (`#804 `__) -* Add delay option (`#789 `__) -* Copy recorder QoS profile to local variable so that temporary value isn't cleared (`#803 `__) -* test_play_services: fail gracefully on future error (`#798 `__) -* Recording with --all and --exclude fix (`#765 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Bastian Jäger, Cameron Miller, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Ivan Santiago Paunovic, Kosuke Takeuchi, Lei Liu, Louise Poubel, Michael Orlov, Michel Hidalgo, Piotr Jaroszek, Shane Loretz, sonia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosgraph_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_adapter `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rename nested loop index (`#643 `__) -* Fix how comments in action interfaces are processed (`#632 `__) -* Pass comments in ros interface constants to the .idl generated files (`#630 `__) -* Update package maintainers (`#624 `__) -* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) -* Fix escaping in string literals (`#595 `__) -* Ignore multiple ``#`` characters and dedent comments (`#594 `__) -* Contributors: Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz, ibnHatab - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix importlib_metdata warning with Python 3.10. (`#674 `__) -* Update maintainers to Michel Hidalgo and Shane Loretz (`#633 `__) -* Update package maintainers (`#624 `__) -* Support passing keyword arguments to rosidl CLI extensions (`#597 `__) -* Add missing f for format string (`#600 `__) -* Contributors: Audrow Nash, Chris Lalancette, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make rosidl_get_typesupport_target return -NOTFOUND instead of FATAL_ERROR (`#672 `__) -* Add introspection typesupport tests for C/C++ messages (`#651 `__) -* Use target output name for exporting typesupport library (`#625 `__) -* Update package maintainers (`#624 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) -* Add rosidl_get_typesupport_target and deprecate rosidl_target_interfaces (`#606 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) -* Contributors: Jonathan Selling, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_generators `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Unroll group dependencies (`#20 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_runtime `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Unroll group dependencies (`#20 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix error handling when copying C sequence messages (`#671 `__) -* Install generated headers to include/${PROJECT_NAME} (`#670 `__) -* Misc cleanup in the rosidl generator extensions (`#662 `__) -* Set the output size unconditionally when copying sequences (`#669 `__) -* Implement copy function for C messages (`#650 `__) -* Implement equality operator function for C messages. (`#648 `__) -* Generate documentation in generated C header files based on ROS interfaces comments (`#593 `__) -* Update package maintainers (`#624 `__) -* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) -* Fix a cpplint allocator regression. (`#590 `__) -* Use RCUtils allocators in rosidl_generator_c (`#584 `__) -* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Nikolai Morin, Pablo Garrido, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install generated headers to include/${PROJECT_NAME} (`#670 `__) -* Misc cleanup in the rosidl generator extensions (`#662 `__) -* Add missing build_export_depend dependency (`#665 `__) -* Fix bug where rosidl_runtime_cpp wasn't depended upon (`#660 `__) -* Fix include order for cpplint (`#644 `__) -* Set CXX standard to 17 (`#635 `__) -* Update package maintainers (`#624 `__) -* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) -* Support flow style YAML printing (`#613 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) -* Relocate to_yaml() under message namespace (`#609 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) -* Contributors: Jacob Perron, Jorge Perez, Michel Hidalgo, Shane Loretz, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_dds_idl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add changelog (`#56 `__) -* Contributors: Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removes erroneous unmatched closing parenthesis (`#125 `__) -* require Python 3.6 as we use format strings in various places (`#152 `__) -* Fix rosidl_generator_py assuming incorect library names (`#149 `__) -* Fix for msg file containing a property field that is not at the end (`#151 `__) -* Update package maintainers (`#147 `__) -* Use rosidl_get_typesupport_target() (`#139 `__) -* Support available typesupport specification in CLI extension (`#133 `__) -* Use python_d for test_cli_extension in Debug mode (`#136 `__) -* Add missing float/double bounds check (`#128 `__) -* Added optimization for copying arrays using buffer protocol (`#129 `__) -* Add smoke test for CLI extension (`#132 `__) -* Install generated Python interfaces in a Python package (`#131 `__) -* Contributors: Charles Cross, Chen Lihui, Michel Hidalgo, Seulbae Kim, Shane Loretz, William Woodall, ksuszka - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set maybe_placeholders to False for lark 1.+ compatibility (`#664 `__) -* Generate documentation in generated C header files based on ROS interfaces comments (`#593 `__) -* Pass comments in ros interface constants to the .idl generated files (`#630 `__) -* Update package maintainers (`#624 `__) -* Fix escaping in string literals (`#595 `__) -* Contributors: Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix error handling when copying C sequence messages (`#671 `__) -* Set the output size unconditionally when copying sequences (`#669 `__) -* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) -* Install headers to include/${PROJECT_NAME} (`#658 `__) -* Implement copy function for C messages (`#650 `__) -* Implement equality operator function for C messages. (`#648 `__) -* Set CXX standard to 17 (`#635 `__) -* Update package maintainers (`#624 `__) -* Use RCUtils allocators in rosidl_generator_c (`#584 `__) -* Contributors: Jose Luis Rivero, Michel Hidalgo, Nikolai Morin, Pablo Garrido, Shane Loretz, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing dependency on rosidl_runtime_c (`#666 `__) -* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) -* Install headers to include/${PROJECT_NAME} (`#658 `__) -* Set CXX standard to 17 (`#635 `__) -* Update package maintainers (`#624 `__) -* Contributors: Jose Luis Rivero, Michel Hidalgo, Shane Loretz, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add yaml dump flow style. (`#16 `__) -* Update maintainers (`#15 `__) * Update maintainers to Shane Loretz * Update Shane's email Co-authored-by: Shane Loretz -* Contributors: Audrow Nash, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries(... PRIVATE ...) in single typesupport case (`#124 `__) -* rosidl CMake cleanup in rosidl_typesupport_c (`#123 `__) -* Install headers to include/${PROJECT_NAME} (`#121 `__) -* Use FindPython3 (`#118 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#116 `__) -* Support available typesupport specification in CLI extensions (`#112 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#113 `__) -* Fix C and C++ typesupports CLI extensions (`#111 `__) -* Contributors: Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries(... PRIVATE ...) in single typesupport case (`#124 `__) -* rosidl CMake cleanup in rosidl_typesupport_cpp (`#123 `__) -* Install headers to include/${PROJECT_NAME} (`#121 `__) -* Make sure to check typesupport handles against nullptr properly (`#119 `__) -* Use FindPython3 (`#118 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#116 `__) -* Support available typesupport specification in CLI extensions (`#112 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#113 `__) -* Fix C and C++ typesupports CLI extensions (`#111 `__) -* Contributors: Chris Lalancette, Michel Hidalgo, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install generated headers to include/${PROJECT_NAME} (`#88 `__) -* Misc fastrtps typesupport generator cleanup (`#87 `__) -* Install headers to include/${PROJECT_NAME} (`#86 `__) -* Fix include order for cpplint (`#84 `__) -* Update maintainers to Shane Loretz (`#83 `__) -* Use FindPython3 explicitly instead of PythonInterp implicitly (`#78 `__) -* Revert rosidl targets and dependencies exportation (`#76 `__) * Revert "Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__)" * Revert "Bundle and ensure the exportation of rosidl generated targets (`#73 `__)" -* Correctly inform that a BoundedSequence is bounded (`#71 `__) -* Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#73 `__) -* Fix Fast-RTPS C++ typesupport CLI extension (`#72 `__) -* Fastdds type support extensions (`#67 `__) -* Remove fastrtps dependency (`#68 `__) -* Contributors: Andrea Sorbini, Audrow Nash, Jacob Perron, Michel Hidalgo, Miguel Company, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install generated headers to include/${PROJECT_NAME} (`#88 `__) -* Misc fastrtps typesupport generator cleanup (`#87 `__) -* Install headers to include/${PROJECT_NAME} (`#86 `__) -* Fix include order for cpplint (`#84 `__) * Fix include order for cpplint Relates to https://github.com/ament/ament_lint/pull/324 * Use double-quotes for other includes This is backwards compatible with older versions of cpplint. -* Update maintainers to Shane Loretz (`#83 `__) -* Re-introduce improvements to serialization of primitive bounded sequences for C++ type support (`#81 `__) -* Revert "Improve serialization of ... (`#79 `__)" (`#80 `__) -* Improve serialization of primitive bounded sequences in C++ type support (`#79 `__) -* Use FindPython3 explicitly instead of PythonInterp implicitly (`#78 `__) -* Revert rosidl targets and dependencies exportation (`#76 `__) * Revert "Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__)" * Revert "Bundle and ensure the exportation of rosidl generated targets (`#73 `__)" -* Correctly inform that a BoundedSequence is bounded (`#71 `__) -* Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#73 `__) -* Fix Fast-RTPS C++ typesupport CLI extension (`#72 `__) -* Fastdds type support extensions (`#67 `__) -* Remove fastrtps dependency (`#68 `__) -* Contributors: Andrea Sorbini, Audrow Nash, Jacob Perron, Jorge Perez, Michel Hidalgo, Miguel Company, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) -* Install headers to include/${PROJECT_NAME} (`#658 `__) -* Add ROSIDL_TYPESUPPORT_INTERFACE__LIBRARY_NAME() macro (`#649 `__) -* Set CXX standard to 17 (`#635 `__) -* Update package maintainers (`#624 `__) -* Contributors: Jose Luis Rivero, Michel Hidalgo, Shane Loretz, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install generated headers to include/${PROJECT_NAME} (`#670 `__) -* Misc cleanup in the rosidl generator extensions (`#662 `__) -* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) -* Update Quality declaration to level 1 in README for instrospection pkgs (`#659 `__) -* Install headers to include/${PROJECT_NAME} (`#658 `__) -* Move rosidl_typesupport_introspection_cpp quality declaration to Q1 (`#657 `__) -* Move rosidl_typesupport_introspection_c quality declaration to Q1 (`#656 `__) -* add documentation for generators and API (`#646 `__) -* Rework nested types' items introspection in C and C++ (`#652 `__) -* Fix up the documentation for rosidl_typesupport_introspection_c (`#628 `__) -* Update package maintainers (`#624 `__) -* Quality Declaration for typesupport_introspection (`#621 `__) -* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) -* Update function prefix (`#596 `__) -* Contributors: Chris Lalancette, Jose Luis Rivero, Michel Hidalgo, Pablo Garrido, Shane Loretz, eboasson - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install generated headers to include/${PROJECT_NAME} (`#670 `__) -* Misc cleanup in the rosidl generator extensions (`#662 `__) -* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) -* Update Quality declaration to level 1 in README for instrospection pkgs (`#659 `__) -* Install headers to include/${PROJECT_NAME} (`#658 `__) -* Move rosidl_typesupport_introspection_cpp quality declaration to Q1 (`#657 `__) -* add documentation for generators and API (`#646 `__) -* Rework nested types' items introspection in C and C++ (`#652 `__) -* Set CXX standard to 17 (`#635 `__) -* Fix up the documentation for rosidl_typesupport_introspection_cpp (`#627 `__) -* Update package maintainers (`#624 `__) -* Quality Declaration for typesupport_introspection (`#621 `__) -* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) -* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) -* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) -* Contributors: Chris Lalancette, Jose Luis Rivero, Michel Hidalgo, Shane Loretz, eboasson, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump ``rosidl_typesupport_introspection_tests`` coverage (`#655 `__) -* Add introspection typesupport tests for C/C++ services (`#653 `__) -* Add introspection typesupport tests for C/C++ messages (`#651 `__) -* Contributors: Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rpyutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to call abspath when adding Windows DLL directories. (`#8 `__) -* Update troubleshooting links to docs.ros.org (`#6 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed getiter to iter (`#1 `__) (`#241 `__) -* Update maintainers (`#233 `__) (`#237 `__) -* add missing dependencies: rospkg-modules, python_qt_binding, rospy (`#227 `__) -* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) -* use catkin_install_python for Python script (`#206 `__) -* Contributors: Michael Jeronimo, sven-herrmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#233 `__) (`#237 `__) -* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) -* [Windows] fix rqt_gui_cpp install path (`#190 `__) -* [Windows] fix building (`#189 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#233 `__) (`#237 `__) -* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#233 `__) (`#237 `__) -* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) -* fix missing import bugs (`#139 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rti_connext_dds_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rti-connext-dds dependency to 6.0.1. (`#71 `__) -* Contributors: Steven! Ragnarök - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rttest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#114 `__) -* Fix include order for cpplint (`#113 `__) -* Fixes for uncrustify 0.72 (`#111 `__) -* Mark dependent targets as PRIVATE (`#112 `__) -* Export modern CMake targets (`#110 `__) -* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change links index.ros.org -> docs.ros.org. (`#698 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_assimp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to pass compiler and flags down to assimp (`#844 `__) -* Fix support for assimp 5.1.0 (`#817 `__) -* Contributors: Chris Lalancette, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add implementation for cancel interface (`#809 `__) -* Install headers to include/${PROJECT_NAME} (`#829 `__) -* Remove definition of PLUGINLIB_DISABLE_BOOST. (`#821 `__) -* Fix support for assimp 5.1.0 (`#817 `__) -* Fix cpplint errors (`#818 `__) -* Set message type for ros topic display (`#800 `__) -* Fixes for uncrustify 0.72 (`#807 `__) -* Do not block visualization manager updates when opening the display panel dialog (`#795 `__) -* Switch to using Qt::MiddleButton for RViz. (`#802 `__) -* Removed traces in renderPanel (`#777 `__) -* move yaml_config_writer.hpp to public includes (`#764 `__) -* Update displays_panel.cpp (`#745 `__) -* Robot: Report mesh loading issues (`#744 `__) -* Exposed tool_manager header file. (`#767 `__) -* refactor: make const getter methods const (`#756 `__) -* Efficiently handle 3-bytes pixel formats (`#743 `__) -* Report sample lost events (`#686 `__) -* Update window close icon (`#734 `__) -* Fix missing "X" icon in panel close button (`#731 `__) -* Add rviz_rendering dependency to rviz_common (`#727 `__) -* Remove the word "Alpha" from the splash screen. (`#696 `__) -* Removed some memory leaks in rviz_rendering and rviz_rendering_tests (`#710 `__) -* Contributors: ANDOU Tetsuo, Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Daisuke Nishimatsu, Gonzo, Ivan Santiago Paunovic, Jacob Perron, Joseph Schornak, Rebecca Butler, Shane Loretz, Silvio Traversaro, davidorchansky - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add far plane distance property to camera (`#849 `__) -* Drop ignition-math6 from rviz_default_plugins link interface (`#833 `__) -* add implementation for cancel interface (`#809 `__) -* Install headers to include/${PROJECT_NAME} (`#829 `__) -* Remove definition of PLUGINLIB_DISABLE_BOOST. (`#821 `__) -* Remove TF filter from ImageTransportDisplay (`#788 `__) -* Add underscores to material names (`#811 `__) -* Export image_transport dependency (`#813 `__) -* Fixes for uncrustify 0.72 (`#807 `__) -* Switch to using Qt::MiddleButton for RViz. (`#802 `__) -* Add a tf_buffer_cache_time_ns to tf_wrapper (`#792 `__) -* Make libraries to avoid compiling files multiple times (`#774 `__) -* Computed inertia with ignition-math (`#751 `__) -* Fixed crash when changing rendering parameters for pointcloud2 while 'Selectable' box is unchecked (`#768 `__) -* Robot: Report mesh loading issues (`#744 `__) -* Handle NaN values for Wrench msgs (`#746 `__) -* Triangle lists support textures (`#719 `__) -* Report sample lost events (`#686 `__) -* Fix path message orientation error (`#736 `__) -* Set topic namespace in interactive markers display (`#725 `__) -* mass property visualization (`#714 `__) -* Export InteractiveMarker (`#718 `__) -* Yuv to rgb changes (`#701 `__) -* Extract message type in ImageTransportDisplay (`#711 `__) -* Duplicated code RobotJoint (`#702 `__) -* Don't attempt to moc generate files that don't have QOBJECT. (`#690 `__) -* Switch to including tf2_geometry_msgs.hpp (`#689 `__) -* Export Qt5 dependencies properly (`#687 `__) -* Add support for namespace-scoped DELETEALL action in Marker displays (`#685 `__) -* Use image_transport to subscribe to image messages (`#523 `__) -* Contributors: Akash, Alejandro Hernández Cordero, Audrow Nash, Chen Lihui, Chris Lalancette, Cory Crean, Gonzo, Greg Balke, Ivan Santiago Paunovic, Jacob Perron, Martin Idel, Michel Hidalgo, Paul, Rebecca Butler, Scott K Logan, Shane Loretz, bailaC, brian soe, cturcotte-qnx, ketatam - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_ogre_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix interface link libraries in ogre vendor (`#761 `__) -* Fix the build for Ubuntu Jammy arm64. (`#828 `__) -* Strip RPATH from installed Ogre binaries (`#688 `__) -* Contributors: Chris Lalancette, Laszlo Turanyi, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make getVerticesPerPoint method public and improve tests (`#843 `__) -* Disable class-memaccess warnings for Eigen (`#838 `__) -* Disable a warning when including Eigen. (`#835 `__) -* Install headers to include/${PROJECT_NAME} (`#829 `__) -* Fix support for assimp 5.1.0 (`#817 `__) -* Fix cpplint errors (`#818 `__) -* Fixes for uncrustify 0.72 (`#807 `__) -* Suppress assimp warnings in rviz_rendering build (`#775 `__) -* Fix for ogre failing when material already exists (`#729 `__) -* Removed some memory leaks in rviz_rendering and rviz_rendering_tests (`#710 `__) -* Export Qt5 dependencies properly (`#687 `__) -* Putting glsl 1.50 resources back in RenderSystem (`#668 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Jorge Perez, Michel Hidalgo, Piotr Jaroszek, Scott K Logan, Shane Loretz, Silvio Traversaro, Wolf Vollprecht - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed some memory leaks in rviz_rendering and rviz_rendering_tests (`#710 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_visual_testing_framework `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} (`#829 `__) -* Fixes for uncrustify 0.72 (`#807 `__) -* Update includes after rcutils/get_env.h deprecation (`#677 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Move the find_package statements for BUILD_TESTING (`#186 `__) -* Feedback on conditional sensor_msgs_library target (`#1 `__) (`#183 `__) -* [Fix] Fix image_encodings.hpp's URL in README (`#184 `__) -* [Fix] Fix fill_image.hpp's URL in README (`#182 `__) -* Add sensor_msgs_library target and install headers to include/${PROJECT_NAME} (`#178 `__) -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Add YUV420 and YUV444 to image encodings (`#172 `__) -* Cleanup mislabeled BSD license (`#83 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Fix rosdoc2 warnings in sensor_msgs. (`#162 `__) -* Add equidistant distortion model (`#160 `__) -* Use rosidl_get_typesupport_target() (`#156 `__) -* Update CompressedImage documentation: add 'tiff' as a supported format (`#154 `__) -* Contributors: Audrow Nash, Chris Lalancette, Grey, Hemal Shah, Homalozoa X, Ivan Santiago Paunovic, Martin Günther, Michael Jeronimo, Pablo Garrido, Shane Loretz, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in a compatibility layer for older versions of numpy. (`#185 `__) -* Port pointcloud creation to numpy. (`#175 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Chris Lalancette, Florian Vahl - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shape_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Add prism type to the SolidPrimitive.msg (`#166 `__) (`#167 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey, M. Fatih Cırıt - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shared_queues_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Update package maintainers (`#899 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sqlite3_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Update package maintainers (`#899 `__) -* Contributors: Chris Lalancette, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sros2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Increase the shutdown timeout for test_generate_policy_no_nodes. (`#278 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`statistics_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Chris Lalancette (`#130 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_srvs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`stereo_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#489 `__) -* Add changelogs (`#473 `__) -* Merge pull request `#356 `__ from ros2/issue/321_enhance_parameter_api -* Contributors: Aditya Pande, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli_remapping `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update python nodes SIGINT handling (`#490 `__) -* Updated maintainers (`#489 `__) -* Add changelogs (`#473 `__) -* Contributors: Aditya Pande, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_communication `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Split test_subscriber into multiple compilation units. (`#500 `__) -* Add test_msgs dependency (`#497 `__) -* Update python nodes SIGINT handling (`#490 `__) -* Updated maintainers (`#489 `__) -* Fix deprecated subscriber callback warnings (`#483 `__) -* Add tests for BoundedPlainSequences (`#481 `__) -* Use rosidl_get_typesupport_target() (`#480 `__) -* Use rcpputils/scope_exit.hpp instead of rclcpp/scope_exit.hpp (`#479 `__) -* Add changelogs (`#473 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_interface_files `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Update package.xml (`#18 `__)" (`#19 `__) -* Update package.xml (`#18 `__) -* Update maintainers to Audrow Nash (`#17 `__) -* Added BoundedPlainSequences messages (`#14 `__) -* Contributors: Audrow Nash, Chris Lalancette, Miguel Company, Nikolai Morin - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Increase test time tolerance (`#305 `__) -* Use correct namespace when evaluating parameter files for composable nodes (`#303 `__) -* Handle empty strings when evaluating parameters (`#300 `__) -* Add parameter substitution (`#297 `__) -* More Helpful Error Messages (`#275 `__) -* Update maintainers in setup.py (`#287 `__) -* Set parameters from file for composable nodes (`#281 `__) -* Update package maintainers (`#284 `__) -* Update node name matcher (`#282 `__) -* Support both parameter file configurations for composable nodes (`#259 `__) -* Shutdown context after test (`#267 `__) -* Handle substitutions in RosTimer (`#264 `__) -* Add SetParametersFromFile action (`#260 `__) -* Properly support ros_args attribute through launch frontends (`#253 `__) -* Add 'push_ros_namespace' alias to 'push-ros-namespace' (`#250 `__) -* Add ros_arguments option to Node action (`#249 `__) -* ROS Timer Action (`#244 `__) -* Support container in frontend (`#235 `__) -* Added normalize_remap_rule and types. (`launch #173 `__) -* Fixed setup.py versions (`launch #155 `__) -* Fixed a bug to ensure that shutdown event is handled correctly (`launch #154 `__) -* Made various fixes and added tests for remappings passed to Node actions (`launch #137 `__) -* Contributors: Aditya Pande, Audrow Nash, Christophe Bedard, David V. Lu!!, Jacob Perron, Jorge Perez, Kenji Miyake, Michel Hidalgo, Rebecca Butler - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) -* Updated maintainers (`#555 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} and Depend on rosidl_typesupport\_* targets directly (`#133 `__) -* Update maintainers to Chris Lalancette (`#130 `__) -* Add test fixures for BoundedPlainSequences (`#125 `__) -* Added BoundedPlainSequences to test_msgs (`#123 `__) -* Contributors: Audrow Nash, Miguel Company, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_quality_of_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Aditya Pande and Shane Loretz (`#491 `__) -* Updated maintainers (`#489 `__) -* Fix deprecated subscriber callback warnings (`#483 `__) -* Add changelogs (`#473 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix include order for cpplint (`#493 `__) -* Fix test (`#488 `__) -* Updated maintainers (`#489 `__) -* Add tests for rclcpp sigterm handler (`#485 `__) -* Fix deprecated subscriber callback warnings (`#483 `__) -* Fix deprecation warnings and failures after client API update (`#482 `__) -* Use rosidl_get_typesupport_target() (`#480 `__) -* Use rcpputils/scope_exit.hpp instead of rclcpp/scope_exit.hpp (`#479 `__) -* Add test for defered service callback signature (`#478 `__) -* Add changelogs (`#473 `__) -* Merge pull request `#357 `__ from ros2/ros2_658_leftovers -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Mauro Passerino, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add content-filtered-topic interfaces (`#181 `__) -* Fix linter issues (`#200 `__) -* Add client/service QoS getters. (`#196 `__) -* Added tests for bounded sequences serialization (`#193 `__) -* Add RMW_DURATION_INFINITE basic compliance test. (`#194 `__) -* Test SubscriptionOptions::ignore_local_publications. (`#192 `__) -* Add rmw_publisher_wait_for_all_acked. (`#188 `__) -* Wait for server in test_rmw_implementation service tests. (`#191 `__) -* Contributors: Barry Xu, Chen Lihui, Emerson Knapp, Jorge Perez, Jose Antonio Moral, Michel Hidalgo, Miguel Company, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_security `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated maintainers (`#489 `__) -* Fix deprecated subscriber callback warnings (`#483 `__) -* Add changelogs (`#473 `__) -* Simplify the test_secure_subscriber code. (`#471 `__) -* Update includes after rcutils/get_env.h deprecation (`#472 `__) -* Contributors: Abrar Rahman Protyasha, Aditya Pande, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix more instances of Eigen problems on RHEL. (`#515 `__) -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* Fix precision loss from using rclcpp::Time::seconds() (`#511 `__) -* More Intuitive CLI for Static Transform Publisher (`#392 `__) -* Conversion tests for toMsg() (`#423 `__) -* Deprecate tf2_geometry_msgs.h (`#418 `__) -* Deprecate tf2_kdl.h (`#414 `__) -* Deprecate tf2_bullet.h (`#412 `__) -* Contributors: Bjar Ne, Chris Lalancette, Hunter L. Allen, Kenji Brameld, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Introduce constants for tracepoint names -* Move actual tests out of tracetools_test to new test_tracetools package -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for preloading pthread and dl instrumentation shared libs -* Remove profile_fast option and consider LD_PRELOADing both libs -* Fix multiple LdPreload actions not working and add test -* Deprecate 'context_names' param and replace with 'context_fields' -* Move some tests from tracetools_launch to test_tracetools_launch -* Contributors: Christophe Bedard, Ingo Lütkebohle - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* forward declare fromMsg to avoid missing symbols in downstream libraries (`#485 `__) -* tf2: Enable common linter tests (`#469 `__) -* Move time functions into time.cpp. -* Change a for loop to a while loop. -* Switch to C++-style casts. -* Remove totally unused (and unreachable) code. -* Replace NULL with nullptr. -* Fix up some comments. -* Use std::make_shared where we can. -* Replace two comparisons with empty string to empty(). -* Make sure to include-what-you-use. -* Remove unnecessary internal method. -* Remove long-deprecated walkToTopParent overload. -* Remove unnecessary test dependencies. -* Remove some references to the ROS 1 wiki. -* Add rosidl_runtime_cpp as build_depend and build_export_depend. -* Minor cleanups in CMakeLists.txt. -* Remove include directory that doesn't exist. -* Remove completely unnecessary target_link_libraries. -* Remove unused speed_test from tf2. -* Suppress clang warnings about enumerator attributes. (`#463 `__) -* Change TF2Error names to be a bit more descriptive. (`#349 `__) -* Fixed errors due to missing header link. (`#432 `__) -* Deprecate tf2_geometry_msgs.h (`#418 `__) -* Speedup covariance unwrapping (`#399 `__) -* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Dima Dorezyuk, João C. Monteiro, Shane Loretz, Shivam Pandey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_bullet `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* Export a tf2_bullet::tf2_bullet target (`#495 `__) -* Fix cpplint errors (`#497 `__) -* Remove some references to the ROS 1 wiki. -* Fix tf2_bullet dependency export (`#428 `__) -* Deprecate tf2_bullet.h (`#412 `__) -* Contributors: Bjar Ne, Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Workaround broken RHEL FindEigen3.cmake (`#513 `__) -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* Disable mem-access warnings on aarch64. (`#506 `__) -* Fix cpplint errors (`#497 `__) -* Remove some references to the ROS 1 wiki. -* Add doTransform function for twists or wrenches (`#406 `__) -* Reenable stamped eigen tests (`#429 `__) -* Deprecate tf2_eigen.h (`#413 `__) -* Contributors: AndyZe, Bjar Ne, Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix more instances of Eigen problems on RHEL. (`#515 `__) -* Depend on orocos_kdl_vendor (`#473 `__) -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* Fix cpplint errors (`#497 `__) -* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to find the right Python executable. (`#514 `__) -* Depend on orocos_kdl_vendor (`#473 `__) -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* Drop PyKDL dependency in tf2_geometry_msgs (`#509 `__) -* Fix cpplint errors (`#497 `__) -* Export a tf2_geometry_msgs::tf2_geometry_msgs target (`#496 `__) -* Feature: Add doTransform for Wrench messages (`#476 `__) -* Remove some references to the ROS 1 wiki. -* Style fixes in tf2_geometry_msgs. (`#464 `__) -* Fix for issue `#431 `__ - Covariance is not transformed in do_transform_pose_with_covariance_stamped (`#453 `__) -* doTransform non stamped msgs (`#452 `__) -* ``tf2_geometry_msgs``: Fixing covariance transformation in ``doTransform`` (`#430 `__) -* Geometry nitpicks (`#426 `__) -* Conversion tests for toMsg() (`#423 `__) -* Deprecate tf2_geometry_msgs.h (`#418 `__) -* Contributors: Abrar Rahman Protyasha, Bjar Ne, Chris Lalancette, Denis Štogl, Florian Vahl, Jacob Perron, Khasreto, Shane Loretz, vineet131 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Depend on orocos_kdl_vendor (`#473 `__) -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* KDL python formatting and licenses (`#425 `__) -* Deprecate tf2_kdl.h (`#414 `__) -* Contributors: Bjar Ne, Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove dead file from tf2_msgs (`#415 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to finalize tf2_py BufferCore. (`#505 `__) -* Make tf2_py Use FindPython3 (`#494 `__) -* Change TF2Error names to be a bit more descriptive. (`#349 `__) -* Remove python_compat.h (`#417 `__) -* Contributors: Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) -* use dedicated callback group and executor to isolate timer (`#447 `__) -* Adding shared pointer definition to tf2 buffer (`#508 `__) -* fix for a basic logic (`#510 `__) -* Fix precision loss from using rclcpp::Time::seconds() (`#511 `__) -* clear relative callback of Buffer if MessageFilter is destroyed (`#490 `__) -* More info in tf2_echo output (`#468 `__) -* Fix cpplint errors (`#497 `__) -* Fixes for uncrustify 0.72 (`#486 `__) -* More Intuitive CLI for Static Transform Publisher (`#392 `__) -* Reduce transform listener nodes (`#442 `__) -* ``tf2_ros``: Fix deprecated subscriber callbacks (`#448 `__) -* Fix tf2_echo does not work with ros-args (`#407 `__) (`#408 `__) -* Contributors: Abrar Rahman Protyasha, Chen Lihui, Chris Lalancette, Hunter L. Allen, Jacob Perron, Kenji Brameld, PGotzmann, Shane Loretz, Steve Macenski, Zhenpeng Ge, gezp, simulacrus - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Drop PyKDL dependency in tf2_geometry_msgs (`#509 `__) -* Add in one more destroy call that was missed in testing. (`#504 `__) -* Be much more careful about cleanup in the tf2_ros_py tests. (`#499 `__) -* Use the correct type for BufferClient timeout_padding. (`#498 `__) It should be a duration, not a float. -* Update maintainers to Alejandro Hernandez Cordero and Chris Lalancette (`#481 `__) -* Fix buffer_client.py using default timeout_padding (`#437 `__) -* Use underscores instead of dashes in setup.cfg. (`#403 `__) -* Contributors: Audrow Nash, Carlos Andrés Álvarez Restrepo, Chris Lalancette, Florian Vahl - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable mem-access warnings on aarch64. (`#506 `__) -* Fix cpplint errors (`#497 `__) -* Reenable sensor_msgs test (`#422 `__) -* Deprecate tf2_sensor_msgs.h (`#416 `__) -* Contributors: Bjar Ne, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Alejandro Hernandez Cordero and Chris Lalancette (`#481 `__) -* Remove unused import (`#465 `__) -* Adding date-time to frames filename (`#454 `__) -* Use underscores instead of dashes in setup.cfg. (`#403 `__) -* Contributors: Audrow Nash, Hannu Henttinen, Nisala Kalupahana - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} (`#11 `__) -* Export a modern CMake target instead of old-style variables (`#10 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#114 `__) -* Export modern CMake targets (`#110 `__) -* Remove the use of malloc hooks from the tlsf_cpp tests. (`#109 `__) -* Contributors: Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_monitor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) -* Small cleanups to the topic monitor. (`#517 `__) -* Fix topic_monitor for high publication rate (`#461 `__) -* Use is_alive for threads. (`#510 `__) -* Contributors: Audrow Nash, Chris Lalancette, Elias De Coninck - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_statistics_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install includes to include/${PROJECT_NAME} (`#548 `__) -* Additional fixes for documentation in demos. (`#538 `__) -* Fixing deprecated subscriber callback warnings (`#532 `__) -* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} -* Merge branch 'update-mentions-of-tracetools-test' into 'master' Update applicable mentions of tracetools_test to test_tracetools See merge request `ros-tracing/ros2_tracing!259 `__ -* Update applicable mentions of tracetools_test to test_tracetools -* Merge branch 'version-3-1-0' into 'master' Version 3.1.0 See merge request `ros-tracing/ros2_tracing!256 `__ -* Correctly handle calls to TRACEPOINT() macro with no tracepoint args -* Move publisher handle tracepoint argument from rclcpp_publish to rcl_publish -* Add support for rmw init/pub, take, and executor instrumentation -* Export target on Windows and export an interface if TRACETOOLS_DISABLED -* Remove deprecated utility functions -* Contributors: Christophe Bedard, Ivan Santiago Paunovic, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable kernel tracing by default -* Don't require kernel tracer and detect when it's not installed -* Add support for preloading pthread and dl instrumentation shared libs -* Remove profile_fast option and consider LD_PRELOADing both libs -* Improve event matching for shared lib preloading -* Improve LdPreload action's lib-finding function and add proper tests -* Fix multiple LdPreload actions not working and add test -* Deprecate 'context_names' param and replace with 'context_fields' -* Support per-domain context fields for the Trace action -* Improve LdPreload.get_shared_lib_path() for when a static lib may exist -* Move some tests from tracetools_launch to test_tracetools_launch -* Expose Trace action as frontend action and support substitutions -* Contributors: Christophe Bedard, Ingo Lütkebohle - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow providing additional actions for TraceTestCase -* Remove default value for 'package' kwarg for TraceTestCase -* Move actual tests out of tracetools_test to new test_tracetools package -* Add tests for rmw init/pub, take, and executor instrumentation -* Add field type assertion utilities to TraceTestCase -* Fixing deprecated subscriber callback warnings -* Contributors: Abrar Rahman Protyasha, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable kernel tracing by default -* Don't require kernel tracer and detect when it's not installed -* Introduce constants for tracepoint names -* Optimize default tracing session channel config values -* Deprecate 'context_names' param and replace with 'context_fields' -* Support per-domain context fields for the Trace action -* Add support for rmw init/pub, take, and executor tracepoints -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`trajectory_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Contributors: Audrow Nash, Grey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`turtlesim `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use ``double`` when handling ``qreal orient\_`` (`#114 `__) -* Add Rolling Icon (`#133 `__) -* Update maintainers to Audrow Nash and Michael Jeronimo (`#137 `__) -* Fixing deprecated subscriber callback warnings (`#134 `__) -* Use rosidl_get_typesupport_target() (`#132 `__) -* Print out the correct node name on startup. (`#122 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Katherine Scott, Seulbae Kim, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} (`#31 `__) -* Add linter tests and fix errors (`#30 `__) -* Add in a Doxyfile to predefine macros. (`#28 `__) -* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf_parser_plugin `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Install headers to include/${PROJECT_NAME} (`#31 `__) -* Add linter tests and fix errors (`#30 `__) -* Contributors: Jacob Perron, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`visualization_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Interface packages should fully on the interface packages that they depend on (`#173 `__) -* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) -* Marker Textures (`#153 `__) -* Document namespace scoped marker deletion. (`#151 `__) -* Contributors: Audrow Nash, Greg Balke, Grey, Michel Hidalgo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`yaml_cpp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing dependency on yaml-cpp (`#32 `__) -* Upgrade to yaml-cpp 0.7.0 (`#25 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`zstd_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version number to avoid conflict -* Use git hash for zstd vendor (`#969 `__) -* Update package maintainers (`#899 `__) -* Declare missing dependency on 'git' in zstd_vendor (`#890 `__) -* Switch to using 'git apply' for zstd_vendor patches (`#846 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Michel Hidalgo, Scott K Logan, Shane Loretz +.. redirect-from:: + + Releases/Humble-Hawksbill-Complete-Changelog + +Humble Hawksbill changelog +========================== + +This page is a list of the complete changes in all ROS 2 core packages since the previous release. + +.. contents:: Table of Contents + :local: + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`actionlib_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* remove google style from clang-tidy default settings, removing need for default config file (`#337 `__) +* Improvements to ament_lint_clang_tidy. (`#316 `__) +* Contributors: Audrow Nash, Steven! Ragnarök, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Add ament_cmake_gen_version_h package (`#198 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz, serge-nikulin + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Fix typo in ament_auto_find_test_dependencies (`#363 `__) +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Add ament_auto_add_gtest (`#344 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Daisuke Nishimatsu, Joshua Whitley, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Improvements to ament_lint_clang_tidy. (`#316 `__) +* Contributors: Audrow Nash, Steven! Ragnarök + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Increase the ament_cmake_copyright default timeout. (`#355 `__) +* Update forthcoming version in changelogs +* [ament_cmake_copyright] Add file exclusion support (`#328 `__) * [ament_cmake_copyright] Add file exclusion support In the ``ament_copyright`` CMake function, the optional list argument ``EXCLUDE`` can now be used as an exclusion specifier. * [ament_cmake_copyright] Fix function header typo Remove reference to ``cppcheck`` in the ``EXCLUDE`` arg description. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Support commands with executable targets (`#352 `__) +* doc/resource_index: Indent list subitems correctly (`#342 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Michal Sojka, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* [ament_cmake_cppcheck] Fix file exclusion behavior (`#329 `__) The ``EXCLUDE`` argument of the ``ament_cppcheck`` CMake function is a list, i.e. a multi-value keyword. As such, it needs to be placed out of the one-value keywords from the ``cmake_parse_arguments`` function call. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Add cppcheck libraries option (`#323 `__) * adding ament_cppcheck libraries option * pass libraries option via CMake Co-authored-by: William Wedler +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Will + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_definitions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Add note regarding interface libraries (`#339 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Bjar Ne, Chris Lalancette, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_link_flags `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_targets `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Add custom config file support for flake8 (`#331 `__) +* Contributors: Audrow Nash, Kenji Miyake + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gen_version_h `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_generate_version_header and deprecate ament_cmake_gen_version_h (`#377 `__) +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Add ament_cmake_gen_version_h package (`#198 `__) +* Contributors: Audrow Nash, Shane Loretz, serge-nikulin + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gmock `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_google_benchmark `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gtest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Make ament_include_directories_order a function to allow paths with backslashes on windows. (`#371 `__) * Repalce backslashes with forward slashes on Windows * Typo * Replace slashes in ARGN * Don't quote * Check ARGN has values before trying to string(REPLACE them * Make ament_include_directories_order a function +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_nose `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Support commands with executable targets (`#352 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Fix misleading comment (`#361 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Support commands with executable targets (`#352 `__) +* Mention other platforms in 'pytest/pytest-cov not found' warning (`#337 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Christophe Bedard, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use sysconfig directly to determine python lib dir (`#378 `__) +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Make ament_cmake_python symlink for symlink installs only (`#357 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Make ament_python_install_package() match setuptools' egg names. (`#338 `__) +* Drop ament_cmake_python outdated tests. (`#340 `__) +* Update maintainers (`#336 `__) +* Make ament_python_install_package() install console_scripts (`#328 `__) +* Contributors: Audrow Nash, Chris Lalancette, Michel Hidalgo, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Refactor domain_coordinator API to use a context manager (`#12 `__) +* Contributors: Timo Röhling + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_target_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Fix bug packages with multiple configurations (`#318 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Resolve various ament_lint linter violations (`#360 `__) We can't add ament_lint linters in ament_cmake in the traditional way without creating a circular dependency between the repositories. Even though we can't automatically enforce linting, it's still a good idea to try to keep conformance where possible. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* [ament_cmake_uncrustify] Add file exclude support (`#330 `__) In the ``ament_uncrustify`` CMake function, the optional list argument ``EXCLUDE`` can now be used as an exclusion specifier. +* Contributors: Abrar Rahman Protyasha, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_version `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelog +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#362 `__) +* Use FindPython3 instead of FindPythonInterp (`#355 `__) +* Update maintainers (`#336 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix importlib_metadata warning on Python 3.10. (`#365 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. +* Add SPDX identifiers to the licenses. (`#315 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable cppcheck 2.x. (`#345 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Add cppcheck libraries option (`#323 `__) * adding ament_cppcheck libraries option * pass libraries option via CMake Co-authored-by: William Wedler +* Contributors: Audrow Nash, Chris Lalancette, Will + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ignore NOLINT comments with categories that come from clang-tidy (`#339 `__) +* Update forthcoming version in changelogs +* Reapply patches Reapply parts of 232428752251de61e84ef013bcd643e35eb9038d that are still relevant. +* Update cpplint version Point to the fork https://github.com/cpplint/cpplint Contains updates for modern C++ standards (e.g. C++14 and C++17). +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Dirk Thomas, Jacob Perron, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove use of distutils.version.LooseVersion. (`#346 `__) +* Update forthcoming version in changelogs +* Ignore .*/_* dirs in ament_flake8 (`#335 `__) Other ament\_* linters specifically ignore directories starting with a dot or underscore when crawling for files to lint. They also do so implicitly, so this change mimics that same pattern so that the behavior is consistent. +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Ignore flake8-blind-except B902 (`#292 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/ (`#83 `__) +* Remove ament_export_include_directories and ament_export_libraries (`#81 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Print warning when get_package_share_directory() does not exist (Fix `#74 `__) (`#77 `__) +* Fail lookups on invalid resource names (`#69 `__) +* Add get_package_share_path method (`#73 `__) +* Contributors: David V. Lu, rob-clarke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. +* Contributors: Abrar Rahman Protyasha, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Fix typo in ament_lint_common/package.xml (`#336 `__) +* Contributors: Audrow Nash, Kenji Miyake + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set forthcoming for previous version +* Add support for appending to environment variables (`#130 `__) This works largely the same as 'prepend-non-duplicate', but instead puts the candidate value at the end of the target variable. +* Update maintainers to Audrow Nash (`#135 `__) +* Make python executable variable ament_package specific (`#134 `__) +* Contributors: Audrow Nash, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* [ament_copyright] Fix file exclusion behavior (`#327 `__) * [ament_copyright] Fix file exclusion behavior This commit fixes the faulty file exclusion behavior reported in https://github.com/ament/ament_lint/issues/326. Specifically, the exclusion list is matched against traversed files in the ``crawler`` module. Changes inspired by https://github.com/ament/ament_lint/pull/299/. * Update excluded file path in copyright tests Since file names are not indiscriminately matched throughout the search tree anymore, the excluded files listed in the copyright tests need to be updated relative to the root of the package. * Add test cases to check exclusion behavior Specifically, these tests check for: - Incorrect exclusion of single filenames. - Correct exclusion of relatively/absolutely addressed filenames. - Correct exclusion of wildcarded paths. * Add unit tests for crawler module These unit tests make sure both search and exclusion behaviors are correctly demonstrated by the ``ament_copyright.crawler`` module. +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Remove use of distutils.version.LooseVersion. (`#346 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve documentation by clarifying the purpose of different tools (`#357 `__) +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash, Bi0T1N + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* [ament_uncrustify] Fix file exclusion behavior (`#334 `__) * [ament_uncrustify] Fix file exclusion behavior This PR fixes the file exclusion behavior reported in `#326 `__. Specifically, the exclusion list is matched against files/directories as the search path is traversed. Tries to maintain consistency with `#327 `__. * [ament_uncrustify] Add file exclusion tests * [ament_uncrustify] Remove erroneous pytest marker +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* [ament_uncrustify] Add ament_lint tests (`#338 `__) * Add ``ament_lint`` tests on ``ament_uncrustify`` * Address linter warnings in ``ament_uncrustify`` +* Contributors: Abrar Rahman Protyasha, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update forthcoming version in changelogs +* Update maintainers to Michael Jeronimo and Michel Hidalgo (`#340 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`builtin_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_calibration_parsers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Tests depend on rcpputils (`#236 `__) +* Remove YAML_CPP_DLL define (`#231 `__) +* Export a modern CMake target instead of variables and install includes to include/${PROJECT_NAME} (`#218 `__) +* Update maintainers (`#173 `__) +* Contributors: Akash, Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_info_manager `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Export a modern CMake target instead of variables and install includes to include/${PROJECT_NAME} (`#218 `__) +* Update maintainers (`#173 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`class_loader `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/ (`#191 `__) +* Fix include order for cpplint (`#192 `__) +* Update maintainers to Geoffrey Biggs and Michael Carroll (`#190 `__) +* Fix spelling mistake (`#184 `__) +* Contributors: Audrow Nash, David V. Lu!!, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`common_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Fixing deprecated subscriber callback warnings (`#532 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Add how to fix the most vexing parse problem (`#541 `__) * use uniform initialization +* Fixing deprecated subscriber callback warnings (`#532 `__) +* Update talker_loaned_message.cpp (`#518 `__) +* Revert "Use sizeof(char) in place for sizeof(void) (`#515 `__)" (`#516 `__) +* change how serialized message works with subscription (`#497 `__) +* Use sizeof(char) in place for sizeof(void) (`#515 `__) +* Fix small print issue in allocator tutorial. (`#509 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Michel Hidalgo, Tomoya Fujita, William Woodall, Zongbao Feng + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp_native `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Fix typo in demo_nodes_cpp_native package description (`#536 `__) +* Contributors: Audrow Nash, Víctor Mayoral Vilches + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanups in demo_nodes_py. (`#555 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Fixed typo executor -> executors (`#542 `__) +* Update python nodes SIGINT handling (`#539 `__) +* Contributors: Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, ori155 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`diagnostic_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`domain_coordinator `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Michel Hidalgo (`#13 `__) +* Refactor domain_coordinator API to use a context manager (`#12 `__) +* Contributors: Audrow Nash, Timo Röhling + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_map_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_robot_bringup `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_sensors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`example_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Mabel Zhang (`#15 `__) +* Add changelog (`#14 `__) +* Contributors: Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_async_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Add example of how to prune old requests in client API (`#322 `__) +* Contributors: Aditya Pande, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_cbg_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve scheduling configuration of examples_rclcpp_cbg_executor package (`#331 `__) +* Added jitter measurement to examples_rclcpp_cbg_executor. (`#328 `__) +* Fix deprecated subscriber callbacks (`#323 `__) +* Remove use of get_callback_groups(). (`#320 `__) +* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Ralph Lange + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Add example of how to prune old requests in client API (`#322 `__) +* Contributors: Aditya Pande, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add an example about how to use wait_for_all_acked (`#316 `__) +* Updated maintainers (`#329 `__) +* Add try&catch statement to unique network flow publisher example (`#313 `__) +* Add type adaption example (`#300 `__) +* Contributors: Aditya Pande, Audrow Nash, Barry Xu, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use ``const&`` signature for read-only sub callbacks (`#337 `__) +* Updated maintainers (`#329 `__) +* Fix deprecated subscriber callbacks (`#323 `__) +* Add wait set examples (`#315 `__) +* Add type adaption example (`#300 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, carlossvg + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_timer `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_multithreaded_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#329 `__) +* Fix deprecated subscriber callbacks (`#323 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_wait_set `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add wait set examples (`#315 `__) +* Contributors: carlossvg + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_executors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Update python nodes sigint/sigterm handling (`#330 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_guard_conditions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) * Updated maintainers * Removed author +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_pointcloud_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Alejandro Hernandez Cordero and Chris Lalancette (`#481 `__) +* Use underscores instead of dashes in setup.cfg. (`#403 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`fastrtps_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Shane Loretz (`#83 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`google_benchmark_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add git buildtool dependency. +* Use git hash for google_benchmark_vendor (`#20 `__) +* Update to google benchmark version 1.6.1 (`#19 `__) +* Update maintainers to Audrow Nash (`#18 `__) +* Update google_benchmark to v1.5.3 (`#16 `__) 1. Change google_benchmark version from v1.5.2 to v1.5.3. Because v1.5.2 can not build with GCC 11 2. Removed shrink-tz-offset-size.patch because of this patch was merged in google-benchmark repo. +* Add changelog (`#15 `__) +* Shrink the size of the tz_offset variable. (`#13 `__) +* Update the patching to work on Windows without admin. (`#11 `__) +* Always preserve source permissions in vendor packages. (`#12 `__) +* Update package maintainers. (`#10 `__) +* Upgrade google benchmark from v1.5.1 to v1.5.2 to include QNX patch. (`#9 `__) +* Set the SOVERSION on benchmark libraries. (`#8 `__) +* Set minimum criteria for system package. (`#3 `__) +* Work around warnings building Google Benchmark w/Clang. (`#2 `__) +* Initial google_benchmark_vendor package. (`#1 `__) +* Initial commit. +* Contributors: Ahmed Sobhy, Audrow Nash, Chris Lalancette, Homalozoa X, Ivan Santiago Paunovic, Michel Hidalgo, Scott K Logan, Shane Loretz, Steven! Ragnarök + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#548 `__) +* Fix include order and relative paths for cpplint (`#551 `__) +* Reduce the number of OpenCV libraries image_tools links against. (`#549 `__) +* Adds copy constructor and assignment operator to ROSCvMatContainer (`#546 `__) +* Fixes for uncrustify 0.72 (`#545 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Fixing deprecated subscriber callback warnings (`#532 `__) +* ambigulity: unknown type name 'nullptr_t' (`#528 `__) +* Add type masquerading demos (`#482 `__) +* Add support for visualizing yuv422 (`#499 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Gonzo, Jacob Perron, Shane Loretz, William Woodall, joshua-qnx, xwnb + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Image transport publisher crash fixes (`#235 `__) +* Simple IT plugins shutdown (`#225 `__) +* Remove PLUGINLIB__DISABLE_BOOST_FUNCTIONS definition. (`#226 `__) +* Fix include order for cpplint (`#221 `__) Relates to https://github.com/ament/ament_lint/pull/324 +* Export a modern CMake target instead of variables and install includes to include/${PROJECT_NAME} (`#218 `__) +* Fix SimpleSubscriberPlugin (`#195 `__) +* Make sure to mark overridden methods as 'override'. (`#192 `__) +* Expose subscription options (`#186 `__) +* fix mistyping 'cammera_publisher.hpp -> camera_publisher.hpp' (`#177 `__) +* Update maintainers (`#173 `__) +* make CameraPublisher::getNumSubscribers() work (`#163 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Hye-Jong KIM, Ivan Santiago Paunovic, Jacob Perron, Michael Ferguson, RoboTech Vision, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`interactive_markers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Do not publish if context is invalid during shutdown (`#89 `__) +* Install includes to include/ and misc CMake fixes (`#85 `__) +* Fix deprecation warning introduced after client API update (`#83 `__) +* Fix deprecated sub callback warnings (`#84 `__) +* Include tf2_geometry_msgs.hpp instead of the h file. (`#82 `__) +* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`intra_process_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add opencv_imgproc dependency for cv::putText (`#554 `__) +* Install includes to include/${PROJECT_NAME} (`#548 `__) +* Fix include order and relative paths for cpplint (`#551 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Fixing deprecated subscriber callback warnings (`#532 `__) +* Revert "Add type masquerading demos (`#482 `__)" (`#520 `__) +* Add type masquerading demos (`#482 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Jacob Perron, Shane Loretz, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`kdl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Depend on orocos-kdl vendor packages (`#58 `__) +* Install includes to include/ and misc CMake fixes (`#61 `__) +* Update to uncrustify 0.72 (`#60 `__) +* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`laser_geometry `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} (`#86 `__) +* Explicit cast to double to prevent loss of precision +* Fix Duration casting issue leading to no undistortion +* Fix building on running on Windows Debug (`#82 `__) +* Update python code and tests for ros2 (`#80 `__) +* Contributors: Chris Lalancette, Jonathan Binney, Marco Lampacrescia, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Sandbox environment in tests to fix repeated job failures (`#609 `__) +* Start Python faster in test_execute_processs_shutdown to avoid flakey failures (`#608 `__) +* Fix warnings from importlib_metdata on Python 3.10. (`#606 `__) +* Add boolean substitutions (`#598 `__) +* Support scoping environment variables (`#601 `__) +* Fix awaiting shutdown in launch context (`#603 `__) +* Fix parse respawn var (`#569 `__) +* Make the logged command pretty in ExecuteLocal (`#594 `__) +* 'output' is expanded as a substitution in XML/YAML files (`#577 `__) +* Skip warning test if warning already happend (`#585 `__) +* Use asyncio.wait with timeout rather than sleep (`#576 `__) +* Make test_parser compatible with Python older than 3.8 (`#575 `__) +* Propagate exceptions of completed actions to launch service main loop (`#566 `__) +* Warn when loading launch extensions fails (`#572 `__) +* Add in two fixes for Jammy (`#571 `__) +* Evaluate math symbols and functions in python expression (`#557 `__) +* Document TimerAction params (`#558 `__) +* Improve launch arguments introspection (`#556 `__) +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* Updated maintainers (`#555 `__) +* First prototype of native pytest plugin for launch based tests (`#528 `__) +* Allow for raw path specification in IncludeLaunchDescription (`#544 `__) +* Adding Executable description class (`#454 `__) +* event handlers: Allow to match the target action with a callable and not only with an object instance (`#540 `__) +* Add AppendEnvironmentVariable action (`#543 `__) +* Document EnvironmentVariable substitution resolution context caveat (`#541 `__) +* Feature clear launch configs (`#515 `__) +* Add examples to ExecuteProcess docs (`#525 `__) +* Fix ``DeclareLaunchArgument`` xml parsing and constructor (`#529 `__) +* Fix pytest run on Windows (`#526 `__) +* Improving docs (`#523 `__) +* Add filtering mechanism for executable prefix application (`#522 `__) +* Make each parser extension provide a set of file extensions (`#516 `__) +* Add missing exec dependency on PyYAML (`#493 `__) +* Refactor TimerAction to allow RosTimer to extend (`#512 `__) +* Improve (Not)Equals condition type hinting (`#510 `__) +* Contributors: Aditya Pande, Audrow Nash, Cameron Miller, Chris Lalancette, Christophe Bedard, David V. Lu!!, Derek Chopp, HMellor, Immanuel Martini, Ivan Santiago Paunovic, Jacob Perron, Kenji Miyake, Khush Jain, Kosuke Takeuchi, Rebecca Butler, Scott K Logan, Shane Loretz, roger-strain, tumtom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* [launch_pytest] Modify how wait_for_output()/wait_for_stderr() work, add assert\_*() alternatives (`#553 `__) +* Updated maintainers (`#555 `__) +* * [launch_pytest] Fix issue when colcon --retest-until-fail flag is used (`#552 `__) +* First prototype of native pytest plugin for launch based tests (`#528 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix importlib_metadata warning on Python 3.10. (`#307 `__) +* Use correct namespace when evaluating parameter files for composable nodes (`#303 `__) +* Handle empty strings when evaluating parameters (`#300 `__) +* Add parameter substitution (`#297 `__) +* fix bug in warning when an entry point fails to load (`#243 `__) +* More Helpful Error Messages (`#275 `__) +* Update maintainers in setup.py (`#287 `__) +* Set parameters from file for composable nodes (`#281 `__) +* Update package maintainers (`#284 `__) +* Update node name matcher (`#282 `__) +* Support both parameter file configurations for composable nodes (`#259 `__) +* Handle substitutions in RosTimer (`#264 `__) +* Add SetParametersFromFile action (`#260 `__) +* Properly support ros_args attribute through launch frontends (`#253 `__) +* Add 'push_ros_namespace' alias to 'push-ros-namespace' (`#250 `__) +* Add ros_arguments option to Node action (`#249 `__) +* Refactor RosTimer to extend TimerAction (`#248 `__) +* ROS Timer Action (`#244 `__) +* Support container in frontend (`#235 `__) +* Fix a small typo in a comment (`#237 `__) +* Better document parameter handling in Node (`#234 `__) +* Make 'ros2 launch' work again. (`launch #201 `__) +* Added LaunchLogger class (`launch #145 `__) +* Changed logger.warn (deprecated) to logger.warning. (`launch #199 `__) +* Added Plumb rclpy.init context to get_default_launch_description. (`launch #193 `__) +* Added normalize_parameters and evaluate_paramters. (`launch #192 `__) +* Added normalize_remap_rule and types. (`launch #173 `__) +* Renamed transitions to match changes in ``lifecycle_msgs`` (`launch #153 `__) +* Added support for passing parameters as a dictionary to a Node (`launch #138 `__) +* Made various fixes and added tests for remappings passed to Node actions (`launch #137 `__) +* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Christophe Bedard, David V. Lu!!, Felix Divo, Jacob Perron, Kenji Miyake, Michel Hidalgo, Rebecca Butler, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed the deprecated ``ready_fn`` feature (`#589 `__) +* Added case for instances of ExecuteLocal in resolveProcess function (`#587 `__) +* Add compatitibility with pytest 7 (`#592 `__) +* Renamed three files from example_processes (`#573 `__) +* Fix launch_testing README.md proc keyword to process. (`#554 `__) (`#560 `__) +* Declare frontend group dependency & use explicit dependencies in launch_testing (`#520 `__) +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* Updated maintainers (`#555 `__) +* First prototype of native pytest plugin for launch based tests (`#528 `__) +* Adding Executable description class (`#454 `__) +* Add a "hello world" style example (`#532 `__) +* Contributors: Aditya Pande, Audrow Nash, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Khush Jain, Matt Lanting, Shane Loretz, William Woodall, roger-strain + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [launch_testing_ament_cmake] Add test label (`#584 `__) +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* Updated maintainers (`#555 `__) +* Contributors: Aditya Pande, Audrow Nash, Keisuke Shima + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_examples `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Readded WaitForTopics utility (`#333 `__) +* Final batch of examples (`#327 `__) +* Update maintainers to Aditya Pande and Shane Loretz (`#332 `__) +* Updated maintainers (`#329 `__) +* Reverted WaitForTopics utility usage (`#326 `__) +* Moved examples (`#324 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ``hz`` param to ``talker.py`` to fix wait_for_topic_launch_test (`#309 `__) +* Revert WaitForTopics (`#288 `__) +* Update maintainers in setup.py (`#287 `__) +* Move pytest entrypoints to own module (`#278 `__) +* Update package maintainers (`#284 `__) +* Check that future is done, and always call rclpy.shutdown (`#273 `__) +* Revert "launch testing : Wait for topics to publish (`#274 `__)" (`#276 `__) +* Add WaitForTopics utility for waiting on publishers (`#274 `__) +* Remove unused code, Future.result() already raises (`#270 `__) +* Add timeout to wait for service response in example (`#271 `__) +* Add examples (`#263 `__) +* Contributors: Aditya Pande, Audrow Nash, Jacob Perron, Jorge Perez, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_xml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix sphinx directive to cross-ref Launch method (`#605 `__) +* Add boolean substitutions (`#598 `__) +* Support scoping environment variables (`#601 `__) +* 'output' is expanded as a substitution in XML/YAML files (`#577 `__) +* Declare frontend group dependency & use explicit dependencies in launch_testing (`#520 `__) +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* Updated maintainers (`#555 `__) +* Add AppendEnvironmentVariable action (`#543 `__) +* Feature clear launch configs (`#515 `__) +* Fix ``DeclareLaunchArgument`` xml parsing and constructor (`#529 `__) +* Add 'launch' to sets of launch file extensions (`#518 `__) +* Make each parser extension provide a set of file extensions (`#516 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, Christophe Bedard, Derek Chopp, Ivan Santiago Paunovic, Jacob Perron, Kenji Miyake, Khush Jain + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_yaml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix sphinx directive to cross-ref Launch method (`#605 `__) +* Add boolean substitutions (`#598 `__) +* Support scoping environment variables (`#601 `__) +* 'output' is expanded as a substitution in XML/YAML files (`#577 `__) +* Declare frontend group dependency & use explicit dependencies in launch_testing (`#520 `__) +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* Updated maintainers (`#555 `__) +* Add AppendEnvironmentVariable action (`#543 `__) +* Feature clear launch configs (`#515 `__) +* Add 'launch' to sets of launch file extensions (`#518 `__) +* Make each parser extension provide a set of file extensions (`#516 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, Christophe Bedard, Derek Chopp, Jacob Perron, Kenji Miyake, Khush Jain + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libcurl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to curl 7.81. (`#74 `__) +* Update maintainers (`#66 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libstatistics_collector `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump pascalgn/automerge-action from 0.14.3 to 0.15.2 +* Bump ros-tooling/setup-ros from 0.2.2 to 0.3.0 +* Bump actions/upload-artifact from 2.3.1 to 3 +* Bump actions/upload-artifact from 2.2.4 to 2.3.1 +* Bump actions/checkout from 2 to 3 +* Bump ros-tooling/setup-ros from 0.2.1 to 0.2.2 (`#123 `__) +* Install includes to include/${PROJECT_NAME} (`#122 `__) +* Bump codecov/codecov-action from 2.0.3 to 2.1.0 +* Bump pascalgn/automerge-action from 0.14.2 to 0.14.3 +* Bump codecov/codecov-action from 2.0.2 to 2.0.3 +* Use rosidl_get_typesupport_target() (`#116 `__) +* Bump codecov/codecov-action from 2.0.1 to 2.0.2 +* Bump codecov/codecov-action from 1.5.2 to 2.0.1 +* Bump actions/upload-artifact from 1 to 2.2.4 +* Bump codecov/codecov-action from 1.5.1 to 1.5.2 +* Bump codecov/codecov-action from 1.3.1 to 1.5.1 +* Bump ros-tooling/setup-ros from 0.2.0 to 0.2.1 +* Bump pascalgn/automerge-action from 0.14.1 to 0.14.2 +* Bump ros-tooling/setup-ros from 0.1 to 0.2.0 +* Bump pascalgn/automerge-action from 0.13.1 to 0.14.1 +* Fix autoapprove +* Package.json explicitly owned by emerson to minimize notifications +* Bump hmarr/auto-approve-action from v2.0.0 to v2.1.0 +* Bump codecov/codecov-action from v1.2.1 to v1.3.1 +* Contributors: Chris Lalancette, Emerson Knapp, Shane Loretz, dependabot[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libyaml_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add a buildtool dependency on git. (`#48 `__) +* Install headers to include/${PROJECT_NAME} (`#46 `__) +* Merge pull request `#43 `__ from ros2/update-maintainers +* Update maintainers to Audrow Nash +* Contributors: Audrow Nash, Shane Loretz, Steven! Ragnarök + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make lifecycle demo automatically exit when done (`#558 `__) +* Use default on_activate()/on_deactivate() implemenetation of Node (`#552 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Fix use of future in lifecycle demo (`#534 `__) +* Fixing deprecated subscriber callback warnings (`#532 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Christophe Bedard, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Create changelog for lifecycle_py +* Add rclpy lifecycle demo (`#547 `__) +* Contributors: Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`logging_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Use rosidl_get_typesupport_target() (`#529 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`message_filters `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use RCL_ROS_TIME for message_traits::TimeStamp (`#72 `__) +* Install includes to include/${PROJECT_NAME} (`#71 `__) +* Update maintainers (`#67 `__) +* Suppress rclcpp deprecation warnings in unit tests (`#62 `__) +* Add missing overrides to subscriber.h (`#60 `__) +* Add lifecycle node support (`#59 `__) +* Correct package.xml and CMakeLists.txt (`#58 `__) +* Expose Subscription Options - V2 (`#56 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Hunter L. Allen, Kenji Brameld, Michel Hidalgo, Rebecca Butler, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mimick_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* support pi zero (`#24 `__) +* Update maintainers to Geoffrey Biggs (`#23 `__) +* Update to latest commit for Apple M1 support (`#20 `__) +* Contributors: Audrow Nash, Brett Downing, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`nav_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_control `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix include order and relative paths for cpplint (`#551 `__) +* Remove the malloc_hook from the pendulum_demo. (`#544 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Fix documentation for pendulum_control. (`#537 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pluginlib `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} and remove ament_target_dependencies calls (`#226 `__) +* Require (`#225 `__) +* Move LibraryLoadExceptions down a level for more accurate error messages (`#221 `__) +* Update maintainers to Chris Lalancette (`#223 `__) +* extend termination condition to avoid infinite loop if package.xml is not found (`#220 `__) +* Remove deprecated headers. (`#217 `__) +* Contributors: Alberto Soragna, Audrow Nash, Chris Lalancette, David V. Lu!!, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pybind11_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use sha256 hash instead of tag (`#12 `__) +* Install headers to include/${PROJECT_NAME} (`#11 `__) +* Update pybind11 to 2.7.1. (`#10 `__) This is the version that is shipped in Ubuntu 22.04. +* Contributors: Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* require Python 3.6 as we use format strings in various places (`#10 `__) +* Document all variables set by this module (`#5 `__) +* Add changelog (`#4 `__) +* Contributors: Ivan Santiago Paunovic, Shane Loretz, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include${PROJECT_NAME} (`#259 `__) +* Export targets instead of old-style CMake variables (`#257 `__) +* FindPython3 explicitly instead of FindPythonInterp implicitly (`#254 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#548 `__) +* Fix include order and relative paths for cpplint (`#551 `__) +* Fixes for uncrustify 0.72 (`#545 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Fixing deprecated subscriber callback warnings (`#532 `__) +* Initialize message correctly (`#522 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Update python nodes SIGINT handling (`#539 `__) +* Contributors: Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add content-filtered-topic interfaces (`#894 `__) +* Add additional null check for timer argument (`#973 `__) +* Allow forward slashes within a parameter name rule in argument parsing (`#860 `__) +* Suppress false positive from clang-tidy (`#951 `__) +* Fix missing terminating \0 in rcl_context_impl_t.argv (`#969 `__) +* test_publisher_wait_all_ack depends on rcpputils (`#968 `__) +* Micro-optimizations in rcl (`#965 `__) +* If timer canceled, rcl_timer_get_time_until_next_call returns TIMER_CANCELED (`#963 `__) +* Add Events Executor (`#839 `__) +* Remove fastrtps customization on test_events (`#960 `__) +* Add client/service QoS getters (`#941 `__) +* introduce ROS_DISABLE_LOAN_MSG to disable can_loan_messages. (`#949 `__) +* Install includes it include/${PROJECT_NAME} (`#959 `__) +* Make rcl_difference_times args const (`#955 `__) +* Update inject_on_return test skipping logic (`#953 `__) +* Fix jump callbacks being called when zero time jump thresholds used (`#948 `__) +* Only change the default logger level if default_logger_level is set (`#943 `__) +* Add Library for wait_for_entity_helpers to deduplicate compilation (`#942 `__) +* Increase Windows timeout 15 -> 25 ms (`#940 `__) +* test should check specified number of entities. (`#935 `__) +* Fix up documentation build for rcl when using rosdoc2 (`#932 `__) +* Include rmw_event_t instead of forward declaring it (`#933 `__) +* Add rcl_publisher_wait_for_all_acked support. (`#913 `__) +* Add tracing instrumentation for rcl_take. (`#930 `__) +* Fix #include in C++ typesupport example in rcl_subscription_init docblock. (`#927 `__) +* Update includes after rcutils/get_env.h deprecation. (`#917 `__) +* Use proper rcl_logging return value type and compare to constant. (`#916 `__) +* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Haowei Wen, Ivan Santiago Paunovic, Jafar Abdi, Michel Hidalgo, Miguel Company, NoyZuberi, Scott K Logan, Shane Loretz, Tomoya Fujita, William Woodall, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add Events Executor (`#839 `__) +* Install includes it include/${PROJECT_NAME} (`#959 `__) +* Fix up documentation build for rcl_action when using rosdoc2 (`#937 `__) +* Fix expired goals capacity of action server (`#931 `__) +* Wait for action server in rcl_action comm tests. (`#919 `__) +* Contributors: Michel Hidalgo, Shane Loretz, iRobot ROS, spiralray + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes it include/${PROJECT_NAME} (`#959 `__) +* [rcl_lifecycle] Do not share transition event message between nodes (`#956 `__) +* Update maintainers to Ivan Paunovic and William Woodall (`#952 `__) +* Fix up documentation build for rcl_lifecycle when using rosdoc2 (`#938 `__) +* Rename variable to fix name shadowing warning (`#929 `__) +* Contributors: Alberto Soragna, Audrow Nash, Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#85 `__) +* Fix include order for cpplint (`#84 `__) Relates to https://github.com/ament/ament_lint/pull/324 +* Update maintainers to Chris Lalancette (`#83 `__) +* Fix renamed ``rcpputils`` header (`#81 `__) +* Add Doxyfile to rcl_logging_interface package (`#80 `__) +* Update includes after rcutils/get_env.h deprecation (`#75 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Christophe Bedard, Jacob Perron, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_noop `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#83 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_spdlog `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix include order for cpplint (`#84 `__) Relates to https://github.com/ament/ament_lint/pull/324 +* Update maintainers to Chris Lalancette (`#83 `__) +* Fix renamed ``rcpputils`` header (`#81 `__) +* Update includes after rcutils/get_env.h deprecation (`#75 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Christophe Bedard, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_yaml_param_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes it include/${PROJECT_NAME} (`#959 `__) +* Update maintainers to Ivan Paunovic and William Woodall (`#952 `__) +* Tweak rcl_yaml_param_parser documentation (`#939 `__) +* Contributors: Audrow Nash, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* remove DEFINE_CONTENT_FILTER cmake option (`#1914 `__) +* remove things that were deprecated during galactic (`#1913 `__) +* add take_data_by_entity_id API to waitable (`#1892 `__) +* add content-filtered-topic interfaces (`#1561 `__) +* [NodeParameters] Set name in param info pre-check (`#1908 `__) +* Add test-dep ament_cmake_google_benchmark (`#1904 `__) +* Add publish by loaned message in GenericPublisher (`#1856 `__) +* Add missing ament dependency on rcl_interfaces (`#1903 `__) +* Update data callback tests to account for all published samples (`#1900 `__) +* Increase timeout for acknowledgments to account for slower Connext settings (`#1901 `__) +* clang-tidy: explicit constructors (`#1782 `__) +* Add client/service QoS getters (`#1784 `__) +* Fix a bunch more rosdoc2 issues in rclcpp. (`#1897 `__) +* time_until_trigger returns max time if timer is cancelled (`#1893 `__) +* Micro-optimizations in rclcpp (`#1896 `__) +* spin_all with a zero timeout. (`#1878 `__) +* Add RMW listener APIs (`#1579 `__) +* Remove fastrtps customization on tests (`#1887 `__) +* Install headers to include/${PROJECT_NAME} (`#1888 `__) +* Use ament_generate_version_header (`#1886 `__) +* use universal reference to support rvalue. (`#1883 `__) +* fix one subscription can wait_for_message twice (`#1870 `__) +* Add return value version of get_parameter_or (`#1813 `__) +* Cleanup time source object lifetimes (`#1867 `__) +* add is_spinning() method to executor base class +* Cleanup the TypeAdapt tests (`#1858 `__) +* Cleanup includes (`#1857 `__) +* Fix include order and relative paths for cpplint (`#1859 `__) +* Rename stringstream in macros to a more unique name (`#1862 `__) +* Add non transform capabilities for intra-process (`#1849 `__) +* Fix rclcpp documentation build (`#1779 `__) +* Use UninitializedStaticallyTypedParameterException (`#1689 `__) +* Add wait_for_all_acked support (`#1662 `__) +* Add tests for function templates of declare_parameter (`#1747 `__) +* Fixes for uncrustify 0.72 (`#1844 `__) +* use private member to keep the all reference underneath. (`#1845 `__) +* Make node base sharable (`#1832 `__) +* Add Clock::sleep_for() (`#1828 `__) +* Synchronize rcl and std::chrono steady clocks in Clock::sleep_until (`#1830 `__) +* Use rclcpp::guard_condition (`#1612 `__) +* Call CMake function to generate version header (`#1805 `__) +* Use parantheses around logging macro parameter (`#1820 `__) +* Remove author by request (`#1818 `__) +* Update maintainers (`#1817 `__) +* min_forward & min_backward thresholds must not be disabled (`#1815 `__) +* Re-add Clock::sleep_until (`#1814 `__) +* Fix lifetime of context so it remains alive while its dependent node handles are still in use (`#1754 `__) +* Add the interface for pre-shutdown callback (`#1714 `__) +* Take message ownership from moved LoanedMessage (`#1808 `__) +* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) +* Wait for publisher and subscription to match (`#1777 `__) +* Fix unused QoS profile for clock subscription and make ClockQoS the default (`#1801 `__) +* Fix dangerous std::bind capture in TimeSource implementation. (`#1768 `__) +* Fix dangerous std::bind capture in ParameterEventHandler implementation. (`#1770 `__) +* Handle sigterm, in the same way sigint is being handled. (`#1771 `__) +* rclcpp::Node copy constructor: make copy of node_waitables\_ member. (`#1799 `__) +* Extend NodeGraph to match what rcl provides. (`#1484 `__) +* Context::sleep_for(): replace recursion with do-while to avoid potential stack-overflow. (`#1765 `__) +* extend_sub_namespace(): Verify string::empty() before calling string::front(). (`#1764 `__) +* Deprecate the ``void shared_ptr`` subscription callback signatures. (`#1713 `__) +* Remove can_be_nullptr assignment check for QNX case. (`#1752 `__) +* Update client API to be able to remove pending requests. (`#1734 `__) +* Fix: Allow to add a node while spinning in the StaticSingleThreadedExecutor. (`#1690 `__) +* Add tracing instrumentation for executor and message taking. (`#1738 `__) +* Fix: Reset timer trigger time before execute in StaticSingleThreadedExecutor. (`#1739 `__) +* Use FindPython3 and make python3 dependency explicit. (`#1745 `__) +* Use rosidl_get_typesupport_target(). (`#1729 `__) +* Fix returning invalid namespace if sub_namespace is empty. (`#1658 `__) +* Add free function to wait for a subscription message. (`#1705 `__) +* Use rcpputils/scope_exit.hpp and remove rclcpp/scope_exit.hpp. (`#1727 `__) +* Remove unsafe get_callback_groups API. Callers should change to using for_each_callback_group(), or store the callback groups they need internally. +* Add in callback_groups_for_each. The main reason to add this method in is to make accesses to the callback_groups\_ vector thread-safe. By having a callback_groups_for_each that accepts a std::function, we can just have the callers give us the callback they are interested in, and we can take care of the locking. The rest of this fairly large PR is cleaning up all of the places that use get_callback_groups() to instead use callback_groups_for_each(). +* Use a different mechanism to avoid timers being scheduled multiple times by the MultiThreadedExecutor (`#1692 `__) +* Fix windows CI (`#1726 `__) Fix bug in AnyServiceCallback introduced in `#1709 `__. +* Support to defer to send a response in services. (`#1709 `__) Signed-off-by: Ivan Santiago Paunovic +* Fix documentation bug. (`#1719 `__) Signed-off-by: William Woodall +* Removed left over ``is_initialized()`` implementation (`#1711 `__) Leftover from https://github.com/ros2/rclcpp/pull/1622 +* Fixed declare parameter methods for int and float vectors (`#1696 `__) +* Cleaned up implementation of the intra-process manager (`#1695 `__) +* Added the node name to an executor ``runtime_error`` (`#1686 `__) +* Fixed a typo "Attack" -> "Attach" (`#1687 `__) +* Removed use of std::allocator<>::rebind (`#1678 `__) rebind is deprecated in c++17 and removed in c++20 +* Allow declare uninitialized parameters (`#1673 `__) +* Fix syntax issue with gcc (`#1674 `__) +* [service] Don't use a weak_ptr to avoid leaking (`#1668 `__) +* Fix doc typo (`#1663 `__) +* [rclcpp] Type Adaptation feature (`#1557 `__) +* Do not attempt to use void allocators for memory allocation. (`#1657 `__) +* Keep custom allocator in publisher and subscription options alive. (`#1647 `__) +* Fix get_publishers_subscriptions_info_by_topic test in test_node.cpp (`#1648 `__) +* Use OnShutdown callback handle instead of OnShutdown callback (`#1639 `__) +* use dynamic_pointer_cast to detect allocator mismatch in intra process manager (`#1643 `__) +* Contributors: Abrar Rahman Protyasha, Ahmed Sobhy, Alberto Soragna, Andrea Sorbini, Audrow Nash, Barry Xu, Bi0T1N, Chen Lihui, Chris Lalancette, Christophe Bedard, Doug Smith, Emerson Knapp, Gaël Écorchard, Geoffrey Biggs, Gonzo, Grey, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Karsten Knese, Kenji Miyake, M. Hofstätter, M. Mostafa Farzan, Mauro Passerino, Michel Hidalgo, Miguel Company, Nikolai Morin, Petter Nilsson, Scott K Logan, Shane Loretz, Steve Macenski, Tomoya Fujita, William Woodall, Yong-Hao Zou, iRobot ROS, livanov93, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* remove things that were deprecated during galactic (`#1913 `__) +* add take_data_by_entity_id API to waitable (`#1892 `__) +* Fix rosdoc2 issues (`#1897 `__) +* Add RMW listener APIs (`#1579 `__) +* Install headers to include/${PROJECT_NAME} (`#1888 `__) +* Fix include order and relative paths for cpplint (`#1859 `__) +* Fixes for uncrustify 0.72 (`#1844 `__) +* Use rclcpp::guard_condition (`#1612 `__) +* Remove author by request (`#1818 `__) +* Update maintainers (`#1817 `__) +* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) +* Deprecate the ``void shared_ptr`` subscription callback signatures (`#1713 `__) +* Use rcpputils/scope_exit.hpp and remove rclcpp/scope_exit.hpp. (`#1727 `__) +* Fixed occasionally missing goal result caused by race condition (`#1677 `__) +* Bump the benchmark timeout for benchmark_action_client (`#1671 `__) +* Returns CancelResponse::REJECT while goal handle failed to transit to CANCELING state (`#1641 `__) +* Fix action server deadlock issue that caused by other mutexes locked in CancelCallback (`#1635 `__) +* Contributors: Abrar Rahman Protyasha, Alberto Soragna, Chris Lalancette, Christophe Bedard, Jacob Perron, Kaven Yau, Shane Loretz, Tomoya Fujita, William Woodall, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_components `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Select executor in node registration (`#1898 `__) +* Fix rosdoc2 issues in rclcpp (`#1897 `__) +* Fix bugprone-exception-escape in node_main.cpp.in (`#1895 `__) +* small improvements to node_main.cpp.in +* Install headers to include/${PROJECT_NAME} (`#1888 `__) +* Use spin() in component_manager_isolated.hpp (`#1881 `__) +* add use_global_arguments for node options of component nodes (`#1776 `__) +* Add rclcpp_components::component (`#1855 `__) +* Add parameter to configure number of thread (`#1708 `__) +* remove RCLCPP_COMPONENTS_PUBLIC in class ComponentManagerIsolated (`#1843 `__) +* create component_container_isolated (`#1781 `__) +* Remove author by request (`#1818 `__) +* Update maintainers (`#1817 `__) +* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) +* Update client API to be able to remove pending requests. (`#1734 `__) +* Deprecate method names that use CamelCase in rclcpp_components. (`#1716 `__) +* Added a hook to generate node options in ComponentManager (`#1702 `__) +* Contributors: Alberto Soragna, Chris Lalancette, Daisuke Nishimatsu, Hirokazu Ishida, Ivan Santiago Paunovic, Jacob Perron, Rebecca Butler, Shane Loretz, gezp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* remove things that were deprecated during galactic (`#1913 `__) +* Fix rosdoc2 issues (`#1897 `__) +* Install headers to include/${PROJECT_NAME} (`#1888 `__) +* LifecycleNode::on_deactivate deactivate all managed entities. (`#1885 `__) +* Automatically transition lifecycle entities when node transitions (`#1863 `__) +* Remove author by request (`#1818 `__) +* Update maintainers (`#1817 `__) +* Suppress clang dead-store warnings in the benchmarks. (`#1802 `__) +* Update forward declarations of ``rcl_lifecycle`` types (`#1788 `__) +* Deprecate the ``void shared_ptr`` subscription callback signatures (`#1713 `__) +* Update client API to be able to remove pending requests. (`#1734 `__) +* Change log level for lifecycle_publisher. (`#1715 `__) +* Fix: RCLCPP_PUBLIC -> RCLCPP_LIFECYCLE_PUBLIC (`#1732 `__) +* Use rcpputils/scope_exit.hpp and remove rclcpp/scope_exit.hpp (`#1727 `__) +* Remove unsafe get_callback_groups API. Callers should change to using for_each_callback_group(), or store the callback groups they need internally. +* Add in callback_groups_for_each. The main reason to add this method in is to make accesses to the callback_groups\_ vector thread-safe. By having a callback_groups_for_each that accepts a std::function, we can just have the callers give us the callback they are interested in, and we can take care of the locking. The rest of this fairly large PR is cleaning up all of the places that use get_callback_groups() to instead use callback_groups_for_each(). +* Fix destruction order in lifecycle benchmark (`#1675 `__) +* [rclcpp] Type Adaptation feature (`#1557 `__) +* Contributors: Abrar Rahman Protyasha, Alberto Soragna, Audrow Nash, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, Tomoya Fujita, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make rclpy dependencies explicit (`#906 `__) +* Avoid exception in Node constructor when use override for 'use_sim_time' (`#896 `__) +* time_until_next_call returns max if timer is canceled. (`#910 `__) +* Properly implement action server/client handle cleanup. (`#905 `__) +* Make sure to take out contexts on Action{Client,Server}. (`#904 `__) +* Make sure to free the goal_status_array when done using it. (`#902 `__) +* Bugfix to Node.destroy_rate() result (`#901 `__) +* Remove fastrtps customization on tests (`#895 `__) +* fix typo (`#890 `__) +* Document that Future.result() may return None (`#884 `__) +* update doc release number (`#885 `__) +* Fix multi-threaded race condition in client.call_async (`#871 `__) +* Fix include order for cpplint (`#877 `__) +* Bugfix/duration to msg precision (`#876 `__) +* Update to pybind11 2.7.1 (`#874 `__) +* QoS history depth is only available with KEEP_LAST (`#869 `__) +* Implement managed nodes. (`#865 `__) +* Make rclpy.try_shutdown() behavior to follow rclpy.shutdown() more closely. (`#868 `__) +* Update TopicEndpointTypeEnum.__str_\_() method to include history kind and history depth. (`#849 `__) +* Add Clock.sleep_for() using Clock.sleep_until(). (`#864 `__) +* Add Clock.sleep_until() (`#858 `__) +* Add __enter_\_ and __exit_\_ to JumpHandle. (`#862 `__) +* Don't override rclpy._rclpy_pybind11 docs. (`#863 `__) +* Improve JumpThreshold documentation and forbid zero durations. (`#861 `__) +* Fix time.py and clock.py circular import. (`#860 `__) +* Make context.on_shutdown() allow free functions. (`#859 `__) +* Fix automatically declared parameters descriptor type. (`#853 `__) +* Shutdown asynchronously when sigint is received. (`#844 `__) +* Update maintainers. (`#845 `__) +* Add entities to callback group before making them available to the executor to avoid a race condition. (`#839 `__) +* Avoid race condition in client.call(). (`#838 `__) +* Handle sigterm. (`#830 `__) +* Use pybind11 for signal handling, and delete now unused rclpy_common, pycapsule, and handle code. (`#814 `__) +* Fix memory leak in Service::take_request() and Client::take_response(). (`#828 `__) +* Add Publisher.wait_for_all_acked(). (`#793 `__) +* Only add one done callback to a future in Executor. (`#816 `__) +* Add convert function from ParameterValue to Python builtin. (`#819 `__) +* Call Context._logging_fini() in Context.try_shutdown(). (`#800 `__) +* Lift LoggingSeverity enum as common dependency to logging and rcutils_logger modules (`#785 `__) +* Set Context.__context to None in __init_\_(). (`#812 `__) +* Remove unused function make_mock_subscription. (`#809 `__) +* Removed common.c/h (`#789 `__) +* Allow declaring uninitialized parameters (`#798 `__) +* Reject cancel request if failed to transit to CANCEL_GOAL state (`#791 `__) +* Deleted handle as it should no longer be used (`#786 `__) +* Removed some functions in common.c and replaced them in utils.cpp (`#787 `__) +* Moved exception.cpp/hpp to the _rclpy_pybind11 module (`#788 `__) +* Print 'Infinite' for infinite durations in topic endpoint info (`#722 `__) +* Break log function execution ASAP if configured severity is too high (`#776 `__) +* Convert Node and Context to use C++ Classes (`#771 `__) +* Misc action server improvements (`#774 `__) +* Misc action goal handle improvements (`#767 `__) +* Convert Guardcondition to use C++ classes (`#772 `__) +* Removed unused structs ``rclpy_client_t`` and ``rclpy_service_t`` (`#770 `__) +* Convert WaitSet to use C++ Classes (`#769 `__) +* Convert ActionServer to use C++ Classes (`#766 `__) +* Convert ActionClient to use C++ classes (`#759 `__) +* Use py::class\_ for rcl_action_goal_handle_t (`#751 `__) +* Convert Publisher and Subscription to use C++ Classes (`#756 `__) +* Rename QoS*Policy enum's to \*Policy (`#379 `__) +* Use params from node '/\*\*' from parameter YAML file (`#370 `__) +* Updated to use params from node '/\*\*' from parameter YAML file. (`#399 `__) +* Contributors: Alejandro Hernández Cordero, Anthony, Artem Shumov, Auguste Lalande, Barry Xu, Chris Lalancette, Emerson Knapp, Erki Suurjaak, Greg Balke, Ivan Santiago Paunovic, Jacob Perron, Lei Liu, Louise Poubel, Miguel Company, Shane Loretz, Tomoya Fujita, ksuszka + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcpputils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#160 `__) +* Fix include order for cpplint (`#158 `__) +* [path] Declare the default assignment operator (`#156 `__) +* Fixes for uncrustify 0.72 (`#154 `__) +* Fix the BSD license headers to use the standard one. (`#153 `__) +* Update maintainers to Chris Lalancette (`#152 `__) +* Add checked convert_to_nanoseconds() function (`#145 `__) +* Add missing sections in docs/FEATURES.md TOC (`#151 `__) +* [env] Add ``set_env_var`` function (`#150 `__) +* Add missing cstddef include (`#147 `__) +* Add accumulator test to CMakeLists.txt (`#144 `__) +* ``rcpputils::fs``: Fix doxygen parameter identifier (`#142 `__) +* Make thread safety macro C++ standards compliant (`#141 `__) +* Fix API documentation for clean ``rosdoc2`` build (`#139 `__) +* Improve ``rcppmath`` Doxygen documentation (`#138 `__) +* Improve documentation of utilities in docs/FEATURES.md (`#137 `__) +* Include ``rcppmath`` utilities in docs/FEATURES.md (`#136 `__) +* Fix ``IllegalStateException`` reference in FEATURES (`#135 `__) +* migrate rolling mean from ros2_controllers to rcppmath (`#133 `__) +* Update includes after rcutils/get_env.h deprecation (`#132 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Chris Lalancette, Christophe Bedard, Jacob Perron, Karsten Knese, Octogonapus, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update launch test for change related to enviroment variables in launch (`#354 `__) +* Remove dst_size from strlen usage (`#353 `__) +* Install headers to include\${PROJECT_NAME} (`#351 `__) +* Use static_cast instead of C-style cast (`#349 `__) +* Fixing up documentation build when using rosdoc2 (`#344 `__) +* Stop double-defining structs. (`#333 `__) +* Use FindPython3 explicitly instead of FindPythonInterp implicitly (`#345 `__) +* Fix build on Android (`#342 `__) +* Deprecate get_env.h and move content to env.{h,c} (`#340 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Shane Loretz, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`resource_retriever `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} (`#72 `__) +* Fix include order for cpplint (`#69 `__) +* Update maintainers (`#66 `__) +* Remove the deprecated retriever.h header (`#63 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add content filtered topics support. (`#302 `__) +* Add sequence numbers to rmw_message_info_t. (`#318 `__) +* Add rmw_feature_supported(). (`#318 `__) +* Add EventsExecutor (`#286 `__) +* Document that rmw_wait() SHOULD use a monotonic clock (`#316 `__) +* Install headers to include/${PROJECT_NAME} (`#317 `__) +* Update rmw_server_is_available() API documentation. (`#277 `__) +* Add client/service QoS getters. (`#314 `__) +* Fix up documentation build for rmw when using rosdoc2 (`#313 `__) +* Fix up errors in doxygen documentation (`#311 `__) +* Fix copy-paste error in API doc for rmw_get_gid_for_publisher (`#310 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#296 `__) +* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Exclude missing sample info fields when building rmw_connextddsmicro (`#79 `__) +* Update launch_testing_ros output filter prefixes for Connext6 (`#80 `__) +* Add support for user-specified content filters (`#68 `__) +* add stub for content filtered topic (`#77 `__) +* Add rmw listener apis (`#44 `__) +* Add client/service QoS getters. (`#67 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#20 `__) +* Contributors: Andrea Sorbini, Barry Xu, Chen Lihui, Ivan Santiago Paunovic, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Exclude missing sample info fields when building rmw_connextddsmicro (`#79 `__) +* Properly initialize CDR stream before using it for filtering (`#81 `__) +* Add support for user-specified content filters (`#68 `__) +* add stub for content filtered topic (`#77 `__) +* Add sequence numbers to message info structure (`#74 `__) +* Add rmw listener apis (`#44 `__) +* Fix cpplint errors (`#69 `__) +* Add client/service QoS getters. (`#67 `__) +* Update rmw_context_impl_t definition (`#65 `__) +* Use the new rmw_dds_common::get_security_files API (`#61 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#20 `__) +* Support extended signature for ``message_type_support_callbacks_t::max_serialized_size()`` from ``rosidl_typesupport_fastrtps_cpp``. (`#14 `__) +* Update includes after rcutils/get_env.h deprecation. (`#55 `__) +* Always modify UserObjectQosPolicy regardless of override policy. (`#53 `__) +* Improved conversion of time values between ROS and DDS formats. (`#43 `__) +* Allow sharing DomainParticipant with C++ applications. (`#25 `__) +* Add environment variable to control override of DomainParticipantQos. (`#41 `__) +* Contributors: Andrea Sorbini, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Miguel Company, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextddsmicro `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Exclude missing sample info fields when building rmw_connextddsmicro (`#79 `__) +* Add support for user-specified content filters (`#68 `__) +* add stub for content filtered topic (`#77 `__) +* Add sequence numbers to message info structure (`#74 `__) +* Add rmw listener apis (`#44 `__) +* Add client/service QoS getters. (`#67 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#20 `__) +* Contributors: Andrea Sorbini, Barry Xu, Chen Lihui, Ivan Santiago Paunovic, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_cyclonedds_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix get_topic_name and handling long service names +* Add serialization for SDK_DATA +* Additional checks for loan API +* Depend on just rmw_dds_common::rmw_dds_common_library (`#385 `__) +* Fix error message in rmw_init_options_copy(). (`#380 `__) +* Add content filter topic feature empty stub. (`#289 `__) +* Update to work with Cyclone 0.9.0 and Iceoryx 2.0 (`#379 `__) +* Fill message info sequence numbers as unsupported, add rmw_feature_supported() implementation. (`#381 `__) +* Fix a warning by making a pointer nullptr. (`#375 `__) +* Bump QDs to QL2 (`#371 `__) +* Add EventsExecutor (`#256 `__) +* Call dissociate_reader in rmw_destroy_subscription +* Wrap creation of new serdata_rmw within a try-catch block +* Fix memory leak in error scenario on the publish side with SHM +* Fix memory leaks on the take side with SHM +* rename _cyclonedds_has_shm to follow the convention +* Add iceoryx_binding_c as dependency to rmw_cyclonedds_cpp +* Release iox_chunk to iceoryx in serdata_free if the iox_chunk is still available +* Update iceoryx_subscriber also when constructing the serdata from the iox chunk +* Fix cpplint errors (`#363 `__) +* Updates for uncrustify 0.72 (`#358 `__) +* Export only rmw::rmw to downstream targets (`#360 `__) +* Export modern CMake targets (`#357 `__) +* Free with the same allocator in rmw_destroy_node (`#355 `__) +* Add client/service QoS getters. (`#343 `__) +* Updated version number and quality level. (`#349 `__) +* Update package maintainers. (`#351 `__) +* Fix undesired memory initialization in zero-copy data path. (`#348 `__) +* Fix QoS depth settings for clients/service being ignored. (`#340 `__) +* Link to Cyclone DDS in Quality Declaration. (`#342 `__) +* Update rmw_context_impl_t definition (`#337 `__) +* Add quality declaration for rmw_cyclonedds_cpp (`#335 `__) +* Fix use of deprecated is_loan_available (`#336 `__) +* Add -latomic for RISC-V (`#332 `__) +* Add pub/sub init, publish and take instrumentation using tracetools (`#329 `__) +* Pass the CRL down to CycloneDDS if it exists (`#325 `__) +* Use the new rmw_dds_common::get_security_files API (`#323 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#294 `__) +* Fix zero copy issues. (`#309 `__) +* Handle allocation errors during message deserialization. (`#313 `__) +* Update includes after rcutils/get_env.h deprecation. (`#312 `__) +* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Dietrich Krönke, Erik Boasson, Haowei Wen, Ivan Santiago Paunovic, Jacob Perron, Joe Speed, Michel Hidalgo, Shane Loretz, Sumanth Nirmal, eboasson, guillaume-pais-siemens, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_dds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Depend on target generated by rosidl_typesupport_cpp (`#58 `__) +* Use rosidl_get_typesupport_target() and target_link_libraries(). (`#57 `__) +* Install headers to include/${PROJECT_NAME} (`#56 `__) +* Fix include order for cpplint (`#55 `__) +* Fix up rmw_dds_common documentation when using rosdoc2 (`#54 `__) +* Add support for Certificate Revocation List files (`#52 `__) +* Silence clang warning (``range-loop-construct``) (`#53 `__) +* Add a common function for security files. (`#51 `__) +* Normalize rmw_time_t according to DDS spec (`#48 `__) +* Contributors: Andrea Sorbini, Chris Lalancette, Jacob Perron, Karsten Knese, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add pub/sub init, publish and take instrumentation using tracetools (`#591 `__) +* Add content filter topic feature (`#513 `__) +* Add sequence numbers to message info structure (`#587 `__) +* Removed some heap interactions in rmw_serialize.cpp (`#590 `__) +* Add EventsExecutor (`#468 `__) +* Install headers to include/${PROJECT_NAME} (`#578 `__) +* Add client/service QoS getters. (`#560 `__) +* Correctly recalculate serialized size on bounded sequences. (`#540 `__) +* Fix type size alignment. (`#550 `__) +* Change links from index.ros.org -> docs.ros.org (`#539 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#519 `__) +* Loan messages implementation (`#523 `__) * Added is_plain\_ attribute to base TypeSupport. * Added new methods to base TypeSupport. * Implementation of rmw_borrow_loaned_message. * Implementation of rmw_return_loaned_message_from_publisher. * Enable loan messages on publishers of plain types. * Implementation for taking loaned messages. * Enable loan messages on subscriptions of plain types. +* Contributors: Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Miguel Company, Shane Loretz, WideAwakeTN, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_dynamic_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add content filter topic feature (`#513 `__) +* Add sequence numbers to message info structure (`#587 `__) +* Add EventsExecutor (`#468 `__) +* Install headers to include/${PROJECT_NAME} (`#578 `__) +* Add client/service QoS getters. (`#560 `__) +* Correctly recalculate serialized size on bounded sequences. (`#540 `__) +* Fix type size alignment. (`#550 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#519 `__) +* Loan messages implementation (`#523 `__) * Added is_plain\_ attribute to base TypeSupport. * Added new methods to base TypeSupport. * Implementation of rmw_borrow_loaned_message. * Implementation of rmw_return_loaned_message_from_publisher. * Enable loan messages on publishers of plain types. * Implementation for taking loaned messages. * Enable loan messages on subscriptions of plain types. +* Contributors: Barry Xu, Chen Lihui, Ivan Santiago Paunovic, Miguel Company, Shane Loretz, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_shared_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address linter waning for windows. (`#592 `__) +* Add pub/sub init, publish and take instrumentation using tracetools (`#591 `__) +* Add content filter topic feature (`#513 `__) +* Add sequence numbers to message info structure (`#587 `__) +* Add EventsExecutor (`#468 `__) +* Complete events support (`#583 `__) +* Install headers to include/${PROJECT_NAME} (`#578 `__) +* Change default to synchronous (`#571 `__) +* Fix cpplint error (`#574 `__) +* Fixes for uncrustify 0.72 (`#572 `__) +* Add client/service QoS getters. (`#560 `__) +* Fix QoS depth settings for clients/service being ignored. (`#564 `__) +* Update rmw_context_impl_t definition. (`#558 `__) +* Update the LoanManager to do internal locking. (`#552 `__) +* Pass the CRL down to Fast-DDS if available. (`#546 `__) +* Use the new rmw_dds_common::get_security_files (`#544 `__) +* Support for SubscriptionOptions::ignore_local_publications (`#536 `__) +* Change links from index.ros.org -> docs.ros.org (`#539 `__) +* Add rmw_publisher_wait_for_all_acked support. (`#519 `__) +* Loan messages implementation (`#523 `__) * Added is_plain\_ attribute to base TypeSupport. * Added new methods to base TypeSupport. * Implementation of rmw_borrow_loaned_message. * Implementation of rmw_return_loaned_message_from_publisher. * Enable loan messages on publishers of plain types. * Implementation for taking loaned messages. * Enable loan messages on subscriptions of plain types. +* Export rmw_dds_common as an rmw_fastrtps_shared_cpp dependency (`#530 `__) +* Update includes after rcutils/get_env.h deprecation (`#529 `__) +* Contributors: Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Jose Antonio Moral, Michel Hidalgo, Miguel Company, Shane Loretz, Tomoya Fujita, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add content-filtered-topic interfaces (`#181 `__) +* Add rmw_feature_supported() (`#204 `__) +* Add EventsExecutor (`#161 `__) +* Fix relative path include syntax for cpplint (`#203 `__) +* Support and prefer exported targets from rmw implementations (`#201 `__) +* Add client/service QoS getters. (`#196 `__) +* Update maintainers to Audrow Nash and Michael Carroll. (`#199 `__) +* Fix renamed ``rcpputils`` header (`#198 `__) +* Fix rmw_implementation generated documentation (`#197 `__) +* Add rmw_publisher_wait_for_all_acked. (`#188 `__) +* Attempt to load any available RMW implementation. (`#189 `__) +* Update includes after rcutils/get_env.h deprecation (`#190 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Michel Hidalgo, Shane Loretz, iRobot ROS, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use FastDDS as default DDS (`#315 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`robot_state_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Depend on orocos_kdl_vendor (`#191 `__) +* export dependencies, to use robot_state_publisher as a component (`#193 `__) +* Fix include order for cpplint (`#186 `__) +* Change how parameter updates are handled (`#180 `__) +* Install includes to instal/${PROJECT_NAME} (`#184 `__) +* Make the change_fixed_joint test more robust (`#183 `__) +* Add in a test to make sure fixed transforms change on update +* Small C++ nice-isms in the tests +* Switch to using target_include_directories for tests +* Publish new fixed transforms when URDF is updated +* Make joint_states subscription QoS configurable; default to SensorDataQoS (`#179 `__) +* Remove dependency on urdfdom_headers (`#168 `__) +* Fix deprecated subscriber callbacks (`#173 `__) +* Cleanup the documentation in the RobotStatePublisher class. (`#172 `__) +* Always publish fixed frames to /tf_static (`#158 `__) +* corrected publish_frequency default in README (`#166 `__) +* Add tf frame_prefix parameter (`#159 `__) +* Contributors: Abrar Rahman Protyasha, Anthony Deschamps, Chris Lalancette, Jacob Perron, Kenji Brameld, Nils Schulte, Russell Joyce, Shane Loretz, Steve Nogar + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* support to publish as loaned message (`#981 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* support to publish as loaned message (`#981 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Bump version number to avoid conflict +* Make sure published messages are acknowledged for play mode (`#951 `__) +* TopicFilter use regex_search instead of regex_match (`#932 `__) +* Add start-offset play option (`#931 `__) +* Expose bag_rewrite as ``ros2 bag convert`` (`#921 `__) +* Add "ignore leaf topics" option to recorder (`#925 `__) +* Auto-detect storage_id for Reader (if possible) (`#918 `__) +* Add pause/resume options to the bag recorder (`#905 `__) +* Add --start-paused option to ``ros2 bag play`` (`#904 `__) +* Update package maintainers (`#899 `__) +* Fix converter plugin choices for record (`#897 `__) +* Add missing spaces to error message (`#875 `__) +* keyboard controls for pause/resume toggle and play-next: (`#847 `__) +* Add --snapshot-mode argument to the "record" verb (`#851 `__) +* Refactor plugin query mechanism and standardize trait management (`#833 `__) +* Update ``PlayOptions::delay`` to ``rclcpp::Duration`` to get nanosecond resolution (`#843 `__) +* Load compression and serialization choices via plugin query (`#827 `__) +* Add delay option (`#789 `__) +* Avoid passing exception KeyboardInterrupt to the upper layer (`#788 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Kosuke Takeuchi, Michel Hidalgo, Sonia Jin, Tony Peng + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix importlib_metadata warning on Python 3.10. (`#706 `__) +* Add timeout to kill hanging tests (`#701 `__) +* Use try_shutdown() instead of shutdown() in DirectNode.__exit_\_() (`#683 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Reapply `#659 `__ (`#661 `__) +* Revert "Make the ros2cli output always line buffered (`#659 `__)" (`#660 `__) +* Make the ros2cli output always line buffered (`#659 `__) +* add uuid to ros2 daemon node name. (`#658 `__) +* Transfer daemon socket ownership on spawn. (`#652 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli_test_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2component `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Drop deprecated get_container_components_info() API. (`#647 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2doctor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix importlib_metadata warning on Python 3.10. (`#706 `__) +* Add timeout to kill hanging tests (`#701 `__) +* Switch ros2 doctor to using psutil for network checks. (`#687 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Improve ros2 doctor on Windows. (`#631 `__) +* Add QoS compatibility check and report. (`#621 `__) +* Contributors: Aditya Pande, Alberto Soragna, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers in setup.py (`#287 `__) +* Use frontend group dependency & explicit dependencies in ros2launch (`#256 `__) +* Update package maintainers (`#284 `__) +* Add regex filter for selective launch-prefix application (`#261 `__) +* Resolves `#37 `__ - Added --launch-prefix argument for 'ros2 launch' command (`#254 `__) +* Use sets of file extensions provided by parser extensions (`#252 `__) +* Simplify logic to fix absolute paths (`#230 `__) +* add way to include other Python launch files (`launch #122 `__) +* Contributors: Audrow Nash, Cameron Miller, Christophe Bedard, Michel Hidalgo, rob-clarke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle_test_fixtures `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2multicast `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2node `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2param `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Fix how ros2 param interprets command-line arguments. (`#684 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Removed redundant code (`#666 `__) +* Reapply `#659 `__ (`#661 `__) +* Fix flaky ros2 param list (`#656 `__) +* Skip None Result (`#646 `__) +* add '--write' option to avoid an unintentional data loss. (`#638 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Jacob Perron, Jay Wang, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2pkg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Use local git config instead of global (`#693 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* [ros2pkg] Skip copyright tests in template packages (`#676 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Generate LICENSE files on ros2 pkg create. (`#650 `__) +* Handle ValueError (`#643 `__) +* Pass package exports to template in pkg create api (`#619 `__) (`#628 `__) +* Add changelogs (`#635 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Amro Al-Baali, Audrow Nash, Chris Lalancette, Ivan Santiago Paunovic, Shane Loretz, rob-clarke, tim-fan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2run `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* check subprocess.returncode to print error message. (`#639 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Also provide --include-hidden-services for ``ros2 service list`` verb (`#551 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Add changelogs (`#635 `__) +* Contributors: Aditya Pande, Audrow Nash, Ivan Santiago Paunovic, Karsten Knese, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use new domain_coordinator API (`#10 `__) +* Contributors: Timo Röhling + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to kill hanging tests (`#701 `__) +* Add yaml dump flow style. (`#698 `__) +* support ros2topic echo once option. (`#695 `__) +* Fix special case for fastrtps incompatible QoS. (`#694 `__) +* Depend on launch packages instead of ros_testing to avoid circular dependency (`#685 `__) +* Add QoS history and depth information if available. (`#678 `__) +* Cleanup mislabeled BSD license (`#447 `__) +* Update maintainers to Aditya Pande, Audrow Nash, and Michael Jeronimo (`#673 `__) +* Updated maintainers (`#670 `__) +* Update lost messages test case (`#669 `__) +* Implementation of message filtering for ros2 (`#654 `__) +* Change default QoSProfile for pub (`#653 `__) +* Add option in ros2 topic pub to wait for N matching subscriptions, use N=1 by default when combined with --times (`#642 `__) +* ``ros2 topic pub`` starts publishing right away. (`#626 `__) +* Fix Topic Info Test with "Infinite" printing (`#616 `__) +* Add changelogs (`#635 `__) +* QoS autodetection (`#613 `__) +* Make Lost Messages option ON by default (`#633 `__) +* Contributors: Aditya Pande, Audrow Nash, Chris Lalancette, Emerson Knapp, Gonzo, Ivan Santiago Paunovic, Jorge Perez, Shane Loretz, Tomoya Fujita, Tully Foote, matthews-jca + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix 'ros2 trace' fini() error +* Don't require kernel tracer and detect when it's not installed +* Deprecate 'context_names' param and replace with 'context_fields' +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Update package maintainers (`#899 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Remove unnecessary public definition. (`#950 `__) +* Changes for uncrustify 0.72 (`#937 `__) +* Bugfix for broken bag split when using cache (`#936 `__) +* Update package maintainers (`#899 `__) +* Don't preprocess a storage file more than once (`#895 `__) +* added seek interface (`#836 `__) +* Refactor plugin query mechanism and standardize trait management (`#833 `__) +* fix sequential reader rollover-to-next-file strategy: (`#839 `__) +* Load compression and serialization choices via plugin query (`#827 `__) +* Contributors: Cameron Miller, Chris Lalancette, Michael Orlov, Michel Hidalgo, Shane Loretz, sonia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression_zstd `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Update package maintainers (`#899 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Remove unnecessary public definition. (`#950 `__) +* Fix relative path syntax for cpplint (`#947 `__) +* Mark up the message_cache with TSA annotations (`#946 `__) +* Changes for uncrustify 0.72 (`#937 `__) +* Redesign in cache consumer and circular message cache to get rid from busy loop (`#941 `__) +* Bugfix for broken bag split when using cache (`#936 `__) +* Remove JumpHandler copy-implementation from PlayerClock/TimeControllerClock (`#935 `__) +* Auto-detect storage_id for Reader (if possible) (`#918 `__) +* Add --start-paused option to ``ros2 bag play`` (`#904 `__) +* Use the message_introspection header to get MessageMember. (`#903 `__) +* Update package maintainers (`#899 `__) +* Fix converter plugin choices for record (`#897 `__) +* Enable sanitizers only if code actually can run (`#572 `__) +* Need to pass introspection TS to converter plugin for it to be useful (`#896 `__) +* Don't preprocess a storage file more than once (`#895 `__) +* Fix a bug on invalid pointer address when using "MESSAGE" compressio… (`#866 `__) +* Metadata per file info (`#870 `__) +* Fix TSA warnings when building with clang thread analysis. (`#877 `__) +* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) +* Circular Message Cache implementation for snapshot feature (`#844 `__) +* Fix discovery silently stops after unknown msg type is found. (`#848 `__) +* added seek interface (`#836 `__) +* Refactor plugin query mechanism and standardize trait management (`#833 `__) +* fix sequential reader rollover-to-next-file strategy: (`#839 `__) +* Load compression and serialization choices via plugin query (`#827 `__) +* Workaround for false positive findings by clang thread safety analysis in time controller jump callbacks API. (`#799 `__) +* Add callbacks for PlayerClock::jump(time_point) API with CI fix (`#779 `__) +* Revert "Add callbacks for PlayerClock::jump(time_point) API (`#775 `__)" (`#778 `__) +* Add callbacks for PlayerClock::jump(time_point) API (`#775 `__) +* Contributors: Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Lei Liu, Michael Orlov, Michel Hidalgo, Shane Loretz, Tony Peng, Wojciech Jaworski, sonia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Add burst-mode to Player (`#977 `__) +* Update package maintainers (`#899 `__) +* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) * Add snapshot service to recorder node * Simplify and clarify double buffering patterns +* Contributors: Cameron Miller, Chris Lalancette, Geoffrey Biggs, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_performance_benchmarking `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) * Enable YAML encoding/decoding for RecordOptions and StorageOptions +* Update package maintainers (`#899 `__) +* Updated node declare_parameter to new syntax (`#882 `__) +* Updated benchmark package to use writer close() instead of old reset() (`#881 `__) +* Contributors: Adam Dąbrowski, Chris Lalancette, Emerson Knapp, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* support to publish as loaned message (`#981 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* support to publish as loaned message (`#981 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Bump version number to avoid conflict +* Make sure published messages are acknowledged for play mode (`#951 `__) +* Fix relative path syntax for cpplint (`#947 `__) +* Update to pybind11 2.7.1 (`#945 `__) +* Add start-offset play option (`#931 `__) +* Expose bag_rewrite as ``ros2 bag convert`` (`#921 `__) +* Add "ignore leaf topics" option to recorder (`#925 `__) +* Add a ReaderWriterFactory utility to share logic for reuse (`#923 `__) +* Add pause/resume options to the bag recorder (`#905 `__) +* Add --start-paused option to ``ros2 bag play`` (`#904 `__) +* Update package maintainers (`#899 `__) +* Fix converter plugin choices for record (`#897 `__) +* Metadata per file info (`#870 `__) +* keyboard controls for pause/resume toggle and play-next: (`#847 `__) +* Add --snapshot-mode argument to the "record" verb (`#851 `__) +* Add stopRecording into rosbag2_py (`#854 `__) +* added seek interface (`#836 `__) +* Refactor plugin query mechanism and standardize trait management (`#833 `__) +* Update ``PlayOptions::delay`` to ``rclcpp::Duration`` to get nanosecond resolution (`#843 `__) +* Load compression and serialization choices via plugin query (`#827 `__) +* Add delay option (`#789 `__) +* Handle SIGTERM gracefully in recording (`#792 `__) +* Contributors: Abrar Rahman Protyasha, Afonso da Fonseca Braga, Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jacob Perron, Jorge Perez, Kosuke Takeuchi, Michel Hidalgo, Tony Peng, Wojciech Jaworski, sonia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Remove unnecessary public definition. (`#950 `__) +* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) +* Update package maintainers (`#899 `__) +* Provide MetadataIO interface to convert metadata to a string in memory, alongside file IO versions (`#894 `__) +* Metadata per file info (`#870 `__) +* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) +* added seek interface (`#836 `__) +* Refactor plugin query mechanism and standardize trait management (`#833 `__) +* Contributors: Audrow Nash, Cameron Miller, Chris Lalancette, Emerson Knapp, Jorge Perez, Michel Hidalgo, Shane Loretz, Tony Peng, Wojciech Jaworski, sonia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Emit a warning rather than crash when a message is too big for sqlite (`#919 `__) +* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) +* Update package maintainers (`#899 `__) +* added seek interface (`#836 `__) +* Contributors: Chris Lalancette, Emerson Knapp, Michel Hidalgo, Shane Loretz, William Woodall, sonia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Update package maintainers (`#899 `__) +* Make sure the subscription exists before publishing messages (`#804 `__) +* Handle SIGTERM gracefully in recording (`#792 `__) +* Add spin_and_wait_for_matched to PublicationManager and update test c… (`#797 `__) +* Avoid passing exception KeyboardInterrupt to the upper layer (`#788 `__) +* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Revert "Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__)" (`#984 `__) +* Add the ability to record any key/value pair in the 'custom' field in metadata.yaml (`#976 `__) +* Bump version number to avoid conflict +* Add pause/resume options to the bag recorder (`#905 `__) +* Update package maintainers (`#899 `__) +* Fix a bug on invalid pointer address when using "MESSAGE" compressio… (`#866 `__) +* Metadata per file info (`#870 `__) +* Fix record test to reflect plugin query changes (`#838 `__) +* Make sure the subscription exists before publishing messages (`#804 `__) +* Handle SIGTERM gracefully in recording (`#792 `__) +* Add spin_and_wait_for_matched to PublicationManager and update test c… (`#797 `__) +* Remove rmw_fastrtps_cpp find_package in rosbag2_tests (`#774 `__) +* Contributors: Audrow Nash, Barry Xu, Cameron Miller, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Jorge Perez, Michel Hidalgo, Tony Peng, Wojciech Jaworski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* support to publish as loaned message (`#981 `__) +* support to publish as loaned message (`#981 `__) +* Bump version number to avoid conflict +* Add burst-mode to Player (`#977 `__) +* Install headers to include/${PROJECT_NAME} (`#958 `__) +* Make sure published messages are acknowledged for play mode (`#951 `__) +* Changes for uncrustify 0.72 (`#937 `__) +* TopicFilter use regex_search instead of regex_match (`#932 `__) +* Add start-offset play option (`#931 `__) +* Add parentheses suggested by Clang on OSX to fix build warning (`#930 `__) +* Bag rewriter (C++) (`#920 `__) +* Add "ignore leaf topics" option to recorder (`#925 `__) +* Rewrite TopicFilter for single-call reusability (`#924 `__) +* Add a ReaderWriterFactory utility to share logic for reuse (`#923 `__) +* Add pause/resume options to the bag recorder (`#905 `__) +* Add logging macros for rosbag2_transport (`#917 `__) +* Enable YAML encoding/decoding for RecordOptions and StorageOptions (`#916 `__) +* Expose the QoS object wrapper (`#910 `__) +* Add --start-paused option to ``ros2 bag play`` (`#904 `__) +* Update package maintainers (`#899 `__) +* Add a Seek service (`#874 `__) +* Add simple keyboard control for playback rate (`#893 `__) +* Fix a bug on invalid pointer address when using "MESSAGE" compressio… (`#866 `__) +* Fix typo (`#880 `__) +* Use Reader's seek() method for seeking/jumping in Player (`#873 `__) +* keyboard controls for pause/resume toggle and play-next: (`#847 `__) +* Implement snapshot mechanism and corresponding ROS Service (`#850 `__) +* Circular Message Cache implementation for snapshot feature (`#844 `__) +* Add jump/seek API for Player class (`#826 `__) +* Restructure test_play_timing to one test per case, to see which times out (`#863 `__) +* Fix discovery silently stops after unknown msg type is found. (`#848 `__) +* Fixing deprecated subscriber callback warnings (`#852 `__) +* Bugfix for race condition in Player::peek_next_message_from_queue() (`#849 `__) +* added seek interface (`#836 `__) +* Update ``PlayOptions::delay`` to ``rclcpp::Duration`` to get nanosecond resolution (`#843 `__) +* Move notification about ready for playback inside play_messages_from_queue() (`#832 `__) +* Add wait for player to be ready for playback in Player::play_next() method (`#814 `__) +* Make sure the subscription exists before publishing messages (`#804 `__) +* Add delay option (`#789 `__) +* Copy recorder QoS profile to local variable so that temporary value isn't cleared (`#803 `__) +* test_play_services: fail gracefully on future error (`#798 `__) +* Recording with --all and --exclude fix (`#765 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Barry Xu, Bastian Jäger, Cameron Miller, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Ivan Santiago Paunovic, Kosuke Takeuchi, Lei Liu, Louise Poubel, Michael Orlov, Michel Hidalgo, Piotr Jaroszek, Shane Loretz, sonia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosgraph_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_adapter `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rename nested loop index (`#643 `__) +* Fix how comments in action interfaces are processed (`#632 `__) +* Pass comments in ros interface constants to the .idl generated files (`#630 `__) +* Update package maintainers (`#624 `__) +* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) +* Fix escaping in string literals (`#595 `__) +* Ignore multiple ``#`` characters and dedent comments (`#594 `__) +* Contributors: Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz, ibnHatab + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix importlib_metdata warning with Python 3.10. (`#674 `__) +* Update maintainers to Michel Hidalgo and Shane Loretz (`#633 `__) +* Update package maintainers (`#624 `__) +* Support passing keyword arguments to rosidl CLI extensions (`#597 `__) +* Add missing f for format string (`#600 `__) +* Contributors: Audrow Nash, Chris Lalancette, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make rosidl_get_typesupport_target return -NOTFOUND instead of FATAL_ERROR (`#672 `__) +* Add introspection typesupport tests for C/C++ messages (`#651 `__) +* Use target output name for exporting typesupport library (`#625 `__) +* Update package maintainers (`#624 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) +* Add rosidl_get_typesupport_target and deprecate rosidl_target_interfaces (`#606 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) +* Contributors: Jonathan Selling, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_generators `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Unroll group dependencies (`#20 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_runtime `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Unroll group dependencies (`#20 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix error handling when copying C sequence messages (`#671 `__) +* Install generated headers to include/${PROJECT_NAME} (`#670 `__) +* Misc cleanup in the rosidl generator extensions (`#662 `__) +* Set the output size unconditionally when copying sequences (`#669 `__) +* Implement copy function for C messages (`#650 `__) +* Implement equality operator function for C messages. (`#648 `__) +* Generate documentation in generated C header files based on ROS interfaces comments (`#593 `__) +* Update package maintainers (`#624 `__) +* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) +* Fix a cpplint allocator regression. (`#590 `__) +* Use RCUtils allocators in rosidl_generator_c (`#584 `__) +* Contributors: Chris Lalancette, Ivan Santiago Paunovic, Michel Hidalgo, Nikolai Morin, Pablo Garrido, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install generated headers to include/${PROJECT_NAME} (`#670 `__) +* Misc cleanup in the rosidl generator extensions (`#662 `__) +* Add missing build_export_depend dependency (`#665 `__) +* Fix bug where rosidl_runtime_cpp wasn't depended upon (`#660 `__) +* Fix include order for cpplint (`#644 `__) +* Set CXX standard to 17 (`#635 `__) +* Update package maintainers (`#624 `__) +* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) +* Support flow style YAML printing (`#613 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) +* Relocate to_yaml() under message namespace (`#609 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) +* Contributors: Jacob Perron, Jorge Perez, Michel Hidalgo, Shane Loretz, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_dds_idl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add changelog (`#56 `__) +* Contributors: Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removes erroneous unmatched closing parenthesis (`#125 `__) +* require Python 3.6 as we use format strings in various places (`#152 `__) +* Fix rosidl_generator_py assuming incorect library names (`#149 `__) +* Fix for msg file containing a property field that is not at the end (`#151 `__) +* Update package maintainers (`#147 `__) +* Use rosidl_get_typesupport_target() (`#139 `__) +* Support available typesupport specification in CLI extension (`#133 `__) +* Use python_d for test_cli_extension in Debug mode (`#136 `__) +* Add missing float/double bounds check (`#128 `__) +* Added optimization for copying arrays using buffer protocol (`#129 `__) +* Add smoke test for CLI extension (`#132 `__) +* Install generated Python interfaces in a Python package (`#131 `__) +* Contributors: Charles Cross, Chen Lihui, Michel Hidalgo, Seulbae Kim, Shane Loretz, William Woodall, ksuszka + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set maybe_placeholders to False for lark 1.+ compatibility (`#664 `__) +* Generate documentation in generated C header files based on ROS interfaces comments (`#593 `__) +* Pass comments in ros interface constants to the .idl generated files (`#630 `__) +* Update package maintainers (`#624 `__) +* Fix escaping in string literals (`#595 `__) +* Contributors: Ivan Santiago Paunovic, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix error handling when copying C sequence messages (`#671 `__) +* Set the output size unconditionally when copying sequences (`#669 `__) +* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) +* Install headers to include/${PROJECT_NAME} (`#658 `__) +* Implement copy function for C messages (`#650 `__) +* Implement equality operator function for C messages. (`#648 `__) +* Set CXX standard to 17 (`#635 `__) +* Update package maintainers (`#624 `__) +* Use RCUtils allocators in rosidl_generator_c (`#584 `__) +* Contributors: Jose Luis Rivero, Michel Hidalgo, Nikolai Morin, Pablo Garrido, Shane Loretz, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing dependency on rosidl_runtime_c (`#666 `__) +* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) +* Install headers to include/${PROJECT_NAME} (`#658 `__) +* Set CXX standard to 17 (`#635 `__) +* Update package maintainers (`#624 `__) +* Contributors: Jose Luis Rivero, Michel Hidalgo, Shane Loretz, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add yaml dump flow style. (`#16 `__) +* Update maintainers (`#15 `__) * Update maintainers to Shane Loretz * Update Shane's email Co-authored-by: Shane Loretz +* Contributors: Audrow Nash, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries(... PRIVATE ...) in single typesupport case (`#124 `__) +* rosidl CMake cleanup in rosidl_typesupport_c (`#123 `__) +* Install headers to include/${PROJECT_NAME} (`#121 `__) +* Use FindPython3 (`#118 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#116 `__) +* Support available typesupport specification in CLI extensions (`#112 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#113 `__) +* Fix C and C++ typesupports CLI extensions (`#111 `__) +* Contributors: Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries(... PRIVATE ...) in single typesupport case (`#124 `__) +* rosidl CMake cleanup in rosidl_typesupport_cpp (`#123 `__) +* Install headers to include/${PROJECT_NAME} (`#121 `__) +* Make sure to check typesupport handles against nullptr properly (`#119 `__) +* Use FindPython3 (`#118 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#116 `__) +* Support available typesupport specification in CLI extensions (`#112 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#113 `__) +* Fix C and C++ typesupports CLI extensions (`#111 `__) +* Contributors: Chris Lalancette, Michel Hidalgo, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install generated headers to include/${PROJECT_NAME} (`#88 `__) +* Misc fastrtps typesupport generator cleanup (`#87 `__) +* Install headers to include/${PROJECT_NAME} (`#86 `__) +* Fix include order for cpplint (`#84 `__) +* Update maintainers to Shane Loretz (`#83 `__) +* Use FindPython3 explicitly instead of PythonInterp implicitly (`#78 `__) +* Revert rosidl targets and dependencies exportation (`#76 `__) * Revert "Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__)" * Revert "Bundle and ensure the exportation of rosidl generated targets (`#73 `__)" +* Correctly inform that a BoundedSequence is bounded (`#71 `__) +* Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#73 `__) +* Fix Fast-RTPS C++ typesupport CLI extension (`#72 `__) +* Fastdds type support extensions (`#67 `__) +* Remove fastrtps dependency (`#68 `__) +* Contributors: Andrea Sorbini, Audrow Nash, Jacob Perron, Michel Hidalgo, Miguel Company, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install generated headers to include/${PROJECT_NAME} (`#88 `__) +* Misc fastrtps typesupport generator cleanup (`#87 `__) +* Install headers to include/${PROJECT_NAME} (`#86 `__) +* Fix include order for cpplint (`#84 `__) * Fix include order for cpplint Relates to https://github.com/ament/ament_lint/pull/324 * Use double-quotes for other includes This is backwards compatible with older versions of cpplint. +* Update maintainers to Shane Loretz (`#83 `__) +* Re-introduce improvements to serialization of primitive bounded sequences for C++ type support (`#81 `__) +* Revert "Improve serialization of ... (`#79 `__)" (`#80 `__) +* Improve serialization of primitive bounded sequences in C++ type support (`#79 `__) +* Use FindPython3 explicitly instead of PythonInterp implicitly (`#78 `__) +* Revert rosidl targets and dependencies exportation (`#76 `__) * Revert "Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__)" * Revert "Bundle and ensure the exportation of rosidl generated targets (`#73 `__)" +* Correctly inform that a BoundedSequence is bounded (`#71 `__) +* Export rosidl_typesupport_fastrtps_c* dependencies (`#75 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#73 `__) +* Fix Fast-RTPS C++ typesupport CLI extension (`#72 `__) +* Fastdds type support extensions (`#67 `__) +* Remove fastrtps dependency (`#68 `__) +* Contributors: Andrea Sorbini, Audrow Nash, Jacob Perron, Jorge Perez, Michel Hidalgo, Miguel Company, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) +* Install headers to include/${PROJECT_NAME} (`#658 `__) +* Add ROSIDL_TYPESUPPORT_INTERFACE__LIBRARY_NAME() macro (`#649 `__) +* Set CXX standard to 17 (`#635 `__) +* Update package maintainers (`#624 `__) +* Contributors: Jose Luis Rivero, Michel Hidalgo, Shane Loretz, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install generated headers to include/${PROJECT_NAME} (`#670 `__) +* Misc cleanup in the rosidl generator extensions (`#662 `__) +* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) +* Update Quality declaration to level 1 in README for instrospection pkgs (`#659 `__) +* Install headers to include/${PROJECT_NAME} (`#658 `__) +* Move rosidl_typesupport_introspection_cpp quality declaration to Q1 (`#657 `__) +* Move rosidl_typesupport_introspection_c quality declaration to Q1 (`#656 `__) +* add documentation for generators and API (`#646 `__) +* Rework nested types' items introspection in C and C++ (`#652 `__) +* Fix up the documentation for rosidl_typesupport_introspection_c (`#628 `__) +* Update package maintainers (`#624 `__) +* Quality Declaration for typesupport_introspection (`#621 `__) +* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) +* Update function prefix (`#596 `__) +* Contributors: Chris Lalancette, Jose Luis Rivero, Michel Hidalgo, Pablo Garrido, Shane Loretz, eboasson + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install generated headers to include/${PROJECT_NAME} (`#670 `__) +* Misc cleanup in the rosidl generator extensions (`#662 `__) +* De-duplicate Quality Level from README and QUALITY_DECLARATION (`#661 `__) +* Update Quality declaration to level 1 in README for instrospection pkgs (`#659 `__) +* Install headers to include/${PROJECT_NAME} (`#658 `__) +* Move rosidl_typesupport_introspection_cpp quality declaration to Q1 (`#657 `__) +* add documentation for generators and API (`#646 `__) +* Rework nested types' items introspection in C and C++ (`#652 `__) +* Set CXX standard to 17 (`#635 `__) +* Fix up the documentation for rosidl_typesupport_introspection_cpp (`#627 `__) +* Update package maintainers (`#624 `__) +* Quality Declaration for typesupport_introspection (`#621 `__) +* Make rosidl packages use FindPython3 instead of FindPythonInterp (`#612 `__) +* Revert "Bundle and ensure the exportation of rosidl generated targets" (`#611 `__) +* Bundle and ensure the exportation of rosidl generated targets (`#601 `__) +* Contributors: Chris Lalancette, Jose Luis Rivero, Michel Hidalgo, Shane Loretz, eboasson, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump ``rosidl_typesupport_introspection_tests`` coverage (`#655 `__) +* Add introspection typesupport tests for C/C++ services (`#653 `__) +* Add introspection typesupport tests for C/C++ messages (`#651 `__) +* Contributors: Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rpyutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to call abspath when adding Windows DLL directories. (`#8 `__) +* Update troubleshooting links to docs.ros.org (`#6 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed getiter to iter (`#1 `__) (`#241 `__) +* Update maintainers (`#233 `__) (`#237 `__) +* add missing dependencies: rospkg-modules, python_qt_binding, rospy (`#227 `__) +* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) +* use catkin_install_python for Python script (`#206 `__) +* Contributors: Michael Jeronimo, sven-herrmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#233 `__) (`#237 `__) +* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) +* [Windows] fix rqt_gui_cpp install path (`#190 `__) +* [Windows] fix building (`#189 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#233 `__) (`#237 `__) +* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#233 `__) (`#237 `__) +* bump CMake minimum version to avoid CMP0048 warning (`#219 `__) +* fix missing import bugs (`#139 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rti_connext_dds_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rti-connext-dds dependency to 6.0.1. (`#71 `__) +* Contributors: Steven! Ragnarök + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rttest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#114 `__) +* Fix include order for cpplint (`#113 `__) +* Fixes for uncrustify 0.72 (`#111 `__) +* Mark dependent targets as PRIVATE (`#112 `__) +* Export modern CMake targets (`#110 `__) +* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change links index.ros.org -> docs.ros.org. (`#698 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_assimp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to pass compiler and flags down to assimp (`#844 `__) +* Fix support for assimp 5.1.0 (`#817 `__) +* Contributors: Chris Lalancette, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add implementation for cancel interface (`#809 `__) +* Install headers to include/${PROJECT_NAME} (`#829 `__) +* Remove definition of PLUGINLIB_DISABLE_BOOST. (`#821 `__) +* Fix support for assimp 5.1.0 (`#817 `__) +* Fix cpplint errors (`#818 `__) +* Set message type for ros topic display (`#800 `__) +* Fixes for uncrustify 0.72 (`#807 `__) +* Do not block visualization manager updates when opening the display panel dialog (`#795 `__) +* Switch to using Qt::MiddleButton for RViz. (`#802 `__) +* Removed traces in renderPanel (`#777 `__) +* move yaml_config_writer.hpp to public includes (`#764 `__) +* Update displays_panel.cpp (`#745 `__) +* Robot: Report mesh loading issues (`#744 `__) +* Exposed tool_manager header file. (`#767 `__) +* refactor: make const getter methods const (`#756 `__) +* Efficiently handle 3-bytes pixel formats (`#743 `__) +* Report sample lost events (`#686 `__) +* Update window close icon (`#734 `__) +* Fix missing "X" icon in panel close button (`#731 `__) +* Add rviz_rendering dependency to rviz_common (`#727 `__) +* Remove the word "Alpha" from the splash screen. (`#696 `__) +* Removed some memory leaks in rviz_rendering and rviz_rendering_tests (`#710 `__) +* Contributors: ANDOU Tetsuo, Alejandro Hernández Cordero, Chen Lihui, Chris Lalancette, Daisuke Nishimatsu, Gonzo, Ivan Santiago Paunovic, Jacob Perron, Joseph Schornak, Rebecca Butler, Shane Loretz, Silvio Traversaro, davidorchansky + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add far plane distance property to camera (`#849 `__) +* Drop ignition-math6 from rviz_default_plugins link interface (`#833 `__) +* add implementation for cancel interface (`#809 `__) +* Install headers to include/${PROJECT_NAME} (`#829 `__) +* Remove definition of PLUGINLIB_DISABLE_BOOST. (`#821 `__) +* Remove TF filter from ImageTransportDisplay (`#788 `__) +* Add underscores to material names (`#811 `__) +* Export image_transport dependency (`#813 `__) +* Fixes for uncrustify 0.72 (`#807 `__) +* Switch to using Qt::MiddleButton for RViz. (`#802 `__) +* Add a tf_buffer_cache_time_ns to tf_wrapper (`#792 `__) +* Make libraries to avoid compiling files multiple times (`#774 `__) +* Computed inertia with ignition-math (`#751 `__) +* Fixed crash when changing rendering parameters for pointcloud2 while 'Selectable' box is unchecked (`#768 `__) +* Robot: Report mesh loading issues (`#744 `__) +* Handle NaN values for Wrench msgs (`#746 `__) +* Triangle lists support textures (`#719 `__) +* Report sample lost events (`#686 `__) +* Fix path message orientation error (`#736 `__) +* Set topic namespace in interactive markers display (`#725 `__) +* mass property visualization (`#714 `__) +* Export InteractiveMarker (`#718 `__) +* Yuv to rgb changes (`#701 `__) +* Extract message type in ImageTransportDisplay (`#711 `__) +* Duplicated code RobotJoint (`#702 `__) +* Don't attempt to moc generate files that don't have QOBJECT. (`#690 `__) +* Switch to including tf2_geometry_msgs.hpp (`#689 `__) +* Export Qt5 dependencies properly (`#687 `__) +* Add support for namespace-scoped DELETEALL action in Marker displays (`#685 `__) +* Use image_transport to subscribe to image messages (`#523 `__) +* Contributors: Akash, Alejandro Hernández Cordero, Audrow Nash, Chen Lihui, Chris Lalancette, Cory Crean, Gonzo, Greg Balke, Ivan Santiago Paunovic, Jacob Perron, Martin Idel, Michel Hidalgo, Paul, Rebecca Butler, Scott K Logan, Shane Loretz, bailaC, brian soe, cturcotte-qnx, ketatam + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_ogre_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix interface link libraries in ogre vendor (`#761 `__) +* Fix the build for Ubuntu Jammy arm64. (`#828 `__) +* Strip RPATH from installed Ogre binaries (`#688 `__) +* Contributors: Chris Lalancette, Laszlo Turanyi, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make getVerticesPerPoint method public and improve tests (`#843 `__) +* Disable class-memaccess warnings for Eigen (`#838 `__) +* Disable a warning when including Eigen. (`#835 `__) +* Install headers to include/${PROJECT_NAME} (`#829 `__) +* Fix support for assimp 5.1.0 (`#817 `__) +* Fix cpplint errors (`#818 `__) +* Fixes for uncrustify 0.72 (`#807 `__) +* Suppress assimp warnings in rviz_rendering build (`#775 `__) +* Fix for ogre failing when material already exists (`#729 `__) +* Removed some memory leaks in rviz_rendering and rviz_rendering_tests (`#710 `__) +* Export Qt5 dependencies properly (`#687 `__) +* Putting glsl 1.50 resources back in RenderSystem (`#668 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jacob Perron, Jorge Perez, Michel Hidalgo, Piotr Jaroszek, Scott K Logan, Shane Loretz, Silvio Traversaro, Wolf Vollprecht + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed some memory leaks in rviz_rendering and rviz_rendering_tests (`#710 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_visual_testing_framework `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} (`#829 `__) +* Fixes for uncrustify 0.72 (`#807 `__) +* Update includes after rcutils/get_env.h deprecation (`#677 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Move the find_package statements for BUILD_TESTING (`#186 `__) +* Feedback on conditional sensor_msgs_library target (`#1 `__) (`#183 `__) +* [Fix] Fix image_encodings.hpp's URL in README (`#184 `__) +* [Fix] Fix fill_image.hpp's URL in README (`#182 `__) +* Add sensor_msgs_library target and install headers to include/${PROJECT_NAME} (`#178 `__) +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Add YUV420 and YUV444 to image encodings (`#172 `__) +* Cleanup mislabeled BSD license (`#83 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Fix rosdoc2 warnings in sensor_msgs. (`#162 `__) +* Add equidistant distortion model (`#160 `__) +* Use rosidl_get_typesupport_target() (`#156 `__) +* Update CompressedImage documentation: add 'tiff' as a supported format (`#154 `__) +* Contributors: Audrow Nash, Chris Lalancette, Grey, Hemal Shah, Homalozoa X, Ivan Santiago Paunovic, Martin Günther, Michael Jeronimo, Pablo Garrido, Shane Loretz, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in a compatibility layer for older versions of numpy. (`#185 `__) +* Port pointcloud creation to numpy. (`#175 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Chris Lalancette, Florian Vahl + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shape_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Add prism type to the SolidPrimitive.msg (`#166 `__) (`#167 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey, M. Fatih Cırıt + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shared_queues_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Update package maintainers (`#899 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sqlite3_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Update package maintainers (`#899 `__) +* Contributors: Chris Lalancette, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sros2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Increase the shutdown timeout for test_generate_policy_no_nodes. (`#278 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`statistics_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Chris Lalancette (`#130 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_srvs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`stereo_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#489 `__) +* Add changelogs (`#473 `__) +* Merge pull request `#356 `__ from ros2/issue/321_enhance_parameter_api +* Contributors: Aditya Pande, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli_remapping `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update python nodes SIGINT handling (`#490 `__) +* Updated maintainers (`#489 `__) +* Add changelogs (`#473 `__) +* Contributors: Aditya Pande, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_communication `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Split test_subscriber into multiple compilation units. (`#500 `__) +* Add test_msgs dependency (`#497 `__) +* Update python nodes SIGINT handling (`#490 `__) +* Updated maintainers (`#489 `__) +* Fix deprecated subscriber callback warnings (`#483 `__) +* Add tests for BoundedPlainSequences (`#481 `__) +* Use rosidl_get_typesupport_target() (`#480 `__) +* Use rcpputils/scope_exit.hpp instead of rclcpp/scope_exit.hpp (`#479 `__) +* Add changelogs (`#473 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_interface_files `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Update package.xml (`#18 `__)" (`#19 `__) +* Update package.xml (`#18 `__) +* Update maintainers to Audrow Nash (`#17 `__) +* Added BoundedPlainSequences messages (`#14 `__) +* Contributors: Audrow Nash, Chris Lalancette, Miguel Company, Nikolai Morin + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Increase test time tolerance (`#305 `__) +* Use correct namespace when evaluating parameter files for composable nodes (`#303 `__) +* Handle empty strings when evaluating parameters (`#300 `__) +* Add parameter substitution (`#297 `__) +* More Helpful Error Messages (`#275 `__) +* Update maintainers in setup.py (`#287 `__) +* Set parameters from file for composable nodes (`#281 `__) +* Update package maintainers (`#284 `__) +* Update node name matcher (`#282 `__) +* Support both parameter file configurations for composable nodes (`#259 `__) +* Shutdown context after test (`#267 `__) +* Handle substitutions in RosTimer (`#264 `__) +* Add SetParametersFromFile action (`#260 `__) +* Properly support ros_args attribute through launch frontends (`#253 `__) +* Add 'push_ros_namespace' alias to 'push-ros-namespace' (`#250 `__) +* Add ros_arguments option to Node action (`#249 `__) +* ROS Timer Action (`#244 `__) +* Support container in frontend (`#235 `__) +* Added normalize_remap_rule and types. (`launch #173 `__) +* Fixed setup.py versions (`launch #155 `__) +* Fixed a bug to ensure that shutdown event is handled correctly (`launch #154 `__) +* Made various fixes and added tests for remappings passed to Node actions (`launch #137 `__) +* Contributors: Aditya Pande, Audrow Nash, Christophe Bedard, David V. Lu!!, Jacob Perron, Jorge Perez, Kenji Miyake, Michel Hidalgo, Rebecca Butler + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Michel Hidalgo (`#559 `__) +* Updated maintainers (`#555 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} and Depend on rosidl_typesupport\_* targets directly (`#133 `__) +* Update maintainers to Chris Lalancette (`#130 `__) +* Add test fixures for BoundedPlainSequences (`#125 `__) +* Added BoundedPlainSequences to test_msgs (`#123 `__) +* Contributors: Audrow Nash, Miguel Company, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_quality_of_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Aditya Pande and Shane Loretz (`#491 `__) +* Updated maintainers (`#489 `__) +* Fix deprecated subscriber callback warnings (`#483 `__) +* Add changelogs (`#473 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Audrow Nash, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix include order for cpplint (`#493 `__) +* Fix test (`#488 `__) +* Updated maintainers (`#489 `__) +* Add tests for rclcpp sigterm handler (`#485 `__) +* Fix deprecated subscriber callback warnings (`#483 `__) +* Fix deprecation warnings and failures after client API update (`#482 `__) +* Use rosidl_get_typesupport_target() (`#480 `__) +* Use rcpputils/scope_exit.hpp instead of rclcpp/scope_exit.hpp (`#479 `__) +* Add test for defered service callback signature (`#478 `__) +* Add changelogs (`#473 `__) +* Merge pull request `#357 `__ from ros2/ros2_658_leftovers +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Christophe Bedard, Ivan Santiago Paunovic, Jacob Perron, Mauro Passerino, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add content-filtered-topic interfaces (`#181 `__) +* Fix linter issues (`#200 `__) +* Add client/service QoS getters. (`#196 `__) +* Added tests for bounded sequences serialization (`#193 `__) +* Add RMW_DURATION_INFINITE basic compliance test. (`#194 `__) +* Test SubscriptionOptions::ignore_local_publications. (`#192 `__) +* Add rmw_publisher_wait_for_all_acked. (`#188 `__) +* Wait for server in test_rmw_implementation service tests. (`#191 `__) +* Contributors: Barry Xu, Chen Lihui, Emerson Knapp, Jorge Perez, Jose Antonio Moral, Michel Hidalgo, Miguel Company, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_security `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated maintainers (`#489 `__) +* Fix deprecated subscriber callback warnings (`#483 `__) +* Add changelogs (`#473 `__) +* Simplify the test_secure_subscriber code. (`#471 `__) +* Update includes after rcutils/get_env.h deprecation (`#472 `__) +* Contributors: Abrar Rahman Protyasha, Aditya Pande, Chris Lalancette, Christophe Bedard, Ivan Santiago Paunovic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix more instances of Eigen problems on RHEL. (`#515 `__) +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* Fix precision loss from using rclcpp::Time::seconds() (`#511 `__) +* More Intuitive CLI for Static Transform Publisher (`#392 `__) +* Conversion tests for toMsg() (`#423 `__) +* Deprecate tf2_geometry_msgs.h (`#418 `__) +* Deprecate tf2_kdl.h (`#414 `__) +* Deprecate tf2_bullet.h (`#412 `__) +* Contributors: Bjar Ne, Chris Lalancette, Hunter L. Allen, Kenji Brameld, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Introduce constants for tracepoint names +* Move actual tests out of tracetools_test to new test_tracetools package +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for preloading pthread and dl instrumentation shared libs +* Remove profile_fast option and consider LD_PRELOADing both libs +* Fix multiple LdPreload actions not working and add test +* Deprecate 'context_names' param and replace with 'context_fields' +* Move some tests from tracetools_launch to test_tracetools_launch +* Contributors: Christophe Bedard, Ingo Lütkebohle + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* forward declare fromMsg to avoid missing symbols in downstream libraries (`#485 `__) +* tf2: Enable common linter tests (`#469 `__) +* Move time functions into time.cpp. +* Change a for loop to a while loop. +* Switch to C++-style casts. +* Remove totally unused (and unreachable) code. +* Replace NULL with nullptr. +* Fix up some comments. +* Use std::make_shared where we can. +* Replace two comparisons with empty string to empty(). +* Make sure to include-what-you-use. +* Remove unnecessary internal method. +* Remove long-deprecated walkToTopParent overload. +* Remove unnecessary test dependencies. +* Remove some references to the ROS 1 wiki. +* Add rosidl_runtime_cpp as build_depend and build_export_depend. +* Minor cleanups in CMakeLists.txt. +* Remove include directory that doesn't exist. +* Remove completely unnecessary target_link_libraries. +* Remove unused speed_test from tf2. +* Suppress clang warnings about enumerator attributes. (`#463 `__) +* Change TF2Error names to be a bit more descriptive. (`#349 `__) +* Fixed errors due to missing header link. (`#432 `__) +* Deprecate tf2_geometry_msgs.h (`#418 `__) +* Speedup covariance unwrapping (`#399 `__) +* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Dima Dorezyuk, João C. Monteiro, Shane Loretz, Shivam Pandey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_bullet `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* Export a tf2_bullet::tf2_bullet target (`#495 `__) +* Fix cpplint errors (`#497 `__) +* Remove some references to the ROS 1 wiki. +* Fix tf2_bullet dependency export (`#428 `__) +* Deprecate tf2_bullet.h (`#412 `__) +* Contributors: Bjar Ne, Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Workaround broken RHEL FindEigen3.cmake (`#513 `__) +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* Disable mem-access warnings on aarch64. (`#506 `__) +* Fix cpplint errors (`#497 `__) +* Remove some references to the ROS 1 wiki. +* Add doTransform function for twists or wrenches (`#406 `__) +* Reenable stamped eigen tests (`#429 `__) +* Deprecate tf2_eigen.h (`#413 `__) +* Contributors: AndyZe, Bjar Ne, Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix more instances of Eigen problems on RHEL. (`#515 `__) +* Depend on orocos_kdl_vendor (`#473 `__) +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* Fix cpplint errors (`#497 `__) +* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to find the right Python executable. (`#514 `__) +* Depend on orocos_kdl_vendor (`#473 `__) +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* Drop PyKDL dependency in tf2_geometry_msgs (`#509 `__) +* Fix cpplint errors (`#497 `__) +* Export a tf2_geometry_msgs::tf2_geometry_msgs target (`#496 `__) +* Feature: Add doTransform for Wrench messages (`#476 `__) +* Remove some references to the ROS 1 wiki. +* Style fixes in tf2_geometry_msgs. (`#464 `__) +* Fix for issue `#431 `__ - Covariance is not transformed in do_transform_pose_with_covariance_stamped (`#453 `__) +* doTransform non stamped msgs (`#452 `__) +* ``tf2_geometry_msgs``: Fixing covariance transformation in ``doTransform`` (`#430 `__) +* Geometry nitpicks (`#426 `__) +* Conversion tests for toMsg() (`#423 `__) +* Deprecate tf2_geometry_msgs.h (`#418 `__) +* Contributors: Abrar Rahman Protyasha, Bjar Ne, Chris Lalancette, Denis Štogl, Florian Vahl, Jacob Perron, Khasreto, Shane Loretz, vineet131 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Depend on orocos_kdl_vendor (`#473 `__) +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* KDL python formatting and licenses (`#425 `__) +* Deprecate tf2_kdl.h (`#414 `__) +* Contributors: Bjar Ne, Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove dead file from tf2_msgs (`#415 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to finalize tf2_py BufferCore. (`#505 `__) +* Make tf2_py Use FindPython3 (`#494 `__) +* Change TF2Error names to be a bit more descriptive. (`#349 `__) +* Remove python_compat.h (`#417 `__) +* Contributors: Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} and use modern CMake (`#493 `__) +* use dedicated callback group and executor to isolate timer (`#447 `__) +* Adding shared pointer definition to tf2 buffer (`#508 `__) +* fix for a basic logic (`#510 `__) +* Fix precision loss from using rclcpp::Time::seconds() (`#511 `__) +* clear relative callback of Buffer if MessageFilter is destroyed (`#490 `__) +* More info in tf2_echo output (`#468 `__) +* Fix cpplint errors (`#497 `__) +* Fixes for uncrustify 0.72 (`#486 `__) +* More Intuitive CLI for Static Transform Publisher (`#392 `__) +* Reduce transform listener nodes (`#442 `__) +* ``tf2_ros``: Fix deprecated subscriber callbacks (`#448 `__) +* Fix tf2_echo does not work with ros-args (`#407 `__) (`#408 `__) +* Contributors: Abrar Rahman Protyasha, Chen Lihui, Chris Lalancette, Hunter L. Allen, Jacob Perron, Kenji Brameld, PGotzmann, Shane Loretz, Steve Macenski, Zhenpeng Ge, gezp, simulacrus + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Drop PyKDL dependency in tf2_geometry_msgs (`#509 `__) +* Add in one more destroy call that was missed in testing. (`#504 `__) +* Be much more careful about cleanup in the tf2_ros_py tests. (`#499 `__) +* Use the correct type for BufferClient timeout_padding. (`#498 `__) It should be a duration, not a float. +* Update maintainers to Alejandro Hernandez Cordero and Chris Lalancette (`#481 `__) +* Fix buffer_client.py using default timeout_padding (`#437 `__) +* Use underscores instead of dashes in setup.cfg. (`#403 `__) +* Contributors: Audrow Nash, Carlos Andrés Álvarez Restrepo, Chris Lalancette, Florian Vahl + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable mem-access warnings on aarch64. (`#506 `__) +* Fix cpplint errors (`#497 `__) +* Reenable sensor_msgs test (`#422 `__) +* Deprecate tf2_sensor_msgs.h (`#416 `__) +* Contributors: Bjar Ne, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Alejandro Hernandez Cordero and Chris Lalancette (`#481 `__) +* Remove unused import (`#465 `__) +* Adding date-time to frames filename (`#454 `__) +* Use underscores instead of dashes in setup.cfg. (`#403 `__) +* Contributors: Audrow Nash, Hannu Henttinen, Nisala Kalupahana + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} (`#11 `__) +* Export a modern CMake target instead of old-style variables (`#10 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#114 `__) +* Export modern CMake targets (`#110 `__) +* Remove the use of malloc hooks from the tlsf_cpp tests. (`#109 `__) +* Contributors: Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_monitor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers to Audrow Nash and Michael Jeronimo (`#543 `__) +* Small cleanups to the topic monitor. (`#517 `__) +* Fix topic_monitor for high publication rate (`#461 `__) +* Use is_alive for threads. (`#510 `__) +* Contributors: Audrow Nash, Chris Lalancette, Elias De Coninck + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_statistics_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install includes to include/${PROJECT_NAME} (`#548 `__) +* Additional fixes for documentation in demos. (`#538 `__) +* Fixing deprecated subscriber callback warnings (`#532 `__) +* Contributors: Abrar Rahman Protyasha, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} +* Merge branch 'update-mentions-of-tracetools-test' into 'master' Update applicable mentions of tracetools_test to test_tracetools See merge request `ros-tracing/ros2_tracing!259 `__ +* Update applicable mentions of tracetools_test to test_tracetools +* Merge branch 'version-3-1-0' into 'master' Version 3.1.0 See merge request `ros-tracing/ros2_tracing!256 `__ +* Correctly handle calls to TRACEPOINT() macro with no tracepoint args +* Move publisher handle tracepoint argument from rclcpp_publish to rcl_publish +* Add support for rmw init/pub, take, and executor instrumentation +* Export target on Windows and export an interface if TRACETOOLS_DISABLED +* Remove deprecated utility functions +* Contributors: Christophe Bedard, Ivan Santiago Paunovic, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable kernel tracing by default +* Don't require kernel tracer and detect when it's not installed +* Add support for preloading pthread and dl instrumentation shared libs +* Remove profile_fast option and consider LD_PRELOADing both libs +* Improve event matching for shared lib preloading +* Improve LdPreload action's lib-finding function and add proper tests +* Fix multiple LdPreload actions not working and add test +* Deprecate 'context_names' param and replace with 'context_fields' +* Support per-domain context fields for the Trace action +* Improve LdPreload.get_shared_lib_path() for when a static lib may exist +* Move some tests from tracetools_launch to test_tracetools_launch +* Expose Trace action as frontend action and support substitutions +* Contributors: Christophe Bedard, Ingo Lütkebohle + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow providing additional actions for TraceTestCase +* Remove default value for 'package' kwarg for TraceTestCase +* Move actual tests out of tracetools_test to new test_tracetools package +* Add tests for rmw init/pub, take, and executor instrumentation +* Add field type assertion utilities to TraceTestCase +* Fixing deprecated subscriber callback warnings +* Contributors: Abrar Rahman Protyasha, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable kernel tracing by default +* Don't require kernel tracer and detect when it's not installed +* Introduce constants for tracepoint names +* Optimize default tracing session channel config values +* Deprecate 'context_names' param and replace with 'context_fields' +* Support per-domain context fields for the Trace action +* Add support for rmw init/pub, take, and executor tracepoints +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`trajectory_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Contributors: Audrow Nash, Grey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`turtlesim `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use ``double`` when handling ``qreal orient\_`` (`#114 `__) +* Add Rolling Icon (`#133 `__) +* Update maintainers to Audrow Nash and Michael Jeronimo (`#137 `__) +* Fixing deprecated subscriber callback warnings (`#134 `__) +* Use rosidl_get_typesupport_target() (`#132 `__) +* Print out the correct node name on startup. (`#122 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Chris Lalancette, Katherine Scott, Seulbae Kim, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} (`#31 `__) +* Add linter tests and fix errors (`#30 `__) +* Add in a Doxyfile to predefine macros. (`#28 `__) +* Contributors: Chris Lalancette, Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf_parser_plugin `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Install headers to include/${PROJECT_NAME} (`#31 `__) +* Add linter tests and fix errors (`#30 `__) +* Contributors: Jacob Perron, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`visualization_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Interface packages should fully on the interface packages that they depend on (`#173 `__) +* Update maintainers to Geoffrey Biggs and Tully Foote (`#163 `__) +* Marker Textures (`#153 `__) +* Document namespace scoped marker deletion. (`#151 `__) +* Contributors: Audrow Nash, Greg Balke, Grey, Michel Hidalgo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`yaml_cpp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing dependency on yaml-cpp (`#32 `__) +* Upgrade to yaml-cpp 0.7.0 (`#25 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`zstd_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version number to avoid conflict +* Use git hash for zstd vendor (`#969 `__) +* Update package maintainers (`#899 `__) +* Declare missing dependency on 'git' in zstd_vendor (`#890 `__) +* Switch to using 'git apply' for zstd_vendor patches (`#846 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Michel Hidalgo, Scott K Logan, Shane Loretz \ No newline at end of file diff --git a/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst b/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst index ee70728feb1..6e5def602b1 100644 --- a/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst @@ -1,4219 +1,4223 @@ -Iron Irwini Changelog -===================== - -This page is a list of the complete changes in all ROS 2 core packages since the previous release. - -.. contents:: Table of Contents - :local: - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* Add service_msgs package (`#143 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Depend on rosidl_core_generators for packages required by actions (`#144 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* Update the demos to C++17. (`#594 `__) -* Add README's for action_tutorials. (`#576 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Fix two small bugs in the fibonacci C++ tutorial. (`#564 `__) -* Contributors: Audrow Nash, Chris Lalancette, kagibson - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* A couple more upgrades to C++17. (`#609 `__) -* Add README's for action_tutorials. (`#576 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Remove action_msgs dependency (`#580 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, kagibson - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add README's for action_tutorials. (`#576 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, kagibson - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`actionlib_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ament_clang_format: use open braces for enum definitions (`#426 `__) -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, james-rms, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* recommend use of --mixin compile-commands (`#371 `__) -* Improve message and avoid missing new lines between reports from files (`#373 `__) -* Contributors: Audrow Nash, William Woodall, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support INTERFACE on ament_auto_add_library (`#420 `__) -* Fix ament_auto_add_gtest's parameter passing (`#421 `__) -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) -* Rolling: ament_cmake_auto should include dependencies as SYSTEM (`#385 `__) -* Contributors: Audrow Nash, Christopher Wecht, Joshua Whitley, Rin Iwai - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) -* Update maintainers (`#379 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ament_cmake_uninstall_target: Correct location of install_manifest.txt (`#432 `__) -* Use file(GENERATE OUTPUT) to create dsv files (`#416 `__) Using file(WRITE) and file(APPEND) causes the modification stamp of the file to be changed each time CMake configures, resluting in an 'Installing' message rather than an 'Up-to-date' message even though the file content is identical. Using file(GENERATE OUTPUT) updates the timestamp of the file only if the content changes. -* Warn when trying to symlink install an INTERFACE_LIBRARY (`#417 `__) -* Workaround to exclude Clion's cmake folders from colcon test (`#410 `__) - Add AMENT_IGNORE to CMAKE_BINARY_DIR to avoid picking up cmake specific folders created by CLion in ``colcon build`` and ``colcon test`` commands -* if (NOT ${UNDEFINED_VAR}) gets evaluated to false, so change to if (NOT UNDEFINED_VAR) so it evaluates to true. (`#407 `__) -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Implement ament_add_default_options (`#390 `__) -* Contributors: Audrow Nash, Kenji Brameld, Michael Orlov, Scott K Logan, Shane Loretz, Silvio Traversaro, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) -* Update maintainers (`#379 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) -* Update maintainers (`#379 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_definitions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_link_flags `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_targets `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Support new target export template introduced with CMake 3.24 (`#395 `__) -* Fix the order in which Export.cmake files are included (`#256 `__) -* Contributors: Audrow Nash, Timo Röhling - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add flake8 linter ignore support (`#424 `__) -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, RFRIEDM-Trimble, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gen_version_h `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changed version gte macro to make it MSVC compatible. Fix `#433 `__ (`#434 `__) -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash, iquarobotics - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gmock `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix compiler warnings related to gtest/gmock (`#408 `__) * Suppress compiler warnings when building gmock definition of implicit copy constructor ... is deprecated because it has a user-declared copy assignment operator [-Wdeprecated-copy] * Declare gtest/gmock include dirs as SYSTEM PRIVATE for test targets -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash, Robert Haschke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_google_benchmark `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gtest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix compiler warnings related to gtest/gmock (`#408 `__) * Suppress compiler warnings when building gmock definition of implicit copy constructor ... is deprecated because it has a user-declared copy assignment operator [-Wdeprecated-copy] * Declare gtest/gmock include dirs as SYSTEM PRIVATE for test targets -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash, Robert Haschke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix test skipping logic for missing pytest module (`#441 `__) -* Add missing buildtool_depend on python3-pytest (`#440 `__) -* ament_cmake_pytest needs a buildtool_depend on ament_cmake_test. (`#439 `__) -* Fix pytest-cov version detection with pytest >=7.0.0 (`#436 `__) -* use the error handler replace to allow non-utf8 to be decoded (`#381 `__) -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Add NOCAPTURE option to ament_add_pytest_test (`#393 `__) -* Contributors: Audrow Nash, Chris Lalancette, Christophe Bedard, El Jawad Alaa, Jacob Perron, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support Debian-specific install dir for ament_cmake_python (`#431 `__) -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Document ament_cmake_python (`#387 `__) -* Contributors: Audrow Nash, Shane Loretz, Timo Röhling - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#16 `__) -* Update maintainers (`#15 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_target_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* use the error handler replace to allow non-utf8 to be decoded (`#381 `__) -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash, El Jawad Alaa - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) -* Update maintainers (`#379 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_vendor_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix the version number of ament_cmake_vendor_package. -* Add ament_cmake_vendor_package package (`#429 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_version `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Support for matching license header within multiline comment block (`#361 `__) -* Improved licencse matching (`#358 `__) -* Updated regex and adding test cases for copyright search (`#363 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, Will, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_cpplint] Process errors without linenums (`#385 `__) -* Update maintainers (`#379 `__) -* Consider files with '.hh' extension as C++ headers (`#374 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, Jacob Perron, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Fix exclude regression (`#387 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#89 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#89 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add flake8 linter ignore support (`#424 `__) -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) -* Update maintainers (`#379 `__) -* Contributors: Abrar Rahman Protyasha, Audrow Nash, RFRIEDM-Trimble, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for comment lines in dsv files (`#139 `__) -* [rolling] Update maintainers - 2022-11-07 (`#138 `__) -* Mirror rolling to master -* Remove unused isolated prefix level templates (`#133 `__) -* Contributors: Audrow Nash, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* updating ref to pep257 docs (`#433 `__) -* Added underscore to ignore new pydocstyle item (`#428 `__) -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* [ament_pep257][master] redirecting error prints to stderr (`#390 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, Christian Henkel, Cristóbal Arroyo, Mirco Colosi (CR/AAS3), methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ament_pycodestyle - fix crash caused by reporting on ignored errors (`#435 `__) -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, Shane Loretz, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#421 `__) -* Update maintainers (`#379 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`builtin_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Depend on rosidl_core_generators for packages required by actions (`#144 `__) -* Fix documented range (`#139 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_calibration_parsers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update image_common to C++17. (`#267 `__) -* Add alias library targets for all libraries (`#259 `__) -* Add support for missing ROI and binning fields (`#254 `__) -* Contributors: AndreasR30, Chris Lalancette, RFRIEDM-Trimble - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_info_manager `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update image_common to C++17. (`#267 `__) -* Add alias library targets for all libraries (`#259 `__) -* Add lifecycle node compatibility to camera_info_manager (`#190 `__) -* Contributors: Chris Lalancette, RFRIEDM-Trimble, Ramon Wijnands - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`class_loader `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* make sanitizer happy (`#205 `__) -* [rolling] Update maintainers - 2022-11-07 (`#206 `__) -* Remove appveyor configuration. (`#204 `__) -* Just fix a typo in a comment. (`#203 `__) -* make the meta-object alive in the lifecycle of the registered plugin (`#201 `__) -* Mirror rolling to ros2 -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`common_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* update launch file name format to match documentation (`#588 `__) -* Added README.md for composition (`#598 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* fix memory leak (`#585 `__) -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Gary Bey, Patrick Wspanialy - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* Add matched event demo for rclcpp and rclpy (`#607 `__) -* Fix the set_parameters_callback example program. (`#608 `__) -* [demo_nodes_cpp] Add YAML launch demos for topics (`#605 `__) -* update launch file name format to match documentation (`#588 `__) -* Service introspection (`#602 `__) * Add in a rclcpp and rclpy demo of introspection. -* Added README.md for demo_cpp_nodes (`#599 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Demo for pre and post set parameter callback support (`#565 `__) * local parameter callback support -* counter starts from 1, not 2. (`#562 `__) -* add a demo of content filter listener (`#557 `__) -* Contributors: Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Damien LaRocque, Deepanshu Bansal, Gary Bey, Patrick Wspanialy, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp_native `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* Added README.md for demo_cpp_nodes_native (`#597 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Make demo_nodes_cpp_native install stuff only when it builds (`#590 `__) -* Contributors: Audrow Nash, Chris Lalancette, Gary Bey, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* Add matched event demo for rclcpp and rclpy (`#607 `__) -* Enable document generation using rosdoc2 (`#606 `__) -* Service introspection (`#602 `__) -* Added README.md for demo_nodes_py (`#600 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Demo for pre and post set parameter callback support (`#565 `__) -* Add demo for rclpy parameter client (`#566 `__) -* Exit with code 0 if ExternalShutdownException is raised (`#581 `__) -* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Deepanshu Bansal, Gary Bey, Jacob Perron, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`diagnostic_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`domain_coordinator `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#16 `__) -* Update maintainers (`#15 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_map_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Added README.md for dummy_map_server (`#572 `__) -* Contributors: Audrow Nash, Chris Lalancette, Gary Bey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_robot_bringup `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update launch file name format to match documentation (`#588 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Patrick Wspanialy - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_sensors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix unstable LaserScan status for rviz2 (`#616 `__) -* Added README.md for dummy_sensors (`#573 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Gary Bey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`eigen3_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#6 `__) -* Mirror rolling to master -* Update maintainers (`#4 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`example_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#17 `__) -* Remove action_msgs dependency (`#16 `__) -* Mirror rolling to master -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_async_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_cbg_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* add ContentFilteredTopic example. (`#341 `__) -* Contributors: Audrow Nash, Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_timer `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_multithreaded_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_wait_set `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the examples to C++17. (`#353 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Add test linting to wait_set and fix issues. (`#346 `__) (`#347 `__) -* Contributors: Audrow Nash, Chris Lalancette, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_executors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_guard_conditions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 for ament_python pkgs (`#357 `__) * Add missing action_msgs dep * Add exec_deps for launch_testing_examples -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_pointcloud_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 for ament_python pkgs (`#587 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`fastrtps_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#93 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`foonathan_memory_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added support for QNX 7.1 build (#65) -* Update upstream to release 0.7-3 (#62)(#63) -* Fix CMake minimum required version (#60) - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`google_benchmark_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Actually update to 1.6.1. (`#25 `__) We claimed we were, but in fact we were pinned to the 1.5.3 git hash. -* Remove set but unused variable (`#24 `__) Clang checks -Wunused-but-set-variable. This fails the build with -Werror also enabled. -* [rolling] Update maintainers - 2022-11-07 (`#22 `__) -* Mirror rolling to main -* Contributors: Audrow Nash, Chris Lalancette, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ignition_cmake2_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set target version to 2.14.0 (`#5 `__) -* Mirror rolling to main -* Contributors: Audrow Nash, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ignition_math6_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Forward CMAKE_PREFIX_PATH when building vendor package (`#8 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added README.md for image_tools - [Clean] (`#596 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette, Gary Bey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update image_common to C++17. (`#267 `__) -* Add alias library targets for all libraries (`#259 `__) -* Remove subscriber and publisher impl methods without options (`#252 `__) -* Deprecate impl without options (`#249 `__) -* opt-in to qos overriding for publisher (`#246 `__) -* Add qos option to override qos (`#208 `__) -* Contributors: Brian, Chris Lalancette, Daisuke Nishimatsu, Kenji Brameld, RFRIEDM-Trimble - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`interactive_markers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update interactive_markers to C++17. (`#99 `__) -* Update maintainers (`#98 `__) -* Mirror rolling to ros2 -* update maintainer (`#92 `__) -* Contributors: Audrow Nash, Chris Lalancette, Dharini Dutia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`intra_process_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix executable name in README (`#619 `__) -* Change all ROS2 -> ROS 2. (`#610 `__) -* Added README.md for intra_process_demo (`#595 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette, Gary Bey, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`kdl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch some tests to use unique pointers instead of raw pointers. (`#74 `__) -* log link children as DEBUG instead of INFO (`#71 `__) -* Enable the kdl_parser tests in ROS 2 (`#68 `__) -* Add in a LICENSE file and fix up copyright headers (`#66 `__) -* Use orocos_kdl_vendor and orocos-kdl target (`#64 `__) -* Use the rcutils logger instead of printf (`#65 `__) -* Contributors: Chris Lalancette, Joseph Schornak, Scott K Logan, yuraSomatic - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`keyboard_handler `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Force exit from main thread on signal handling in ``keyboard_handler`` (`#23 `__) -* Contributors: Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`laser_geometry `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update laser_geometry to C++17. (`#90 `__) -* Update Maintainers (`#88 `__) -* Mirror rolling to ros2 -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Document LaunchService.{run,run_async}() return value (`#702 `__) -* [rosdoc2] Fix document generation on buildfarm (`#701 `__) -* Enable document generation using rosdoc2 for ament_python pkgs (`#697 `__) -* Remove the import of Literal from entity.py. (`#694 `__) -* Fix flake8 errors. (`#695 `__) -* add symlink to latest log directory (`#686 `__) -* Improve type checking (`#679 `__) -* Fixed typos (`#692 `__) -* Pass modules to PythonExpression (`#655 `__) -* Allow ReadyToTest() usage in event handler (`#665 `__) -* Expose emulate_tty to xml and yaml launch (`#669 `__) -* Expose sigterm_timeout and sigkill_timeout to xml frontend (`#667 `__) -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Expect deprecation warnings in tests (`#657 `__) -* Fix the restoring of os.environ to maintain type. (`#656 `__) -* Implement Any, All, Equals, and NotEquals substitutions (`#649 `__) -* add LaunchLogDir substitution, replacing log_dir frontend only substitution (`#652 `__) -* Add special cases to coerce "1" and "0" to bool when using bool coercion only (`#651 `__) -* Update launch/test/launch/test_execute_local.py -* Added unit test ensuring that output dictionary works with ExecuteLocal -* Addresses issue `#588 `__, allowing dict for 'output' -* Remove unused variables. (`#612 `__) -* Expose shutdown action to xml frontend (`#611 `__) -* Contributors: Aditya Pande, Alejandro Hernández Cordero, Audrow Nash, Blake Anderson, Chris Lalancette, Christophe Bedard, Hervé Audren, Jacob Perron, Matthew Elwin, Michael Jeronimo, Nikolai Morin, Welte, William Woodall, Yadu, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed typos (`#692 `__) -* Drop unused data_files entry for example_processes (`#680 `__) -* Spelling correction -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Geoffrey Biggs, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use SomeEntitiesType for type checking. (`#358 `__) -* Fix normalize_parameters_dict for multiple nodes in the same namespace (`#347 `__) -* Implement None check for ComposableNodeContainer (`#341 `__) -* Add LifecyleTransition action (`#317 `__) -* Improve evaluate_paramenter_dict exceptions error message (`#320 `__) -* Ensure load_composable_nodes respects condition (`#339 `__) -* fix: return text value to avoid exception (`#338 `__) -* [rolling] Update maintainers - 2022-11-07 (`#331 `__) -* RosTimer -> ROSTimer and PushRosNamespace -> PushROSNamespace, to follow PEP8 (`#326 `__) -* add SetROSLogDir action (`#325 `__) -* Support default values in parameter substitution (`#313 `__) -* Run condition for composable nodes (`#311 `__) -* Contributors: Aditya Pande, Alexey Merzlyakov, Audrow Nash, Chris Lalancette, Christoph Hellmann Santos, Daisuke Nishimatsu, Felipe Gomes de Melo, Kenji Miyake, William Woodall, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve type checking (`#679 `__) -* Fixed typos (`#692 `__) -* Allow ReadyToTest() usage in event handler (`#665 `__) -* Inherit markers from generate_test_description (`#670 `__) -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Fix Typo (`#641 `__) -* ReadyToTest action timeout using decorator (`#625 `__) -* Switch to using a comprehension for process_names. (`#614 `__) -* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Deepanshu Bansal, Hervé Audren, Kenji Brameld, Nikolai Morin, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_examples `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 for ament_python pkgs (`#357 `__) -* increase the timeout for window platform to avoid flaky test (`#355 `__) -* [rolling] Update maintainers - 2022-11-07 (`#352 `__) -* Increase the WaitForNode timeout. (`#350 `__) -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Increase the timeouts in wait_for_topic_launch_test. (`#360 `__) -* Enable document generation using rosdoc2 (`#359 `__) -* exit() methods should not reraise the passed-in exception (`#357 `__) -* Inherit markers from generate_test_description (`#330 `__) -* [rolling] Update maintainers - 2022-11-07 (`#331 `__) -* Fix long wait during shutdown in WaitForTopics (`#314 `__) -* Contributors: Audrow Nash, Chris Lalancette, Giorgio Pintaudi, Keng12, Scott K Logan, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_xml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed typos (`#692 `__) -* Expose emulate_tty to xml and yaml launch (`#669 `__) -* Expose sigterm_timeout and sigkill_timeout to xml frontend (`#667 `__) -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Contributors: Aditya Pande, Alejandro Hernández Cordero, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_yaml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose emulate_tty to xml and yaml launch (`#669 `__) -* Expose sigterm_timeout and sigkill_timeout to xml frontend (`#667 `__) -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Contributors: Aditya Pande, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libcurl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* merge libcurl_vendor build instructions (`#81 `__) -* Sets CMP0135 policy behavior to NEW (`#79 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 -* Contributors: Cristóbal Arroyo, Crola1702, schrodinbug - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libstatistics_collector `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump hmarr/auto-approve-action from 3.2.0 to 3.2.1 -* Mark benchmark _ as unused. (`#158 `__) -* Bump hmarr/auto-approve-action from 3.1.0 to 3.2.0 -* Bump ros-tooling/action-ros-ci from 0.2 to 0.3 -* Bump pascalgn/automerge-action from 0.15.5 to 0.15.6 -* Update libstatistics_collector to C++17. (`#154 `__) -* Remove unnecessary build dependency on std_msgs. (`#145 `__) -* Bump pascalgn/automerge-action from 0.15.2 to 0.15.3 -* Cleanup the CI jobs on this repository. (`#146 `__) -* Check if message has a "header" field with a stamp subfield of type builtin_interfaces::msg::Time (`#54 `__) -* Mirror rolling to master -* Contributors: Audrow Nash, Chris Lalancette, Scott Mende, dependabot[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libyaml_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix system package dependency (`#54 `__) -* Update libyaml_vendor to C++17. (`#55 `__) -* [rolling] Update maintainers - 2022-11-07 (`#53 `__) -* Remove a warning message. (`#51 `__) -* check if libyaml is already present before building it (take 2) (`#45 `__) -* Mirror rolling to master -* Support WindowsStore builds for ROS2 (`#50 `__) * libyaml for uwp -* Contributors: Audrow Nash, Chris Lalancette, Lou Amadio, Scott K Logan, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update launch file name format to match documentation (`#588 `__) -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette, Patrick Wspanialy - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* lifecycle_msgs: remove non-ASCII chars from field comments (`#147 `__) -* Contributors: Audrow Nash, Chris Lalancette, G.A. vd. Hoorn - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 (`#606 `__) -* update launch file name format to match documentation (`#588 `__) -* Cleanup lifecycle_py to conform to ROS 2 standards. (`#604 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Install the launch file for lifecycle_py. (`#586 `__) -* Contributors: Audrow Nash, Chris Lalancette, Patrick Wspanialy, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`logging_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Change dependency from 'rosidl_cmake' to 'rosidl_default_generators' (`#578 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`map_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers -* Contributors: Audrow Nash, Steve Macenski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mcap_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* mcap_vendor: add readme with versioning procedure (`#1230 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* mcap_vendor: only install public headers (`#1207 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 for mcap_vendor (`#1208 `__) -* mcap_vendor: download MCAP source via tarball (`#1204 `__) -* rosbag2_cpp: test more than one storage plugin (`#1196 `__) -* rosbag2_storage_mcap: merge into rosbag2 repo (`#1163 `__) -* Fix Windows build (`#73 `__) Update mcap version to newest windows-compatible release. Add visibility macros for tests. Add clang-format preprocessor indentation for visibility_control to be readable. -* mcap_vendor: update to v0.6.0 (`#69 `__) -* Cleanup in ``mcap_vendor`` package (`#62 `__) -* Switch to using the vendored zstd library. (`#59 `__) -* Support timestamp-ordered playback (`#50 `__) -* Support regex topic filtering -* Add all lz4 sources to fix undefined symbols at runtime (`#46 `__) -* Upgrade mcap to fix LZ4 error and segfault (`#42 `__) Incorporates fixes from https://github.com/foxglove/mcap/pull/478 and https://github.com/foxglove/mcap/pull/482 -* Add missing buildtool_depend on git (`#37 `__) This vendor package uses git to fetch sources for other packages. It should declare a dependency on that build tool. This should address the current cause of RPM build failures for RHEL: https://build.ros2.org/view/Rbin_rhel_el864/job/Rbin_rhel_el864__mcap_vendor__rhel_8_x86_64__binary/ -* Test Foxy & Galactic in CI, fix missing test_depends in mcap_vendor/package.xml (`#33 `__) -* fix: minor issues (`#31 `__) * remove unnecessary block * use target_link_libraries instead of ament_target_dependencies * remove ros environment * add prefix to compile definition -* Update email address for Foxglove maintainers (`#32 `__) -* Added mcap_vendor package. Updated CMakeLists.txt to fetch dependencies with FetchContent rather than Conan. -* Contributors: Chris Lalancette, Cristóbal Arroyo, Daisuke Nishimatsu, Emerson Knapp, Jacob Bandes-Storch, James Smith, Michael Orlov, Scott K Logan, james-rms - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`message_filters `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update message_filters to C++17. (`#88 `__) -* Fix cache.h std::placeholder namespace (`#87 `__) -* [rolling] Update maintainers - 2022-11-07 (`#85 `__) -* Add a simpler aproximate time sync policy: ApproximateEpsilonTime (`#84 `__) -* Add latest time zero-order-hold sync policy (`#73 `__) -* Fix python examples and add a new example in documentation (`#79 `__) -* Mirror rolling to master -* Adding fix to subscribe() call with raw node pointer and subscriber options (`#76 `__) -* Corrected function arguments in example description (`#35 `__) -* Changed invocation to ``add`` to conform template syntax (`#1388 `__) -* fix sphinx warning (`#1371 `__) -* change invocation to ``add`` to conform template syntax (`#1388 `__) -* fix sphinx warning (`#1371 `__) -* Contributors: Audrow Nash, Carlos Andrés Álvarez Restrepo, Chris Lalancette, Haoru Xue, Ivan Santiago Paunovic, Martin Ganeff, Steve Macenski, andermi - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mimick_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#29 `__) -* Mirror rolling to master -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`nav_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`orocos_kdl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to quote orocos variables when setting targets. (`#12 `__) -* Ensure orocos-kdl is available as a target (`#10 `__) -* Ensure orocos-kdl target references Eigen (`#6 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [master] Update maintainers - 2022-11-07 (`#89 `__) -* Declare test dependencies in [test] extra (`#86 `__) -* Contributors: Audrow Nash, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_testing_tools_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix mpark/variant conditional for MSVC (`#77 `__) -* Changing C++ Compile Version (`#76 `__) -* Update maintainers (`#74 `__) -* Sets CMP0135 policy behavior to NEW (`#73 `__) -* Fixes policy CMP0135 warning in CMake 3.24 (`#71 `__) -* Add cstring include. (`#70 `__) -* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Lucas Wendland, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_control `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change all ROS2 -> ROS 2. (`#610 `__) -* A couple more upgrades to C++17. (`#609 `__) -* Added README.md for pendulum_msgs. (`#577 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette, Gary Bey - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`performance_test_fixture `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Resolve use-after-free compiler warnings (`#24 `__) -* Update performance_test_fixture to C++17. (`#21 `__) -* [rolling] Update maintainers - 2022-11-07 (`#20 `__) -* Mirror rolling to main -* Add "cstring" to the list of includes (`#19 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pluginlib `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainers -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pybind11_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add a modified patch from upstream to support Python 3.11 (`#22 `__) -* Add missing buildtool dependency on git (`#19 `__) -* Update maintainers (`#17 `__) -* Force pybind11 to find Python 3. (`#15 `__) -* Mirror rolling to master -* Update maintainers (`#14 `__) -* Update to pybind11 2.9.1. -* Rename patch file for history continuity. -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Steven! Ragnarök, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#13 `__) -* Mirror rolling to master -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_orocos_kdl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#16 `__) -* Workaround pybind11 CMake error (`#9 `__) -* Contributors: Cristóbal Arroyo, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_qt_binding `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix to allow ninja to use make for generators (`#123 `__) -* Fix flake8 linter regression (`#125 `__) -* Remove pyqt from default binding order for macOS (`#118 `__) -* Demote missing SIP message from WARNING to STATUS (`#122 `__) -* [rolling] Update maintainers - 2022-11-07 (`#120 `__) -* Contributors: Audrow Nash, Christoph Hellmann Santos, Cristóbal Arroyo, Michael Carroll, Rhys Mainwaring, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_dotgraph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in LICENSE file -* Cast drawLine input arguments to int (`#264 `__) (`#265 `__) -* Contributors: Chris Lalancette, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in LICENSE file -* Fix flake8 errors introduced by the previous commit. (`#262 `__) -* Enable basic help information if no plugins are running (`#261 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_app `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in LICENSE file -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in LICENSE file -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix ClassLoader warning by unloading plugin providers. (`#275 `__) -* Chen Lihui -* fix shiboken error (`#267 `__) -* Conditionally run import tests when generators are built (`#269 `__) -* Add in LICENSE file -* Contributors: Chris Lalancette, Christoph Hellmann Santos, Michael Carroll, Rhys Mainwaring, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_py_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in LICENSE file -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use non-deprecated rclpy import. (`#617 `__) -* Change all ROS2 -> ROS 2. (`#610 `__) -* Enable document generation using rosdoc2 (`#606 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Exit with code 0 if ExternalShutdownException is raised (`#581 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Honor ROS_LOCALHOST_ONLY if enabled. (`#1071 `__) -* fix flaky test (`#1063 `__) -* Add enable_type_description_service node option - API only (`#1060 `__) -* Dynamic Subscription (BONUS: Allocators): rcl (`#1057 `__) -* Runtime Interface Reflection: rcl (`#1025 `__) -* [rcl] Improve handling of dynamic discovery (`#1023 `__) -* Use get_type_hash_func for typesupports (`#1055 `__) -* publish for rosout topic multiple times to avoid flaky test (`#1054 `__) -* Switch to target_link_libraries in rcl. (`#1051 `__) -* Calculate type hash from TypeDescription (rep2011) (`#1027 `__) -* Implement matched event (`#1033 `__) -* use user-defined allocator to configure logging. (`#1047 `__) -* user defined allocator should be used for rosout publisher. (`#1044 `__) -* Add in inconsistent_topic implementation. (`#1024 `__) -* doc update, ROS message accessibility depends on RMW implementation. (`#1043 `__) -* Fix some warnings from clang. (`#1042 `__) -* avoid unnecessary copy for rcutils_char_array_vsprintf. (`#1035 `__) -* Service introspection (`#997 `__) -* Cache disable flag to avoid reading environmental variable. (`#1029 `__) -* use parent logger (`#921 `__) -* Add timer on reset callback (`#995 `__) -* Update rcl to C++17. (`#1031 `__) -* Make sure to check the return value of rcl_clock_init in tests. (`#1030 `__) -* Implement rcl_clock_time_started (`#1021 `__) -* Make sure to reset errors more places in the tests. (`#1020 `__) This makes it so we don't get as many warnings when the tests are running. -* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) -* Small cleanups to rcl (`#1013 `__) -* use int64_t for period. (`#1010 `__) -* fixed rcl_wait return error when timer cancelled (`#1003 `__) -* remove duplicate packages in find_package and reorder (`#994 `__) -* Fix buffer overflow in argument parsing caused by lexer returning length beyond length of string (`#979 `__) -* Fix leak in test_subscription_content_filter_options.cpp (`#978 `__) -* Contributors: Audrow Nash, Barry Xu, Brian, Chen Lihui, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Shane Loretz, Tomoya Fujita, mauropasse, methylDragon, 정찬희 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* doc update, ROS message accessibility depends on RMW implementation. (`#1043 `__) -* Update rcl to C++17. (`#1031 `__) -* Reduce result_timeout to 10 seconds. (`#1012 `__) -* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) -* Contributors: Audrow Nash, Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add interfaces for logging service. (`#154 `__) -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Contributors: Audrow Nash, Chris Lalancette, Lei Liu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rcl to C++17. (`#1031 `__) -* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rcl_logging to C++17. (`#98 `__) -* Updated maintainers - 2022-11-07 (`#96 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_noop `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rcl_logging to C++17. (`#98 `__) -* Updated maintainers - 2022-11-07 (`#96 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_spdlog `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Mark the benchmark _ as unused. (`#99 `__) -* Update rcl_logging to C++17. (`#98 `__) -* change flushing behavior for spdlog log files, and add env var to use old style (no explicit flushing) (`#95 `__) * now flushes every ERROR message and periodically every 5 seconds * can set ``RCL_LOGGING_SPDLOG_EXPERIMENTAL_OLD_FLUSHING_BEHAVIOR=1`` to get old behavior -* Updated maintainers - 2022-11-07 (`#96 `__) -* Disable cppcheck for rcl_logging_spdlog. (`#93 `__) -* ament_export_dependencies any package with targets we linked against (`#89 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_yaml_param_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix some warnings from clang. (`#1042 `__) -* Cleanup the dependencies in rcl_yaml_param_parser. (`#1014 `__) -* Update rcl to C++17. (`#1031 `__) -* Support yaml string tag '!!str' (`#999 `__) -* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) -* Contributors: Audrow Nash, Barry Xu, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix delivered message kind (`#2175 `__) (`#2178 `__) -* Add support for logging service. (`#2122 `__) -* Picking ABI-incompatible executor changes (`#2170 `__) -* add events-executor and timers-manager in rclcpp (`#2155 `__) -* Create common structures for executors to use (`#2143 `__) -* Implement deliver message kind (`#2168 `__) -* applied tracepoints for ring_buffer (`#2091 `__) -* Dynamic Subscription (REP-2011 Subset): Stubs for rclcpp (`#2165 `__) -* Add type_hash to cpp TopicEndpointInfo (`#2137 `__) -* Trigger the intraprocess guard condition with data (`#2164 `__) -* Minor grammar fix (`#2149 `__) -* Fix unnecessary allocations in executor.cpp (`#2135 `__) -* add Logger::get_effective_level(). (`#2141 `__) -* Remove deprecated header (`#2139 `__) -* Implement matched event (`#2105 `__) -* use allocator via init_options argument. (`#2129 `__) -* Fixes to silence some clang warnings. (`#2127 `__) -* Documentation improvements on the executor (`#2125 `__) -* Avoid losing waitable handles while using MultiThreadedExecutor (`#2109 `__) -* Hook up the incompatible type event inside of rclcpp (`#2069 `__) -* Update all rclcpp packages to C++17. (`#2121 `__) -* Fix clang warning: bugprone-use-after-move (`#2116 `__) -* Fix memory leak in tracetools::get_symbol() (`#2104 `__) -* Service introspection (`#1985 `__) -* Allow publishing borrowed messages with intra-process enabled (`#2108 `__) -* to fix flaky test about TestTimeSource.callbacks (`#2111 `__) -* to create a sublogger while getting child of Logger (`#1717 `__) -* Fix documentation of Context class (`#2107 `__) -* fixes for rmw callbacks in qos_event class (`#2102 `__) -* Add support for timers on reset callback (`#1979 `__) -* Topic node guard condition in executor (`#2074 `__) -* Fix bug on the disorder of calling shutdown callback (`#2097 `__) -* Add default constructor to NodeInterfaces (`#2094 `__) -* Fix clock state cached time to be a copy, not a reference. (`#2092 `__) -* Fix -Wmaybe-uninitialized warning (`#2081 `__) -* Fix the keep_last warning when using system defaults. (`#2082 `__) -* Add in a fix for older compilers. (`#2075 `__) -* Implement Unified Node Interface (NodeInterfaces class) (`#2041 `__) -* Do not throw exception if trying to dequeue an empty intra-process buffer (`#2061 `__) -* Move event callback binding to PublisherBase and SubscriptionBase (`#2066 `__) -* Implement validity checks for rclcpp::Clock (`#2040 `__) -* Explicitly set callback type (`#2059 `__) -* Fix logging macros to build with msvc and cpp20 (`#2063 `__) -* Add clock type to node_options (`#1982 `__) -* Fix nullptr dereference in prune_requests_older_than (`#2008 `__) -* Remove templating on to_rcl_subscription_options (`#2056 `__) -* Fix SharedFuture from async_send_request never becoming valid (`#2044 `__) -* Add in a warning for a KeepLast depth of 0. (`#2048 `__) -* Mark rclcpp::Clock::now() as const (`#2050 `__) -* Fix a case that did not throw ParameterUninitializedException (`#2036 `__) -* Update maintainers (`#2043 `__) -* MultiThreadExecutor number of threads is at least 2+ in default. (`#2032 `__) -* Fix bug that a callback not reached (`#1640 `__) -* Set the minimum number of threads of the Multithreaded executor to 2 (`#2030 `__) -* check thread whether joinable before join (`#2019 `__) -* Set cpplint test timeout to 3 minutes (`#2022 `__) -* Make sure to include-what-you-use in the node_interfaces. (`#2018 `__) -* Do not clear entities callbacks on destruction (`#2002 `__) -* fix mismatched issue if using zero_allocate (`#1995 `__) -* Make ParameterService and Sync/AsyncParameterClient accept rclcpp::QoS (`#1978 `__) -* support regex match for parameter client (`#1992 `__) -* operator+= and operator-= for Duration (`#1988 `__) -* Revert "Revert "Add a create_timer method to Node and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) (`#2010 `__) -* force compiler warning if callback handles not captured (`#2000 `__) -* Revert "Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) -* Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__) -* [docs] add note about callback lifetime for {on, post}_set_parameter_callback (`#1981 `__) -* fix memory leak (`#1994 `__) -* Support pre-set and post-set parameter callbacks in addition to on-set-parameter-callback. (`#1947 `__) -* Make create_service accept rclcpp::QoS (`#1969 `__) -* Make create_client accept rclcpp::QoS (`#1964 `__) -* Fix the documentation for rclcpp::ok to be accurate. (`#1965 `__) -* use regex for wildcard matching (`#1839 `__) -* Revert "Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__)" (`#1956 `__) -* Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__) -* test adjustment for LoanedMessage. (`#1951 `__) -* fix virtual dispatch issues identified by clang-tidy (`#1816 `__) -* Remove unused on_parameters_set_callback\_ (`#1945 `__) -* Fix subscription.is_serialized() for callbacks with message info (`#1950 `__) -* wait for subscriptions on another thread. (`#1940 `__) -* Fix documentation of ``RCLCPP\_[INFO,WARN,...]`` (`#1943 `__) -* Always trigger guard condition waitset (`#1923 `__) -* Add statistics for handle_loaned_message (`#1927 `__) -* Drop wrong template specialization (`#1926 `__) -* Update get_parameter_from_event to follow the function description (`#1922 `__) -* Add 'best available' QoS enum values and methods (`#1920 `__) -* use reinterpret_cast for function pointer conversion. (`#1919 `__) -* Contributors: Alberto Soragna, Alexander Hans, Alexis Paques, Andrew Symington, Audrow Nash, Barry Xu, Brian, Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, Cristóbal Arroyo, Daniel Reuter, Deepanshu Bansal, Emerson Knapp, Hubert Liberacki, Ivan Santiago Paunovic, Jacob Perron, Jeffery Hsu, Jochen Sprickerhof, Lei Liu, Mateusz Szczygielski, Michael Carroll, Miguel Company, Nikolai Morin, Shane Loretz, Silvio Traversaro, Tomoya Fujita, Tyler Weaver, William Woodall, Yadu, andrei, mauropasse, mergify[bot], methylDragon, schrodinbug, uupks, ymski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* extract the result response before the callback is issued. (`#2132 `__) -* Update all rclcpp packages to C++17. (`#2121 `__) -* Fix the GoalUUID to_string representation (`#1999 `__) -* Explicitly set callback type (`#2059 `__) -* Update maintainers (`#2043 `__) -* Do not clear entities callbacks on destruction (`#2002 `__) -* Revert "Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__)" (`#1956 `__) -* Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__) -* Contributors: Audrow Nash, Chris Lalancette, Hubert Liberacki, Nathan Wiebe Neufeldt, Tomoya Fujita, William Woodall, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_components `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update all rclcpp packages to C++17. (`#2121 `__) -* Improve component_manager_isolated shutdown (`#2085 `__) -* Update maintainers (`#2043 `__) -* use unique ptr and remove unuseful container (`#2013 `__) -* Revert "Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__)" (`#1956 `__) -* Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__) -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Hubert Liberacki, Michael Carroll, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for logging service. (`#2122 `__) -* Support publishing loaned messages in LifecyclePublisher (`#2159 `__) -* Fixes to silence some clang warnings. (`#2127 `__) -* Update all rclcpp packages to C++17. (`#2121 `__) -* Use the correct macro for LifecycleNode::get_fully_qualified_name (`#2117 `__) -* add get_fully_qualified_name to rclcpp_lifecycle (`#2115 `__) -* Implement Unified Node Interface (NodeInterfaces class) (`#2041 `__) -* Add clock type to node_options (`#1982 `__) -* Update maintainers (`#2043 `__) -* LifecycleNode on_configure doc fix. (`#2034 `__) -* Bugfix 20210810 get current state (`#1756 `__) -* Make lifecycle impl get_current_state() const. (`#2031 `__) -* Cleanup the lifecycle implementation (`#2027 `__) -* Cleanup the rclcpp_lifecycle dependencies. (`#2021 `__) -* Revert "Revert "Add a create_timer method to Node and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) (`#2010 `__) -* Revert "Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) -* Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__) -* Support pre-set and post-set parameter callbacks in addition to on-set-parameter-callback. (`#1947 `__) -* Make create_service accept rclcpp::QoS (`#1969 `__) -* Make create_client accept rclcpp::QoS (`#1964 `__) -* Contributors: Andrew Symington, Audrow Nash, Chris Lalancette, Deepanshu Bansal, Ivan Santiago Paunovic, Jeffery Hsu, Lei Liu, Michael Babenko, Shane Loretz, Steve Macenski, Tomoya Fujita, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix type in Node init args (`#1115 `__) (`#1122 `__) -* Logging service support (`#1102 `__) -* Use custom sourcedir for conf.py (`#1109 `__) -* ServerGoalHandle should be destroyed before removing. (`#1113 `__) -* Fix unnecessary list comprehension flake8 (`#1112 `__) -* Stub type hash value line in TopicEndpointInfo string (`#1110 `__) -* Support documentation generation using rosdoc2 (`#1103 `__) -* Fix Time and Duration raising exception when compared to another type (`#1007 `__) -* Make rcl_interfaces a build and exec dependency. (`#1100 `__) -* Solving Atomic undefined on OSX with clang (`#1096 `__) -* Implement matched event (`#1083 `__) -* Update service.py documentation (`#1094 `__) -* Allow space or empty strings when using ros2 param set (`#1093 `__) -* Hook up the incompatible type event inside of rclpy (`#1058 `__) -* Switch to using module instead of module\_ (`#1090 `__) -* Add in subscription.get_publisher_count() (`#1089 `__) -* Service introspection (`#988 `__) -* to create a sublogger while getting child of Logger (`#1084 `__) -* Fix `#983 `__ by saving future and checking for + raising any exceptions (`#1073 `__) -* Force C++17 support on. (`#1076 `__) -* Use RCPPUTILS_SCOPE_EXIT to cleanup unparsed_indices_c. (`#1075 `__) -* Explicitly link atomic when building with Clang (`#1065 `__) -* Fix test_publisher linter for pydocstyle 6.2.2 (`#1063 `__) -* Add default preset qos profile (`#1062 `__) -* Add on_parameter_event method to the AsyncParameterClient. (`#1061 `__) -* Add documentation page for rclpy.clock (`#1055 `__) -* Rewrite test code without depending on parameter client (`#1045 `__) -* Add parallel callback test (`#1044 `__) -* decorator should not be callable. (`#1050 `__) -* typo fix. (`#1049 `__) -* Add in a warning for a depth of 0 with KEEP_LAST. (`#1048 `__) -* Add feature of wait for message (`#953 `__). (`#960 `__) -* Document rclpy.time.Time class (`#1040 `__) -* Deal with ParameterUninitializedException for parameter service (`#1033 `__) -* Improve documentation in rclpy.utilities (`#1038 `__) -* Document rclpy.utilities.remove_ros_args (`#1036 `__) -* Fix incorrect comparsion on whether parameter type is NOT_SET (`#1032 `__) -* [rolling] Update maintainers (`#1035 `__) -* Set the default number of threads of the MultiThreadedExecutor to 2 (`#1031 `__) -* Update the rclpy method documentation. (`#1026 `__) -* Revert "Raise user handler exception in MultiThreadedExecutor. (`#984 `__)" (`#1017 `__) -* Waitable should check callback_group if it can be executed. (`#1001 `__) -* support wildcard matching for params file (`#987 `__) -* Raise user handler exception in MultiThreadedExecutor. (`#984 `__) -* Add wait_for_node method (`#930 `__) -* Create sublogger for action server and action client (`#982 `__) -* Support for pre-set and post-set parameter callback. (`#966 `__) -* fix gcc 7.5 build errors (`#977 `__) -* make _on_parameter_event return result correctly (`#817 `__) -* Fix a small typo in documentation. (`#967 `__) -* Add Parameter Client (`#959 `__) -* Change sphinx theme to readthedocs (`#950 `__) -* Name and type in descriptor(s) is ignored via declare_parameter(s). (`#957 `__) -* Typo fix (`#951 `__) -* Add py.typed to package (`#946 `__) -* Fix rclpy.shutdown() from hanging when triggered from callback (`#947 `__) -* Check if the context is already shutdown. (`#939 `__) -* Avoid causing infinite loop when message is empty (`#935 `__) -* Expose 'best available' QoS policies (`#928 `__) -* remove feedback callback when the goal has been completed. (`#927 `__) -* Allow to create a subscription with a callback that also receives the message info (`#922 `__) -* Contributors: Achille Verheye, Audrow Nash, Barry Xu, Brian, Brian Chen, Chen Lihui, Chris Lalancette, Cristóbal Arroyo, Deepanshu Bansal, Emerson Knapp, Erki Suurjaak, Felix Divo, Florian Vahl, Gonzo, GuiHome, Ivan Santiago Paunovic, Jacob Perron, Lei Liu, Lucas Wendland, Michael Carroll, Sebastian Freitag, Seulbae Kim, Shane Loretz, Steve Nogar, Takeshi Ishita, Tomoya Fujita, Tony Najjar, Yadu, Yuki Igarashi, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcpputils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing header for strlen (`#169 `__) -* issue-167 (`#172 `__) -* [rolling] Update maintainers - 2022-11-07 (`#166 `__) -* require C++17 and deprecate the rcppmath namespace (`#165 `__) -* Mirror rolling to master -* Fix possible race condition in create_directories() (`#162 `__) -* Contributors: Artem Shumov, Audrow Nash, Sebastian Freitag, William Woodall, bijoua29 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix memory leak (`#423 `__) -* Add convenience error handling macros (`#421 `__) -* Calculate the next power-of-two for the user in hash_map_init. (`#420 `__) -* update cast to modern style (`#418 `__) -* Remove deprecated header get_env.h (`#417 `__) -* Updates to rcutils to make rosdoc2 generation happier. (`#416 `__) -* add RCUTILS_LOGGING_AUTOINIT_WITH_ALLOCATOR. (`#415 `__) -* Fix memory leak in string_map.c in rcutils (`#411 `__) -* avoid unnecessary copy for rcutils_char_array_vsprintf. (`#412 `__) -* Add missing stddef include for size_t (`#410 `__) -* Add SHA256 utility implementation (`#408 `__) -* Upgrade rcutils to C++17. (`#392 `__) -* [rolling] Update maintainers - 2022-11-07 (`#404 `__) -* Fix build on OpenHarmony (`#395 `__) -* regression of thread-safety for logging macros (`#393 `__) -* add portable nonnull macros (`#382 `__) -* Fix memory leak when adding the same key to the logger hash map multiple times (`#391 `__) -* time_unix: uses ZEPHYR_VERSION_CODE instead (`#390 `__) -* Cleanup time_unix.c (`#389 `__) -* time_unix: namespace zephyr headers (`#383 `__) -* Restrict overmatching MACH ifdef to only trigger on OSX and Mach (`#386 `__) -* Optimize rcutils_logging_get_logger_effective_level() (`#381 `__) -* Change syntax __VAR_ARGS_\_ to __VA_ARGS_\_ (`#376 `__) -* Fix a bug in hash_map_get_next_key_and_data. (`#375 `__) -* More fixes from review. -* Fixes from review. -* Make g_rcutils_logging_output_handler static. -* Make g_rcutils_logging_default_logger_level static. -* Optimize rcutils_find_lastn where possible. -* Don't bother computing the hash_map key if the hash map is empty. -* Make sure to expand char_array by at least 1.5x. -* Optimize index computation in hash_map_find. -* Improve the performance of rcutils_logging_format_message. (`#372 `__) -* Get rid of unnecessary ret variable. -* Get rid of unnecessary ifdef cplusplus checks in the C file. -* Get rid of unnecessary rcutils_custom_add\_{gtest,gmock} -* Get rid of unnecessary and unused RMW switching for logging tests. -* Remove unnecessary IS_OUTPUT_COLORIZED macro. -* Rename logging internal structures to use our new convention. -* Make all of the logging 'expand' methods static. -* Fix up error checking for RCUTILS_CONSOLE_STDOUT_LINE_BUFFERED. -* Cleanup error handling for the RCUTILS_CONSOLE_OUTPUT_FORMAT checks. -* Revamp error handling in rcutils_logging_initialize_with_allocator. -* Revamp rcutils_logging_initialize_with_allocator. -* Make a few logging global variables static. -* Optimize calls via the RCUTILS_LOG macros. (`#369 `__) -* time_unix: add zephyr posix time (`#368 `__) -* Optimize the implementation of rcutils_char_array_strncpy. (`#367 `__) -* strdup.c: fix arbitrary length overread (`#366 `__) -* Mirror rolling to master -* strdup.c: fix 1 byte buffer overread (`#363 `__) -* Clarify duration arg description in logging macros (`#359 `__) -* Update rcutils_steady_time_now to return the same data as std::chrono (`#357 `__) -* Contributors: AIxWall, Abrar Rahman Protyasha, Audrow Nash, Chen Lihui, Chris Lalancette, Emerson Knapp, Felipe Neves, Jacob Perron, Mario Prats, Maximilian Downey Twiss, Nikolai Morin, Tomoya Fujita, William Woodall, Yakumoo, guijan, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw (`#353 `__) -* Runtime Interface Reflection: rmw (`#340 `__) -* [rmw] Improve handling of dynamic discovery (`#338 `__) -* rmw_send_reqponse returns RMW_RET_TIMEOUT. (`#350 `__) -* Add a note about asynchronicity of discovery. (`#352 `__) -* Add matched event support (`#331 `__) -* Add type hash to rmw_topic_endpoint_info_t (rep2011) (`#348 `__) -* Add in inconsistent topic defines and data structures. (`#339 `__) -* Update documented expectations for GIDs (`#335 `__) -* Fix rmw->rwm typo (`#347 `__) -* Add rmw count clients, services (`#334 `__) -* make writer_guid uint8_t[] instead of int8_t for consistency with rmw_gid_t (`#329 `__) -* Update rmw to C++17. (`#346 `__) -* Reduce GID storage to 16 bytes. (`#345 `__) -* Move the RMW_CHECK_TYPE_IDENTIFIERS_MATCH macro to a C header. (`#343 `__) -* [rolling] Update maintainers - 2022-11-07 (`#337 `__) -* Remove unused test_loaned_message_sequence.cpp (`#336 `__) -* callback can be NULL to clear in Listener APIs. (`#332 `__) -* Add rmw_get_gid_for_client method (`#327 `__) -* Add 'best available' QoS policies (`#320 `__) The best available policy should select the highest level of service for the QoS setting while matching with the majority of endpoints. For example, in the case of a DDS middleware subscription, this means: * Prefer reliable reliability if all existing publishers on the same topic are reliable, otherwise use best effort. * Prefer transient local durability if all existing publishers on the same topic are transient local, otherwise use volatile. * Prefer manual by topic liveliness if all existing publishers on the same topic are manual by topic, otherwise use automatic. * Use a deadline that is equal to the largest deadline of existing publishers on the same topic. * Use a liveliness lease duration that is equal to the largest lease duration of existing publishers on the same topic. -* Move statuses definitions to rmw/events_statuses/ (`#232 `__) -* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jacob Perron, Lee, Minju, Nikolai Morin, Tomoya Fujita, William Woodall, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw_connextdds (`#115 `__) -* Revert "Refactor serialization support to use allocators and refs" -* Refactor serialization support to use allocators and refs -* Add stubs for new rmw interfaces (`#111 `__) -* Add rmw_get_gid_for_client impl (`#92 `__) -* Switch ROS2 -> ROS 2 everywhere (`#83 `__) -* Contributors: Brian, Chris Lalancette, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rmw_connextdds] New RMW discovery options (`#108 `__) -* Call get_type_hash_func (`#113 `__) -* Type hash distribution during discovery (rep2011) (`#104 `__) -* Implement matched event (`#101 `__) -* Add in implementation of inconsistent topic. (`#103 `__) -* Add rmw_get_gid_for_client impl (`#92 `__) -* Fix assert statement to allow the seconds field of a DDS_Duration_t to be zero (`#88 `__) -* Handle 'best_available' QoS policies in common (`#85 `__) -* Resolve build error with RTI Connext DDS 5.3.1 (`#82 `__) -* Contributors: Andrea Sorbini, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Grey, Jose Luis Rivero, Michael Carroll, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextddsmicro `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw_connextdds (`#115 `__) -* Add stubs for new rmw interfaces (`#111 `__) -* Add rmw_get_gid_for_client impl (`#92 `__) -* Switch ROS2 -> ROS 2 everywhere (`#83 `__) -* Contributors: Brian, Chris Lalancette, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_cyclonedds_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw_cyclonedds (`#451 `__) -* Add stubs for new rmw interfaces (`#447 `__) -* [rmw_cyclonedds] Improve handling of dynamic discovery (`#429 `__) -* Call get_type_hash_func (`#448 `__) -* Type hash distribution in discovery (rep2011) (`#437 `__) -* Disable inconsistent topic events. (`#444 `__) -* Implement matched event (`#435 `__) -* Implement inconsistent topic. (`#431 `__) -* Make sure to add semicolons to the CHECK_TYPE_IDENTIFIER_MATCH. (`#432 `__) -* [rolling] Update maintainers - 2022-11-07 (`#428 `__) -* Export CycloneDDS dependency (`#424 `__) -* add NULL check before accessing object. (`#423 `__) -* Add rmw_get_gid_for_client impl (`#402 `__) -* Makes topic_name a const ref -* Adds topic name to error msg when create_topic fails -* Improve error message when create_topic fails (`#405 `__) -* Change wrong use of %d to print uint32_t to PRIu32 (`#253 `__) -* Add cstring include. (`#393 `__) -* Handle 'best_available' QoS policies (`#389 `__) -* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jose Luis Rivero, Shane Loretz, Tomoya Fujita, Tully Foote, Voldivh, eboasson, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_dds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type hash in GraphCache, user_data encoding tools (`#70 `__) -* Mark benchmark _ as unused. (`#71 `__) -* Update rmw_dds_common to C++17. (`#69 `__) -* Change Gid.msg to be 16 bytes. (`#68 `__) -* Minor cleanups of test_qos. (`#67 `__) -* [rolling] Update maintainers - 2022-11-07 (`#65 `__) -* build shared lib only if BUILD_SHARED_LIBS is set (`#62 `__) -* Update maintainers (`#61 `__) -* Add functions for resolving 'best available' QoS policies (`#60 `__) Given a QoS profile and set of endpoints for the same topic, overwrite any policies set to BEST_AVAILABLE with a policy such that it matches all endpoints while maintaining a high level of service. Add testable functions for updating BEST_AVAILABLE policies, * qos_profile_get_best_available_for_subscription * qos_profile_get_best_available_for_publisher and add convenience functions that actual query the graph for RMW implementations to use, * qos_profile_get_best_available_for_topic_subscription * qos_profile_get_best_available_for_topic_publisher -* Contributors: Audrow Nash, Chris Lalancette, Emerson Knapp, Jacob Perron, hannes09, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw_fastrtps (`#687 `__) -* Runtime Interface Reflection: rmw_fastrtps (`#655 `__) -* [rmw_fastrtps] Improve handling of dynamic discovery (`#653 `__) -* Call get_type_hash_func (`#680 `__) -* Type hash distribution in discovery (rep2011) (`#671 `__) -* Implement inconsistent topic event (`#654 `__) -* Update all rmw_fastrtps packages to C++17. (`#674 `__) -* Rewrite how Topics are tracked in rmw_fastrtps_cpp. (`#669 `__) -* Allow loaned messages without data-sharing (`#568 `__) -* Fix incoherent dissociate_writer to dissociate_reader (`#647 `__) (`#649 `__) -* [rolling] Update maintainers - 2022-11-07 (`#643 `__) -* Add rmw_get_gid_for_client impl (`#631 `__) -* Use Fast-DDS Waitsets instead of listeners (`#619 `__) -* Remove rosidl_cmake dependency (`#629 `__) -* Revert "add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__)" (`#612 `__) -* add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__) -* Allow null arguments in the EventsExecutor parameters (`#602 `__) -* Add RMW_CHECKS to rmw_fastrtps_cpp EventsExecutor implementation -* Handle 'best_available' QoS policies (`#598 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jacob Perron, Jose Luis Rivero, Miguel Company, Oscarchoi, Ricardo González, Tomoya Fujita, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_dynamic_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw_fastrtps (`#687 `__) -* Runtime Interface Reflection: rmw_fastrtps (`#655 `__) -* [rmw_fastrtps] Improve handling of dynamic discovery (`#653 `__) -* Call get_type_hash_func (`#680 `__) -* Type hash distribution in discovery (rep2011) (`#671 `__) -* Implement inconsistent topic event (`#654 `__) -* Update all rmw_fastrtps packages to C++17. (`#674 `__) -* Rewrite how Topics are tracked in rmw_fastrtps_cpp. (`#669 `__) -* Allow loaned messages without data-sharing (`#568 `__) -* Fix incoherent dissociate_writer to dissociate_reader (`#647 `__) (`#649 `__) -* [rolling] Update maintainers - 2022-11-07 (`#643 `__) -* Add rmw_get_gid_for_client impl (`#631 `__) -* Use Fast-DDS Waitsets instead of listeners (`#619 `__) -* Revert "add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__)" (`#612 `__) -* add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__) -* Allow null arguments in the EventsExecutor parameters (`#602 `__) -* Add EventExecutor to rmw_fastrtps_dynamic_cpp -* Fix cpplint error (`#601 `__) -* Handle 'best_available' QoS policies (`#598 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jacob Perron, Jose Luis Rivero, Miguel Company, Oscarchoi, Ricardo González, Tomoya Fujita, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_shared_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix matched event issues (`#683 `__) -* Dynamic Subscription (BONUS: Allocators): rmw_fastrtps (`#687 `__) -* Check for triggered guard conditions before waiting (`#685 `__) -* Runtime Interface Reflection: rmw_fastrtps (`#655 `__) -* [rmw_fastrtps] Improve handling of dynamic discovery (`#653 `__) -* Type hash distribution in discovery (rep2011) (`#671 `__) -* Implement matched event (`#645 `__) -* Implement inconsistent topic event (`#654 `__) -* Update all rmw_fastrtps packages to C++17. (`#674 `__) -* Rewrite how Topics are tracked in rmw_fastrtps_cpp. (`#669 `__) -* Delay lock on message callback setters (`#657 `__) -* Make sure to add semicolons to the CHECK_TYPE_IDENTIFIER_MATCH. (`#658 `__) -* Allow loaned messages without data-sharing (`#568 `__) -* Fix incoherent dissociate_writer to dissociate_reader (`#647 `__) (`#649 `__) -* [rolling] Update maintainers - 2022-11-07 (`#643 `__) -* Remove duplicated code (`#637 `__) -* Call callbacks only if unread count > 0 (`#634 `__) -* Add rmw_get_gid_for_client impl (`#631 `__) -* Use Fast-DDS Waitsets instead of listeners (`#619 `__) -* Take all available samples on service/client on_data_available. (`#616 `__) -* Revert "add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__)" (`#612 `__) -* add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__) -* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Michael Carroll, Miguel Company, Oscarchoi, Ricardo González, Tomoya Fujita, mauropasse, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rmw_implementation (`#219 `__) -* Runtime Interface Reflection: rmw_implementation (`#215 `__) -* Mark the benchmark _ variables as unused. (`#218 `__) -* Update rmw_implementation to C++17. (`#214 `__) -* [rolling] Update maintainers - 2022-11-07 (`#212 `__) -* Build-time RMW selection does not need ament_index_cpp (`#210 `__) -* Add rmw_get_gid_for_client & tests (`#206 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, G.A. vd. Hoorn, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#337 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`robot_state_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update robot_state_publisher to C++17. (`#204 `__) -* [rolling] Update maintainers - 2022-11-07 (`#203 `__) -* Mirror rolling to ros2 -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup the help text for ros2 bag record. (`#1329 `__) (`#1333 `__) -* Enable document generation using rosdoc2 for ament_python pkgs (`#1260 `__) -* CLI: Get storage-specific values from plugin (`#1209 `__) -* Fix up some of the wording in the record help text. (`#1228 `__) -* Add topic_name option to info verb (`#1217 `__) -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* rosbag2_py: parametrize tests across storage plugins (`#1203 `__) -* Added option to change node name for the recorder from the Python API (`#1180 `__) -* rosbag2_cpp: test more than one storage plugin (`#1196 `__) -* rosbag2_storage: expose default storage ID as method (`#1146 `__) -* Fix for ros2 bag play exit with non-zero code on SIGINT (`#1126 `__) -* ros2bag: move storage preset validation to sqlite3 plugin (`#1135 `__) -* Add option to prevent message loss while converting (`#1058 `__) -* Added support for excluding topics via regular expressions (`#1046 `__) -* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) -* Add short -v option to ros2 bag list for verbose (`#1065 `__) -* Use a single variable for evaluating the filter regex (`#1053 `__) -* Add additional mode of publishing sim time updates triggered by replayed messages (`#1050 `__) -* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) -* Use first available writer in recording if default ``sqlite3`` not available. (`#1044 `__) -* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) -* Added support for filtering topics via regular expressions on Playback (`#1034 `__) -* Fix incorrect boundary check for ``playback_duration`` and ``play_until_timestamp`` (`#1032 `__) -* Adds play until timestamp functionality (`#1005 `__) -* Add CLI verb for burst mode of playback (`#980 `__) -* Add play-for specified number of seconds functionality (`#960 `__) -* Make unpublished topics unrecorded by default (`#968 `__) -* Contributors: Agustin Alba Chicar, Chris Lalancette, DensoADAS, Emerson Knapp, EsipovPA, Esteve Fernandez, Geoffrey Biggs, Hunter L.Allen, Keisuke Shima, Michael Orlov, Sean Kelly, Tony Peng, Yadu, james-rms, kylemarcey, mergify[bot], ricardo-manriquez - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set automatically_declare_parameters_from_overrides in DirectNode. (`#813 `__) -* Enable document generation using rosdoc2 (`#811 `__) -* Fix linters (`#808 `__) -* add timeout option for ros2param to find node. (`#802 `__) -* Save method list via connection check to XMLRPC server. (`#796 `__) -* ZSH argcomplete: call compinit only if needed (`#750 `__) -* Fix network aware node issue (`#785 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* XMLRPC server accepts request from all local IP addresses. (`#729 `__) -* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Ivan Santiago Paunovic, Tomoya Fujita, Yadu, mjbogusz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli_common_extensions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#7 `__) -* Update maintainers (`#6 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli_test_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Remove action_msgs dependency (`#743 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2component `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 (`#811 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Fix the component load help to mention load, not unload. (`#756 `__) -* Remove unused arguments from ros2 component types. (`#711 `__) -* Contributors: Audrow Nash, Chris Lalancette, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2doctor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Shutdown ros2doctor hello when ctrl-c is received (`#829 `__) -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* Enable document generation using rosdoc2 (`#811 `__) * Fix warnings for ros2component, ros2doctor, ros2interface, and ros2node -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette, Michael Carroll, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* Enable document generation using rosdoc2 (`#811 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#331 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle_test_fixtures `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the ros2cli test fixture to C++17. (`#789 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2multicast `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Add --group and --port options to ros2 multicast (`#770 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2node `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* Enable document generation using rosdoc2 (`#811 `__) * Fix warnings for ros2component, ros2doctor, ros2interface, and ros2node -* Fix linters (`#808 `__) -* add timeout option for ros2param to find node. (`#802 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Updated wording in list.py (`#775 `__) -* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Michael Wrock, Tomoya Fujita, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2param `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* remove deprecated options (`#824 `__) -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* add timeout option for ros2param to find node. (`#802 `__) -* Fix printing of integer and double arrays. (`#804 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* refactor: make ros2param use rclpy.parameter_client (`#716 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2pkg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix typo in ros2pkg warning message. (`#828 `__) -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* resolve `#790 `__ (`#801 `__) -* Add alias library targets for CMake (`#718 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette, Kenji Brameld, RFRIEDM-Trimble, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2run `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#12 `__) -* update maintainer -* Contributors: Audrow Nash, Dharini Dutia, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* remove deprecated options (`#824 `__) -* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) -* Expect type hash cli output in test (`#822 `__) -* Fix the type annotation in pub.py. (`#814 `__) -* Switch to using new event_handler instead of qos_event. (`#787 `__) -* avoid flaky test that subscriber might not receive the message (`#810 `__) -* Adds a ``--max-wait-time`` option to ``ros2 topic pub`` (`#800 `__) -* Fix some flake8 warnings related to style. (`#805 `__) -* Adds a timeout feature to rostopic echo (`#792 `__) -* Refactor common types (`#791 `__) -* Allow configuring liveliness in ros2 topic echo and pub (`#788 `__) -* Extend timeout to shutdown the command line process. (`#783 `__) -* [rolling] Update maintainers - 2022-11-07 (`#776 `__) -* a couple of typo fixes. (`#774 `__) -* Add support use_sim_time for ros2 topic hz/bw/pub. (`#754 `__) -* Use set_message_fields from rosidl_runtime_py (`#761 `__) -* Expand auto to the current time when passed to a Header field (`#749 `__) -* Add verbose option to echo that also prints the associated message info (`#707 `__) -* update docs for bandwidth functions. (`#709 `__) -* Split the bandwidth functions into a get and print. (`#708 `__) -* Contributors: Arjo Chakravarty, Audrow Nash, Chen Lihui, Chris Lalancette, Emerson Knapp, Esteve Fernandez, Ivan Santiago Paunovic, Lei Liu, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Move ros2trace tests to new test_ros2trace package (`#63 `__) -* Error out if trace already exists unless 'append' option is used (`#58 `__) -* Improve 'ros2 trace' command error handling & add end-to-end tests (`#54 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#12 `__) -* update maintainer -* Contributors: Audrow Nash, Dharini Dutia, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) -* Contributors: Emerson Knapp, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in a missing cstdint include. (`#1321 `__) (`#1322 `__) -* Fix warning from ClassLoader in sequential compression reader and writer (`#1299 `__) (`#1316 `__) -* Add message definition read API (`#1292 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* set_read_order: return success (`#1177 `__) -* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) -* Reverse read order API and sqlite storage implementation (`#1083 `__) -* Add option to prevent message loss while converting (`#1058 `__) -* set default metadata of compressed message (in case compressor does not set it) (`#1060 `__) -* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) -* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Hunter L. Allen, Joshua Hampp, Michael Orlov, Tony Peng, james-rms, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression_zstd `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Joshua Hampp, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add recorder stop() API (`#1300 `__) (`#1334 `__) -* Add type_hash in MessageDefinition struct (`#1296 `__) -* Add message definition read API (`#1292 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* Fix for flaky ``TimeControllerClockTest::unpaused_sleep_returns_true`` test (`#1290 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Fix rwm->rmw spelling (`#1249 `__) -* Expose more Writer methods in python interface (`#1220 `__) -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* Parametrize all rosbag2_tests for both supported storage plugins (`#1221 `__) -* rosbag2_cpp: test more than one storage plugin (`#1196 `__) -* Replace language for "db3"/"db"/"database" (`#1194 `__) -* set_read_order: return success (`#1177 `__) -* Remove explicit sqlite3 from code (`#1166 `__) -* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) -* Reader and writer can use default storage by not specifying (`#1167 `__) -* rosbag2_storage: expose default storage ID as method (`#1146 `__) -* Don't reopen file for every seek if we don't have to. Search directionally for the correct file (`#1117 `__) -* Add SplitBagfile recording service. (`#1115 `__) -* Reverse read order API and sqlite storage implementation (`#1083 `__) -* Replace ``std::filesystem::path(..)`` with ``rcpputils::fs::path(..)`` (`#1104 `__) -* Fix issue where sequentialwriter only sets metadata duration to the duration of the final file (`#1098 `__) -* Delete obsolete compression_options.cpp from rosbag2_cpp (`#1078 `__) -* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) -* Remove deprecated rosbag2_cpp/storage_options.hpp, for post-Humble releases (`#1064 `__) -* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) -* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) -* Notification of significant events during bag recording and playback (`#908 `__) -* Bugfix for "Playing the bags recorded with split by duration/size is playing only the last recorded .db3." (`#1022 `__) -* Improve test_time_controller test (`#1012 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Geoffrey Biggs, Hunter L. Allen, Jorge Perez, Joshua Hampp, Kaju-Bubanja, Michael Orlov, Tony Peng, james-rms, mergify[bot], rshanor - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_examples_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Add API samples on main branch - Rolling C++ API examples (`#1068 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Michael Orlov, james-rms - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_examples_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix a warning from python setuptools. (`#1312 `__) (`#1314 `__) -* Add API samples for Python [rebased] (`#1253 `__) * Add API samples for Python * Package Renaming and Move * linting + copyright * more linting --------- Co-authored-by: Geoffrey Biggs -* Contributors: David V. Lu!!, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rosbag2 to C++17. (`#1238 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Add SplitBagfile recording service. (`#1115 `__) -* Adds stop operation for rosbag2::Player (`#1007 `__) -* Notification of significant events during bag recording and playback (`#908 `__) -* Adds play until timestamp functionality (`#1005 `__) -* Add CLI verb for burst mode of playback (`#980 `__) -* Add play-for specified number of seconds functionality (`#960 `__) -* Contributors: Agustin Alba Chicar, Chris Lalancette, Geoffrey Biggs, Michael Orlov, Misha Shalem, rshanor - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_performance_benchmarking `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add tests for rosbag2_performance_benchmarking pkg (`#1268 `__) -* Fix expectations for rosbag2 return code in rosbag2_performance_benchmarking (`#1267 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use thread pool to run benchmark publishers in rosbag2_performance_benchmarking (`#1250 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Skip ament_package() call when not building rosbag2_performance_benchmarking (`#1242 `__) -* Add option to specify a message type (`#1153 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Replace language for "db3"/"db"/"database" (`#1194 `__) -* Remove explicit sqlite3 from code (`#1166 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Michael Orlov, Shane Loretz, carlossvg - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_performance_benchmarking_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add tests for rosbag2_performance_benchmarking pkg (`#1268 `__) -* Skip ament_package() call when not building rosbag2_performance_benchmarking (`#1242 `__) -* [rolling] Bump to 0.19.0 (`#1232 `__) -* Add option to specify a message type (`#1153 `__) -* Contributors: Audrow Nash, Michael Orlov, Shane Loretz, carlossvg - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add binding to close the writer (`#1339 `__) (`#1340 `__) -* Add type_hash in MessageDefinition struct (`#1296 `__) -* Store message definitions in SQLite3 storage plugin (`#1293 `__) -* Add message definition read API (`#1292 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Expose more Writer methods in python interface (`#1220 `__) -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* rosbag2_py: parametrize tests across storage plugins (`#1203 `__) -* Added option to change node name for the recorder from the Python API (`#1180 `__) -* Replace language for "db3"/"db"/"database" (`#1194 `__) -* Remove explicit sqlite3 from code (`#1166 `__) -* Move python get_default_storage_id to storage module instead of writer (`#1165 `__) -* rosbag2_storage: expose default storage ID as method (`#1146 `__) -* rosbag2_py: set defaults for config when bag rewriting (`#1121 `__) -* Reverse read order API and sqlite storage implementation (`#1083 `__) -* expose py Reader metadata, improve ``rosbag2_py.BagMetadata`` usability (`#1082 `__) -* Added support for excluding topics via regular expressions (`#1046 `__) -* Use a single variable for evaluating the filter regex (`#1053 `__) -* Add additional mode of publishing sim time updates triggered by replayed messages (`#1050 `__) -* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) -* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) -* Added support for filtering topics via regular expressions on Playback (`#1034 `__) -* Adds play until timestamp functionality (`#1005 `__) -* Add CLI verb for burst mode of playback (`#980 `__) -* Add play-for specified number of seconds functionality (`#960 `__) -* Make unpublished topics unrecorded by default (`#968 `__) -* Fix test rosbag2_py test compatibility with Python < 3.8 (`#987 `__) -* Contributors: Agustin Alba Chicar, Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Esteve Fernandez, Geoffrey Biggs, Hunter L. Allen, Michael Orlov, Scott K Logan, Sean Kelly, Tony Peng, james-rms, kylemarcey, mergify[bot], ricardo-manriquez - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add type_hash in MessageDefinition struct (`#1296 `__) -* Add message definition read API (`#1292 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* set_read_order: return success (`#1177 `__) -* Remove explicit sqlite3 from code (`#1166 `__) -* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) -* rosbag2_storage: expose default storage ID as method (`#1146 `__) -* Don't reopen file for every seek if we don't have to. Search directionally for the correct file (`#1117 `__) -* Reverse read order API and sqlite storage implementation (`#1083 `__) -* Remove YAML_CPP_DLL define (`#964 `__) -* Added support for excluding topics via regular expressions (`#1046 `__) -* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) -* Use a single variable for evaluating the filter regex (`#1053 `__) -* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) -* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) -* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) -* Added support for filtering topics via regular expressions on Playback (`#1034 `__) -* Contributors: Akash, Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Esteve Fernandez, Hunter L. Allen, Joshua Hampp, Michael Orlov, Tony Peng, james-rms - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) -* Reverse read order API and sqlite storage implementation (`#1083 `__) -* Add support for old db3 schema used on distros prior to Foxy (`#1090 `__) -* Added support for excluding topics via regular expressions (`#1046 `__) -* Contributors: Emerson Knapp, Esteve Fernandez, Michael Orlov, james-rms - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_mcap `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add type_hash in MessageDefinition struct (`#1296 `__) -* Add message definition read API (`#1292 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* CLI: Get storage-specific values from plugin (`#1209 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* rosbag2_cpp: test more than one storage plugin (`#1196 `__) -* set_read_order: return success (`#1177 `__) -* rosbag2_storage_mcap: merge into rosbag2 repo (`#1163 `__) -* mcap_storage: 'none' is a valid storage preset profile (`#86 `__) -* mcap_storage: handle update_metadata call (`#83 `__) -* Update clang-format rules to fit ROS 2 style guide (`#80 `__) -* Revert "read_order: throw exception from set_read_order for unsupported orders" -* read_order: throw exception from set_read_order for unsupported orders -* Fix compile flags to work on rosbag_storage:0.17.x (`#78 `__) -* Fix Windows build (`#73 `__) -* set defaults for SQLite plugin parity (`#68 `__) -* rosbag2_storage_mcap: add storage preset profiles (`#57 `__) -* rename test_fixture_interfaces package to testdata (`#64 `__) -* Switch to using the vendored zstd library. (`#59 `__) -* Add set_read_order reader API (`#54 `__) -* Some minor improvements in rosbag2_storage_mcap after review (`#58 `__) -* Revert "rosbag2_storage_mcap: add storage preset profiles" -* rosbag2_storage_mcap: add storage preset profiles -* Store IDL message definitions in Schema records when no MSG definition is available (`#43 `__) -* Support timestamp-ordered playback (`#50 `__) -* Support regex topic filtering -* Add all lz4 sources to fix undefined symbols at runtime (`#46 `__) -* Upgrade mcap to fix LZ4 error and segfault (`#42 `__) -* Fix build for Foxy (`#34 `__) -* fix: minor issues (`#31 `__) * remove unnecessary block * use target_link_libraries instead of ament_target_dependencies * remove ros environment * add prefix to compile definition -* Update email address for Foxglove maintainers (`#32 `__) -* Added mcap_vendor package. Updated CMakeLists.txt to fetch dependencies with FetchContent rather than Conan. -* CMake build script will now execute pip install conan automatically. -* [1.0.0] Use Summary section for get_metadata() and seek(), implement remaining methods (`#17 `__) -* feat: add play impl (`#16 `__) -* chore: refine package.xml (`#15 `__) -* Don't throw when READ_WRITE mode is used; add .mcap file extension to recorded files (`#14 `__) -* Add dynamic message definition lookup (`#13 `__) -* Switch C++ formatter to clang-format (`#12 `__) -* Merge pull request `#7 `__ from ros-tooling/jhurliman/reader-writer -* uninitialized struct -* lint -* lint -* lint -* Reader and writer implementation -* Merge pull request `#6 `__ from wep21/add-metadata-impl -* feat: add metadata impl -* Merge pull request `#5 `__ from wep21/mcap-storage-impl -* chore: update cmake minimum version -* chore: install mcap header -* chore: include mcap header -* fix: move fetch content into rosbag2 storage mcap -* Merge pull request `#3 `__ from ros-tooling/emersonknapp/mcap_plugin_skeleton -* Add rosbag2_storage_mcap skeleton -* Contributors: Andrew Symington, Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Jacob Bandes-Storch, James Smith, John Hurliman, Michael Orlov, james-rms, wep21 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_sqlite3 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add type_hash in MessageDefinition struct (`#1296 `__) -* Store message definitions in SQLite3 storage plugin (`#1293 `__) -* Add message definition read API (`#1292 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* CLI: Get storage-specific values from plugin (`#1209 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Remove sqlite3-specific info from main README, make it more storage agnostic and point to plugin-specific README (`#1193 `__) -* set_read_order: return success (`#1177 `__) -* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) -* Store db schema version and ROS_DISTRO name in db3 files (`#1156 `__) -* ros2bag: move storage preset validation to sqlite3 plugin (`#1135 `__) -* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) -* Use a single variable for evaluating the filter regex (`#1053 `__) -* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) -* Added support for filtering topics via regular expressions on Playback (`#1034 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Esteve Fernandez, Michael Orlov, james-rms - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) (`#1330 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* rosbag2_py: parametrize tests across storage plugins (`#1203 `__) -* Fix for ros2 bag play exit with non-zero code on SIGINT (`#1126 `__) -* Split up the include of rclcpp.hpp (`#1027 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, Michael Orlov, james-rms, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_msgdefs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) The intention of this PR is to move the message-definition-finding capability outside of rosbag2_storage_mcap, and allow any rosbag2 storage plugin to store message definitions. -* Contributors: james-rms - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) (`#1330 `__) -* Add type_hash in MessageDefinition struct (`#1296 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Parametrize all rosbag2_tests for both supported storage plugins (`#1221 `__) -* Make rosbag2_tests agnostic to storage implementation (`#1192 `__) -* Get rid from attempt to open DB file in ``wait_for_db()`` test fixture (`#1141 `__) -* Fix for ros2 bag play exit with non-zero code on SIGINT (`#1126 `__) -* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) -* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) -* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Hunter L. Allen, Michael Orlov, Tony Peng, james-rms, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change subscriptions from GenericSubscripton to SubscriptionBase (`#1338 `__) -* Add recorder stop() API (`#1300 `__) (`#1334 `__) -* Read message definitions from input files in bag_rewrite (`#1295 `__) -* Add message definition read API (`#1292 `__) -* Move rosbag2_transport::Recorder implementation to pimpl (`#1291 `__) -* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) -* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) -* Use RMW methods to initialize endpoint info instead of brace initializer to guard against upcoming struct change (`#1257 `__) -* Update rosbag2 to C++17. (`#1238 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) -* Print "Hidden topics are not recorded" only once. (`#1225 `__) -* rosbag2_storage: set MCAP as default plugin (`#1160 `__) -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* rosbag2_transport: parametrize test_rewrite (`#1206 `__) -* rosbag2_cpp: test more than one storage plugin (`#1196 `__) -* Replace language for "db3"/"db"/"database" (`#1194 `__) -* set_read_order: return success (`#1177 `__) -* Remove explicit sqlite3 from code (`#1166 `__) -* Add pause and resume service calls for rosbag2 recorder (`#1131 `__) -* Redesign record_services tests to make them more deterministic (`#1122 `__) -* Add SplitBagfile recording service. (`#1115 `__) -* Reverse read order API and sqlite storage implementation (`#1083 `__) -* make recorder node composable by inheritance (`#1093 `__) -* Mark ``test_play_services`` as xfail for FastRTPS and CycloneDDS (`#1091 `__) -* fixed typo (`#1057 `__) -* Fix hangout in rosbag2 player and recorder when pressing ``CTRL+C`` (`#1081 `__) -* Added support for excluding topics via regular expressions (`#1046 `__) -* Use a single variable for evaluating the filter regex (`#1053 `__) -* Add additional mode of publishing sim time updates triggered by replayed messages (`#1050 `__) -* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) -* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) -* Refactor play until and duration tests (`#1024 `__) -* Added support for filtering topics via regular expressions on Playback (`#1034 `__) -* Adds stop operation for rosbag2::Player (`#1007 `__) -* Fix incorrect boundary check for ``playback_duration`` and ``play_until_timestamp`` (`#1032 `__) -* Split up the include of rclcpp.hpp (`#1027 `__) -* Notification of significant events during bag recording and playback (`#908 `__) -* Adds play until timestamp functionality (`#1005 `__) -* Add CLI verb for burst mode of playback (`#980 `__) -* Add on play message callbacks to the ``rosbag2::Player`` class (`#1004 `__) -* Add play-for specified number of seconds functionality (`#960 `__) -* Reduce message spam when topics to be recorded do not exist (`#1018 `__) -* Address flakiness in record_all_with_sim_time test (`#1014 `__) -* Add debug instrumentation for ``test_play_services`` (`#1013 `__) -* Fix for rosbag2::Player freeze when pressing ctrl+c in pause mode (`#1002 `__) -* Add the /bigobj flag to Windows Debug builds. (`#1009 `__) -* Make unpublished topics unrecorded by default (`#968 `__) -* Make peek_next_message_from_queue return a SharedPtr. (`#993 `__) -* Change the topic names in test_record.cpp (`#988 `__) -* Contributors: Agustin Alba Chicar, Bernardo Taveira, Brian, Chris Lalancette, Cristóbal Arroyo, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Esteve Fernandez, Geoffrey Biggs, Jorge Perez, Joshua Hampp, Michael Orlov, Misha Shalem, Sean Kelly, Tony Peng, james-rms, kylemarcey, mergify[bot], rshanor - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosgraph_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_adapter `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rosidl_adapter/cmake/rosidl_adapt_interfaces.cmake: Make ament free (`#709 `__) -* [service introspection] generate service_event messages (`#700 `__) -* Adding tests for unicode support in message comments. (`#720 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Add action2idl script (`#654 `__) -* Contributors: Audrow Nash, Brian, Guilherme Henrique Galelli Christmann, John Daktylidis, Yasushi SHOJI - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix warnings (`#726 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Contributors: Audrow Nash, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Skip rosidl_generate_interfaces dependency export on SKIP_INSTALL. (`#708 `__) -* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. -* Fix comment in camel case conversion function (`#683 `__) -* Protect rosidl_target_interfaces from using NOTFOUND in include_directories (`#679 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron, Jose Luis Rivero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_core_generators `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#2 `__) -* Add generators and runtime configuration packages (`#1 `__) Moved (and renamed) from rosidl_defaults. Related PR: https://github.com/ros2/rosidl_defaults/pull/22 -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_core_runtime `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#2 `__) -* Add generators and runtime configuration packages (`#1 `__) Moved (and renamed) from rosidl_defaults. Related PR: https://github.com/ros2/rosidl_defaults/pull/22 -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_generators `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add service_msgs depend (`#24 `__) -* [rolling] Update maintainers - 2022-11-07 (`#25 `__) -* Move dependencies to rosidl_core and depend on action_msgs (`#22 `__) Move implementation to new packages rosidl_core_generators and rosidl_runtime_generators The new packages are located in a separate repository: https://github.com/ros2/rosidl_core.git rosidl_defaults now depends on the new packages, plus message definitions required for Actions (namely action_msgs). This allows users to avoid having to explictly depend on action_msgs. -* Contributors: Audrow Nash, Brian, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_runtime `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add service_msgs depend (`#24 `__) -* [rolling] Update maintainers - 2022-11-07 (`#25 `__) -* Move dependencies to rosidl_core and depend on action_msgs (`#22 `__) Move implementation to new packages rosidl_core_generators and rosidl_runtime_generators The new packages are located in a separate repository: https://github.com/ros2/rosidl_core.git rosidl_defaults now depends on the new packages, plus message definitions required for Actions (namely action_msgs). This allows users to avoid having to explictly depend on action_msgs. -* Contributors: Audrow Nash, Brian, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_dynamic_typesupport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix up the exports for rosidl_dynamic_typesupport. (`#5 `__) -* Refactor dynamic message type support impl to use allocators (`#2 `__) -* Runtime Interface Reflection: rosidl_dynamic_typesupport (`#1 `__) -* Contributors: Chris Lalancette, William Woodall, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_dynamic_typesupport_fastrtps `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove more unnecessary semicolons (`#4 `__) -* Dynamic Subscription (BONUS: Allocators): rosidl_dynamic_typesupport_fastrtps (`#3 `__) -* Remove unnecessary semicolons. (`#2 `__) -* Runtime Interface Reflection: rosidl_dynamic_typesupport_fastrtps (`#1 `__) -* Contributors: Chris Lalancette, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Expose type hash on typesupports (rep2011) (`#729 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Move rosidl_generator_c/cpp tests to a separate package (`#701 `__) -* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. -* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) -* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Expose type hash on typesupports (rep2011) (`#729 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Move rosidl_generator_c/cpp tests to a separate package (`#701 `__) -* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. -* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) -* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_dds_idl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#60 `__) -* Replace rosidl_cmake imports with rosidl_pycommon (`#59 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Hides the assertions that checks the data types of the message fields. (`#194 `__) -* Service introspection (`#178 `__) -* [rolling] Update maintainers - 2022-11-07 (`#189 `__) -* Remove stray numpy import (`#185 `__) -* :man_farmer: Fix NaN values bound numpy windows version (`#182 `__) -* Allow NaN values to pass floating point bounds check. (`#167 `__) -* Replace rosidl_cmake imports with rosidl_pycommon (`#177 `__) -* Change decode error mode to replace (`#176 `__) -* Merge pull request `#173 `__ from ros2/quarkytale/fix_import_order -* fix flake -* sorting after conversion -* Revert "Use modern cmake targets to avoid absolute paths to appear in binary archives (`#160 `__)" (`#166 `__) -* Use modern cmake targets to avoid absolute paths to appear in binary archives (`#160 `__) -* michel as author -* adding maintainer -* Contributors: Audrow Nash, Ben Wolsieffer, Brian, Cristóbal Arroyo, Dharini Dutia, Eloy Briceno, Ivan Santiago Paunovic, Jacob Perron, Tomoya Fujita, quarkytale, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [service introspection] generate service_event messages (`#700 `__) * add service event message -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Move rosidl_generator_c/cpp tests to a separate package (`#701 `__) -* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_type_description `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Expose type hash on typesupports (rep2011) (`#729 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* Contributors: Emerson Knapp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Always include whitespace in string literals (`#688 `__) -* Contributors: Audrow Nash, Brian, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. -* Contributors: Audrow Nash, Emerson Knapp, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Dynamic Subscription (BONUS: Allocators): rosidl (`#737 `__) -* Runtime Interface Reflection: rosidl (`#728 `__) -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Copied type_description_interfaces structs (rep2011) (`#732 `__) -* Expose type hash on typesupports (rep2011) (`#729 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Contributors: Audrow Nash, Brian, Emerson Knapp, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Copied type_description_interfaces structs (rep2011) (`#732 `__) -* Fix a few more clang analysis problems. (`#731 `__) -* Return reference from BoundedVector::emplace_back (`#730 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* fix conversion to ‘std::streamsize’ {aka ‘long int’} from ‘size_t’ {aka ‘long unsigned int’} may change the sign of the result (`#715 `__) -* Contributors: Alexander Hans, Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, ralwing - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace the use __slots_\_ for the appropiate API (`#23 `__) -* fix(typing): ``get_interface_packages`` returns a dict (`#22 `__) -* [rolling] Update maintainers - 2022-11-07 (`#21 `__) -* Expand timestamps for std_msgs.msg.Header and builtin_interfaces.msg.Time if 'auto' and 'now' are passed as values (`#19 `__) -* Document a missing parameter in message_to_yaml. (`#18 `__) -* Mirror rolling to master -* Contributors: Audrow Nash, Chris Lalancette, Eloy Briceno, Esteve Fernandez, 兰陈昕 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Nested Support (`#141 `__) -* Fix rosidl_typesupport_c/cpp exec dependencies. (`#140 `__) -* Type hashes in typesupport (rep2011) (`#135 `__) -* Mark benchmark _ as UNUSED. (`#134 `__) -* Service introspection (`#127 `__) -* Update rosidl_typesupport to C++17. (`#131 `__) -* [rolling] Update maintainers - 2022-11-07 (`#130 `__) -* Replace rosidl_cmake imports with rosidl_pycommon (`#126 `__) -* [service introspection] Use stddef.h instead of cstddef (`#125 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Nested Support (`#141 `__) -* Fix rosidl_typesupport_c/cpp exec dependencies. (`#140 `__) -* Type hashes in typesupport (rep2011) (`#135 `__) -* Mark benchmark _ as UNUSED. (`#134 `__) -* Service introspection (`#127 `__) -* Update rosidl_typesupport to C++17. (`#131 `__) -* [rolling] Update maintainers - 2022-11-07 (`#130 `__) -* Replace rosidl_cmake imports with rosidl_pycommon (`#126 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Nested Support (`#101 `__) -* Type hashes on typesupport (rep2011) (`#98 `__) -* Expose type hash to typesupport structs (rep2011) (`#95 `__) -* Mark benchmark _ as UNUSED. (`#96 `__) -* Service introspection (`#92 `__) -* Update rosidl_typesupport_fastrtps to C++17. (`#94 `__) -* [rolling] Update maintainers - 2022-11-07 (`#93 `__) -* Replace rosidl_cmake imports with rosidl_pycommon (`#91 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Nested Support (`#101 `__) -* Type hashes on typesupport (rep2011) (`#98 `__) -* Depend on ament_cmake_ros to default SHARED to ON (`#99 `__) -* Expose type hash to typesupport structs (rep2011) (`#95 `__) -* Mark benchmark _ as UNUSED. (`#96 `__) -* Service introspection (`#92 `__) -* Update rosidl_typesupport_fastrtps to C++17. (`#94 `__) -* [rolling] Update maintainers - 2022-11-07 (`#93 `__) -* Replace rosidl_cmake imports with rosidl_pycommon (`#91 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron, Tyler Weaver - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Contributors: Audrow Nash, Brian - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Expose type hash on typesupports (rep2011) (`#729 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. -* Fix build export dependencies in C introspection package (`#695 `__) -* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) -* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Type Description Codegen and Typesupport (rep2011) (`#727 `__) -* Expose type hash on typesupports (rep2011) (`#729 `__) -* Type hash in interface codegen (rep2011) (`#722 `__) -* Make sure to add the event message to typesupport introspection cpp. (`#724 `__) -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. -* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix a few more clang analysis problems. (`#731 `__) In particular, make sure to mark the fact that we are C++17 (as the emplace_back signature changed), and also add in a few more (void)_ for benchmark tests. -* [service introspection] generate service_event messages (`#700 `__) -* [rolling] Update maintainers - 2022-11-07 (`#717 `__) -* Contributors: Audrow Nash, Brian, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* typesupport_tests needs to be updated to C++17 (`#137 `__) -* Fix Typesupport Introspection tests (`#133 `__) -* Make rosidl_typesupport_tests depend on rosidl_generator_cpp. (`#132 `__) -* Service introspection (`#127 `__) -* Contributors: Brian, Chris Lalancette, Cristóbal Arroyo, Lucas Wendland - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rpyutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#10 `__) -* Mirror rolling to master -* updating maintainer -* Contributors: Audrow Nash, Dharini Dutia - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix build of ``rqt`` with ``setuptools>=v61.0.0`` (`#271 `__) -* [rolling] Update maintainers - 2022-11-07 (`#283 `__) -* Fix up the package description. (`#250 `__) -* Contributors: Audrow Nash, Chris Lalancette, Daniel Reuter, Dharini Dutia, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#14 `__) -* Small cleanups to the rqt_action plugin (`#13 `__) -* Mirror rolling to ros2 -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use default storage id (`#140 `__) -* Use rosbag2_py API instead of direct bag parsing -* [rolling] Update maintainers - 2022-11-07 (`#132 `__) -* For get_entry_after, bump by 1 nanosecond otherwise always get the same message equal to the timestamp -* Use rosbag2_py.reader for all message queries, remove sqlite3 direct usage -* Cleanup for review -* Improved logging -* Use a rosbag2_py.Reader to get bag metadata -* Disable reading from bag while recording - use direct caching to index for timeline -* Increase publishing checkbox size (`#122 `__) -* Fix toggle thumbnails button (`#117 `__) -* ensure data types match what PyQt expects (`#118 `__) -* Visualize topics being published and highlight topic being selected (`#116 `__) -* Be able to scroll up and down, not only zoom-in and out the timeline (`#114 `__) -* [Fixes] Fix crash when no qos metadata, make scroll bar appear if needed, add gitignore (`#113 `__) -* Fix the types being passed into QFont and QColor. (`#109 `__) -* Fix tuples for bisect calls (`#67 `__) (`#76 `__) -* fix long topic names (`#114 `__) -* fix zoom behavior (`#76 `__) -* Contributors: Audrow Nash, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Kenji Brameld, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changes the use of __slots_\_ for the field and field type getter (`#138 `__) -* [rolling] Update maintainers - 2022-11-07 (`#132 `__) -* Contributors: Audrow Nash, Eloy Briceno - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#39 `__) -* added new maintainer -* Contributors: Arne Hitzmann, Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_graph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Refresh rosgraph when params checkbox is clicked (`#87 `__) -* [rolling] Update maintainers - 2022-11-07 (`#83 `__) -* Minor cleanup (`#80 `__) -* Mirror rolling to galactic-devel -* graph load/save into DOT file corrections for py3 (`#78 `__) -* Remove repeated prefixes from buttons -* Contributors: Audrow Nash, Chris Lalancette, David V. Lu!!, Yadunund, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#283 `__) -* Display basic help information when no plugins are loaded (`#268 `__) -* Contributors: Audrow Nash, Dharini Dutia, Michael Jeronimo, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rqt to C++17. (`#285 `__) -* [rolling] Update maintainers - 2022-11-07 (`#283 `__) -* Contributors: Audrow Nash, Chris Lalancette, Dharini Dutia, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix an exception raised when terminating with Ctrl+c (`#292 `__) -* [rolling] Update maintainers - 2022-11-07 (`#283 `__) -* Contributors: Audrow Nash, Chen Lihui, Dharini Dutia, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_msg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#17 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_plot `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix regression from #87 (`#91 `__) -* Changes the use of __slots_\_ for the field and field type getter (`#87 `__) -* [rolling] Update maintainers - 2022-11-07 (`#83 `__) -* Fix fixed-size Array visualization (`#81 `__) -* Contributors: Audrow Nash, Eloy Briceno, Jacob Perron, Michael Jeronimo, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changes the use of __slots_\_ for the field and field type getter -* [rolling] Update maintainers - 2022-11-07 (`#36 `__) -* Minor cleanups in rqt_publisher for ROS 2 (`#35 `__) -* Delete sync to foxy-devel workflow -* Merge pull request `#33 `__ from NBadyal/improve-evaluation-of-types -* Use regex matching to strip errors from input -* Change slot_type verification strategy -* Mirror rolling to foxy-devel -* Contributors: Audrow Nash, Chris Lalancette, Geoffrey Biggs, Michael Jeronimo, Nicholas Badyal, Voldivh - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changes the use of __slots_\_ for the field and field type getter (`#289 `__) -* [rolling] Update maintainers - 2022-11-07 (`#283 `__) -* Contributors: Audrow Nash, Dharini Dutia, Eloy Briceno, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#13 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_reconfigure `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* reorder imports to fix flake8 warning (`#129 `__) -* Fixed validator locale when float value is not bound in a range. (`#121 `__) -* get parameter type from descriptor -* [rolling] Update maintainers - 2022-11-07 (`#122 `__) -* Cleanup mislabeled BSD license (`#66 `__) -* Add support for array types (`#108 `__) -* Fix float slider step size (`#117 `__) -* update maintainer -* Fixed package to run with ros2 run (`#81 `__) -* fix updating range limits (`#108 `__) -* Improvement; "GUI hangs for awhile or completely, when any one of nodes doesn't return any value" (`#81 `__) -* Contributors: Aris Synodinos, Audrow Nash, Christian Rauch, Dharini Dutia, Florian Vahl, Jacob Perron, Shrijit Singh, Tully Foote, quarkytale - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_service_caller `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#25 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_shell `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#17 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_srv `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#10 `__) -* Contributors: Audrow Nash, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#43 `__) -* Implement bandwidth monitoring (`#40 `__) -* Fix the display of array type elements. (`#41 `__) -* Fix removal of topics while they are being monitored. (`#39 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rti_connext_dds_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use unified approach for checking the existence of environment variables (`#117 `__) -* Contributors: Christopher Wecht - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rttest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#121 `__) -* Addressing issues found in Humble testing (`#116 `__) -* Contributors: Audrow Nash, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make rviz1_to_rviz2.py accept configs with missing values (`#945 `__) -* Update rviz to C++17. (`#939 `__) -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* Add rviz1_to_rviz2.py conversion script (`#882 `__) -* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_assimp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* If vendored assimp is present, always prefer that (`#970 `__) -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#898 `__) -* Contributors: Audrow Nash, Cristóbal Arroyo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update Frame shortcut (`#958 `__) * Update Frame shortcut -* Update rviz to C++17. (`#939 `__) -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* Remove YAML_CPP_DLL define (`#831 `__) -* Document getTransform() time behavior (`#893 `__) -* Ogre 1.12.10 upgrade (`#878 `__) -* Add RVIZ_COMMON_PUBLIC macro (`#865 `__) -* Add time jump handler (`#752 `__) (`#791 `__) -* Make sure not to dereference a null Renderable pointer. (`#850 `__) -* Contributors: Akash, Audrow Nash, Chris Lalancette, David V. Lu!!, Kenji Brameld, Marcel Zeilinger, Shane Loretz, juchajam - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix ODR errors with gmock (`#967 `__) -* Update Frame shortcut (`#958 `__) -* point_marker: fix bug where the number of rendered points accumulates over time (`#949 `__) -* Update rviz to C++17. (`#939 `__) -* Fix tolerance calculation precision (`#934 `__) -* Fix MeshResourceMarker for mesh with color-based embedded material (`#928 `__) -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* Add Map Display binary option (`#846 `__) -* Delete frame_locked_markers when reusing marker (`#907 `__) -* Consider region of interest in CameraDisplay (`#864 `__) -* std::copy fix - OccupancyGridUpdate - Data is not being processed correctly (`#895 `__) -* Set error status when duplicate markers are in the same MarkerArray (`#891 `__) -* Make Axes display use latest transform (`#892 `__) -* Show link names in inertia error message (`#874 `__) -* Ogre 1.12.10 upgrade (`#878 `__) -* Use make_shared to construct PointCloud2 (`#869 `__) -* Fix include order (`#858 `__) -* Contributors: AndreasR30, Audrow Nash, Chris Lalancette, David V. Lu!!, Eric, Hunter L. Allen, Jacob Perron, Kenji Brameld, Patrick Roncagliolo, Shane Loretz, Timon Engelke, Xavier BROQUERE, Xenofon Karamanos, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_ogre_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix build failures on macOS + Apple Silicon (`#944 `__) -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* Remove broken rviz_ogre_vendor::RenderSystem_GL target (`#920 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#898 `__) -* Ogre 1.12.10 upgrade (`#878 `__) -* Make resource file paths relative (`#862 `__) -* Use CMAKE_STAGING_PREFIX for staging OGRE installation (`#861 `__) -* Contributors: Audrow Nash, Cristóbal Arroyo, Kenji Brameld, Scott K Logan, Shane Loretz, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* add test to ensure binary STL files from SOLIDWORKS get imported without a warning (`#917 `__) -* Ogre 1.12.10 upgrade (`#878 `__) -* Stop using glsl150 resources for now. (`#851 `__) -* Contributors: Audrow Nash, Chris Lalancette, Kenji Brameld - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* add test to ensure binary STL files from SOLIDWORKS get imported without a warning (`#917 `__) -* Contributors: Audrow Nash, Kenji Brameld - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_visual_testing_framework `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rviz to C++17. (`#939 `__) -* [rolling] Update maintainers - 2022-11-07 (`#923 `__) -* Ogre 1.12.10 upgrade (`#878 `__) -* Contributors: Audrow Nash, Chris Lalancette, Kenji Brameld - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update YUV format codes and documentation (`#214 `__) -* sensor_msgs/Range lacks variance field (`#181 `__) -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Replaced non-ASCII dash symbol with ASCII dash (`#208 `__) -* Add NV21 and NV24 to colour formats (`#205 `__) -* Update BatteryState.msg (`#206 `__) -* use regex for matching cv types (`#202 `__) -* Fix outdated file path for image_encodings (`#200 `__) -* Use uint32_t for pointcloud2 resize method (`#195 `__) -* Retain width and height after resize for master (`#193 `__) -* Contributors: Audrow Nash, Borong Yuan, Chris Lalancette, Christian Rauch, El Jawad Alaa, Geoffrey Biggs, Ivan Zatevakhin, Kenji Brameld, Tianyu Li - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing dep for sensor_msgs_py (`#217 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Add support for non standard point step sizes (`#199 `__) -* Remove reference to old implementation (`#198 `__) -* Contributors: Audrow Nash, Florian Vahl, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`service_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* Add service_msgs package (`#143 `__) -* Contributors: Brian, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shape_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Fix SolidPrimitive.msg to contain a single Polygon (`#189 `__) -* Contributors: Audrow Nash, Chris Lalancette, M. Fatih Cırıt - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shared_queues_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#1084 `__) -* Contributors: Cristóbal Arroyo, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`spdlog_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to spdlog 1.9.2 (`#33 `__) -* [rolling] Update maintainers - 2022-11-07 (`#31 `__) -* Update to spdlog 1.9.1 (`#27 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#30 `__) -* build shared lib only if BUILD_SHARED_LIBS is set (`#29 `__) -* Mirror rolling to master -* xml tag order -* updating maintainer -* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Dharini Dutia, Scott K Logan, hannes09 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sqlite3_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to sqlite3 3.37.2 (`#1274 `__) This matches version distributed in Ubuntu Jammy. -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#1084 `__) -* Contributors: Cristóbal Arroyo, Michael Orlov, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sros2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix SSH commands in SROS2_Linux.md (`#286 `__) -* Make type of get_package_share_directory apparent for sphinx (`#284 `__) -* Contributors: Boris Boutillier, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`statistics_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_srvs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`stereo_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tango_icons_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#10 `__) -* Mirror rolling to master -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the system tests to C++17. (`#510 `__) -* [rolling] Update maintainers - 2022-11-07 (`#509 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli_remapping `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the system tests to C++17. (`#510 `__) -* [rolling] Update maintainers - 2022-11-07 (`#509 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_communication `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the system tests to C++17. (`#510 `__) -* [rolling] Update maintainers - 2022-11-07 (`#509 `__) -* Revert "Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__)" (`#504 `__) -* Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__) -* Contributors: Audrow Nash, Chris Lalancette, Hubert Liberacki, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_interface_files `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#21 `__) -* Mirror rolling to master -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 (`#359 `__) -* Fix normalize_parameters_dict for multiple nodes in the same namespace (`#347 `__) -* Implement None check for ComposableNodeContainer (`#341 `__) -* Add LifecyleTransition action (`#317 `__) -* Ensure load_composable_nodes respects condition (`#339 `__) -* [rolling] Update maintainers - 2022-11-07 (`#331 `__) -* RosTimer -> ROSTimer and PushRosNamespace -> PushROSNamespace, to follow PEP8 (`#326 `__) -* add SetROSLogDir action (`#325 `__) -* Support default values in parameter substitution (`#313 `__) -* Run condition for composable nodes (`#311 `__) -* Load composable nodes in sequence (`#315 `__) -* Contributors: Aditya Pande, Alexey Merzlyakov, Audrow Nash, Christoph Hellmann Santos, Kenji Miyake, Shane Loretz, William Woodall, Yadu, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#671 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) -* [rolling] Update maintainers - 2022-11-07 (`#150 `__) -* Depend on rosidl_core_generators for packages required by actions (`#144 `__) -* Make the functions in the header static inline (`#140 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_osrf_testing_tools_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Changing C++ Compile Version (`#76 `__) -* Update maintainers (`#74 `__) -* Contributors: Audrow Nash, Lucas Wendland - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_quality_of_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix ODR errors with gtest (`#514 `__) -* Avoid flaky test (`#513 `__) -* Update the system tests to C++17. (`#510 `__) -* [rolling] Update maintainers - 2022-11-07 (`#509 `__) -* Pass rclcpp::QoS to create_service (`#507 `__) -* Pass rclcpp::QoS to create_client (`#506 `__) -* Remove Werror from test_quality_of_service. (`#503 `__) -* Revert "Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__)" (`#504 `__) -* Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__) -* Add tests for 'best available' QoS policies (`#501 `__) -* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Hubert Liberacki, Jacob Perron, Shane Loretz, William Woodall, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the system tests to C++17. (`#510 `__) -* [rolling] Update maintainers - 2022-11-07 (`#509 `__) -* Pass rclcpp::QoS to create_service (`#507 `__) -* Pass rclcpp::QoS to create_client (`#506 `__) -* Revert "Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__)" (`#504 `__) -* Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__) -* Contributors: Audrow Nash, Chris Lalancette, Hubert Liberacki, Shane Loretz, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add tests for rmw matched event (`#216 `__) -* Update rmw_implementation to C++17. (`#214 `__) -* [rolling] Update maintainers - 2022-11-07 (`#212 `__) -* Add rmw_get_gid_for_client & tests (`#206 `__) -* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Move ros2trace tests to new test_ros2trace package (`#63 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_security `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#509 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#578 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable tracing on Android (`#72 `__) -* Add intra-process tracepoints (`#30 `__) -* Allow requiring minimum lttng package version for is_lttng_installed (`#59 `__) -* Disable tracing on macOS (`#53 `__) -* Include tracepoints by default on Linux (`#31 `__) -* Fix memory leak in tracetools::get_symbol() (`#43 `__) -* Update tracing to C++17. (`#33 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Przemysław Dąbrowski, ymski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Error out if trace already exists unless 'append' option is used (`#58 `__) -* Make subbuffer size configurable with Trace action (`#51 `__) -* Allow requiring minimum lttng package version for is_lttng_installed (`#59 `__) -* Enable document generation using rosdoc2 for ament_python pkgs (`#50 `__) -* Contributors: Christophe Bedard, Christopher Wecht, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix error code returned in BufferCore::walkToTopParent (`#602 `__) -* Depend on ament_cmake_ros to default SHARED to ON (`#591 `__) -* Fix a potential crash in TimeCache::findClosest (`#592 `__) -* Extend TimeCache API to provide rich ExtrapolationException infos (`#586 `__) -* Update geometry2 to C++17 (`#584 `__) -* Include required header Scalar.h (`#559 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Chris Lalancette, Patrick Roncagliolo, Shane Loretz, Tyler Weaver - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_bullet `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#578 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#578 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update geometry2 to C++17 (`#584 `__) -* Update maintainers (`#560 `__) -* Use orocos_kdl_vendor and orocos-kdl target (`#534 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add do_transform_polygon_stamped (`#582 `__) -* Update the demos to C++17. (`#578 `__) -* Update maintainers (`#560 `__) -* Add torque due to force offset (`#538 `__) -* Use orocos_kdl_vendor and orocos-kdl target (`#534 `__) -* Contributors: Audrow Nash, Chris Lalancette, Paul Gesel, Scott K Logan, Tony Najjar - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#578 `__) -* Update maintainers (`#560 `__) -* Use orocos_kdl_vendor and orocos-kdl target (`#534 `__) -* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update geometry2 to C++17 (`#584 `__) -* Update maintainers (`#560 `__) -* Remove action_msgs dependency (`#547 `__) -* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update geometry2 to C++17 (`#584 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Destroy callback group before node (`#595 `__) -* Enable TransformListener node-based constructor in Intra-process enabled components (`#572 `__) -* Fix use-after-free bug in BufferServer::cancelCB (`#579 `__) -* Update the demos to C++17. (`#578 `__) -* add constructor to static tf broadcaster accepting node interfaces (`#576 `__) -* Update maintainers (`#560 `__) -* Switching from sstream to c string formatting to fix ros arg issue (`#557 `__) -* allow construction of tf broadcaster from node object (not a pointer) (`#555 `__) -* Allow to construct ``TransformBroadcaster`` and ``TransformListener`` from node interfaces (`#552 `__) -* Suppress spam from calling canTransform (`#529 `__) -* Contributors: Alberto Soragna, Alexander Hans, Audrow Nash, Chris Lalancette, Gonzo, Michael Carroll, Patrick Roncagliolo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update sys.path with wokring directory (`#594 `__) -* Enable document generation using rosdoc2 for ament_python pkgs (`#587 `__) -* Update maintainers (`#560 `__) -* Use pytest rather than unittest to enable repeat (`#558 `__) -* Contributors: Audrow Nash, Michael Carroll, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#578 `__) -* Update maintainers (`#560 `__) -* feat: export tf2 sensor msgs target (`#536 `__) -* tf2_sensor_msgs find the right Python executable. (`#525 `__) -* Add missing ament_cmake_pytest package needed because of newly-enabled test (`#520 `__) -* Port point cloud transformation to numpy (`#507 `__) -* Contributors: Audrow Nash, Chris Lalancette, Daisuke Nishimatsu, Florian Vahl, Jorge Perez, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable document generation using rosdoc2 for ament_python pkgs (`#587 `__) -* Update maintainers (`#560 `__) -* Contributors: Audrow Nash, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#13 `__) -* Update maintainers (`#12 `__) -* Contributors: Audrow Nash, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update realtime support to C++17. (`#122 `__) -* [rolling] Update maintainers - 2022-11-07 (`#121 `__) -* Addressing issues found in Humble testing (`#116 `__) -* Contributors: Audrow Nash, Chris Lalancette, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_monitor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update launch file name format to match documentation (`#588 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Patrick Wspanialy - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_statistics_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the demos to C++17. (`#594 `__) -* [rolling] Update maintainers - 2022-11-07 (`#589 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Disable tracing on Android (`#72 `__) -* Add intra-process tracepoints (`#30 `__) -* Improve tracetools rosdoc2/doxygen output (`#57 `__) -* Update README and other documentation (`#55 `__) -* Disable tracing on macOS (`#53 `__) -* Include tracepoints by default on Linux (`#31 `__) -* Explicitly link against dl for dladdr() (`#48 `__) -* Fix memory leak in tracetools::get_symbol() (`#43 `__) -* Add TRACEPOINT_ENABLED() and DO_TRACEPOINT() macros (`#46 `__) -* Update tracing to C++17. (`#33 `__) -* Add new rclcpp_subscription_init tracepoint to support new intra-process comms -* Contributors: Chris Lalancette, Christophe Bedard, Przemysław Dąbrowski, ymski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Error out if trace already exists unless 'append' option is used (`#58 `__) -* Improve 'ros2 trace' command error handling & add end-to-end tests (`#54 `__) -* Make subbuffer size configurable with Trace action (`#51 `__) -* Enable document generation using rosdoc2 for ament_python pkgs (`#50 `__) -* Remove deprecated context_names parameter (`#38 `__) -* Contributors: Christophe Bedard, Christopher Wecht, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Error out if trace already exists unless 'append' option is used (`#58 `__) -* Improve 'ros2 trace' command error handling & add end-to-end tests (`#54 `__) -* Make subbuffer size configurable with Trace action (`#51 `__) -* Add intra-process tracepoints (`#30 `__) -* Allow requiring minimum lttng package version for is_lttng_installed (`#59 `__) -* Include tracepoints by default on Linux (`#31 `__) -* Enable document generation using rosdoc2 for ament_python pkgs (`#50 `__) -* Replace distutils.version.StrictVersion with packaging.version.Version (`#42 `__) -* Remove deprecated context_names parameter (`#38 `__) -* Contributors: Christophe Bedard, Christopher Wecht, Yadu, ymski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`trajectory_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`turtlesim `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove the range constraints from the holonomic parameter. (`#150 `__) (`#151 `__) -* Add icon (`#148 `__) (`#149 `__) -* Update turtlesim to C++17. (`#146 `__) -* [rolling] Update maintainers - 2022-11-07 (`#145 `__) -* Add parameter to enable holonomic motion (`#131 `__) -* Add humble turtle (`#140 `__) -* Contributors: Audrow Nash, Chris Lalancette, Daisuke Sato, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`type_description_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add GetTypeDescription.srv (rep2011) (`#153 `__) -* new package and interfaces for describing other types (`#146 `__) -* Contributors: Emerson Knapp, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`unique_identifier_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#26 `__) -* Depend on rosidl_core instead of rosidl_defaults (`#24 `__) -* Mirror rolling to master -* Update maintainers (`#22 `__) -* Contributors: Audrow Nash, Jacob Perron, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#35 `__) -* [urdf] package.xml: add missing exec_depend to urdf_parser_plugin (`#34 `__) -* Provide copy and move constructors for ``model`` (`#33 `__) -* Add linter tests and fix errors (`#30 `__) -* fix `#30 `__ -* Contributors: Audrow Nash, Daniel Reuter, Tobias Neumann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf_parser_plugin `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#35 `__) -* Contributors: Audrow Nash - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`visualization_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update common_interfaces to C++17. (`#215 `__) -* [rolling] Update maintainers - 2022-11-07 (`#210 `__) -* Contributors: Audrow Nash, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`yaml_cpp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [rolling] Update maintainers - 2022-11-07 (`#40 `__) -* Export YAML_CPP_DLL define on Windows (`#30 `__) (`#38 `__) -* Sets CMP0135 policy behavior to NEW (`#36 `__) -* Fixes policy CMP0135 warning for CMake >= 3.24 (`#35 `__) -* build shared lib only if BUILD_SHARED_LIBS is set (`#34 `__) -* Mirror rolling to master -* Contributors: Audrow Nash, Cristóbal Arroyo, Jacob Perron, hannes09 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`zstd_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) -* Bump zstd to 1.4.8 in zstd_vendor package (`#1132 `__) -* Fix/zstd vendor does not find system zstd (`#1111 `__) -* Contributors: DasRoteSkelett, Michael Orlov +.. redirect-from:: + + Releases/Iron-Irwini-Complete-Changelog + +Iron Irwini Changelog +===================== + +This page is a list of the complete changes in all ROS 2 core packages since the previous release. + +.. contents:: Table of Contents + :local: + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* Add service_msgs package (`#143 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Depend on rosidl_core_generators for packages required by actions (`#144 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* Update the demos to C++17. (`#594 `__) +* Add README's for action_tutorials. (`#576 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Fix two small bugs in the fibonacci C++ tutorial. (`#564 `__) +* Contributors: Audrow Nash, Chris Lalancette, kagibson + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* A couple more upgrades to C++17. (`#609 `__) +* Add README's for action_tutorials. (`#576 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Remove action_msgs dependency (`#580 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, kagibson + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add README's for action_tutorials. (`#576 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, kagibson + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`actionlib_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ament_clang_format: use open braces for enum definitions (`#426 `__) +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, james-rms, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* recommend use of --mixin compile-commands (`#371 `__) +* Improve message and avoid missing new lines between reports from files (`#373 `__) +* Contributors: Audrow Nash, William Woodall, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support INTERFACE on ament_auto_add_library (`#420 `__) +* Fix ament_auto_add_gtest's parameter passing (`#421 `__) +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) +* Rolling: ament_cmake_auto should include dependencies as SYSTEM (`#385 `__) +* Contributors: Audrow Nash, Christopher Wecht, Joshua Whitley, Rin Iwai + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) +* Update maintainers (`#379 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ament_cmake_uninstall_target: Correct location of install_manifest.txt (`#432 `__) +* Use file(GENERATE OUTPUT) to create dsv files (`#416 `__) Using file(WRITE) and file(APPEND) causes the modification stamp of the file to be changed each time CMake configures, resluting in an 'Installing' message rather than an 'Up-to-date' message even though the file content is identical. Using file(GENERATE OUTPUT) updates the timestamp of the file only if the content changes. +* Warn when trying to symlink install an INTERFACE_LIBRARY (`#417 `__) +* Workaround to exclude Clion's cmake folders from colcon test (`#410 `__) - Add AMENT_IGNORE to CMAKE_BINARY_DIR to avoid picking up cmake specific folders created by CLion in ``colcon build`` and ``colcon test`` commands +* if (NOT ${UNDEFINED_VAR}) gets evaluated to false, so change to if (NOT UNDEFINED_VAR) so it evaluates to true. (`#407 `__) +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Implement ament_add_default_options (`#390 `__) +* Contributors: Audrow Nash, Kenji Brameld, Michael Orlov, Scott K Logan, Shane Loretz, Silvio Traversaro, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) +* Update maintainers (`#379 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) +* Update maintainers (`#379 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_definitions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_link_flags `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_targets `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Support new target export template introduced with CMake 3.24 (`#395 `__) +* Fix the order in which Export.cmake files are included (`#256 `__) +* Contributors: Audrow Nash, Timo Röhling + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add flake8 linter ignore support (`#424 `__) +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, RFRIEDM-Trimble, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gen_version_h `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changed version gte macro to make it MSVC compatible. Fix `#433 `__ (`#434 `__) +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash, iquarobotics + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gmock `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix compiler warnings related to gtest/gmock (`#408 `__) * Suppress compiler warnings when building gmock definition of implicit copy constructor ... is deprecated because it has a user-declared copy assignment operator [-Wdeprecated-copy] * Declare gtest/gmock include dirs as SYSTEM PRIVATE for test targets +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash, Robert Haschke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_google_benchmark `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gtest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix compiler warnings related to gtest/gmock (`#408 `__) * Suppress compiler warnings when building gmock definition of implicit copy constructor ... is deprecated because it has a user-declared copy assignment operator [-Wdeprecated-copy] * Declare gtest/gmock include dirs as SYSTEM PRIVATE for test targets +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash, Robert Haschke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix test skipping logic for missing pytest module (`#441 `__) +* Add missing buildtool_depend on python3-pytest (`#440 `__) +* ament_cmake_pytest needs a buildtool_depend on ament_cmake_test. (`#439 `__) +* Fix pytest-cov version detection with pytest >=7.0.0 (`#436 `__) +* use the error handler replace to allow non-utf8 to be decoded (`#381 `__) +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Add NOCAPTURE option to ament_add_pytest_test (`#393 `__) +* Contributors: Audrow Nash, Chris Lalancette, Christophe Bedard, El Jawad Alaa, Jacob Perron, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support Debian-specific install dir for ament_cmake_python (`#431 `__) +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Document ament_cmake_python (`#387 `__) +* Contributors: Audrow Nash, Shane Loretz, Timo Röhling + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#16 `__) +* Update maintainers (`#15 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_target_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* use the error handler replace to allow non-utf8 to be decoded (`#381 `__) +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash, El Jawad Alaa + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) +* Update maintainers (`#379 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_vendor_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix the version number of ament_cmake_vendor_package. +* Add ament_cmake_vendor_package package (`#429 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_version `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#411 `__) * Update maintainers to Michael Jeronimo +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Support for matching license header within multiline comment block (`#361 `__) +* Improved licencse matching (`#358 `__) +* Updated regex and adding test cases for copyright search (`#363 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, Will, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_cpplint] Process errors without linenums (`#385 `__) +* Update maintainers (`#379 `__) +* Consider files with '.hh' extension as C++ headers (`#374 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, Jacob Perron, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Fix exclude regression (`#387 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#89 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#89 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add flake8 linter ignore support (`#424 `__) +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_lint_auto] General file exclusion with AMENT_LINT_AUTO_FILE_EXCLUDE (`#386 `__) +* Update maintainers (`#379 `__) +* Contributors: Abrar Rahman Protyasha, Audrow Nash, RFRIEDM-Trimble, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for comment lines in dsv files (`#139 `__) +* [rolling] Update maintainers - 2022-11-07 (`#138 `__) +* Mirror rolling to master +* Remove unused isolated prefix level templates (`#133 `__) +* Contributors: Audrow Nash, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* updating ref to pep257 docs (`#433 `__) +* Added underscore to ignore new pydocstyle item (`#428 `__) +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* [ament_pep257][master] redirecting error prints to stderr (`#390 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, Christian Henkel, Cristóbal Arroyo, Mirco Colosi (CR/AAS3), methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ament_pycodestyle - fix crash caused by reporting on ignored errors (`#435 `__) +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, Shane Loretz, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#421 `__) +* Update maintainers (`#379 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`builtin_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Depend on rosidl_core_generators for packages required by actions (`#144 `__) +* Fix documented range (`#139 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_calibration_parsers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update image_common to C++17. (`#267 `__) +* Add alias library targets for all libraries (`#259 `__) +* Add support for missing ROI and binning fields (`#254 `__) +* Contributors: AndreasR30, Chris Lalancette, RFRIEDM-Trimble + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_info_manager `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update image_common to C++17. (`#267 `__) +* Add alias library targets for all libraries (`#259 `__) +* Add lifecycle node compatibility to camera_info_manager (`#190 `__) +* Contributors: Chris Lalancette, RFRIEDM-Trimble, Ramon Wijnands + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`class_loader `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* make sanitizer happy (`#205 `__) +* [rolling] Update maintainers - 2022-11-07 (`#206 `__) +* Remove appveyor configuration. (`#204 `__) +* Just fix a typo in a comment. (`#203 `__) +* make the meta-object alive in the lifecycle of the registered plugin (`#201 `__) +* Mirror rolling to ros2 +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`common_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* update launch file name format to match documentation (`#588 `__) +* Added README.md for composition (`#598 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* fix memory leak (`#585 `__) +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Gary Bey, Patrick Wspanialy + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* Add matched event demo for rclcpp and rclpy (`#607 `__) +* Fix the set_parameters_callback example program. (`#608 `__) +* [demo_nodes_cpp] Add YAML launch demos for topics (`#605 `__) +* update launch file name format to match documentation (`#588 `__) +* Service introspection (`#602 `__) * Add in a rclcpp and rclpy demo of introspection. +* Added README.md for demo_cpp_nodes (`#599 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Demo for pre and post set parameter callback support (`#565 `__) * local parameter callback support +* counter starts from 1, not 2. (`#562 `__) +* add a demo of content filter listener (`#557 `__) +* Contributors: Audrow Nash, Barry Xu, Chen Lihui, Chris Lalancette, Damien LaRocque, Deepanshu Bansal, Gary Bey, Patrick Wspanialy, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp_native `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* Added README.md for demo_cpp_nodes_native (`#597 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Make demo_nodes_cpp_native install stuff only when it builds (`#590 `__) +* Contributors: Audrow Nash, Chris Lalancette, Gary Bey, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* Add matched event demo for rclcpp and rclpy (`#607 `__) +* Enable document generation using rosdoc2 (`#606 `__) +* Service introspection (`#602 `__) +* Added README.md for demo_nodes_py (`#600 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Demo for pre and post set parameter callback support (`#565 `__) +* Add demo for rclpy parameter client (`#566 `__) +* Exit with code 0 if ExternalShutdownException is raised (`#581 `__) +* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Deepanshu Bansal, Gary Bey, Jacob Perron, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`diagnostic_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`domain_coordinator `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#16 `__) +* Update maintainers (`#15 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_map_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Added README.md for dummy_map_server (`#572 `__) +* Contributors: Audrow Nash, Chris Lalancette, Gary Bey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_robot_bringup `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update launch file name format to match documentation (`#588 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Patrick Wspanialy + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_sensors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix unstable LaserScan status for rviz2 (`#616 `__) +* Added README.md for dummy_sensors (`#573 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Gary Bey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`eigen3_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#6 `__) +* Mirror rolling to master +* Update maintainers (`#4 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`example_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#17 `__) +* Remove action_msgs dependency (`#16 `__) +* Mirror rolling to master +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_async_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_cbg_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* add ContentFilteredTopic example. (`#341 `__) +* Contributors: Audrow Nash, Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_timer `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_multithreaded_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_wait_set `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the examples to C++17. (`#353 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Add test linting to wait_set and fix issues. (`#346 `__) (`#347 `__) +* Contributors: Audrow Nash, Chris Lalancette, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_executors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_guard_conditions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 for ament_python pkgs (`#357 `__) * Add missing action_msgs dep * Add exec_deps for launch_testing_examples +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_pointcloud_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 for ament_python pkgs (`#587 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`fastrtps_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#93 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`foonathan_memory_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added support for QNX 7.1 build (#65) +* Update upstream to release 0.7-3 (#62)(#63) +* Fix CMake minimum required version (#60) + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`google_benchmark_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Actually update to 1.6.1. (`#25 `__) We claimed we were, but in fact we were pinned to the 1.5.3 git hash. +* Remove set but unused variable (`#24 `__) Clang checks -Wunused-but-set-variable. This fails the build with -Werror also enabled. +* [rolling] Update maintainers - 2022-11-07 (`#22 `__) +* Mirror rolling to main +* Contributors: Audrow Nash, Chris Lalancette, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ignition_cmake2_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set target version to 2.14.0 (`#5 `__) +* Mirror rolling to main +* Contributors: Audrow Nash, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ignition_math6_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Forward CMAKE_PREFIX_PATH when building vendor package (`#8 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added README.md for image_tools - [Clean] (`#596 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette, Gary Bey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update image_common to C++17. (`#267 `__) +* Add alias library targets for all libraries (`#259 `__) +* Remove subscriber and publisher impl methods without options (`#252 `__) +* Deprecate impl without options (`#249 `__) +* opt-in to qos overriding for publisher (`#246 `__) +* Add qos option to override qos (`#208 `__) +* Contributors: Brian, Chris Lalancette, Daisuke Nishimatsu, Kenji Brameld, RFRIEDM-Trimble + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`interactive_markers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update interactive_markers to C++17. (`#99 `__) +* Update maintainers (`#98 `__) +* Mirror rolling to ros2 +* update maintainer (`#92 `__) +* Contributors: Audrow Nash, Chris Lalancette, Dharini Dutia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`intra_process_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix executable name in README (`#619 `__) +* Change all ROS2 -> ROS 2. (`#610 `__) +* Added README.md for intra_process_demo (`#595 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette, Gary Bey, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`kdl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch some tests to use unique pointers instead of raw pointers. (`#74 `__) +* log link children as DEBUG instead of INFO (`#71 `__) +* Enable the kdl_parser tests in ROS 2 (`#68 `__) +* Add in a LICENSE file and fix up copyright headers (`#66 `__) +* Use orocos_kdl_vendor and orocos-kdl target (`#64 `__) +* Use the rcutils logger instead of printf (`#65 `__) +* Contributors: Chris Lalancette, Joseph Schornak, Scott K Logan, yuraSomatic + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`keyboard_handler `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Force exit from main thread on signal handling in ``keyboard_handler`` (`#23 `__) +* Contributors: Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`laser_geometry `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update laser_geometry to C++17. (`#90 `__) +* Update Maintainers (`#88 `__) +* Mirror rolling to ros2 +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Document LaunchService.{run,run_async}() return value (`#702 `__) +* [rosdoc2] Fix document generation on buildfarm (`#701 `__) +* Enable document generation using rosdoc2 for ament_python pkgs (`#697 `__) +* Remove the import of Literal from entity.py. (`#694 `__) +* Fix flake8 errors. (`#695 `__) +* add symlink to latest log directory (`#686 `__) +* Improve type checking (`#679 `__) +* Fixed typos (`#692 `__) +* Pass modules to PythonExpression (`#655 `__) +* Allow ReadyToTest() usage in event handler (`#665 `__) +* Expose emulate_tty to xml and yaml launch (`#669 `__) +* Expose sigterm_timeout and sigkill_timeout to xml frontend (`#667 `__) +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Expect deprecation warnings in tests (`#657 `__) +* Fix the restoring of os.environ to maintain type. (`#656 `__) +* Implement Any, All, Equals, and NotEquals substitutions (`#649 `__) +* add LaunchLogDir substitution, replacing log_dir frontend only substitution (`#652 `__) +* Add special cases to coerce "1" and "0" to bool when using bool coercion only (`#651 `__) +* Update launch/test/launch/test_execute_local.py +* Added unit test ensuring that output dictionary works with ExecuteLocal +* Addresses issue `#588 `__, allowing dict for 'output' +* Remove unused variables. (`#612 `__) +* Expose shutdown action to xml frontend (`#611 `__) +* Contributors: Aditya Pande, Alejandro Hernández Cordero, Audrow Nash, Blake Anderson, Chris Lalancette, Christophe Bedard, Hervé Audren, Jacob Perron, Matthew Elwin, Michael Jeronimo, Nikolai Morin, Welte, William Woodall, Yadu, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed typos (`#692 `__) +* Drop unused data_files entry for example_processes (`#680 `__) +* Spelling correction +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Geoffrey Biggs, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use SomeEntitiesType for type checking. (`#358 `__) +* Fix normalize_parameters_dict for multiple nodes in the same namespace (`#347 `__) +* Implement None check for ComposableNodeContainer (`#341 `__) +* Add LifecyleTransition action (`#317 `__) +* Improve evaluate_paramenter_dict exceptions error message (`#320 `__) +* Ensure load_composable_nodes respects condition (`#339 `__) +* fix: return text value to avoid exception (`#338 `__) +* [rolling] Update maintainers - 2022-11-07 (`#331 `__) +* RosTimer -> ROSTimer and PushRosNamespace -> PushROSNamespace, to follow PEP8 (`#326 `__) +* add SetROSLogDir action (`#325 `__) +* Support default values in parameter substitution (`#313 `__) +* Run condition for composable nodes (`#311 `__) +* Contributors: Aditya Pande, Alexey Merzlyakov, Audrow Nash, Chris Lalancette, Christoph Hellmann Santos, Daisuke Nishimatsu, Felipe Gomes de Melo, Kenji Miyake, William Woodall, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve type checking (`#679 `__) +* Fixed typos (`#692 `__) +* Allow ReadyToTest() usage in event handler (`#665 `__) +* Inherit markers from generate_test_description (`#670 `__) +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Fix Typo (`#641 `__) +* ReadyToTest action timeout using decorator (`#625 `__) +* Switch to using a comprehension for process_names. (`#614 `__) +* Contributors: Alejandro Hernández Cordero, Audrow Nash, Chris Lalancette, Deepanshu Bansal, Hervé Audren, Kenji Brameld, Nikolai Morin, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_examples `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 for ament_python pkgs (`#357 `__) +* increase the timeout for window platform to avoid flaky test (`#355 `__) +* [rolling] Update maintainers - 2022-11-07 (`#352 `__) +* Increase the WaitForNode timeout. (`#350 `__) +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Increase the timeouts in wait_for_topic_launch_test. (`#360 `__) +* Enable document generation using rosdoc2 (`#359 `__) +* exit() methods should not reraise the passed-in exception (`#357 `__) +* Inherit markers from generate_test_description (`#330 `__) +* [rolling] Update maintainers - 2022-11-07 (`#331 `__) +* Fix long wait during shutdown in WaitForTopics (`#314 `__) +* Contributors: Audrow Nash, Chris Lalancette, Giorgio Pintaudi, Keng12, Scott K Logan, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_xml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed typos (`#692 `__) +* Expose emulate_tty to xml and yaml launch (`#669 `__) +* Expose sigterm_timeout and sigkill_timeout to xml frontend (`#667 `__) +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Contributors: Aditya Pande, Alejandro Hernández Cordero, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_yaml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose emulate_tty to xml and yaml launch (`#669 `__) +* Expose sigterm_timeout and sigkill_timeout to xml frontend (`#667 `__) +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Contributors: Aditya Pande, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libcurl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* merge libcurl_vendor build instructions (`#81 `__) +* Sets CMP0135 policy behavior to NEW (`#79 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 +* Contributors: Cristóbal Arroyo, Crola1702, schrodinbug + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libstatistics_collector `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump hmarr/auto-approve-action from 3.2.0 to 3.2.1 +* Mark benchmark _ as unused. (`#158 `__) +* Bump hmarr/auto-approve-action from 3.1.0 to 3.2.0 +* Bump ros-tooling/action-ros-ci from 0.2 to 0.3 +* Bump pascalgn/automerge-action from 0.15.5 to 0.15.6 +* Update libstatistics_collector to C++17. (`#154 `__) +* Remove unnecessary build dependency on std_msgs. (`#145 `__) +* Bump pascalgn/automerge-action from 0.15.2 to 0.15.3 +* Cleanup the CI jobs on this repository. (`#146 `__) +* Check if message has a "header" field with a stamp subfield of type builtin_interfaces::msg::Time (`#54 `__) +* Mirror rolling to master +* Contributors: Audrow Nash, Chris Lalancette, Scott Mende, dependabot[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libyaml_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix system package dependency (`#54 `__) +* Update libyaml_vendor to C++17. (`#55 `__) +* [rolling] Update maintainers - 2022-11-07 (`#53 `__) +* Remove a warning message. (`#51 `__) +* check if libyaml is already present before building it (take 2) (`#45 `__) +* Mirror rolling to master +* Support WindowsStore builds for ROS2 (`#50 `__) * libyaml for uwp +* Contributors: Audrow Nash, Chris Lalancette, Lou Amadio, Scott K Logan, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update launch file name format to match documentation (`#588 `__) +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette, Patrick Wspanialy + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* lifecycle_msgs: remove non-ASCII chars from field comments (`#147 `__) +* Contributors: Audrow Nash, Chris Lalancette, G.A. vd. Hoorn + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 (`#606 `__) +* update launch file name format to match documentation (`#588 `__) +* Cleanup lifecycle_py to conform to ROS 2 standards. (`#604 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Install the launch file for lifecycle_py. (`#586 `__) +* Contributors: Audrow Nash, Chris Lalancette, Patrick Wspanialy, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`logging_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Change dependency from 'rosidl_cmake' to 'rosidl_default_generators' (`#578 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`map_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers +* Contributors: Audrow Nash, Steve Macenski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mcap_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* mcap_vendor: add readme with versioning procedure (`#1230 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* mcap_vendor: only install public headers (`#1207 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 for mcap_vendor (`#1208 `__) +* mcap_vendor: download MCAP source via tarball (`#1204 `__) +* rosbag2_cpp: test more than one storage plugin (`#1196 `__) +* rosbag2_storage_mcap: merge into rosbag2 repo (`#1163 `__) +* Fix Windows build (`#73 `__) Update mcap version to newest windows-compatible release. Add visibility macros for tests. Add clang-format preprocessor indentation for visibility_control to be readable. +* mcap_vendor: update to v0.6.0 (`#69 `__) +* Cleanup in ``mcap_vendor`` package (`#62 `__) +* Switch to using the vendored zstd library. (`#59 `__) +* Support timestamp-ordered playback (`#50 `__) +* Support regex topic filtering +* Add all lz4 sources to fix undefined symbols at runtime (`#46 `__) +* Upgrade mcap to fix LZ4 error and segfault (`#42 `__) Incorporates fixes from https://github.com/foxglove/mcap/pull/478 and https://github.com/foxglove/mcap/pull/482 +* Add missing buildtool_depend on git (`#37 `__) This vendor package uses git to fetch sources for other packages. It should declare a dependency on that build tool. This should address the current cause of RPM build failures for RHEL: https://build.ros2.org/view/Rbin_rhel_el864/job/Rbin_rhel_el864__mcap_vendor__rhel_8_x86_64__binary/ +* Test Foxy & Galactic in CI, fix missing test_depends in mcap_vendor/package.xml (`#33 `__) +* fix: minor issues (`#31 `__) * remove unnecessary block * use target_link_libraries instead of ament_target_dependencies * remove ros environment * add prefix to compile definition +* Update email address for Foxglove maintainers (`#32 `__) +* Added mcap_vendor package. Updated CMakeLists.txt to fetch dependencies with FetchContent rather than Conan. +* Contributors: Chris Lalancette, Cristóbal Arroyo, Daisuke Nishimatsu, Emerson Knapp, Jacob Bandes-Storch, James Smith, Michael Orlov, Scott K Logan, james-rms + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`message_filters `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update message_filters to C++17. (`#88 `__) +* Fix cache.h std::placeholder namespace (`#87 `__) +* [rolling] Update maintainers - 2022-11-07 (`#85 `__) +* Add a simpler aproximate time sync policy: ApproximateEpsilonTime (`#84 `__) +* Add latest time zero-order-hold sync policy (`#73 `__) +* Fix python examples and add a new example in documentation (`#79 `__) +* Mirror rolling to master +* Adding fix to subscribe() call with raw node pointer and subscriber options (`#76 `__) +* Corrected function arguments in example description (`#35 `__) +* Changed invocation to ``add`` to conform template syntax (`#1388 `__) +* fix sphinx warning (`#1371 `__) +* change invocation to ``add`` to conform template syntax (`#1388 `__) +* fix sphinx warning (`#1371 `__) +* Contributors: Audrow Nash, Carlos Andrés Álvarez Restrepo, Chris Lalancette, Haoru Xue, Ivan Santiago Paunovic, Martin Ganeff, Steve Macenski, andermi + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mimick_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#29 `__) +* Mirror rolling to master +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`nav_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`orocos_kdl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to quote orocos variables when setting targets. (`#12 `__) +* Ensure orocos-kdl is available as a target (`#10 `__) +* Ensure orocos-kdl target references Eigen (`#6 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [master] Update maintainers - 2022-11-07 (`#89 `__) +* Declare test dependencies in [test] extra (`#86 `__) +* Contributors: Audrow Nash, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_testing_tools_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix mpark/variant conditional for MSVC (`#77 `__) +* Changing C++ Compile Version (`#76 `__) +* Update maintainers (`#74 `__) +* Sets CMP0135 policy behavior to NEW (`#73 `__) +* Fixes policy CMP0135 warning in CMake 3.24 (`#71 `__) +* Add cstring include. (`#70 `__) +* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Lucas Wendland, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_control `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change all ROS2 -> ROS 2. (`#610 `__) +* A couple more upgrades to C++17. (`#609 `__) +* Added README.md for pendulum_msgs. (`#577 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette, Gary Bey + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`performance_test_fixture `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Resolve use-after-free compiler warnings (`#24 `__) +* Update performance_test_fixture to C++17. (`#21 `__) +* [rolling] Update maintainers - 2022-11-07 (`#20 `__) +* Mirror rolling to main +* Add "cstring" to the list of includes (`#19 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pluginlib `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainers +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pybind11_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add a modified patch from upstream to support Python 3.11 (`#22 `__) +* Add missing buildtool dependency on git (`#19 `__) +* Update maintainers (`#17 `__) +* Force pybind11 to find Python 3. (`#15 `__) +* Mirror rolling to master +* Update maintainers (`#14 `__) +* Update to pybind11 2.9.1. +* Rename patch file for history continuity. +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan, Steven! Ragnarök, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#13 `__) +* Mirror rolling to master +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_orocos_kdl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#16 `__) +* Workaround pybind11 CMake error (`#9 `__) +* Contributors: Cristóbal Arroyo, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_qt_binding `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix to allow ninja to use make for generators (`#123 `__) +* Fix flake8 linter regression (`#125 `__) +* Remove pyqt from default binding order for macOS (`#118 `__) +* Demote missing SIP message from WARNING to STATUS (`#122 `__) +* [rolling] Update maintainers - 2022-11-07 (`#120 `__) +* Contributors: Audrow Nash, Christoph Hellmann Santos, Cristóbal Arroyo, Michael Carroll, Rhys Mainwaring, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_dotgraph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in LICENSE file +* Cast drawLine input arguments to int (`#264 `__) (`#265 `__) +* Contributors: Chris Lalancette, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in LICENSE file +* Fix flake8 errors introduced by the previous commit. (`#262 `__) +* Enable basic help information if no plugins are running (`#261 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_app `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in LICENSE file +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in LICENSE file +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix ClassLoader warning by unloading plugin providers. (`#275 `__) +* Chen Lihui +* fix shiboken error (`#267 `__) +* Conditionally run import tests when generators are built (`#269 `__) +* Add in LICENSE file +* Contributors: Chris Lalancette, Christoph Hellmann Santos, Michael Carroll, Rhys Mainwaring, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_py_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in LICENSE file +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use non-deprecated rclpy import. (`#617 `__) +* Change all ROS2 -> ROS 2. (`#610 `__) +* Enable document generation using rosdoc2 (`#606 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Exit with code 0 if ExternalShutdownException is raised (`#581 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Honor ROS_LOCALHOST_ONLY if enabled. (`#1071 `__) +* fix flaky test (`#1063 `__) +* Add enable_type_description_service node option - API only (`#1060 `__) +* Dynamic Subscription (BONUS: Allocators): rcl (`#1057 `__) +* Runtime Interface Reflection: rcl (`#1025 `__) +* [rcl] Improve handling of dynamic discovery (`#1023 `__) +* Use get_type_hash_func for typesupports (`#1055 `__) +* publish for rosout topic multiple times to avoid flaky test (`#1054 `__) +* Switch to target_link_libraries in rcl. (`#1051 `__) +* Calculate type hash from TypeDescription (rep2011) (`#1027 `__) +* Implement matched event (`#1033 `__) +* use user-defined allocator to configure logging. (`#1047 `__) +* user defined allocator should be used for rosout publisher. (`#1044 `__) +* Add in inconsistent_topic implementation. (`#1024 `__) +* doc update, ROS message accessibility depends on RMW implementation. (`#1043 `__) +* Fix some warnings from clang. (`#1042 `__) +* avoid unnecessary copy for rcutils_char_array_vsprintf. (`#1035 `__) +* Service introspection (`#997 `__) +* Cache disable flag to avoid reading environmental variable. (`#1029 `__) +* use parent logger (`#921 `__) +* Add timer on reset callback (`#995 `__) +* Update rcl to C++17. (`#1031 `__) +* Make sure to check the return value of rcl_clock_init in tests. (`#1030 `__) +* Implement rcl_clock_time_started (`#1021 `__) +* Make sure to reset errors more places in the tests. (`#1020 `__) This makes it so we don't get as many warnings when the tests are running. +* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) +* Small cleanups to rcl (`#1013 `__) +* use int64_t for period. (`#1010 `__) +* fixed rcl_wait return error when timer cancelled (`#1003 `__) +* remove duplicate packages in find_package and reorder (`#994 `__) +* Fix buffer overflow in argument parsing caused by lexer returning length beyond length of string (`#979 `__) +* Fix leak in test_subscription_content_filter_options.cpp (`#978 `__) +* Contributors: Audrow Nash, Barry Xu, Brian, Chen Lihui, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Shane Loretz, Tomoya Fujita, mauropasse, methylDragon, 정찬희 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* doc update, ROS message accessibility depends on RMW implementation. (`#1043 `__) +* Update rcl to C++17. (`#1031 `__) +* Reduce result_timeout to 10 seconds. (`#1012 `__) +* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) +* Contributors: Audrow Nash, Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add interfaces for logging service. (`#154 `__) +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Contributors: Audrow Nash, Chris Lalancette, Lei Liu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rcl to C++17. (`#1031 `__) +* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rcl_logging to C++17. (`#98 `__) +* Updated maintainers - 2022-11-07 (`#96 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_noop `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rcl_logging to C++17. (`#98 `__) +* Updated maintainers - 2022-11-07 (`#96 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_spdlog `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Mark the benchmark _ as unused. (`#99 `__) +* Update rcl_logging to C++17. (`#98 `__) +* change flushing behavior for spdlog log files, and add env var to use old style (no explicit flushing) (`#95 `__) * now flushes every ERROR message and periodically every 5 seconds * can set ``RCL_LOGGING_SPDLOG_EXPERIMENTAL_OLD_FLUSHING_BEHAVIOR=1`` to get old behavior +* Updated maintainers - 2022-11-07 (`#96 `__) +* Disable cppcheck for rcl_logging_spdlog. (`#93 `__) +* ament_export_dependencies any package with targets we linked against (`#89 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_yaml_param_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix some warnings from clang. (`#1042 `__) +* Cleanup the dependencies in rcl_yaml_param_parser. (`#1014 `__) +* Update rcl to C++17. (`#1031 `__) +* Support yaml string tag '!!str' (`#999 `__) +* [rolling] Update maintainers - 2022-11-07 (`#1017 `__) +* Contributors: Audrow Nash, Barry Xu, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix delivered message kind (`#2175 `__) (`#2178 `__) +* Add support for logging service. (`#2122 `__) +* Picking ABI-incompatible executor changes (`#2170 `__) +* add events-executor and timers-manager in rclcpp (`#2155 `__) +* Create common structures for executors to use (`#2143 `__) +* Implement deliver message kind (`#2168 `__) +* applied tracepoints for ring_buffer (`#2091 `__) +* Dynamic Subscription (REP-2011 Subset): Stubs for rclcpp (`#2165 `__) +* Add type_hash to cpp TopicEndpointInfo (`#2137 `__) +* Trigger the intraprocess guard condition with data (`#2164 `__) +* Minor grammar fix (`#2149 `__) +* Fix unnecessary allocations in executor.cpp (`#2135 `__) +* add Logger::get_effective_level(). (`#2141 `__) +* Remove deprecated header (`#2139 `__) +* Implement matched event (`#2105 `__) +* use allocator via init_options argument. (`#2129 `__) +* Fixes to silence some clang warnings. (`#2127 `__) +* Documentation improvements on the executor (`#2125 `__) +* Avoid losing waitable handles while using MultiThreadedExecutor (`#2109 `__) +* Hook up the incompatible type event inside of rclcpp (`#2069 `__) +* Update all rclcpp packages to C++17. (`#2121 `__) +* Fix clang warning: bugprone-use-after-move (`#2116 `__) +* Fix memory leak in tracetools::get_symbol() (`#2104 `__) +* Service introspection (`#1985 `__) +* Allow publishing borrowed messages with intra-process enabled (`#2108 `__) +* to fix flaky test about TestTimeSource.callbacks (`#2111 `__) +* to create a sublogger while getting child of Logger (`#1717 `__) +* Fix documentation of Context class (`#2107 `__) +* fixes for rmw callbacks in qos_event class (`#2102 `__) +* Add support for timers on reset callback (`#1979 `__) +* Topic node guard condition in executor (`#2074 `__) +* Fix bug on the disorder of calling shutdown callback (`#2097 `__) +* Add default constructor to NodeInterfaces (`#2094 `__) +* Fix clock state cached time to be a copy, not a reference. (`#2092 `__) +* Fix -Wmaybe-uninitialized warning (`#2081 `__) +* Fix the keep_last warning when using system defaults. (`#2082 `__) +* Add in a fix for older compilers. (`#2075 `__) +* Implement Unified Node Interface (NodeInterfaces class) (`#2041 `__) +* Do not throw exception if trying to dequeue an empty intra-process buffer (`#2061 `__) +* Move event callback binding to PublisherBase and SubscriptionBase (`#2066 `__) +* Implement validity checks for rclcpp::Clock (`#2040 `__) +* Explicitly set callback type (`#2059 `__) +* Fix logging macros to build with msvc and cpp20 (`#2063 `__) +* Add clock type to node_options (`#1982 `__) +* Fix nullptr dereference in prune_requests_older_than (`#2008 `__) +* Remove templating on to_rcl_subscription_options (`#2056 `__) +* Fix SharedFuture from async_send_request never becoming valid (`#2044 `__) +* Add in a warning for a KeepLast depth of 0. (`#2048 `__) +* Mark rclcpp::Clock::now() as const (`#2050 `__) +* Fix a case that did not throw ParameterUninitializedException (`#2036 `__) +* Update maintainers (`#2043 `__) +* MultiThreadExecutor number of threads is at least 2+ in default. (`#2032 `__) +* Fix bug that a callback not reached (`#1640 `__) +* Set the minimum number of threads of the Multithreaded executor to 2 (`#2030 `__) +* check thread whether joinable before join (`#2019 `__) +* Set cpplint test timeout to 3 minutes (`#2022 `__) +* Make sure to include-what-you-use in the node_interfaces. (`#2018 `__) +* Do not clear entities callbacks on destruction (`#2002 `__) +* fix mismatched issue if using zero_allocate (`#1995 `__) +* Make ParameterService and Sync/AsyncParameterClient accept rclcpp::QoS (`#1978 `__) +* support regex match for parameter client (`#1992 `__) +* operator+= and operator-= for Duration (`#1988 `__) +* Revert "Revert "Add a create_timer method to Node and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) (`#2010 `__) +* force compiler warning if callback handles not captured (`#2000 `__) +* Revert "Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) +* Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__) +* [docs] add note about callback lifetime for {on, post}_set_parameter_callback (`#1981 `__) +* fix memory leak (`#1994 `__) +* Support pre-set and post-set parameter callbacks in addition to on-set-parameter-callback. (`#1947 `__) +* Make create_service accept rclcpp::QoS (`#1969 `__) +* Make create_client accept rclcpp::QoS (`#1964 `__) +* Fix the documentation for rclcpp::ok to be accurate. (`#1965 `__) +* use regex for wildcard matching (`#1839 `__) +* Revert "Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__)" (`#1956 `__) +* Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__) +* test adjustment for LoanedMessage. (`#1951 `__) +* fix virtual dispatch issues identified by clang-tidy (`#1816 `__) +* Remove unused on_parameters_set_callback\_ (`#1945 `__) +* Fix subscription.is_serialized() for callbacks with message info (`#1950 `__) +* wait for subscriptions on another thread. (`#1940 `__) +* Fix documentation of ``RCLCPP\_[INFO,WARN,...]`` (`#1943 `__) +* Always trigger guard condition waitset (`#1923 `__) +* Add statistics for handle_loaned_message (`#1927 `__) +* Drop wrong template specialization (`#1926 `__) +* Update get_parameter_from_event to follow the function description (`#1922 `__) +* Add 'best available' QoS enum values and methods (`#1920 `__) +* use reinterpret_cast for function pointer conversion. (`#1919 `__) +* Contributors: Alberto Soragna, Alexander Hans, Alexis Paques, Andrew Symington, Audrow Nash, Barry Xu, Brian, Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, Cristóbal Arroyo, Daniel Reuter, Deepanshu Bansal, Emerson Knapp, Hubert Liberacki, Ivan Santiago Paunovic, Jacob Perron, Jeffery Hsu, Jochen Sprickerhof, Lei Liu, Mateusz Szczygielski, Michael Carroll, Miguel Company, Nikolai Morin, Shane Loretz, Silvio Traversaro, Tomoya Fujita, Tyler Weaver, William Woodall, Yadu, andrei, mauropasse, mergify[bot], methylDragon, schrodinbug, uupks, ymski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* extract the result response before the callback is issued. (`#2132 `__) +* Update all rclcpp packages to C++17. (`#2121 `__) +* Fix the GoalUUID to_string representation (`#1999 `__) +* Explicitly set callback type (`#2059 `__) +* Update maintainers (`#2043 `__) +* Do not clear entities callbacks on destruction (`#2002 `__) +* Revert "Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__)" (`#1956 `__) +* Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__) +* Contributors: Audrow Nash, Chris Lalancette, Hubert Liberacki, Nathan Wiebe Neufeldt, Tomoya Fujita, William Woodall, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_components `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update all rclcpp packages to C++17. (`#2121 `__) +* Improve component_manager_isolated shutdown (`#2085 `__) +* Update maintainers (`#2043 `__) +* use unique ptr and remove unuseful container (`#2013 `__) +* Revert "Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__)" (`#1956 `__) +* Introduce executors new spin_for method, replace spin_until_future_complete with spin_until_complete. (`#1821 `__) (`#1874 `__) +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Hubert Liberacki, Michael Carroll, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for logging service. (`#2122 `__) +* Support publishing loaned messages in LifecyclePublisher (`#2159 `__) +* Fixes to silence some clang warnings. (`#2127 `__) +* Update all rclcpp packages to C++17. (`#2121 `__) +* Use the correct macro for LifecycleNode::get_fully_qualified_name (`#2117 `__) +* add get_fully_qualified_name to rclcpp_lifecycle (`#2115 `__) +* Implement Unified Node Interface (NodeInterfaces class) (`#2041 `__) +* Add clock type to node_options (`#1982 `__) +* Update maintainers (`#2043 `__) +* LifecycleNode on_configure doc fix. (`#2034 `__) +* Bugfix 20210810 get current state (`#1756 `__) +* Make lifecycle impl get_current_state() const. (`#2031 `__) +* Cleanup the lifecycle implementation (`#2027 `__) +* Cleanup the rclcpp_lifecycle dependencies. (`#2021 `__) +* Revert "Revert "Add a create_timer method to Node and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) (`#2010 `__) +* Revert "Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__)" (`#2009 `__) +* Add a ``create_timer`` method to ``Node`` and ``LifecycleNode`` classes (`#1975 `__) +* Support pre-set and post-set parameter callbacks in addition to on-set-parameter-callback. (`#1947 `__) +* Make create_service accept rclcpp::QoS (`#1969 `__) +* Make create_client accept rclcpp::QoS (`#1964 `__) +* Contributors: Andrew Symington, Audrow Nash, Chris Lalancette, Deepanshu Bansal, Ivan Santiago Paunovic, Jeffery Hsu, Lei Liu, Michael Babenko, Shane Loretz, Steve Macenski, Tomoya Fujita, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix type in Node init args (`#1115 `__) (`#1122 `__) +* Logging service support (`#1102 `__) +* Use custom sourcedir for conf.py (`#1109 `__) +* ServerGoalHandle should be destroyed before removing. (`#1113 `__) +* Fix unnecessary list comprehension flake8 (`#1112 `__) +* Stub type hash value line in TopicEndpointInfo string (`#1110 `__) +* Support documentation generation using rosdoc2 (`#1103 `__) +* Fix Time and Duration raising exception when compared to another type (`#1007 `__) +* Make rcl_interfaces a build and exec dependency. (`#1100 `__) +* Solving Atomic undefined on OSX with clang (`#1096 `__) +* Implement matched event (`#1083 `__) +* Update service.py documentation (`#1094 `__) +* Allow space or empty strings when using ros2 param set (`#1093 `__) +* Hook up the incompatible type event inside of rclpy (`#1058 `__) +* Switch to using module instead of module\_ (`#1090 `__) +* Add in subscription.get_publisher_count() (`#1089 `__) +* Service introspection (`#988 `__) +* to create a sublogger while getting child of Logger (`#1084 `__) +* Fix `#983 `__ by saving future and checking for + raising any exceptions (`#1073 `__) +* Force C++17 support on. (`#1076 `__) +* Use RCPPUTILS_SCOPE_EXIT to cleanup unparsed_indices_c. (`#1075 `__) +* Explicitly link atomic when building with Clang (`#1065 `__) +* Fix test_publisher linter for pydocstyle 6.2.2 (`#1063 `__) +* Add default preset qos profile (`#1062 `__) +* Add on_parameter_event method to the AsyncParameterClient. (`#1061 `__) +* Add documentation page for rclpy.clock (`#1055 `__) +* Rewrite test code without depending on parameter client (`#1045 `__) +* Add parallel callback test (`#1044 `__) +* decorator should not be callable. (`#1050 `__) +* typo fix. (`#1049 `__) +* Add in a warning for a depth of 0 with KEEP_LAST. (`#1048 `__) +* Add feature of wait for message (`#953 `__). (`#960 `__) +* Document rclpy.time.Time class (`#1040 `__) +* Deal with ParameterUninitializedException for parameter service (`#1033 `__) +* Improve documentation in rclpy.utilities (`#1038 `__) +* Document rclpy.utilities.remove_ros_args (`#1036 `__) +* Fix incorrect comparsion on whether parameter type is NOT_SET (`#1032 `__) +* [rolling] Update maintainers (`#1035 `__) +* Set the default number of threads of the MultiThreadedExecutor to 2 (`#1031 `__) +* Update the rclpy method documentation. (`#1026 `__) +* Revert "Raise user handler exception in MultiThreadedExecutor. (`#984 `__)" (`#1017 `__) +* Waitable should check callback_group if it can be executed. (`#1001 `__) +* support wildcard matching for params file (`#987 `__) +* Raise user handler exception in MultiThreadedExecutor. (`#984 `__) +* Add wait_for_node method (`#930 `__) +* Create sublogger for action server and action client (`#982 `__) +* Support for pre-set and post-set parameter callback. (`#966 `__) +* fix gcc 7.5 build errors (`#977 `__) +* make _on_parameter_event return result correctly (`#817 `__) +* Fix a small typo in documentation. (`#967 `__) +* Add Parameter Client (`#959 `__) +* Change sphinx theme to readthedocs (`#950 `__) +* Name and type in descriptor(s) is ignored via declare_parameter(s). (`#957 `__) +* Typo fix (`#951 `__) +* Add py.typed to package (`#946 `__) +* Fix rclpy.shutdown() from hanging when triggered from callback (`#947 `__) +* Check if the context is already shutdown. (`#939 `__) +* Avoid causing infinite loop when message is empty (`#935 `__) +* Expose 'best available' QoS policies (`#928 `__) +* remove feedback callback when the goal has been completed. (`#927 `__) +* Allow to create a subscription with a callback that also receives the message info (`#922 `__) +* Contributors: Achille Verheye, Audrow Nash, Barry Xu, Brian, Brian Chen, Chen Lihui, Chris Lalancette, Cristóbal Arroyo, Deepanshu Bansal, Emerson Knapp, Erki Suurjaak, Felix Divo, Florian Vahl, Gonzo, GuiHome, Ivan Santiago Paunovic, Jacob Perron, Lei Liu, Lucas Wendland, Michael Carroll, Sebastian Freitag, Seulbae Kim, Shane Loretz, Steve Nogar, Takeshi Ishita, Tomoya Fujita, Tony Najjar, Yadu, Yuki Igarashi, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcpputils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing header for strlen (`#169 `__) +* issue-167 (`#172 `__) +* [rolling] Update maintainers - 2022-11-07 (`#166 `__) +* require C++17 and deprecate the rcppmath namespace (`#165 `__) +* Mirror rolling to master +* Fix possible race condition in create_directories() (`#162 `__) +* Contributors: Artem Shumov, Audrow Nash, Sebastian Freitag, William Woodall, bijoua29 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix memory leak (`#423 `__) +* Add convenience error handling macros (`#421 `__) +* Calculate the next power-of-two for the user in hash_map_init. (`#420 `__) +* update cast to modern style (`#418 `__) +* Remove deprecated header get_env.h (`#417 `__) +* Updates to rcutils to make rosdoc2 generation happier. (`#416 `__) +* add RCUTILS_LOGGING_AUTOINIT_WITH_ALLOCATOR. (`#415 `__) +* Fix memory leak in string_map.c in rcutils (`#411 `__) +* avoid unnecessary copy for rcutils_char_array_vsprintf. (`#412 `__) +* Add missing stddef include for size_t (`#410 `__) +* Add SHA256 utility implementation (`#408 `__) +* Upgrade rcutils to C++17. (`#392 `__) +* [rolling] Update maintainers - 2022-11-07 (`#404 `__) +* Fix build on OpenHarmony (`#395 `__) +* regression of thread-safety for logging macros (`#393 `__) +* add portable nonnull macros (`#382 `__) +* Fix memory leak when adding the same key to the logger hash map multiple times (`#391 `__) +* time_unix: uses ZEPHYR_VERSION_CODE instead (`#390 `__) +* Cleanup time_unix.c (`#389 `__) +* time_unix: namespace zephyr headers (`#383 `__) +* Restrict overmatching MACH ifdef to only trigger on OSX and Mach (`#386 `__) +* Optimize rcutils_logging_get_logger_effective_level() (`#381 `__) +* Change syntax __VAR_ARGS_\_ to __VA_ARGS_\_ (`#376 `__) +* Fix a bug in hash_map_get_next_key_and_data. (`#375 `__) +* More fixes from review. +* Fixes from review. +* Make g_rcutils_logging_output_handler static. +* Make g_rcutils_logging_default_logger_level static. +* Optimize rcutils_find_lastn where possible. +* Don't bother computing the hash_map key if the hash map is empty. +* Make sure to expand char_array by at least 1.5x. +* Optimize index computation in hash_map_find. +* Improve the performance of rcutils_logging_format_message. (`#372 `__) +* Get rid of unnecessary ret variable. +* Get rid of unnecessary ifdef cplusplus checks in the C file. +* Get rid of unnecessary rcutils_custom_add\_{gtest,gmock} +* Get rid of unnecessary and unused RMW switching for logging tests. +* Remove unnecessary IS_OUTPUT_COLORIZED macro. +* Rename logging internal structures to use our new convention. +* Make all of the logging 'expand' methods static. +* Fix up error checking for RCUTILS_CONSOLE_STDOUT_LINE_BUFFERED. +* Cleanup error handling for the RCUTILS_CONSOLE_OUTPUT_FORMAT checks. +* Revamp error handling in rcutils_logging_initialize_with_allocator. +* Revamp rcutils_logging_initialize_with_allocator. +* Make a few logging global variables static. +* Optimize calls via the RCUTILS_LOG macros. (`#369 `__) +* time_unix: add zephyr posix time (`#368 `__) +* Optimize the implementation of rcutils_char_array_strncpy. (`#367 `__) +* strdup.c: fix arbitrary length overread (`#366 `__) +* Mirror rolling to master +* strdup.c: fix 1 byte buffer overread (`#363 `__) +* Clarify duration arg description in logging macros (`#359 `__) +* Update rcutils_steady_time_now to return the same data as std::chrono (`#357 `__) +* Contributors: AIxWall, Abrar Rahman Protyasha, Audrow Nash, Chen Lihui, Chris Lalancette, Emerson Knapp, Felipe Neves, Jacob Perron, Mario Prats, Maximilian Downey Twiss, Nikolai Morin, Tomoya Fujita, William Woodall, Yakumoo, guijan, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw (`#353 `__) +* Runtime Interface Reflection: rmw (`#340 `__) +* [rmw] Improve handling of dynamic discovery (`#338 `__) +* rmw_send_reqponse returns RMW_RET_TIMEOUT. (`#350 `__) +* Add a note about asynchronicity of discovery. (`#352 `__) +* Add matched event support (`#331 `__) +* Add type hash to rmw_topic_endpoint_info_t (rep2011) (`#348 `__) +* Add in inconsistent topic defines and data structures. (`#339 `__) +* Update documented expectations for GIDs (`#335 `__) +* Fix rmw->rwm typo (`#347 `__) +* Add rmw count clients, services (`#334 `__) +* make writer_guid uint8_t[] instead of int8_t for consistency with rmw_gid_t (`#329 `__) +* Update rmw to C++17. (`#346 `__) +* Reduce GID storage to 16 bytes. (`#345 `__) +* Move the RMW_CHECK_TYPE_IDENTIFIERS_MATCH macro to a C header. (`#343 `__) +* [rolling] Update maintainers - 2022-11-07 (`#337 `__) +* Remove unused test_loaned_message_sequence.cpp (`#336 `__) +* callback can be NULL to clear in Listener APIs. (`#332 `__) +* Add rmw_get_gid_for_client method (`#327 `__) +* Add 'best available' QoS policies (`#320 `__) The best available policy should select the highest level of service for the QoS setting while matching with the majority of endpoints. For example, in the case of a DDS middleware subscription, this means: * Prefer reliable reliability if all existing publishers on the same topic are reliable, otherwise use best effort. * Prefer transient local durability if all existing publishers on the same topic are transient local, otherwise use volatile. * Prefer manual by topic liveliness if all existing publishers on the same topic are manual by topic, otherwise use automatic. * Use a deadline that is equal to the largest deadline of existing publishers on the same topic. * Use a liveliness lease duration that is equal to the largest lease duration of existing publishers on the same topic. +* Move statuses definitions to rmw/events_statuses/ (`#232 `__) +* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jacob Perron, Lee, Minju, Nikolai Morin, Tomoya Fujita, William Woodall, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw_connextdds (`#115 `__) +* Revert "Refactor serialization support to use allocators and refs" +* Refactor serialization support to use allocators and refs +* Add stubs for new rmw interfaces (`#111 `__) +* Add rmw_get_gid_for_client impl (`#92 `__) +* Switch ROS2 -> ROS 2 everywhere (`#83 `__) +* Contributors: Brian, Chris Lalancette, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rmw_connextdds] New RMW discovery options (`#108 `__) +* Call get_type_hash_func (`#113 `__) +* Type hash distribution during discovery (rep2011) (`#104 `__) +* Implement matched event (`#101 `__) +* Add in implementation of inconsistent topic. (`#103 `__) +* Add rmw_get_gid_for_client impl (`#92 `__) +* Fix assert statement to allow the seconds field of a DDS_Duration_t to be zero (`#88 `__) +* Handle 'best_available' QoS policies in common (`#85 `__) +* Resolve build error with RTI Connext DDS 5.3.1 (`#82 `__) +* Contributors: Andrea Sorbini, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Grey, Jose Luis Rivero, Michael Carroll, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextddsmicro `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw_connextdds (`#115 `__) +* Add stubs for new rmw interfaces (`#111 `__) +* Add rmw_get_gid_for_client impl (`#92 `__) +* Switch ROS2 -> ROS 2 everywhere (`#83 `__) +* Contributors: Brian, Chris Lalancette, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_cyclonedds_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw_cyclonedds (`#451 `__) +* Add stubs for new rmw interfaces (`#447 `__) +* [rmw_cyclonedds] Improve handling of dynamic discovery (`#429 `__) +* Call get_type_hash_func (`#448 `__) +* Type hash distribution in discovery (rep2011) (`#437 `__) +* Disable inconsistent topic events. (`#444 `__) +* Implement matched event (`#435 `__) +* Implement inconsistent topic. (`#431 `__) +* Make sure to add semicolons to the CHECK_TYPE_IDENTIFIER_MATCH. (`#432 `__) +* [rolling] Update maintainers - 2022-11-07 (`#428 `__) +* Export CycloneDDS dependency (`#424 `__) +* add NULL check before accessing object. (`#423 `__) +* Add rmw_get_gid_for_client impl (`#402 `__) +* Makes topic_name a const ref +* Adds topic name to error msg when create_topic fails +* Improve error message when create_topic fails (`#405 `__) +* Change wrong use of %d to print uint32_t to PRIu32 (`#253 `__) +* Add cstring include. (`#393 `__) +* Handle 'best_available' QoS policies (`#389 `__) +* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jose Luis Rivero, Shane Loretz, Tomoya Fujita, Tully Foote, Voldivh, eboasson, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_dds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type hash in GraphCache, user_data encoding tools (`#70 `__) +* Mark benchmark _ as unused. (`#71 `__) +* Update rmw_dds_common to C++17. (`#69 `__) +* Change Gid.msg to be 16 bytes. (`#68 `__) +* Minor cleanups of test_qos. (`#67 `__) +* [rolling] Update maintainers - 2022-11-07 (`#65 `__) +* build shared lib only if BUILD_SHARED_LIBS is set (`#62 `__) +* Update maintainers (`#61 `__) +* Add functions for resolving 'best available' QoS policies (`#60 `__) Given a QoS profile and set of endpoints for the same topic, overwrite any policies set to BEST_AVAILABLE with a policy such that it matches all endpoints while maintaining a high level of service. Add testable functions for updating BEST_AVAILABLE policies, * qos_profile_get_best_available_for_subscription * qos_profile_get_best_available_for_publisher and add convenience functions that actual query the graph for RMW implementations to use, * qos_profile_get_best_available_for_topic_subscription * qos_profile_get_best_available_for_topic_publisher +* Contributors: Audrow Nash, Chris Lalancette, Emerson Knapp, Jacob Perron, hannes09, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw_fastrtps (`#687 `__) +* Runtime Interface Reflection: rmw_fastrtps (`#655 `__) +* [rmw_fastrtps] Improve handling of dynamic discovery (`#653 `__) +* Call get_type_hash_func (`#680 `__) +* Type hash distribution in discovery (rep2011) (`#671 `__) +* Implement inconsistent topic event (`#654 `__) +* Update all rmw_fastrtps packages to C++17. (`#674 `__) +* Rewrite how Topics are tracked in rmw_fastrtps_cpp. (`#669 `__) +* Allow loaned messages without data-sharing (`#568 `__) +* Fix incoherent dissociate_writer to dissociate_reader (`#647 `__) (`#649 `__) +* [rolling] Update maintainers - 2022-11-07 (`#643 `__) +* Add rmw_get_gid_for_client impl (`#631 `__) +* Use Fast-DDS Waitsets instead of listeners (`#619 `__) +* Remove rosidl_cmake dependency (`#629 `__) +* Revert "add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__)" (`#612 `__) +* add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__) +* Allow null arguments in the EventsExecutor parameters (`#602 `__) +* Add RMW_CHECKS to rmw_fastrtps_cpp EventsExecutor implementation +* Handle 'best_available' QoS policies (`#598 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jacob Perron, Jose Luis Rivero, Miguel Company, Oscarchoi, Ricardo González, Tomoya Fujita, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_dynamic_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw_fastrtps (`#687 `__) +* Runtime Interface Reflection: rmw_fastrtps (`#655 `__) +* [rmw_fastrtps] Improve handling of dynamic discovery (`#653 `__) +* Call get_type_hash_func (`#680 `__) +* Type hash distribution in discovery (rep2011) (`#671 `__) +* Implement inconsistent topic event (`#654 `__) +* Update all rmw_fastrtps packages to C++17. (`#674 `__) +* Rewrite how Topics are tracked in rmw_fastrtps_cpp. (`#669 `__) +* Allow loaned messages without data-sharing (`#568 `__) +* Fix incoherent dissociate_writer to dissociate_reader (`#647 `__) (`#649 `__) +* [rolling] Update maintainers - 2022-11-07 (`#643 `__) +* Add rmw_get_gid_for_client impl (`#631 `__) +* Use Fast-DDS Waitsets instead of listeners (`#619 `__) +* Revert "add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__)" (`#612 `__) +* add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__) +* Allow null arguments in the EventsExecutor parameters (`#602 `__) +* Add EventExecutor to rmw_fastrtps_dynamic_cpp +* Fix cpplint error (`#601 `__) +* Handle 'best_available' QoS policies (`#598 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Jacob Perron, Jose Luis Rivero, Miguel Company, Oscarchoi, Ricardo González, Tomoya Fujita, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_shared_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix matched event issues (`#683 `__) +* Dynamic Subscription (BONUS: Allocators): rmw_fastrtps (`#687 `__) +* Check for triggered guard conditions before waiting (`#685 `__) +* Runtime Interface Reflection: rmw_fastrtps (`#655 `__) +* [rmw_fastrtps] Improve handling of dynamic discovery (`#653 `__) +* Type hash distribution in discovery (rep2011) (`#671 `__) +* Implement matched event (`#645 `__) +* Implement inconsistent topic event (`#654 `__) +* Update all rmw_fastrtps packages to C++17. (`#674 `__) +* Rewrite how Topics are tracked in rmw_fastrtps_cpp. (`#669 `__) +* Delay lock on message callback setters (`#657 `__) +* Make sure to add semicolons to the CHECK_TYPE_IDENTIFIER_MATCH. (`#658 `__) +* Allow loaned messages without data-sharing (`#568 `__) +* Fix incoherent dissociate_writer to dissociate_reader (`#647 `__) (`#649 `__) +* [rolling] Update maintainers - 2022-11-07 (`#643 `__) +* Remove duplicated code (`#637 `__) +* Call callbacks only if unread count > 0 (`#634 `__) +* Add rmw_get_gid_for_client impl (`#631 `__) +* Use Fast-DDS Waitsets instead of listeners (`#619 `__) +* Take all available samples on service/client on_data_available. (`#616 `__) +* Revert "add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__)" (`#612 `__) +* add line feed for RCUTILS_SAFE_FWRITE_TO_STDERR (`#608 `__) +* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette, Emerson Knapp, Geoffrey Biggs, Michael Carroll, Miguel Company, Oscarchoi, Ricardo González, Tomoya Fujita, mauropasse, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rmw_implementation (`#219 `__) +* Runtime Interface Reflection: rmw_implementation (`#215 `__) +* Mark the benchmark _ variables as unused. (`#218 `__) +* Update rmw_implementation to C++17. (`#214 `__) +* [rolling] Update maintainers - 2022-11-07 (`#212 `__) +* Build-time RMW selection does not need ament_index_cpp (`#210 `__) +* Add rmw_get_gid_for_client & tests (`#206 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, G.A. vd. Hoorn, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#337 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`robot_state_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update robot_state_publisher to C++17. (`#204 `__) +* [rolling] Update maintainers - 2022-11-07 (`#203 `__) +* Mirror rolling to ros2 +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup the help text for ros2 bag record. (`#1329 `__) (`#1333 `__) +* Enable document generation using rosdoc2 for ament_python pkgs (`#1260 `__) +* CLI: Get storage-specific values from plugin (`#1209 `__) +* Fix up some of the wording in the record help text. (`#1228 `__) +* Add topic_name option to info verb (`#1217 `__) +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* rosbag2_py: parametrize tests across storage plugins (`#1203 `__) +* Added option to change node name for the recorder from the Python API (`#1180 `__) +* rosbag2_cpp: test more than one storage plugin (`#1196 `__) +* rosbag2_storage: expose default storage ID as method (`#1146 `__) +* Fix for ros2 bag play exit with non-zero code on SIGINT (`#1126 `__) +* ros2bag: move storage preset validation to sqlite3 plugin (`#1135 `__) +* Add option to prevent message loss while converting (`#1058 `__) +* Added support for excluding topics via regular expressions (`#1046 `__) +* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) +* Add short -v option to ros2 bag list for verbose (`#1065 `__) +* Use a single variable for evaluating the filter regex (`#1053 `__) +* Add additional mode of publishing sim time updates triggered by replayed messages (`#1050 `__) +* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) +* Use first available writer in recording if default ``sqlite3`` not available. (`#1044 `__) +* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) +* Added support for filtering topics via regular expressions on Playback (`#1034 `__) +* Fix incorrect boundary check for ``playback_duration`` and ``play_until_timestamp`` (`#1032 `__) +* Adds play until timestamp functionality (`#1005 `__) +* Add CLI verb for burst mode of playback (`#980 `__) +* Add play-for specified number of seconds functionality (`#960 `__) +* Make unpublished topics unrecorded by default (`#968 `__) +* Contributors: Agustin Alba Chicar, Chris Lalancette, DensoADAS, Emerson Knapp, EsipovPA, Esteve Fernandez, Geoffrey Biggs, Hunter L.Allen, Keisuke Shima, Michael Orlov, Sean Kelly, Tony Peng, Yadu, james-rms, kylemarcey, mergify[bot], ricardo-manriquez + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set automatically_declare_parameters_from_overrides in DirectNode. (`#813 `__) +* Enable document generation using rosdoc2 (`#811 `__) +* Fix linters (`#808 `__) +* add timeout option for ros2param to find node. (`#802 `__) +* Save method list via connection check to XMLRPC server. (`#796 `__) +* ZSH argcomplete: call compinit only if needed (`#750 `__) +* Fix network aware node issue (`#785 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* XMLRPC server accepts request from all local IP addresses. (`#729 `__) +* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Ivan Santiago Paunovic, Tomoya Fujita, Yadu, mjbogusz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli_common_extensions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#7 `__) +* Update maintainers (`#6 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli_test_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Remove action_msgs dependency (`#743 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2component `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 (`#811 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Fix the component load help to mention load, not unload. (`#756 `__) +* Remove unused arguments from ros2 component types. (`#711 `__) +* Contributors: Audrow Nash, Chris Lalancette, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2doctor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Shutdown ros2doctor hello when ctrl-c is received (`#829 `__) +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* Enable document generation using rosdoc2 (`#811 `__) * Fix warnings for ros2component, ros2doctor, ros2interface, and ros2node +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette, Michael Carroll, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* Enable document generation using rosdoc2 (`#811 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#331 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle_test_fixtures `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the ros2cli test fixture to C++17. (`#789 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2multicast `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Add --group and --port options to ros2 multicast (`#770 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2node `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* Enable document generation using rosdoc2 (`#811 `__) * Fix warnings for ros2component, ros2doctor, ros2interface, and ros2node +* Fix linters (`#808 `__) +* add timeout option for ros2param to find node. (`#802 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Updated wording in list.py (`#775 `__) +* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Michael Wrock, Tomoya Fujita, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2param `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* remove deprecated options (`#824 `__) +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* add timeout option for ros2param to find node. (`#802 `__) +* Fix printing of integer and double arrays. (`#804 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* refactor: make ros2param use rclpy.parameter_client (`#716 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2pkg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix typo in ros2pkg warning message. (`#828 `__) +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* resolve `#790 `__ (`#801 `__) +* Add alias library targets for CMake (`#718 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette, Kenji Brameld, RFRIEDM-Trimble, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2run `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#12 `__) +* update maintainer +* Contributors: Audrow Nash, Dharini Dutia, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* remove deprecated options (`#824 `__) +* Make all of the dependencies in pure Python packages exec_depend. (`#823 `__) +* Expect type hash cli output in test (`#822 `__) +* Fix the type annotation in pub.py. (`#814 `__) +* Switch to using new event_handler instead of qos_event. (`#787 `__) +* avoid flaky test that subscriber might not receive the message (`#810 `__) +* Adds a ``--max-wait-time`` option to ``ros2 topic pub`` (`#800 `__) +* Fix some flake8 warnings related to style. (`#805 `__) +* Adds a timeout feature to rostopic echo (`#792 `__) +* Refactor common types (`#791 `__) +* Allow configuring liveliness in ros2 topic echo and pub (`#788 `__) +* Extend timeout to shutdown the command line process. (`#783 `__) +* [rolling] Update maintainers - 2022-11-07 (`#776 `__) +* a couple of typo fixes. (`#774 `__) +* Add support use_sim_time for ros2 topic hz/bw/pub. (`#754 `__) +* Use set_message_fields from rosidl_runtime_py (`#761 `__) +* Expand auto to the current time when passed to a Header field (`#749 `__) +* Add verbose option to echo that also prints the associated message info (`#707 `__) +* update docs for bandwidth functions. (`#709 `__) +* Split the bandwidth functions into a get and print. (`#708 `__) +* Contributors: Arjo Chakravarty, Audrow Nash, Chen Lihui, Chris Lalancette, Emerson Knapp, Esteve Fernandez, Ivan Santiago Paunovic, Lei Liu, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Move ros2trace tests to new test_ros2trace package (`#63 `__) +* Error out if trace already exists unless 'append' option is used (`#58 `__) +* Improve 'ros2 trace' command error handling & add end-to-end tests (`#54 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#12 `__) +* update maintainer +* Contributors: Audrow Nash, Dharini Dutia, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) +* Contributors: Emerson Knapp, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in a missing cstdint include. (`#1321 `__) (`#1322 `__) +* Fix warning from ClassLoader in sequential compression reader and writer (`#1299 `__) (`#1316 `__) +* Add message definition read API (`#1292 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* set_read_order: return success (`#1177 `__) +* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) +* Reverse read order API and sqlite storage implementation (`#1083 `__) +* Add option to prevent message loss while converting (`#1058 `__) +* set default metadata of compressed message (in case compressor does not set it) (`#1060 `__) +* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) +* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Hunter L. Allen, Joshua Hampp, Michael Orlov, Tony Peng, james-rms, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression_zstd `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Joshua Hampp, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add recorder stop() API (`#1300 `__) (`#1334 `__) +* Add type_hash in MessageDefinition struct (`#1296 `__) +* Add message definition read API (`#1292 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* Fix for flaky ``TimeControllerClockTest::unpaused_sleep_returns_true`` test (`#1290 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Fix rwm->rmw spelling (`#1249 `__) +* Expose more Writer methods in python interface (`#1220 `__) +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* Parametrize all rosbag2_tests for both supported storage plugins (`#1221 `__) +* rosbag2_cpp: test more than one storage plugin (`#1196 `__) +* Replace language for "db3"/"db"/"database" (`#1194 `__) +* set_read_order: return success (`#1177 `__) +* Remove explicit sqlite3 from code (`#1166 `__) +* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) +* Reader and writer can use default storage by not specifying (`#1167 `__) +* rosbag2_storage: expose default storage ID as method (`#1146 `__) +* Don't reopen file for every seek if we don't have to. Search directionally for the correct file (`#1117 `__) +* Add SplitBagfile recording service. (`#1115 `__) +* Reverse read order API and sqlite storage implementation (`#1083 `__) +* Replace ``std::filesystem::path(..)`` with ``rcpputils::fs::path(..)`` (`#1104 `__) +* Fix issue where sequentialwriter only sets metadata duration to the duration of the final file (`#1098 `__) +* Delete obsolete compression_options.cpp from rosbag2_cpp (`#1078 `__) +* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) +* Remove deprecated rosbag2_cpp/storage_options.hpp, for post-Humble releases (`#1064 `__) +* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) +* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) +* Notification of significant events during bag recording and playback (`#908 `__) +* Bugfix for "Playing the bags recorded with split by duration/size is playing only the last recorded .db3." (`#1022 `__) +* Improve test_time_controller test (`#1012 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Geoffrey Biggs, Hunter L. Allen, Jorge Perez, Joshua Hampp, Kaju-Bubanja, Michael Orlov, Tony Peng, james-rms, mergify[bot], rshanor + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_examples_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Add API samples on main branch - Rolling C++ API examples (`#1068 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Michael Orlov, james-rms + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_examples_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix a warning from python setuptools. (`#1312 `__) (`#1314 `__) +* Add API samples for Python [rebased] (`#1253 `__) * Add API samples for Python * Package Renaming and Move * linting + copyright * more linting --------- Co-authored-by: Geoffrey Biggs +* Contributors: David V. Lu!!, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rosbag2 to C++17. (`#1238 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Add SplitBagfile recording service. (`#1115 `__) +* Adds stop operation for rosbag2::Player (`#1007 `__) +* Notification of significant events during bag recording and playback (`#908 `__) +* Adds play until timestamp functionality (`#1005 `__) +* Add CLI verb for burst mode of playback (`#980 `__) +* Add play-for specified number of seconds functionality (`#960 `__) +* Contributors: Agustin Alba Chicar, Chris Lalancette, Geoffrey Biggs, Michael Orlov, Misha Shalem, rshanor + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_performance_benchmarking `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add tests for rosbag2_performance_benchmarking pkg (`#1268 `__) +* Fix expectations for rosbag2 return code in rosbag2_performance_benchmarking (`#1267 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use thread pool to run benchmark publishers in rosbag2_performance_benchmarking (`#1250 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Skip ament_package() call when not building rosbag2_performance_benchmarking (`#1242 `__) +* Add option to specify a message type (`#1153 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Replace language for "db3"/"db"/"database" (`#1194 `__) +* Remove explicit sqlite3 from code (`#1166 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Michael Orlov, Shane Loretz, carlossvg + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_performance_benchmarking_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add tests for rosbag2_performance_benchmarking pkg (`#1268 `__) +* Skip ament_package() call when not building rosbag2_performance_benchmarking (`#1242 `__) +* [rolling] Bump to 0.19.0 (`#1232 `__) +* Add option to specify a message type (`#1153 `__) +* Contributors: Audrow Nash, Michael Orlov, Shane Loretz, carlossvg + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add binding to close the writer (`#1339 `__) (`#1340 `__) +* Add type_hash in MessageDefinition struct (`#1296 `__) +* Store message definitions in SQLite3 storage plugin (`#1293 `__) +* Add message definition read API (`#1292 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Expose more Writer methods in python interface (`#1220 `__) +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* rosbag2_py: parametrize tests across storage plugins (`#1203 `__) +* Added option to change node name for the recorder from the Python API (`#1180 `__) +* Replace language for "db3"/"db"/"database" (`#1194 `__) +* Remove explicit sqlite3 from code (`#1166 `__) +* Move python get_default_storage_id to storage module instead of writer (`#1165 `__) +* rosbag2_storage: expose default storage ID as method (`#1146 `__) +* rosbag2_py: set defaults for config when bag rewriting (`#1121 `__) +* Reverse read order API and sqlite storage implementation (`#1083 `__) +* expose py Reader metadata, improve ``rosbag2_py.BagMetadata`` usability (`#1082 `__) +* Added support for excluding topics via regular expressions (`#1046 `__) +* Use a single variable for evaluating the filter regex (`#1053 `__) +* Add additional mode of publishing sim time updates triggered by replayed messages (`#1050 `__) +* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) +* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) +* Added support for filtering topics via regular expressions on Playback (`#1034 `__) +* Adds play until timestamp functionality (`#1005 `__) +* Add CLI verb for burst mode of playback (`#980 `__) +* Add play-for specified number of seconds functionality (`#960 `__) +* Make unpublished topics unrecorded by default (`#968 `__) +* Fix test rosbag2_py test compatibility with Python < 3.8 (`#987 `__) +* Contributors: Agustin Alba Chicar, Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Esteve Fernandez, Geoffrey Biggs, Hunter L. Allen, Michael Orlov, Scott K Logan, Sean Kelly, Tony Peng, james-rms, kylemarcey, mergify[bot], ricardo-manriquez + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add type_hash in MessageDefinition struct (`#1296 `__) +* Add message definition read API (`#1292 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* set_read_order: return success (`#1177 `__) +* Remove explicit sqlite3 from code (`#1166 `__) +* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) +* rosbag2_storage: expose default storage ID as method (`#1146 `__) +* Don't reopen file for every seek if we don't have to. Search directionally for the correct file (`#1117 `__) +* Reverse read order API and sqlite storage implementation (`#1083 `__) +* Remove YAML_CPP_DLL define (`#964 `__) +* Added support for excluding topics via regular expressions (`#1046 `__) +* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) +* Use a single variable for evaluating the filter regex (`#1053 `__) +* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) +* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) +* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) +* Added support for filtering topics via regular expressions on Playback (`#1034 `__) +* Contributors: Akash, Chris Lalancette, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Esteve Fernandez, Hunter L. Allen, Joshua Hampp, Michael Orlov, Tony Peng, james-rms + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) +* Reverse read order API and sqlite storage implementation (`#1083 `__) +* Add support for old db3 schema used on distros prior to Foxy (`#1090 `__) +* Added support for excluding topics via regular expressions (`#1046 `__) +* Contributors: Emerson Knapp, Esteve Fernandez, Michael Orlov, james-rms + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_mcap `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add type_hash in MessageDefinition struct (`#1296 `__) +* Add message definition read API (`#1292 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* CLI: Get storage-specific values from plugin (`#1209 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* rosbag2_cpp: test more than one storage plugin (`#1196 `__) +* set_read_order: return success (`#1177 `__) +* rosbag2_storage_mcap: merge into rosbag2 repo (`#1163 `__) +* mcap_storage: 'none' is a valid storage preset profile (`#86 `__) +* mcap_storage: handle update_metadata call (`#83 `__) +* Update clang-format rules to fit ROS 2 style guide (`#80 `__) +* Revert "read_order: throw exception from set_read_order for unsupported orders" +* read_order: throw exception from set_read_order for unsupported orders +* Fix compile flags to work on rosbag_storage:0.17.x (`#78 `__) +* Fix Windows build (`#73 `__) +* set defaults for SQLite plugin parity (`#68 `__) +* rosbag2_storage_mcap: add storage preset profiles (`#57 `__) +* rename test_fixture_interfaces package to testdata (`#64 `__) +* Switch to using the vendored zstd library. (`#59 `__) +* Add set_read_order reader API (`#54 `__) +* Some minor improvements in rosbag2_storage_mcap after review (`#58 `__) +* Revert "rosbag2_storage_mcap: add storage preset profiles" +* rosbag2_storage_mcap: add storage preset profiles +* Store IDL message definitions in Schema records when no MSG definition is available (`#43 `__) +* Support timestamp-ordered playback (`#50 `__) +* Support regex topic filtering +* Add all lz4 sources to fix undefined symbols at runtime (`#46 `__) +* Upgrade mcap to fix LZ4 error and segfault (`#42 `__) +* Fix build for Foxy (`#34 `__) +* fix: minor issues (`#31 `__) * remove unnecessary block * use target_link_libraries instead of ament_target_dependencies * remove ros environment * add prefix to compile definition +* Update email address for Foxglove maintainers (`#32 `__) +* Added mcap_vendor package. Updated CMakeLists.txt to fetch dependencies with FetchContent rather than Conan. +* CMake build script will now execute pip install conan automatically. +* [1.0.0] Use Summary section for get_metadata() and seek(), implement remaining methods (`#17 `__) +* feat: add play impl (`#16 `__) +* chore: refine package.xml (`#15 `__) +* Don't throw when READ_WRITE mode is used; add .mcap file extension to recorded files (`#14 `__) +* Add dynamic message definition lookup (`#13 `__) +* Switch C++ formatter to clang-format (`#12 `__) +* Merge pull request `#7 `__ from ros-tooling/jhurliman/reader-writer +* uninitialized struct +* lint +* lint +* lint +* Reader and writer implementation +* Merge pull request `#6 `__ from wep21/add-metadata-impl +* feat: add metadata impl +* Merge pull request `#5 `__ from wep21/mcap-storage-impl +* chore: update cmake minimum version +* chore: install mcap header +* chore: include mcap header +* fix: move fetch content into rosbag2 storage mcap +* Merge pull request `#3 `__ from ros-tooling/emersonknapp/mcap_plugin_skeleton +* Add rosbag2_storage_mcap skeleton +* Contributors: Andrew Symington, Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Jacob Bandes-Storch, James Smith, John Hurliman, Michael Orlov, james-rms, wep21 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_sqlite3 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add type_hash in MessageDefinition struct (`#1296 `__) +* Store message definitions in SQLite3 storage plugin (`#1293 `__) +* Add message definition read API (`#1292 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* CLI: Get storage-specific values from plugin (`#1209 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Remove sqlite3-specific info from main README, make it more storage agnostic and point to plugin-specific README (`#1193 `__) +* set_read_order: return success (`#1177 `__) +* Add ``update_metadata(BagMetadata)`` API for storage plugin interface (`#1149 `__) +* Store db schema version and ROS_DISTRO name in db3 files (`#1156 `__) +* ros2bag: move storage preset validation to sqlite3 plugin (`#1135 `__) +* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) +* Use a single variable for evaluating the filter regex (`#1053 `__) +* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) +* Added support for filtering topics via regular expressions on Playback (`#1034 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Esteve Fernandez, Michael Orlov, james-rms + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) (`#1330 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* rosbag2_py: parametrize tests across storage plugins (`#1203 `__) +* Fix for ros2 bag play exit with non-zero code on SIGINT (`#1126 `__) +* Split up the include of rclcpp.hpp (`#1027 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, Michael Orlov, james-rms, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_msgdefs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) The intention of this PR is to move the message-definition-finding capability outside of rosbag2_storage_mcap, and allow any rosbag2 storage plugin to store message definitions. +* Contributors: james-rms + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) (`#1330 `__) +* Add type_hash in MessageDefinition struct (`#1296 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Parametrize all rosbag2_tests for both supported storage plugins (`#1221 `__) +* Make rosbag2_tests agnostic to storage implementation (`#1192 `__) +* Get rid from attempt to open DB file in ``wait_for_db()`` test fixture (`#1141 `__) +* Fix for ros2 bag play exit with non-zero code on SIGINT (`#1126 `__) +* Move sqlite3 storage implementation to rosbag2_storage_sqlite3 package (`#1113 `__) +* Readers/info can accept a single bag storage file, and detect its storage id automatically (`#1072 `__) +* Add the ability to record any key/value pair in 'custom' field in metadata.yaml (`#1038 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, Emerson Knapp, Hunter L. Allen, Michael Orlov, Tony Peng, james-rms, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change subscriptions from GenericSubscripton to SubscriptionBase (`#1338 `__) +* Add recorder stop() API (`#1300 `__) (`#1334 `__) +* Read message definitions from input files in bag_rewrite (`#1295 `__) +* Add message definition read API (`#1292 `__) +* Move rosbag2_transport::Recorder implementation to pimpl (`#1291 `__) +* rosbag2_storage: add type description hash to topic metadata (`#1272 `__) +* rosbag2_cpp: move local message definition source out of MCAP plugin (`#1265 `__) +* Use RMW methods to initialize endpoint info instead of brace initializer to guard against upcoming struct change (`#1257 `__) +* Update rosbag2 to C++17. (`#1238 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#1202 `__) +* Print "Hidden topics are not recorded" only once. (`#1225 `__) +* rosbag2_storage: set MCAP as default plugin (`#1160 `__) +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* rosbag2_transport: parametrize test_rewrite (`#1206 `__) +* rosbag2_cpp: test more than one storage plugin (`#1196 `__) +* Replace language for "db3"/"db"/"database" (`#1194 `__) +* set_read_order: return success (`#1177 `__) +* Remove explicit sqlite3 from code (`#1166 `__) +* Add pause and resume service calls for rosbag2 recorder (`#1131 `__) +* Redesign record_services tests to make them more deterministic (`#1122 `__) +* Add SplitBagfile recording service. (`#1115 `__) +* Reverse read order API and sqlite storage implementation (`#1083 `__) +* make recorder node composable by inheritance (`#1093 `__) +* Mark ``test_play_services`` as xfail for FastRTPS and CycloneDDS (`#1091 `__) +* fixed typo (`#1057 `__) +* Fix hangout in rosbag2 player and recorder when pressing ``CTRL+C`` (`#1081 `__) +* Added support for excluding topics via regular expressions (`#1046 `__) +* Use a single variable for evaluating the filter regex (`#1053 `__) +* Add additional mode of publishing sim time updates triggered by replayed messages (`#1050 `__) +* Speed optimization: Preparing copyless publish/subscribing by using const message for writing (`#1010 `__) +* Renamed --topics-regex to --regex and -e in Player class to be consistent with Recorder (`#1045 `__) +* Refactor play until and duration tests (`#1024 `__) +* Added support for filtering topics via regular expressions on Playback (`#1034 `__) +* Adds stop operation for rosbag2::Player (`#1007 `__) +* Fix incorrect boundary check for ``playback_duration`` and ``play_until_timestamp`` (`#1032 `__) +* Split up the include of rclcpp.hpp (`#1027 `__) +* Notification of significant events during bag recording and playback (`#908 `__) +* Adds play until timestamp functionality (`#1005 `__) +* Add CLI verb for burst mode of playback (`#980 `__) +* Add on play message callbacks to the ``rosbag2::Player`` class (`#1004 `__) +* Add play-for specified number of seconds functionality (`#960 `__) +* Reduce message spam when topics to be recorded do not exist (`#1018 `__) +* Address flakiness in record_all_with_sim_time test (`#1014 `__) +* Add debug instrumentation for ``test_play_services`` (`#1013 `__) +* Fix for rosbag2::Player freeze when pressing ctrl+c in pause mode (`#1002 `__) +* Add the /bigobj flag to Windows Debug builds. (`#1009 `__) +* Make unpublished topics unrecorded by default (`#968 `__) +* Make peek_next_message_from_queue return a SharedPtr. (`#993 `__) +* Change the topic names in test_record.cpp (`#988 `__) +* Contributors: Agustin Alba Chicar, Bernardo Taveira, Brian, Chris Lalancette, Cristóbal Arroyo, Daisuke Nishimatsu, DensoADAS, Emerson Knapp, Esteve Fernandez, Geoffrey Biggs, Jorge Perez, Joshua Hampp, Michael Orlov, Misha Shalem, Sean Kelly, Tony Peng, james-rms, kylemarcey, mergify[bot], rshanor + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosgraph_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_adapter `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rosidl_adapter/cmake/rosidl_adapt_interfaces.cmake: Make ament free (`#709 `__) +* [service introspection] generate service_event messages (`#700 `__) +* Adding tests for unicode support in message comments. (`#720 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Add action2idl script (`#654 `__) +* Contributors: Audrow Nash, Brian, Guilherme Henrique Galelli Christmann, John Daktylidis, Yasushi SHOJI + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix warnings (`#726 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Contributors: Audrow Nash, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Skip rosidl_generate_interfaces dependency export on SKIP_INSTALL. (`#708 `__) +* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. +* Fix comment in camel case conversion function (`#683 `__) +* Protect rosidl_target_interfaces from using NOTFOUND in include_directories (`#679 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron, Jose Luis Rivero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_core_generators `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#2 `__) +* Add generators and runtime configuration packages (`#1 `__) Moved (and renamed) from rosidl_defaults. Related PR: https://github.com/ros2/rosidl_defaults/pull/22 +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_core_runtime `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#2 `__) +* Add generators and runtime configuration packages (`#1 `__) Moved (and renamed) from rosidl_defaults. Related PR: https://github.com/ros2/rosidl_defaults/pull/22 +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_generators `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add service_msgs depend (`#24 `__) +* [rolling] Update maintainers - 2022-11-07 (`#25 `__) +* Move dependencies to rosidl_core and depend on action_msgs (`#22 `__) Move implementation to new packages rosidl_core_generators and rosidl_runtime_generators The new packages are located in a separate repository: https://github.com/ros2/rosidl_core.git rosidl_defaults now depends on the new packages, plus message definitions required for Actions (namely action_msgs). This allows users to avoid having to explictly depend on action_msgs. +* Contributors: Audrow Nash, Brian, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_runtime `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add service_msgs depend (`#24 `__) +* [rolling] Update maintainers - 2022-11-07 (`#25 `__) +* Move dependencies to rosidl_core and depend on action_msgs (`#22 `__) Move implementation to new packages rosidl_core_generators and rosidl_runtime_generators The new packages are located in a separate repository: https://github.com/ros2/rosidl_core.git rosidl_defaults now depends on the new packages, plus message definitions required for Actions (namely action_msgs). This allows users to avoid having to explictly depend on action_msgs. +* Contributors: Audrow Nash, Brian, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_dynamic_typesupport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix up the exports for rosidl_dynamic_typesupport. (`#5 `__) +* Refactor dynamic message type support impl to use allocators (`#2 `__) +* Runtime Interface Reflection: rosidl_dynamic_typesupport (`#1 `__) +* Contributors: Chris Lalancette, William Woodall, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_dynamic_typesupport_fastrtps `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove more unnecessary semicolons (`#4 `__) +* Dynamic Subscription (BONUS: Allocators): rosidl_dynamic_typesupport_fastrtps (`#3 `__) +* Remove unnecessary semicolons. (`#2 `__) +* Runtime Interface Reflection: rosidl_dynamic_typesupport_fastrtps (`#1 `__) +* Contributors: Chris Lalancette, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Expose type hash on typesupports (rep2011) (`#729 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Move rosidl_generator_c/cpp tests to a separate package (`#701 `__) +* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. +* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) +* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Expose type hash on typesupports (rep2011) (`#729 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Move rosidl_generator_c/cpp tests to a separate package (`#701 `__) +* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. +* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) +* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_dds_idl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#60 `__) +* Replace rosidl_cmake imports with rosidl_pycommon (`#59 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Hides the assertions that checks the data types of the message fields. (`#194 `__) +* Service introspection (`#178 `__) +* [rolling] Update maintainers - 2022-11-07 (`#189 `__) +* Remove stray numpy import (`#185 `__) +* :man_farmer: Fix NaN values bound numpy windows version (`#182 `__) +* Allow NaN values to pass floating point bounds check. (`#167 `__) +* Replace rosidl_cmake imports with rosidl_pycommon (`#177 `__) +* Change decode error mode to replace (`#176 `__) +* Merge pull request `#173 `__ from ros2/quarkytale/fix_import_order +* fix flake +* sorting after conversion +* Revert "Use modern cmake targets to avoid absolute paths to appear in binary archives (`#160 `__)" (`#166 `__) +* Use modern cmake targets to avoid absolute paths to appear in binary archives (`#160 `__) +* michel as author +* adding maintainer +* Contributors: Audrow Nash, Ben Wolsieffer, Brian, Cristóbal Arroyo, Dharini Dutia, Eloy Briceno, Ivan Santiago Paunovic, Jacob Perron, Tomoya Fujita, quarkytale, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [service introspection] generate service_event messages (`#700 `__) * add service event message +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Move rosidl_generator_c/cpp tests to a separate package (`#701 `__) +* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_type_description `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Expose type hash on typesupports (rep2011) (`#729 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* Contributors: Emerson Knapp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Always include whitespace in string literals (`#688 `__) +* Contributors: Audrow Nash, Brian, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. +* Contributors: Audrow Nash, Emerson Knapp, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Dynamic Subscription (BONUS: Allocators): rosidl (`#737 `__) +* Runtime Interface Reflection: rosidl (`#728 `__) +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Copied type_description_interfaces structs (rep2011) (`#732 `__) +* Expose type hash on typesupports (rep2011) (`#729 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Contributors: Audrow Nash, Brian, Emerson Knapp, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Copied type_description_interfaces structs (rep2011) (`#732 `__) +* Fix a few more clang analysis problems. (`#731 `__) +* Return reference from BoundedVector::emplace_back (`#730 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* fix conversion to ‘std::streamsize’ {aka ‘long int’} from ‘size_t’ {aka ‘long unsigned int’} may change the sign of the result (`#715 `__) +* Contributors: Alexander Hans, Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, ralwing + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace the use __slots_\_ for the appropiate API (`#23 `__) +* fix(typing): ``get_interface_packages`` returns a dict (`#22 `__) +* [rolling] Update maintainers - 2022-11-07 (`#21 `__) +* Expand timestamps for std_msgs.msg.Header and builtin_interfaces.msg.Time if 'auto' and 'now' are passed as values (`#19 `__) +* Document a missing parameter in message_to_yaml. (`#18 `__) +* Mirror rolling to master +* Contributors: Audrow Nash, Chris Lalancette, Eloy Briceno, Esteve Fernandez, 兰陈昕 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Nested Support (`#141 `__) +* Fix rosidl_typesupport_c/cpp exec dependencies. (`#140 `__) +* Type hashes in typesupport (rep2011) (`#135 `__) +* Mark benchmark _ as UNUSED. (`#134 `__) +* Service introspection (`#127 `__) +* Update rosidl_typesupport to C++17. (`#131 `__) +* [rolling] Update maintainers - 2022-11-07 (`#130 `__) +* Replace rosidl_cmake imports with rosidl_pycommon (`#126 `__) +* [service introspection] Use stddef.h instead of cstddef (`#125 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Nested Support (`#141 `__) +* Fix rosidl_typesupport_c/cpp exec dependencies. (`#140 `__) +* Type hashes in typesupport (rep2011) (`#135 `__) +* Mark benchmark _ as UNUSED. (`#134 `__) +* Service introspection (`#127 `__) +* Update rosidl_typesupport to C++17. (`#131 `__) +* [rolling] Update maintainers - 2022-11-07 (`#130 `__) +* Replace rosidl_cmake imports with rosidl_pycommon (`#126 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Nested Support (`#101 `__) +* Type hashes on typesupport (rep2011) (`#98 `__) +* Expose type hash to typesupport structs (rep2011) (`#95 `__) +* Mark benchmark _ as UNUSED. (`#96 `__) +* Service introspection (`#92 `__) +* Update rosidl_typesupport_fastrtps to C++17. (`#94 `__) +* [rolling] Update maintainers - 2022-11-07 (`#93 `__) +* Replace rosidl_cmake imports with rosidl_pycommon (`#91 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Nested Support (`#101 `__) +* Type hashes on typesupport (rep2011) (`#98 `__) +* Depend on ament_cmake_ros to default SHARED to ON (`#99 `__) +* Expose type hash to typesupport structs (rep2011) (`#95 `__) +* Mark benchmark _ as UNUSED. (`#96 `__) +* Service introspection (`#92 `__) +* Update rosidl_typesupport_fastrtps to C++17. (`#94 `__) +* [rolling] Update maintainers - 2022-11-07 (`#93 `__) +* Replace rosidl_cmake imports with rosidl_pycommon (`#91 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron, Tyler Weaver + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Contributors: Audrow Nash, Brian + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Expose type hash on typesupports (rep2011) (`#729 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. +* Fix build export dependencies in C introspection package (`#695 `__) +* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) +* Contributors: Audrow Nash, Brian, Emerson Knapp, Jacob Perron, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Type Description Codegen and Typesupport (rep2011) (`#727 `__) +* Expose type hash on typesupports (rep2011) (`#729 `__) +* Type hash in interface codegen (rep2011) (`#722 `__) +* Make sure to add the event message to typesupport introspection cpp. (`#724 `__) +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Move rosidl_cmake Python module to a new package rosidl_pycommon (`#696 `__) Deprecate the Python module in rosidl_cmake and move the implementation to the new package rosidl_pycommon. +* Add namespaced ALIAS target to easily consume generated libraries via add_subdirectory (`#605 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette, Emerson Knapp, Jacob Perron, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix a few more clang analysis problems. (`#731 `__) In particular, make sure to mark the fact that we are C++17 (as the emplace_back signature changed), and also add in a few more (void)_ for benchmark tests. +* [service introspection] generate service_event messages (`#700 `__) +* [rolling] Update maintainers - 2022-11-07 (`#717 `__) +* Contributors: Audrow Nash, Brian, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* typesupport_tests needs to be updated to C++17 (`#137 `__) +* Fix Typesupport Introspection tests (`#133 `__) +* Make rosidl_typesupport_tests depend on rosidl_generator_cpp. (`#132 `__) +* Service introspection (`#127 `__) +* Contributors: Brian, Chris Lalancette, Cristóbal Arroyo, Lucas Wendland + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rpyutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#10 `__) +* Mirror rolling to master +* updating maintainer +* Contributors: Audrow Nash, Dharini Dutia + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix build of ``rqt`` with ``setuptools>=v61.0.0`` (`#271 `__) +* [rolling] Update maintainers - 2022-11-07 (`#283 `__) +* Fix up the package description. (`#250 `__) +* Contributors: Audrow Nash, Chris Lalancette, Daniel Reuter, Dharini Dutia, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#14 `__) +* Small cleanups to the rqt_action plugin (`#13 `__) +* Mirror rolling to ros2 +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use default storage id (`#140 `__) +* Use rosbag2_py API instead of direct bag parsing +* [rolling] Update maintainers - 2022-11-07 (`#132 `__) +* For get_entry_after, bump by 1 nanosecond otherwise always get the same message equal to the timestamp +* Use rosbag2_py.reader for all message queries, remove sqlite3 direct usage +* Cleanup for review +* Improved logging +* Use a rosbag2_py.Reader to get bag metadata +* Disable reading from bag while recording - use direct caching to index for timeline +* Increase publishing checkbox size (`#122 `__) +* Fix toggle thumbnails button (`#117 `__) +* ensure data types match what PyQt expects (`#118 `__) +* Visualize topics being published and highlight topic being selected (`#116 `__) +* Be able to scroll up and down, not only zoom-in and out the timeline (`#114 `__) +* [Fixes] Fix crash when no qos metadata, make scroll bar appear if needed, add gitignore (`#113 `__) +* Fix the types being passed into QFont and QColor. (`#109 `__) +* Fix tuples for bisect calls (`#67 `__) (`#76 `__) +* fix long topic names (`#114 `__) +* fix zoom behavior (`#76 `__) +* Contributors: Audrow Nash, Chris Lalancette, Emerson Knapp, Ivan Santiago Paunovic, Kenji Brameld, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changes the use of __slots_\_ for the field and field type getter (`#138 `__) +* [rolling] Update maintainers - 2022-11-07 (`#132 `__) +* Contributors: Audrow Nash, Eloy Briceno + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#39 `__) +* added new maintainer +* Contributors: Arne Hitzmann, Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_graph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Refresh rosgraph when params checkbox is clicked (`#87 `__) +* [rolling] Update maintainers - 2022-11-07 (`#83 `__) +* Minor cleanup (`#80 `__) +* Mirror rolling to galactic-devel +* graph load/save into DOT file corrections for py3 (`#78 `__) +* Remove repeated prefixes from buttons +* Contributors: Audrow Nash, Chris Lalancette, David V. Lu!!, Yadunund, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#283 `__) +* Display basic help information when no plugins are loaded (`#268 `__) +* Contributors: Audrow Nash, Dharini Dutia, Michael Jeronimo, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rqt to C++17. (`#285 `__) +* [rolling] Update maintainers - 2022-11-07 (`#283 `__) +* Contributors: Audrow Nash, Chris Lalancette, Dharini Dutia, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix an exception raised when terminating with Ctrl+c (`#292 `__) +* [rolling] Update maintainers - 2022-11-07 (`#283 `__) +* Contributors: Audrow Nash, Chen Lihui, Dharini Dutia, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_msg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#17 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_plot `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix regression from #87 (`#91 `__) +* Changes the use of __slots_\_ for the field and field type getter (`#87 `__) +* [rolling] Update maintainers - 2022-11-07 (`#83 `__) +* Fix fixed-size Array visualization (`#81 `__) +* Contributors: Audrow Nash, Eloy Briceno, Jacob Perron, Michael Jeronimo, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changes the use of __slots_\_ for the field and field type getter +* [rolling] Update maintainers - 2022-11-07 (`#36 `__) +* Minor cleanups in rqt_publisher for ROS 2 (`#35 `__) +* Delete sync to foxy-devel workflow +* Merge pull request `#33 `__ from NBadyal/improve-evaluation-of-types +* Use regex matching to strip errors from input +* Change slot_type verification strategy +* Mirror rolling to foxy-devel +* Contributors: Audrow Nash, Chris Lalancette, Geoffrey Biggs, Michael Jeronimo, Nicholas Badyal, Voldivh + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changes the use of __slots_\_ for the field and field type getter (`#289 `__) +* [rolling] Update maintainers - 2022-11-07 (`#283 `__) +* Contributors: Audrow Nash, Dharini Dutia, Eloy Briceno, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#13 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_reconfigure `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* reorder imports to fix flake8 warning (`#129 `__) +* Fixed validator locale when float value is not bound in a range. (`#121 `__) +* get parameter type from descriptor +* [rolling] Update maintainers - 2022-11-07 (`#122 `__) +* Cleanup mislabeled BSD license (`#66 `__) +* Add support for array types (`#108 `__) +* Fix float slider step size (`#117 `__) +* update maintainer +* Fixed package to run with ros2 run (`#81 `__) +* fix updating range limits (`#108 `__) +* Improvement; "GUI hangs for awhile or completely, when any one of nodes doesn't return any value" (`#81 `__) +* Contributors: Aris Synodinos, Audrow Nash, Christian Rauch, Dharini Dutia, Florian Vahl, Jacob Perron, Shrijit Singh, Tully Foote, quarkytale + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_service_caller `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#25 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_shell `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#17 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_srv `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#10 `__) +* Contributors: Audrow Nash, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#43 `__) +* Implement bandwidth monitoring (`#40 `__) +* Fix the display of array type elements. (`#41 `__) +* Fix removal of topics while they are being monitored. (`#39 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rti_connext_dds_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use unified approach for checking the existence of environment variables (`#117 `__) +* Contributors: Christopher Wecht + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rttest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#121 `__) +* Addressing issues found in Humble testing (`#116 `__) +* Contributors: Audrow Nash, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make rviz1_to_rviz2.py accept configs with missing values (`#945 `__) +* Update rviz to C++17. (`#939 `__) +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* Add rviz1_to_rviz2.py conversion script (`#882 `__) +* Contributors: Audrow Nash, Chris Lalancette, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_assimp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* If vendored assimp is present, always prefer that (`#970 `__) +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#898 `__) +* Contributors: Audrow Nash, Cristóbal Arroyo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update Frame shortcut (`#958 `__) * Update Frame shortcut +* Update rviz to C++17. (`#939 `__) +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* Remove YAML_CPP_DLL define (`#831 `__) +* Document getTransform() time behavior (`#893 `__) +* Ogre 1.12.10 upgrade (`#878 `__) +* Add RVIZ_COMMON_PUBLIC macro (`#865 `__) +* Add time jump handler (`#752 `__) (`#791 `__) +* Make sure not to dereference a null Renderable pointer. (`#850 `__) +* Contributors: Akash, Audrow Nash, Chris Lalancette, David V. Lu!!, Kenji Brameld, Marcel Zeilinger, Shane Loretz, juchajam + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix ODR errors with gmock (`#967 `__) +* Update Frame shortcut (`#958 `__) +* point_marker: fix bug where the number of rendered points accumulates over time (`#949 `__) +* Update rviz to C++17. (`#939 `__) +* Fix tolerance calculation precision (`#934 `__) +* Fix MeshResourceMarker for mesh with color-based embedded material (`#928 `__) +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* Add Map Display binary option (`#846 `__) +* Delete frame_locked_markers when reusing marker (`#907 `__) +* Consider region of interest in CameraDisplay (`#864 `__) +* std::copy fix - OccupancyGridUpdate - Data is not being processed correctly (`#895 `__) +* Set error status when duplicate markers are in the same MarkerArray (`#891 `__) +* Make Axes display use latest transform (`#892 `__) +* Show link names in inertia error message (`#874 `__) +* Ogre 1.12.10 upgrade (`#878 `__) +* Use make_shared to construct PointCloud2 (`#869 `__) +* Fix include order (`#858 `__) +* Contributors: AndreasR30, Audrow Nash, Chris Lalancette, David V. Lu!!, Eric, Hunter L. Allen, Jacob Perron, Kenji Brameld, Patrick Roncagliolo, Shane Loretz, Timon Engelke, Xavier BROQUERE, Xenofon Karamanos, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_ogre_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix build failures on macOS + Apple Silicon (`#944 `__) +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* Remove broken rviz_ogre_vendor::RenderSystem_GL target (`#920 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#898 `__) +* Ogre 1.12.10 upgrade (`#878 `__) +* Make resource file paths relative (`#862 `__) +* Use CMAKE_STAGING_PREFIX for staging OGRE installation (`#861 `__) +* Contributors: Audrow Nash, Cristóbal Arroyo, Kenji Brameld, Scott K Logan, Shane Loretz, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* add test to ensure binary STL files from SOLIDWORKS get imported without a warning (`#917 `__) +* Ogre 1.12.10 upgrade (`#878 `__) +* Stop using glsl150 resources for now. (`#851 `__) +* Contributors: Audrow Nash, Chris Lalancette, Kenji Brameld + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* add test to ensure binary STL files from SOLIDWORKS get imported without a warning (`#917 `__) +* Contributors: Audrow Nash, Kenji Brameld + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_visual_testing_framework `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rviz to C++17. (`#939 `__) +* [rolling] Update maintainers - 2022-11-07 (`#923 `__) +* Ogre 1.12.10 upgrade (`#878 `__) +* Contributors: Audrow Nash, Chris Lalancette, Kenji Brameld + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update YUV format codes and documentation (`#214 `__) +* sensor_msgs/Range lacks variance field (`#181 `__) +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Replaced non-ASCII dash symbol with ASCII dash (`#208 `__) +* Add NV21 and NV24 to colour formats (`#205 `__) +* Update BatteryState.msg (`#206 `__) +* use regex for matching cv types (`#202 `__) +* Fix outdated file path for image_encodings (`#200 `__) +* Use uint32_t for pointcloud2 resize method (`#195 `__) +* Retain width and height after resize for master (`#193 `__) +* Contributors: Audrow Nash, Borong Yuan, Chris Lalancette, Christian Rauch, El Jawad Alaa, Geoffrey Biggs, Ivan Zatevakhin, Kenji Brameld, Tianyu Li + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing dep for sensor_msgs_py (`#217 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Add support for non standard point step sizes (`#199 `__) +* Remove reference to old implementation (`#198 `__) +* Contributors: Audrow Nash, Florian Vahl, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`service_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* Add service_msgs package (`#143 `__) +* Contributors: Brian, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shape_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Fix SolidPrimitive.msg to contain a single Polygon (`#189 `__) +* Contributors: Audrow Nash, Chris Lalancette, M. Fatih Cırıt + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shared_queues_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#1084 `__) +* Contributors: Cristóbal Arroyo, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`spdlog_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to spdlog 1.9.2 (`#33 `__) +* [rolling] Update maintainers - 2022-11-07 (`#31 `__) +* Update to spdlog 1.9.1 (`#27 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#30 `__) +* build shared lib only if BUILD_SHARED_LIBS is set (`#29 `__) +* Mirror rolling to master +* xml tag order +* updating maintainer +* Contributors: Audrow Nash, Chris Lalancette, Cristóbal Arroyo, Dharini Dutia, Scott K Logan, hannes09 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sqlite3_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to sqlite3 3.37.2 (`#1274 `__) This matches version distributed in Ubuntu Jammy. +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#1084 `__) +* Contributors: Cristóbal Arroyo, Michael Orlov, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sros2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix SSH commands in SROS2_Linux.md (`#286 `__) +* Make type of get_package_share_directory apparent for sphinx (`#284 `__) +* Contributors: Boris Boutillier, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`statistics_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_srvs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`stereo_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tango_icons_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#10 `__) +* Mirror rolling to master +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the system tests to C++17. (`#510 `__) +* [rolling] Update maintainers - 2022-11-07 (`#509 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli_remapping `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the system tests to C++17. (`#510 `__) +* [rolling] Update maintainers - 2022-11-07 (`#509 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_communication `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the system tests to C++17. (`#510 `__) +* [rolling] Update maintainers - 2022-11-07 (`#509 `__) +* Revert "Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__)" (`#504 `__) +* Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__) +* Contributors: Audrow Nash, Chris Lalancette, Hubert Liberacki, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_interface_files `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#21 `__) +* Mirror rolling to master +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 (`#359 `__) +* Fix normalize_parameters_dict for multiple nodes in the same namespace (`#347 `__) +* Implement None check for ComposableNodeContainer (`#341 `__) +* Add LifecyleTransition action (`#317 `__) +* Ensure load_composable_nodes respects condition (`#339 `__) +* [rolling] Update maintainers - 2022-11-07 (`#331 `__) +* RosTimer -> ROSTimer and PushRosNamespace -> PushROSNamespace, to follow PEP8 (`#326 `__) +* add SetROSLogDir action (`#325 `__) +* Support default values in parameter substitution (`#313 `__) +* Run condition for composable nodes (`#311 `__) +* Load composable nodes in sequence (`#315 `__) +* Contributors: Aditya Pande, Alexey Merzlyakov, Audrow Nash, Christoph Hellmann Santos, Kenji Miyake, Shane Loretz, William Woodall, Yadu, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#671 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) (`#151 `__) +* [rolling] Update maintainers - 2022-11-07 (`#150 `__) +* Depend on rosidl_core_generators for packages required by actions (`#144 `__) +* Make the functions in the header static inline (`#140 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_osrf_testing_tools_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Changing C++ Compile Version (`#76 `__) +* Update maintainers (`#74 `__) +* Contributors: Audrow Nash, Lucas Wendland + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_quality_of_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix ODR errors with gtest (`#514 `__) +* Avoid flaky test (`#513 `__) +* Update the system tests to C++17. (`#510 `__) +* [rolling] Update maintainers - 2022-11-07 (`#509 `__) +* Pass rclcpp::QoS to create_service (`#507 `__) +* Pass rclcpp::QoS to create_client (`#506 `__) +* Remove Werror from test_quality_of_service. (`#503 `__) +* Revert "Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__)" (`#504 `__) +* Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__) +* Add tests for 'best available' QoS policies (`#501 `__) +* Contributors: Audrow Nash, Chen Lihui, Chris Lalancette, Hubert Liberacki, Jacob Perron, Shane Loretz, William Woodall, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the system tests to C++17. (`#510 `__) +* [rolling] Update maintainers - 2022-11-07 (`#509 `__) +* Pass rclcpp::QoS to create_service (`#507 `__) +* Pass rclcpp::QoS to create_client (`#506 `__) +* Revert "Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__)" (`#504 `__) +* Replace deprecated spin_until_future_complete with spin_until_complete (`#499 `__) +* Contributors: Audrow Nash, Chris Lalancette, Hubert Liberacki, Shane Loretz, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add tests for rmw matched event (`#216 `__) +* Update rmw_implementation to C++17. (`#214 `__) +* [rolling] Update maintainers - 2022-11-07 (`#212 `__) +* Add rmw_get_gid_for_client & tests (`#206 `__) +* Contributors: Audrow Nash, Barry Xu, Brian, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Move ros2trace tests to new test_ros2trace package (`#63 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_security `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#509 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#578 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable tracing on Android (`#72 `__) +* Add intra-process tracepoints (`#30 `__) +* Allow requiring minimum lttng package version for is_lttng_installed (`#59 `__) +* Disable tracing on macOS (`#53 `__) +* Include tracepoints by default on Linux (`#31 `__) +* Fix memory leak in tracetools::get_symbol() (`#43 `__) +* Update tracing to C++17. (`#33 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Przemysław Dąbrowski, ymski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Error out if trace already exists unless 'append' option is used (`#58 `__) +* Make subbuffer size configurable with Trace action (`#51 `__) +* Allow requiring minimum lttng package version for is_lttng_installed (`#59 `__) +* Enable document generation using rosdoc2 for ament_python pkgs (`#50 `__) +* Contributors: Christophe Bedard, Christopher Wecht, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix error code returned in BufferCore::walkToTopParent (`#602 `__) +* Depend on ament_cmake_ros to default SHARED to ON (`#591 `__) +* Fix a potential crash in TimeCache::findClosest (`#592 `__) +* Extend TimeCache API to provide rich ExtrapolationException infos (`#586 `__) +* Update geometry2 to C++17 (`#584 `__) +* Include required header Scalar.h (`#559 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Chris Lalancette, Patrick Roncagliolo, Shane Loretz, Tyler Weaver + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_bullet `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#578 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#578 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update geometry2 to C++17 (`#584 `__) +* Update maintainers (`#560 `__) +* Use orocos_kdl_vendor and orocos-kdl target (`#534 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add do_transform_polygon_stamped (`#582 `__) +* Update the demos to C++17. (`#578 `__) +* Update maintainers (`#560 `__) +* Add torque due to force offset (`#538 `__) +* Use orocos_kdl_vendor and orocos-kdl target (`#534 `__) +* Contributors: Audrow Nash, Chris Lalancette, Paul Gesel, Scott K Logan, Tony Najjar + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#578 `__) +* Update maintainers (`#560 `__) +* Use orocos_kdl_vendor and orocos-kdl target (`#534 `__) +* Contributors: Audrow Nash, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update geometry2 to C++17 (`#584 `__) +* Update maintainers (`#560 `__) +* Remove action_msgs dependency (`#547 `__) +* Contributors: Audrow Nash, Chris Lalancette, Jacob Perron + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update geometry2 to C++17 (`#584 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Destroy callback group before node (`#595 `__) +* Enable TransformListener node-based constructor in Intra-process enabled components (`#572 `__) +* Fix use-after-free bug in BufferServer::cancelCB (`#579 `__) +* Update the demos to C++17. (`#578 `__) +* add constructor to static tf broadcaster accepting node interfaces (`#576 `__) +* Update maintainers (`#560 `__) +* Switching from sstream to c string formatting to fix ros arg issue (`#557 `__) +* allow construction of tf broadcaster from node object (not a pointer) (`#555 `__) +* Allow to construct ``TransformBroadcaster`` and ``TransformListener`` from node interfaces (`#552 `__) +* Suppress spam from calling canTransform (`#529 `__) +* Contributors: Alberto Soragna, Alexander Hans, Audrow Nash, Chris Lalancette, Gonzo, Michael Carroll, Patrick Roncagliolo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update sys.path with wokring directory (`#594 `__) +* Enable document generation using rosdoc2 for ament_python pkgs (`#587 `__) +* Update maintainers (`#560 `__) +* Use pytest rather than unittest to enable repeat (`#558 `__) +* Contributors: Audrow Nash, Michael Carroll, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#578 `__) +* Update maintainers (`#560 `__) +* feat: export tf2 sensor msgs target (`#536 `__) +* tf2_sensor_msgs find the right Python executable. (`#525 `__) +* Add missing ament_cmake_pytest package needed because of newly-enabled test (`#520 `__) +* Port point cloud transformation to numpy (`#507 `__) +* Contributors: Audrow Nash, Chris Lalancette, Daisuke Nishimatsu, Florian Vahl, Jorge Perez, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable document generation using rosdoc2 for ament_python pkgs (`#587 `__) +* Update maintainers (`#560 `__) +* Contributors: Audrow Nash, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#13 `__) +* Update maintainers (`#12 `__) +* Contributors: Audrow Nash, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update realtime support to C++17. (`#122 `__) +* [rolling] Update maintainers - 2022-11-07 (`#121 `__) +* Addressing issues found in Humble testing (`#116 `__) +* Contributors: Audrow Nash, Chris Lalancette, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_monitor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update launch file name format to match documentation (`#588 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Patrick Wspanialy + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_statistics_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the demos to C++17. (`#594 `__) +* [rolling] Update maintainers - 2022-11-07 (`#589 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Disable tracing on Android (`#72 `__) +* Add intra-process tracepoints (`#30 `__) +* Improve tracetools rosdoc2/doxygen output (`#57 `__) +* Update README and other documentation (`#55 `__) +* Disable tracing on macOS (`#53 `__) +* Include tracepoints by default on Linux (`#31 `__) +* Explicitly link against dl for dladdr() (`#48 `__) +* Fix memory leak in tracetools::get_symbol() (`#43 `__) +* Add TRACEPOINT_ENABLED() and DO_TRACEPOINT() macros (`#46 `__) +* Update tracing to C++17. (`#33 `__) +* Add new rclcpp_subscription_init tracepoint to support new intra-process comms +* Contributors: Chris Lalancette, Christophe Bedard, Przemysław Dąbrowski, ymski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Error out if trace already exists unless 'append' option is used (`#58 `__) +* Improve 'ros2 trace' command error handling & add end-to-end tests (`#54 `__) +* Make subbuffer size configurable with Trace action (`#51 `__) +* Enable document generation using rosdoc2 for ament_python pkgs (`#50 `__) +* Remove deprecated context_names parameter (`#38 `__) +* Contributors: Christophe Bedard, Christopher Wecht, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Error out if trace already exists unless 'append' option is used (`#58 `__) +* Improve 'ros2 trace' command error handling & add end-to-end tests (`#54 `__) +* Make subbuffer size configurable with Trace action (`#51 `__) +* Add intra-process tracepoints (`#30 `__) +* Allow requiring minimum lttng package version for is_lttng_installed (`#59 `__) +* Include tracepoints by default on Linux (`#31 `__) +* Enable document generation using rosdoc2 for ament_python pkgs (`#50 `__) +* Replace distutils.version.StrictVersion with packaging.version.Version (`#42 `__) +* Remove deprecated context_names parameter (`#38 `__) +* Contributors: Christophe Bedard, Christopher Wecht, Yadu, ymski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`trajectory_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`turtlesim `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove the range constraints from the holonomic parameter. (`#150 `__) (`#151 `__) +* Add icon (`#148 `__) (`#149 `__) +* Update turtlesim to C++17. (`#146 `__) +* [rolling] Update maintainers - 2022-11-07 (`#145 `__) +* Add parameter to enable holonomic motion (`#131 `__) +* Add humble turtle (`#140 `__) +* Contributors: Audrow Nash, Chris Lalancette, Daisuke Sato, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`type_description_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add GetTypeDescription.srv (rep2011) (`#153 `__) +* new package and interfaces for describing other types (`#146 `__) +* Contributors: Emerson Knapp, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`unique_identifier_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#26 `__) +* Depend on rosidl_core instead of rosidl_defaults (`#24 `__) +* Mirror rolling to master +* Update maintainers (`#22 `__) +* Contributors: Audrow Nash, Jacob Perron, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#35 `__) +* [urdf] package.xml: add missing exec_depend to urdf_parser_plugin (`#34 `__) +* Provide copy and move constructors for ``model`` (`#33 `__) +* Add linter tests and fix errors (`#30 `__) +* fix `#30 `__ +* Contributors: Audrow Nash, Daniel Reuter, Tobias Neumann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf_parser_plugin `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#35 `__) +* Contributors: Audrow Nash + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`visualization_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update common_interfaces to C++17. (`#215 `__) +* [rolling] Update maintainers - 2022-11-07 (`#210 `__) +* Contributors: Audrow Nash, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`yaml_cpp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [rolling] Update maintainers - 2022-11-07 (`#40 `__) +* Export YAML_CPP_DLL define on Windows (`#30 `__) (`#38 `__) +* Sets CMP0135 policy behavior to NEW (`#36 `__) +* Fixes policy CMP0135 warning for CMake >= 3.24 (`#35 `__) +* build shared lib only if BUILD_SHARED_LIBS is set (`#34 `__) +* Mirror rolling to master +* Contributors: Audrow Nash, Cristóbal Arroyo, Jacob Perron, hannes09 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`zstd_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) +* Bump zstd to 1.4.8 in zstd_vendor package (`#1132 `__) +* Fix/zstd vendor does not find system zstd (`#1111 `__) +* Contributors: DasRoteSkelett, Michael Orlov \ No newline at end of file diff --git a/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst b/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst index 9737fe90078..78cfaba9e30 100644 --- a/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst @@ -1,3325 +1,3329 @@ -Jazzy Jalisco changelog -======================= - -This page is a list of the complete changes in all ROS 2 core packages since the previous release. - -.. contents:: Table of Contents - :local: - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Fix format-security warning with clang. (`#663 `__) -* Migrate std::bind calls to lambda expressions (`#659 `__) -* Contributors: Chris Lalancette, Felipe Gomes de Melo, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Add tests to action_tutorials_py. (`#664 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`actionlib_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Fix a warning from newer versions of flake8. (`#469 `__) -* remove AMENT_IGNORE check in clang-tidy when looking for compilation db (`#441 `__) -* Contributors: Alberto Soragna, Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Add ament_auto_add_gmock to ament_cmake_auto (`#482 `__) -* Contributors: Jordan Palacios, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Provide --header-filter and --jobs to CMake. (`#450 `__) -* Contributors: Michael Jeronimo, Roderick Taylor - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set hints to find the python version we actually want. (`#508 `__) -* Update maintainer list in package.xml files (`#503 `__) -* Use CMAKE_CURRENT_BINARY_DIR instead of CMAKE_BINARY_DIR in ament_generate_environment (`#485 `__) -* Fix CMake error when entire ament projects are added via add_subdirectory (`#484 `__) -* Contributors: Chris Lalancette, Michael Jeronimo, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Increased cpplint timeout by default on Windows (`#486 `__) -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Alejandro Hernández Cordero, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_definitions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_link_flags `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_export_targets `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Add NAMESPACE support to ament_export_targets (`#498 `__) -* Contributors: Michael Jeronimo, Ryan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gen_version_h `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Update to C++17 (`#488 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gmock `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Split ament_add_gmock into _executable and _test. (`#497 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_google_benchmark `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gtest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Split ament_add_gmock into _executable and _test. (`#497 `__) -* ament_add_gtest_test: add TEST_NAME parameter (`#492 `__) -* Contributors: Chris Lalancette, Christopher Wecht, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_include_directories `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_libraries `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* perf: faster ament_libraries_deduplicate implementation (`#448 `__) Co-authored-by: Scott K Logan -* Subtle fix for ament_libraries_deduplicate tests (`#516 `__) -* Add some basic tests to ament_cmake_libraries (`#512 `__) -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo, Scott K Logan, Vincent Richard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in a comment explaining where Python3::Interpreter comes from. (`#510 `__) -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_target_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Fix ``ament_target_dependencies`` (`#452 `__) -* Contributors: Michael Jeronimo, Vincent Richard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Recursively check for errors/failures in produced JUnit result XMLs (`#446 `__) -* Contributors: Michael Jeronimo, Nick Morales - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added Timeout to ament_uncrustify (`#485 `__) -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Alejandro Hernández Cordero, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_vendor_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add more CMake variables to pass to vendor projects (`#519 `__) -* Fix patch file dependencies in ament_cmake_vendor_package (`#520 `__) -* Update maintainer list in package.xml files (`#503 `__) -* Always set CMAKE_C[XX]_COMPILER for vendor packages if needed (`#476 `__) -* Switch to CMake 'braket arguments' (`#461 `__) -* Replace 'git' dep with 'vcstool' (`#462 `__) -* Add support for specifying a patch directory in ament_vendor (`#449 `__) -* Contributors: Christophe Bedard, Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_version `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#503 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Small fixes for modern flake8. (`#484 `__) -* Fix add-copyright year function (`#466 `__) -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Chris Lalancette, Lloyd Pearson, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Add in checks to ament_cppcheck code. (`#472 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Pass --output argument to cpplint (`#453 `__) -* Contributors: Michael Jeronimo, Vladimir Ivan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Changes to make ament_flake8 work with v6+ (`#459 `__) -* Add additional dependencies to ament_flake8. (`#454 `__) -* Fix compatibility with flake8 version 5 (`#410 `__) -* Contributors: Chris Lalancette, Michael Carroll, Michael Jeronimo, Timo Röhling - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update quality declaration documents (`#94 `__) -* only append search paths on first PackageNotFound (`#91 `__) -* Update to C++17 (`#90 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Lucas Walter - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update quality declaration documents (`#94 `__) -* Add type annotations to python files. (`#93 `__) -* Contributors: Christophe Bedard, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Add an ament_lint test dependency on python3-pytest. (`#473 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Fix a flake8 warning in ament_mypy. (`#470 `__) No need for parentheses around an assert. -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Migrate from legacy importlib-resources (`#143 `__) -* Add setuptools dependency back in. (`#141 `__) -* Make python dependencies exec_depend. (`#140 `__) -* Contributors: Chris Lalancette, Isabel Paredes - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pep257 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Convert linenumber to string when printing errors (`#443 `__) -* Contributors: Michael Jeronimo, Robert Brothers - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Adds uncrustify 0.78.1 config (`#475 `__) -* Update maintainer list in package.xml files (`#474 `__) -* Fix a flake8 warning in ament_uncrustify. (`#471 `__) -* Contributors: Chris Lalancette, Marco A. Gutierrez, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#474 `__) -* (ament_xmllint) add extensions argument (`#456 `__) -* Contributors: Matthijs van der Burgh, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_calibration_parsers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to yaml-cpp 0.8.0. (`#305 `__) -* Switch from rcpputils::fs to std::filesystem (`#300 `__) -* Removed C headers: camera_info_manager camera_calibration_parsers (`#290 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_info_manager `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch from rcpputils::fs to std::filesystem (`#300 `__) -* Removed C headers: camera_info_manager camera_calibration_parsers (`#290 `__) -* Contributors: Alejandro Hernández Cordero, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`class_loader `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove all uses of ament_target_dependencies. (`#210 `__) -* Update to C++17 (`#209 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`common_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [composition] add launch action console output in the verify section (`#677 `__) (`#681 `__) (cherry picked from commit 34d29db73e78a84a174ad8699a2d646b0eeb1cdf) Co-authored-by: Mikael Arguedas -* Update maintainer list in package.xml files (`#665 `__) -* Migrate std::bind calls to lambda expressions (`#659 `__) -* Contributors: Felipe Gomes de Melo, Michael Jeronimo, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [demo_nodes_cpp] some readme and executable name fixups (`#678 `__) (`#688 `__) (cherry picked from commit aa8df8904b864d063e31fd5b953ffe561c7a9fe0) Co-authored-by: Mikael Arguedas -* Fix gcc warnings when building with optimizations. (`#672 `__) (`#673 `__) * Fix gcc warnings when building with optimizations. When building the allocator_tutorial_pmr demo with -O2, gcc is throwing an error saying that new and delete are mismatched. This is something of a misnomer, however; the real problem is that the global new override we have in that demo is actually implemented incorrectly. In particular, the documentation at https://en.cppreference.com/w/cpp/memory/new/operator_new very clearly specifies that operator new either has to return a valid pointer, or throw an exception on error. Our version wasn't throwing the exception, so change it to throw std::bad_alloc if std::malloc fails. While we are in here, also fix another small possible is where std::malloc could return nullptr on a zero-sized object, thus throwing an exception it shouldn't. * Always inline the new and delete operators. That's because gcc 13 has a bug where it can sometimes inline one or the other, and then it detects that they mismatch. For gcc and clang, just force them to always be inline in this demo. * Switch to NOINLINE instead. Both clang and MSVC don't like inlining these, so instead ensure that they are *not* inlined. This also works because the problem is when new is inlined but not delete (or vice-versa). As long as they are both not inlined, this should fix the warning. (cherry picked from commit 957ddbb9f04f55cabd8496e8d74eb35ee4d29105) Co-authored-by: Chris Lalancette -* A few uncrustify fixes for 0.78. (`#667 `__) -* Allow users to configure the executor for executables in ``demo_nodes_cpp`` (`#666 `__) -* Update maintainer list in package.xml files (`#665 `__) -* Added extra documentation and clarifications. (`#651 `__) -* Add in support for both the PMR and custom allocator tutorials. (`#655 `__) -* Replacing old-style C++ allocator with a polymorphic memory resource (PMR) (`#653 `__) -* Remove unnecessary captures in the various demos. (`#647 `__) -* Dramatically speed up the demo_nodes_cpp tests (`#641 `__) -* Switch to using RCLCPP logging macros in the lifecycle package. (`#644 `__) -* failed to call introspection_client (`#643 `__) -* Small cleanups to the demos when running through them. (`#639 `__) -* Cleanup demo_nodes_cpp CMake and dependencies (`#638 `__) -* Change the service introspection parameter off value to 'disabled' (`#634 `__) -* Add demos for using logger service (`#611 `__) -* Contributors: Ali Ashkani Nia, Barry Xu, Chen Lihui, Chris Lalancette, Michael Jeronimo, Yadu, jrutgeer, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp_native `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Change the service introspection parameter off value to 'disabled' (`#634 `__) With this we can avoid the tricky bits around YAML interpretation of 'off' as a boolean. -* Add demos for using logger service (`#611 `__) -* Contributors: Barry Xu, Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`diagnostic_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_map_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_robot_bringup `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Switch to file-content launch substitution (`#627 `__) -* Contributors: Michael Jeronimo, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_sensors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update dummy_sensors readme to echo the correct topic (`#675 `__) (`#684 `__) (cherry picked from commit eec5c12ea95dfaaa230f9f1a8e9cff9b09dde5d5) Co-authored-by: jmackay2 <1.732mackay@gmail.com> -* Update maintainer list in package.xml files (`#665 `__) -* Fix unstable LaserScan status for rviz2 (`#614 `__) -* Contributors: Chen Lihui, Michael Jeronimo, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`example_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17. (`#18 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix: Fixed compilation after API change of TimerBase::execute (`#375 `__) Co-authored-by: Janosch Machowinski -* Split lambda and subscriber def in minimal example (`#363 `__) -* Contributors: Felipe Gomes de Melo, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_wait_set `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix: Fixed compilation after API change of TimerBase::execute (`#375 `__) Co-authored-by: Janosch Machowinski -* Contributors: jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`foonathan_memory_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve mechanism to find an installation of foonathan_memory (#67) -* Added support for QNX 7.1 build (#65) - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove references to index.ros.org. (`#244 `__) -* Create new messages with all fields needed to define a velocity and transform it (`#240 `__) Co-authored-by: Dr. Denis Co-authored-by: Addisu Z. Taddese Co-authored-by: Tully Foote -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* adding IDs to geometry_msgs/Polygon, PolygonStamped (`#232 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Steve Macenski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`google_benchmark_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to 1.8.3. (`#29 `__) -* Contributors: Marco A. Gutierrez - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gz_cmake_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update vendored version to 3.5.3 -* Use an alias target for root library -* Add support for the ``::`` and ``::all`` targets, fix sourcing of dsv files -* Update vendored version to 3.5.2 -* Update vendored package version -* Patch the pkg-config directory in the gz-cmake code. (`#4 `__) * Patch the pkg-config directory in the gz-cmake code. When building on the ROS 2 buildfarm, we aren't setting some of the CMAKE_PREFIX variables. This means that using CMAKE_INSTALL_FULL_LIBDIR actually creates a path like /opt/ros/rolling/... , which makes debuild upset. However, we actually need the FULL_LIBDIR in order to calculate the relative path between it and the INSTALL_PREFIX. Work around this by having two variables; the pkgconfig_install_dir (relative), used to install the files, and pkgconfig_abs_install_dir (absolute), used to calculate the relative path between them. This should fix the build on the buildfarm. I'll note that we are doing it here and not in gz-cmake proper because of knock-on effects to downstream gazebo. If this is successful we may end up merging it there, at which point we can drop this patch. * Update GzPackage as well. --------- -* Require calling find_package on the underlying package (`#3 `__) This also changes the version of the vendor package to 0.0.1 and adds the version of the vendored package in the description -* Fix linter (`#2 `__) -* Use ```` on upstream package so that dependency is exported -* Update maintainer -* Add package.xml and CMakeLists (`#1 `__) -* Initial import -* Contributors: Addisu Z. Taddese, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gz_math_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use an alias target for root library -* Add support for the ``::`` and ``::all`` targets, fix sourcing of dsv files -* Disable SWIG to fix CMake warning -* Disable pybind11 for now -* Require calling find_package on the underlying package (`#2 `__) -* Fix linter (`#1 `__) -* Remove Nate -* Update maintainers -* Initial import -* Contributors: Addisu Z. Taddese - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gz_utils_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use an alias target for root library -* Add support for the ``::`` and ``::all`` targets, fix sourcing of dsv files -* Require calling find_package on the underlying package (`#2 `__) -* Fix linter (`#1 `__) -* Initial import -* Contributors: Addisu Z. Taddese - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* A few uncrustify fixes for 0.78. (`#667 `__) -* Update maintainer list in package.xml files (`#665 `__) -* Migrate std::bind calls to lambda expressions (`#659 `__) -* Contributors: Chris Lalancette, Felipe Gomes de Melo, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added rclcpp component to Republish (`#275 `__) -* Add QoS option reliability to republisher qos params (`#296 `__) -* implement CameraSubscriber::getNumPublishers (`#297 `__) -* Add missing definition for CameraPublisher::publish overload (`#278 `__) -* Advertize and subscribe with custom qos (`#288 `__) -* Removed C headers (`#289 `__) -* Switch to using the override keyword for simple_publisher_plugin. (`#285 `__) -* feat: enable plugin allowlist (`#264 `__) -* Expose option to set callback groups (`#274 `__) -* add support for lazy subscribers (`#272 `__) -* Contributors: Aditya Pande, Alejandro Hernández Cordero, Carlos Andrés Álvarez Restrepo, Chris Lalancette, Daisuke Nishimatsu, Michael Ferguson, s-hall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`interactive_markers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Shorten the length of a lambda. (`#106 `__) -* Fixed C++20 warning that ‘++’ expression of ‘volatile’-qualified type is deprecated (`#102 `__) -* Cleanup of interactive markers (`#101 `__) -* Contributors: AiVerisimilitude, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`intra_process_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Migrate std::bind calls to lambda expressions (`#659 `__) -* Fix executable name in README (`#618 `__) -* Contributors: Felipe Gomes de Melo, Michael Jeronimo, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`kdl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17. (`#82 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`keyboard_handler `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Shorten lambdas so newer uncrustify is happier. (`#42 `__) -* Fixed C++20 warning implicit capture of this in lambda (`#41 `__) -* Update to C++17. (`#37 `__) -* Contributors: AiVerisimilitude, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`laser_geometry `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries. (`#92 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* (launch) fix describe of PathJoinSubstitution (`#771 `__) -* Small fixes for modern flake8. (`#772 `__) -* Cleanup some type annotations. -* Rework task exceptions loop. (`#755 `__) -* add format overriding by environment variables (`#722 `__) -* Add exception type to error output (`#753 `__) -* Let XML executables/nodes be "required" (like in ROS 1) (`#751 `__) -* Add conditional substitution (`#734 `__) -* Add maximum times for a process to respawn (`#696 `__) -* Add in a timeout for launch pytests. (`#725 `__) -* Fix remaining occurrences of "There is no current event loop" (`#723 `__) -* Update the launch code for newer flake8 and mypy. (`#719 `__) -* Remove the deprecated some_actions_type.py (`#718 `__) -* Improve launch file parsing error messages (`#626 `__) -* Add file-content launch substitution (`#708 `__) -* Contributors: Chris Lalancette, David Yackzan, Marc Bestmann, Matthew Elwin, Matthijs van der Burgh, Nick Lamprianidis, Santti4go, Scott K Logan, Timon Engelke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch tryfirst/trylast to hookimpl. -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix: typing. Iterable doesn't have __getitem_\_ (`#393 `__) -* Cleanup some type annotations. (`#392 `__) -* Create py.typed to mark this library as typed (`#379 `__) -* Remove create_future implementation. (`#372 `__) -* cache lookup of importlib metadata in Node action (`#365 `__) -* Get rid of unnecessary checks in composable_node_container. (`#364 `__) -* Contributors: Chris Lalancette, Jonas Otto, Matthijs van der Burgh, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix a warning in modern unittest. (`#773 `__) Newer versions of unittest no longer store an errors list; instead, they store a result, which then stores an error list. Update the code here to be able to deal with either version. -* Add consider_namespace_packages=False (`#766 `__) -* to open expected outpout file with an encoding parameter (`#717 `__) -* Contributors: Chen Lihui, Chris Lalancette, Tony Najjar - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_examples `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup the launch_testing_examples. (`#374 `__) -* Refactor WaitForNodes class. (`#373 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make launch_testing_ros examples more robust. (`#394 `__) -* added type hinting to launch_testing_ros/test/examples (`#386 `__) -* Handle spin() ExternalShutdownException. (`#378 `__) -* Increase the timeout in wait_for_topic_launch_test. (`#377 `__) -* ``WaitForTopics``: get content of messages for each topic (`#353 `__) -* Contributors: Chris Lalancette, Giorgio Pintaudi, Yaswanth - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_xml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* launch_xml: fix xml syntax in README (`#770 `__) -* Let XML executables/nodes be "required" (like in ROS 1) (`#751 `__) * Let XML nodes be "required" Essentially on_exit="shutdown" is equivalent to ROS 1 required="true". This feature is implemented using the python launchfile on_exit mechanism. Right now "shutdown" is the only action accepted by on_exit, but theoretically more "on_exit" actions could be added later. Example: * Added tests for yaml -* Improve launch file parsing error messages (`#626 `__) -* Contributors: Matthew Elwin, Steve Peters, Timon Engelke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_yaml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix flake8 warnings in launch_yaml. (`#756 `__) -* Let XML executables/nodes be "required" (like in ROS 1) (`#751 `__) * Let XML nodes be "required" Essentially on_exit="shutdown" is equivalent to ROS 1 required="true". This feature is implemented using the python launchfile on_exit mechanism. Right now "shutdown" is the only action accepted by on_exit, but theoretically more "on_exit" actions could be added later. Example: * Added tests for yaml -* Improve launch file parsing error messages (`#626 `__) -* Contributors: Chris Lalancette, Matthew Elwin, Timon Engelke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libcurl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add "lib" to the Windows curl search path. (`#96 `__) (`#97 `__) In CMake 3.3, a commit made it so that the find_package module in CMake had a compatibility mode where it would automatically search for packages in a /lib subdirectory. In CMake 3.6, this compatibility mode was reverted for all platforms *except* Windows. That means that since CMake 3.3, we haven't actually been using the path as specified in ``curl_DIR``, but we have instead been inadvertently relying on that fallback behavior. In CMake 3.28, that compatibilty mode was also removed for Windows, meaning that we are now failing to find_package(curl) in downstream packages (like resource_retriever). Fix this by adding in the "lib" directory that always should have been there. I'll note that this *only* affects our Windows builds, because this code is in a if(WIN32) block. (cherry picked from commit 1839d583190eb9dcf339eaaf6bebe632d94664a6) Co-authored-by: Chris Lalancette -* Switch to ament_cmake_vendor_package (`#86 `__) -* Contributors: Scott K Logan, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`liblz4_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to build_export_depend liblz4-dev. (`#1614 `__) -* Switch to using ament_vendor_package for lz4. (`#1583 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libstatistics_collector `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump pascalgn/automerge-action from 0.16.2 to 0.16.3 -* Bump codecov/codecov-action from 4.1.1 to 4.2.0 -* Fixes for newer uncrustify. (`#186 `__) -* Bump actions/upload-artifact from 3 to 4 -* Switch to using target_link_libraries everywhere. (`#174 `__) -* Bump rolling to 1.6.3 (`#173 `__) -* Bump actions/checkout from 3 to 4 (`#169 `__) -* Add API to use message_info instead unserialized message (`#170 `__) -* Bump codecov/codecov-action from 3.1.3 to 3.1.4 -* Bump actions/checkout from 3 to 4 (`#169 `__) -* Add API to use message_info instead unserialized message (`#170 `__) -* Bump codecov/codecov-action from 3.1.3 to 3.1.4 -* Add in missing cstdint include. (`#165 `__) -* Bump codecov/codecov-action from 3.1.2 to 3.1.3 -* Contributors: Chris Lalancette, Lucas Wendland, Michael Orlov, dependabot[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libyaml_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update quality declaration documents (`#62 `__) -* remove rcpputils and rcutils dependency (`#61 `__) -* Set to C++17. (`#59 `__) -* Switch to ament_cmake_vendor_package (`#58 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Kenta Yonekura, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* A few uncrustify fixes for 0.78. (`#667 `__) -* Update maintainer list in package.xml files (`#665 `__) -* Migrate std::bind calls to lambda expressions (`#659 `__) -* Switch to using RCLCPP logging macros in the lifecycle package. (`#644 `__) -* Contributors: Chris Lalancette, Felipe Gomes de Melo, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`logging_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Migrate std::bind calls to lambda expressions (`#659 `__) -* Contributors: Felipe Gomes de Melo, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lttngpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Fixes for newer uncrustify (`#101 `__) -* Fix Python not being found for lttngpy in Windows debug mode (`#87 `__) -* Switch to custom lttng-ctl Python bindings (`#81 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`map_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files -* Update to C++17 -* Contributors: Chris Lalancette, Michael Jeronimo, Steve Macenski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mcap_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to using ament_vendor_package for lz4. (`#1583 `__) -* Switch to target_link_libraries everywhere. (`#1504 `__) -* Update mcap to v1.1.0 (`#1361 `__) -* Contributors: Chris Lalancette, Emerson Knapp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`message_filters `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update TimeSynchronizer usage example. (`#115 `__) -* Remove 'using' keyword in message_filters (`#106 `__) -* Remove the use of ament_target_dependencies. (`#105 `__) -* Fixes pointed out by clang (`#104 `__) -* Mark subscription cb parameter const (`#103 `__) -* Update the HasHeader check to be more specific. (`#101 `__) -* TypeAdapters support (`#95 `__) (`#96 `__) -* Cleanup a few minor things in the filters. (`#100 `__) -* Fix python examples (`#99 `__) -* feat: add signal time functions to ExactTime policy (`#94 `__) -* Contributors: Chris Lalancette, Patrick Roncagliolo, Ricardo de Azambuja, Russ, rkeating-planted - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mimick_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump vendored mimick version for `ros2/Mimick#32 `__ (`#35 `__) -* Update to the commit that fixes mmk_noreturn. (`#34 `__) -* Update to the commit the fixes exe stack on macOS. (`#33 `__) -* Update to the comment that fixes the executable stack. (`#32 `__) -* Update to take advantage of TARGET_ARCH (`#28 `__) -* Switch to ament_cmake_vendor_package (`#31 `__) -* Contributors: Chris Lalancette, Michael Carroll, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`nav_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed TODO (`#243 `__) -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`orocos_kdl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Ensure that orocos_kdl_vendor doesn't accidentally find itself. (`#27 `__) (`#28 `__) When initially building the orocos_kdl_vendor package (on platforms where it actually builds), it turns out that it places a valid cmake configuration in the build directory. In turn, that means that a subsequent rebuild will find this configuration in the build directory, and throw the rest of the logic off. This only seems to be a problem with CMake 3.29 and later, though I can't say exactly why at the moment. Workaround this problem by writing the configuration out to a temporary file, and then moving it into the final place with the final name. (cherry picked from commit 7aad6d1ad9fa54f3a48f1f194a85127e362c8ade) Co-authored-by: Chris Lalancette -* Update to the latest orocos_kdl_kinematics commit. (`#25 `__) -* Switch to ament_cmake_vendor_package (`#20 `__) -* Contributors: Chris Lalancette, Scott K Logan, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Catch all of the spurious warnings from get_event_loop. (`#94 `__) -* Add bookworm as a python3 target (`#91 `__) -* Suppress warning for specifically handled behavior (`#87 `__) -* Update supported platforms (`#93 `__) -* Add GitHub Actions CI workflow (`#88 `__) -* Contributors: Chris Lalancette, Scott K Logan, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_testing_tools_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Upgrade to Google test 1.14.0 (`#84 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_control `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* [pendulum_control Install targets to project lib (`#624 `__) -* Contributors: Michael Jeronimo, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pluginlib `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch from rcpputils::fs to std::filesystem (`#254 `__) -* Remove redundant throw of a std::runtime_error (`#232 `__) -* Update to C++17 (`#251 `__) -* Fix wShadow compile warning (`#250 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Hunter L. Allen, Steve Macenski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pybind11_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to pybind11 2.11.1 (`#28 `__) -* Add Apache 2.0 LICENSE file (`#27 `__) -* Switch to ament_cmake_vendor_package (`#24 `__) -* Contributors: Chris Lalancette, Michael Carroll, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use FindPython3 instead of FindPythonInterp (`#7 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_orocos_kdl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to the latest orocos_kdl_kinematics commit. (`#25 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_qt_binding `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Suppress warning from Shiboken2. (backport `#137 `__) (`#138 `__) Co-authored-by: Chris Lalancette Co-authored-by: Alejandro Hernández Cordero -* Switch to C++17 for SIP and Shiboken (`#135 `__) -* Set hints to find the python version we actually want. (`#134 `__) -* Remove unnecessary parentheses around assert. (`#133 `__) -* Switch to FindPython3 in the shiboken_helper.cmake. (`#132 `__) -* Cleanup of the sip_configure.py file. (`#131 `__) -* Update the SIP support so we can deal with a broken RHEL-9. (`#129 `__) -* Contributors: Chris Lalancette, Christophe Bedard, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_dotgraph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Handle empty dotcode nodes. (`#290 `__) -* Small fix for modern flake8. (`#289 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove unnecessary parentheses for assert. (`#286 `__) -* (qt_gui) extended theme logic to get icons (`#279 `__) -* Contributors: Chris Lalancette, Matthijs van der Burgh - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch from rcpputils::fs to std::filesystem (`#288 `__) -* Set hints to find the python version we actually want. (`#287 `__) -* Update to C++17 (`#278 `__) -* fix unload warning (`#274 `__) -* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Explicit time conversion (`#657 `__) -* Cleanup the interactive quality of service demos. (`#637 `__) -* More quality of service demo cleanup (`#632 `__) -* Fix small typos in the incompatible_qos demos. (`#629 `__) -* Contributors: AiVerisimilitude, Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* More quality of service demo cleanup (`#632 `__) -* Fix small typos in the incompatible_qos demos. (`#629 `__) -* Fix the quality_of_service_demo_py output to look like the C++ one. (`#626 `__) -* Use non-deprecated rclpy import. (`#615 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix up rmw_cyclonedds timestamp testing. (`#1156 `__) (`#1157 `__) We are about to fix it so that rmw_cyclonedds has receive_timestamp support, so we also need to enable that support here in rcl. We actually rewrite the logic a bit because now the only combination that doesn't work is rmw_connextdds on Windows. (cherry picked from commit 6d53d24a863c3e9e4a41e9fe5f550271210d9d9d) Co-authored-by: Chris Lalancette -* Fixed warnings - strict-prototypes (`#1148 `__) (`#1150 `__) -* chore: Minor style improvements (`#1147 `__) Co-authored-by: Janosch Machowinski -* improved rcl_wait in the area of timeout computation and spurious wakeups (`#1146 `__) Added special handling for timers with a clock that has time override enabled. For these timer we should not compute a timeout, as the waitset is waken up by the associated guard condition. Before this change, the waitset could wait up, because of an expected ready timer, that was acutally not ready, as the time update to the ROS_TIME had not yet arrived. -* Add tracepoint for publish_serialized_publish (`#1136 `__) * Add tracepoint for publish_serialized_publish * Add: tracepoint for rcl_take_serialized_message --------- -* Revert "improved rcl_wait in the area of timeout computation and spurious wakeups (`#1135 `__)" (`#1142 `__) This reverts commit 3c6c5dc47dac23d70722a60b2c0a387d2e71b71d. -* improved rcl_wait in the area of timeout computation and spurious wakeups (`#1135 `__) * feat: Allow usage of rcl_timer_clock with const rcl_timer_t* * fix: Fixed purious wake-ups on ROS_TIME timers with ROS_TIME enabled Added special handling for timers with a clock that has time override enabled. For theses timer we should not compute a timeout, as the waitset is waken up by the associated guard condition. Before this change, the waitset could wait up, because of an expected ready timer, that was acutally not ready, as the time update to the ROS_TIME had not yet arrived. * feat: Added rcl_timer_get_next_call_time * fix(rcl_wait): Improved timeout computation in case of many timers This commit changes the computation of the timer timeout, to be more precise, in the case, of many registered timers. --------- Co-authored-by: Janosch Machowinski -* Generate version header using ament_generate_version_header(..) (`#1141 `__) -* Add rcl_timer_call_with_info function that retrieves the expected and the actual timer trigger times (`#1113 `__) Co-authored-by: Alexis Tsogias Co-authored-by: Michael Carroll Co-authored-by: Tomoya Fujita -* document out parameters for rcl_get_node_names and rcl_get_node_names_with_enclaves (`#1137 `__) * document out params for rcl_get_node_names Co-authored-by: Chris Lalancette -* Cleanups for uncrustify 0.78. (`#1134 `__) Mostly this is expanding macros, as this is just easier to read anyway. But we also mark one section as INDENT-OFF. -* Re-order rcl_logging_interface include (`#1133 `__) -* Remove unnecessary macros. (`#1132 `__) These really don't add anything, and allows us to avoid some changes in macro formatting between Ubuntu 22.04 and Ubuntu 24.04. -* Update quality declaration documents (`#1131 `__) -* add unit tests for --log-file-name argument. (`#1130 `__) -* support ``--log-file-name`` to ros args. (`#1127 `__) -* Make sure to disable a test_node test on RHEL. (`#1124 `__) -* remove static function rcl_ret_from_rcutils_ret(). (`#1122 `__) -* Remove AMENT_DEPENDENCIES from rcl_add_custom_gtest. (`#1119 `__) -* Remove unncecessary dependencies in tests (`#1114 `__) -* a rosout publisher of a node might not exist (`#1115 `__) -* Set disable loan to on by default. (`#1110 `__) -* Return service from node_type_description_service_init (`#1112 `__) -* next_call_time will always be greater than now after calling rcl_timer_call. (`#1089 `__) -* Add rcl count clients, servicec & tests (`#1011 `__) -* Improve the reliability of test_get_type_description_service. (`#1107 `__) -* Remove most remaining uses of ament_target_dependencies. (`#1102 `__) -* Just remove rcpputils::fs dependency (`#1105 `__) -* Decouple rosout publisher init from node init. (`#1065 `__) -* Cleanup the error handling in rcl_node_init. (`#1099 `__) -* Fix a clang warning for suspicious string concatentation. (`#1101 `__) -* add the link to the topic name rules. (`#1100 `__) -* Cut down the amount of time for test_logging_rosout. (`#1098 `__) -* Simplify local_namespace handling in rcl_node_init. (`#1097 `__) -* Reduce the number of tests we run (`#1096 `__) -* Adding duplicate node information (`#1088 `__) -* Revamp the test_get_type_description_service. (`#1095 `__) -* Cleanup network flow endpoints test. (`#1094 `__) -* Reduce the failure timeout time for namespaces. (`#1093 `__) -* Shorten wait time for a subscription not being ready. (`#1092 `__) -* rcl_send_response returns RCL_RET_TIMEOUT. (`#1048 `__) -* Move test_namespace into the correct directory. (`#1087 `__) -* Reset errors in tests to reduce warnings (`#1085 `__) -* Cleanup error reporting in the type hash code. (`#1084 `__) -* Instrument loaned message publication code path (`#1083 `__) -* Add ``~/get_type_description`` service (rep2011) (`#1052 `__) -* Modifies timers API to select autostart state (`#1004 `__) -* test publisher/subscription with the c/cpp typesupport for test_msgs::msg::array (`#1074 `__) -* validation result should be used to print the error message. (`#1077 `__) -* improve error msg of ``rcl_expand_topic_name`` (`#1076 `__) -* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#1058 `__) -* fix comment (`#1073 `__) -* localhost_only prevails auto discovery options if enabled. (`#1069 `__) -* Avoid dynamic allocation of message before sending over rosout (`#1067 `__) -* clarify ``rcl_node_init`` return code (`#1066 `__) -* Fix a format-security warning when building with clang. (`#1064 `__) -* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, Eloy Briceno, Eric W, Felix Penzlin, G.A. vd. Hoorn, Hans-Joachim Krauch, Kenta Yonekura, Lee, Lucas Wendland, Michael Carroll, Minju, Thiemo Kohrt, Tomoya Fujita, h-suzuki-isp, jmachowinski, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Generate version header using ament_generate_version_header(..) (`#1141 `__) -* add RCL_RET_TIMEOUT to action service response. (`#1138 `__) * add RCL_RET_TIMEOUT to action service response. * address review comment. --------- -* Update quality declaration documents (`#1131 `__) -* Remove most remaining uses of ament_target_dependencies. (`#1102 `__) -* Add ``~/get_type_description`` service (rep2011) (`#1052 `__) -* Modifies timers API to select autostart state (`#1004 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Eloy Briceno, G.A. vd. Hoorn, Hans-Joachim Krauch, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the Log.msg constant types. (`#161 `__) -* Update the comments for SetParametersResult to reflect reality. (`#159 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed warnings - strict-prototypes (`#1148 `__) (`#1150 `__) -* Generate version header using ament_generate_version_header(..) (`#1141 `__) -* Update quality declaration documents (`#1131 `__) -* Remove most remaining uses of ament_target_dependencies. (`#1102 `__) -* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#1058 `__) -* Contributors: Chris Lalancette, Christophe Bedard, G.A. vd. Hoorn, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Check allocator validity in some rcl_logging functions (`#116 `__) If the allocator is zero-initialized, it may cause a segfault when it is used later in the functions. -* Use (void) in declaration of param-less function (`#114 `__) -* add file_name_prefix parameter to external log configuration. (`#109 `__) -* Migrate to std::filesystem (`#104 `__) -* Remove the last uses of ament_target_dependencies in this repo. (`#102 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Kenta Yonekura, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_noop `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add file_name_prefix parameter to external log configuration. (`#109 `__) -* Remove the last uses of ament_target_dependencies in this repo. (`#102 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_spdlog `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Check allocator validity in some rcl_logging functions (`#116 `__) If the allocator is zero-initialized, it may cause a segfault when it is used later in the functions. -* Cleanup the tests. (`#115 `__) * Cleanup the tests. There are a few different fixes in here: 1. Move away from using "popen" to get the list of files in a directory. Instead, switch to using the C++ std::filesystem directory iterator and doing the work ourselves, which is portable and much less error-prone. 2. Set the ROS_LOG_DIR for all of the tests in here. This should make the test resistant to being run in parallel with other tests. 3. Consistently use rcpputils::set_env_var, rather than a mix of rcpputils and rcutils. -* Update quality declaration document (`#112 `__) -* Re-order rcl_logging_interface include (`#111 `__) -* add file_name_prefix parameter to external log configuration. (`#109 `__) -* Migrate to std::filesystem (`#104 `__) -* Remove the last uses of ament_target_dependencies in this repo. (`#102 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Kenta Yonekura, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_yaml_param_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Generate version header using ament_generate_version_header(..) (`#1141 `__) -* Update quality declaration documents (`#1131 `__) -* Fix for incorrect integer value conversion on Windows (`#1126 `__) -* Just remove rcpputils::fs dependency (`#1105 `__) -* Contributors: Christophe Bedard, G.A. vd. Hoorn, Kenta Yonekura, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add impl pointer for ExecutorOptions (`#2523 `__) (`#2525 `__) * add impl pointer for ExecutorOptions (cherry picked from commit 343b29b617b163ad72b9fe3f6441dd4ed3d3af09) Co-authored-by: William Woodall -* Fixup Executor::spin_all() regression fix (`#2517 `__) (`#2521 `__) * test(Executors): Added tests for busy waiting Checks if executors are busy waiting while they should block in spin_some or spin_all. * fix: Reworked spinAll test This test was strange. It looked like, it assumed that spin_all did not return instantly. Also it was racy, as the thread could terminate instantly. * fix(Executor): Fixed spin_all not returning instantly is no work was available * Update rclcpp/test/rclcpp/executors/test_executors.cpp * test(executors): Added test for busy waiting while calling spin * fix(executor): Reset wait_result on every call to spin_some_impl Before, the method would not recollect available work in case of spin_some, spin_all. This would lead to the method behaving differently than to what the documentation states. * restore previous test logic for now * refactor spin_some_impl's logic and improve busy wait tests * added some more comments about the implementation --------- Co-authored-by: Janosch Machowinski Co-authored-by: jmachowinski Co-authored-by: Tomoya Fujita Co-authored-by: William Woodall -* Revise the description of service configure_introspection() (`#2511 `__) (`#2513 `__) -* Remove references to index.ros.org. (`#2504 `__) -* Reduce overhead for inheriting from rclcpp::Executor when base functionality is not reused (`#2506 `__) -* [wjwwood] Updated "Data race fixes" (`#2500 `__) * Fix callback group logic in executor * fix: Fixed unnecessary copy of wait_set * fix(executor): Fixed race conditions with rebuild of wait_sets Before this change, the rebuild of wait set would be triggered after the wait set was waken up. With bad timing, this could lead to the rebuild not happening with multi threaded executor. * fix(Executor): Fixed lost of entities rebuild request * chore: Added assert for not set callback_group in execute_any_executable * Add test for cbg getting reset Co-authored-by: Janosch Machowinski * chore: renamed test cases to snake_case * style * fixup test to avoid polling and short timeouts * fix: Use correct notify_waitable\_ instance * fix(StaticSingleThreadedExecutor): Added missing special case handling for current_notify_waitable\_ * fix(TestCallbackGroup): Fixed test after change to timers --------- Co-authored-by: Janosch Machowinski Co-authored-by: Michael Carroll Co-authored-by: Janosch Machowinski -* fixup var names to snake case (`#2501 `__) -* Added optional TimerInfo to timer callback (`#2343 `__) Co-authored-by: Alexis Tsogias Co-authored-by: Janosch Machowinski -* Fix uninitialized memory in test (`#2498 `__) When I added in the tests for large messages, I made a mistake and reserved space in the strings, but didn't actually expand it. Thus, we were writing into uninitialized memory. Fix this by just using the correct constructor for string, which will allocate and initialize the memory properly. -* Ensure waitables handle guard condition retriggering (`#2483 `__) Co-authored-by: Michael Carroll -* fix: init concatenated_vector with begin() & end() (`#2492 `__) * this commit will fix the warning [-Wstringop-overflow=] `#2461 `__ -* Use the same context for the specified node in rclcpp::spin functions (`#2433 `__) * Use the same conext for the specified node in rclcpp::spin_xx functions * Add test for spinning with non-default-context * Format code --------- -* Disable compare-function-pointers in test_utilities (`#2489 `__) -* address ambiguous auto variable. (`#2481 `__) -* Increase the cppcheck timeout to 1200 seconds (`#2484 `__) -* Removed test_timers_manager clang warning (`#2479 `__) -* Flaky timer test fix (`#2469 `__) * fix(time_source): Fixed possible race condition * fix(test_executors_time_cancel_behaviour): Fixed multiple race conditions --------- Co-authored-by: Janosch Machowinski -* Add tracepoint for generic publisher/subscriber (`#2448 `__) -* update rclcpp::Waitable API to use references and const (`#2467 `__) -* Utilize rclcpp::WaitSet as part of the executors (`#2142 `__) * Deprecate callback_group call taking context * Add base executor objects that can be used by implementors * Template common operations * Address reviewer feedback: * Add callback to EntitiesCollector constructor * Make function to check automatically added callback groups take a list * Lint * Address reviewer feedback and fix templates * Lint and docs * Make executor own the notify waitable * Add pending queue to collector, remove from waitable Also change node's get_guard_condition to return shared_ptr * Change interrupt guard condition to shared_ptr Check if guard condition is valid before adding it to the waitable * Lint and docs * Utilize rclcpp::WaitSet as part of the executors * Don't exchange atomic twice * Fix add_node and add more tests * Make get_notify_guard_condition follow API tick-tock * Improve callback group tick-tocking * Don't lock twice * Address reviewer feedback * Add thread safety annotations and make locks consistent * @wip * Reset callback groups for multithreaded executor * Avoid many small function calls when building executables * Re-trigger guard condition if buffer has data * Address reviewer feedback * Trace points * Remove tracepoints * Reducing diff * Reduce diff * Uncrustify * Restore tests * Back to weak_ptr and reduce test time * reduce diff and lint * Restore static single threaded tests that weren't working before * Restore more tests * Fix multithreaded test * Fix assert * Fix constructor test * Change ready_executables signature back * Don't enforce removing callback groups before nodes * Remove the "add_valid_node" API * Only notify if the trigger condition is valid * Only trigger if valid and needed * Fix spin_some/spin_all implementation * Restore single threaded executor * Picking ABI-incompatible executor changes * Add PIMPL * Additional waitset prune * Fix bad merge * Expand test timeout * Introduce method to clear expired entities from a collection * Make sure to call remove_expired_entities(). * Prune queued work when callback group is removed * Prune subscriptions from dynamic storage * Styles fixes. * Re-trigger guard conditions * Condense to just use watiable.take_data * Lint * Address reviewer comments (nits) * Lock mutex when copying * Refactors to static single threaded based on reviewers * More small refactoring * Lint * Lint * Add ready executable accessors to WaitResult * Make use of accessors from wait_set * Fix tests * Fix more tests * Tidy up single threaded executor implementation * Don't null out timer, rely on call * change how timers are checked from wait result in executors * peak -> peek * fix bug in next_waitable logic * fix bug in StaticSTE that broke the add callback groups to executor tests * style --------- Co-authored-by: Chris Lalancette Co-authored-by: William Woodall -* fix flakiness in TestTimersManager unit-test (`#2468 `__) the previous version of the test was relying on the assumption that a timer with 1ms period gets called at least 6 times if the main thread waits 15ms. this is true most of the times, but it's not guaranteed, especially when running the test on windows CI servers. the new version of the test makes no assumptions on how much time it takes for the timers manager to invoke the timers, but rather focuses on ensuring that they are called the right amount of times, which is what's important for the purpose of the test -* fix spin_some_max_duration unit-test for events-executor (`#2465 `__) -* refactor and improve the parameterized spin_some tests for executors (`#2460 `__) * refactor and improve the spin_some parameterized tests for executors * disable spin_some_max_duration for the StaticSingleThreadedExecutor and EventsExecutor * fixup and clarify the docstring for Executor::spin_some() * style * review comments --------- -* enable simulation clock for timer canceling test. (`#2458 `__) * enable simulation clock for timer canceling test. * move MainExecutorTypes to test_executors_timer_cancel_behavior.cpp. --------- -* Revert "relax the test simulation rate for timer canceling tests. (`#2453 `__)" (`#2456 `__) This reverts commit 1c350d0d7fb9c7158e0a39057112486ddbd38e9a. -* relax the test simulation rate for timer canceling tests. (`#2453 `__) -* Fix TypeAdapted publishing with large messages. (`#2443 `__) Mostly by ensuring we aren't attempting to store large messages on the stack. Also add in tests. I verified that before these changes, the tests failed, while after them they succeed. -* Implement generic client (`#2358 `__) * Implement generic client * Fix the incorrect parameter declaration * Deleted copy constructor and assignment for FutureAndRequestId * Update codes after rebase * Address review comments * Address review comments from iuhilnehc-ynos * Correct an error in a description * Fix window build errors * Address review comments from William * Add doc strings to create_generic_client --------- -* Rule of five: implement move operators (`#2425 `__) -* Various cleanups to deal with uncrustify 0.78. (`#2439 `__) These should also work with uncrustify 0.72. -* Remove the set_deprecated signatures in any_subscription_callback. (`#2431 `__) These have been deprecated since April 2021, so it is safe to remove them now. -* fix doxygen syntax for NodeInterfaces (`#2428 `__) -* Set hints to find the python version we actually want. (`#2426 `__) The comment in the commit explains the reasoning behind it. -* Update quality declaration documents (`#2427 `__) -* feat: add/minus for msg::Time and rclcpp::Duration (`#2419 `__) * feat: add/minus for msg::Time and rclcpp::Duration -* Split test_executors up into smaller chunks. (`#2421 `__) -* [events executor] - Fix Behavior with Timer Cancel (`#2375 `__) -* Removed deprecated header (`#2413 `__) -* Make sure to mark RingBuffer methods as 'override'. (`#2410 `__) -* Increase the cppcheck timeout to 600 seconds. (`#2409 `__) -* Add transient local durability support to publisher and subscriptions when using intra-process communication (`#2303 `__) -* Stop storing the context in the guard condition. (`#2400 `__) -* Updated GenericSubscription to AnySubscriptionCallback (`#1928 `__) -* make type support helper supported for service (`#2209 `__) -* Adding QoS to subscription options (`#2323 `__) -* Switch to target_link_libraries. (`#2374 `__) -* aligh with rcl that a rosout publisher of a node might not exist (`#2357 `__) -* Fix data race in EventHandlerBase (`#2349 `__) -* Support users holding onto shared pointers in the message memory pool (`#2336 `__) -* fix (signal_handler.hpp): spelling (`#2356 `__) -* Updates to not use std::move in some places. (`#2353 `__) -* rclcpp::Time::max() clock type support. (`#2352 `__) -* Serialized Messages with Topic Statistics (`#2274 `__) -* Add a custom deleter when constructing rcl_service_t (`#2351 `__) -* Disable the loaned messages inside the executor. (`#2335 `__) -* Use message_info in SubscriptionTopicStatistics instead of typed message (`#2337 `__) -* Add missing 'enable_rosout' comments (`#2345 `__) -* Adjust rclcpp usage of type description service (`#2344 `__) -* address rate related flaky tests. (`#2329 `__) -* Fixes pointed out by the clang analyzer. (`#2339 `__) -* Remove useless ROSRate class (`#2326 `__) -* add clients & services count (`#2072 `__) -* remove invalid sized allocation test for SerializedMessage. (`#2330 `__) -* Adding API to copy all parameters from one node to another (`#2304 `__) -* Add locking to protect the TimeSource::NodeState::node_base\_ (`#2320 `__) -* Update SignalHandler get_global_signal_handler to avoid complex types in static memory (`#2316 `__) -* Removing Old Connext Tests (`#2313 `__) -* Documentation for list_parameters (`#2315 `__) -* Decouple rosout publisher init from node init. (`#2174 `__) -* fix the depth to relative in list_parameters (`#2300 `__) -* Fix the return type of Rate::period. (`#2301 `__) -* Update API docs links in package READMEs (`#2302 `__) -* Cleanup flaky timers_manager tests. (`#2299 `__) -* Topic correct typeadapter deduction (`#2294 `__) -* Fix C++20 allocator construct deprecation (`#2292 `__) -* Make Rate to select the clock to work with (`#2123 `__) -* Correct the position of a comment. (`#2290 `__) -* Remove unnecessary lambda captures in the tests. (`#2289 `__) -* Add rcl_logging_interface as an explicit dependency. (`#2284 `__) -* Revamp list_parameters to be more efficient and easier to read. (`#2282 `__) -* Do not crash Executor when send_response fails due to client failure. (`#2276 `__) -* Adding Custom Unknown Type Error (`#2272 `__) -* Add a pimpl inside rclcpp::Node for future distro backports (`#2228 `__) -* Remove an unused variable from the events executor tests. (`#2270 `__) -* Add spin_all shortcut (`#2246 `__) -* Adding Missing Group Exceptions (`#2256 `__) -* Change associated clocks storage to unordered_set (`#2257 `__) -* associated clocks should be protected by mutex. (`#2255 `__) -* Instrument loaned message publication code path (`#2240 `__) -* Implement get_node_type_descriptions_interface for lifecyclenode and add smoke test for it (`#2237 `__) -* Add new node interface TypeDescriptionsInterface to provide GetTypeDescription service (`#2224 `__) -* Move always_false_v to detail namespace (`#2232 `__) -* Revamp the test_subscription.cpp tests. (`#2227 `__) -* warning: comparison of integer expressions of different signedness (`#2219 `__) -* Modifies timers API to select autostart state (`#2005 `__) -* Enable callback group tests for connextdds (`#2182 `__) -* Fix up misspellings of "receive". (`#2208 `__) -* Remove flaky stressAddRemoveNode test (`#2206 `__) -* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#2162 `__) -* remove nolint since ament_cpplint updated for the c++17 header (`#2198 `__) -* Feature/available capacity of ipm (`#2173 `__) -* add mutex to protect events_executor current entity collection (`#2187 `__) -* Declare rclcpp callbacks before the rcl entities (`#2024 `__) -* Fix race condition in events-executor (`#2177 `__) -* Add missing stdexcept include (`#2186 `__) -* Fix a format-security warning when building with clang (`#2171 `__) -* Fix delivered message kind (`#2175 `__) -* Contributors: AiVerisimilitude, Alberto Soragna, Alejandro Hernández Cordero, Alexey Merzlyakov, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, DensoADAS, Eloy Briceno, Emerson Knapp, Homalozoa X, HuaTsai, Jeffery Hsu, Jiaqi Li, Jonas Otto, Kotaro Yoshimoto, Lee, Luca Della Vedova, Lucas Wendland, Matt Condino, Michael Carroll, Michael Orlov, Minju, Nathan Wiebe Neufeldt, Steve Macenski, Tim Clephas, Tomoya Fujita, Tony Najjar, Tully Foote, William Woodall, Zard-C, h-suzuki-isp, jmachowinski, mauropasse, mergify[bot], methylDragon, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove references to index.ros.org. (`#2504 `__) -* Callback after cancel (`#2281 `__) * feat(Client): Added function to stop callbacks of a goal handle This function allows us to drop the handle in a locked context. If we do not do this within a lock, there will be a race condition between the deletion of the shared_ptr of the handle and the result / feedback callbacks. * fix: make Client goal handle recursive This fixes deadlocks due to release of goal handles in callbacks etc. * fix(ActionGoalClient): Fixed memory leak for nominal case This fixes a memory leak due to a self reference in the ClientGoalHandle. Note, this fix will only work, if the ClientGoalHandle ever receives a result callback. * doc: Updated documentation of rclcpp_action::Client::async_send_goal * docs: Made the async_send_goal documentation more explicit Co-authored-by: Janosch Machowinski -* Remake of "fix: Fixed race condition in action server between is_ready and take" (`#2495 `__) Some background information: is_ready, take_data and execute data may be called from different threads in any order. The code in the old state expected them to be called in series, without interruption. This lead to multiple race conditions, as the state of the pimpl objects was altered by the three functions in a non thread safe way. Co-authored-by: Janosch Machowinski -* update rclcpp::Waitable API to use references and const (`#2467 `__) -* Do not generate the exception when action service response timeout. (`#2464 `__) * Do not generate the exception when action service response timeout. * address review comment. --------- -* Modify rclcpp_action::GoalUUID hashing algorithm (`#2441 `__) * Add unit tests for hashing rclcpp_action::GoalUUID's * Use the FNV-1a hash algorithm for Goal UUID -* Various cleanups to deal with uncrustify 0.78. (`#2439 `__) These should also work with uncrustify 0.72. -* Update quality declaration documents (`#2427 `__) -* Switch to target_link_libraries. (`#2374 `__) -* Update API docs links in package READMEs (`#2302 `__) -* fix(ClientGoalHandle): Made mutex recursive to prevent deadlocks (`#2267 `__) -* Correct the position of a comment. (`#2290 `__) -* Fix a typo in a comment. (`#2283 `__) -* doc fix: call ``canceled`` only after goal state is in canceling. (`#2266 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Jiaqi Li, Tomoya Fujita, William Woodall, jmachowinski, mauropasse - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_components `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove references to index.ros.org. (`#2504 `__) -* Add EXECUTOR docs (`#2440 `__) -* Update quality declaration documents (`#2427 `__) -* crash on no class found (`#2415 `__) * crash on no class found * error on no class found instead of no callback groups Co-authored-by: Chris Lalancette -* Switch to target_link_libraries. (`#2374 `__) -* feat(rclcpp_components): support events executor in node main template (`#2366 `__) -* fix(rclcpp_components): increase the service queue sizes in component_container (`#2363 `__) -* Add missing header required by the rclcpp::NodeOptions type (`#2324 `__) -* Update API docs links in package READMEs (`#2302 `__) -* Contributors: Adam Aposhian, Chris Lalancette, Christophe Bedard, Daisuke Nishimatsu, Ignacio Vizzo, M. Fatih Cırıt, Ruddick Lawrence - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "call shutdown in LifecycleNode dtor to avoid leaving the device in un… (`#2450 `__)" (`#2522 `__) (`#2524 `__) This reverts commit 04ea0bb00293387791522590b7347a2282cda290. (cherry picked from commit 42b0b5775b4e68718c5949308c9e1a059930ded7) Co-authored-by: Chris Lalancette -* Remove references to index.ros.org. (`#2504 `__) -* call shutdown in LifecycleNode dtor to avoid leaving the device in un… (`#2450 `__) * call shutdown in LifecycleNode dtor to avoid leaving the device in unknown state. * add test to verify LifecycleNode::shutdown is called on destructor. --------- -* Update quality declaration documents (`#2427 `__) -* Increase timeout for rclcpp_lifecycle to 360 (`#2395 `__) -* Fix rclcpp_lifecycle inclusion on Windows. (`#2331 `__) -* add clients & services count (`#2072 `__) -* Update API docs links in package READMEs (`#2302 `__) -* add logger level service to lifecycle node. (`#2277 `__) -* Stop using constref signature of benchmark DoNotOptimize. (`#2238 `__) -* Implement get_node_type_descriptions_interface for lifecyclenode and add smoke test for it (`#2237 `__) -* Switch lifecycle to use the RCLCPP macros. (`#2233 `__) -* Add new node interface TypeDescriptionsInterface to provide GetTypeDescription service (`#2224 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Emerson Knapp, Jorge Perez, Lee, Minju, Tomoya Fujita, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clock.py types. (`#1244 `__) * Start typing time.py * Testing out Enum wrapper for ClockType * convert to rcl_clock_type_t * Update create_time_point * add types to logging_service * Add types to duration.py * Add newlines for class definintions * update type alias name * Update to use Protocols * Add types to time.py * Add types * Fix import order * Started typing clock.py * Move typealias import -* pybind11 definition doc typo fixes. (`#1270 `__) -* Fix small flake8 error in rclpy. (`#1267 `__) Newer versions of flake8 complain that using 'str' as a variable shadows a builtin. Just make it 's'. -* Allow specifying qos (`#1225 `__) -* update RCL_RET_TIMEOUT error handling with action service response. (`#1258 `__) -* Add types to time_source.py (`#1259 `__) -* Small fixes for modern flake8. (`#1264 `__) -* Add types to qos_overriding_options.py (`#1248 `__) -* Add types to context.py (`#1240 `__) -* Add back Type hash __slots_\_ and add test cases. (`#1245 `__) -* Revert "Add types to TypeHash and moved away from __slots_\_ usage (`#1232 `__)" (`#1243 `__) -* Time.py Types (`#1237 `__) -* Add types to TypeHash and moved away from __slots_\_ usage (`#1232 `__) -* Add Static Typing to Validate files (`#1230 `__) -* Add types to duration.py (`#1233 `__) -* added python3-yaml (`#1242 `__) -* Add types to exceptions.py (`#1241 `__) -* Add types (`#1231 `__) -* Creates Enum wrapper for ClockType and ClockChange (`#1235 `__) -* Add types to expand_topic_name (`#1238 `__) -* Add types to logging_service.py (`#1227 `__) -* Add types to logging.py (`#1226 `__) -* forbid parameter to be declared statically without initialization. (`#1216 `__) -* Remove parentheses from assert statements. (`#1213 `__) -* Add doc-string warnings for destroy methods for services. (`#1205 `__) -* Add doc-string warnings for destroy() methods (`#1204 `__) -* Add an optional timeout_sec input to Client.call() to fix issue https://github.com/ros2/rclpy/issues/1181 (`#1188 `__) -* aligh with rcl that a rosout publisher of a node might not exist (`#1196 `__) -* call ok() to see if rclpy and context is initialized. (`#1198 `__) -* Adjust python usage of the type_description service API (`#1192 `__) -* Document that spin_once() should not be called from multiple threads (`#1079 `__) -* making optional things Optional (`#1182 `__) -* Use timeout object to avoid callback losing in wait_for_ready_callbacks (`#1165 `__) -* Fix to issue https://github.com/ros2/rclpy/issues/1179 (`#1180 `__) -* Add count services, clients & test (`#1024 `__) -* 1105 parameter event handler (`#1135 `__) -* unregister_sigterm_signal_handler should be called. (`#1170 `__) -* Handle take failure in wait_for_message (`#1172 `__) -* Decouple rosout publisher init from node init. (`#1121 `__) -* Fix _list_parameters_callback & test (`#1161 `__) -* add list_parameters & test (`#1124 `__) -* Support to get remapped service name (`#1156 `__) -* a couple of typo fixes. (`#1158 `__) -* Fix get_type_description service bug and add a unit test (`#1155 `__) -* Fix an inherent race in execution vs. destruction. (`#1150 `__) -* Cleanup of test_node.py. (`#1153 `__) -* Avoid generating the exception when rcl_send_response times out. (`#1136 `__) -* Store time source clocks in a set (`#1146 `__) -* Fix spin_once_until_future_complete to quit when the future finishes. (`#1143 `__) -* get_type_description service (`#1139 `__) -* Add in the ability to start timers paused. (`#1138 `__) -* Modifies ros_timer_init for ros_timer_init2 (`#999 `__) -* Fix/param namespace association 894 (`#1132 `__) -* Include type hash in topic endpoint info (`#1104 `__) -* Fix iteration over modified list (`#1129 `__) -* making optional things Optional (`#974 `__) -* Fix type signature of Client.wait_for_service (`#1128 `__) -* Fix action server crash when the client goes away. (`#1114 `__) -* Turn Executor into a ContextManager (`#1118 `__) -* Turn Context into a ContextManager (`#1117 `__) -* Fix type in Node init args (`#1115 `__) -* Contributors: AndyZe, Anton Kesy, Barry Xu, Brian, Chen Lihui, Chris Lalancette, Eloy Briceno, Emerson Knapp, EsipovPA, Felix Divo, Hans-Joachim Krauch, KKSTB, Lee, Luca Della Vedova, M. Hofstätter, Michael Carlstrom, Michael Carroll, Minju, Russ, SnIcK, Steve Peters, Tim Clephas, Tomoya Fujita, mhidalgo-bdai - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcpputils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Generate version header with ament_generate_version_header function (`#190 `__) -* Update docs for rcpputils::split functions (`#188 `__) -* Included tl_expected (`#185 `__) -* Switch to using target_link_libraries. (`#183 `__) -* Add a missing header due to missing PATH_MAX variable (`#181 `__) -* Add unique_lock implementation with clang thread safety annotations (`#180 `__) -* Add in a missing cstdint. (`#178 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Emerson Knapp, Sai Kishor Kothakota, wojciechmadry - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed warnings - strict-prototypes (`#461 `__) (`#465 `__) -* Increase timeout repl_str test (`#463 `__) (`#464 `__) -* validate the allocator before use. (`#455 `__) * validate the allocator before use. * address review comments. - validate allocator only if the function specifically uses. - argument null check comes before validation of value. --------- -* feat: Add human readable date to logging formats (`#441 `__) -* Updates for uncrustify 0.78. (`#454 `__) -* Set hints to find the python version we actually want. (`#451 `__) -* Bring ament_add_gtest/target_link_libraries back together (`#452 `__) -* Change 'ROS2' to 'ROS 2' in quality declaration (`#453 `__) -* Allow parsing of escape sequence in log format (`#443 `__) -* Clean up unused references to mimick/mocking in tests (`#450 `__) -* Fix if(TARGET ...) condition for test (`#447 `__) -* Zero-initialize rcutils_string_array_t in test_string_array (`#446 `__) -* Use rcutils_string_array_init in rcutils_split & handle alloc fail (`#445 `__) -* Make rcutils_split() return RCUTILS_RET_BAD_ALLOC if alloc fails (`#444 `__) -* Remove two last uses of ament_target_dependencies. (`#440 `__) -* time_win32: Update dead link (`#438 `__) -* memmove for overlaping memory (`#434 `__) -* make escape characters work (`#426 `__) -* Remove unused 'max' functions from sha256.c (`#429 `__) -* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Kaju-Bubanja, Marc Bestmann, Silvio Traversaro, Tomoya Fujita, Tyler Weaver, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`resource_retriever `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update resource retreiver to use rule of five (`#95 `__) -* Use default ament_lint_auto (`#92 `__) -* Switch to target_link_libraries. (`#89 `__) -* Update to C++17 (`#88 `__) -* Contributors: Chris Lalancette, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed warnings - strict-prototypes (`#365 `__) (`#366 `__) -* Switch to target_link_libraries. (`#361 `__) -* Remove unnecessary c++14 flag. (`#360 `__) -* definition of local means being in the same context. (`#359 `__) -* typo fix. (`#355 `__) -* Contributors: Chris Lalancette, Tomoya Fujita, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add rmw count clients services impl (`#93 `__) -* Cleanup context implementation (`#131 `__) -* Update to C++17 (`#125 `__) -* Contributors: Chris Lalancette, Lee, Minju - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Mitigate discovery race condition between clients and services (`#132 `__)" (`#146 `__) This reverts commit 7c95abbfc4559b293ebf5e94e20250bdd99d3ac6. -* Mitigate discovery race condition between clients and services (`#132 `__) * Mitigate discovery race condition between clients and services. -* Add: tracepoint for subscribe serialized_message (`#145 `__) * Add: tracepoint for take_serialized_message * Fix: TRACETOOLS_TRACEPOINT args * Update rmw_connextdds_common/src/common/rmw_subscription.cpp Co-authored-by: Christophe Bedard -* Support Fast CDR v2 (`#141 `__) -* Fix the rmw_connextdds_common build with gcc 13.2. (`#142 `__) The most important fix here is to #include , but also make sure we #include for all used STL functions. -* Fix basic request reply mapping for ConnextDDS Pro (`#139 `__) -* Add ros2_tracing tracepoints (`#120 `__) -* avoid using dds common public mutex directly (`#134 `__) -* Fix a couple of warnings pointed out by clang. (`#133 `__) -* Add rmw count clients services impl (`#93 `__) -* Conditional internal API access to support Connext 7+ (`#121 `__) -* Cleanup context implementation (`#131 `__) -* Fix RMW_Connext_Client::is_service_available for micro (`#130 `__) -* Update to C++17 (`#125 `__) -* Pass parameters in the correct order to DDS_DataReader_read in rmw_connextdds_count_unread_samples for micro (`#129 `__) -* Optimize QoS to improve responsiveness of reliable endpoints (`#26 `__) -* Clear out errors once we have handled them. (`#126 `__) -* Add support for listener callbacks (`#76 `__) -* Contributors: Andrea Sorbini, Chen Lihui, Chris Lalancette, Christopher Wecht, Lee, Miguel Company, Minju, h-suzuki-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextddsmicro `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add rmw count clients services impl (`#93 `__) -* Cleanup context implementation (`#131 `__) -* Update to C++17 (`#125 `__) -* Contributors: Chris Lalancette, Lee, Minju - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_cyclonedds_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set received_timestamp to system_clock::now() in message_info (`#491 `__) (`#493 `__) * Set received_timestamp to steady_clock::now() in message_info * Use 'system_clock' instead of 'steady_clock' * Also update receive_timestamp for services. (cherry picked from commit 76c9d8f38a03d160b258902af6d1d06f6ed9391e) Co-authored-by: Michael Orlov -* Add tracepoint for publish/subscribe serialized message (`#485 `__) Co-authored-by: eboasson -* Remove a bunch of unnecessary macros. (`#482 `__) -* compare string contents but string pointer addresses. (`#481 `__) -* Add timestamp to rmw_publish tracepoint (`#454 `__) -* avoid using dds common public mutex directly (`#474 `__) -* Add rmw count clients,services impl (`#427 `__) -* Minor revamp of the CMakeLists.txt. (`#468 `__) -* Clear out errors once we have handled them. (`#464 `__) -* Instrument loaned message publication code path -* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#450 `__) -* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, Lee, Minju, Tomoya Fujita, h-suzuki-isp, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_dds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add pkcs11 support to get_security_files (`#66 `__) -* make a new private mutex and add updating graph methods (`#73 `__) -* Just remove rcpputils::fs dependency (`#72 `__) -* Contributors: Chen Lihui, Kenta Yonekura, Miguel Company - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support Fast CDR v2 (`#746 `__) * Require fastcdr version 2 * Changes to build rmw_fastrtps_shared_cpp * Changes to build rmw_fastrtps_cpp * Changes to build rmw_fastrtps_dynamic_cpp -* Capture ``std::bad_alloc`` on deserializeROSmessage. (`#665 `__) -* Switch to target_link_libraries for linking. (`#734 `__) -* avoid using dds common public mutex directly (`#725 `__) -* Add rmw_count clients,services impl (`#641 `__) -* Improve node graph delivery by using a unique listening port (`#711 `__) -* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#686 `__) -* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Lee, Miguel Company, Minju - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_dynamic_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support Fast CDR v2 (`#746 `__) * Require fastcdr version 2 * Changes to build rmw_fastrtps_shared_cpp * Changes to build rmw_fastrtps_cpp * Changes to build rmw_fastrtps_dynamic_cpp -* compare string contents but string pointer addresses. (`#744 `__) -* Improve wide string (de)serialization in rwm_dynamic_fastrtps_cpp (`#740 `__) * Move type support headers to src * Fix references to moved headers * move macros.hpp to src/serialization_helpers.hpp * Move other non-api headers * Move common code into serialize_wide_string. * Move common code into deserialize_wide_string. * Move serialization into serialization_helpers.hpp * Move deserialization into serialization_helpers.hpp * Fix header guards * Linters * Do not account for extra character on serialized size calculation * Remove dependency on rosidl_typesupport_fastrtps_c(pp) --------- -* Capture ``std::bad_alloc`` on deserializeROSmessage. (`#665 `__) -* Switch to target_link_libraries for linking. (`#734 `__) -* avoid using dds common public mutex directly (`#725 `__) -* Account for alignment on is_plain calculations. (`#716 `__) -* Add rmw_count clients,services impl (`#641 `__) -* Improve node graph delivery by using a unique listening port (`#711 `__) -* Contributors: Chen Lihui, Chris Lalancette, Lee, Miguel Company, Minju, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_shared_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow pkcs11 when calling rmw_dds_common::get_security_files. (`#565 `__) Co-authored-by: Miguel Company -* Add tracepoint for publish/subscribe serialized_message (`#748 `__) * Add: tracepoint for generic pub/sub * Fix: correspond to PR 454 * Fix: change write to write_to_timestamp --------- -* Support Fast CDR v2 (`#746 `__) * Require fastcdr version 2 * Changes to build rmw_fastrtps_shared_cpp * Changes to build rmw_fastrtps_cpp * Changes to build rmw_fastrtps_dynamic_cpp -* Remove an unnecessary constructor. (`#743 `__) We can just use brace initialization here, and this allows us to side-step an uncrustify issue with the constructor. -* Add timestamp to rmw_publish tracepoint (`#694 `__) -* Switch to Unix line endings. (`#736 `__) -* Switch to target_link_libraries for linking. (`#734 `__) -* Quiet compiler warning in Release mode. (`#730 `__) -* avoid using dds common public mutex directly (`#725 `__) -* Add rmw_count clients,services impl (`#641 `__) -* Switch to using rclcpp::unique_lock. (`#712 `__) -* Use DataWriter Qos to configure max_blocking_time on rmw_send_response (`#704 `__) -* Clear out errors once we have handled them. (`#701 `__) -* Instrument loaned message publication code path (`#698 `__) -* Add in a missing data_reader check when creating subscription. (`#697 `__) -* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#686 `__) -* typo fix. (`#693 `__) -* address clang nightly build error. (`#689 `__) -* Check for errors while doing an rmw_discovery_options_copy. (`#690 `__) -* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, IkerLuengo, Lee, Miguel Company, Minju, Tomoya Fujita, h-suzuki-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update quality declaration document (`#225 `__) (`#226 `__) -* Switch to using target_link_libraries everywhere. (`#222 `__) -* Add rmw_count_clients,services & test (`#208 `__) -* Contributors: Chris Lalancette, Lee, Minju, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`robot_state_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix reload after a description with a mimic joint (`#212 `__) -* Remove ament_target_dependencies. (`#209 `__) -* Improve log messages (`#206 `__) -* Contributors: Chris Lalancette, Guillaume Doisy, Nick Lamprianidis - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* call get_action_interfaces() properly. (`#898 `__) (`#900 `__) (cherry picked from commit 305ef763b83e42ebddc4802ac788869d178b6e93) Co-authored-by: Tomoya Fujita -* support ``ros2 action type ``. (`#894 `__) * support ``ros2 action type ``. * add review comments. --------- -* Load a message/request/goal from standard input (`#844 `__) -* Contributors: Tomoya Fujita, mergify[bot], ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add option to disable recorder keyboard controls (`#1607 `__) -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Added exclude-topic-types to record (`#1582 `__) -* Overhaul in the rosbag2_transport::TopicFilter class and relevant tests (`#1585 `__) -* Filter topic by type (`#1577 `__) -* Implement service recording and display info about recorded services (`#1480 `__) -* Add python3-yaml as a dependency (`#1490 `__) -* Fix the description of paramter '--topics' for play (`#1426 `__) -* When using sim time, wait for /clock before beginning recording (`#1378 `__) -* Revert "Don't record sim-time messages before first /clock (`#1354 `__)" (`#1377 `__) -* Don't record sim-time messages before first /clock (`#1354 `__) -* Fix wrong descritpion for '--ignore-leaf-topics' (`#1344 `__) -* Cleanup the help text for ros2 bag record. (`#1329 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Bernd Pfrommer, Chris Lalancette, Emerson Knapp, Michael Orlov, Michal Sojka - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ros2cli.node.daemon : try getting fdsize from /proc for open fd limit (`#888 `__) -* Fix the SIGTERM handling in the ros2 daemon. (`#887 `__) -* Replace unmaintained ``netifaces`` library to avoid local wheel builds (`#875 `__) -* make handles not inheritable to prevent from blocking durning tab-completion (`#852 `__) -* Add ros2 service info (`#771 `__) -* catch ExternalShutdownException ros2cli main. (`#854 `__) -* Load a message/request/goal from standard input (`#844 `__) -* Fix tests with get_type_description service and param present (`#838 `__) -* Add marshalling functions for rclpy.type_hash.TypeHash (rep2011) (`#816 `__) -* [service introspection] ros2 service echo (`#745 `__) -* Contributors: Brian, Chen Lihui, Chris Lalancette, Emerson Knapp, Hans-Joachim Krauch, Laurenz, Lee, Minju, Tomoya Fujita, akssri-sony, ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli_test_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17 (`#848 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2component `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Warning: get_parameter_value() is deprecated. (`#866 `__) -* Contributors: Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2doctor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove references to https://index.ros.org (`#897 `__) -* (ros2doctor) fix PackageCheck (`#860 `__) * (ros2doctor)(package) improve result string generation -* Shutdown ros2doctor hello when ctrl-c is received (`#826 `__) -* Contributors: Chris Lalancette, Matthijs van der Burgh, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2interface `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add interface type filters to ros2 interface package (`#765 `__) -* Contributors: David V. Lu!! - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2param `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ros2 param dump should handle empty list as exception. (`#881 `__) -* Warning: get_parameter_value() is deprecated. (`#866 `__) -* Fix tests with get_type_description service and param present (`#838 `__) -* Update ros2 param dump dosctring. (`#837 `__) -* Contributors: Emerson Knapp, Murilo M Marinho, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2pkg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update the package template for our new include directories. (`#847 `__) -* Fix typo in ros2pkg warning message. (`#827 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ros2 service info (`#771 `__) -* Load a message/request/goal from standard input (`#844 `__) -* Fix tests with get_type_description service and param present (`#838 `__) -* [service introspection] ros2 service echo (`#745 `__) -* Contributors: Brian, Emerson Knapp, Lee, Minju, ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove parentheses from assert statement. (`#878 `__) -* Load a message/request/goal from standard input (`#844 `__) -* Add marshalling functions for rclpy.type_hash.TypeHash (rep2011) (`#816 `__) -* [service introspection] ros2 service echo (`#745 `__) -* Contributors: Brian, Chris Lalancette, Hans-Joachim Krauch, ymd-stella - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Create start/pause/resume/stop sub-commands for 'ros2 trace' (`#70 `__) -* Switch to in pure Python packages (`#67 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Use std::filesystem instead of rcpputils::fs (`#1576 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Add default initialization for CompressionOptions (`#1539 `__) -* Add option to set compression threads priority (`#1457 `__) -* Fixes pointed out by clang. (`#1493 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* Add in a missing cstdint include. (`#1321 `__) -* Fix warning from ClassLoader in sequential compression reader and writer (`#1299 `__) -* Contributors: Arne B, Chris Lalancette, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression_zstd `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use std::filesystem instead of rcpputils::fs (`#1576 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Contributors: Chris Lalancette, Roman Sokolkov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Update to use yaml-cpp version 0.8.0. (`#1605 `__) -* Use std::filesystem instead of rcpputils::fs (`#1576 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* call cv.wait_until only if necessary. (`#1521 `__) -* Implement service recording and display info about recorded services (`#1480 `__) -* Switch to target_link_libraries everywhere. (`#1504 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* ros2 bag convert now excludes messages not in [start_time;end_time] (`#1455 `__) -* Replace TSAUniqueLock implementation with rcpputils::unique_lock (`#1454 `__) -* Add BagSplitInfo service call on bag close (`#1422 `__) -* Rewrite TimeControllerClockTest.unpaused_sleep_returns_true to be correct (`#1384 `__) -* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) -* Don't crash when type definition cannot be found (`#1350 `__) -* Add recorder stop() API (`#1300 `__) -* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Peter Favrholdt, Roman Sokolkov, Tomoya Fujita, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_examples_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* Contributors: Michael Orlov, Patrick Roncagliolo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_examples_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Fix a warning from python setuptools. (`#1312 `__) -* Contributors: Chris Lalancette, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add node name to the Read(Write)SplitEvent message (`#1609 `__) -* Contributors: Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_performance_benchmarking `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Update to use yaml-cpp version 0.8.0. (`#1605 `__) -* Add option to set compression threads priority (`#1457 `__) -* Add per group statistics for rosbag2_performance_benchmarking report (`#1306 `__) -* Set CPU affinity for producers and recorder from benchmark parameters (`#1305 `__) -* Add CPU usage to rosbag2_performance_benchmarking results report (`#1304 `__) -* Add config option to use storage_id parameter in benchmark_launch.py (`#1303 `__) -* Contributors: Chris Lalancette, Michael Orlov, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add option to disable recorder keyboard controls (`#1607 `__) -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Switch rclpy to be an exec_depend here. (`#1606 `__) -* Gracefully handle SIGINT and SIGTERM signals for play and burst CLI (`#1557 `__) -* Added exclude-topic-types to record (`#1582 `__) -* Fix for false negative tests in rosbag2_py (`#1592 `__) -* Update rosbag2_py stubs (`#1593 `__) -* Add Python stubs for rosbag2_py (`#1459 `__) (`#1569 `__) -* Filter topic by type (`#1577 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Install signal handlers in recorder only inside record method (`#1464 `__) -* add missing import otherwise it doesnt compile (`#1524 `__) -* Implement service recording and display info about recorded services (`#1480 `__) -* Make ``rosbag2_transport::Player::play()`` run in a separate thread (`#1503 `__) -* Switch to target_link_libraries everywhere. (`#1504 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* ros2 bag convert now excludes messages not in [start_time;end_time] (`#1455 `__) -* Add support for compression to python API (`#1425 `__) -* Gracefully handle SIGINT and SIGTERM in rosbag2 recorder (`#1301 `__) -* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) -* Add binding to close the writer (`#1339 `__) -* Contributors: Alejandro Hernández Cordero, Andrew Symington, Barry Xu, Bernd Pfrommer, Chris Lalancette, Emerson Knapp, Michael Orlov, Mikael Arguedas, Patrick Roncagliolo, Peter Favrholdt, Roman Sokolkov, Yadu, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Update to use yaml-cpp version 0.8.0. (`#1605 `__) -* Use std::filesystem instead of rcpputils::fs (`#1576 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Remove rcpputils::fs dependencies from rosbag2_storages (`#1558 `__) -* Improve performance in SqliteStorage::get_bagfile_size() (`#1516 `__) -* Make Player and Recorder Composable (`#902 `__) (`#1419 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* ros2 bag convert now excludes messages not in [start_time;end_time] (`#1455 `__) -* Fix missing cstdint include (`#1383 `__) -* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) -* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Peter Favrholdt, Roman Sokolkov, Zac Stanton, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_mcap `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Update to use yaml-cpp version 0.8.0. (`#1605 `__) -* Check existence of a file before passing it to the mcap reader (`#1594 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Use rw_lock to protect mcap metadata lists. (`#1561 `__) -* Remove rcpputils::fs dependencies from rosbag2_storages (`#1558 `__) -* remove unused headers (`#1544 `__) -* Link and compile against rosbag2_storage_mcap: Fixed issue 1492 (`#1496 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* Store serialized metadata in MCAP file (`#1423 `__) -* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christopher Wecht, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, Tomoya Fujita, jmachowinski, uupks - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_sqlite3 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Update to use yaml-cpp version 0.8.0. (`#1605 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Remove rcpputils::fs dependencies from rosbag2_storages (`#1558 `__) -* Change an incorrect TSA annotation. (`#1552 `__) -* Improve performance in SqliteStorage::get_bagfile_size() (`#1516 `__) -* Update rosbag2_storage_sqlite3 to C++17. (`#1501 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* Stop inheriting from std::iterator. (`#1424 `__) -* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) -* Store metadata in db3 file (`#1294 `__) -* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Implement service recording and display info about recorded services (`#1480 `__) -* Add extra checks in execute_and_wait_until_completion(..) (`#1346 `__) -* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) -* Contributors: Barry Xu, Chris Lalancette, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_msgdefs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Implement service recording and display info about recorded services (`#1480 `__) -* Don't crash when type definition cannot be found (`#1350 `__) * Don't fail when type definition cannot be found -* Contributors: Barry Xu, Emerson Knapp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Added exclude-topic-types to record (`#1582 `__) -* Use std::filesystem instead of rcpputils::fs (`#1576 `__) -* Filter topic by type (`#1577 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Improve performance in SqliteStorage::get_bagfile_size() (`#1516 `__) -* Implement service recording and display info about recorded services (`#1480 `__) -* Mark play_end_to_end test as xfail in Windows (`#1452 `__) -* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) -* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Cristóbal Arroyo, Emerson Knapp, Michael Orlov, Roman Sokolkov, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed warnings - unqualified-std-cast-call (`#1618 `__) (`#1622 `__) -* Add node name to the Read(Write)SplitEvent message (`#1609 `__) -* Add option to disable recorder keyboard controls (`#1607 `__) -* Support service 2/2 --- rosbag2 service play (`#1481 `__) -* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) -* Update to use yaml-cpp version 0.8.0. (`#1605 `__) -* Gracefully handle SIGINT and SIGTERM signals for play and burst CLI (`#1557 `__) -* Added exclude-topic-types to record (`#1582 `__) -* Use std::filesystem instead of rcpputils::fs (`#1576 `__) -* Add transactional state mutex for RecorderImpl class. (`#1547 `__) -* Overhaul in the rosbag2_transport::TopicFilter class and relevant tests (`#1585 `__) -* Filter topic by type (`#1577 `__) -* fix: use size_t instead of uint64_t in play_options YAML converter (`#1575 `__) -* Make some changes for newer versions of uncrustify. (`#1578 `__) -* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) -* Workaround for flaky test_play_services running with fastrtps (`#1556 `__) -* Add proper message for --start-paused (`#1537 `__) -* ``Recording stopped`` prints only once. (`#1530 `__) -* Cleanup the rosbag2_transport tests (`#1518 `__) -* Implement service recording and display info about recorded services (`#1480 `__) -* Add option to set compression threads priority (`#1457 `__) -* Bugfix for incorrect playback rate changes when pressing buttons (`#1513 `__) -* Make Player and Recorder Composable (`#902 `__) (`#1419 `__) -* Clang fixes for the latest PlayerImpl code. (`#1507 `__) -* Make ``rosbag2_transport::Player::play()`` run in a separate thread (`#1503 `__) -* Switch to target_link_libraries everywhere. (`#1504 `__) -* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) -* Redesign Player class with PIMPL idiom (`#1447 `__) -* Don't warn for unknown types if topics are not selected (`#1466 `__) -* Remove unused concurrentqueue implementation. (`#1465 `__) -* Fix uninitialized value pointed out by clang static analysis. (`#1440 `__) -* Fix the build with rmw_fastrtps_dynamic. (`#1416 `__) -* Fix for rosbag2_transport::Recorder failures due to the unhandled exceptions (`#1382 `__) -* When using sim time, wait for /clock before beginning recording (`#1378 `__) -* Fix for possible freeze in Recorder::stop() (`#1381 `__) -* Revert "Don't record sim-time messages before first /clock (`#1354 `__)" (`#1377 `__) -* Don't record sim-time messages before first /clock (`#1354 `__) -* Fix a clang warning about uninitialized variable. (`#1370 `__) -* [bugfix] for parameters not passing to recorder's node from child component (`#1360 `__) -* Change subscriptions from GenericSubscripton to SubscriptionBase (`#1337 `__) -* Add recorder stop() API (`#1300 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Bernd Pfrommer, Chris Lalancette, Christoph Fröhlich, Daisuke Nishimatsu, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, Tomoya Fujita, jmachowinski, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve deprecation notice of rosidl_target_interface to give a hint on how to update the code (`#788 `__) -* Add rosidl_find_package_idl helper function (`#754 `__) -* Remove unused splitting of .srv files in CMake (`#753 `__) -* Contributors: Alexis Paques, Mike Purvis, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_dynamic_typesupport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* uchar: fix conditional include/typedef (`#10 `__) -* uchar: use __has_include(..) on separate line (`#8 `__) -* Refactor the handling of nested types. (`#7 `__) -* Add C++ version check to char16 definition (`#3 `__) -* Contributors: Antonio Cuadros, Chris Lalancette, G.A. vd. Hoorn - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed warnings - strict-prototypes (`#800 `__) (`#802 `__) -* Set hints to find the python version we actually want. (`#785 `__) -* Add rosidl_find_package_idl helper function (`#754 `__) -* Fix IWYU for clangd in C and C++ (`#742 `__) -* Contributors: Alexis Paques, Chris Lalancette, Mike Purvis, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set hints to find the python version we actually want. (`#785 `__) -* Fix constant generation for C++ floats (`#772 `__) -* Add rosidl_find_package_idl helper function (`#754 `__) -* Fixed visibility control file added to wrong header list variable. (`#755 `__) -* Fix deprecation warnings for message constants (`#750 `__) -* Generate typesupport declarations for actions, messages and services (`#703 `__) -* Fix IWYU for clangd in C and C++ (`#742 `__) -* Contributors: Alexis Paques, Chris Lalancette, Emerson Knapp, Mike Purvis, Stefan Fabian - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_dds_idl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove unnecessary parentheses. (`#61 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert install of .so files into python path (`#211 `__) There seems that some regression might have happened after `#195 `__. When removing those 2 lines, we avoid to install the .so files in lib *and* python path. -* Prototype code for seeing if FindPython3 is usable for rosidl_python (`#140 `__) -* Add in a missing space. (`#203 `__) -* Install compiled libraries only to 'lib' (`#195 `__) -* Fix: Missing dependency that causes cmake error in downstream (resolves https://github.com/ros2/rosidl_python/issues/198) (`#199 `__) -* Contributors: Chris Lalancette, Isaac Saito, Matthias Schoepfer, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed warnings - strict-prototypes (`#800 `__) (`#802 `__) -* Increased the cpplint timeout to 300 seconds (`#797 `__) -* Fixes for modern uncrustify. (`#793 `__) -* Fix constant generation for C++ floats (`#772 `__) -* Fix same named types overriding typesources (`#759 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Emerson Knapp, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_type_description `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set hints to find the python version we actually want. (`#785 `__) -* Remove unnecessary parentheses. (`#783 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Adding interfaces to support ``@key`` annotation (`#796 `__) Co-authored-by: Mario Dominguez -* Small fix for newer flake8 compatibility. (`#792 `__) -* Remove unnecessary parentheses. (`#783 `__) -* Contributors: Chris Lalancette, Miguel Company - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove unnecessary parentheses. (`#783 `__) -* Fix same named types overriding typesources (`#759 `__) -* Contributors: Chris Lalancette, Emerson Knapp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries. (`#776 `__) -* Set the C++ version to 17. (`#761 `__) -* Mark _ in benchmark tests as unused. (`#741 `__) This helps clang static analysis. -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Suppress a warning around BoundedVector. (`#803 `__) (`#804 `__) The comment has more explanation, but in short GCC 13 has false positives around some warnings, so we suppress it for BoundedVector. (cherry picked from commit 858e76adb03edba00469b91d50dd5fe0dcb34236) Co-authored-by: Chris Lalancette -* Contributors: mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Some fixes for modern flake8. (`#25 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed warnings - strict-prototypes (`#155 `__) (`#156 `__) -* compare string contents but string pointer addresses. (`#153 `__) -* Set hints to find the python version we actually want. (`#150 `__) -* Don't override user provided compile definitions (`#145 `__) -* Contributors: Chris Lalancette, Emerson Knapp, Tomoya Fujita, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* compare string contents but string pointer addresses. (`#153 `__) -* Set hints to find the python version we actually want. (`#150 `__) -* Don't override user provided compile definitions (`#145 `__) -* Added C interfaces to obtain service and action type support. (`#143 `__) -* Contributors: Chris Lalancette, Emerson Knapp, Stefan Fabian, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Adding interfaces to support ``@key`` annotation (`#116 `__) Co-authored-by: Mario Dominguez -* Support Fast CDR v2 (`#114 `__) -* Improve wide string (de)serialization (`#113 `__) -* Set hints to find the python version we actually want. (`#112 `__) Co-authored-by: Michael Carroll -* Update to C++17 (`#111 `__) -* Account for alignment on ``is_plain`` calculations (`#108 `__) -* Contributors: Chris Lalancette, Miguel Company - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix how header template works to prevent double-inclusion (`#117 `__) Co-authored-by: Alejandro Hernández Cordero -* Adding interfaces to support ``@key`` annotation (`#116 `__) Co-authored-by: Mario Dominguez -* Support Fast CDR v2 (`#114 `__) -* Improve wide string (de)serialization (`#113 `__) -* Set hints to find the python version we actually want. (`#112 `__) Co-authored-by: Michael Carroll -* Update to C++17 (`#111 `__) -* Account for alignment on ``is_plain`` calculations (`#108 `__) -* Avoid redundant declarations in generated code for services and actions (`#102 `__) -* Contributors: Chris Lalancette, Emerson Knapp, Michael Carroll, Miguel Company - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed warnings - strict-prototypes (`#800 `__) (`#802 `__) -* Adding interfaces to support ``@key`` annotation (`#796 `__) Co-authored-by: Mario Dominguez -* Set hints to find the python version we actually want. (`#785 `__) -* Add rosidl_find_package_idl helper function (`#754 `__) -* update comment (`#757 `__) -* Contributors: Chen Lihui, Chris Lalancette, Miguel Company, Mike Purvis, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Adding interfaces to support ``@key`` annotation (`#796 `__) Co-authored-by: Mario Dominguez -* Set hints to find the python version we actually want. (`#785 `__) -* Switch to target_link_libraries. (`#776 `__) -* Add rosidl_find_package_idl helper function (`#754 `__) -* update comment (`#757 `__) -* Fix deprecation warnings for message constants (`#750 `__) -* Contributors: Chen Lihui, Chris Lalancette, Emerson Knapp, Miguel Company, Mike Purvis - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* One last uncrustify fix for newer uncrustify. (`#795 `__) -* Disable zero-variadic-macro-arguments warning when using clang. (`#768 `__) -* Fixed C++20 warning implicit capture of this in lambda (`#766 `__) -* Contributors: AiVerisimilitude, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Suppress uncrustify on long lines. (`#152 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rpyutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* correct the URL and f-strings format (`#11 `__) -* Contributors: Chen Lihui - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add a test dependency on pytest. (`#306 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in copyright tests to rqt_bag. (`#154 `__) -* Add a test dependency on pytest. (`#153 `__) -* Revert "Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (#… (`#151 `__) -* Update maintainer to myself. (`#150 `__) -* Update maintainer list in package.xml files (`#149 `__) -* Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (`#148 `__) -* [ros2] Enable Save (`#142 `__) -* Call close (`#141 `__) -* Use default storage id (`#139 `__) -* Contributors: Chris Lalancette, Michael Jeronimo, Yadu, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add a test dependency on pytest. (`#153 `__) -* Revert "Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (#… (`#151 `__) -* Update maintainer to myself. (`#150 `__) -* Update maintainer list in package.xml files (`#149 `__) -* Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (`#148 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add a test dependency on pytest. (`#45 `__) -* Contributors: Arne Hitzmann, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_graph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#92 `__) -* Add a test dependency on python3-pytest. (`#91 `__) -* Refresh rosgraph when params checkbox is clicked (`#86 `__) -* Contributors: Chris Lalancette, Michael Jeronimo, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries. (`#297 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix an exception raised while press ctrl+c to exit (`#291 `__) -* Contributors: Chen Lihui - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_msg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in python3-pytest test dependency. (`#19 `__) -* Small cleanups to rqt_msg (`#16 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_plot `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in copyright tests to rqt_bag. (`#95 `__) -* Add a test dependency on pytest. (`#94 `__) -* Add in a pytest dependency for running tests. (`#92 `__) -* Fix regression from #87 (`#90 `__) -* Contributors: Chris Lalancette, Yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use raw strings for regular expressions. (`#44 `__) -* Switch maintainer to me. (`#43 `__) -* Update maintainer list in package.xml files (`#42 `__) -* Add in a test dependency on pytest. (`#41 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow to autocomplete namespaced topics (`#299 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in test dependency on pytest. (`#16 `__) -* Fix a crash in the rqt_py_console dialog box. (`#15 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_reconfigure `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly add a pytest test dependency. (`#141 `__) -* Remove unnecessary parentheses around if statements. (`#140 `__) -* Fixed executor conflict (`#126 `__) -* Add param filtering (`#128 `__) -* Fix handling of namespaces in the node tree (`#132 `__) -* Contributors: Aleksander Szymański, Chris Lalancette, Devarsi Rawal, Nick Lamprianidis - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_service_caller `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in a pytest test dependency. (`#28 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_shell `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change maintainer to clalancette. (`#21 `__) -* Add in pytest test dependency. (`#19 `__) -* Contributors: Chris Lalancette, Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_srv `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add explicit dependency to python3-pytest. (`#12 `__) -* Minor cleanups in rqt_srv for ROS 2 (`#9 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Small fix for modern flake8. (`#50 `__) -* Add explicit python3-pytest dependency. (`#48 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rti_connext_dds_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use unified approach for checking the existence of environment variables (`#105 `__) -* Contributors: Christopher Wecht - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rttest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17 (`#124 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add "R" key as shortcut for resetTime (`#1088 `__) -* Switch to target_link_libraries. (`#1098 `__) -* Contributors: Chris Lalancette, Paul Erik Frivold - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_assimp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed assimp warnings (`#1191 `__) (`#1192 `__) (cherry picked from commit e8dd485d19a35d3abba905020741973e613334e3) Co-authored-by: Alejandro Hernández Cordero -* Update the vendored package path. (`#1184 `__) Since we just updated to assimp 5.3, we also need to update the path we look for it. This should fix the build with clang which is currently failing. -* Update assimp vendor to 5.3.1 (`#1182 `__) This matches what is in Ubuntu 24.04. -* Update to assimp 5.2.2 (`#968 `__) -* Fix the vendoring flags for clang compilation. (`#1003 `__) -* Switch to ament_cmake_vendor_package (`#995 `__) -* Contributors: Chris Lalancette, Scott K Logan, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to yaml-cpp 0.8.0 (`#1183 `__) yaml-cpp 0.8.0 has a proper CMake target, i.e. yaml-cpp::yaml-cpp. Use that here. -* Remove regex_filter_property.hpp from the moc lines. (`#1172 `__) Since it has no SLOTS or SIGNALS, we don't need to run MOC on it. That will both speed up the compilation and remove a warning when building. -* Added regex filter field for TF display (`#1032 `__) -* Fix camera display overlay (`#1151 `__) -* Fixes for uncrustify 0.78. (`#1155 `__) Mostly what we do here is to disable the indentation on certain constructs that are different between 0.72 and 0.78. It isn't my preferred solution, but since it only affects a small amount of code (and most of that in macros), this seems acceptable to me. -* Append measured subscription frequency to topic status (`#1113 `__) -* Implement reset time service (`#1109 `__) -* Add "R" key as shortcut for resetTime (`#1088 `__) -* Add fullscreen startup option (`#1097 `__) -* Switch to target_link_libraries. (`#1098 `__) -* Initialize more of the visualization_manager members. (`#1090 `__) -* Explicit time conversions and comparisons (`#1087 `__) -* Rolling namespace in title (`#1074 `__) -* Removed unused code (`#1044 `__) -* Remove unused LineEditWithButton::simulateReturnPressed() (`#1040 `__) -* Remove warning in depth_cloud_mld.cpp (`#1021 `__) -* Added DepthCloud default plugin (`#996 `__) -* Stop inheriting from std::iterator. (`#1013 `__) In C++17, inheriting from std::iterator has been deprecated: https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated/ Here, switch away from inheriting and just define the interface ourselves (which is the current recommended best practice). This removes some warnings when building with gcc 13.1.1 -* use static QCoreApplication::processEvents() function without a QApplication instance (`#924 `__) -* Re-implemented setName for tools (`#989 `__) -* Add a libqt5-svg dependency to rviz_common. (`#992 `__) -* Remove onHelpWiki. (`#985 `__) -* Clean Code (`#975 `__) -* Contributors: AiVerisimilitude, Alejandro Hernández Cordero, Chris Lalancette, Felix Exner (fexner), Hyunseok, Markus Bader, Paul Erik Frivold, Yadu, Yannis Gerlach, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Make sure to export all rviz_default_plugins dependencies. (`#1181 `__) -* Increase the cpplint timeout to 180 seconds. (`#1179 `__) -* Switch to gz_math_vendor. (`#1177 `__) -* Fixed camera info warning (`#1175 `__) -* Added CameraInfo display (`#1166 `__) -* apply origin rotation to inertia box visualization (`#1171 `__) -* Added regex filter field for TF display (`#1032 `__) -* Added point_cloud_transport (`#1008 `__) -* Select QoS reliability policy in DepthCloud Plugin (`#1159 `__) -* Fixed crash on DepthCloud plugin (`#1161 `__) -* Fixes for uncrustify 0.78. (`#1155 `__) Mostly what we do here is to disable the indentation on certain constructs that are different between 0.72 and 0.78. It isn't my preferred solution, but since it only affects a small amount of code (and most of that in macros), this seems acceptable to me. -* Fixed crash on DepthCloudPlugin (`#1133 `__) -* Wrench accepth nan values fix (`#1141 `__) -* DepthCloud plugin: Append measured subscription frequency to topic status (`#1137 `__) -* Added Cache to camera display for TimeExact (`#1138 `__) -* Fixed transport name in DepthCloud plugin (`#1134 `__) -* Fix time-syncing message (`#1121 `__) -* Switch from ROS_TIME to SYSTEM_TIME on rclcpp::Time construction (`#1117 `__) -* Append measured subscription frequency to topic status (`#1113 `__) -* Fix typo (`#1104 `__) -* Fix potencial leak / seg fault (`#726 `__) -* Fixed screw display (`#1093 `__) -* Explicit time conversions and comparisons (`#1087 `__) -* Handle missing effort limit in URDF (`#1084 `__) -* (robot) fix styling of log msg (`#1080 `__) -* Fix image display wrapping (`#1038 `__) -* removed enableInteraction reference (`#1075 `__) -* Fix ODR violations in interactive_marker displays. (`#1068 `__) -* Improve error handling in LaserScanDisplay (`#1035 `__) -* Fix implicit capture of "this" warning in C++20 (`#1053 `__) -* Removed unused code (`#1044 `__) -* Fixed AccelStamped, TwistStamped and Wrench icons (`#1041 `__) -* Fix the flakey rviz_rendering tests (`#1026 `__) -* Don't pass screw_display.hpp to the moc generator. (`#1018 `__) Since it isn't a Qt class, you get a warning from moc: Note: No relevant classes found. No output generated. Just skip adding it to the moc list here, which gets rid of the warning. -* Added DepthCloud default plugin (`#996 `__) -* Added TwistStamped and AccelStamped default plugins (`#991 `__) -* Added Effort plugin (`#990 `__) -* Improve the compilation time of rviz_default_plugins (`#1007 `__) -* Switch to ament_cmake_vendor_package (`#995 `__) -* Modify access specifier to protected or public for the scope of processMessage() member function (`#984 `__) -* Contributors: AiVerisimilitude, Alejandro Hernández Cordero, Austin Moore, Chris Lalancette, Christoph Fröhlich, Hyunseok, Jonas Otto, Lewe Christiansen, Matthijs van der Burgh, Patrick Roncagliolo, Scott K Logan, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_ogre_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update zlib into CMakeLists.txt (`#1128 `__) (`#1195 `__) Changes in 1.3 (18 Aug 2023) - Remove K&R function definitions and zlib2ansi - Fix bug in deflateBound() for level 0 and memLevel 9 - Fix bug when gzungetc() is used immediately after gzopen() - Fix bug when using gzflush() with a very small buffer - Fix crash when gzsetparams() attempted for transparent write - Fix test/example.c to work with FORCE_STORED - Rewrite of zran in examples (see zran.c version history) - Fix minizip to allow it to open an empty zip file - Fix reading disk number start on zip64 files in minizip - Fix logic error in minizip argument processing - Add minizip testing to Makefile - Read multiple bytes instead of byte-by-byte in minizip unzip.c - Add memory sanitizer to configure (--memory) - Various portability improvements - Various documentation improvements - Various spelling and typo corrections Co-authored-by: Chris Lalancette (cherry picked from commit 32eb8b9404927883247e868ab0c7d62b80df2ed1) Co-authored-by: mosfet80 -* Change an rviz_ogre_vendor dependency to libfreetype-dev. (`#1167 `__) The situation is complicated, but in versions of Ubuntu prior to Focal and versions of Debian prior to Bookworm, the name of the library was 'libfreetype6-dev'. Since Focal and Bookworm, the name of the library is 'libfreetype-dev'. While 'libfreetype-dev' provides a "virtual package" for 'libfreetype6-dev', we should really use the new canonical name. Further, there is currently a bug on ros_buildfarm where it doesn't properly deal with "virtual packages" like this. This is currently preventing this package from building on Ubuntu Noble. That bug is being worked on separately. Finally, I'll note that we already have a libfreetype-dev key in rosdep, so we just switch to using that here which should work around the bug on the buildfarm, and also use the correct canonical name going forward. -* fix: modify typo in cmake args for mac (`#1160 `__) -* feat: support macos (`#1156 `__) -* Suppress a couple more of clang warnings in rviz_ogre_vendor. (`#1102 `__) -* Fix the vendoring flags for clang compilation. (`#1003 `__) Several of the flags are not available on clang, so don't add them there. This fixes the clang build for me locally. -* Switch to ament_cmake_vendor_package (`#995 `__) -* CMake: rename FeatureSummary.cmake to avoid name clashes (`#953 `__) -* FIX CVE in external libraries (`#961 `__) -* Contributors: Chris Lalancette, Daisuke Nishimatsu, Gökçe Aydos, Scott K Logan, mergify[bot], mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added CameraInfo display (`#1166 `__) -* Fix camera display overlay (`#1151 `__) -* Fixes for uncrustify 0.78. (`#1155 `__) Mostly what we do here is to disable the indentation on certain constructs that are different between 0.72 and 0.78. It isn't my preferred solution, but since it only affects a small amount of code (and most of that in macros), this seems acceptable to me. -* fixed MovableText::getWorldTransforms transform (`#1118 `__) -* Switch to target_link_libraries. (`#1098 `__) -* Update rviz_rendering and rviz_rendering_tests to C++17. (`#1096 `__) -* Include MeshShape class (`#1064 `__) -* Use assimp to load stl (`#1063 `__) -* RVIZ_RENDERING_PUBLIC to export class RenderSystem (`#1072 `__) -* Restore the maybe-uninitialized flag in covariance_visual.hpp (`#1071 `__) -* Fix up warnings when building with clang. (`#1070 `__) -* Use buildsystem info to get the ros_package_name (`#1062 `__) -* make box-mode point cloud shader lighter on top than bottom (`#1058 `__) -* Removed warning when building in release mode (`#1057 `__) -* Fixed low FPS when sending point markers (`#1049 `__) -* Removed unused code (`#1044 `__) -* Fix the flakey rviz_rendering tests (`#1026 `__) -* Added TwistStamped and AccelStamped default plugins (`#991 `__) -* Added Effort plugin (`#990 `__) -* load GLB meshes (`#1001 `__) -* Fixed camera default plusin crash (`#999 `__) -* Clean Code (`#975 `__) * Clean Code -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Felix F Xu, Morgan Quigley, Yaswanth, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove the loading_ascii_stl_files_fail (`#1125 `__) -* Update rviz_rendering and rviz_rendering_tests to C++17. (`#1096 `__) -* Use assimp to load stl (`#1063 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_visual_testing_framework `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve the compilation time of rviz_default_plugins (`#1007 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* [J-Turtle] Fix uninitialized values in NavSatFix and add missing NavSatStatus UNKNOWN (`#220 `__) * Fix unitialized values in NavSatFix and add missing UNKNOWN * Fixes `#196 `__ * Fix default initialization instead of constants * Define SERVICE_UNKNOWN Co-authored-by: Tully Foote Co-authored-by: Martin Pecka -* Use target qualifier for checking the cpp typesupport exists (`#238 `__) -* sensor_msgs/CompressedImage: updated description of format field (`#231 `__) -* Return true for isColor if format is YUYV or UYUV (`#229 `__) -* Contributors: Chris Lalancette, Kenji Brameld, Ryan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Allow pointcloud create_cloud function to set specific point_step (`#223 `__) -* Fix read_points_numpy field_names parameter -* Contributors: Chris Lalancette, George Broughton - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shape_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`shared_queues_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove unused concurrentqueue implementation. (`#1465 `__) rosbag2 only depends on the readerwriter queue. -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`spdlog_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed spdlog_vendor warnings (`#36 `__) (`#37 `__) (cherry picked from commit 4510d9ab4389f84daac77210f3fdf8aab372b938) Co-authored-by: Alejandro Hernández Cordero -* Upgrade to v1.12.0. (`#35 `__) -* Switch to ament_cmake_vendor_package (`#34 `__) -* Contributors: Marco A. Gutierrez, Scott K Logan, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sqlite3_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_vendor_package (`#1400 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sros2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix linux tutorial: cloning example policies and set of default policies for a node (`#295 `__) (`#296 `__) * clone policies to temporary dir as subversion hack doesnt work anymore * add get_type_description service to policies * update MacOS similarly * update all permissions with new topics * dont rule out cycloneDDS * example of enclave override Co-authored-by: Chris Lalancette (cherry picked from commit ca6bb12cc650b73e7ccfc0fa789d8b49358d44ad) Co-authored-by: Mikael Arguedas -* Use modern PKCS7 to sign the certificate bytes. (`#290 `__) -* Fix a number of warnings on Ubuntu 24.04. (`#289 `__) -* Fix SSH commands in SROS2_Linux.md (`#286 `__) -* Contributors: Boris Boutillier, Chris Lalancette, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`std_srvs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`stereo_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries everywhere. (`#532 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli_remapping `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries everywhere. (`#532 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_communication `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Small fix for modern flake8. (`#539 `__) -* Switch to target_link_libraries everywhere. (`#532 `__) -* Add integration test for nested messages. (`#530 `__) -* Adjust for new rclcpp::Rate API (`#516 `__) -* Contributors: Alexey Merzlyakov, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Small fixes for modern flake8. (`#395 `__) -* add "--log-file-name" command line argument for test. (`#387 `__) -* Fix an assert in the test_launch_ros tests. (`#367 `__) -* Fix misspelled "receive". (`#362 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17 (`#742 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Increase the timeout for the test_msgs rosidl_generated_cpp cpplint. (`#163 `__) This should make it much more likely to succeed on Windows. -* Fix for invalid conversion from const char8_t* to char for C++20 (`#160 `__) -* Contributors: AiVerisimilitude, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_quality_of_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup header includes in test_quality_of_service. (`#533 `__) -* Switch to target_link_libraries everywhere. (`#532 `__) -* Fix test QoS on macOS by moving qos_utilities.cpp to the four tests; fixes `#517 `__ (`#518 `__) -* Contributors: Chris Lalancette, PhDittmann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Addressed TODO in test_local_parameters (`#545 `__) -* Actually skip the gtest_subscription test on Connext. (`#544 `__) -* Increased time in test_multithreaded (`#543 `__) -* Improve the node_name test. (`#538 `__) -* Change up the formatting in the test_rclcpp tests. (`#537 `__) -* Revamp test_rclcpp to compile far few files. (`#535 `__) -* Mark gtest_subscription__rmw_connextdds xfail. (`#531 `__) -* refactor corrected depth check for prefix in parameter_fixtures.hpp (`#529 `__) -* Remove an unnecessary capture in test_rclcpp. (`#527 `__) -* Cleanup of the CMakeLists.txt for test_rclcpp. (`#526 `__) -* Add a fix for the tests given the new type description parameter (`#520 `__) -* Changes ros_timer_init for ros_timer_init2 (`#508 `__) -* refactor the multi_access_publisher test to avoid dead locks (`#515 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Eloy Briceno, Emerson Knapp, Lee, Minju, William Woodall - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Compile the test_rmw_implementation tests fewer times. (`#224 `__) -* Switch to using target_link_libraries everywhere. (`#222 `__) -* Add rmw_count_clients,services & test (`#208 `__) -* Contributors: Chris Lalancette, Lee, Minju - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add explicit context fields test to test_ros2trace (`#107 `__) -* Allow tracing tests to be run in parallel with other tests (`#95 `__) -* Make test_ros2trace depend on test_tracetools_launch. -* Switch to custom lttng-ctl Python bindings (`#81 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_security `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17 (`#528 `__) -* Switch to target_link_libraries everywhere. (`#532 `__) -* Adjust for new rclcpp::Rate API (`#516 `__) -* Extract sros_artifacts fixture into a CMake script (`#525 `__) -* Use test fixtures to create SROS artifacts (`#522 `__) -* Contributors: Alexey Merzlyakov, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Compile fix for upcomming changes to rclcpp::Executor (`#668 `__) -* Adding addition BUILD_TESTING requirement (`#660 `__) -* normalize quaternions on tf2_eigen (`#644 `__) -* Contributors: Lucas Wendland, Paul Gesel, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve tracetools_test and simplify test_tracetools code (`#109 `__) -* Install test_tracetools_mark_process (`#113 `__) -* Remove unnecessary include (`#111 `__) -* Include in mark_process.cpp (`#110 `__) -* Remove unnecessary print in test (`#108 `__) -* Add test for GenericPublisher/Subscriber (`#97 `__) -* Use lttng_ust_tracef instead of lttng_ust__tracef (`#103 `__) -* Use a memcmp for the expected symbol name. (`#100 `__) -* Fix the build on RHEL-9. (`#98 `__) -* Allow tracing tests to be run in parallel with other tests (`#95 `__) -* Fix interference between test_tracetools and ros2lifecycle tests (`#96 `__) -* Make tracing test assert messages more descriptive (`#93 `__) -* Update tests and docs after new rmw_publish timestamp field (`#90 `__) -* Switch to target_link_libraries in test_tracetools. (`#83 `__) -* Improve test coverage of rclcpp_callback_register in test_tracetools (`#69 `__) -* Disable tracing on Android (`#71 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Przemysław Dąbrowski, h-suzuki-isp - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve tracing configuration error reporting (`#85 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote -* Warning Message Intervals for canTransform (`#663 `__) -* Nacho/minor fixes tf2 cache (`#658 `__) -* Removing console_bridge (`#655 `__) -* Fix constantly increasing memory in std::list (`#636 `__) -* Update the tf2 documentation (`#638 `__) -* Fix error code returned in BufferCore::walkToTopParent (`#601 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ignacio Vizzo, Lucas Wendland, Patrick Roncagliolo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_bullet `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed obsolete headers (`#645 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed obsolete headers (`#645 `__) -* normalize quaternions on tf2_eigen (`#644 `__) -* Fix clang build warnings. (`#628 `__) -* Add another reference for twist transformation. Comment correction. (`#620 `__) -* Contributors: Alejandro Hernández Cordero, AndyZe, Chris Lalancette, Paul Gesel - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix installation directory of .dll files in tf2_eigen_kdl (`#657 `__) -* Remove unnecessary use of ament_target_dependencies. (`#637 `__) We can just use target_link_libraries instead. -* Fix clang build warnings. (`#628 `__) -* Contributors: Chris Lalancette, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote -* Removed obsolete headers (`#645 `__) -* Add doTransform support for Point32, Polygon and PolygonStamped (backport `#616 `__) (`#619 `__) -* Contributors: Alejandro Hernández Cordero, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed obsolete headers (`#645 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Compile fix for upcomming changes to rclcpp::Executor (`#668 `__) -* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote -* Adding NodeInterfaces to Buffer (`#656 `__) -* Reformat some code to make uncrustify happier. (`#654 `__) -* Enable intra-process (`#649 `__) (`#642 `__) -* Avoid unecessary time conversions. (`#635 `__) -* Expose TF2 listener CB (`#632 `__) -* Fix invalid timer handle exception (`#474 `__) -* Fix for `#589 `__ - Should be able to transform with default timeout (`#593 `__) -* Enable StaticTransformBroadcaster in Intra-process enabled components (`#607 `__) -* Contributors: AiVerisimilitude, Alejandro Hernández Cordero, Chris Lalancette, Cliff Wu, Lucas Wendland, Patrick Roncagliolo, Steve Macenski, jmachowinski, vineet131 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Transform Data Callback Python (`#664 `__) -* Make sure to cache transforms in tf2_ros_py. (`#634 `__) -* Remove 'efficient copy' prints (`#625 `__) -* Add time jump callback (`#608 `__) -* Contributors: Chris Lalancette, Erich L Foster, Lucas Wendland, Matthijs van der Burgh - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed obsolete headers (`#645 `__) -* Fix clang build warnings. (`#628 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* [view_frames] log filenames after it's been determined (`#674 `__) (`#675 `__) (cherry picked from commit 24643fce510d8cc836fe6e5277a1d3f86a21af04) Co-authored-by: Mikael Arguedas -* Add in tests for tf2_tools. (`#647 `__) -* Contributors: Chris Lalancette, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_monitor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* fix readme for topic_monitor. (`#630 `__) -* Contributors: Michael Jeronimo, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_statistics_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update maintainer list in package.xml files (`#665 `__) -* Contributors: Michael Jeronimo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Switch to ament_generate_version_header for tracetools (`#112 `__) -* Fixes for newer uncrustify (`#101 `__) -* Update tests and docs after new rmw_publish timestamp field (`#90 `__) -* Add timestamp to rmw_publish tracepoint (`#74 `__) -* Add TRACETOOLS\_ prefix to tracepoint-related public macros (`#56 `__) -* Disable tracing on Android (`#71 `__) -* Add new rclcpp_subscription_init tracepoint to support new intra-process comms -* Contributors: Chris Lalancette, Christophe Bedard, Christopher Wecht, Przemysław Dąbrowski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Use single underscore for private vars in Python (`#92 `__) -* Improve tracing configuration error reporting (`#85 `__) -* Fix warnings when using mypy 1.8.0. (`#89 `__) -* Remove extra single quote in LdPreload debug log (`#79 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_read `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Improve tracetools_test and simplify test_tracetools code (`#109 `__) -* Allow tracing tests to be run in parallel with other tests (`#95 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Improve tracetools_test and simplify test_tracetools code (`#109 `__) -* Improve assertEventOrder failure output (`#106 `__) -* Allow tracing tests to be run in parallel with other tests (`#95 `__) -* Fix interference between test_tracetools and ros2lifecycle tests (`#96 `__) -* Make tracing test assert messages more descriptive (`#93 `__) -* Fix use of mutable default arg in tracetools_test (`#84 `__) -* Switch to in pure Python packages (`#67 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Replace all occurences of index.ros.org (`#114 `__) -* Improve tracing configuration error reporting (`#85 `__) -* Add a space in between not and parentheses. (`#88 `__) -* Switch to custom lttng-ctl Python bindings (`#81 `__) -* Create start/pause/resume/stop sub-commands for 'ros2 trace' (`#70 `__) -* Detect issue with LTTng and Docker and report error when tracing (`#66 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`trajectory_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`turtlesim `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add icon for Jazzy. (`#167 `__) (`#168 `__) (cherry picked from commit 014955e15a6ac3b1649cbf21e11c8547ebd47af7) Co-authored-by: Marco A. Gutierrez -* [teleop_turtle_key] update usage string to match keys captured by keyboard (`#165 `__) (`#166 `__) On windows it will stay uppercase but shouldn't impact users compared to current situation (cherry picked from commit e2853cac87f0c62db6294e5bc351e5b52fcd1ae1) Co-authored-by: Mikael Arguedas -* Shorten the callback definition for uncrustify. (`#163 `__) -* Use same QoS for all topic pub/subs (`#161 `__) -* Remove all uses of ament_target_dependencies. (`#159 `__) -* Crop galactic.png and rolling.png to 45x45. (`#158 `__) -* Remove the unused member variable last_state\_ (`#156 `__) -* Added common tests (`#154 `__) -* Heavy cleanup of the draw_square tutorial. (`#152 `__) * Heavy cleanup of the draw_square tutorial. In particular: 1. Make it conform to the current ROS 2 style. 2. Add in copyright information. 3. Refactor the entire code into a class, which tidies it up quite a bit and removes a bunch of globals. 4. Make sure to wait for the reset to complete before trying to move the turtle. -* Remove the range constraints from the holonomic parameter. (`#150 `__) -* Add icon (`#148 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jason O'Kane, Yadu, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`uncrustify_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to uncrustify 0.78.1 (`#37 `__) * Update to uncrustify 0.78.1 * Fix the uncrustify version detection logic. And make sure we are at least 0.78. -* Switch to ament_cmake_vendor_package (`#34 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`unique_identifier_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update to C++17 (`#27 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries (`#36 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf_parser_plugin `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to target_link_libraries (`#36 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`visualization_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove references to index.ros.org. (`#244 `__) -* Adds ARROW_STRIP to Marker.msg (`#242 `__) -* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). -* Contributors: Chris Lalancette, Tom Noble - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`yaml_cpp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed warnigns (`#49 `__) (`#50 `__) (cherry picked from commit 4b6808fd0f9b0b5e05928c0c8e44fd976a043d33) Co-authored-by: Alejandro Hernández Cordero -* Upgrade to yaml-cpp 0.8.0 (`#48 `__) Co-authored-by: Chris Lalancette -* Support yaml-cpp >= 0.8.0 (`#46 `__) -* Disable the -Wshadow warning when building under clang. (`#45 `__) -* Switch to ament_cmake_vendor_package (`#43 `__) -* Revamp the extras file to find the correct version. (`#42 `__) -* Contributors: Chris Lalancette, Marco A. Gutierrez, Scott K Logan, Silvio Traversaro, mergify[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`zstd_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Updated zstd to 1.5.5 (`#1617 `__) (`#1624 `__) -* Switch to ament_cmake_vendor_package (`#1400 `__) -* Contributors: Scott K Logan, mergify[bot] +.. redirect-from:: + + Releases/Jazzy-Jalisco-Complete-Changelog + +Jazzy Jalisco changelog +======================= + +This page is a list of the complete changes in all ROS 2 core packages since the previous release. + +.. contents:: Table of Contents + :local: + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Fix format-security warning with clang. (`#663 `__) +* Migrate std::bind calls to lambda expressions (`#659 `__) +* Contributors: Chris Lalancette, Felipe Gomes de Melo, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Add tests to action_tutorials_py. (`#664 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`actionlib_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Fix a warning from newer versions of flake8. (`#469 `__) +* remove AMENT_IGNORE check in clang-tidy when looking for compilation db (`#441 `__) +* Contributors: Alberto Soragna, Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Add ament_auto_add_gmock to ament_cmake_auto (`#482 `__) +* Contributors: Jordan Palacios, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Provide --header-filter and --jobs to CMake. (`#450 `__) +* Contributors: Michael Jeronimo, Roderick Taylor + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set hints to find the python version we actually want. (`#508 `__) +* Update maintainer list in package.xml files (`#503 `__) +* Use CMAKE_CURRENT_BINARY_DIR instead of CMAKE_BINARY_DIR in ament_generate_environment (`#485 `__) +* Fix CMake error when entire ament projects are added via add_subdirectory (`#484 `__) +* Contributors: Chris Lalancette, Michael Jeronimo, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Increased cpplint timeout by default on Windows (`#486 `__) +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Alejandro Hernández Cordero, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_definitions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_link_flags `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_export_targets `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Add NAMESPACE support to ament_export_targets (`#498 `__) +* Contributors: Michael Jeronimo, Ryan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gen_version_h `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Update to C++17 (`#488 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gmock `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Split ament_add_gmock into _executable and _test. (`#497 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_google_benchmark `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gtest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Split ament_add_gmock into _executable and _test. (`#497 `__) +* ament_add_gtest_test: add TEST_NAME parameter (`#492 `__) +* Contributors: Chris Lalancette, Christopher Wecht, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_include_directories `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_libraries `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* perf: faster ament_libraries_deduplicate implementation (`#448 `__) Co-authored-by: Scott K Logan +* Subtle fix for ament_libraries_deduplicate tests (`#516 `__) +* Add some basic tests to ament_cmake_libraries (`#512 `__) +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo, Scott K Logan, Vincent Richard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in a comment explaining where Python3::Interpreter comes from. (`#510 `__) +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_target_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Fix ``ament_target_dependencies`` (`#452 `__) +* Contributors: Michael Jeronimo, Vincent Richard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Recursively check for errors/failures in produced JUnit result XMLs (`#446 `__) +* Contributors: Michael Jeronimo, Nick Morales + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added Timeout to ament_uncrustify (`#485 `__) +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Alejandro Hernández Cordero, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_vendor_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add more CMake variables to pass to vendor projects (`#519 `__) +* Fix patch file dependencies in ament_cmake_vendor_package (`#520 `__) +* Update maintainer list in package.xml files (`#503 `__) +* Always set CMAKE_C[XX]_COMPILER for vendor packages if needed (`#476 `__) +* Switch to CMake 'braket arguments' (`#461 `__) +* Replace 'git' dep with 'vcstool' (`#462 `__) +* Add support for specifying a patch directory in ament_vendor (`#449 `__) +* Contributors: Christophe Bedard, Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_version `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#503 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Small fixes for modern flake8. (`#484 `__) +* Fix add-copyright year function (`#466 `__) +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Chris Lalancette, Lloyd Pearson, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Add in checks to ament_cppcheck code. (`#472 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Pass --output argument to cpplint (`#453 `__) +* Contributors: Michael Jeronimo, Vladimir Ivan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Changes to make ament_flake8 work with v6+ (`#459 `__) +* Add additional dependencies to ament_flake8. (`#454 `__) +* Fix compatibility with flake8 version 5 (`#410 `__) +* Contributors: Chris Lalancette, Michael Carroll, Michael Jeronimo, Timo Röhling + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update quality declaration documents (`#94 `__) +* only append search paths on first PackageNotFound (`#91 `__) +* Update to C++17 (`#90 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Lucas Walter + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update quality declaration documents (`#94 `__) +* Add type annotations to python files. (`#93 `__) +* Contributors: Christophe Bedard, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Add an ament_lint test dependency on python3-pytest. (`#473 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Fix a flake8 warning in ament_mypy. (`#470 `__) No need for parentheses around an assert. +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Migrate from legacy importlib-resources (`#143 `__) +* Add setuptools dependency back in. (`#141 `__) +* Make python dependencies exec_depend. (`#140 `__) +* Contributors: Chris Lalancette, Isabel Paredes + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pep257 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Convert linenumber to string when printing errors (`#443 `__) +* Contributors: Michael Jeronimo, Robert Brothers + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Adds uncrustify 0.78.1 config (`#475 `__) +* Update maintainer list in package.xml files (`#474 `__) +* Fix a flake8 warning in ament_uncrustify. (`#471 `__) +* Contributors: Chris Lalancette, Marco A. Gutierrez, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#474 `__) +* (ament_xmllint) add extensions argument (`#456 `__) +* Contributors: Matthijs van der Burgh, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_calibration_parsers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to yaml-cpp 0.8.0. (`#305 `__) +* Switch from rcpputils::fs to std::filesystem (`#300 `__) +* Removed C headers: camera_info_manager camera_calibration_parsers (`#290 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_info_manager `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch from rcpputils::fs to std::filesystem (`#300 `__) +* Removed C headers: camera_info_manager camera_calibration_parsers (`#290 `__) +* Contributors: Alejandro Hernández Cordero, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`class_loader `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove all uses of ament_target_dependencies. (`#210 `__) +* Update to C++17 (`#209 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`common_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [composition] add launch action console output in the verify section (`#677 `__) (`#681 `__) (cherry picked from commit 34d29db73e78a84a174ad8699a2d646b0eeb1cdf) Co-authored-by: Mikael Arguedas +* Update maintainer list in package.xml files (`#665 `__) +* Migrate std::bind calls to lambda expressions (`#659 `__) +* Contributors: Felipe Gomes de Melo, Michael Jeronimo, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [demo_nodes_cpp] some readme and executable name fixups (`#678 `__) (`#688 `__) (cherry picked from commit aa8df8904b864d063e31fd5b953ffe561c7a9fe0) Co-authored-by: Mikael Arguedas +* Fix gcc warnings when building with optimizations. (`#672 `__) (`#673 `__) * Fix gcc warnings when building with optimizations. When building the allocator_tutorial_pmr demo with -O2, gcc is throwing an error saying that new and delete are mismatched. This is something of a misnomer, however; the real problem is that the global new override we have in that demo is actually implemented incorrectly. In particular, the documentation at https://en.cppreference.com/w/cpp/memory/new/operator_new very clearly specifies that operator new either has to return a valid pointer, or throw an exception on error. Our version wasn't throwing the exception, so change it to throw std::bad_alloc if std::malloc fails. While we are in here, also fix another small possible is where std::malloc could return nullptr on a zero-sized object, thus throwing an exception it shouldn't. * Always inline the new and delete operators. That's because gcc 13 has a bug where it can sometimes inline one or the other, and then it detects that they mismatch. For gcc and clang, just force them to always be inline in this demo. * Switch to NOINLINE instead. Both clang and MSVC don't like inlining these, so instead ensure that they are *not* inlined. This also works because the problem is when new is inlined but not delete (or vice-versa). As long as they are both not inlined, this should fix the warning. (cherry picked from commit 957ddbb9f04f55cabd8496e8d74eb35ee4d29105) Co-authored-by: Chris Lalancette +* A few uncrustify fixes for 0.78. (`#667 `__) +* Allow users to configure the executor for executables in ``demo_nodes_cpp`` (`#666 `__) +* Update maintainer list in package.xml files (`#665 `__) +* Added extra documentation and clarifications. (`#651 `__) +* Add in support for both the PMR and custom allocator tutorials. (`#655 `__) +* Replacing old-style C++ allocator with a polymorphic memory resource (PMR) (`#653 `__) +* Remove unnecessary captures in the various demos. (`#647 `__) +* Dramatically speed up the demo_nodes_cpp tests (`#641 `__) +* Switch to using RCLCPP logging macros in the lifecycle package. (`#644 `__) +* failed to call introspection_client (`#643 `__) +* Small cleanups to the demos when running through them. (`#639 `__) +* Cleanup demo_nodes_cpp CMake and dependencies (`#638 `__) +* Change the service introspection parameter off value to 'disabled' (`#634 `__) +* Add demos for using logger service (`#611 `__) +* Contributors: Ali Ashkani Nia, Barry Xu, Chen Lihui, Chris Lalancette, Michael Jeronimo, Yadu, jrutgeer, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp_native `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Change the service introspection parameter off value to 'disabled' (`#634 `__) With this we can avoid the tricky bits around YAML interpretation of 'off' as a boolean. +* Add demos for using logger service (`#611 `__) +* Contributors: Barry Xu, Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`diagnostic_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_map_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_robot_bringup `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Switch to file-content launch substitution (`#627 `__) +* Contributors: Michael Jeronimo, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_sensors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update dummy_sensors readme to echo the correct topic (`#675 `__) (`#684 `__) (cherry picked from commit eec5c12ea95dfaaa230f9f1a8e9cff9b09dde5d5) Co-authored-by: jmackay2 <1.732mackay@gmail.com> +* Update maintainer list in package.xml files (`#665 `__) +* Fix unstable LaserScan status for rviz2 (`#614 `__) +* Contributors: Chen Lihui, Michael Jeronimo, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`example_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17. (`#18 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix: Fixed compilation after API change of TimerBase::execute (`#375 `__) Co-authored-by: Janosch Machowinski +* Split lambda and subscriber def in minimal example (`#363 `__) +* Contributors: Felipe Gomes de Melo, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_wait_set `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix: Fixed compilation after API change of TimerBase::execute (`#375 `__) Co-authored-by: Janosch Machowinski +* Contributors: jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`foonathan_memory_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve mechanism to find an installation of foonathan_memory (#67) +* Added support for QNX 7.1 build (#65) + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove references to index.ros.org. (`#244 `__) +* Create new messages with all fields needed to define a velocity and transform it (`#240 `__) Co-authored-by: Dr. Denis Co-authored-by: Addisu Z. Taddese Co-authored-by: Tully Foote +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* adding IDs to geometry_msgs/Polygon, PolygonStamped (`#232 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Steve Macenski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`google_benchmark_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to 1.8.3. (`#29 `__) +* Contributors: Marco A. Gutierrez + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gz_cmake_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update vendored version to 3.5.3 +* Use an alias target for root library +* Add support for the ``::`` and ``::all`` targets, fix sourcing of dsv files +* Update vendored version to 3.5.2 +* Update vendored package version +* Patch the pkg-config directory in the gz-cmake code. (`#4 `__) * Patch the pkg-config directory in the gz-cmake code. When building on the ROS 2 buildfarm, we aren't setting some of the CMAKE_PREFIX variables. This means that using CMAKE_INSTALL_FULL_LIBDIR actually creates a path like /opt/ros/rolling/... , which makes debuild upset. However, we actually need the FULL_LIBDIR in order to calculate the relative path between it and the INSTALL_PREFIX. Work around this by having two variables; the pkgconfig_install_dir (relative), used to install the files, and pkgconfig_abs_install_dir (absolute), used to calculate the relative path between them. This should fix the build on the buildfarm. I'll note that we are doing it here and not in gz-cmake proper because of knock-on effects to downstream gazebo. If this is successful we may end up merging it there, at which point we can drop this patch. * Update GzPackage as well. --------- +* Require calling find_package on the underlying package (`#3 `__) This also changes the version of the vendor package to 0.0.1 and adds the version of the vendored package in the description +* Fix linter (`#2 `__) +* Use ```` on upstream package so that dependency is exported +* Update maintainer +* Add package.xml and CMakeLists (`#1 `__) +* Initial import +* Contributors: Addisu Z. Taddese, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gz_math_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use an alias target for root library +* Add support for the ``::`` and ``::all`` targets, fix sourcing of dsv files +* Disable SWIG to fix CMake warning +* Disable pybind11 for now +* Require calling find_package on the underlying package (`#2 `__) +* Fix linter (`#1 `__) +* Remove Nate +* Update maintainers +* Initial import +* Contributors: Addisu Z. Taddese + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gz_utils_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use an alias target for root library +* Add support for the ``::`` and ``::all`` targets, fix sourcing of dsv files +* Require calling find_package on the underlying package (`#2 `__) +* Fix linter (`#1 `__) +* Initial import +* Contributors: Addisu Z. Taddese + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* A few uncrustify fixes for 0.78. (`#667 `__) +* Update maintainer list in package.xml files (`#665 `__) +* Migrate std::bind calls to lambda expressions (`#659 `__) +* Contributors: Chris Lalancette, Felipe Gomes de Melo, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added rclcpp component to Republish (`#275 `__) +* Add QoS option reliability to republisher qos params (`#296 `__) +* implement CameraSubscriber::getNumPublishers (`#297 `__) +* Add missing definition for CameraPublisher::publish overload (`#278 `__) +* Advertize and subscribe with custom qos (`#288 `__) +* Removed C headers (`#289 `__) +* Switch to using the override keyword for simple_publisher_plugin. (`#285 `__) +* feat: enable plugin allowlist (`#264 `__) +* Expose option to set callback groups (`#274 `__) +* add support for lazy subscribers (`#272 `__) +* Contributors: Aditya Pande, Alejandro Hernández Cordero, Carlos Andrés Álvarez Restrepo, Chris Lalancette, Daisuke Nishimatsu, Michael Ferguson, s-hall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`interactive_markers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Shorten the length of a lambda. (`#106 `__) +* Fixed C++20 warning that ‘++’ expression of ‘volatile’-qualified type is deprecated (`#102 `__) +* Cleanup of interactive markers (`#101 `__) +* Contributors: AiVerisimilitude, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`intra_process_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Migrate std::bind calls to lambda expressions (`#659 `__) +* Fix executable name in README (`#618 `__) +* Contributors: Felipe Gomes de Melo, Michael Jeronimo, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`kdl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17. (`#82 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`keyboard_handler `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Shorten lambdas so newer uncrustify is happier. (`#42 `__) +* Fixed C++20 warning implicit capture of this in lambda (`#41 `__) +* Update to C++17. (`#37 `__) +* Contributors: AiVerisimilitude, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`laser_geometry `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries. (`#92 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* (launch) fix describe of PathJoinSubstitution (`#771 `__) +* Small fixes for modern flake8. (`#772 `__) +* Cleanup some type annotations. +* Rework task exceptions loop. (`#755 `__) +* add format overriding by environment variables (`#722 `__) +* Add exception type to error output (`#753 `__) +* Let XML executables/nodes be "required" (like in ROS 1) (`#751 `__) +* Add conditional substitution (`#734 `__) +* Add maximum times for a process to respawn (`#696 `__) +* Add in a timeout for launch pytests. (`#725 `__) +* Fix remaining occurrences of "There is no current event loop" (`#723 `__) +* Update the launch code for newer flake8 and mypy. (`#719 `__) +* Remove the deprecated some_actions_type.py (`#718 `__) +* Improve launch file parsing error messages (`#626 `__) +* Add file-content launch substitution (`#708 `__) +* Contributors: Chris Lalancette, David Yackzan, Marc Bestmann, Matthew Elwin, Matthijs van der Burgh, Nick Lamprianidis, Santti4go, Scott K Logan, Timon Engelke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch tryfirst/trylast to hookimpl. +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix: typing. Iterable doesn't have __getitem_\_ (`#393 `__) +* Cleanup some type annotations. (`#392 `__) +* Create py.typed to mark this library as typed (`#379 `__) +* Remove create_future implementation. (`#372 `__) +* cache lookup of importlib metadata in Node action (`#365 `__) +* Get rid of unnecessary checks in composable_node_container. (`#364 `__) +* Contributors: Chris Lalancette, Jonas Otto, Matthijs van der Burgh, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix a warning in modern unittest. (`#773 `__) Newer versions of unittest no longer store an errors list; instead, they store a result, which then stores an error list. Update the code here to be able to deal with either version. +* Add consider_namespace_packages=False (`#766 `__) +* to open expected outpout file with an encoding parameter (`#717 `__) +* Contributors: Chen Lihui, Chris Lalancette, Tony Najjar + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_examples `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup the launch_testing_examples. (`#374 `__) +* Refactor WaitForNodes class. (`#373 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make launch_testing_ros examples more robust. (`#394 `__) +* added type hinting to launch_testing_ros/test/examples (`#386 `__) +* Handle spin() ExternalShutdownException. (`#378 `__) +* Increase the timeout in wait_for_topic_launch_test. (`#377 `__) +* ``WaitForTopics``: get content of messages for each topic (`#353 `__) +* Contributors: Chris Lalancette, Giorgio Pintaudi, Yaswanth + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_xml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* launch_xml: fix xml syntax in README (`#770 `__) +* Let XML executables/nodes be "required" (like in ROS 1) (`#751 `__) * Let XML nodes be "required" Essentially on_exit="shutdown" is equivalent to ROS 1 required="true". This feature is implemented using the python launchfile on_exit mechanism. Right now "shutdown" is the only action accepted by on_exit, but theoretically more "on_exit" actions could be added later. Example: * Added tests for yaml +* Improve launch file parsing error messages (`#626 `__) +* Contributors: Matthew Elwin, Steve Peters, Timon Engelke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_yaml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix flake8 warnings in launch_yaml. (`#756 `__) +* Let XML executables/nodes be "required" (like in ROS 1) (`#751 `__) * Let XML nodes be "required" Essentially on_exit="shutdown" is equivalent to ROS 1 required="true". This feature is implemented using the python launchfile on_exit mechanism. Right now "shutdown" is the only action accepted by on_exit, but theoretically more "on_exit" actions could be added later. Example: * Added tests for yaml +* Improve launch file parsing error messages (`#626 `__) +* Contributors: Chris Lalancette, Matthew Elwin, Timon Engelke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libcurl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add "lib" to the Windows curl search path. (`#96 `__) (`#97 `__) In CMake 3.3, a commit made it so that the find_package module in CMake had a compatibility mode where it would automatically search for packages in a /lib subdirectory. In CMake 3.6, this compatibility mode was reverted for all platforms *except* Windows. That means that since CMake 3.3, we haven't actually been using the path as specified in ``curl_DIR``, but we have instead been inadvertently relying on that fallback behavior. In CMake 3.28, that compatibilty mode was also removed for Windows, meaning that we are now failing to find_package(curl) in downstream packages (like resource_retriever). Fix this by adding in the "lib" directory that always should have been there. I'll note that this *only* affects our Windows builds, because this code is in a if(WIN32) block. (cherry picked from commit 1839d583190eb9dcf339eaaf6bebe632d94664a6) Co-authored-by: Chris Lalancette +* Switch to ament_cmake_vendor_package (`#86 `__) +* Contributors: Scott K Logan, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`liblz4_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to build_export_depend liblz4-dev. (`#1614 `__) +* Switch to using ament_vendor_package for lz4. (`#1583 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libstatistics_collector `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump pascalgn/automerge-action from 0.16.2 to 0.16.3 +* Bump codecov/codecov-action from 4.1.1 to 4.2.0 +* Fixes for newer uncrustify. (`#186 `__) +* Bump actions/upload-artifact from 3 to 4 +* Switch to using target_link_libraries everywhere. (`#174 `__) +* Bump rolling to 1.6.3 (`#173 `__) +* Bump actions/checkout from 3 to 4 (`#169 `__) +* Add API to use message_info instead unserialized message (`#170 `__) +* Bump codecov/codecov-action from 3.1.3 to 3.1.4 +* Bump actions/checkout from 3 to 4 (`#169 `__) +* Add API to use message_info instead unserialized message (`#170 `__) +* Bump codecov/codecov-action from 3.1.3 to 3.1.4 +* Add in missing cstdint include. (`#165 `__) +* Bump codecov/codecov-action from 3.1.2 to 3.1.3 +* Contributors: Chris Lalancette, Lucas Wendland, Michael Orlov, dependabot[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libyaml_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update quality declaration documents (`#62 `__) +* remove rcpputils and rcutils dependency (`#61 `__) +* Set to C++17. (`#59 `__) +* Switch to ament_cmake_vendor_package (`#58 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Kenta Yonekura, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* A few uncrustify fixes for 0.78. (`#667 `__) +* Update maintainer list in package.xml files (`#665 `__) +* Migrate std::bind calls to lambda expressions (`#659 `__) +* Switch to using RCLCPP logging macros in the lifecycle package. (`#644 `__) +* Contributors: Chris Lalancette, Felipe Gomes de Melo, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`logging_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Migrate std::bind calls to lambda expressions (`#659 `__) +* Contributors: Felipe Gomes de Melo, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lttngpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Fixes for newer uncrustify (`#101 `__) +* Fix Python not being found for lttngpy in Windows debug mode (`#87 `__) +* Switch to custom lttng-ctl Python bindings (`#81 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`map_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files +* Update to C++17 +* Contributors: Chris Lalancette, Michael Jeronimo, Steve Macenski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mcap_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to using ament_vendor_package for lz4. (`#1583 `__) +* Switch to target_link_libraries everywhere. (`#1504 `__) +* Update mcap to v1.1.0 (`#1361 `__) +* Contributors: Chris Lalancette, Emerson Knapp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`message_filters `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update TimeSynchronizer usage example. (`#115 `__) +* Remove 'using' keyword in message_filters (`#106 `__) +* Remove the use of ament_target_dependencies. (`#105 `__) +* Fixes pointed out by clang (`#104 `__) +* Mark subscription cb parameter const (`#103 `__) +* Update the HasHeader check to be more specific. (`#101 `__) +* TypeAdapters support (`#95 `__) (`#96 `__) +* Cleanup a few minor things in the filters. (`#100 `__) +* Fix python examples (`#99 `__) +* feat: add signal time functions to ExactTime policy (`#94 `__) +* Contributors: Chris Lalancette, Patrick Roncagliolo, Ricardo de Azambuja, Russ, rkeating-planted + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mimick_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump vendored mimick version for `ros2/Mimick#32 `__ (`#35 `__) +* Update to the commit that fixes mmk_noreturn. (`#34 `__) +* Update to the commit the fixes exe stack on macOS. (`#33 `__) +* Update to the comment that fixes the executable stack. (`#32 `__) +* Update to take advantage of TARGET_ARCH (`#28 `__) +* Switch to ament_cmake_vendor_package (`#31 `__) +* Contributors: Chris Lalancette, Michael Carroll, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`nav_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed TODO (`#243 `__) +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`orocos_kdl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Ensure that orocos_kdl_vendor doesn't accidentally find itself. (`#27 `__) (`#28 `__) When initially building the orocos_kdl_vendor package (on platforms where it actually builds), it turns out that it places a valid cmake configuration in the build directory. In turn, that means that a subsequent rebuild will find this configuration in the build directory, and throw the rest of the logic off. This only seems to be a problem with CMake 3.29 and later, though I can't say exactly why at the moment. Workaround this problem by writing the configuration out to a temporary file, and then moving it into the final place with the final name. (cherry picked from commit 7aad6d1ad9fa54f3a48f1f194a85127e362c8ade) Co-authored-by: Chris Lalancette +* Update to the latest orocos_kdl_kinematics commit. (`#25 `__) +* Switch to ament_cmake_vendor_package (`#20 `__) +* Contributors: Chris Lalancette, Scott K Logan, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Catch all of the spurious warnings from get_event_loop. (`#94 `__) +* Add bookworm as a python3 target (`#91 `__) +* Suppress warning for specifically handled behavior (`#87 `__) +* Update supported platforms (`#93 `__) +* Add GitHub Actions CI workflow (`#88 `__) +* Contributors: Chris Lalancette, Scott K Logan, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_testing_tools_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Upgrade to Google test 1.14.0 (`#84 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_control `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* [pendulum_control Install targets to project lib (`#624 `__) +* Contributors: Michael Jeronimo, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pluginlib `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch from rcpputils::fs to std::filesystem (`#254 `__) +* Remove redundant throw of a std::runtime_error (`#232 `__) +* Update to C++17 (`#251 `__) +* Fix wShadow compile warning (`#250 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Hunter L. Allen, Steve Macenski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pybind11_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to pybind11 2.11.1 (`#28 `__) +* Add Apache 2.0 LICENSE file (`#27 `__) +* Switch to ament_cmake_vendor_package (`#24 `__) +* Contributors: Chris Lalancette, Michael Carroll, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use FindPython3 instead of FindPythonInterp (`#7 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_orocos_kdl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to the latest orocos_kdl_kinematics commit. (`#25 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_qt_binding `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Suppress warning from Shiboken2. (backport `#137 `__) (`#138 `__) Co-authored-by: Chris Lalancette Co-authored-by: Alejandro Hernández Cordero +* Switch to C++17 for SIP and Shiboken (`#135 `__) +* Set hints to find the python version we actually want. (`#134 `__) +* Remove unnecessary parentheses around assert. (`#133 `__) +* Switch to FindPython3 in the shiboken_helper.cmake. (`#132 `__) +* Cleanup of the sip_configure.py file. (`#131 `__) +* Update the SIP support so we can deal with a broken RHEL-9. (`#129 `__) +* Contributors: Chris Lalancette, Christophe Bedard, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_dotgraph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Handle empty dotcode nodes. (`#290 `__) +* Small fix for modern flake8. (`#289 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove unnecessary parentheses for assert. (`#286 `__) +* (qt_gui) extended theme logic to get icons (`#279 `__) +* Contributors: Chris Lalancette, Matthijs van der Burgh + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch from rcpputils::fs to std::filesystem (`#288 `__) +* Set hints to find the python version we actually want. (`#287 `__) +* Update to C++17 (`#278 `__) +* fix unload warning (`#274 `__) +* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Explicit time conversion (`#657 `__) +* Cleanup the interactive quality of service demos. (`#637 `__) +* More quality of service demo cleanup (`#632 `__) +* Fix small typos in the incompatible_qos demos. (`#629 `__) +* Contributors: AiVerisimilitude, Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* More quality of service demo cleanup (`#632 `__) +* Fix small typos in the incompatible_qos demos. (`#629 `__) +* Fix the quality_of_service_demo_py output to look like the C++ one. (`#626 `__) +* Use non-deprecated rclpy import. (`#615 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix up rmw_cyclonedds timestamp testing. (`#1156 `__) (`#1157 `__) We are about to fix it so that rmw_cyclonedds has receive_timestamp support, so we also need to enable that support here in rcl. We actually rewrite the logic a bit because now the only combination that doesn't work is rmw_connextdds on Windows. (cherry picked from commit 6d53d24a863c3e9e4a41e9fe5f550271210d9d9d) Co-authored-by: Chris Lalancette +* Fixed warnings - strict-prototypes (`#1148 `__) (`#1150 `__) +* chore: Minor style improvements (`#1147 `__) Co-authored-by: Janosch Machowinski +* improved rcl_wait in the area of timeout computation and spurious wakeups (`#1146 `__) Added special handling for timers with a clock that has time override enabled. For these timer we should not compute a timeout, as the waitset is waken up by the associated guard condition. Before this change, the waitset could wait up, because of an expected ready timer, that was acutally not ready, as the time update to the ROS_TIME had not yet arrived. +* Add tracepoint for publish_serialized_publish (`#1136 `__) * Add tracepoint for publish_serialized_publish * Add: tracepoint for rcl_take_serialized_message --------- +* Revert "improved rcl_wait in the area of timeout computation and spurious wakeups (`#1135 `__)" (`#1142 `__) This reverts commit 3c6c5dc47dac23d70722a60b2c0a387d2e71b71d. +* improved rcl_wait in the area of timeout computation and spurious wakeups (`#1135 `__) * feat: Allow usage of rcl_timer_clock with const rcl_timer_t* * fix: Fixed purious wake-ups on ROS_TIME timers with ROS_TIME enabled Added special handling for timers with a clock that has time override enabled. For theses timer we should not compute a timeout, as the waitset is waken up by the associated guard condition. Before this change, the waitset could wait up, because of an expected ready timer, that was acutally not ready, as the time update to the ROS_TIME had not yet arrived. * feat: Added rcl_timer_get_next_call_time * fix(rcl_wait): Improved timeout computation in case of many timers This commit changes the computation of the timer timeout, to be more precise, in the case, of many registered timers. --------- Co-authored-by: Janosch Machowinski +* Generate version header using ament_generate_version_header(..) (`#1141 `__) +* Add rcl_timer_call_with_info function that retrieves the expected and the actual timer trigger times (`#1113 `__) Co-authored-by: Alexis Tsogias Co-authored-by: Michael Carroll Co-authored-by: Tomoya Fujita +* document out parameters for rcl_get_node_names and rcl_get_node_names_with_enclaves (`#1137 `__) * document out params for rcl_get_node_names Co-authored-by: Chris Lalancette +* Cleanups for uncrustify 0.78. (`#1134 `__) Mostly this is expanding macros, as this is just easier to read anyway. But we also mark one section as INDENT-OFF. +* Re-order rcl_logging_interface include (`#1133 `__) +* Remove unnecessary macros. (`#1132 `__) These really don't add anything, and allows us to avoid some changes in macro formatting between Ubuntu 22.04 and Ubuntu 24.04. +* Update quality declaration documents (`#1131 `__) +* add unit tests for --log-file-name argument. (`#1130 `__) +* support ``--log-file-name`` to ros args. (`#1127 `__) +* Make sure to disable a test_node test on RHEL. (`#1124 `__) +* remove static function rcl_ret_from_rcutils_ret(). (`#1122 `__) +* Remove AMENT_DEPENDENCIES from rcl_add_custom_gtest. (`#1119 `__) +* Remove unncecessary dependencies in tests (`#1114 `__) +* a rosout publisher of a node might not exist (`#1115 `__) +* Set disable loan to on by default. (`#1110 `__) +* Return service from node_type_description_service_init (`#1112 `__) +* next_call_time will always be greater than now after calling rcl_timer_call. (`#1089 `__) +* Add rcl count clients, servicec & tests (`#1011 `__) +* Improve the reliability of test_get_type_description_service. (`#1107 `__) +* Remove most remaining uses of ament_target_dependencies. (`#1102 `__) +* Just remove rcpputils::fs dependency (`#1105 `__) +* Decouple rosout publisher init from node init. (`#1065 `__) +* Cleanup the error handling in rcl_node_init. (`#1099 `__) +* Fix a clang warning for suspicious string concatentation. (`#1101 `__) +* add the link to the topic name rules. (`#1100 `__) +* Cut down the amount of time for test_logging_rosout. (`#1098 `__) +* Simplify local_namespace handling in rcl_node_init. (`#1097 `__) +* Reduce the number of tests we run (`#1096 `__) +* Adding duplicate node information (`#1088 `__) +* Revamp the test_get_type_description_service. (`#1095 `__) +* Cleanup network flow endpoints test. (`#1094 `__) +* Reduce the failure timeout time for namespaces. (`#1093 `__) +* Shorten wait time for a subscription not being ready. (`#1092 `__) +* rcl_send_response returns RCL_RET_TIMEOUT. (`#1048 `__) +* Move test_namespace into the correct directory. (`#1087 `__) +* Reset errors in tests to reduce warnings (`#1085 `__) +* Cleanup error reporting in the type hash code. (`#1084 `__) +* Instrument loaned message publication code path (`#1083 `__) +* Add ``~/get_type_description`` service (rep2011) (`#1052 `__) +* Modifies timers API to select autostart state (`#1004 `__) +* test publisher/subscription with the c/cpp typesupport for test_msgs::msg::array (`#1074 `__) +* validation result should be used to print the error message. (`#1077 `__) +* improve error msg of ``rcl_expand_topic_name`` (`#1076 `__) +* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#1058 `__) +* fix comment (`#1073 `__) +* localhost_only prevails auto discovery options if enabled. (`#1069 `__) +* Avoid dynamic allocation of message before sending over rosout (`#1067 `__) +* clarify ``rcl_node_init`` return code (`#1066 `__) +* Fix a format-security warning when building with clang. (`#1064 `__) +* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, Eloy Briceno, Eric W, Felix Penzlin, G.A. vd. Hoorn, Hans-Joachim Krauch, Kenta Yonekura, Lee, Lucas Wendland, Michael Carroll, Minju, Thiemo Kohrt, Tomoya Fujita, h-suzuki-isp, jmachowinski, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Generate version header using ament_generate_version_header(..) (`#1141 `__) +* add RCL_RET_TIMEOUT to action service response. (`#1138 `__) * add RCL_RET_TIMEOUT to action service response. * address review comment. --------- +* Update quality declaration documents (`#1131 `__) +* Remove most remaining uses of ament_target_dependencies. (`#1102 `__) +* Add ``~/get_type_description`` service (rep2011) (`#1052 `__) +* Modifies timers API to select autostart state (`#1004 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Eloy Briceno, G.A. vd. Hoorn, Hans-Joachim Krauch, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the Log.msg constant types. (`#161 `__) +* Update the comments for SetParametersResult to reflect reality. (`#159 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed warnings - strict-prototypes (`#1148 `__) (`#1150 `__) +* Generate version header using ament_generate_version_header(..) (`#1141 `__) +* Update quality declaration documents (`#1131 `__) +* Remove most remaining uses of ament_target_dependencies. (`#1102 `__) +* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#1058 `__) +* Contributors: Chris Lalancette, Christophe Bedard, G.A. vd. Hoorn, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Check allocator validity in some rcl_logging functions (`#116 `__) If the allocator is zero-initialized, it may cause a segfault when it is used later in the functions. +* Use (void) in declaration of param-less function (`#114 `__) +* add file_name_prefix parameter to external log configuration. (`#109 `__) +* Migrate to std::filesystem (`#104 `__) +* Remove the last uses of ament_target_dependencies in this repo. (`#102 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Kenta Yonekura, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_noop `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add file_name_prefix parameter to external log configuration. (`#109 `__) +* Remove the last uses of ament_target_dependencies in this repo. (`#102 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_spdlog `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Check allocator validity in some rcl_logging functions (`#116 `__) If the allocator is zero-initialized, it may cause a segfault when it is used later in the functions. +* Cleanup the tests. (`#115 `__) * Cleanup the tests. There are a few different fixes in here: 1. Move away from using "popen" to get the list of files in a directory. Instead, switch to using the C++ std::filesystem directory iterator and doing the work ourselves, which is portable and much less error-prone. 2. Set the ROS_LOG_DIR for all of the tests in here. This should make the test resistant to being run in parallel with other tests. 3. Consistently use rcpputils::set_env_var, rather than a mix of rcpputils and rcutils. +* Update quality declaration document (`#112 `__) +* Re-order rcl_logging_interface include (`#111 `__) +* add file_name_prefix parameter to external log configuration. (`#109 `__) +* Migrate to std::filesystem (`#104 `__) +* Remove the last uses of ament_target_dependencies in this repo. (`#102 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Kenta Yonekura, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_yaml_param_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Generate version header using ament_generate_version_header(..) (`#1141 `__) +* Update quality declaration documents (`#1131 `__) +* Fix for incorrect integer value conversion on Windows (`#1126 `__) +* Just remove rcpputils::fs dependency (`#1105 `__) +* Contributors: Christophe Bedard, G.A. vd. Hoorn, Kenta Yonekura, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add impl pointer for ExecutorOptions (`#2523 `__) (`#2525 `__) * add impl pointer for ExecutorOptions (cherry picked from commit 343b29b617b163ad72b9fe3f6441dd4ed3d3af09) Co-authored-by: William Woodall +* Fixup Executor::spin_all() regression fix (`#2517 `__) (`#2521 `__) * test(Executors): Added tests for busy waiting Checks if executors are busy waiting while they should block in spin_some or spin_all. * fix: Reworked spinAll test This test was strange. It looked like, it assumed that spin_all did not return instantly. Also it was racy, as the thread could terminate instantly. * fix(Executor): Fixed spin_all not returning instantly is no work was available * Update rclcpp/test/rclcpp/executors/test_executors.cpp * test(executors): Added test for busy waiting while calling spin * fix(executor): Reset wait_result on every call to spin_some_impl Before, the method would not recollect available work in case of spin_some, spin_all. This would lead to the method behaving differently than to what the documentation states. * restore previous test logic for now * refactor spin_some_impl's logic and improve busy wait tests * added some more comments about the implementation --------- Co-authored-by: Janosch Machowinski Co-authored-by: jmachowinski Co-authored-by: Tomoya Fujita Co-authored-by: William Woodall +* Revise the description of service configure_introspection() (`#2511 `__) (`#2513 `__) +* Remove references to index.ros.org. (`#2504 `__) +* Reduce overhead for inheriting from rclcpp::Executor when base functionality is not reused (`#2506 `__) +* [wjwwood] Updated "Data race fixes" (`#2500 `__) * Fix callback group logic in executor * fix: Fixed unnecessary copy of wait_set * fix(executor): Fixed race conditions with rebuild of wait_sets Before this change, the rebuild of wait set would be triggered after the wait set was waken up. With bad timing, this could lead to the rebuild not happening with multi threaded executor. * fix(Executor): Fixed lost of entities rebuild request * chore: Added assert for not set callback_group in execute_any_executable * Add test for cbg getting reset Co-authored-by: Janosch Machowinski * chore: renamed test cases to snake_case * style * fixup test to avoid polling and short timeouts * fix: Use correct notify_waitable\_ instance * fix(StaticSingleThreadedExecutor): Added missing special case handling for current_notify_waitable\_ * fix(TestCallbackGroup): Fixed test after change to timers --------- Co-authored-by: Janosch Machowinski Co-authored-by: Michael Carroll Co-authored-by: Janosch Machowinski +* fixup var names to snake case (`#2501 `__) +* Added optional TimerInfo to timer callback (`#2343 `__) Co-authored-by: Alexis Tsogias Co-authored-by: Janosch Machowinski +* Fix uninitialized memory in test (`#2498 `__) When I added in the tests for large messages, I made a mistake and reserved space in the strings, but didn't actually expand it. Thus, we were writing into uninitialized memory. Fix this by just using the correct constructor for string, which will allocate and initialize the memory properly. +* Ensure waitables handle guard condition retriggering (`#2483 `__) Co-authored-by: Michael Carroll +* fix: init concatenated_vector with begin() & end() (`#2492 `__) * this commit will fix the warning [-Wstringop-overflow=] `#2461 `__ +* Use the same context for the specified node in rclcpp::spin functions (`#2433 `__) * Use the same conext for the specified node in rclcpp::spin_xx functions * Add test for spinning with non-default-context * Format code --------- +* Disable compare-function-pointers in test_utilities (`#2489 `__) +* address ambiguous auto variable. (`#2481 `__) +* Increase the cppcheck timeout to 1200 seconds (`#2484 `__) +* Removed test_timers_manager clang warning (`#2479 `__) +* Flaky timer test fix (`#2469 `__) * fix(time_source): Fixed possible race condition * fix(test_executors_time_cancel_behaviour): Fixed multiple race conditions --------- Co-authored-by: Janosch Machowinski +* Add tracepoint for generic publisher/subscriber (`#2448 `__) +* update rclcpp::Waitable API to use references and const (`#2467 `__) +* Utilize rclcpp::WaitSet as part of the executors (`#2142 `__) * Deprecate callback_group call taking context * Add base executor objects that can be used by implementors * Template common operations * Address reviewer feedback: * Add callback to EntitiesCollector constructor * Make function to check automatically added callback groups take a list * Lint * Address reviewer feedback and fix templates * Lint and docs * Make executor own the notify waitable * Add pending queue to collector, remove from waitable Also change node's get_guard_condition to return shared_ptr * Change interrupt guard condition to shared_ptr Check if guard condition is valid before adding it to the waitable * Lint and docs * Utilize rclcpp::WaitSet as part of the executors * Don't exchange atomic twice * Fix add_node and add more tests * Make get_notify_guard_condition follow API tick-tock * Improve callback group tick-tocking * Don't lock twice * Address reviewer feedback * Add thread safety annotations and make locks consistent * @wip * Reset callback groups for multithreaded executor * Avoid many small function calls when building executables * Re-trigger guard condition if buffer has data * Address reviewer feedback * Trace points * Remove tracepoints * Reducing diff * Reduce diff * Uncrustify * Restore tests * Back to weak_ptr and reduce test time * reduce diff and lint * Restore static single threaded tests that weren't working before * Restore more tests * Fix multithreaded test * Fix assert * Fix constructor test * Change ready_executables signature back * Don't enforce removing callback groups before nodes * Remove the "add_valid_node" API * Only notify if the trigger condition is valid * Only trigger if valid and needed * Fix spin_some/spin_all implementation * Restore single threaded executor * Picking ABI-incompatible executor changes * Add PIMPL * Additional waitset prune * Fix bad merge * Expand test timeout * Introduce method to clear expired entities from a collection * Make sure to call remove_expired_entities(). * Prune queued work when callback group is removed * Prune subscriptions from dynamic storage * Styles fixes. * Re-trigger guard conditions * Condense to just use watiable.take_data * Lint * Address reviewer comments (nits) * Lock mutex when copying * Refactors to static single threaded based on reviewers * More small refactoring * Lint * Lint * Add ready executable accessors to WaitResult * Make use of accessors from wait_set * Fix tests * Fix more tests * Tidy up single threaded executor implementation * Don't null out timer, rely on call * change how timers are checked from wait result in executors * peak -> peek * fix bug in next_waitable logic * fix bug in StaticSTE that broke the add callback groups to executor tests * style --------- Co-authored-by: Chris Lalancette Co-authored-by: William Woodall +* fix flakiness in TestTimersManager unit-test (`#2468 `__) the previous version of the test was relying on the assumption that a timer with 1ms period gets called at least 6 times if the main thread waits 15ms. this is true most of the times, but it's not guaranteed, especially when running the test on windows CI servers. the new version of the test makes no assumptions on how much time it takes for the timers manager to invoke the timers, but rather focuses on ensuring that they are called the right amount of times, which is what's important for the purpose of the test +* fix spin_some_max_duration unit-test for events-executor (`#2465 `__) +* refactor and improve the parameterized spin_some tests for executors (`#2460 `__) * refactor and improve the spin_some parameterized tests for executors * disable spin_some_max_duration for the StaticSingleThreadedExecutor and EventsExecutor * fixup and clarify the docstring for Executor::spin_some() * style * review comments --------- +* enable simulation clock for timer canceling test. (`#2458 `__) * enable simulation clock for timer canceling test. * move MainExecutorTypes to test_executors_timer_cancel_behavior.cpp. --------- +* Revert "relax the test simulation rate for timer canceling tests. (`#2453 `__)" (`#2456 `__) This reverts commit 1c350d0d7fb9c7158e0a39057112486ddbd38e9a. +* relax the test simulation rate for timer canceling tests. (`#2453 `__) +* Fix TypeAdapted publishing with large messages. (`#2443 `__) Mostly by ensuring we aren't attempting to store large messages on the stack. Also add in tests. I verified that before these changes, the tests failed, while after them they succeed. +* Implement generic client (`#2358 `__) * Implement generic client * Fix the incorrect parameter declaration * Deleted copy constructor and assignment for FutureAndRequestId * Update codes after rebase * Address review comments * Address review comments from iuhilnehc-ynos * Correct an error in a description * Fix window build errors * Address review comments from William * Add doc strings to create_generic_client --------- +* Rule of five: implement move operators (`#2425 `__) +* Various cleanups to deal with uncrustify 0.78. (`#2439 `__) These should also work with uncrustify 0.72. +* Remove the set_deprecated signatures in any_subscription_callback. (`#2431 `__) These have been deprecated since April 2021, so it is safe to remove them now. +* fix doxygen syntax for NodeInterfaces (`#2428 `__) +* Set hints to find the python version we actually want. (`#2426 `__) The comment in the commit explains the reasoning behind it. +* Update quality declaration documents (`#2427 `__) +* feat: add/minus for msg::Time and rclcpp::Duration (`#2419 `__) * feat: add/minus for msg::Time and rclcpp::Duration +* Split test_executors up into smaller chunks. (`#2421 `__) +* [events executor] - Fix Behavior with Timer Cancel (`#2375 `__) +* Removed deprecated header (`#2413 `__) +* Make sure to mark RingBuffer methods as 'override'. (`#2410 `__) +* Increase the cppcheck timeout to 600 seconds. (`#2409 `__) +* Add transient local durability support to publisher and subscriptions when using intra-process communication (`#2303 `__) +* Stop storing the context in the guard condition. (`#2400 `__) +* Updated GenericSubscription to AnySubscriptionCallback (`#1928 `__) +* make type support helper supported for service (`#2209 `__) +* Adding QoS to subscription options (`#2323 `__) +* Switch to target_link_libraries. (`#2374 `__) +* aligh with rcl that a rosout publisher of a node might not exist (`#2357 `__) +* Fix data race in EventHandlerBase (`#2349 `__) +* Support users holding onto shared pointers in the message memory pool (`#2336 `__) +* fix (signal_handler.hpp): spelling (`#2356 `__) +* Updates to not use std::move in some places. (`#2353 `__) +* rclcpp::Time::max() clock type support. (`#2352 `__) +* Serialized Messages with Topic Statistics (`#2274 `__) +* Add a custom deleter when constructing rcl_service_t (`#2351 `__) +* Disable the loaned messages inside the executor. (`#2335 `__) +* Use message_info in SubscriptionTopicStatistics instead of typed message (`#2337 `__) +* Add missing 'enable_rosout' comments (`#2345 `__) +* Adjust rclcpp usage of type description service (`#2344 `__) +* address rate related flaky tests. (`#2329 `__) +* Fixes pointed out by the clang analyzer. (`#2339 `__) +* Remove useless ROSRate class (`#2326 `__) +* add clients & services count (`#2072 `__) +* remove invalid sized allocation test for SerializedMessage. (`#2330 `__) +* Adding API to copy all parameters from one node to another (`#2304 `__) +* Add locking to protect the TimeSource::NodeState::node_base\_ (`#2320 `__) +* Update SignalHandler get_global_signal_handler to avoid complex types in static memory (`#2316 `__) +* Removing Old Connext Tests (`#2313 `__) +* Documentation for list_parameters (`#2315 `__) +* Decouple rosout publisher init from node init. (`#2174 `__) +* fix the depth to relative in list_parameters (`#2300 `__) +* Fix the return type of Rate::period. (`#2301 `__) +* Update API docs links in package READMEs (`#2302 `__) +* Cleanup flaky timers_manager tests. (`#2299 `__) +* Topic correct typeadapter deduction (`#2294 `__) +* Fix C++20 allocator construct deprecation (`#2292 `__) +* Make Rate to select the clock to work with (`#2123 `__) +* Correct the position of a comment. (`#2290 `__) +* Remove unnecessary lambda captures in the tests. (`#2289 `__) +* Add rcl_logging_interface as an explicit dependency. (`#2284 `__) +* Revamp list_parameters to be more efficient and easier to read. (`#2282 `__) +* Do not crash Executor when send_response fails due to client failure. (`#2276 `__) +* Adding Custom Unknown Type Error (`#2272 `__) +* Add a pimpl inside rclcpp::Node for future distro backports (`#2228 `__) +* Remove an unused variable from the events executor tests. (`#2270 `__) +* Add spin_all shortcut (`#2246 `__) +* Adding Missing Group Exceptions (`#2256 `__) +* Change associated clocks storage to unordered_set (`#2257 `__) +* associated clocks should be protected by mutex. (`#2255 `__) +* Instrument loaned message publication code path (`#2240 `__) +* Implement get_node_type_descriptions_interface for lifecyclenode and add smoke test for it (`#2237 `__) +* Add new node interface TypeDescriptionsInterface to provide GetTypeDescription service (`#2224 `__) +* Move always_false_v to detail namespace (`#2232 `__) +* Revamp the test_subscription.cpp tests. (`#2227 `__) +* warning: comparison of integer expressions of different signedness (`#2219 `__) +* Modifies timers API to select autostart state (`#2005 `__) +* Enable callback group tests for connextdds (`#2182 `__) +* Fix up misspellings of "receive". (`#2208 `__) +* Remove flaky stressAddRemoveNode test (`#2206 `__) +* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#2162 `__) +* remove nolint since ament_cpplint updated for the c++17 header (`#2198 `__) +* Feature/available capacity of ipm (`#2173 `__) +* add mutex to protect events_executor current entity collection (`#2187 `__) +* Declare rclcpp callbacks before the rcl entities (`#2024 `__) +* Fix race condition in events-executor (`#2177 `__) +* Add missing stdexcept include (`#2186 `__) +* Fix a format-security warning when building with clang (`#2171 `__) +* Fix delivered message kind (`#2175 `__) +* Contributors: AiVerisimilitude, Alberto Soragna, Alejandro Hernández Cordero, Alexey Merzlyakov, Barry Xu, Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, DensoADAS, Eloy Briceno, Emerson Knapp, Homalozoa X, HuaTsai, Jeffery Hsu, Jiaqi Li, Jonas Otto, Kotaro Yoshimoto, Lee, Luca Della Vedova, Lucas Wendland, Matt Condino, Michael Carroll, Michael Orlov, Minju, Nathan Wiebe Neufeldt, Steve Macenski, Tim Clephas, Tomoya Fujita, Tony Najjar, Tully Foote, William Woodall, Zard-C, h-suzuki-isp, jmachowinski, mauropasse, mergify[bot], methylDragon, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove references to index.ros.org. (`#2504 `__) +* Callback after cancel (`#2281 `__) * feat(Client): Added function to stop callbacks of a goal handle This function allows us to drop the handle in a locked context. If we do not do this within a lock, there will be a race condition between the deletion of the shared_ptr of the handle and the result / feedback callbacks. * fix: make Client goal handle recursive This fixes deadlocks due to release of goal handles in callbacks etc. * fix(ActionGoalClient): Fixed memory leak for nominal case This fixes a memory leak due to a self reference in the ClientGoalHandle. Note, this fix will only work, if the ClientGoalHandle ever receives a result callback. * doc: Updated documentation of rclcpp_action::Client::async_send_goal * docs: Made the async_send_goal documentation more explicit Co-authored-by: Janosch Machowinski +* Remake of "fix: Fixed race condition in action server between is_ready and take" (`#2495 `__) Some background information: is_ready, take_data and execute data may be called from different threads in any order. The code in the old state expected them to be called in series, without interruption. This lead to multiple race conditions, as the state of the pimpl objects was altered by the three functions in a non thread safe way. Co-authored-by: Janosch Machowinski +* update rclcpp::Waitable API to use references and const (`#2467 `__) +* Do not generate the exception when action service response timeout. (`#2464 `__) * Do not generate the exception when action service response timeout. * address review comment. --------- +* Modify rclcpp_action::GoalUUID hashing algorithm (`#2441 `__) * Add unit tests for hashing rclcpp_action::GoalUUID's * Use the FNV-1a hash algorithm for Goal UUID +* Various cleanups to deal with uncrustify 0.78. (`#2439 `__) These should also work with uncrustify 0.72. +* Update quality declaration documents (`#2427 `__) +* Switch to target_link_libraries. (`#2374 `__) +* Update API docs links in package READMEs (`#2302 `__) +* fix(ClientGoalHandle): Made mutex recursive to prevent deadlocks (`#2267 `__) +* Correct the position of a comment. (`#2290 `__) +* Fix a typo in a comment. (`#2283 `__) +* doc fix: call ``canceled`` only after goal state is in canceling. (`#2266 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Jiaqi Li, Tomoya Fujita, William Woodall, jmachowinski, mauropasse + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_components `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove references to index.ros.org. (`#2504 `__) +* Add EXECUTOR docs (`#2440 `__) +* Update quality declaration documents (`#2427 `__) +* crash on no class found (`#2415 `__) * crash on no class found * error on no class found instead of no callback groups Co-authored-by: Chris Lalancette +* Switch to target_link_libraries. (`#2374 `__) +* feat(rclcpp_components): support events executor in node main template (`#2366 `__) +* fix(rclcpp_components): increase the service queue sizes in component_container (`#2363 `__) +* Add missing header required by the rclcpp::NodeOptions type (`#2324 `__) +* Update API docs links in package READMEs (`#2302 `__) +* Contributors: Adam Aposhian, Chris Lalancette, Christophe Bedard, Daisuke Nishimatsu, Ignacio Vizzo, M. Fatih Cırıt, Ruddick Lawrence + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "call shutdown in LifecycleNode dtor to avoid leaving the device in un… (`#2450 `__)" (`#2522 `__) (`#2524 `__) This reverts commit 04ea0bb00293387791522590b7347a2282cda290. (cherry picked from commit 42b0b5775b4e68718c5949308c9e1a059930ded7) Co-authored-by: Chris Lalancette +* Remove references to index.ros.org. (`#2504 `__) +* call shutdown in LifecycleNode dtor to avoid leaving the device in un… (`#2450 `__) * call shutdown in LifecycleNode dtor to avoid leaving the device in unknown state. * add test to verify LifecycleNode::shutdown is called on destructor. --------- +* Update quality declaration documents (`#2427 `__) +* Increase timeout for rclcpp_lifecycle to 360 (`#2395 `__) +* Fix rclcpp_lifecycle inclusion on Windows. (`#2331 `__) +* add clients & services count (`#2072 `__) +* Update API docs links in package READMEs (`#2302 `__) +* add logger level service to lifecycle node. (`#2277 `__) +* Stop using constref signature of benchmark DoNotOptimize. (`#2238 `__) +* Implement get_node_type_descriptions_interface for lifecyclenode and add smoke test for it (`#2237 `__) +* Switch lifecycle to use the RCLCPP macros. (`#2233 `__) +* Add new node interface TypeDescriptionsInterface to provide GetTypeDescription service (`#2224 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Emerson Knapp, Jorge Perez, Lee, Minju, Tomoya Fujita, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clock.py types. (`#1244 `__) * Start typing time.py * Testing out Enum wrapper for ClockType * convert to rcl_clock_type_t * Update create_time_point * add types to logging_service * Add types to duration.py * Add newlines for class definintions * update type alias name * Update to use Protocols * Add types to time.py * Add types * Fix import order * Started typing clock.py * Move typealias import +* pybind11 definition doc typo fixes. (`#1270 `__) +* Fix small flake8 error in rclpy. (`#1267 `__) Newer versions of flake8 complain that using 'str' as a variable shadows a builtin. Just make it 's'. +* Allow specifying qos (`#1225 `__) +* update RCL_RET_TIMEOUT error handling with action service response. (`#1258 `__) +* Add types to time_source.py (`#1259 `__) +* Small fixes for modern flake8. (`#1264 `__) +* Add types to qos_overriding_options.py (`#1248 `__) +* Add types to context.py (`#1240 `__) +* Add back Type hash __slots_\_ and add test cases. (`#1245 `__) +* Revert "Add types to TypeHash and moved away from __slots_\_ usage (`#1232 `__)" (`#1243 `__) +* Time.py Types (`#1237 `__) +* Add types to TypeHash and moved away from __slots_\_ usage (`#1232 `__) +* Add Static Typing to Validate files (`#1230 `__) +* Add types to duration.py (`#1233 `__) +* added python3-yaml (`#1242 `__) +* Add types to exceptions.py (`#1241 `__) +* Add types (`#1231 `__) +* Creates Enum wrapper for ClockType and ClockChange (`#1235 `__) +* Add types to expand_topic_name (`#1238 `__) +* Add types to logging_service.py (`#1227 `__) +* Add types to logging.py (`#1226 `__) +* forbid parameter to be declared statically without initialization. (`#1216 `__) +* Remove parentheses from assert statements. (`#1213 `__) +* Add doc-string warnings for destroy methods for services. (`#1205 `__) +* Add doc-string warnings for destroy() methods (`#1204 `__) +* Add an optional timeout_sec input to Client.call() to fix issue https://github.com/ros2/rclpy/issues/1181 (`#1188 `__) +* aligh with rcl that a rosout publisher of a node might not exist (`#1196 `__) +* call ok() to see if rclpy and context is initialized. (`#1198 `__) +* Adjust python usage of the type_description service API (`#1192 `__) +* Document that spin_once() should not be called from multiple threads (`#1079 `__) +* making optional things Optional (`#1182 `__) +* Use timeout object to avoid callback losing in wait_for_ready_callbacks (`#1165 `__) +* Fix to issue https://github.com/ros2/rclpy/issues/1179 (`#1180 `__) +* Add count services, clients & test (`#1024 `__) +* 1105 parameter event handler (`#1135 `__) +* unregister_sigterm_signal_handler should be called. (`#1170 `__) +* Handle take failure in wait_for_message (`#1172 `__) +* Decouple rosout publisher init from node init. (`#1121 `__) +* Fix _list_parameters_callback & test (`#1161 `__) +* add list_parameters & test (`#1124 `__) +* Support to get remapped service name (`#1156 `__) +* a couple of typo fixes. (`#1158 `__) +* Fix get_type_description service bug and add a unit test (`#1155 `__) +* Fix an inherent race in execution vs. destruction. (`#1150 `__) +* Cleanup of test_node.py. (`#1153 `__) +* Avoid generating the exception when rcl_send_response times out. (`#1136 `__) +* Store time source clocks in a set (`#1146 `__) +* Fix spin_once_until_future_complete to quit when the future finishes. (`#1143 `__) +* get_type_description service (`#1139 `__) +* Add in the ability to start timers paused. (`#1138 `__) +* Modifies ros_timer_init for ros_timer_init2 (`#999 `__) +* Fix/param namespace association 894 (`#1132 `__) +* Include type hash in topic endpoint info (`#1104 `__) +* Fix iteration over modified list (`#1129 `__) +* making optional things Optional (`#974 `__) +* Fix type signature of Client.wait_for_service (`#1128 `__) +* Fix action server crash when the client goes away. (`#1114 `__) +* Turn Executor into a ContextManager (`#1118 `__) +* Turn Context into a ContextManager (`#1117 `__) +* Fix type in Node init args (`#1115 `__) +* Contributors: AndyZe, Anton Kesy, Barry Xu, Brian, Chen Lihui, Chris Lalancette, Eloy Briceno, Emerson Knapp, EsipovPA, Felix Divo, Hans-Joachim Krauch, KKSTB, Lee, Luca Della Vedova, M. Hofstätter, Michael Carlstrom, Michael Carroll, Minju, Russ, SnIcK, Steve Peters, Tim Clephas, Tomoya Fujita, mhidalgo-bdai + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcpputils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Generate version header with ament_generate_version_header function (`#190 `__) +* Update docs for rcpputils::split functions (`#188 `__) +* Included tl_expected (`#185 `__) +* Switch to using target_link_libraries. (`#183 `__) +* Add a missing header due to missing PATH_MAX variable (`#181 `__) +* Add unique_lock implementation with clang thread safety annotations (`#180 `__) +* Add in a missing cstdint. (`#178 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Emerson Knapp, Sai Kishor Kothakota, wojciechmadry + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed warnings - strict-prototypes (`#461 `__) (`#465 `__) +* Increase timeout repl_str test (`#463 `__) (`#464 `__) +* validate the allocator before use. (`#455 `__) * validate the allocator before use. * address review comments. - validate allocator only if the function specifically uses. - argument null check comes before validation of value. --------- +* feat: Add human readable date to logging formats (`#441 `__) +* Updates for uncrustify 0.78. (`#454 `__) +* Set hints to find the python version we actually want. (`#451 `__) +* Bring ament_add_gtest/target_link_libraries back together (`#452 `__) +* Change 'ROS2' to 'ROS 2' in quality declaration (`#453 `__) +* Allow parsing of escape sequence in log format (`#443 `__) +* Clean up unused references to mimick/mocking in tests (`#450 `__) +* Fix if(TARGET ...) condition for test (`#447 `__) +* Zero-initialize rcutils_string_array_t in test_string_array (`#446 `__) +* Use rcutils_string_array_init in rcutils_split & handle alloc fail (`#445 `__) +* Make rcutils_split() return RCUTILS_RET_BAD_ALLOC if alloc fails (`#444 `__) +* Remove two last uses of ament_target_dependencies. (`#440 `__) +* time_win32: Update dead link (`#438 `__) +* memmove for overlaping memory (`#434 `__) +* make escape characters work (`#426 `__) +* Remove unused 'max' functions from sha256.c (`#429 `__) +* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Kaju-Bubanja, Marc Bestmann, Silvio Traversaro, Tomoya Fujita, Tyler Weaver, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`resource_retriever `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update resource retreiver to use rule of five (`#95 `__) +* Use default ament_lint_auto (`#92 `__) +* Switch to target_link_libraries. (`#89 `__) +* Update to C++17 (`#88 `__) +* Contributors: Chris Lalancette, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed warnings - strict-prototypes (`#365 `__) (`#366 `__) +* Switch to target_link_libraries. (`#361 `__) +* Remove unnecessary c++14 flag. (`#360 `__) +* definition of local means being in the same context. (`#359 `__) +* typo fix. (`#355 `__) +* Contributors: Chris Lalancette, Tomoya Fujita, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add rmw count clients services impl (`#93 `__) +* Cleanup context implementation (`#131 `__) +* Update to C++17 (`#125 `__) +* Contributors: Chris Lalancette, Lee, Minju + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Mitigate discovery race condition between clients and services (`#132 `__)" (`#146 `__) This reverts commit 7c95abbfc4559b293ebf5e94e20250bdd99d3ac6. +* Mitigate discovery race condition between clients and services (`#132 `__) * Mitigate discovery race condition between clients and services. +* Add: tracepoint for subscribe serialized_message (`#145 `__) * Add: tracepoint for take_serialized_message * Fix: TRACETOOLS_TRACEPOINT args * Update rmw_connextdds_common/src/common/rmw_subscription.cpp Co-authored-by: Christophe Bedard +* Support Fast CDR v2 (`#141 `__) +* Fix the rmw_connextdds_common build with gcc 13.2. (`#142 `__) The most important fix here is to #include , but also make sure we #include for all used STL functions. +* Fix basic request reply mapping for ConnextDDS Pro (`#139 `__) +* Add ros2_tracing tracepoints (`#120 `__) +* avoid using dds common public mutex directly (`#134 `__) +* Fix a couple of warnings pointed out by clang. (`#133 `__) +* Add rmw count clients services impl (`#93 `__) +* Conditional internal API access to support Connext 7+ (`#121 `__) +* Cleanup context implementation (`#131 `__) +* Fix RMW_Connext_Client::is_service_available for micro (`#130 `__) +* Update to C++17 (`#125 `__) +* Pass parameters in the correct order to DDS_DataReader_read in rmw_connextdds_count_unread_samples for micro (`#129 `__) +* Optimize QoS to improve responsiveness of reliable endpoints (`#26 `__) +* Clear out errors once we have handled them. (`#126 `__) +* Add support for listener callbacks (`#76 `__) +* Contributors: Andrea Sorbini, Chen Lihui, Chris Lalancette, Christopher Wecht, Lee, Miguel Company, Minju, h-suzuki-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextddsmicro `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add rmw count clients services impl (`#93 `__) +* Cleanup context implementation (`#131 `__) +* Update to C++17 (`#125 `__) +* Contributors: Chris Lalancette, Lee, Minju + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_cyclonedds_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set received_timestamp to system_clock::now() in message_info (`#491 `__) (`#493 `__) * Set received_timestamp to steady_clock::now() in message_info * Use 'system_clock' instead of 'steady_clock' * Also update receive_timestamp for services. (cherry picked from commit 76c9d8f38a03d160b258902af6d1d06f6ed9391e) Co-authored-by: Michael Orlov +* Add tracepoint for publish/subscribe serialized message (`#485 `__) Co-authored-by: eboasson +* Remove a bunch of unnecessary macros. (`#482 `__) +* compare string contents but string pointer addresses. (`#481 `__) +* Add timestamp to rmw_publish tracepoint (`#454 `__) +* avoid using dds common public mutex directly (`#474 `__) +* Add rmw count clients,services impl (`#427 `__) +* Minor revamp of the CMakeLists.txt. (`#468 `__) +* Clear out errors once we have handled them. (`#464 `__) +* Instrument loaned message publication code path +* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#450 `__) +* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, Lee, Minju, Tomoya Fujita, h-suzuki-isp, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_dds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add pkcs11 support to get_security_files (`#66 `__) +* make a new private mutex and add updating graph methods (`#73 `__) +* Just remove rcpputils::fs dependency (`#72 `__) +* Contributors: Chen Lihui, Kenta Yonekura, Miguel Company + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support Fast CDR v2 (`#746 `__) * Require fastcdr version 2 * Changes to build rmw_fastrtps_shared_cpp * Changes to build rmw_fastrtps_cpp * Changes to build rmw_fastrtps_dynamic_cpp +* Capture ``std::bad_alloc`` on deserializeROSmessage. (`#665 `__) +* Switch to target_link_libraries for linking. (`#734 `__) +* avoid using dds common public mutex directly (`#725 `__) +* Add rmw_count clients,services impl (`#641 `__) +* Improve node graph delivery by using a unique listening port (`#711 `__) +* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#686 `__) +* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Lee, Miguel Company, Minju + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_dynamic_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support Fast CDR v2 (`#746 `__) * Require fastcdr version 2 * Changes to build rmw_fastrtps_shared_cpp * Changes to build rmw_fastrtps_cpp * Changes to build rmw_fastrtps_dynamic_cpp +* compare string contents but string pointer addresses. (`#744 `__) +* Improve wide string (de)serialization in rwm_dynamic_fastrtps_cpp (`#740 `__) * Move type support headers to src * Fix references to moved headers * move macros.hpp to src/serialization_helpers.hpp * Move other non-api headers * Move common code into serialize_wide_string. * Move common code into deserialize_wide_string. * Move serialization into serialization_helpers.hpp * Move deserialization into serialization_helpers.hpp * Fix header guards * Linters * Do not account for extra character on serialized size calculation * Remove dependency on rosidl_typesupport_fastrtps_c(pp) --------- +* Capture ``std::bad_alloc`` on deserializeROSmessage. (`#665 `__) +* Switch to target_link_libraries for linking. (`#734 `__) +* avoid using dds common public mutex directly (`#725 `__) +* Account for alignment on is_plain calculations. (`#716 `__) +* Add rmw_count clients,services impl (`#641 `__) +* Improve node graph delivery by using a unique listening port (`#711 `__) +* Contributors: Chen Lihui, Chris Lalancette, Lee, Miguel Company, Minju, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_shared_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow pkcs11 when calling rmw_dds_common::get_security_files. (`#565 `__) Co-authored-by: Miguel Company +* Add tracepoint for publish/subscribe serialized_message (`#748 `__) * Add: tracepoint for generic pub/sub * Fix: correspond to PR 454 * Fix: change write to write_to_timestamp --------- +* Support Fast CDR v2 (`#746 `__) * Require fastcdr version 2 * Changes to build rmw_fastrtps_shared_cpp * Changes to build rmw_fastrtps_cpp * Changes to build rmw_fastrtps_dynamic_cpp +* Remove an unnecessary constructor. (`#743 `__) We can just use brace initialization here, and this allows us to side-step an uncrustify issue with the constructor. +* Add timestamp to rmw_publish tracepoint (`#694 `__) +* Switch to Unix line endings. (`#736 `__) +* Switch to target_link_libraries for linking. (`#734 `__) +* Quiet compiler warning in Release mode. (`#730 `__) +* avoid using dds common public mutex directly (`#725 `__) +* Add rmw_count clients,services impl (`#641 `__) +* Switch to using rclcpp::unique_lock. (`#712 `__) +* Use DataWriter Qos to configure max_blocking_time on rmw_send_response (`#704 `__) +* Clear out errors once we have handled them. (`#701 `__) +* Instrument loaned message publication code path (`#698 `__) +* Add in a missing data_reader check when creating subscription. (`#697 `__) +* Use TRACETOOLS\_ prefix for tracepoint-related macros (`#686 `__) +* typo fix. (`#693 `__) +* address clang nightly build error. (`#689 `__) +* Check for errors while doing an rmw_discovery_options_copy. (`#690 `__) +* Contributors: Chen Lihui, Chris Lalancette, Christophe Bedard, Christopher Wecht, IkerLuengo, Lee, Miguel Company, Minju, Tomoya Fujita, h-suzuki-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update quality declaration document (`#225 `__) (`#226 `__) +* Switch to using target_link_libraries everywhere. (`#222 `__) +* Add rmw_count_clients,services & test (`#208 `__) +* Contributors: Chris Lalancette, Lee, Minju, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`robot_state_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix reload after a description with a mimic joint (`#212 `__) +* Remove ament_target_dependencies. (`#209 `__) +* Improve log messages (`#206 `__) +* Contributors: Chris Lalancette, Guillaume Doisy, Nick Lamprianidis + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* call get_action_interfaces() properly. (`#898 `__) (`#900 `__) (cherry picked from commit 305ef763b83e42ebddc4802ac788869d178b6e93) Co-authored-by: Tomoya Fujita +* support ``ros2 action type ``. (`#894 `__) * support ``ros2 action type ``. * add review comments. --------- +* Load a message/request/goal from standard input (`#844 `__) +* Contributors: Tomoya Fujita, mergify[bot], ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add option to disable recorder keyboard controls (`#1607 `__) +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Added exclude-topic-types to record (`#1582 `__) +* Overhaul in the rosbag2_transport::TopicFilter class and relevant tests (`#1585 `__) +* Filter topic by type (`#1577 `__) +* Implement service recording and display info about recorded services (`#1480 `__) +* Add python3-yaml as a dependency (`#1490 `__) +* Fix the description of paramter '--topics' for play (`#1426 `__) +* When using sim time, wait for /clock before beginning recording (`#1378 `__) +* Revert "Don't record sim-time messages before first /clock (`#1354 `__)" (`#1377 `__) +* Don't record sim-time messages before first /clock (`#1354 `__) +* Fix wrong descritpion for '--ignore-leaf-topics' (`#1344 `__) +* Cleanup the help text for ros2 bag record. (`#1329 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Bernd Pfrommer, Chris Lalancette, Emerson Knapp, Michael Orlov, Michal Sojka + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ros2cli.node.daemon : try getting fdsize from /proc for open fd limit (`#888 `__) +* Fix the SIGTERM handling in the ros2 daemon. (`#887 `__) +* Replace unmaintained ``netifaces`` library to avoid local wheel builds (`#875 `__) +* make handles not inheritable to prevent from blocking durning tab-completion (`#852 `__) +* Add ros2 service info (`#771 `__) +* catch ExternalShutdownException ros2cli main. (`#854 `__) +* Load a message/request/goal from standard input (`#844 `__) +* Fix tests with get_type_description service and param present (`#838 `__) +* Add marshalling functions for rclpy.type_hash.TypeHash (rep2011) (`#816 `__) +* [service introspection] ros2 service echo (`#745 `__) +* Contributors: Brian, Chen Lihui, Chris Lalancette, Emerson Knapp, Hans-Joachim Krauch, Laurenz, Lee, Minju, Tomoya Fujita, akssri-sony, ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli_test_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17 (`#848 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2component `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Warning: get_parameter_value() is deprecated. (`#866 `__) +* Contributors: Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2doctor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove references to https://index.ros.org (`#897 `__) +* (ros2doctor) fix PackageCheck (`#860 `__) * (ros2doctor)(package) improve result string generation +* Shutdown ros2doctor hello when ctrl-c is received (`#826 `__) +* Contributors: Chris Lalancette, Matthijs van der Burgh, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2interface `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add interface type filters to ros2 interface package (`#765 `__) +* Contributors: David V. Lu!! + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2param `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ros2 param dump should handle empty list as exception. (`#881 `__) +* Warning: get_parameter_value() is deprecated. (`#866 `__) +* Fix tests with get_type_description service and param present (`#838 `__) +* Update ros2 param dump dosctring. (`#837 `__) +* Contributors: Emerson Knapp, Murilo M Marinho, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2pkg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update the package template for our new include directories. (`#847 `__) +* Fix typo in ros2pkg warning message. (`#827 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ros2 service info (`#771 `__) +* Load a message/request/goal from standard input (`#844 `__) +* Fix tests with get_type_description service and param present (`#838 `__) +* [service introspection] ros2 service echo (`#745 `__) +* Contributors: Brian, Emerson Knapp, Lee, Minju, ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove parentheses from assert statement. (`#878 `__) +* Load a message/request/goal from standard input (`#844 `__) +* Add marshalling functions for rclpy.type_hash.TypeHash (rep2011) (`#816 `__) +* [service introspection] ros2 service echo (`#745 `__) +* Contributors: Brian, Chris Lalancette, Hans-Joachim Krauch, ymd-stella + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Create start/pause/resume/stop sub-commands for 'ros2 trace' (`#70 `__) +* Switch to in pure Python packages (`#67 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Use std::filesystem instead of rcpputils::fs (`#1576 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Add default initialization for CompressionOptions (`#1539 `__) +* Add option to set compression threads priority (`#1457 `__) +* Fixes pointed out by clang. (`#1493 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* Add in a missing cstdint include. (`#1321 `__) +* Fix warning from ClassLoader in sequential compression reader and writer (`#1299 `__) +* Contributors: Arne B, Chris Lalancette, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression_zstd `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use std::filesystem instead of rcpputils::fs (`#1576 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Contributors: Chris Lalancette, Roman Sokolkov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Update to use yaml-cpp version 0.8.0. (`#1605 `__) +* Use std::filesystem instead of rcpputils::fs (`#1576 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* call cv.wait_until only if necessary. (`#1521 `__) +* Implement service recording and display info about recorded services (`#1480 `__) +* Switch to target_link_libraries everywhere. (`#1504 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* ros2 bag convert now excludes messages not in [start_time;end_time] (`#1455 `__) +* Replace TSAUniqueLock implementation with rcpputils::unique_lock (`#1454 `__) +* Add BagSplitInfo service call on bag close (`#1422 `__) +* Rewrite TimeControllerClockTest.unpaused_sleep_returns_true to be correct (`#1384 `__) +* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) +* Don't crash when type definition cannot be found (`#1350 `__) +* Add recorder stop() API (`#1300 `__) +* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Peter Favrholdt, Roman Sokolkov, Tomoya Fujita, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_examples_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* Contributors: Michael Orlov, Patrick Roncagliolo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_examples_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Fix a warning from python setuptools. (`#1312 `__) +* Contributors: Chris Lalancette, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add node name to the Read(Write)SplitEvent message (`#1609 `__) +* Contributors: Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_performance_benchmarking `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Update to use yaml-cpp version 0.8.0. (`#1605 `__) +* Add option to set compression threads priority (`#1457 `__) +* Add per group statistics for rosbag2_performance_benchmarking report (`#1306 `__) +* Set CPU affinity for producers and recorder from benchmark parameters (`#1305 `__) +* Add CPU usage to rosbag2_performance_benchmarking results report (`#1304 `__) +* Add config option to use storage_id parameter in benchmark_launch.py (`#1303 `__) +* Contributors: Chris Lalancette, Michael Orlov, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add option to disable recorder keyboard controls (`#1607 `__) +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Switch rclpy to be an exec_depend here. (`#1606 `__) +* Gracefully handle SIGINT and SIGTERM signals for play and burst CLI (`#1557 `__) +* Added exclude-topic-types to record (`#1582 `__) +* Fix for false negative tests in rosbag2_py (`#1592 `__) +* Update rosbag2_py stubs (`#1593 `__) +* Add Python stubs for rosbag2_py (`#1459 `__) (`#1569 `__) +* Filter topic by type (`#1577 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Install signal handlers in recorder only inside record method (`#1464 `__) +* add missing import otherwise it doesnt compile (`#1524 `__) +* Implement service recording and display info about recorded services (`#1480 `__) +* Make ``rosbag2_transport::Player::play()`` run in a separate thread (`#1503 `__) +* Switch to target_link_libraries everywhere. (`#1504 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* ros2 bag convert now excludes messages not in [start_time;end_time] (`#1455 `__) +* Add support for compression to python API (`#1425 `__) +* Gracefully handle SIGINT and SIGTERM in rosbag2 recorder (`#1301 `__) +* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) +* Add binding to close the writer (`#1339 `__) +* Contributors: Alejandro Hernández Cordero, Andrew Symington, Barry Xu, Bernd Pfrommer, Chris Lalancette, Emerson Knapp, Michael Orlov, Mikael Arguedas, Patrick Roncagliolo, Peter Favrholdt, Roman Sokolkov, Yadu, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Update to use yaml-cpp version 0.8.0. (`#1605 `__) +* Use std::filesystem instead of rcpputils::fs (`#1576 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Remove rcpputils::fs dependencies from rosbag2_storages (`#1558 `__) +* Improve performance in SqliteStorage::get_bagfile_size() (`#1516 `__) +* Make Player and Recorder Composable (`#902 `__) (`#1419 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* ros2 bag convert now excludes messages not in [start_time;end_time] (`#1455 `__) +* Fix missing cstdint include (`#1383 `__) +* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) +* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Peter Favrholdt, Roman Sokolkov, Zac Stanton, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_mcap `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Update to use yaml-cpp version 0.8.0. (`#1605 `__) +* Check existence of a file before passing it to the mcap reader (`#1594 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Use rw_lock to protect mcap metadata lists. (`#1561 `__) +* Remove rcpputils::fs dependencies from rosbag2_storages (`#1558 `__) +* remove unused headers (`#1544 `__) +* Link and compile against rosbag2_storage_mcap: Fixed issue 1492 (`#1496 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* Store serialized metadata in MCAP file (`#1423 `__) +* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christopher Wecht, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, Tomoya Fujita, jmachowinski, uupks + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_sqlite3 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Update to use yaml-cpp version 0.8.0. (`#1605 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Remove rcpputils::fs dependencies from rosbag2_storages (`#1558 `__) +* Change an incorrect TSA annotation. (`#1552 `__) +* Improve performance in SqliteStorage::get_bagfile_size() (`#1516 `__) +* Update rosbag2_storage_sqlite3 to C++17. (`#1501 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* Stop inheriting from std::iterator. (`#1424 `__) +* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) +* Store metadata in db3 file (`#1294 `__) +* Contributors: Barry Xu, Chris Lalancette, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Implement service recording and display info about recorded services (`#1480 `__) +* Add extra checks in execute_and_wait_until_completion(..) (`#1346 `__) +* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) +* Contributors: Barry Xu, Chris Lalancette, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_msgdefs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Implement service recording and display info about recorded services (`#1480 `__) +* Don't crash when type definition cannot be found (`#1350 `__) * Don't fail when type definition cannot be found +* Contributors: Barry Xu, Emerson Knapp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Added exclude-topic-types to record (`#1582 `__) +* Use std::filesystem instead of rcpputils::fs (`#1576 `__) +* Filter topic by type (`#1577 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Improve performance in SqliteStorage::get_bagfile_size() (`#1516 `__) +* Implement service recording and display info about recorded services (`#1480 `__) +* Mark play_end_to_end test as xfail in Windows (`#1452 `__) +* Implement storing and loading ROS_DISTRO from metadata.yaml and mcap files (`#1241 `__) +* Address flakiness in rosbag2_play_end_to_end tests (`#1297 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Cristóbal Arroyo, Emerson Knapp, Michael Orlov, Roman Sokolkov, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed warnings - unqualified-std-cast-call (`#1618 `__) (`#1622 `__) +* Add node name to the Read(Write)SplitEvent message (`#1609 `__) +* Add option to disable recorder keyboard controls (`#1607 `__) +* Support service 2/2 --- rosbag2 service play (`#1481 `__) +* Use middleware send and receive timestamps from message_info during recording (`#1531 `__) +* Update to use yaml-cpp version 0.8.0. (`#1605 `__) +* Gracefully handle SIGINT and SIGTERM signals for play and burst CLI (`#1557 `__) +* Added exclude-topic-types to record (`#1582 `__) +* Use std::filesystem instead of rcpputils::fs (`#1576 `__) +* Add transactional state mutex for RecorderImpl class. (`#1547 `__) +* Overhaul in the rosbag2_transport::TopicFilter class and relevant tests (`#1585 `__) +* Filter topic by type (`#1577 `__) +* fix: use size_t instead of uint64_t in play_options YAML converter (`#1575 `__) +* Make some changes for newer versions of uncrustify. (`#1578 `__) +* Add topic_id returned by storage to the TopicMetadata (`#1538 `__) +* Workaround for flaky test_play_services running with fastrtps (`#1556 `__) +* Add proper message for --start-paused (`#1537 `__) +* ``Recording stopped`` prints only once. (`#1530 `__) +* Cleanup the rosbag2_transport tests (`#1518 `__) +* Implement service recording and display info about recorded services (`#1480 `__) +* Add option to set compression threads priority (`#1457 `__) +* Bugfix for incorrect playback rate changes when pressing buttons (`#1513 `__) +* Make Player and Recorder Composable (`#902 `__) (`#1419 `__) +* Clang fixes for the latest PlayerImpl code. (`#1507 `__) +* Make ``rosbag2_transport::Player::play()`` run in a separate thread (`#1503 `__) +* Switch to target_link_libraries everywhere. (`#1504 `__) +* Use enum values for offered_qos_profiles in code and string names in serialized metadata (`#1476 `__) +* Redesign Player class with PIMPL idiom (`#1447 `__) +* Don't warn for unknown types if topics are not selected (`#1466 `__) +* Remove unused concurrentqueue implementation. (`#1465 `__) +* Fix uninitialized value pointed out by clang static analysis. (`#1440 `__) +* Fix the build with rmw_fastrtps_dynamic. (`#1416 `__) +* Fix for rosbag2_transport::Recorder failures due to the unhandled exceptions (`#1382 `__) +* When using sim time, wait for /clock before beginning recording (`#1378 `__) +* Fix for possible freeze in Recorder::stop() (`#1381 `__) +* Revert "Don't record sim-time messages before first /clock (`#1354 `__)" (`#1377 `__) +* Don't record sim-time messages before first /clock (`#1354 `__) +* Fix a clang warning about uninitialized variable. (`#1370 `__) +* [bugfix] for parameters not passing to recorder's node from child component (`#1360 `__) +* Change subscriptions from GenericSubscripton to SubscriptionBase (`#1337 `__) +* Add recorder stop() API (`#1300 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Bernd Pfrommer, Chris Lalancette, Christoph Fröhlich, Daisuke Nishimatsu, Emerson Knapp, Michael Orlov, Patrick Roncagliolo, Roman Sokolkov, Tomoya Fujita, jmachowinski, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve deprecation notice of rosidl_target_interface to give a hint on how to update the code (`#788 `__) +* Add rosidl_find_package_idl helper function (`#754 `__) +* Remove unused splitting of .srv files in CMake (`#753 `__) +* Contributors: Alexis Paques, Mike Purvis, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_dynamic_typesupport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* uchar: fix conditional include/typedef (`#10 `__) +* uchar: use __has_include(..) on separate line (`#8 `__) +* Refactor the handling of nested types. (`#7 `__) +* Add C++ version check to char16 definition (`#3 `__) +* Contributors: Antonio Cuadros, Chris Lalancette, G.A. vd. Hoorn + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed warnings - strict-prototypes (`#800 `__) (`#802 `__) +* Set hints to find the python version we actually want. (`#785 `__) +* Add rosidl_find_package_idl helper function (`#754 `__) +* Fix IWYU for clangd in C and C++ (`#742 `__) +* Contributors: Alexis Paques, Chris Lalancette, Mike Purvis, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set hints to find the python version we actually want. (`#785 `__) +* Fix constant generation for C++ floats (`#772 `__) +* Add rosidl_find_package_idl helper function (`#754 `__) +* Fixed visibility control file added to wrong header list variable. (`#755 `__) +* Fix deprecation warnings for message constants (`#750 `__) +* Generate typesupport declarations for actions, messages and services (`#703 `__) +* Fix IWYU for clangd in C and C++ (`#742 `__) +* Contributors: Alexis Paques, Chris Lalancette, Emerson Knapp, Mike Purvis, Stefan Fabian + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_dds_idl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove unnecessary parentheses. (`#61 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert install of .so files into python path (`#211 `__) There seems that some regression might have happened after `#195 `__. When removing those 2 lines, we avoid to install the .so files in lib *and* python path. +* Prototype code for seeing if FindPython3 is usable for rosidl_python (`#140 `__) +* Add in a missing space. (`#203 `__) +* Install compiled libraries only to 'lib' (`#195 `__) +* Fix: Missing dependency that causes cmake error in downstream (resolves https://github.com/ros2/rosidl_python/issues/198) (`#199 `__) +* Contributors: Chris Lalancette, Isaac Saito, Matthias Schoepfer, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed warnings - strict-prototypes (`#800 `__) (`#802 `__) +* Increased the cpplint timeout to 300 seconds (`#797 `__) +* Fixes for modern uncrustify. (`#793 `__) +* Fix constant generation for C++ floats (`#772 `__) +* Fix same named types overriding typesources (`#759 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Emerson Knapp, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_type_description `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set hints to find the python version we actually want. (`#785 `__) +* Remove unnecessary parentheses. (`#783 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Adding interfaces to support ``@key`` annotation (`#796 `__) Co-authored-by: Mario Dominguez +* Small fix for newer flake8 compatibility. (`#792 `__) +* Remove unnecessary parentheses. (`#783 `__) +* Contributors: Chris Lalancette, Miguel Company + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove unnecessary parentheses. (`#783 `__) +* Fix same named types overriding typesources (`#759 `__) +* Contributors: Chris Lalancette, Emerson Knapp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries. (`#776 `__) +* Set the C++ version to 17. (`#761 `__) +* Mark _ in benchmark tests as unused. (`#741 `__) This helps clang static analysis. +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Suppress a warning around BoundedVector. (`#803 `__) (`#804 `__) The comment has more explanation, but in short GCC 13 has false positives around some warnings, so we suppress it for BoundedVector. (cherry picked from commit 858e76adb03edba00469b91d50dd5fe0dcb34236) Co-authored-by: Chris Lalancette +* Contributors: mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Some fixes for modern flake8. (`#25 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed warnings - strict-prototypes (`#155 `__) (`#156 `__) +* compare string contents but string pointer addresses. (`#153 `__) +* Set hints to find the python version we actually want. (`#150 `__) +* Don't override user provided compile definitions (`#145 `__) +* Contributors: Chris Lalancette, Emerson Knapp, Tomoya Fujita, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* compare string contents but string pointer addresses. (`#153 `__) +* Set hints to find the python version we actually want. (`#150 `__) +* Don't override user provided compile definitions (`#145 `__) +* Added C interfaces to obtain service and action type support. (`#143 `__) +* Contributors: Chris Lalancette, Emerson Knapp, Stefan Fabian, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Adding interfaces to support ``@key`` annotation (`#116 `__) Co-authored-by: Mario Dominguez +* Support Fast CDR v2 (`#114 `__) +* Improve wide string (de)serialization (`#113 `__) +* Set hints to find the python version we actually want. (`#112 `__) Co-authored-by: Michael Carroll +* Update to C++17 (`#111 `__) +* Account for alignment on ``is_plain`` calculations (`#108 `__) +* Contributors: Chris Lalancette, Miguel Company + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix how header template works to prevent double-inclusion (`#117 `__) Co-authored-by: Alejandro Hernández Cordero +* Adding interfaces to support ``@key`` annotation (`#116 `__) Co-authored-by: Mario Dominguez +* Support Fast CDR v2 (`#114 `__) +* Improve wide string (de)serialization (`#113 `__) +* Set hints to find the python version we actually want. (`#112 `__) Co-authored-by: Michael Carroll +* Update to C++17 (`#111 `__) +* Account for alignment on ``is_plain`` calculations (`#108 `__) +* Avoid redundant declarations in generated code for services and actions (`#102 `__) +* Contributors: Chris Lalancette, Emerson Knapp, Michael Carroll, Miguel Company + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed warnings - strict-prototypes (`#800 `__) (`#802 `__) +* Adding interfaces to support ``@key`` annotation (`#796 `__) Co-authored-by: Mario Dominguez +* Set hints to find the python version we actually want. (`#785 `__) +* Add rosidl_find_package_idl helper function (`#754 `__) +* update comment (`#757 `__) +* Contributors: Chen Lihui, Chris Lalancette, Miguel Company, Mike Purvis, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Adding interfaces to support ``@key`` annotation (`#796 `__) Co-authored-by: Mario Dominguez +* Set hints to find the python version we actually want. (`#785 `__) +* Switch to target_link_libraries. (`#776 `__) +* Add rosidl_find_package_idl helper function (`#754 `__) +* update comment (`#757 `__) +* Fix deprecation warnings for message constants (`#750 `__) +* Contributors: Chen Lihui, Chris Lalancette, Emerson Knapp, Miguel Company, Mike Purvis + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* One last uncrustify fix for newer uncrustify. (`#795 `__) +* Disable zero-variadic-macro-arguments warning when using clang. (`#768 `__) +* Fixed C++20 warning implicit capture of this in lambda (`#766 `__) +* Contributors: AiVerisimilitude, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Suppress uncrustify on long lines. (`#152 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rpyutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* correct the URL and f-strings format (`#11 `__) +* Contributors: Chen Lihui + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add a test dependency on pytest. (`#306 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in copyright tests to rqt_bag. (`#154 `__) +* Add a test dependency on pytest. (`#153 `__) +* Revert "Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (#… (`#151 `__) +* Update maintainer to myself. (`#150 `__) +* Update maintainer list in package.xml files (`#149 `__) +* Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (`#148 `__) +* [ros2] Enable Save (`#142 `__) +* Call close (`#141 `__) +* Use default storage id (`#139 `__) +* Contributors: Chris Lalancette, Michael Jeronimo, Yadu, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add a test dependency on pytest. (`#153 `__) +* Revert "Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (#… (`#151 `__) +* Update maintainer to myself. (`#150 `__) +* Update maintainer list in package.xml files (`#149 `__) +* Add a dependency on pytest to rqt_bag and rqt_bag_plugins. (`#148 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add a test dependency on pytest. (`#45 `__) +* Contributors: Arne Hitzmann, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_graph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#92 `__) +* Add a test dependency on python3-pytest. (`#91 `__) +* Refresh rosgraph when params checkbox is clicked (`#86 `__) +* Contributors: Chris Lalancette, Michael Jeronimo, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries. (`#297 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix an exception raised while press ctrl+c to exit (`#291 `__) +* Contributors: Chen Lihui + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_msg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in python3-pytest test dependency. (`#19 `__) +* Small cleanups to rqt_msg (`#16 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_plot `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in copyright tests to rqt_bag. (`#95 `__) +* Add a test dependency on pytest. (`#94 `__) +* Add in a pytest dependency for running tests. (`#92 `__) +* Fix regression from #87 (`#90 `__) +* Contributors: Chris Lalancette, Yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use raw strings for regular expressions. (`#44 `__) +* Switch maintainer to me. (`#43 `__) +* Update maintainer list in package.xml files (`#42 `__) +* Add in a test dependency on pytest. (`#41 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow to autocomplete namespaced topics (`#299 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in test dependency on pytest. (`#16 `__) +* Fix a crash in the rqt_py_console dialog box. (`#15 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_reconfigure `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly add a pytest test dependency. (`#141 `__) +* Remove unnecessary parentheses around if statements. (`#140 `__) +* Fixed executor conflict (`#126 `__) +* Add param filtering (`#128 `__) +* Fix handling of namespaces in the node tree (`#132 `__) +* Contributors: Aleksander Szymański, Chris Lalancette, Devarsi Rawal, Nick Lamprianidis + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_service_caller `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in a pytest test dependency. (`#28 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_shell `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change maintainer to clalancette. (`#21 `__) +* Add in pytest test dependency. (`#19 `__) +* Contributors: Chris Lalancette, Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_srv `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add explicit dependency to python3-pytest. (`#12 `__) +* Minor cleanups in rqt_srv for ROS 2 (`#9 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Small fix for modern flake8. (`#50 `__) +* Add explicit python3-pytest dependency. (`#48 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rti_connext_dds_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use unified approach for checking the existence of environment variables (`#105 `__) +* Contributors: Christopher Wecht + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rttest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17 (`#124 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add "R" key as shortcut for resetTime (`#1088 `__) +* Switch to target_link_libraries. (`#1098 `__) +* Contributors: Chris Lalancette, Paul Erik Frivold + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_assimp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed assimp warnings (`#1191 `__) (`#1192 `__) (cherry picked from commit e8dd485d19a35d3abba905020741973e613334e3) Co-authored-by: Alejandro Hernández Cordero +* Update the vendored package path. (`#1184 `__) Since we just updated to assimp 5.3, we also need to update the path we look for it. This should fix the build with clang which is currently failing. +* Update assimp vendor to 5.3.1 (`#1182 `__) This matches what is in Ubuntu 24.04. +* Update to assimp 5.2.2 (`#968 `__) +* Fix the vendoring flags for clang compilation. (`#1003 `__) +* Switch to ament_cmake_vendor_package (`#995 `__) +* Contributors: Chris Lalancette, Scott K Logan, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to yaml-cpp 0.8.0 (`#1183 `__) yaml-cpp 0.8.0 has a proper CMake target, i.e. yaml-cpp::yaml-cpp. Use that here. +* Remove regex_filter_property.hpp from the moc lines. (`#1172 `__) Since it has no SLOTS or SIGNALS, we don't need to run MOC on it. That will both speed up the compilation and remove a warning when building. +* Added regex filter field for TF display (`#1032 `__) +* Fix camera display overlay (`#1151 `__) +* Fixes for uncrustify 0.78. (`#1155 `__) Mostly what we do here is to disable the indentation on certain constructs that are different between 0.72 and 0.78. It isn't my preferred solution, but since it only affects a small amount of code (and most of that in macros), this seems acceptable to me. +* Append measured subscription frequency to topic status (`#1113 `__) +* Implement reset time service (`#1109 `__) +* Add "R" key as shortcut for resetTime (`#1088 `__) +* Add fullscreen startup option (`#1097 `__) +* Switch to target_link_libraries. (`#1098 `__) +* Initialize more of the visualization_manager members. (`#1090 `__) +* Explicit time conversions and comparisons (`#1087 `__) +* Rolling namespace in title (`#1074 `__) +* Removed unused code (`#1044 `__) +* Remove unused LineEditWithButton::simulateReturnPressed() (`#1040 `__) +* Remove warning in depth_cloud_mld.cpp (`#1021 `__) +* Added DepthCloud default plugin (`#996 `__) +* Stop inheriting from std::iterator. (`#1013 `__) In C++17, inheriting from std::iterator has been deprecated: https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated/ Here, switch away from inheriting and just define the interface ourselves (which is the current recommended best practice). This removes some warnings when building with gcc 13.1.1 +* use static QCoreApplication::processEvents() function without a QApplication instance (`#924 `__) +* Re-implemented setName for tools (`#989 `__) +* Add a libqt5-svg dependency to rviz_common. (`#992 `__) +* Remove onHelpWiki. (`#985 `__) +* Clean Code (`#975 `__) +* Contributors: AiVerisimilitude, Alejandro Hernández Cordero, Chris Lalancette, Felix Exner (fexner), Hyunseok, Markus Bader, Paul Erik Frivold, Yadu, Yannis Gerlach, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Make sure to export all rviz_default_plugins dependencies. (`#1181 `__) +* Increase the cpplint timeout to 180 seconds. (`#1179 `__) +* Switch to gz_math_vendor. (`#1177 `__) +* Fixed camera info warning (`#1175 `__) +* Added CameraInfo display (`#1166 `__) +* apply origin rotation to inertia box visualization (`#1171 `__) +* Added regex filter field for TF display (`#1032 `__) +* Added point_cloud_transport (`#1008 `__) +* Select QoS reliability policy in DepthCloud Plugin (`#1159 `__) +* Fixed crash on DepthCloud plugin (`#1161 `__) +* Fixes for uncrustify 0.78. (`#1155 `__) Mostly what we do here is to disable the indentation on certain constructs that are different between 0.72 and 0.78. It isn't my preferred solution, but since it only affects a small amount of code (and most of that in macros), this seems acceptable to me. +* Fixed crash on DepthCloudPlugin (`#1133 `__) +* Wrench accepth nan values fix (`#1141 `__) +* DepthCloud plugin: Append measured subscription frequency to topic status (`#1137 `__) +* Added Cache to camera display for TimeExact (`#1138 `__) +* Fixed transport name in DepthCloud plugin (`#1134 `__) +* Fix time-syncing message (`#1121 `__) +* Switch from ROS_TIME to SYSTEM_TIME on rclcpp::Time construction (`#1117 `__) +* Append measured subscription frequency to topic status (`#1113 `__) +* Fix typo (`#1104 `__) +* Fix potencial leak / seg fault (`#726 `__) +* Fixed screw display (`#1093 `__) +* Explicit time conversions and comparisons (`#1087 `__) +* Handle missing effort limit in URDF (`#1084 `__) +* (robot) fix styling of log msg (`#1080 `__) +* Fix image display wrapping (`#1038 `__) +* removed enableInteraction reference (`#1075 `__) +* Fix ODR violations in interactive_marker displays. (`#1068 `__) +* Improve error handling in LaserScanDisplay (`#1035 `__) +* Fix implicit capture of "this" warning in C++20 (`#1053 `__) +* Removed unused code (`#1044 `__) +* Fixed AccelStamped, TwistStamped and Wrench icons (`#1041 `__) +* Fix the flakey rviz_rendering tests (`#1026 `__) +* Don't pass screw_display.hpp to the moc generator. (`#1018 `__) Since it isn't a Qt class, you get a warning from moc: Note: No relevant classes found. No output generated. Just skip adding it to the moc list here, which gets rid of the warning. +* Added DepthCloud default plugin (`#996 `__) +* Added TwistStamped and AccelStamped default plugins (`#991 `__) +* Added Effort plugin (`#990 `__) +* Improve the compilation time of rviz_default_plugins (`#1007 `__) +* Switch to ament_cmake_vendor_package (`#995 `__) +* Modify access specifier to protected or public for the scope of processMessage() member function (`#984 `__) +* Contributors: AiVerisimilitude, Alejandro Hernández Cordero, Austin Moore, Chris Lalancette, Christoph Fröhlich, Hyunseok, Jonas Otto, Lewe Christiansen, Matthijs van der Burgh, Patrick Roncagliolo, Scott K Logan, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_ogre_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update zlib into CMakeLists.txt (`#1128 `__) (`#1195 `__) Changes in 1.3 (18 Aug 2023) - Remove K&R function definitions and zlib2ansi - Fix bug in deflateBound() for level 0 and memLevel 9 - Fix bug when gzungetc() is used immediately after gzopen() - Fix bug when using gzflush() with a very small buffer - Fix crash when gzsetparams() attempted for transparent write - Fix test/example.c to work with FORCE_STORED - Rewrite of zran in examples (see zran.c version history) - Fix minizip to allow it to open an empty zip file - Fix reading disk number start on zip64 files in minizip - Fix logic error in minizip argument processing - Add minizip testing to Makefile - Read multiple bytes instead of byte-by-byte in minizip unzip.c - Add memory sanitizer to configure (--memory) - Various portability improvements - Various documentation improvements - Various spelling and typo corrections Co-authored-by: Chris Lalancette (cherry picked from commit 32eb8b9404927883247e868ab0c7d62b80df2ed1) Co-authored-by: mosfet80 +* Change an rviz_ogre_vendor dependency to libfreetype-dev. (`#1167 `__) The situation is complicated, but in versions of Ubuntu prior to Focal and versions of Debian prior to Bookworm, the name of the library was 'libfreetype6-dev'. Since Focal and Bookworm, the name of the library is 'libfreetype-dev'. While 'libfreetype-dev' provides a "virtual package" for 'libfreetype6-dev', we should really use the new canonical name. Further, there is currently a bug on ros_buildfarm where it doesn't properly deal with "virtual packages" like this. This is currently preventing this package from building on Ubuntu Noble. That bug is being worked on separately. Finally, I'll note that we already have a libfreetype-dev key in rosdep, so we just switch to using that here which should work around the bug on the buildfarm, and also use the correct canonical name going forward. +* fix: modify typo in cmake args for mac (`#1160 `__) +* feat: support macos (`#1156 `__) +* Suppress a couple more of clang warnings in rviz_ogre_vendor. (`#1102 `__) +* Fix the vendoring flags for clang compilation. (`#1003 `__) Several of the flags are not available on clang, so don't add them there. This fixes the clang build for me locally. +* Switch to ament_cmake_vendor_package (`#995 `__) +* CMake: rename FeatureSummary.cmake to avoid name clashes (`#953 `__) +* FIX CVE in external libraries (`#961 `__) +* Contributors: Chris Lalancette, Daisuke Nishimatsu, Gökçe Aydos, Scott K Logan, mergify[bot], mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added CameraInfo display (`#1166 `__) +* Fix camera display overlay (`#1151 `__) +* Fixes for uncrustify 0.78. (`#1155 `__) Mostly what we do here is to disable the indentation on certain constructs that are different between 0.72 and 0.78. It isn't my preferred solution, but since it only affects a small amount of code (and most of that in macros), this seems acceptable to me. +* fixed MovableText::getWorldTransforms transform (`#1118 `__) +* Switch to target_link_libraries. (`#1098 `__) +* Update rviz_rendering and rviz_rendering_tests to C++17. (`#1096 `__) +* Include MeshShape class (`#1064 `__) +* Use assimp to load stl (`#1063 `__) +* RVIZ_RENDERING_PUBLIC to export class RenderSystem (`#1072 `__) +* Restore the maybe-uninitialized flag in covariance_visual.hpp (`#1071 `__) +* Fix up warnings when building with clang. (`#1070 `__) +* Use buildsystem info to get the ros_package_name (`#1062 `__) +* make box-mode point cloud shader lighter on top than bottom (`#1058 `__) +* Removed warning when building in release mode (`#1057 `__) +* Fixed low FPS when sending point markers (`#1049 `__) +* Removed unused code (`#1044 `__) +* Fix the flakey rviz_rendering tests (`#1026 `__) +* Added TwistStamped and AccelStamped default plugins (`#991 `__) +* Added Effort plugin (`#990 `__) +* load GLB meshes (`#1001 `__) +* Fixed camera default plusin crash (`#999 `__) +* Clean Code (`#975 `__) * Clean Code +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Felix F Xu, Morgan Quigley, Yaswanth, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove the loading_ascii_stl_files_fail (`#1125 `__) +* Update rviz_rendering and rviz_rendering_tests to C++17. (`#1096 `__) +* Use assimp to load stl (`#1063 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_visual_testing_framework `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve the compilation time of rviz_default_plugins (`#1007 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* [J-Turtle] Fix uninitialized values in NavSatFix and add missing NavSatStatus UNKNOWN (`#220 `__) * Fix unitialized values in NavSatFix and add missing UNKNOWN * Fixes `#196 `__ * Fix default initialization instead of constants * Define SERVICE_UNKNOWN Co-authored-by: Tully Foote Co-authored-by: Martin Pecka +* Use target qualifier for checking the cpp typesupport exists (`#238 `__) +* sensor_msgs/CompressedImage: updated description of format field (`#231 `__) +* Return true for isColor if format is YUYV or UYUV (`#229 `__) +* Contributors: Chris Lalancette, Kenji Brameld, Ryan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Allow pointcloud create_cloud function to set specific point_step (`#223 `__) +* Fix read_points_numpy field_names parameter +* Contributors: Chris Lalancette, George Broughton + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shape_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`shared_queues_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove unused concurrentqueue implementation. (`#1465 `__) rosbag2 only depends on the readerwriter queue. +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`spdlog_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed spdlog_vendor warnings (`#36 `__) (`#37 `__) (cherry picked from commit 4510d9ab4389f84daac77210f3fdf8aab372b938) Co-authored-by: Alejandro Hernández Cordero +* Upgrade to v1.12.0. (`#35 `__) +* Switch to ament_cmake_vendor_package (`#34 `__) +* Contributors: Marco A. Gutierrez, Scott K Logan, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sqlite3_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_vendor_package (`#1400 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sros2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix linux tutorial: cloning example policies and set of default policies for a node (`#295 `__) (`#296 `__) * clone policies to temporary dir as subversion hack doesnt work anymore * add get_type_description service to policies * update MacOS similarly * update all permissions with new topics * dont rule out cycloneDDS * example of enclave override Co-authored-by: Chris Lalancette (cherry picked from commit ca6bb12cc650b73e7ccfc0fa789d8b49358d44ad) Co-authored-by: Mikael Arguedas +* Use modern PKCS7 to sign the certificate bytes. (`#290 `__) +* Fix a number of warnings on Ubuntu 24.04. (`#289 `__) +* Fix SSH commands in SROS2_Linux.md (`#286 `__) +* Contributors: Boris Boutillier, Chris Lalancette, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`std_srvs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`stereo_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries everywhere. (`#532 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli_remapping `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries everywhere. (`#532 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_communication `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Small fix for modern flake8. (`#539 `__) +* Switch to target_link_libraries everywhere. (`#532 `__) +* Add integration test for nested messages. (`#530 `__) +* Adjust for new rclcpp::Rate API (`#516 `__) +* Contributors: Alexey Merzlyakov, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Small fixes for modern flake8. (`#395 `__) +* add "--log-file-name" command line argument for test. (`#387 `__) +* Fix an assert in the test_launch_ros tests. (`#367 `__) +* Fix misspelled "receive". (`#362 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17 (`#742 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Increase the timeout for the test_msgs rosidl_generated_cpp cpplint. (`#163 `__) This should make it much more likely to succeed on Windows. +* Fix for invalid conversion from const char8_t* to char for C++20 (`#160 `__) +* Contributors: AiVerisimilitude, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_quality_of_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup header includes in test_quality_of_service. (`#533 `__) +* Switch to target_link_libraries everywhere. (`#532 `__) +* Fix test QoS on macOS by moving qos_utilities.cpp to the four tests; fixes `#517 `__ (`#518 `__) +* Contributors: Chris Lalancette, PhDittmann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Addressed TODO in test_local_parameters (`#545 `__) +* Actually skip the gtest_subscription test on Connext. (`#544 `__) +* Increased time in test_multithreaded (`#543 `__) +* Improve the node_name test. (`#538 `__) +* Change up the formatting in the test_rclcpp tests. (`#537 `__) +* Revamp test_rclcpp to compile far few files. (`#535 `__) +* Mark gtest_subscription__rmw_connextdds xfail. (`#531 `__) +* refactor corrected depth check for prefix in parameter_fixtures.hpp (`#529 `__) +* Remove an unnecessary capture in test_rclcpp. (`#527 `__) +* Cleanup of the CMakeLists.txt for test_rclcpp. (`#526 `__) +* Add a fix for the tests given the new type description parameter (`#520 `__) +* Changes ros_timer_init for ros_timer_init2 (`#508 `__) +* refactor the multi_access_publisher test to avoid dead locks (`#515 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Eloy Briceno, Emerson Knapp, Lee, Minju, William Woodall + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Compile the test_rmw_implementation tests fewer times. (`#224 `__) +* Switch to using target_link_libraries everywhere. (`#222 `__) +* Add rmw_count_clients,services & test (`#208 `__) +* Contributors: Chris Lalancette, Lee, Minju + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add explicit context fields test to test_ros2trace (`#107 `__) +* Allow tracing tests to be run in parallel with other tests (`#95 `__) +* Make test_ros2trace depend on test_tracetools_launch. +* Switch to custom lttng-ctl Python bindings (`#81 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_security `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17 (`#528 `__) +* Switch to target_link_libraries everywhere. (`#532 `__) +* Adjust for new rclcpp::Rate API (`#516 `__) +* Extract sros_artifacts fixture into a CMake script (`#525 `__) +* Use test fixtures to create SROS artifacts (`#522 `__) +* Contributors: Alexey Merzlyakov, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Compile fix for upcomming changes to rclcpp::Executor (`#668 `__) +* Adding addition BUILD_TESTING requirement (`#660 `__) +* normalize quaternions on tf2_eigen (`#644 `__) +* Contributors: Lucas Wendland, Paul Gesel, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve tracetools_test and simplify test_tracetools code (`#109 `__) +* Install test_tracetools_mark_process (`#113 `__) +* Remove unnecessary include (`#111 `__) +* Include in mark_process.cpp (`#110 `__) +* Remove unnecessary print in test (`#108 `__) +* Add test for GenericPublisher/Subscriber (`#97 `__) +* Use lttng_ust_tracef instead of lttng_ust__tracef (`#103 `__) +* Use a memcmp for the expected symbol name. (`#100 `__) +* Fix the build on RHEL-9. (`#98 `__) +* Allow tracing tests to be run in parallel with other tests (`#95 `__) +* Fix interference between test_tracetools and ros2lifecycle tests (`#96 `__) +* Make tracing test assert messages more descriptive (`#93 `__) +* Update tests and docs after new rmw_publish timestamp field (`#90 `__) +* Switch to target_link_libraries in test_tracetools. (`#83 `__) +* Improve test coverage of rclcpp_callback_register in test_tracetools (`#69 `__) +* Disable tracing on Android (`#71 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Przemysław Dąbrowski, h-suzuki-isp + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve tracing configuration error reporting (`#85 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote +* Warning Message Intervals for canTransform (`#663 `__) +* Nacho/minor fixes tf2 cache (`#658 `__) +* Removing console_bridge (`#655 `__) +* Fix constantly increasing memory in std::list (`#636 `__) +* Update the tf2 documentation (`#638 `__) +* Fix error code returned in BufferCore::walkToTopParent (`#601 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Ignacio Vizzo, Lucas Wendland, Patrick Roncagliolo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_bullet `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed obsolete headers (`#645 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed obsolete headers (`#645 `__) +* normalize quaternions on tf2_eigen (`#644 `__) +* Fix clang build warnings. (`#628 `__) +* Add another reference for twist transformation. Comment correction. (`#620 `__) +* Contributors: Alejandro Hernández Cordero, AndyZe, Chris Lalancette, Paul Gesel + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix installation directory of .dll files in tf2_eigen_kdl (`#657 `__) +* Remove unnecessary use of ament_target_dependencies. (`#637 `__) We can just use target_link_libraries instead. +* Fix clang build warnings. (`#628 `__) +* Contributors: Chris Lalancette, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote +* Removed obsolete headers (`#645 `__) +* Add doTransform support for Point32, Polygon and PolygonStamped (backport `#616 `__) (`#619 `__) +* Contributors: Alejandro Hernández Cordero, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed obsolete headers (`#645 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Compile fix for upcomming changes to rclcpp::Executor (`#668 `__) +* Enable Twist interpolator (`#646 `__) Co-authored-by: Tully Foote +* Adding NodeInterfaces to Buffer (`#656 `__) +* Reformat some code to make uncrustify happier. (`#654 `__) +* Enable intra-process (`#649 `__) (`#642 `__) +* Avoid unecessary time conversions. (`#635 `__) +* Expose TF2 listener CB (`#632 `__) +* Fix invalid timer handle exception (`#474 `__) +* Fix for `#589 `__ - Should be able to transform with default timeout (`#593 `__) +* Enable StaticTransformBroadcaster in Intra-process enabled components (`#607 `__) +* Contributors: AiVerisimilitude, Alejandro Hernández Cordero, Chris Lalancette, Cliff Wu, Lucas Wendland, Patrick Roncagliolo, Steve Macenski, jmachowinski, vineet131 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Transform Data Callback Python (`#664 `__) +* Make sure to cache transforms in tf2_ros_py. (`#634 `__) +* Remove 'efficient copy' prints (`#625 `__) +* Add time jump callback (`#608 `__) +* Contributors: Chris Lalancette, Erich L Foster, Lucas Wendland, Matthijs van der Burgh + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed obsolete headers (`#645 `__) +* Fix clang build warnings. (`#628 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* [view_frames] log filenames after it's been determined (`#674 `__) (`#675 `__) (cherry picked from commit 24643fce510d8cc836fe6e5277a1d3f86a21af04) Co-authored-by: Mikael Arguedas +* Add in tests for tf2_tools. (`#647 `__) +* Contributors: Chris Lalancette, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_monitor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* fix readme for topic_monitor. (`#630 `__) +* Contributors: Michael Jeronimo, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_statistics_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update maintainer list in package.xml files (`#665 `__) +* Contributors: Michael Jeronimo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Switch to ament_generate_version_header for tracetools (`#112 `__) +* Fixes for newer uncrustify (`#101 `__) +* Update tests and docs after new rmw_publish timestamp field (`#90 `__) +* Add timestamp to rmw_publish tracepoint (`#74 `__) +* Add TRACETOOLS\_ prefix to tracepoint-related public macros (`#56 `__) +* Disable tracing on Android (`#71 `__) +* Add new rclcpp_subscription_init tracepoint to support new intra-process comms +* Contributors: Chris Lalancette, Christophe Bedard, Christopher Wecht, Przemysław Dąbrowski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Use single underscore for private vars in Python (`#92 `__) +* Improve tracing configuration error reporting (`#85 `__) +* Fix warnings when using mypy 1.8.0. (`#89 `__) +* Remove extra single quote in LdPreload debug log (`#79 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_read `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Improve tracetools_test and simplify test_tracetools code (`#109 `__) +* Allow tracing tests to be run in parallel with other tests (`#95 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Improve tracetools_test and simplify test_tracetools code (`#109 `__) +* Improve assertEventOrder failure output (`#106 `__) +* Allow tracing tests to be run in parallel with other tests (`#95 `__) +* Fix interference between test_tracetools and ros2lifecycle tests (`#96 `__) +* Make tracing test assert messages more descriptive (`#93 `__) +* Fix use of mutable default arg in tracetools_test (`#84 `__) +* Switch to in pure Python packages (`#67 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Replace all occurences of index.ros.org (`#114 `__) +* Improve tracing configuration error reporting (`#85 `__) +* Add a space in between not and parentheses. (`#88 `__) +* Switch to custom lttng-ctl Python bindings (`#81 `__) +* Create start/pause/resume/stop sub-commands for 'ros2 trace' (`#70 `__) +* Detect issue with LTTng and Docker and report error when tracing (`#66 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`trajectory_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`turtlesim `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add icon for Jazzy. (`#167 `__) (`#168 `__) (cherry picked from commit 014955e15a6ac3b1649cbf21e11c8547ebd47af7) Co-authored-by: Marco A. Gutierrez +* [teleop_turtle_key] update usage string to match keys captured by keyboard (`#165 `__) (`#166 `__) On windows it will stay uppercase but shouldn't impact users compared to current situation (cherry picked from commit e2853cac87f0c62db6294e5bc351e5b52fcd1ae1) Co-authored-by: Mikael Arguedas +* Shorten the callback definition for uncrustify. (`#163 `__) +* Use same QoS for all topic pub/subs (`#161 `__) +* Remove all uses of ament_target_dependencies. (`#159 `__) +* Crop galactic.png and rolling.png to 45x45. (`#158 `__) +* Remove the unused member variable last_state\_ (`#156 `__) +* Added common tests (`#154 `__) +* Heavy cleanup of the draw_square tutorial. (`#152 `__) * Heavy cleanup of the draw_square tutorial. In particular: 1. Make it conform to the current ROS 2 style. 2. Add in copyright information. 3. Refactor the entire code into a class, which tidies it up quite a bit and removes a bunch of globals. 4. Make sure to wait for the reset to complete before trying to move the turtle. +* Remove the range constraints from the holonomic parameter. (`#150 `__) +* Add icon (`#148 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Jason O'Kane, Yadu, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`uncrustify_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to uncrustify 0.78.1 (`#37 `__) * Update to uncrustify 0.78.1 * Fix the uncrustify version detection logic. And make sure we are at least 0.78. +* Switch to ament_cmake_vendor_package (`#34 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`unique_identifier_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update to C++17 (`#27 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries (`#36 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf_parser_plugin `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to target_link_libraries (`#36 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`visualization_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove references to index.ros.org. (`#244 `__) +* Adds ARROW_STRIP to Marker.msg (`#242 `__) +* Clarify the license. (`#241 `__) In particular, every package in this repository is Apache 2.0 licensed except for sensor_msgs_py. So move the CONTRIBUTING.md and LICENSE files down into the individual packages, and make sure that sensor_msgs_py has the correct CONTRIBUTING.md file (it already had the correct LICENSE file). +* Contributors: Chris Lalancette, Tom Noble + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`yaml_cpp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed warnigns (`#49 `__) (`#50 `__) (cherry picked from commit 4b6808fd0f9b0b5e05928c0c8e44fd976a043d33) Co-authored-by: Alejandro Hernández Cordero +* Upgrade to yaml-cpp 0.8.0 (`#48 `__) Co-authored-by: Chris Lalancette +* Support yaml-cpp >= 0.8.0 (`#46 `__) +* Disable the -Wshadow warning when building under clang. (`#45 `__) +* Switch to ament_cmake_vendor_package (`#43 `__) +* Revamp the extras file to find the correct version. (`#42 `__) +* Contributors: Chris Lalancette, Marco A. Gutierrez, Scott K Logan, Silvio Traversaro, mergify[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`zstd_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Updated zstd to 1.5.5 (`#1617 `__) (`#1624 `__) +* Switch to ament_cmake_vendor_package (`#1400 `__) +* Contributors: Scott K Logan, mergify[bot] \ No newline at end of file diff --git a/source/Get-Started/Releases/Kilted-Kaiju-Complete-Changelog.rst b/source/Get-Started/Releases/Kilted-Kaiju-Complete-Changelog.rst index aabc0f0b487..1a4cd8bb436 100644 --- a/source/Get-Started/Releases/Kilted-Kaiju-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Kilted-Kaiju-Complete-Changelog.rst @@ -1,3289 +1,3292 @@ -ROS 2 Kilted Kaiju Complete Changelog -===================================== - -This page is a list of the complete changes in all ROS 2 core packages since the previous release. - -.. contents:: Table of Contents - :local: - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings -* Update action cpp demos to support setting introspection (`#709 `__) * Update action cpp demos to support setting introspection * Add the missing header file declaration --------- -* Remove action_tutorials_interfaces. (`#701 `__) -* Removed outdated comment (`#699 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`action_tutorials_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update action python demos to support setting introspection (`#708 `__) * Update action python demos to support setting introspection * Correct the errors in the document --------- -* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) -* Remove action_tutorials_interfaces. (`#701 `__) -* Change all of the demos to use the new rclpy context manager. (`#694 `__) -* Contributors: Barry Xu, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_format `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_clang_tidy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* ament_clang_tidy - Fix Reporting when WarningsAsErrors is specified in config (`#397 `__) -* Contributors: Chris Lalancette, Matt Condino - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix headers destination installed by ament_auto_package (`#540 `__) -* Add ament_auto_depend_on_packages to replace ament_target_dependencies (`#571 `__) -* More specific prefix in some cmake_parse_argument calls (`#523 `__) -* Contributors: Kevin Egger, Kotaro Yoshimoto, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Create destination directory during symlink install (`#569 `__) -* Support generator expressions when symlinking install(FILES) (`#560 `__) -* Always symlink TARGET\_{LINKER,SONAME}_FILE on libraries (`#535 `__) -* Fix symlink install of versioned libs on macOS (`#558 `__) -* More specific prefix in some cmake_parse_argument calls (`#523 `__) -* Contributors: Ezra Brooks, Kevin Egger, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gen_version_h `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ALL target for ament_generate_version_header target. (`#526 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_gtest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* set search path args and then append (`#543 `__) -* Contributors: Will - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Don't write Python bytecode when invoking pytest (`#533 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_add_ros_isolated\_{gmock,gtest}_test macros (`#29 `__) -* Switch from 'domain_coordinator' to 'rmw_test_fixture' (`#28 `__) -* Add ament_add_ros_isolated_test function (`#27 `__) -* Split generic parts of ament_cmake_ros into _core package (`#20 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_ros_core `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing build_export_depend on ament_cmake_libraries (`#37 `__) -* Split generic parts of ament_cmake_ros into _core package (`#20 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_target_dependencies `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Deprecate ament_target_dependencies() (`#572 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cmake_vendor_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add explicit git dependency from ament_cmake_vendor_package (`#554 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_copyright `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve ament_copyright performance drastically. (`#515 `__) -* Fix error path for search_copyright_information. (`#491 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cppcheck `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_cpplint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Enable a quiet mode for cpplint (`#532 `__) -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette, Nils-Christian Iseke - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_flake8 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add the rest of the flake8 plugins as dependencies. (`#503 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_index_python `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add py.typed to package_data (`#100 `__) -* Add test_xmllint to ament_index_python. (`#96 `__) -* Add ament_mypy unit test and export types (`#95 `__) -* Contributors: Chris Lalancette, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_auto `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add docu for AMENT_LINT_AUTO_EXCLUDE (`#524 `__) -* Contributors: Alexander Reimann - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_lint_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_mypy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix Windows Regression by removing removesuffix() (`#530 `__) -* Export typing information (`#487 `__) -* Add support for type stubs (`#516 `__) -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_package `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Simplify removing leading and trailing separators (`#152 `__) -* Remove CODEOWNERS and mirror-rolling-to-master. (`#149 `__) -* Always consider .dsv files, even when no shell specific script exists (`#147 `__) -* Contributors: Addisu Z. Taddese, Chris Lalancette, Rob Woolley - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pclint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pycodestyle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_pyflakes `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_uncrustify `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ament_xmllint `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint testing for all packages that we can. (`#508 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`builtin_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_calibration_parsers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#345 `__) -* Added common linters to camera_calibration_parsers (`#317 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_info_manager `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add optional namespace to /set_camera_info service in CameraInfoManager (`#324 `__) -* Added common test to camera info manager (`#318 `__) -* Contributors: Alejandro Hernández Cordero, Jan Hernas - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`camera_info_manager_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup of camera_info_manager_py. (`#340 `__) -* Add ``camera_info_manager_py`` (`#335 `__) -* Bump package version to synchronize with image_common -* Ros2 (`#2 `__) * Run magic converter * Ament_python package * Fix some imports * Remove references to cpp camera info manager. Disable tests * Linting * Fully Remove old tests * Add lint tests * Final tests * Remove pep257 from depends -* changelog -* added CPR maintainer -* Release to Melodic and Noetic -* Only use rostest when testing enabled, thanks to Lukas Bulwahn. -* Move repository to ros-perception. -* Add namespace parameter to constructor, so a driver can handle multiple cameras. Enhancement thanks to Martin Llofriu. -* Make unit tests conditional on ``CATKIN_ENABLE_TESTING``. -* Release to Groovy and Hydro. -* Set null calibration even when URL invalid (#7). -* Release to Groovy and Hydro. -* Convert to catkin. -* Remove roslib dependency. -* Release to Groovy and Hydro. -* Initial Python camera_info_manager release to Fuerte. -* Contributors: Alejandro Hernández Cordero, Chris Iverach-Brereton, Chris Lalancette, Jack O'Quin, José Mastrangelo, Lucas Walter, Lukas Bulwahn, Martin Pecka, Michael Hosmar, mllofriu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Fix typo in composition comment (`#703 `__) -* Change references from "jazzy" to "rolling" on the rolling branch. (`#687 `__) -* [composition] add launch action console output in the verify section (`#677 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Mikael Arguedas, Shane Loretz, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) -* [demo_nodes_cpp] some readme and executable name fixups (`#678 `__) -* Fix gcc warnings when building with optimizations. (`#672 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Mikael Arguedas, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_cpp_native `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Contributors: Shane Loretz, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`demo_nodes_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Revert "fix loading parameter behavior from yaml file. (`#656 `__)" (`#660 `__)" (`#661 `__) -* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) -* Change all of the demos to use the new rclpy context manager. (`#694 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`domain_coordinator `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_xmllint to domain_coordinator. (`#17 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_map_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Contributors: Shane Loretz, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_robot_bringup `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`dummy_sensors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Update dummy_sensors readme to echo the correct topic (`#675 `__) -* Contributors: Shane Loretz, jmackay2, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_async_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_cbg_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Removed outdated comment (`#388 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Removed outdated comment (`#388 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_composition `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_minimal_timer `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_multithreaded_executor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclcpp_wait_set `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_executors `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_guard_conditions `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_action_server `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Add guard on Python single goal action server example (`#380 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette, Ruddick Lawrence - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_client `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Use a single executor instance for spinning in client_async_callback. (`#382 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address flake8 errors for examples_rclpy_minimal_publisher (`#410 `__) -* Add publisher_member_function_with_wait_for_all_acked.py (`#407 `__) -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_minimal_subscriber `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_rclpy_pointcloud_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in ament_xmllint for the ament_python packages. (`#397 `__) -* Switch to using the rclpy context manager everywhere. (`#389 `__) -* Update the shutdown handling in all of the Python examples. (`#379 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`examples_tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in test_xmllint for geometry2 python packages. (`#725 `__) -* Switch to using a context manager for the python examples. (`#700 `__) That way we can be sure to always clean up, but use less code doing so. -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`foonathan_memory_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve mechanism to find an installation of foonathan_memory (#67) - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Complete Removal of PoseStampedArray (`#270 `__) -* Move geometry_msgs/PoseStampedArray to nav_msgs/Goals (`#269 `__) -* Add PoseStampedArray (`#262 `__) -* Contributors: Tony Najjar, Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gmock_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump minimum CMake version to 3.15 (`#31 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`google_benchmark_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump minimum CMake version to 3.10 (`#35 `__) -* Remove CODEOWNERS and mirror-rolling-to-main workflow. (`#31 `__) -* Contributors: Chris Lalancette, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gtest_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump minimum CMake version to 3.15 (`#33 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gz_cmake_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version to 4.1.1 (`#13 `__) -* Bump version to 4.1.0 (`#11 `__) -* Bump version to 4.0.0 (`#10 `__) -* Fixes the cmake-config used during find_package (`#8 `__) The provided cmake-config was not actually working if one did ``` find_package(gz_cmake_vendor) find_package(gz-cmake) ``` This because the config file tried to create aliases to targets that don't exist. For example, gz-cmake4::gz-cmake4 is not exported by gz-cmake. -* Remove the BUILD_DOCS cmake argument. (`#9 `__) It is apparently deprecated in newer Gazebo. -* Apply prerelease suffix and remove patch (`#7 `__) -* Upgrade to Ionic -* Contributors: Addisu Z. Taddese, Chris Lalancette, Steve Peters - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gz_math_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version to 8.1.1 (`#10 `__) -* Bump version to 8.1.0 (`#8 `__) * This is a rerelease since #7 did not actually bump the version of the vendored package. -* Bump version to 8.1.0 (`#7 `__) -* Bump version to 8.0.0 (`#5 `__) -* Apply prerelease suffix (`#4 `__) -* Upgrade to Ionic -* Update vendored package version to 7.5.0 -* Contributors: Addisu Z. Taddese, Carlos Agüero, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`gz_utils_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump version to 3.1.1 (`#10 `__) -* Bump version to 3.1.0 (`#8 `__) -* Bump version to 3.0.0 (`#7 `__) -* Add in a dependency on spdlog_vendor. (`#6 `__) * Add in a dependency on spdlog_vendor. That way when building on e.g. Windows, the paths to spdlog will be setup properly before trying to build this vendor package. * Also remove the spdlog dependency. That's because we will just depend on the vendor package to provide that dependency for us as necessary. --------- -* Remove the BUILD_DOCS cmake argument. (`#5 `__) It is apparently deprecated in newer Gazebo. -* Apply prerelease suffix (`#4 `__) -* Upgrade to Ionic -* Contributors: Addisu Z. Taddese, Carlos Agüero, Chris Lalancette, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Lint image_tools/CMakeLists.txt (`#712 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) -* Contributors: Alejandro Hernández Cordero, mosfet80, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove windows warnings (`#350 `__) -* Add ``rclcpp::shutdown`` (`#347 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#345 `__) -* feat: python bindings for image_transport and publish (`#323 `__) Co-authored-by: Alejandro Hernández Cordero -* Apply remappings to base topic before creating transport-specific topics (`#326 `__) -* Add lazy subscription to republisher (`#325 `__) -* Fix node name (`#321 `__) -* Updated deprecated message filter headers (`#320 `__) -* Removed outdated comment (`#319 `__) -* Preparing for qos deprecation (`#315 `__) -* Removed warning (`#312 `__) -* Support zero-copy intra-process publishing (`#306 `__) -* Add missing sub and pub options (`#308 `__) Co-authored-by: Angsa Deployment Team -* Contributors: Alejandro Hernández Cordero, Błażej Sowa, Földi Tamás, Lucas Wendland, Michal Sojka, Shane Loretz, Tony Najjar, Yuyuan Yuan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`image_transport_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in python3-dev build dependency (`#334 `__) -* feat: python bindings for image_transport and publish (`#323 `__) Co-authored-by: Alejandro Hernández Cordero -* Contributors: Chris Lalancette, Földi Tamás - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`interactive_markers `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Deprecating tf2 C Headers (`#109 `__) -* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#110 `__) -* Use non deprecated API (`#108 `__) -* Contributors: Alejandro Hernández Cordero, Lucas Wendland - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`intra_process_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) -* Removed pre-compiler check for opencv3 (`#695 `__) -* [intra_process_demo] executable name in README.md fix-up (`#690 `__) -* Contributors: Alejandro Hernández Cordero, Trushant Adeshara, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`kdl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update urdf model header (`#85 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`laser_geometry `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Deprecating tf2 C Headers (`#98 `__) -* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#100 `__) -* Stop using python_cmake_module. (`#93 `__) -* Added common linters (`#96 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Lucas Wendland - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Provide copy of launch configs to TimerAction's entities (`#836 `__) -* Allow concatenating each path component of PathJoinSubstitution (`#838 `__) -* Add StringJoinSubstitution substitution (`#843 `__) -* Add missing test_depend for launch (`#850 `__) -* Document substitutions concatenation in architecture doc (`#845 `__) -* Update docs to use proper RST literals (`#837 `__) -* Fix function params indentation (`#833 `__) -* Add ForEach action to repeat entities using iteration-specific values (`#802 `__) -* Create py.typed (`#828 `__) -* Improve error reporting by adding file locations to exceptions (`#823 `__) -* add test coverage for substitution edgecases involving E notation (`#824 `__) -* Cleanup the launch dependencies. (`#819 `__) -* Fix 'set up' typo (`#813 `__) -* Add test_xmllint to all of the ament_python packages. (`#804 `__) -* Fix typo in comment (`#783 `__) -* Contributors: Chris Lalancette, Christian Ruf, Christophe Bedard, Michael Carlstrom, Roland Arsenault, danielcranston - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_pytest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup the launch dependencies. (`#819 `__) -* Add test_xmllint to all of the ament_python packages. (`#804 `__) -* Switch to using an rclpy context manager. (`#787 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove the slash stripping since leading slash matters (`#456 `__) -* Fixing lifecycle node autostart issue `#445 `__ (`#449 `__) -* Change docstring markdown code blocks to RST (`#450 `__) -* Autostarting lifecycle nodes and example launch file demo (`#430 `__) -* Add YAML dumper representator for str type to keep quotes always. (`#436 `__) -* Mock launch components causing rosdoc2 to fail Python API (`#425 `__) -* Add ament_xmllint to the ament_python packages. (`#423 `__) -* Fix url in setup.py (`#413 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Olivia/F.F., R Kent James, Steve Macenski, Tomoya Fujita, Wei HU - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix function params indentation (`#833 `__) -* Cleanup the launch dependencies. (`#819 `__) -* Add test_xmllint to all of the ament_python packages. (`#804 `__) -* Add mechanism to disable workaround for dependency groups (`#775 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ament_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add CMake parameter to override launch_testing module (`#854 `__) -* Stop using python_cmake_module. (`#760 `__) -* Don't write Python bytecode when invoking launch tests (`#785 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_examples `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_xmllint.py. (`#401 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_testing_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* ``WaitForTopics``: let the user inject a trigger function to be executed after starting the subscribers (`#356 `__) -* Add EnableRmwIsolation action for starting rmw_test_fixture (`#459 `__) -* Fix function params indentation (`#446 `__) -* Add ament_xmllint to the ament_python packages. (`#423 `__) -* Switch to use rclpy.init context manager. (`#402 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Giorgio Pintaudi, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_xml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ForEach action to repeat entities using iteration-specific values (`#802 `__) -* Stop loading extensions during launch\_{xml,yaml} tests. (`#820 `__) -* Cleanup the launch dependencies. (`#819 `__) -* Add test_xmllint to all of the ament_python packages. (`#804 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`launch_yaml `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ForEach action to repeat entities using iteration-specific values (`#802 `__) -* Stop loading extensions during launch\_{xml,yaml} tests. (`#820 `__) -* Cleanup the launch dependencies. (`#819 `__) -* Add test_xmllint to all of the ament_python packages. (`#804 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libcurl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* uniform MinCMakeVersion (`#108 `__) -* Add "lib" to the Windows curl search path. (`#96 `__) In CMake 3.3, a commit made it so that the find_package module in CMake had a compatibility mode where it would automatically search for packages in a /lib subdirectory. In CMake 3.6, this compatibility mode was reverted for all platforms *except* Windows. That means that since CMake 3.3, we haven't actually been using the path as specified in ``curl_DIR``, but we have instead been inadvertently relying on that fallback behavior. In CMake 3.28, that compatibilty mode was also removed for Windows, meaning that we are now failing to find_package(curl) in downstream packages (like resource_retriever). Fix this by adding in the "lib" directory that always should have been there. I'll note that this *only* affects our Windows builds, because this code is in a if(WIN32) block. -* Contributors: Chris Lalancette, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`liblz4_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in a library prefix for lz4 from conda on Windows. (`#1846 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libstatistics_collector `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump codecov/codecov-action from 4.5.0 to 4.6.0 -* Fix MovingAverageStatistics::max\_ Default Value (`#201 `__) -* Removed deprecated classes (`#200 `__) -* fix: add void annotation (`#194 `__) -* Contributors: Alejandro Hernández Cordero, Daisuke Nishimatsu, Jeffery Hsu, dependabot[bot] - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`libyaml_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Only set CRT_SECURE_NO_WARNINGS if it hasn't already been set. (`#64 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Contributors: Shane Loretz, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lifecycle_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) -* Change all of the demos to use the new rclpy context manager. (`#694 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`logging_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`lttngpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove SHARED from pybind11_add_module (`#154 `__) -* Add python3-dev build_depend to lttngpy. (`#146 `__) -* Don't try to build on BSD (`#142 `__) -* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) -* Remove python_cmake_module use. (`#91 `__) -* Add missing dependency on pkg-config to lttngpy (`#130 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Nathan Wiebe Neufeldt, Scott K Logan, Silvio Traversaro - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mcap_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update mcap (`#1774 `__) Update mcap cpp to last version -* Update mcap-releases-cpp- into CMakeLists.txt (`#1612 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`message_filters `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed windows warnings (`#171 `__) -* More generic subscriber implementation using NodeInterfaces from rclcpp (`#113 `__) -* Feature/time sequencer python (`#156 `__) -* Add sync_arrival_time flag to ApproximateTimeSynchronizer (`#166 `__) -* fix: add ``rclcpp::shutdown`` (`#167 `__) -* fix typo: Cache.getLastestTime -> Cache.getLatestTime (`#165 `__) -* Add temporal offset between topics between ApproximateTimeSynchronizer (`#154 `__) -* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#158 `__) -* Updated Python docs (`#150 `__) -* Adds an input aligner filter (`#148 `__) -* Stop using python_cmake_module. (`#114 `__) -* Fix the wording in the deprecation messages. (`#144 `__) -* Apply some simplifications and deduplications to ExactTime sync policy (`#142 `__) -* Minor fixes for `#93 `__ (`#143 `__) -* Bugfix/segfault when getting surrounding interval of empty cache (`#116 `__) -* Migrate to C++11 variadic templates (`#93 `__) -* [LatestTimeSync] Fix crash when Synchronizeris started before the messges are available. (`#137 `__) -* Fix cppcheck warning on Windwos (`#138 `__) -* Adding ament_lint_common (`#120 `__) -* Deprecating all C headers (`#135 `__) -* Cleanups (`#134 `__) -* fix link of index.rst in README.md (`#133 `__) -* Revert "Adding explicit constructors (`#129 `__)" (`#132 `__) -* fix: fallback Time used incorrect clock (`#118 `__) -* Adding explicit constructors (`#129 `__) -* Deprecated qos_profile in Subscriber (`#127 `__) -* Adding cpplint (`#125 `__) -* Move Docs From Wiki (`#119 `__) -* Adding lint_cmake (`#126 `__) -* Adding Uncrustify Changes (`#124 `__) -* Adding Copyright Linter (`#122 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christopher Wecht, Clément Chupin, Dominik, Dr. Denis, Iván López Broceño, Kalvik, Lucas Wendland, Matthias Holoch, Michal Staniaszek, Russ, Saif Sidhik, Sascha Arnold, Yuyuan Yuan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`mimick_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update hash to fix windows failures (`#39 `__) -* Update to the commit that includes DT_GNU_HASH. (`#37 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`nav_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Move geometry_msgs/PoseStampedArray to nav_msgs/Goals (`#269 `__) -* Contributors: Tully Foote - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`orocos_kdl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use the same cmake version (`#36 `__) -* Resolve compatibility issue with newer cmake (`#35 `__) -* fix: add cxx_standard to avoid c++ check error (`#30 `__) -* Ensure that orocos_kdl_vendor doesn't accidentally find itself. (`#27 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Homalozoa X, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Merge pull request `#103 `__ from christophebedard/christophebedard/fix-typo-on-each-verb -* Align stdeb dependencies with setup.py (`#101 `__) Follow-up to 4b2f3a8e4969f33dced1dc2db2296230e7a55b1d -* Add '+upstream' suffix to published deb version (`#102 `__) Using a debian version suffix which falls late alphabetically appears to give our packages preference by apt. If a user enables a repository which distributes packages created by OSRF or ROS, it is likely that they wish to use these packages instead of the ones packaged by their platform. -* Upload coverage results to codecov (`#100 `__) -* Update ci.yaml (`#96 `__) fix node.js <20 deprecation Co-authored-by: Scott K Logan -* Updated python version (`#97 `__) Python version 3.7 is no longer supported as of June 27, 2023 Co-authored-by: Scott K Logan -* Resolve outstanding resource warnings when running tests (`#99 `__) -* Update deb platforms for release (`#95 `__) Added: * Ubuntu Noble (24.04 LTS pre-release) * Debian Trixie (testing) Dropped: * Debian Bullseye (oldstable) Retained: * Debian Bookworm (stable) * Ubuntu Focal (20.04 LTS) * Ubuntu Jammy (22.04 LTS) -* Remove CODEOWNERS. (`#98 `__) It is out of date and no longer serving its intended purpose. -* Contributors: Chris Lalancette, Christophe Bedard, Scott K Logan, Steven! Ragnarök, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`osrf_testing_tools_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update CMakeLists.txt (`#85 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_control `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pendulum_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`performance_test_fixture `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix a warning when building on Ubuntu Noble. (`#26 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`pluginlib `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Heavily cleanup pluginlib. (`#265 `__) -* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#268 `__) -* Fix Minor Spelling Mistakes (`#260 `__) -* Removed deprecated method (`#256 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, David V. Lu!! - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`point_cloud_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ``rclcpp::shutdown`` (`#110 `__) -* Updated deprecated message filter headers (`#94 `__) -* Removed warning (`#89 `__) -* republisher: qos override pub and sub (`#88 `__) -* Stop using ament_target_dependencies. (`#86 `__) We are slowly moving away from its use, so stop using it here. While we are in here, notice some things that makes this easier: 1. pluginlib is absolutely a public dependency of this package. Because of that, we can just rely on the PUBLIC export of it, and we don't need to link it into every test. But that also means we don't need some of the forward-declarations that were in loader_fwds.hpp, as we can just get those through the header file. 2. republish.hpp doesn't really need to exist at all. That's because it is only a header file, but the implementation is in an executable. Thus, no downstream could ever use it. So just remove the file and put the declaration straight into the cpp file. -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Yuyuan Yuan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`point_cloud_transport_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in dependency on python3-dev. (`#103 `__) -* Remove use of python_cmake_module. (`#63 `__) -* remove extra semicolon (`#98 `__) -* Contributors: Chris Lalancette, Manu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_orocos_kdl_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* fix: use fetchcontent_makeavailable to fix CMP0169 (`#32 `__) -* Remove the use of python_cmake_module (`#26 `__) -* Contributors: Chris Lalancette, Homalozoa X - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`python_qt_binding `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Skip running the tests on Windows Debug. (`#142 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_dotgraph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Convert qt_dotgraph to a pure Python package. (`#300 `__) -* Cleanup qt_dotgraph and make the tests more robust. (`#296 `__) -* Skip running the tests on Windows Debug. (`#292 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`qt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#302 `__) -* Add common linters and make them happy to qt_gui_cpp (`#295 `__) -* Deprecated h headers (`#294 `__) -* Contributors: Alejandro Hernández Cordero, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`quality_of_service_demo_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) -* Change all of the demos to use the new rclpy context manager. (`#694 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#1218 `__) -* Fix typo in message header include in doc (`#1219 `__) -* use rmw_event_type_is_supported (`#1214 `__) -* No need to add public symbol visibility macros in implementation. (`#1213 `__) -* Add new interfaces to enable intropsection for action (`#1207 `__) -* Use FASTDDS_DEFAULT_PROFILES_FILE instead. (`#1211 `__) -* Relieve timer test period not to miss the cycle. (`#1209 `__) -* fix(rcl_action): Allow to pass the timer to action during initialization (`#1201 `__) * fix(timer): Use impl pointer in jump callback The interface description does not explicitly state that a rcl_timer_t may not be copied around. Therefore users may do this. By using a known never changing pointer in the callbacks, we avoid segfaults, even if the 'user' decides to copy the rcl_timer_t around. -* move qos_profile_rosout_default to rmw. (`#1195 `__) -* Update example usage for rcl_wait_set_init to pass correct number of args (`#1204 `__) -* Clean up error handling in many rcl{_action,_lifecycle} codepaths (`#1202 `__) * Shorten the delay in test_action_server setup. Instead of waiting 250ms between setting up 10 goals (for at least 2.5 seconds), just wait 100ms which reduces this to 1 second. * Small style cleanups in test_action_server.cpp * Reset the error in rcl_node_type_cache_register_type(). That is, if rcutils_hash_map_set() fails, it sets its own error, so overriding it with our own will cause a warning to print. Make sure to clear it before setting our own. * Only unregister a clock jump callback if we have installed it. This avoids a warning on cleanup in rcl_timer_init2. * Record the return value from rcl_node_type_cache_register_type. Otherwise, in a failure situation we set the error but we actually return RCL_RET_OK to the upper layers, which is odd. * Get rid of completely unnecessary return value translation. This generated code was translating an RCL error to an RCL error, which doesn't make much sense. Just remove the duplicate code. * Use the rcl_timer_init2 functionality to start the timer disabled. Rather than starting it enabled, and then immediately canceling it. * Don't overwrite the error from rcl_action_goal_handle_get_info() It already sets the error, so rcl_action_server_goal_exists() should not set it again. * Reset errors before setting new ones when checking action validity That way we avoid an ugly warning in the error paths. * Move the copying of the options earlier in rcl_subscription_init. That way when we go to cleanup in the "fail" case, the options actually exist and are valid. This avoids an ugly warning during cleanup. * Make sure to set the error on failure of rcl_action_get\_##_service_name This makes it match the generated code for the action_client. * Reset the errors during RCUTILS_FAULT_INJECTION testing. That way subsequent failures won't print out ugly error strings. * Make sure to return errors in _rcl_parse_resource_match . That is, if rcl_lexer_lookahead2_expect() returns an error, we should pass that along to higher layers rather than just ignoring it. * Don't overwrite error by rcl_validate_enclave_name. It leads to ugly warnings. * Add acomment that rmw_validate_namespace_with_size sets the error * Make sure to reset error in rcl_node_type_cache_init. Otherwise we get a warning about overwriting the error from rcutils_hash_map_init. * Conditionally set error message in rcl_publisher_is_valid. Only when rcl_context_is_valid doesn't set the error. * Don't overwrite error from rcl_node_get_logger_name. It already sets the error in the failure case. * Make sure to reset errors when testing network flow endpoints. That's because some of the RMW implementations may not support this feature, and thus set errors. * Make sure to reset errors in rcl_expand_topic_name. That way we can set more useful errors for the upper layers. * Cleanup wait.c error handling. In particular, make sure to not overwrite errors as we get into error-handling paths, which should clean up warnings we get. * Make sure to reset errors in rcl_lifecycle tests. That way we won't get ugly "overwritten" warnings on subsequent tests. --------- -* Make the event skipping more generic. (`#1197 `__) -* Heavy cleanup of test_events.cpp. (`#1196 `__) -* Cleanup test_graph.cpp. (`#1193 `__) -* Expect a minimum of two nodes to be alive in test_graph (`#1192 `__) -* escalate RCL_RET_ACTION_xxx to 40XX. (`#1191 `__) -* Fix NULL allocator and racy condition. (`#1188 `__) -* Properly initialize the char array used in type hash calculations. (`#1182 `__) -* Increased timeouts (`#1181 `__) -* Skip some event tests on rmw_zenoh (`#1180 `__) -* doc: rcl_logging_spdlog is the default impl. (`#1177 `__) -* Update wait.h documentation for rcl_wait (`#1176 `__) -* Change the starting time of the goal expiration timeout (`#1121 `__) -* Removed deprecated localhost_only (`#1169 `__) -* Fix typo in rcl_validate_enclave_name_with_size() doc (`#1168 `__) -* Removed deprecated rcl_init_timer() (`#1167 `__) -* Cleanup test_count_matched test to handle non-DDS RMWs (`#1164 `__) * Make check_state a class method in test_count_matched. This allows us to pass fewer parameters into each each invocation, and allows us to hide some more of the implementation inside the class. * Rename "ops" to "opts" in test_count_matched. It just better reflects what these structures are. * Cleanup pub/subs with a scope_exit in test_count_matched. This just ensures that they are always cleaned up, even if we exit early. Note that we specifically do *not* use it for test_count_matched_functions, since the cleanup is intentionally interleaved with other tests. * Check with the RMW layer to see whether QoS is compatible. Some RMWs may have different compatibility than DDS, so check with the RMW layer to see what we should expect for the number of publishers and subscriptions. -* Add mechanism to disable workaround for dependency groups (`#1151 `__) -* remap_impl: minor typo (`#1158 `__) -* Fix up rmw_cyclonedds timestamp testing. (`#1156 `__) -* Add 'mimick' label to tests which use Mimick (`#1152 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Felix Penzlin, G.A. vd. Hoorn, Janosch Machowinski, Scott K Logan, Tomoya Fujita, Yadu, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#1218 `__) -* No need to add public symbol visibility macros in implementation. (`#1213 `__) -* fix 'rcl_action_server_configure_action_introspection': inconsistent dll linkage. (`#1212 `__) -* Add new interfaces to enable intropsection for action (`#1207 `__) -* fix(rcl_action): Allow to pass the timer to action during initialization (`#1201 `__) * fix(timer): Use impl pointer in jump callback The interface description does not explicitly state that a rcl_timer_t may not be copied around. Therefore users may do this. By using a known never changing pointer in the callbacks, we avoid segfaults, even if the 'user' decides to copy the rcl_timer_t around. -* Added remapping resolution for action names (`#1170 `__) * Added remapping resolution for action names * Fix cpplint/uncrustify * Simplified returned error codes in case name resolution failes. * Renamed action_name field to remapped_action_name. * Removed unnecessary resolved_action_name stack variable * Added tests for action name remapping. * Add tests for action name remapping using local arguments --------- -* Clean up error handling in many rcl{_action,_lifecycle} codepaths (`#1202 `__) * Shorten the delay in test_action_server setup. Instead of waiting 250ms between setting up 10 goals (for at least 2.5 seconds), just wait 100ms which reduces this to 1 second. * Small style cleanups in test_action_server.cpp * Reset the error in rcl_node_type_cache_register_type(). That is, if rcutils_hash_map_set() fails, it sets its own error, so overriding it with our own will cause a warning to print. Make sure to clear it before setting our own. * Only unregister a clock jump callback if we have installed it. This avoids a warning on cleanup in rcl_timer_init2. * Record the return value from rcl_node_type_cache_register_type. Otherwise, in a failure situation we set the error but we actually return RCL_RET_OK to the upper layers, which is odd. * Get rid of completely unnecessary return value translation. This generated code was translating an RCL error to an RCL error, which doesn't make much sense. Just remove the duplicate code. * Use the rcl_timer_init2 functionality to start the timer disabled. Rather than starting it enabled, and then immediately canceling it. * Don't overwrite the error from rcl_action_goal_handle_get_info() It already sets the error, so rcl_action_server_goal_exists() should not set it again. * Reset errors before setting new ones when checking action validity That way we avoid an ugly warning in the error paths. * Move the copying of the options earlier in rcl_subscription_init. That way when we go to cleanup in the "fail" case, the options actually exist and are valid. This avoids an ugly warning during cleanup. * Make sure to set the error on failure of rcl_action_get\_##_service_name This makes it match the generated code for the action_client. * Reset the errors during RCUTILS_FAULT_INJECTION testing. That way subsequent failures won't print out ugly error strings. * Make sure to return errors in _rcl_parse_resource_match . That is, if rcl_lexer_lookahead2_expect() returns an error, we should pass that along to higher layers rather than just ignoring it. * Don't overwrite error by rcl_validate_enclave_name. It leads to ugly warnings. * Add acomment that rmw_validate_namespace_with_size sets the error * Make sure to reset error in rcl_node_type_cache_init. Otherwise we get a warning about overwriting the error from rcutils_hash_map_init. * Conditionally set error message in rcl_publisher_is_valid. Only when rcl_context_is_valid doesn't set the error. * Don't overwrite error from rcl_node_get_logger_name. It already sets the error in the failure case. * Make sure to reset errors when testing network flow endpoints. That's because some of the RMW implementations may not support this feature, and thus set errors. * Make sure to reset errors in rcl_expand_topic_name. That way we can set more useful errors for the upper layers. * Cleanup wait.c error handling. In particular, make sure to not overwrite errors as we get into error-handling paths, which should clean up warnings we get. * Make sure to reset errors in rcl_lifecycle tests. That way we won't get ugly "overwritten" warnings on subsequent tests. --------- -* Cleanup test_graph.cpp. (`#1193 `__) -* Expect a minimum of two nodes to be alive in test_graph (`#1192 `__) -* escalate RCL_RET_ACTION_xxx to 40XX. (`#1191 `__) -* Fix NULL allocator and racy condition. (`#1188 `__) -* Increased timeouts (`#1181 `__) -* Change the starting time of the goal expiration timeout (`#1121 `__) -* Increase the test_action_interaction timeouts. (`#1172 `__) While I can't reproduce the problem locally, I suspect that waiting only 1 second for the entities to become ready isn't enough in all cases, particularly on Windows, with Connext, and when we are running in parallel with other tests. Thus, increase the timeout for the rcl_wait() in all of the test_action_interaction tests, which should hopefully be enough to make this always pass. -* Stop compiling rcl_action tests multiple times. (`#1165 `__) We don't need to compile the tests once for each RMW; we can just compile it once and then use the RMW_IMPLEMENTATION environment variable to run the tests on the different RMWs. This speeds up compilation. -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Janosch Machowinski, Justus Braun, Tomoya Fujita, Yadu, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* add rcl_print_transition_map. (`#1217 `__) -* Enable test isolation in rcl_lifecycle (`#1216 `__) -* Clean up error handling in many rcl{_action,_lifecycle} codepaths (`#1202 `__) * Shorten the delay in test_action_server setup. Instead of waiting 250ms between setting up 10 goals (for at least 2.5 seconds), just wait 100ms which reduces this to 1 second. * Small style cleanups in test_action_server.cpp * Reset the error in rcl_node_type_cache_register_type(). That is, if rcutils_hash_map_set() fails, it sets its own error, so overriding it with our own will cause a warning to print. Make sure to clear it before setting our own. * Only unregister a clock jump callback if we have installed it. This avoids a warning on cleanup in rcl_timer_init2. * Record the return value from rcl_node_type_cache_register_type. Otherwise, in a failure situation we set the error but we actually return RCL_RET_OK to the upper layers, which is odd. * Get rid of completely unnecessary return value translation. This generated code was translating an RCL error to an RCL error, which doesn't make much sense. Just remove the duplicate code. * Use the rcl_timer_init2 functionality to start the timer disabled. Rather than starting it enabled, and then immediately canceling it. * Don't overwrite the error from rcl_action_goal_handle_get_info() It already sets the error, so rcl_action_server_goal_exists() should not set it again. * Reset errors before setting new ones when checking action validity That way we avoid an ugly warning in the error paths. * Move the copying of the options earlier in rcl_subscription_init. That way when we go to cleanup in the "fail" case, the options actually exist and are valid. This avoids an ugly warning during cleanup. * Make sure to set the error on failure of rcl_action_get\_##_service_name This makes it match the generated code for the action_client. * Reset the errors during RCUTILS_FAULT_INJECTION testing. That way subsequent failures won't print out ugly error strings. * Make sure to return errors in _rcl_parse_resource_match . That is, if rcl_lexer_lookahead2_expect() returns an error, we should pass that along to higher layers rather than just ignoring it. * Don't overwrite error by rcl_validate_enclave_name. It leads to ugly warnings. * Add acomment that rmw_validate_namespace_with_size sets the error * Make sure to reset error in rcl_node_type_cache_init. Otherwise we get a warning about overwriting the error from rcutils_hash_map_init. * Conditionally set error message in rcl_publisher_is_valid. Only when rcl_context_is_valid doesn't set the error. * Don't overwrite error from rcl_node_get_logger_name. It already sets the error in the failure case. * Make sure to reset errors when testing network flow endpoints. That's because some of the RMW implementations may not support this feature, and thus set errors. * Make sure to reset errors in rcl_expand_topic_name. That way we can set more useful errors for the upper layers. * Cleanup wait.c error handling. In particular, make sure to not overwrite errors as we get into error-handling paths, which should clean up warnings we get. * Make sure to reset errors in rcl_lifecycle tests. That way we won't get ugly "overwritten" warnings on subsequent tests. --------- -* Fix NULL allocator and racy condition. (`#1188 `__) -* Fix typo in rcl_lifecycle_com_interface_t doc (`#1174 `__) -* Fix a memory leak in test_rcl_lifecycle. (`#1173 `__) This one came about probably as a result of a bad merge. But essentially we were forcing the srv_change_state com_interface to be nullptr, but forgetting to save off the old pointer early enough. Thus, we could never restore the old one before we went to "fini", and the memory would be leaked. Fix this by remembering the impl pointer earlier. -* Contributors: Chris Lalancette, Christophe Bedard, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_noop `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rcl_logging_interface is only valid path with build environment. (`#122 `__) -* README update and some cleanups. (`#120 `__) -* Contributors: Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_logging_spdlog `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* rcl_logging_interface is only valid path with build environment. (`#122 `__) -* README update and some cleanups. (`#120 `__) -* Updated deprecated API (`#117 `__) -* Contributors: Alejandro Hernández Cordero, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcl_yaml_param_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Cleanup errors after error paths in rcl_yaml_param_parser tests. (`#1203 `__) This gets rid of ugly "overwritten" warnings in the tests. -* Add 'mimick' label to tests which use Mimick (`#1152 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix a race condition (`#2819 `__) -* Remove redundant typesupport check in serialization module (`#2808 `__) -* Remove get_typesupport_handle implementation. (`#2806 `__) -* Use NodeParameterInterface instead of /parameter_event to update "use_sim_time" (`#2378 `__) -* Remove cancel_clock_executor_promise\_. (`#2797 `__) -* Enable parameter update recursively only when QoS override parameters. (`#2742 `__) -* Removed trailing whitespace from the codebase. (`#2791 `__) -* Expanded docstring of ``get_rmw_qos_profile()`` (`#2787 `__) -* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#2776 `__) -* fix: Compilefix for clang (`#2775 `__) -* add exception doc for configure_introspection. (`#2773 `__) -* feat: Add ClockWaiter and ClockConditionalVariable (`#2691 `__) -* doc: Added warning to not instantiate Clock directly with RCL_ROS_TIME (`#2768 `__) -* Use rmw_event_type_is_supported in test_qos_event (`#2761 `__) -* Support action typesupport helper (`#2750 `__) -* use maybe_unused attribute for the portability. (`#2758 `__) -* Executor strong reference fix (`#2745 `__) -* Cleanup of https://github.com/ros2/rclcpp/pull/2683 (`#2714 `__) -* Fix typo in doc section for get_service_typesupport_handle (`#2751 `__) -* Test case and fix for for https://github.com/ros2/rclcpp/issues/2652 (`#2713 `__) -* fix(timer): Delete node, after executor thread terminated (`#2737 `__) -* update doc section for spin_xxx methods. (`#2730 `__) -* fix: Expose timers used by rclcpp::Waitables (`#2699 `__) -* use rmw_qos_profile_rosout_default instead of rcl. (`#2663 `__) -* fix(Executor): Fixed entities not beeing executed after just beeing added (`#2724 `__) -* fix: make the loop condition align with the description (`#2726 `__) -* Collect log messages from rcl, and reset. (`#2720 `__) -* Fix transient local IPC publish (`#2708 `__) -* apply actual QoS from rmw to the IPC publisher. (`#2707 `__) -* Adding in topic name to logging on IPC issues (`#2706 `__) -* fix TestTimeSource.ROS_time_valid_attach_detach. (`#2700 `__) -* Update docstring for ``rclcpp::Node::now()`` (`#2696 `__) -* Re-enable executor test on rmw_connextdds. (`#2693 `__) -* Fix warnings on Windows. (`#2692 `__) -* Omnibus fixes for running tests with Connext. (`#2684 `__) -* fix(Executor): Fix segfault if callback group is deleted during rmw_wait (`#2683 `__) -* accept custom allocator for LoanedMessage. (`#2672 `__) -* a couple of typo fixes in doc section for LoanedMessage. (`#2676 `__) -* Make sure callback_end tracepoint is triggered in AnyServiceCallback (`#2670 `__) -* Correct the incorrect comments in generic_client.hpp (`#2662 `__) -* Fix NodeOptions assignment operator (`#2656 `__) -* set QoS History KEEP_ALL explicitly for statistics publisher. (`#2650 `__) -* Fix test_intra_process_manager.cpp with rmw_zenoh_cpp (`#2653 `__) -* Fixed test_events_executors in zenoh (`#2643 `__) -* rmw_fastrtps supports service event gid uniqueness test. (`#2638 `__) -* print warning if event callback is not supported instead of passing exception. (`#2648 `__) -* Implement callback support of async_send_request for service generic client (`#2614 `__) -* Fixed test qos rmw zenoh (`#2639 `__) -* verify client gid uniqueness for a single service event. (`#2636 `__) -* Skip some tests in test_qos_event and run others with event types supported by rmw_zenoh (`#2626 `__) -* Shutdown the context before context's destructor is invoked in tests (`#2633 `__) -* Skip rmw zenoh content filtering tests (`#2627 `__) -* Use InvalidServiceTypeError for unavailable service type in GenericClient (`#2629 `__) -* Implement generic service (`#2617 `__) -* fix events-executor warm-up bug and add unit-tests (`#2591 `__) -* remove unnecessary gtest-skip in test_executors (`#2600 `__) -* Correct node name in service test code (`#2615 `__) -* Minor naming fixes for ParameterValue to_string() function (`#2609 `__) -* Removed clang warnings (`#2605 `__) -* Fix a couple of issues in the documentation. (`#2608 `__) -* deprecate the static single threaded executor (`#2598 `__) -* Fix name of ParameterEventHandler class in doc (`#2604 `__) -* subscriber_statistics_collectors\_ should be protected by mutex. (`#2592 `__) -* Fix bug in timers lifecycle for events executor (`#2586 `__) -* fix rclcpp/test/rclcpp/CMakeLists.txt to check for the correct targets existance (`#2596 `__) -* Shut down context during init if logging config fails (`#2594 `__) -* Make more of the Waitable API abstract (`#2593 `__) -* Only compile the tests once. (`#2590 `__) -* Updated rcpputils path API (`#2579 `__) -* Make the subscriber_triggered_to_receive_message test more reliable. (`#2584 `__) * Make the subscriber_triggered_to_receive_message test more reliable. In the current code, inside of the timer we create the subscription and the publisher, publish immediately, and expect the subscription to get it immediately. But it may be the case that discovery hasn't even happened between the publisher and the subscription by the time the publish call happens. To make this more reliable, create the subscription and publish *before* we ever create and spin on the timer. This at least gives 100 milliseconds for discovery to happen. That may not be quite enough to make this reliable on all platforms, but in my local testing this helps a lot. Prior to this change I can make this fail one out of 10 times, and after the change I've run 100 times with no failures. -* Have the EventsExecutor use more common code (`#2570 `__) * move notify waitable setup to its own function * move mutex lock to retrieve_entity utility * use entities_need_rebuild\_ atomic bool in events-executors * remove duplicated set_on_ready_callback for notify_waitable * use mutex from base class rather than a new recursive mutex * use current_collection\_ member in events-executor * delay adding notify waitable to collection * postpone clearing the current collection * commonize notify waitable and collection * commonize add/remove node/cbg methods * fix linter errors --------- -* Removed deprecated methods and classes (`#2575 `__) -* Release ownership of entities after spinning cancelled (`#2556 `__) * Release ownership of entities after spinning cancelled * Move release action to every exit point in different spin functions * Move wait_result\_.reset() before setting spinning to false * Update test code * Move test code to test_executors.cpp --------- -* Split test_executors.cpp even further. (`#2572 `__) That's because it is too large for Windows Debug to compile, so split into smaller bits. Even with this split, the file is too big; that's likely because we are using TYPED_TEST here, which generates multiple symbols per test case. To deal with this, without further breaking up the file, also add in the /bigobj flag when compiling on Windows Debug. -* avoid adding notify waitable twice to events-executor collection (`#2564 `__) * avoid adding notify waitable twice to events-executor entities collection * remove redundant mutex lock --------- -* Remove unnecessary msg includes in tests (`#2566 `__) -* Fix copy-paste errors in function docs (`#2565 `__) -* Fix typo in function doc (`#2563 `__) -* Add test creating two content filter topics with the same topic name (`#2546 `__) (`#2549 `__) -* add impl pointer for ExecutorOptions (`#2523 `__) -* Fixup Executor::spin_all() regression fix (`#2517 `__) -* Add 'mimick' label to tests which use Mimick (`#2516 `__) -* Contributors: Abhishek Kashyap, Alberto Soragna, Alejandro Hernández Cordero, Alexis Pojomovsky, Barry Xu, Chris Lalancette, Christophe Bedard, Hsin-Yi, Janosch Machowinski, Jeffery Hsu, Kang, Leander Stephen D'Souza, Patrick Roncagliolo, Pedro de Azeredo, Romain DESILLE, Scott K Logan, Steve Macenski, Tanishq Chaudhary, Tomoya Fujita, William Woodall, Yuyuan Yuan, jmachowinski - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use std::recursive_mutex for action requests. (`#2798 `__) -* Remove warning (`#2790 `__) -* Harden rclcpp_action::convert(). (`#2786 `__) -* Add new interfaces to enable introspection for action (`#2743 `__) -* use maybe_unused attribute for the portability. (`#2758 `__) -* fix: Expose timers used by rclcpp::Waitables (`#2699 `__) -* Collect log messages from rcl, and reset. (`#2720 `__) -* Make ament_cmake a buildtool dependency (`#2689 `__) -* Fix documentation typo in server_goal_handle.hpp (`#2669 `__) -* Increase the timeout for the cppcheck on rclcpp_action. (`#2640 `__) -* add smart pointer macros definitions to action server and client base classes (`#2631 `__) -* Fix typo in function doc (`#2563 `__) -* Add 'mimick' label to tests which use Mimick (`#2516 `__) -* Contributors: Alberto Soragna, Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Janosch Machowinski, Nathan Wiebe Neufeldt, Scott K Logan, Tomoya Fujita, YR - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_components `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Removed trailing whitespace from the codebase. (`#2791 `__) -* add NO_UNDEFINED_SYMBOLS to rclcpp_components_register_node cmake macro (`#2746 `__) (`#2764 `__) -* use maybe_unused attribute for the portability. (`#2758 `__) -* ComponentManager should just ignore unknown extra argument in the bas… (`#2723 `__) -* Add parsing for rest of obvious boolean extra arguments and throw for unsupported ones (`#2685 `__) -* Shutdown the context before context's destructor is invoked in tests (`#2633 `__) -* Fix typo in rclcpp_components benchmark_components (`#2602 `__) -* Updated rcpputils path API (`#2579 `__) -* remove deprecated APIs from component_manager.hpp (`#2585 `__) -* Contributors: Alberto Soragna, Alejandro Hernández Cordero, Christophe Bedard, Jonas Otto, Leander Stephen D'Souza, Tomoya Fujita, rcp1 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclcpp_lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* should pull valid transition before trying to change the state. (`#2774 `__) -* use maybe_unused attribute for the portability. (`#2758 `__) -* Collect log messages from rcl, and reset. (`#2720 `__) -* Update docstring for ``rclcpp::Node::now()`` (`#2696 `__) -* Fix error message in rclcpp_lifecycle::State::reset() (`#2647 `__) -* Shutdown the context before context's destructor is invoked in tests (`#2633 `__) -* LifecycleNode bugfix and add test cases (`#2562 `__) -* Properly test get_service_names_and_types_by_node in rclcpp_lifecycle (`#2599 `__) -* Removed deprecated methods and classes (`#2575 `__) -* Fix the lifecycle tests on RHEL-9. (`#2583 `__) * Fix the lifecycle tests on RHEL-9. The full explanation is in the comment, but basically since RHEL doesn't support mocking_utils::inject_on_return, we have to split out certain tests to make sure resources within a process don't collide. Co-authored-by: Alejandro Hernández Cordero -* revert call shutdown in LifecycleNode destructor (`#2557 `__) -* LifecycleNode shutdown on dtor only with valid context. (`#2545 `__) -* call shutdown in LifecycleNode dtor to avoid leaving the device in unknown state (2nd) (`#2528 `__) -* rclcpp::shutdown should not be called before LifecycleNode dtor. (`#2527 `__) -* Revert "call shutdown in LifecycleNode dtor to avoid leaving the device in un… (`#2450 `__)" (`#2522 `__) -* Add 'mimick' label to tests which use Mimick (`#2516 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Patrick Roncagliolo, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rclpy `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update parameter types (`#1441 `__) -* Add TypeError string arg for better clarity (`#1442 `__) -* Fix loading parameter behavior from yaml file. (`#1193 `__) -* Update ``lifecycle`` types (`#1440 `__) -* Update _rclpy_pybind11.pyi order and add EventsExecutor (`#1436 `__) -* Update Clock Types (`#1433 `__) -* Introduce EventsExecutor implementation (`#1391 `__) -* Fix Duration, Clock, and QoS Docs (`#1428 `__) -* Add exception doc for configure_introspection. (`#1434 `__) -* Fix Task constructor type bug (`#1431 `__) -* Add new interfaces to enable intropsection for action (`#1413 `__) -* Check parameter callback signature during registration. (`#1425 `__) -* Fix function params indentation (`#1426 `__) -* Update Service and Action Protocols (`#1409 `__) -* Remove ``SHARED`` from ``pybind11_add_module`` (`#1305 `__) -* Publish action goal status once accepted before execution. (`#1228 `__) -* Add missing dependencies so that rosdoc2 shows Node (`#1408 `__) -* add QoS Profile/Depth support to Node. (`#1376 `__) -* Various typing fixes (`#1402 `__) -* Add types to Action with rhel roscli fix (`#1361 `__) -* Check if Task(Future) is canceled. (`#1377 `__) -* Executors types (`#1370 `__) -* event_handler.py types (`#1340 `__) -* Add support for operator overloading of ``Duration`` (`#1387 `__) -* Service/Client Implementation types (`#1384 `__) -* avoid lifecycle node transition exception (`#1319 `__) -* Client:call generates TimeoutError exception when it is timed out. (`#1271 `__) -* Add in python3-dev build dependency. (`#1380 `__) -* Fix the race condition while calling rcl_shutdown (`#1353 `__) -* Use @deprecated to mark deprecated APIs for type checkers. (`#1350 `__) -* init (`#1358 `__) -* Avoid redundant done callbacks of the future while repeatedly calling spin_until_future_complete (`#1374 `__) -* Clean qos zenoh tests (`#1369 `__) -* adjust warn message that requested goal is already expired. (`#1363 `__) -* Adds types to Lifecycle Objects (`#1338 `__) -* Remove python_cmake_module use (`#1220 `__) -* TestClient.test_service_timestamps failing consistently. (`#1364 `__) -* Revert "Add types to Action Server and Action Client (`#1349 `__)" (`#1359 `__) -* Revert "Executors types (`#1345 `__)" (`#1360 `__) -* remove mock_compat (`#1357 `__) -* Executors types (`#1345 `__) -* Add types to Action Server and Action Client (`#1349 `__) -* Remove TODO for OpenSplice DDS issue. (`#1354 `__) -* Add types to parameter_client.py (`#1348 `__) -* Add types to Node.py (`#1346 `__) -* Add types to signals.py (`#1344 `__) -* Fixes spin_until_future_complete inside callback (`#1316 `__) -* add types (`#1339 `__) -* Add types to wait_for_message.py and moves Handles into type stubs (`#1325 `__) -* Add types to waitable.py (`#1328 `__) -* Replace rclpyHandle with type stubs (`#1326 `__) -* Fix time subtraction (`#1312 `__) -* Adds types to TypeDescriptionService. (`#1329 `__) -* Import DurationHandle not DurationType (`#1332 `__) -* Creates PublisherHandle and updates publisher.py (`#1310 `__) -* Subscription types (`#1281 `__) -* Add types to qos.py (`#1255 `__) -* minor improvements (`#1330 `__) -* Initialize signal handlers after context (`#1331 `__) -* shutdown ThreadPoolExecutor in MultiThreadedExecutor. (`#1309 `__) -* Generics Services and Clients (`#1275 `__) -* Add types to ParameterService (`#1262 `__) -* Add types to timer.py (`#1260 `__) -* Add types to rcutils_logger.py (`#1249 `__) -* Add types to topic_endpoint_info.oy (`#1253 `__) -* Add types to parameter.py. (`#1246 `__) -* Guard condition types. (`#1252 `__) -* Add types to callback_groups.py (`#1251 `__) -* Utilities.py types. (`#1250 `__) -* reduce result_timeout to 10 secs from 15 mins. (`#1171 `__) -* Add TimerInfo to timer callback. (`#1292 `__) -* Add types to task.py (`#1254 `__) -* Fix a bad bug in fetching the lifecycle transitions. (`#1321 `__) -* Fix a bug when using multiple rclpy.init context managers. (`#1314 `__) -* Executor executes the tasks in FIFO order. (`#1304 `__) -* Add top-level try_shutdown method. (`#1302 `__) -* Make rclpy initialization context-manager aware. (`#1298 `__) -* Docstring specifying proper destruction and creation of Rate, Timer and GuardCondition (`#1286 `__) -* Make timers context-aware. (`#1296 `__) -* Make service lients context-aware. (`#1295 `__) -* Make service servers context-manager aware. (`#1294 `__) -* Make nodes context-manager aware. (`#1293 `__) -* Make subscriptions context-manager aware. (`#1291 `__) -* Make publishers context-manager aware. (`#1289 `__) -* (NumberOfEntities) improve performance (`#1285 `__) -* Using Generics for messages (`#1239 `__) -* Contributors: Alejandro Hernández Cordero, Arjo Chakravarty, Barry Xu, Brad Martin, Chris Lalancette, Christophe Bedard, Elian NEPPEL, Jonathan, Matthijs van der Burgh, Michael Carlstrom, Nadav Elkabets, R Kent James, Shane Loretz, Tomoya Fujita, Wolf Vollprecht, Zahi Kakish - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcpputils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#211 `__) -* Added marco to disable deprecation warnings (`#210 `__) -* Added missing include (`#207 `__) -* Clear the rcutils error when throwing an exception. (`#206 `__) -* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#204 `__) -* fix memory leak for remove_all(). (`#201 `__) -* Suppress clang error because of deprecation (`#199 `__) -* Deprecated path class (`#196 `__) -* Replace create_temp_directory with the new create_temporary_directory (`#198 `__) * Replace create_temp_directory with the new create_temporary_directory - The newly added ``create_temporary_directory(..)`` uses std::filesystem::path and doesn't have platform-specific code. - Also deprecated ``create_temp_directory(..)`` and ``temp_directory_path`` -* Removed deprecated header get_env.hpp (`#195 `__) -* Removed rolling mean accumulator deprecated header (`#194 `__) -* Removed deprecated clamp methods (`#193 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Janosch Machowinski, Michael Carroll, Michael Orlov, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rcutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Handle spaces in start_process arguments on Windows (`#494 `__) -* Add utility functions for invoking a subprocess (`#491 `__) (`#492 `__) -* Add rcutils_join function for concatenating strings (`#490 `__) -* Switch to ament_cmake_ros_core package (`#489 `__) -* Cleanup error handling in rcutils. (`#485 `__) -* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#483 `__) -* Fix setting allocator to NULL. (`#478 `__) -* Add new API to set envar while specifying overwrite (`#473 `__) -* Remove completely unnecessary use of CLASSNAME. (`#471 `__) -* load dll built by MINGW with lib prefix (`#470 `__) -* add mingw support (`#468 `__) -* Fix filesystem iteration on Windows (`#469 `__) -* Add 'mimick' label to tests which use Mimick (`#466 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Felix F Xu, Michael Carroll, Scott K Logan, Yadu - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`resource_retriever `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed clang compile error (`#112 `__) -* Removed windows warnings (`#111 `__) -* Add a plugin mechanism to resource_retriever (`#103 `__) -* uniform MinCMakeVersion (`#108 `__) -* Stop using python_cmake_module. (`#94 `__) -* Allow spaces (`#100 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michael Carroll, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#397 `__) -* Added rmw_event_type_is_supported (`#395 `__) -* add enclave option functions. (`#393 `__) -* a couple of typo fixes for doc section. (`#391 `__) -* update cmake version (`#389 `__) -* get_zero_initialized_xxx functions return zero initialized structure. (`#380 `__) * get_zero_initialized_xxx functions return zero initialized structure. * introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. * add a comment and more tests for rmw_event_type. --------- -* move qos_profile_rosout_default from rcl. (`#381 `__) -* Fix ugly overwritten warning messages on error paths. (`#387 `__) This mostly has to do with calling rmw_reset_error() in the proper time in the tests, but we also change one test for an allocator to properly check for a valid allocator. -* Fix rmw_validate_namespace{_with_size} error handling. (`#386 `__) * Fix rmw_validate_namespace{_with_size} error handling. It should always set an error, even on invalid arguments. -* Fix arg name in rmw_take_response() doc (`#384 `__) -* Initialize the NULL strucutre with static value. (`#378 `__) -* remove rmw_localhost_only_t. (`#376 `__) -* Fix typo with RMW_DURATION_UNSPECIFIED (`#375 `__) -* Fix typo in rmw_validate\_*_with_size() doc (`#374 `__) -* removed deprecated rmw_node_assert_liveliness() (`#373 `__) -* add mingw support (`#370 `__) -* Minor typo fix (`#368 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Felix F Xu, G.A. vd. Hoorn, Michael Carroll, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch buildtool to ament_cmake package (`#183 `__) -* Export a modern CMake target (`#179 `__) -* Added rmw_event_type_is_supported (`#173 `__) -* Contributors: Alejandro Hernández Cordero, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextdds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address cpplit and gcc warnings. (`#184 `__) -* Support topic instances (`#178 `__) -* Switch buildtool to ament_cmake package (`#183 `__) -* Discovery race condition mitigation (`#174 `__) -* Added rmw_event_type_is_supported (`#173 `__) -* use rmw_enclave_options_xxx APIs instead. (`#172 `__) -* fix security certificate error message format. (`#171 `__) -* Use rmw_security_common (`#167 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#169 `__) -* introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. (`#162 `__) -* Instrument client/service for end-to-end request/response tracking (`#163 `__) -* fix: "Failed to parse type hash" message was overly spammy (ros2-50) (`#149 `__) -* remove rmw_localhost_only_t. (`#156 `__) -* Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT (`#150 `__) -* Use rmw_namespace_validation_result_string() in rmw_create_node (`#151 `__) -* Make rmw_destroy_wait_set return RMW_RET_INVALID_ARGUMENT (`#152 `__) -* Contributors: Alejandro Hernández Cordero, Christophe Bedard, Francisco Gallego Salido, Scott K Logan, Shane Loretz, Taxo Rubio RTI, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_connextddsmicro `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Mark the package rmw_connextddsmicro as deprecated (`#182 `__) -* Switch buildtool to ament_cmake package (`#183 `__) -* Added rmw_event_type_is_supported (`#173 `__) -* Contributors: Alejandro Hernández Cordero, Francisco Gallego Salido, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_cyclonedds_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#538 `__) -* Added rmw_event_type_is_supported (`#532 `__) -* use rmw_enclave_options_xxx APIs instead. (`#531 `__) -* use rmw_security_common (`#529 `__) -* introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. (`#518 `__) -* Reset the error before setting a new one. (`#526 `__) -* Instrument client/service for end-to-end request/response tracking (`#521 `__) -* Drop support for float128. (`#522 `__) -* use RMW_GID_STORAGE_SIZE to client_service_id_t. (`#515 `__) -* remove rmw_localhost_only_t. (`#508 `__) -* Fix the triggering of guard conditions. (`#504 `__) When a guard condition goes active, we have to remember to increase the trig_idx so we look at the next trigger. Otherwise, we can get into situations where we skip a triggered member. -* Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT (`#496 `__) -* Use rmw_namespace_validation_result_string() in rmw_create_node (`#497 `__) -* Make rmw_destroy_wait_set return RMW_RET_INVALID_ARGUMENT (`#498 `__) -* Set received_timestamp to system_clock::now() in message_info (`#491 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Erik Boasson, Joe Speed, Jose Tomas Lorente, Michael Orlov, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_dds_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Deprecated security methods (`#77 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address RHEL warnings and missing includes. (`#819 `__) -* Support topic instances (`#753 `__) -* Switch to ament_cmake_ros_core package (`#818 `__) -* Added rmw_event_type_is_supported (`#809 `__) -* use rmw_enclave_options_xxx APIs instead. (`#808 `__) -* Add deprecation warning for FASTRTPS_DEFAULT_PROFILES_FILE (`#806 `__) -* Export a modern CMake target (`#805 `__) -* Changes to build against Fast DDS 3.0 (`#776 `__) -* Fix some overwritten errors in rmw_fastrtps. (`#799 `__) -* Instrument client/service for end-to-end request/response tracking (`#787 `__) -* Contributors: Alejandro Hernández Cordero, Carlos Espinoza Curto, Chris Lalancette, Christophe Bedard, Miguel Company, Scott K Logan, Shane Loretz, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_dynamic_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address RHEL warnings and missing includes. (`#819 `__) -* Support topic instances (`#753 `__) -* Switch to ament_cmake_ros_core package (`#818 `__) -* Make rmw_fastrtps_dynamic_cpp export a modern CMake target (`#814 `__) -* Added rmw_event_type_is_supported (`#809 `__) -* use rmw_enclave_options_xxx APIs instead. (`#808 `__) -* Add deprecation warning for FASTRTPS_DEFAULT_PROFILES_FILE (`#806 `__) -* Changes to build against Fast DDS 3.0 (`#776 `__) -* Fix some overwritten errors in rmw_fastrtps. (`#799 `__) -* Instrument client/service for end-to-end request/response tracking (`#787 `__) -* Add tracing instrumentation to rmw_fastrtps_dynamic_cpp (`#772 `__) -* Contributors: Alejandro Hernández Cordero, Carlos Espinoza Curto, Chris Lalancette, Christophe Bedard, Miguel Company, Scott K Logan, Shane Loretz, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_fastrtps_shared_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Address RHEL warnings and missing includes. (`#819 `__) -* Support topic instances (`#753 `__) -* Switch to ament_cmake_ros_core package (`#818 `__) -* Added rmw_event_type_is_supported (`#809 `__) -* use rmw_enclave_options_xxx APIs instead. (`#808 `__) -* Add deprecation warning for FASTRTPS_DEFAULT_PROFILES_FILE (`#806 `__) -* Use rmw_security_common (`#803 `__) -* introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. (`#785 `__) -* Changes to build against Fast DDS 3.0 (`#776 `__) -* Cleanup one test in rmw_fastrtps_shared_cpp. (`#794 `__) -* Instrument client/service for end-to-end request/response tracking (`#787 `__) -* Drop support for float128. (`#788 `__) -* Keep reference to ``DomainParticipantFactory`` (`#770 `__) -* Use client's reader guid for service introspection event gid (`#781 `__) -* Revert "Unique Client GID for Service Introspectino Event. (`#779 `__)" (`#780 `__) -* Unique Client GID for Service Introspectino Event. (`#779 `__) -* remove rmw_localhost_only_t. (`#773 `__) -* Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT (`#763 `__) -* Use rmw_namespace_validation_result_string() in rmw_create_node (`#765 `__) -* Make rmw_destroy_wait_set return RMW_RET_INVALID_ARGUMENT (`#766 `__) -* Use unique mangled names when creating Content Filter Topics (`#762 `__) -* Add support for data representation (`#756 `__) -* Contributors: Alejandro Hernández Cordero, Carlos Espinoza Curto, Chris Lalancette, Christophe Bedard, Jorge J. Perez, Mario Domínguez López, Miguel Company, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added rmw_event_type_is_supported (`#250 `__) -* Make sure to find_package(rmw) in rmw_implementation. (`#242 `__) -* Add mechanism to disable workaround for dependency groups (`#229 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_implementation_cmake `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* update cmake version (`#389 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_security_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Export rmw dependency (`#400 `__) -* Added rmw_security_common (`#388 `__) -* Contributors: Alejandro Hernández Cordero, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_test_fixture `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Resolve windows warnings in rmw_test_fixture (`#22 `__) -* Add rmw_test_fixture for supporting RMW-isolated testing (`#21 `__) -* Contributors: Alejandro Hernández Cordero, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_test_fixture_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Don't set ROS_AUTOMATIC_DISCOVERY_RANGE in rmw_test_fixture (`#33 `__) -* Fix rmw_test_fixture DLL import on Windows (`#32 `__) -* Fix range for rmw_test_fixture_default port locking (`#31 `__) -* Stop loading RMW to load the test fixture (`#30 `__) -* Add 'default' rmw_test_fixture based on domain_coordinator (`#26 `__) -* Install run_rmw_isolated executable to lib subdirectory (`#25 `__) -* Ignore Ctrl-C in run_rmw_isolated on Windows (`#24 `__) -* Resolve windows warnings in rmw_test_fixture (`#22 `__) -* Add rmw_test_fixture for supporting RMW-isolated testing (`#21 `__) -* Contributors: Alejandro Hernández Cordero, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rmw_zenoh_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Change serialization format in attachment_helpers.cpp (`#601 `__) -* Bump Zenoh to v1.3.2 and improve e2e reliability with HeartbeatSporadic (`#591 `__) -* Implement rmw_test_fixture to start the Zenoh router (`#583 `__) -* Add quality declaration (`#483 `__) -* Trigger qos event callback if there are changes before registration (`#587 `__) -* Set wait_set->triggered flag to false (`#575 `__) -* Add space after ``id`` token in ``rmw_zenohd`` log string (`#576 `__) -* Use ``std::unique_lock`` to unlock correctly on Windows (`#570 `__) -* Switch to std::map for TopicTypeMap (`#546 `__) -* Support zenoh config override (`#551 `__) -* Align the config with the latest Zenoh. (`#556 `__) -* Added documentation note in the code (`#540 `__) -* fix: unlock the mutex before making get (`#537 `__) -* Take wait_set_lock before condition_variable notification for subscriptions (`#528 `__) -* Switch default durability to volatile (`#521 `__) -* Added rmw_event_type_is_supported (`#502 `__) -* Fixed windows warning (`#500 `__) -* Config: tune some values for ROS use case, especially with large number of Nodes (>200) (`#509 `__) -* Honor ignore_local_publications in subscription options (`#508 `__) -* Bump zenoh-cpp to 2a127bb, zenoh-c to 3540a3c, and zenoh to f735bf5 (`#503 `__) -* Fix calculation of current_count_change when event status is updated (`#504 `__) -* Fix checks for invalid arguments (`#497 `__) -* Fail creation of entities if qos contains unknown settings (`#494 `__) -* use rmw_enclave_options_xxx APIs instead. (`#491 `__) -* Enable Zenoh UDP transport (`#486 `__) -* fix: use the default destructor that automatically drops the zenoh reply/query and hence sends the final signal (`#473 `__) -* Introduce the advanced publisher and subscriber (`#368 `__) -* Switch to debug log if topic_name not in topic_map (`#454 `__) -* Bump Zenoh to commit id 3bbf6af (1.2.1 + few commits) (`#456 `__) -* Bump Zenoh to commit id e4ea6f0 (1.2.0 + few commits) (`#446 `__) -* Inform users that peers will not discover and communicate with one another until the router is started (`#440 `__) -* Clear the error after rmw_serialized_message_resize() (`#435 `__) -* Fix ``ZENOH_ROUTER_CHECK_ATTEMPTS`` which was not respected (`#427 `__) -* fix: use the default destructor to drop the member ``Payload`` (`#419 `__) -* Remove ``gid_hash\_`` from ``AttachmentData`` (`#416 `__) -* Sync the config with the default config in Zenoh. (`#396 `__) -* fix: check the context validity before accessing the session (`#403 `__) -* Fix wan't typo (`#400 `__) -* An alternative middleware for ROS 2 based on Zenoh. -* Contributors: Alejandro Hernández Cordero, Alex Day, Bernd Pfrommer, ChenYing Kuo (CY), Chris Lalancette, Christophe Bedard, CihatAltiparmak, Esteve Fernandez, Franco Cipollone, Geoffrey Biggs, Hans-Martin, Hugal31, James Mount, Julien Enoch, Luca Cominardi, Mahmoud Mazouz, Morgan Quigley, Nate Koenig, Patrick Roncagliolo, Scott K Logan, Shivang Vijay, Tim Clephas, Tomoya Fujita, Yadunund, Yuyuan Yuan, methylDragon, yadunund, yellowhatter - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`robot_state_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use ``emplace()`` with ``std::map`` (`#231 `__) -* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#229 `__) -* update urdf model header (`#223 `__) -* Contributors: Alejandro Hernández Cordero, Patrick Roncagliolo - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2action `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow zenoh tests to run with multicast (`#992 `__) -* Support 'ros2 action echo' (`#978 `__) -* Correct the license content (`#979 `__) -* Maintaining consistency of automatically putting time stamps in the service and action calls similiar to publishing in rostopics. (`#961 `__) -* ros2action: add SIGINT handler to manage cancel request. (`#956 `__) -* node name print bug fix with ros2 action info. (`#926 `__) -* Switch to using rclpy.init context manager. (`#918 `__) -* support 'ros2 action find'. (`#917 `__) -* Contributors: Barry Xu, Chris Lalancette, Michael Carroll, Sukhvansh Jain, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add actions replay feature (`#1955 `__) -* Implement actions recording and displaying information about recorded actions features (`#1939 `__) -* Fix for failing test_record_qos_profiles on Windows (`#1949 `__) -* Progress bar for ros2 bag play (`#1836 `__) -* Update CLI play verb metavar (`#1906 `__) -* Add test_xmllint.py to python packages. (`#1879 `__) -* Add support for replaying based on publication timestamp (`#1876 `__) -* Publish clock after delay is over and disable delay on next loops (`#1861 `__) -* Support replaying multiple bags (`#1848 `__) -* Rename rclpy.qos.QoS*Policy to rclpy.qos.*Policy (`#1832 `__) -* Add "--sort" CLI option to the "ros2 bag info" command (`#1804 `__) -* Add cli option compression-threads-priority (`#1768 `__) -* Add computation of size contribution to info verb (`#1726 `__) -* fix(start-offset): allow specifying a start offset of 0 (`#1682 `__) -* Exclude recorded /clock topic when --clock option is specified (`#1646 `__) -* Sweep cleanup in rosbag2 recorder CLI args verification code (`#1633 `__) -* Add --log-level to ros2 bag play and record (`#1625 `__) -* Add optional '--topics' CLI argument for 'ros2 bag record' (`#1632 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Kosuke Takeuchi, Michael Orlov, Nicola Loi, Patrick Roncagliolo, Rein Appeldoorn, Roman, Sanoronas - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow zenoh tests to run with multicast (`#992 `__) -* Rename the test\_{daemon,direct}.py tests. (`#959 `__) -* replace removeprefix with string slicing. (`#953 `__) -* Fix instability in the ros2 daemon. (`#947 `__) -* Drop dependency on python3-pkg-resources (`#946 `__) -* NodeStrategy supports node name argument. (`#941 `__) -* Switch to using the rclpy.init context manager. (`#920 `__) -* Contributors: Chris Lalancette, Michael Carroll, Scott K Logan, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2doctor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow zenoh tests to run with multicast (`#992 `__) -* Skip QoS compatibility test on Zenoh (`#985 `__) -* New flag and code update for its use (`#942 `__) -* Switch to using rclpy.init context manager. (`#918 `__) -* Revamp how we get network information in ros2doctor. (`#910 `__) -* Contributors: Alejandro Hernández Cordero, Angel LoGa, Chris Lalancette, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint to the ament_python packages. (`#423 `__) -* Fix url in setup.py (`#413 `__) -* Add mechanism to disable workaround for dependency groups (`#397 `__) -* Contributors: Chris Lalancette, Scott K Logan, Wei HU - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow zenoh tests to run with multicast (`#992 `__) -* Contributors: Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2lifecycle_test_fixtures `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use target_link_libraries instead of ament_target_dependencies (`#973 `__) -* Contributors: Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2node `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Allow zenoh tests to run with multicast (`#992 `__) -* ros2node requires fully qualified node name. (`#923 `__) -* Switch to using rclpy.init context manager. (`#918 `__) -* Contributors: Chris Lalancette, Michael Carroll, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2param `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix loading parameter behavior from yaml file (`#864 `__) -* Allow zenoh tests to run with multicast (`#992 `__) -* cosmetic fixes for ros2param dump command. (`#933 `__) -* Switch to using rclpy.init context manager. (`#918 `__) -* Contributors: Chris Lalancette, Michael Carroll, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2pkg `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use modern C++17 syntax. (`#982 `__) -* Use target_link_libraries instead of ament_target_dependencies (`#973 `__) -* Try to use the git global user.name for maintainer-name (`#968 `__) -* Update minimum CMake version CMakeLists.txt.em (`#969 `__) -* Add ament_xmllint test by default to ament_python packages. (`#957 `__) -* Drop dependency on python3-pkg-resources (`#946 `__) -* Support empy4 and empy3 (`#921 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Larry Gezelius, Scott K Logan, Sebastian Castro, Shane Loretz, Shynur - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2run `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add signal handler SIGIN/SIGTERM to ros2run (`#899 `__) -* Contributors: Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use ``get_service`` in ``ros2service call`` (`#994 `__) -* Allow zenoh tests to run with multicast (`#992 `__) -* Support QoS options for ``ros2 service call`` (`#966 `__) -* Maintaining consistency of automatically putting time stamps in the service and action calls similiar to publishing in rostopics. (`#961 `__) -* Switch to using the rclpy.init context manager. (`#920 `__) -* Switch to using rclpy.init context manager. (`#918 `__) -* Contributors: Chris Lalancette, Michael Carlstrom, Michael Carroll, Sukhvansh Jain, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in test_xmllint to ros2test. (`#13 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Custom Completion Finder for fetching topic prototype (`#995 `__) -* Documented now and auto keywords (`#1008 `__) -* Conditional deserialization of message for ``ros2 topic hz`` (`#1005 `__) -* Enable ``ros2 topic echo`` with entries of array fields (`#996 `__) -* Allow zenoh tests to run with multicast (`#992 `__) -* Adapt tests to Zenoh (`#988 `__) -* Adjust topic hz and bw command description (`#987 `__) -* Add support for topic QOS for ros2topic bw, delay and hz (`#935 `__) -* Start the simulation from 1 second for the test (`#975 `__) -* Support QoS options for ``ros2 service call`` (`#966 `__) -* Support ros2 topic pub yaml file input (`#925 `__) -* support multiple fields in ros2topic echo (`#964 `__) -* NodeStrategy supports node name argument. (`#941 `__) -* feat(echo --clear): add --clear option to echo (`#819 `__) -* Support multiple topics via ros2 topic hz. (`#929 `__) -* Remove TODO for OpenSplice DDS issue. (`#928 `__) -* Switch to using rclpy.init context manager. (`#918 `__) -* Contributors: Alejandro Hernández Cordero, Anthony Welte, Chris Lalancette, Fabian Thomsen, Florencia, Guillaume Beuzeboc, Kostubh Khandelwal, Leander Stephen D'Souza, Martin Pecka, Michael Carroll, SangtaekLee, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose types for tracing tools (`#153 `__) -* Contributors: Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`ros_environment `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update ROS_DISTRO for Kilted Kaiju (`#41 `__) -* Remove CODEOWNERS. (`#40 `__) -* Contributors: Chris Lalancette, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Support replaying multiple bags (`#1848 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_compression `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bugfix: Update metadata with new file_info before saving it first time (`#1843 `__) -* Make snapshot writing into a new file each time it is triggered (`#1842 `__) -* Add cli option compression-threads-priority (`#1768 `__) -* Bugfix for bag_split event callbacks called to early with file compression (`#1643 `__) -* Fix for regression in ``open_succeeds_twice`` and ``minimal_writer_example`` tests (`#1667 `__) -* Bugfix for writer not being able to open again after closing (`#1599 `__) -* Contributors: Alejandro Hernández Cordero, Michael Orlov, Roman, yschulz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for finding action types message definitions in the ``LocalMessageDefinitionSource`` class to be able to store actions message definitions during recording. (`#1965 `__) -* Add message sequence number to the messages write API (`#1961 `__) -* Implement actions recording and displaying information about recorded actions features (`#1939 `__) -* Set environment variables to run tests with ``rmw_zenoh_cpp`` with multicast discovery (`#1946 `__) -* Add more logging info to storage and reader/writer open operations (`#1881 `__) -* Add PlayerClock::wakeup() to interrupt sleeping (`#1869 `__) -* Support replaying multiple bags (`#1848 `__) -* Bugfix: Update metadata with new file_info before saving it first time (`#1843 `__) -* Make snapshot writing into a new file each time it is triggered (`#1842 `__) -* Bugfix for rosbag2_cpp serialization converter (`#1814 `__) -* Allow unknown types in bag rewrite (`#1812 `__) -* Add computation of size contribution to info verb (`#1726 `__) -* [WIP] Remove rcpputils::fs dependencies in rosbag2 packages (`#1740 `__) -* Removed deprecated write method (`#1738 `__) -* Bugfix for bag_split event callbacks called to early with file compression (`#1643 `__) -* Add topics with zero message counts to the SQLiteStorage::get_metadata(). (`#1725 `__) -* Propagate "custom_data" and "ros_distro" in to the metadata.yaml file during re-indexing (`#1700 `__) -* Bugfix for writer not being able to open again after closing (`#1599 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Christophe Bedard, Cole Tucker, Michael Orlov, Nicola Loi, Tomoya Fujita, Yadunund, yschulz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_examples_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add rosbag2_examples_cpp/simple_bag_reader.cpp. (`#1683 `__) -* Contributors: Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_examples_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* avoid using internal modules for examples. (`#1905 `__) -* Add test_xmllint.py to python packages. (`#1879 `__) -* simple_bag_reader.py should publish the data for each timer callback. (`#1767 `__) -* Change the python examples to use the rclpy context manager. (`#1758 `__) -* Add rosbag2_examples_cpp/simple_bag_reader.cpp. (`#1683 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add message sequence number to the messages write API (`#1961 `__) -* Add actions replay feature (`#1955 `__) -* Implement actions recording and displaying information about recorded actions features (`#1939 `__) -* Add bindings to close method in PyReader and PyCompressionReader (`#1935 `__) -* Remove SHARED from pybind11_add_module (`#1929 `__) -* Progress bar for ros2 bag play (`#1836 `__) -* Upstream quality changes from Apex.AI part 1 (`#1903 `__) -* Add support for replaying based on publication timestamp (`#1876 `__) -* Support replaying multiple bags (`#1848 `__) -* Add in python3-dev build dependency. (`#1863 `__) -* Add "--sort" CLI option to the "ros2 bag info" command (`#1804 `__) -* Remove use of python_cmake_module (`#1570 `__) -* Added method to introspect QoS in Python (`#1648 `__) -* Update CI scripts to use Ubuntu Noble distros and bump action scripts to latest versions (`#1709 `__) -* Add cli option compression-threads-priority (`#1768 `__) -* Add computation of size contribution to info verb (`#1726 `__) -* Bugfix for wrong timestamps in ros2 bag info (`#1745 `__) -* Add bindings for LocalMessageDefinitionSource (`#1697 `__) -* Add --log-level to ros2 bag play and record (`#1625 `__) -* Included to_rclcpp_qos_vector to Python wrappers (`#1642 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Michael Orlov, Nicola Loi, Roman, Sanoronas, Silvio Traversaro, methylDragon, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add message sequence number to the messages write API (`#1961 `__) -* Add actions replay feature (`#1955 `__) -* Add more logging info to storage and reader/writer open operations (`#1881 `__) -* Contributors: Barry Xu, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_mcap `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add message sequence number to the messages write API (`#1961 `__) -* Add actions replay feature (`#1955 `__) -* Upstream quality changes from Apex.AI part 1 (`#1903 `__) -* Add vscode gitignore rule and remove vscode folder (`#1698 `__) -* Contributors: Barry Xu, Michael Orlov, methylDragon - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_storage_sqlite3 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add actions replay feature (`#1955 `__) -* Fix incorrect zero size for sqlite storage (`#1759 `__) -* Fix for failing throws_on_invalid_pragma_in_config_file on Windows (`#1742 `__) -* Add topics with zero message counts to the SQLiteStorage::get_metadata(). (`#1725 `__) -* Contributors: Barry Xu, Michael Orlov, Roman, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add actions replay feature (`#1955 `__) -* Implement actions recording and displaying information about recorded actions features (`#1939 `__) -* Upstream quality changes from Apex.AI part 1 (`#1903 `__) -* Use tmpfs in rosbag2 temporary_directory_fixture (`#1901 `__) -* Add debug information for flaky can_record_again_after_stop test (`#1871 `__) -* Remove use of python_cmake_module (`#1570 `__) -* Improve the reliability of rosbag2 tests (`#1796 `__) -* Small cleanups to the rosbag2 tests. (`#1792 `__) -* [WIP] Remove rcpputils::fs dependencies in rosbag2 packages (`#1740 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Michael Orlov - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_test_msgdefs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add support for finding action types message definitions in the ``LocalMessageDefinitionSource`` class to be able to store actions message definitions during recording. (`#1965 `__) -* Contributors: Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Implement actions recording and displaying information about recorded actions features (`#1939 `__) -* Upstream quality changes from Apex.AI part 1 (`#1903 `__) -* Increase timeout to 180s for test_rosbag2_record_end_to_end (`#1889 `__) -* Add "--sort" CLI option to the "ros2 bag info" command (`#1804 `__) -* Improve the reliability of rosbag2 tests (`#1796 `__) -* Small cleanups to the rosbag2 tests. (`#1792 `__) -* Add computation of size contribution to info verb (`#1726 `__) -* Bugfix for wrong timestamps in ros2 bag info (`#1745 `__) -* Fix for a false negative integration test with bag split in recorder (`#1743 `__) -* Propagate "custom_data" and "ros_distro" in to the metadata.yaml file during re-indexing (`#1700 `__) -* Sweep cleanup in rosbag2 recorder CLI args verification code (`#1633 `__) -* Fix for regression in ``open_succeeds_twice`` and ``minimal_writer_example`` tests (`#1667 `__) -* Add optional '--topics' CLI argument for 'ros2 bag record' (`#1632 `__) -* Bugfix for writer not being able to open again after closing (`#1599 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Cole Tucker, Michael Orlov, Nicola Loi, Sanoronas, yadunund, yschulz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosbag2_transport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add actions replay feature (`#1955 `__) -* Implement actions recording and displaying information about recorded actions features (`#1939 `__) -* Set environment variables to run tests with ``rmw_zenoh_cpp`` with multicast discovery (`#1946 `__) -* Initialize filter with namespaced updated topics and services. (rolling) (`#1944 `__) -* Fix: QoS incompatibilities are not expected with rmw_zenoh_cpp (`#1936 `__) -* Address windows warnings in the progress bar class (`#1927 `__) -* Don't delete existing subscription if failed to create a new one (`#1923 `__) -* Progress bar for ros2 bag play (`#1836 `__) -* Upstream quality changes from Apex.AI part 1 (`#1903 `__) -* Use tmpfs in rosbag2 temporary_directory_fixture (`#1901 `__) -* Bugfix: Recorder discovery does not restart after being stopped (`#1894 `__) -* Bugfix. Event publisher not starting for second run after stop (`#1888 `__) -* Add support for replaying based on publication timestamp (`#1876 `__) -* Publish clock after delay is over and disable delay on next loops (`#1861 `__) -* Add PlayerClock::wakeup() to interrupt sleeping (`#1869 `__) -* Add debug information for flaky can_record_again_after_stop test (`#1871 `__) -* Support replaying multiple bags (`#1848 `__) -* Reintroduce ``Don't warn for unknown types if topics are not selected`` (`#1825 `__) -* Allow unknown types in bag rewrite (`#1812 `__) -* Improve the reliability of rosbag2 tests (`#1796 `__) -* Removed warnings (`#1794 `__) -* Small cleanups to the rosbag2 tests. (`#1792 `__) -* Add cli option compression-threads-priority (`#1768 `__) -* [WIP] Remove rcpputils::fs dependencies in rosbag2 packages (`#1740 `__) -* Bugfix for bag_split event callbacks called to early with file compression (`#1643 `__) -* Bugfix for issue where unable to create composable nodes with compression (`#1679 `__) -* Add support for "all" and "exclude" in RecordOptions YAML decoder (`#1664 `__) -* Add unit tests to cover message's send and received timestamps during recording (`#1641 `__) -* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Michael Orlov, Nicola Loi, Ramon Wijnands, Roderick Taylor, Roman, Yuyuan Yuan, Øystein Sture - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_adapter `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Types for rosidl_adapter (`#828 `__) -* Support empy3 and empy4 (`#821 `__) -* Contributors: Alejandro Hernández Cordero, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Rosidl cli types with ``specs_set`` fix (`#831 `__) -* Contributors: Chris Lalancette, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_core_generators `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add mechanism to disable workaround for dependency groups (`#3 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_core_runtime `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add mechanism to disable workaround for dependency groups (`#3 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_default_runtime `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Minor update to quality declaration (`#27 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_dynamic_typesupport `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#15 `__) -* Bump minimum CMake version to 3.20 (`#14 `__) -* Drop support for long double/float128. (`#12 `__) -* Contributors: Chris Lalancette, Michael Carroll, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_dynamic_typesupport_fastrtps `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#8 `__) -* Changes to build against Fast DDS 3.0 (`#5 `__) -* Drop support for long double/float128. (`#6 `__) -* Contributors: Chris Lalancette, Miguel Company, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#856 `__) -* Deterministic iteration order for reproducible codegen (`#846 `__) -* Add types ``rosidl_pycommon`` (`#824 `__) -* Contributors: Harry Sarson, Michael Carlstrom, Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add name and data_type traits for actions (`#848 `__) -* Add types ``rosidl_pycommon`` (`#824 `__) -* Contributors: Michael Carlstrom, Nathan Wiebe Neufeldt - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_dds_idl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update cmake version requirements (`#64 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix ``__eq__`` for Array fields (`#224 `__) -* Remove use of ament_target_dependencies (`#222 `__) -* Revamp how we check for the correct class. (`#218 `__) -* Remove python_cmake_module and set hints (`#204 `__) -* Add rosidl_generator_py to the rosidl_runtime_packages group (`#212 `__) -* Contributors: Chris Lalancette, Michael Carlstrom, Scott K Logan, Shane Loretz - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add name and data_type traits for actions (`#848 `__) -* Silence one more gcc false-positive. (`#814 `__) -* Switch to using fastjsonschema for schema validation. (`#809 `__) -* Contributors: Chris Lalancette, Nathan Wiebe Neufeldt - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_generator_type_description `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#856 `__) -* Contributors: Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_parser `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Finish adding types to ``rosidl_parser`` (`#832 `__) -* Add types to definition.py in ``rosidl_parser`` (`#791 `__) -* Contributors: Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_pycommon `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_xmllint to rosidl_pycommon. (`#833 `__) -* Add types ``rosidl_pycommon`` (`#824 `__) -* Support empy3 and empy4 (`#821 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#856 `__) -* Implement ``resize`` function for String (`#806 `__) -* Fix u16 docs and improve docs formatting (`#805 `__) -* Contributors: Christophe Bedard, Michael Carroll, WATANABE Aoi - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Suppress warnings in the benchmarks for upstream GCC false positives. (`#810 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_runtime_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use deepcopy in set_message_fields for safety. (`#34 `__) -* Remove CODEOWNERS and mirror-rolling-to-master. (`#31 `__) -* Contributors: Chris Lalancette, Tomoya Fujita - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#166 `__) -* Uniform cmake requirement (`#163 `__) -* Cleanup warning message in rosidl_typesupport_c tests. (`#161 `__) -* Add mechanism to disable workaround for dependency groups (`#157 `__) -* Add 'mimick' label to tests which use Mimick (`#158 `__) -* Contributors: Chris Lalancette, Scott K Logan, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#166 `__) -* Uniform cmake requirement (`#163 `__) -* Add mechanism to disable workaround for dependency groups (`#157 `__) -* Contributors: Scott K Logan, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#127 `__) -* Remove dependency on fastrtps_cmake_module (`#120 `__) -* Remove CODEOWNERS and mirror-rolling-to-master workflow (`#124 `__) -* Remove deprecated functions benchmark tests (`#122 `__) -* Contributors: Chris Lalancette, Miguel Company, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_fastrtps_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#127 `__) -* Remove dependency on fastrtps_cmake_module (`#120 `__) -* Remove CODEOWNERS and mirror-rolling-to-master workflow (`#124 `__) -* Remove deprecated functions benchmark tests (`#122 `__) -* Contributors: Chris Lalancette, Miguel Company, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_c `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#860 `__) -* Add types ``rosidl_pycommon`` (`#824 `__) -* Contributors: Michael Carlstrom, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#860 `__) -* Add types ``rosidl_pycommon`` (`#824 `__) -* Contributors: Michael Carlstrom, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_introspection_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Suppress false positive warnings from gcc. (`#811 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rosidl_typesupport_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake requirement (`#163 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rpyutils `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add py.typed to Package Data (`#16 `__) -* Add Create py.typed (`#15 `__) -* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#13 `__) -* Add types and ament_mypy to rpyutils. (`#12 `__) -* Contributors: Chris Lalancette, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add standard tests for rqt_bag and rqt_bag_plugins (`#171 `__) -* Updated player QoS (`#164 `__) -* Adapted to rosbag2_py (`#156 `__) -* Fixed button icons (`#159 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_bag_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add standard tests for rqt_bag and rqt_bag_plugins (`#171 `__) -* Adapted to rosbag2_py (`#156 `__) -* Fixed image timeline renderer (`#158 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in standard tests. (`#48 `__) -* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#46 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_graph `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in standard tests. (`#104 `__) -* Remove CODEOWNERS (`#102 `__) -* Fixed fit_in_view icon button (`#95 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in standard tests for rqt_gui and rqt_gui_py (`#318 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added common test to rqt_gui_cpp and deprecate h headers (`#311 `__) -* Updated deprecated qt_gui_cpp headers (`#309 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_gui_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in standard tests for rqt_gui and rqt_gui_py (`#318 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_plot `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add unit tests for topic name validation & field expansion (`#108 `__) -* Fix double slash when plotting all sub-fields with trailing slash (`#107 `__) -* Fix listing of nested basic type fields (`#101 `__) -* Fix f-string and add single quote around field name (`#100 `__) -* Add single quotes around topic in validation msg for consistency (`#99 `__) This is more consistent with the other messages below. -* Add in the rest of the standard ament_python tests. (`#98 `__) -* Remove CODEOWNERS (`#96 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_publisher `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in the remaining standard ament_python tests. (`#49 `__) -* Add in LICENSE. (`#46 `__) -* Remove CODEOWNERS (`#47 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Stop using python_cmake_module. (`#304 `__) -* Use an rclpy context manager. (`#312 `__) -* Added common test to rqt_py_common (`#310 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_py_console `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add the standard tests to rqt_py_console. (`#19 `__) -* Remove CODEOWNERS (`#17 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_service_caller `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update rqt_service_caller to our standard policies. (`#31 `__) -* Remove CODEOWNERS (`#29 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_shell `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in standard tests to rqt_shell. (`#24 `__) That way we know it conforms to our standards. -* Remove CODEOWNERS (`#22 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rqt_topic `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Override subscriber qos (`#51 `__) -* Remove CODEOWNERS (`#52 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rti_connext_dds_cmake_module `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update Connext to 7.3.0 (`#181 `__) -* Quiet a warning when CONNEXTDDS_DIR or NDDSHOME is not found. (`#158 `__) -* Contributors: Chris Lalancette, lobolanja - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rttest `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Don't try to build on BSD (`#126 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Expose the possibility to create ROS node with custom ``NodeOptions`` (`#1347 `__) -* uniform CMAKE requirement (`#1335 `__) -* Detect wayland and make sure X rendering is used. (`#1253 `__) -* Fixed RViz2 linters (`#1231 `__) -* Contributors: Alejandro Hernández Cordero, Matthew Elwin, Patrick Roncagliolo, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_assimp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Revert "Update ASSIMP_VENDOR CMakeLists.txt (`#1226 `__)" (`#1249 `__) -* Update ASSIMP_VENDOR CMakeLists.txt (`#1226 `__) CLEAN UNUSED CHECK SE MIN ASSIMP VERSION TO 5.3.1 SET C++ VERSION TO 17 -* Contributors: Chris Lalancette, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_common `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Work in progress using the new resource retriever apis (`#1262 `__) -* addTrackedObject Function Fails to Handle Null Pointer, Causing Crash When nullptr is Passed (`#1375 `__) -* Add test to check mapGetString when key is missing (`#1361 `__) -* UniformStringStream::parseFloat Fails to Handle Invalid Float Formats Correctly (`#1360 `__) -* Fix Potential Null Pointer Dereference in VisualizerApp::getRenderWindow() to Prevent Crashes (`#1359 `__) -* Extend support for type adaptation (REP 2007) in rviz_common for TF-filtered displays (`#1346 `__) -* Expose the possibility to create ROS node with custom ``NodeOptions`` (`#1347 `__) -* uniform CMAKE requirement (`#1335 `__) -* Add basic support for type adaptation (REP 2007) in ``rviz_common`` for displays (`#1331 `__) -* Fix preferred tools loading names (`#1321 `__) -* Add RVIZ_COMMON_PUBLIC macro to ToolManager (`#1323 `__) -* Clean visualization_manager.cpp (`#1317 `__) -* Fix Deprecated tf2 headers (`#1289 `__) -* include QString (`#1298 `__) -* Handle time source exception (`#1285 `__) -* Fully handle ``Tool::processKeyEvent`` return value (`#1270 `__) -* Handle ``Tool::Finished`` returned by ``processKeyEvent`` (`#1257 `__) -* Added more time to copyright on Windwos (`#1252 `__) -* Added common test for rviz_common (`#1232 `__) -* Set ContentsMargins for RenderPanel to 0 to avoid borders in fullscreen mode. Fixes `#1024 `__ (`#1228 `__) -* Updated deprecated message filter headers (`#1239 `__) -* Correclty load icons of panels with whitespaces in their name (`#1241 `__) -* Prepping for qos deprecation (`#1214 `__) -* Replace ESC shortcut for exiting full screen with solution from https://github.com/ros-visualization/rviz/pull/1416 (`#1205 `__) -* Contributors: Alejandro Hernández Cordero, Bo Chen, Lucas Wendland, Matthew Foran, Michael Carroll, Michael Ripperger, Patrick Roncagliolo, RaduPopescu, Silvio Traversaro, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_default_plugins `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* PointCloudDisplay: Fix decay time 0 keeping more than the last message (`#1400 `__) -* Work in progress using the new resource retriever apis (`#1262 `__) -* Include chrono (`#1353 `__) -* fix: add rclcpp::shutdown (`#1343 `__) -* Nv12 color format (`#1318 `__) Co-authored-by: zycczy -* uniform CMAKE requirement (`#1335 `__) -* Initialize lookup table only once at compile time (`#1330 `__) Co-authored-by: Alejandro Hernández Cordero -* Fixed the XY Orbit controller move (`#1327 `__) Co-authored-by: Terry Scott -* Fix Deprecated tf2 headers (`#1289 `__) -* Change EffortDisplay superclass from MessageFilterDisplay to RosTopicDisplay to avoid dropping messages with empty frame_id. (`#1312 `__) -* Fix access control for Accel, Effort and Twist displays (`#1311 `__) -* remove unused variable (`#1301 `__) -* include QString (`#1298 `__) -* Clean code for Image display (`#1271 `__) -* Handle time source exception (`#1285 `__) -* replace deprecated encodings 'yuv422' and 'yuv422_yuy2' (`#1276 `__) -* Update urdf model.h deprecation (`#1266 `__) -* Enabling manual space width for TextViewFacingMarker (`#1261 `__) -* Added more time to copyright on Windwos (`#1252 `__) -* Updated deprecated message filter headers (`#1239 `__) -* Fixed RViz default plugin license linter (`#1230 `__) -* Contributors: Alejandro Hernández Cordero, Christian Rauch, Lucas Wendland, Matthew Foran, Michael Carroll, Patrick Roncagliolo, Peng Wang, Stefan Fabian, Terry Scott, Tom Moore, Yuyuan Yuan, disRecord, mosfet80, quic-zhaoyuan, suchetanrs - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_ogre_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing glew dependency for ogre vendor package (`#1350 `__) -* Use official freetype github mirror instead of savannah (`#1348 `__) -* Fix flags for both clang and gcc. (`#1219 `__) -* Update freetype lib (`#1216 `__) -* Update zlib into CMakeLists.txt (`#1128 `__) Changes in 1.3 (18 Aug 2023) - Remove K&R function definitions and zlib2ansi - Fix bug in deflateBound() for level 0 and memLevel 9 - Fix bug when gzungetc() is used immediately after gzopen() - Fix bug when using gzflush() with a very small buffer - Fix crash when gzsetparams() attempted for transparent write - Fix test/example.c to work with FORCE_STORED - Rewrite of zran in examples (see zran.c version history) - Fix minizip to allow it to open an empty zip file - Fix reading disk number start on zip64 files in minizip - Fix logic error in minizip argument processing - Add minizip testing to Makefile - Read multiple bytes instead of byte-by-byte in minizip unzip.c - Add memory sanitizer to configure (--memory) - Various portability improvements - Various documentation improvements - Various spelling and typo corrections Co-authored-by: Chris Lalancette -* Contributors: Chris Lalancette, Silvio Traversaro, Stefan Fabian, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* BillboardLine::addPoint() does not throw an exception when exceeding max_points_per_line limit (`#1436 `__) -* Constructor ScrewVisual::ScrewVisual does not handle null pointers, leading to crashes (`#1435 `__) -* Removed Windows warnings (`#1413 `__) -* Memory Access Error When Handling Empty Strings in splitStringIntoTrimmedItems Function (`#1412 `__) -* Crash due to Unhandled Null Pointer in ParameterEventsFilter Constructor (`#1411 `__) -* MovableText constructor does not validate invalid character height, default fallback missing (`#1398 `__) -* Invalid Parameter Handling in CovarianceVisual::CovarianceVisual Constructor (`#1396 `__) -* Lack of Validity Check for Invalid Parameters in EffortVisual::EffortVisual Constructor (`#1395 `__) -* Grid Class Constructor Does Not Handle Null Pointer, Leading to Program Crash (`#1394 `__) -* Crash in MovableText::update() when caption is an empty string due to uninitialized resource usage (`#1393 `__) -* Work in progress using the new resource retriever apis (`#1262 `__) -* uniform CMAKE requirement (`#1335 `__) -* Clean ogre_render_window_impl.cpp (`#1334 `__) -* include QString (`#1298 `__) -* Use consistent conditionals in render_system.hpp (`#1294 `__) -* Avoid redefinition of default color materials (`#1281 `__) -* Added more time to copyright on Windwos (`#1252 `__) -* Fix: issue `#1220 `__. (`#1237 `__) Co-authored-by: Alejandro Hernández Cordero -* Added common test: rviz_rendering (`#1233 `__) -* Contributors: Alejandro Hernández Cordero, Masayoshi Dohi, Matthew Foran, Michael Carroll, Scott K Logan, chama1176, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_rendering_tests `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Work in progress using the new resource retriever apis (`#1262 `__) -* uniform CMAKE requirement (`#1335 `__) -* Added common test to rviz_rendering_tests (`#1234 `__) -* Contributors: Alejandro Hernández Cordero, Michael Carroll, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_resource_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Work in progress using the new resource retriever apis (`#1262 `__) -* Contributors: Michael Carroll - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`rviz_visual_testing_framework `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* uniform CMAKE requirement (`#1335 `__) -* Fix Deprecated tf2 headers (`#1289 `__) -* include QString (`#1298 `__) -* Added common test to rviz_visual_testing_framework (`#1235 `__) -* Contributors: Alejandro Hernández Cordero, Lucas Wendland, Matthew Foran, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add NV12 to color formats (`#253 `__) -* Contributors: Lukas Schäper - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sensor_msgs_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add ament_xmllint to sensor_msgs_py. (`#259 `__) -* Fix formatting in sensor_msgs_py (`#248 `__) -* Contributors: Chris Lalancette, Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`service_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sqlite3_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump sqlite3 to 3.45.1 (`#1737 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`sros2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to get_rmw_additional_env (`#339 `__) -* Fix github-workflow mypy error (`#336 `__) -* Give more time to generate policies in tests (`#323 `__) -* Switch to context manager for rclpy tests. (`#322 `__) -* [FIX] remove dangerous mutable default arguments in generate_artifacts (`#318 `__) -* Fix sros2 tests on Windows Debug. (`#317 `__) -* [TESTS] Update tests and add test for generate_artifacts (`#311 `__) -* remove deprecated create_key and list_keys verbs (`#302 `__) -* Fix linux tutorial: cloning example policies and set of default policies for a node (`#295 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Mikael Arguedas, Tomoya Fujita, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Stop using python_cmake_module. (`#536 `__) -* Use rclpy.init context manager where we can. (`#547 `__) This allows us to cleanup, while using a lot less code to try and track it. -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_cli_remapping `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Stop using python_cmake_module. (`#536 `__) -* Use rclpy.init context manager where we can. (`#547 `__) This allows us to cleanup, while using a lot less code to try and track it. -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_communication `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use EnableRmwIsolation in launch tests (`#571 `__) -* Switch to isolated test fixture macros (`#571 `__) -* Add tests for Keyed types (`#568 `__) -* Remove use of ament_target_dependencies (`#566 `__) -* Skip all multi-vendor pub/sub tests with zenoh (`#560 `__) -* Stop using python_cmake_module. (`#536 `__) -* Use rclpy.init context manager where we can. (`#547 `__) This allows us to cleanup, while using a lot less code to try and track it. -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Francisco Gallego Salido, Scott K Logan, Shane Loretz, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_interface_files `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Drop long double from the IDL. (`#22 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_launch_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add python3-pytest-timeout to test_launch_ros. (`#454 `__) -* Autostarting lifecycle nodes and example launch file demo (`#430 `__) -* Add ament_xmllint to the ament_python packages. (`#423 `__) -* Add in a timeout for test_launch_ros. (`#417 `__) -* Fix url in setup.py (`#413 `__) -* Revamp the test_load_composable_nodes test. (`#403 `__) -* Switch to use rclpy.init context manager. (`#402 `__) -* Contributors: Chris Lalancette, Steve Macenski, Tomoya Fujita, Wei HU - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added test messages with keys (`#173 `__) -* Contributors: Francisco Gallego Salido - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_osrf_testing_tools_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Update CMakeLists.txt (`#85 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_quality_of_service `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to isolated test fixture macros (`#571 `__) -* Use rmw_event_type_is_supported to skip tests (`#563 `__) -* Fixed some qos test related with Zenoh (`#551 `__) -* Contributors: Alejandro Hernández Cordero, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rclcpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Use EnableRmwIsolation in launch tests (`#571 `__) -* Ensure test verifies the existence of all spawning nodes (`#558 `__) -* chore: Adopted to API changes in rclcpp (`#556 `__) -* Implement the pure-virtual functions in the Waitable class. (`#548 `__) -* Update deprecated methods (`#546 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Janosch Machowinski, Scott K Logan, Yuyuan Yuan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_rmw_implementation `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added rmw_event_type_is_supported (`#250 `__) * Added rmw_event_check_compatible * fix return typoe * updated name and use in wait_set test --------- -* Update expectations of tests to remain compatible with non-DDS middlewares (`#248 `__) -* use rmw_enclave_options_xxx APIs instead. (`#247 `__) -* Fix up some overwritten errors. (`#246 `__) That is, make sure to clear out errors where we should. We also slightly rewrite some of the testing around unsupported APIs, so that they make more sense. -* Do not deref msg ptr for rmw\_{publish,return}_loaned_message*() (`#240 `__) -* remove rmw_localhost_only_t. (`#239 `__) -* Expect rmw_service_server_is_available to ret RMW_RET_INVALID_ARGUMENT (`#231 `__) -* Expect rmw_destroy_wait_set to ret RMW_RET_INVALID_ARGUMENT (`#234 `__) -* Add test creating two content filter topics with the same topic name (`#230 `__) (`#233 `__) -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Tomoya Fujita, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_ros2trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add timeout to test_ros2trace tests that wait on stdout (`#167 `__) -* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Add ``rclcpp::shutdown`` (`#762 `__) -* Remove many extra conversions from Matrix3x3 to Quaternion (`#741 `__) Co-authored-by: jmachowinski Co-authored-by: Katherine Scott -* Deprecate C Headers (`#720 `__) -* Switch to using a context manager for the python examples. (`#700 `__) That way we can be sure to always clean up, but use less code doing so. -* Contributors: Chris Lalancette, Lucas Wendland, Yuyuan Yuan, kyle-basis, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Run test_tracetools tests against rmw_zenoh_cpp (`#140 `__) -* Use ament_add_ros_isolated\_* in test_tracetools (`#159 `__) -* Instrument client/service for end-to-end request/response tracking (`#145 `__) -* Don't try to build on BSD (`#142 `__) The 'BSD' variable was added in CMake 3.25. Note that variables which are not defined will evaluate to 'False', so this shouldn't regress platforms using CMake versions older than 3.25. -* Refactor and split test_service into test\_{service,client} (`#144 `__) -* Change expected rmw GID array size to 16 bytes (`#138 `__) -* Run test_tracetools tests against rmw_fastrtps_dynamic_cpp too (`#127 `__) -* Make test_tracetools ping pubs/subs transient_local (`#125 `__) -* Run relevant test_tracetools tests with all instrumented rmw impls (`#116 `__) -* Contributors: Christophe Bedard, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`test_tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix or ignore new mypy issues (`#161 `__) -* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) -* Contributors: Christophe Bedard - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2 `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add isnan support (`#780 `__) -* Overflow Issue in durationFromSec() Function when Handling Extremely Large or Small Values (`#785 `__) -* Do not clobber callback handles when cancelling pending transformable requests (`#779 `__) -* Uniform cmake min version (`#764 `__) -* Remove many extra conversions from Matrix3x3 to Quaternion (`#741 `__) Co-authored-by: jmachowinski Co-authored-by: Katherine Scott -* Cleanup deprecation warnings. (`#744 `__) The deprecation warnings were not printing out properly on GCC, at least; it would warn that #warning was not standard, and it would also not print out the actual warning. Also "deprecated" was spelled wrong. Fix all of these issues here. -* Deprecate C Headers (`#720 `__) -* Removed unused var in tf2 (`#735 `__) -* Error String Filled (`#715 `__) -* Removed deprecated enuns (`#699 `__) -* [TimeCache] Improve performance for insertData() and pruneList() (`#680 `__) Co-authored-by: Chris Lalancette -* Removed warning (`#682 `__) -* Add cache_benchmark (`#679 `__) * Add cache_benchmark Co-authored-by: Chris Lalancette -* [cache_unittest] Add direct implementation testing on ordering, pruning (`#678 `__) * [cache_unittest] Add direct implementation testing on ordering, pruning * do getAllItems() approach * Return a reference instead. * mark getAllItems as internal * Fix warning on Windows. Co-authored-by: Chris Lalancette -* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Eric Cousineau, Lucas Wendland, Michael Carlstrom, Timo Röhling, cramke, kyle-basis, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_bullet `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Deprecate C Headers (`#720 `__) -* Contributors: Lucas Wendland, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Deprecate C Headers (`#720 `__) -* Contributors: Lucas Wendland, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_eigen_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Deprecate C Headers (`#720 `__) -* Contributors: Lucas Wendland, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_geometry_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Remove many extra conversions from Matrix3x3 to Quaternion (`#741 `__) Co-authored-by: jmachowinski Co-authored-by: Katherine Scott -* Deprecate C Headers (`#720 `__) -* Add a python3-dev dependency to tf2_py. (`#733 `__) -* Fix tf2_geometry_msgs_INCLUDE_DIRS. (`#729 `__) -* Remove use of python_cmake_module (`#651 `__) -* Contributors: Chris Lalancette, Lucas Wendland, kyle-basis, rkeating-planted - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_kdl `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Fix external docs mappings (`#757 `__) -* tf2_kdl: add python_orocos_kdl_vendor dependency (`#745 `__) * tf2_kdl: add python_orocos_kdl_vendor dependency The tf2_kdl Python API depends on PyKDL, which is provided by python_orocos_kdl_vendor. * tf2_kdl: remove tf2_msgs test dependency This dependency is not needed. -* Deprecate C Headers (`#720 `__) -* Contributors: Ben Wolsieffer, Emmanuel, Lucas Wendland, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Deprecate C Headers (`#720 `__) -* Add a python3-dev dependency to tf2_py. (`#733 `__) -* Remove use of python_cmake_module (`#651 `__) -* Contributors: Chris Lalancette, Lucas Wendland - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform cmake min version (`#764 `__) -* Add ``rclcpp::shutdown`` (`#762 `__) -* Fix external docs mappings (`#757 `__) -* Deprecate C Headers (`#720 `__) -* specified quaternion order to be xyzw (`#718 `__) -* Add configurable TF topics (`#709 `__) -* Adding static transform listener (`#673 `__) -* Updated deprecated message filter headers (`#702 `__) -* Update qos for deprecation (`#695 `__) -* Cli tools documentation (`#653 `__) -* Contributors: Abhishek Kashyap, Alejandro Hernández Cordero, Emmanuel, Lucas Wendland, Ryan, Tom Moore, Yuyuan Yuan, mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_ros_py `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix external docs mappings (`#757 `__) -* Add in the linters for tf2_ros_py. (`#740 `__) -* Adding StaticTransformListener in Python (`#719 `__) -* Add in test_xmllint for geometry2 python packages. (`#725 `__) -* Add configurable TF topics (`#709 `__) -* Fix the time_jump_callback signature. (`#711 `__) -* Switch to using a context manager for the python examples. (`#700 `__) That way we can be sure to always clean up, but use less code doing so. -* Contributors: Chris Lalancette, Emmanuel, Lucas Wendland, Ryan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_sensor_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Deprecate C Headers (`#720 `__) -* Add a python3-dev dependency to tf2_py. (`#733 `__) -* Remove use of python_cmake_module (`#651 `__) -* Contributors: Chris Lalancette, Lucas Wendland - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tf2_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add in test_xmllint for geometry2 python packages. (`#725 `__) -* Add configurable TF topics (`#709 `__) -* [view_frames] log filenames after it's been determined (`#674 `__) -* Contributors: Chris Lalancette, Mikael Arguedas, Ryan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fixed link (`#15 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tlsf_cpp `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Explicitly shutdown context before test exits (`#129 `__) -* Reduce the number of files we compile. (`#125 `__) -* Contributors: Chris Lalancette, yadunund - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_monitor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) -* Contributors: Chris Lalancette - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`topic_statistics_demo `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Uniform CMAKE min VERSION (`#714 `__) -* Contributors: mosfet80 - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Switch to ament_cmake_ros_core package (`#162 `__) -* Instrument client/service for end-to-end request/response tracking (`#145 `__) -* Don't try to build on BSD (`#142 `__) -* Change expected rmw GID array size to 16 bytes (`#138 `__) -* Fix up two different C problems. (`#129 `__) -* Ignore zero-variadic-macro-arguments warnings from lttng-ust macros (`#126 `__) -* Remove deprecated TRACEPOINT macros (`#123 `__) -* Fix type for buffer index argument in tracepoint event declaration. (`#117 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Mattis Kieffer, Michael Carroll, Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_launch `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix or ignore new mypy issues (`#161 `__) -* Improve Python typing annotations (`#152 `__) -* Expose types for tracing tools (`#153 `__) -* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) -* Contributors: Christophe Bedard, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_read `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve Python typing annotations (`#152 `__) -* Expose types for tracing tools (`#153 `__) -* Contributors: Christophe Bedard, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_test `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Fix or ignore new mypy issues (`#161 `__) -* Improve Python typing annotations (`#152 `__) -* Expose types for tracing tools (`#153 `__) -* Run relevant test_tracetools tests with all instrumented rmw impls (`#116 `__) -* Contributors: Christophe Bedard, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`tracetools_trace `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Improve Python typing annotations (`#152 `__) -* Expose types for tracing tools (`#153 `__) -* Remove unnecessary 'type: ignore' comments in tracetools_trace (`#151 `__) -* Instrument client/service for end-to-end request/response tracking (`#145 `__) -* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) -* Contributors: Christophe Bedard, Michael Carlstrom - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`turtlesim `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Create turtlesim_msgs (`#169 `__) -* Add icon for Jazzy. (`#167 `__) -* [teleop_turtle_key] update usage string to match keys captured by keyboard (`#165 `__) -* Contributors: Alejandro Hernández Cordero, Marco A. Gutierrez, Mikael Arguedas - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`turtlesim_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Create turtlesim_msgs (`#169 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`type_description_interfaces `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`unique_identifier_msgs `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add missing build_export_depend on rosidl_core_runtime (`#30 `__) -* Contributors: Scott K Logan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* make linters happy (`#45 `__) -* Added documentation with rosdoc2 (`#40 `__) -* Added commom linters (`#39 `__) -* Use rcutils to log (`#37 `__) -* Enable test_robot_model_parser test (`#38 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`urdf_parser_plugin `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Added commom linters (`#39 `__) -* Contributors: Alejandro Hernández Cordero - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`zenoh_cpp_vendor `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Bump Zenoh to v1.3.2 and improve e2e reliability with HeartbeatSporadic (`#591 `__) -* Add quality declaration (`#483 `__) -* Fix liveliness crash in debug mode (`#544 `__) -* Bump zenoh-cpp to 2a127bb, zenoh-c to 3540a3c, and zenoh to f735bf5 (`#503 `__) -* Enable Zenoh UDP transport (`#486 `__) -* Bump zenoh-c to 261493 and zenoh-cpp to 5dfb68c (`#463 `__) -* Bump Zenoh to commit id 3bbf6af (1.2.1 + few commits) (`#456 `__) -* Bump Zenoh to commit id e4ea6f0 (1.2.0 + few commits) (`#446 `__) -* Bump zenoh-c and zenoh-cpp to 1.1.1 (`#424 `__) -* Update Zenoh version (`#405 `__) -* Vendors zenoh-cpp for rmw_zenoh. -* Contributors: Alejandro Hernández Cordero, ChenYing Kuo (CY), Chris Lalancette, Franco Cipollone, Hugal31, Julien Enoch, Luca Cominardi, Yadunund, Yuyuan Yuan - - -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -`zenoh_security_tools `__ -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -* Add zenoh_security_tools (`#595 `__) -* Contributors: yadunund - - - +.. redirect-from:: + + Releases/Kilted-Kaiju-Complete-Changelog + +ROS 2 Kilted Kaiju Complete Changelog +===================================== + +This page is a list of the complete changes in all ROS 2 core packages since the previous release. + +.. contents:: Table of Contents + :local: + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings +* Update action cpp demos to support setting introspection (`#709 `__) * Update action cpp demos to support setting introspection * Add the missing header file declaration --------- +* Remove action_tutorials_interfaces. (`#701 `__) +* Removed outdated comment (`#699 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`action_tutorials_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update action python demos to support setting introspection (`#708 `__) * Update action python demos to support setting introspection * Correct the errors in the document --------- +* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) +* Remove action_tutorials_interfaces. (`#701 `__) +* Change all of the demos to use the new rclpy context manager. (`#694 `__) +* Contributors: Barry Xu, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_format `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_clang_tidy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* ament_clang_tidy - Fix Reporting when WarningsAsErrors is specified in config (`#397 `__) +* Contributors: Chris Lalancette, Matt Condino + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix headers destination installed by ament_auto_package (`#540 `__) +* Add ament_auto_depend_on_packages to replace ament_target_dependencies (`#571 `__) +* More specific prefix in some cmake_parse_argument calls (`#523 `__) +* Contributors: Kevin Egger, Kotaro Yoshimoto, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Create destination directory during symlink install (`#569 `__) +* Support generator expressions when symlinking install(FILES) (`#560 `__) +* Always symlink TARGET\_{LINKER,SONAME}_FILE on libraries (`#535 `__) +* Fix symlink install of versioned libs on macOS (`#558 `__) +* More specific prefix in some cmake_parse_argument calls (`#523 `__) +* Contributors: Ezra Brooks, Kevin Egger, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gen_version_h `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ALL target for ament_generate_version_header target. (`#526 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_gtest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* set search path args and then append (`#543 `__) +* Contributors: Will + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Don't write Python bytecode when invoking pytest (`#533 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_add_ros_isolated\_{gmock,gtest}_test macros (`#29 `__) +* Switch from 'domain_coordinator' to 'rmw_test_fixture' (`#28 `__) +* Add ament_add_ros_isolated_test function (`#27 `__) +* Split generic parts of ament_cmake_ros into _core package (`#20 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_ros_core `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing build_export_depend on ament_cmake_libraries (`#37 `__) +* Split generic parts of ament_cmake_ros into _core package (`#20 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_target_dependencies `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Deprecate ament_target_dependencies() (`#572 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cmake_vendor_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add explicit git dependency from ament_cmake_vendor_package (`#554 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_copyright `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve ament_copyright performance drastically. (`#515 `__) +* Fix error path for search_copyright_information. (`#491 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cppcheck `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_cpplint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Enable a quiet mode for cpplint (`#532 `__) +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette, Nils-Christian Iseke + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_flake8 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add the rest of the flake8 plugins as dependencies. (`#503 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_index_python `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add py.typed to package_data (`#100 `__) +* Add test_xmllint to ament_index_python. (`#96 `__) +* Add ament_mypy unit test and export types (`#95 `__) +* Contributors: Chris Lalancette, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_auto `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add docu for AMENT_LINT_AUTO_EXCLUDE (`#524 `__) +* Contributors: Alexander Reimann + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_lint_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_mypy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix Windows Regression by removing removesuffix() (`#530 `__) +* Export typing information (`#487 `__) +* Add support for type stubs (`#516 `__) +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_package `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Simplify removing leading and trailing separators (`#152 `__) +* Remove CODEOWNERS and mirror-rolling-to-master. (`#149 `__) +* Always consider .dsv files, even when no shell specific script exists (`#147 `__) +* Contributors: Addisu Z. Taddese, Chris Lalancette, Rob Woolley + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pclint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pycodestyle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_pyflakes `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_uncrustify `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ament_xmllint `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint testing for all packages that we can. (`#508 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`builtin_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_calibration_parsers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#345 `__) +* Added common linters to camera_calibration_parsers (`#317 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_info_manager `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add optional namespace to /set_camera_info service in CameraInfoManager (`#324 `__) +* Added common test to camera info manager (`#318 `__) +* Contributors: Alejandro Hernández Cordero, Jan Hernas + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`camera_info_manager_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup of camera_info_manager_py. (`#340 `__) +* Add ``camera_info_manager_py`` (`#335 `__) +* Bump package version to synchronize with image_common +* Ros2 (`#2 `__) * Run magic converter * Ament_python package * Fix some imports * Remove references to cpp camera info manager. Disable tests * Linting * Fully Remove old tests * Add lint tests * Final tests * Remove pep257 from depends +* changelog +* added CPR maintainer +* Release to Melodic and Noetic +* Only use rostest when testing enabled, thanks to Lukas Bulwahn. +* Move repository to ros-perception. +* Add namespace parameter to constructor, so a driver can handle multiple cameras. Enhancement thanks to Martin Llofriu. +* Make unit tests conditional on ``CATKIN_ENABLE_TESTING``. +* Release to Groovy and Hydro. +* Set null calibration even when URL invalid (#7). +* Release to Groovy and Hydro. +* Convert to catkin. +* Remove roslib dependency. +* Release to Groovy and Hydro. +* Initial Python camera_info_manager release to Fuerte. +* Contributors: Alejandro Hernández Cordero, Chris Iverach-Brereton, Chris Lalancette, Jack O'Quin, José Mastrangelo, Lucas Walter, Lukas Bulwahn, Martin Pecka, Michael Hosmar, mllofriu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Fix typo in composition comment (`#703 `__) +* Change references from "jazzy" to "rolling" on the rolling branch. (`#687 `__) +* [composition] add launch action console output in the verify section (`#677 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Mikael Arguedas, Shane Loretz, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) +* [demo_nodes_cpp] some readme and executable name fixups (`#678 `__) +* Fix gcc warnings when building with optimizations. (`#672 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Mikael Arguedas, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_cpp_native `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Contributors: Shane Loretz, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`demo_nodes_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Revert "fix loading parameter behavior from yaml file. (`#656 `__)" (`#660 `__)" (`#661 `__) +* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) +* Change all of the demos to use the new rclpy context manager. (`#694 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`domain_coordinator `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_xmllint to domain_coordinator. (`#17 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_map_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Contributors: Shane Loretz, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_robot_bringup `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`dummy_sensors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Update dummy_sensors readme to echo the correct topic (`#675 `__) +* Contributors: Shane Loretz, jmackay2, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_async_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_cbg_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Removed outdated comment (`#388 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Removed outdated comment (`#388 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_composition `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_minimal_timer `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_multithreaded_executor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclcpp_wait_set `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#404 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_executors `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_guard_conditions `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_action_server `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Add guard on Python single goal action server example (`#380 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette, Ruddick Lawrence + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_client `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Use a single executor instance for spinning in client_async_callback. (`#382 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address flake8 errors for examples_rclpy_minimal_publisher (`#410 `__) +* Add publisher_member_function_with_wait_for_all_acked.py (`#407 `__) +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_minimal_subscriber `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_rclpy_pointcloud_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in ament_xmllint for the ament_python packages. (`#397 `__) +* Switch to using the rclpy context manager everywhere. (`#389 `__) +* Update the shutdown handling in all of the Python examples. (`#379 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`examples_tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in test_xmllint for geometry2 python packages. (`#725 `__) +* Switch to using a context manager for the python examples. (`#700 `__) That way we can be sure to always clean up, but use less code doing so. +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`foonathan_memory_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve mechanism to find an installation of foonathan_memory (#67) + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Complete Removal of PoseStampedArray (`#270 `__) +* Move geometry_msgs/PoseStampedArray to nav_msgs/Goals (`#269 `__) +* Add PoseStampedArray (`#262 `__) +* Contributors: Tony Najjar, Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gmock_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump minimum CMake version to 3.15 (`#31 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`google_benchmark_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump minimum CMake version to 3.10 (`#35 `__) +* Remove CODEOWNERS and mirror-rolling-to-main workflow. (`#31 `__) +* Contributors: Chris Lalancette, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gtest_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump minimum CMake version to 3.15 (`#33 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gz_cmake_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version to 4.1.1 (`#13 `__) +* Bump version to 4.1.0 (`#11 `__) +* Bump version to 4.0.0 (`#10 `__) +* Fixes the cmake-config used during find_package (`#8 `__) The provided cmake-config was not actually working if one did ``` find_package(gz_cmake_vendor) find_package(gz-cmake) ``` This because the config file tried to create aliases to targets that don't exist. For example, gz-cmake4::gz-cmake4 is not exported by gz-cmake. +* Remove the BUILD_DOCS cmake argument. (`#9 `__) It is apparently deprecated in newer Gazebo. +* Apply prerelease suffix and remove patch (`#7 `__) +* Upgrade to Ionic +* Contributors: Addisu Z. Taddese, Chris Lalancette, Steve Peters + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gz_math_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version to 8.1.1 (`#10 `__) +* Bump version to 8.1.0 (`#8 `__) * This is a rerelease since #7 did not actually bump the version of the vendored package. +* Bump version to 8.1.0 (`#7 `__) +* Bump version to 8.0.0 (`#5 `__) +* Apply prerelease suffix (`#4 `__) +* Upgrade to Ionic +* Update vendored package version to 7.5.0 +* Contributors: Addisu Z. Taddese, Carlos Agüero, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`gz_utils_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump version to 3.1.1 (`#10 `__) +* Bump version to 3.1.0 (`#8 `__) +* Bump version to 3.0.0 (`#7 `__) +* Add in a dependency on spdlog_vendor. (`#6 `__) * Add in a dependency on spdlog_vendor. That way when building on e.g. Windows, the paths to spdlog will be setup properly before trying to build this vendor package. * Also remove the spdlog dependency. That's because we will just depend on the vendor package to provide that dependency for us as necessary. --------- +* Remove the BUILD_DOCS cmake argument. (`#5 `__) It is apparently deprecated in newer Gazebo. +* Apply prerelease suffix (`#4 `__) +* Upgrade to Ionic +* Contributors: Addisu Z. Taddese, Carlos Agüero, Chris Lalancette, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Lint image_tools/CMakeLists.txt (`#712 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) +* Contributors: Alejandro Hernández Cordero, mosfet80, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove windows warnings (`#350 `__) +* Add ``rclcpp::shutdown`` (`#347 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#345 `__) +* feat: python bindings for image_transport and publish (`#323 `__) Co-authored-by: Alejandro Hernández Cordero +* Apply remappings to base topic before creating transport-specific topics (`#326 `__) +* Add lazy subscription to republisher (`#325 `__) +* Fix node name (`#321 `__) +* Updated deprecated message filter headers (`#320 `__) +* Removed outdated comment (`#319 `__) +* Preparing for qos deprecation (`#315 `__) +* Removed warning (`#312 `__) +* Support zero-copy intra-process publishing (`#306 `__) +* Add missing sub and pub options (`#308 `__) Co-authored-by: Angsa Deployment Team +* Contributors: Alejandro Hernández Cordero, Błażej Sowa, Földi Tamás, Lucas Wendland, Michal Sojka, Shane Loretz, Tony Najjar, Yuyuan Yuan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`image_transport_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in python3-dev build dependency (`#334 `__) +* feat: python bindings for image_transport and publish (`#323 `__) Co-authored-by: Alejandro Hernández Cordero +* Contributors: Chris Lalancette, Földi Tamás + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`interactive_markers `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Deprecating tf2 C Headers (`#109 `__) +* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#110 `__) +* Use non deprecated API (`#108 `__) +* Contributors: Alejandro Hernández Cordero, Lucas Wendland + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`intra_process_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) +* Removed pre-compiler check for opencv3 (`#695 `__) +* [intra_process_demo] executable name in README.md fix-up (`#690 `__) +* Contributors: Alejandro Hernández Cordero, Trushant Adeshara, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`kdl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update urdf model header (`#85 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`laser_geometry `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Deprecating tf2 C Headers (`#98 `__) +* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#100 `__) +* Stop using python_cmake_module. (`#93 `__) +* Added common linters (`#96 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Lucas Wendland + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Provide copy of launch configs to TimerAction's entities (`#836 `__) +* Allow concatenating each path component of PathJoinSubstitution (`#838 `__) +* Add StringJoinSubstitution substitution (`#843 `__) +* Add missing test_depend for launch (`#850 `__) +* Document substitutions concatenation in architecture doc (`#845 `__) +* Update docs to use proper RST literals (`#837 `__) +* Fix function params indentation (`#833 `__) +* Add ForEach action to repeat entities using iteration-specific values (`#802 `__) +* Create py.typed (`#828 `__) +* Improve error reporting by adding file locations to exceptions (`#823 `__) +* add test coverage for substitution edgecases involving E notation (`#824 `__) +* Cleanup the launch dependencies. (`#819 `__) +* Fix 'set up' typo (`#813 `__) +* Add test_xmllint to all of the ament_python packages. (`#804 `__) +* Fix typo in comment (`#783 `__) +* Contributors: Chris Lalancette, Christian Ruf, Christophe Bedard, Michael Carlstrom, Roland Arsenault, danielcranston + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_pytest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup the launch dependencies. (`#819 `__) +* Add test_xmllint to all of the ament_python packages. (`#804 `__) +* Switch to using an rclpy context manager. (`#787 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove the slash stripping since leading slash matters (`#456 `__) +* Fixing lifecycle node autostart issue `#445 `__ (`#449 `__) +* Change docstring markdown code blocks to RST (`#450 `__) +* Autostarting lifecycle nodes and example launch file demo (`#430 `__) +* Add YAML dumper representator for str type to keep quotes always. (`#436 `__) +* Mock launch components causing rosdoc2 to fail Python API (`#425 `__) +* Add ament_xmllint to the ament_python packages. (`#423 `__) +* Fix url in setup.py (`#413 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Olivia/F.F., R Kent James, Steve Macenski, Tomoya Fujita, Wei HU + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix function params indentation (`#833 `__) +* Cleanup the launch dependencies. (`#819 `__) +* Add test_xmllint to all of the ament_python packages. (`#804 `__) +* Add mechanism to disable workaround for dependency groups (`#775 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ament_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add CMake parameter to override launch_testing module (`#854 `__) +* Stop using python_cmake_module. (`#760 `__) +* Don't write Python bytecode when invoking launch tests (`#785 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_examples `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_xmllint.py. (`#401 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_testing_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* ``WaitForTopics``: let the user inject a trigger function to be executed after starting the subscribers (`#356 `__) +* Add EnableRmwIsolation action for starting rmw_test_fixture (`#459 `__) +* Fix function params indentation (`#446 `__) +* Add ament_xmllint to the ament_python packages. (`#423 `__) +* Switch to use rclpy.init context manager. (`#402 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Giorgio Pintaudi, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_xml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ForEach action to repeat entities using iteration-specific values (`#802 `__) +* Stop loading extensions during launch\_{xml,yaml} tests. (`#820 `__) +* Cleanup the launch dependencies. (`#819 `__) +* Add test_xmllint to all of the ament_python packages. (`#804 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`launch_yaml `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ForEach action to repeat entities using iteration-specific values (`#802 `__) +* Stop loading extensions during launch\_{xml,yaml} tests. (`#820 `__) +* Cleanup the launch dependencies. (`#819 `__) +* Add test_xmllint to all of the ament_python packages. (`#804 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libcurl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* uniform MinCMakeVersion (`#108 `__) +* Add "lib" to the Windows curl search path. (`#96 `__) In CMake 3.3, a commit made it so that the find_package module in CMake had a compatibility mode where it would automatically search for packages in a /lib subdirectory. In CMake 3.6, this compatibility mode was reverted for all platforms *except* Windows. That means that since CMake 3.3, we haven't actually been using the path as specified in ``curl_DIR``, but we have instead been inadvertently relying on that fallback behavior. In CMake 3.28, that compatibilty mode was also removed for Windows, meaning that we are now failing to find_package(curl) in downstream packages (like resource_retriever). Fix this by adding in the "lib" directory that always should have been there. I'll note that this *only* affects our Windows builds, because this code is in a if(WIN32) block. +* Contributors: Chris Lalancette, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`liblz4_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in a library prefix for lz4 from conda on Windows. (`#1846 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libstatistics_collector `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump codecov/codecov-action from 4.5.0 to 4.6.0 +* Fix MovingAverageStatistics::max\_ Default Value (`#201 `__) +* Removed deprecated classes (`#200 `__) +* fix: add void annotation (`#194 `__) +* Contributors: Alejandro Hernández Cordero, Daisuke Nishimatsu, Jeffery Hsu, dependabot[bot] + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`libyaml_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Only set CRT_SECURE_NO_WARNINGS if it hasn't already been set. (`#64 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Contributors: Shane Loretz, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lifecycle_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) +* Change all of the demos to use the new rclpy context manager. (`#694 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`logging_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`lttngpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove SHARED from pybind11_add_module (`#154 `__) +* Add python3-dev build_depend to lttngpy. (`#146 `__) +* Don't try to build on BSD (`#142 `__) +* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) +* Remove python_cmake_module use. (`#91 `__) +* Add missing dependency on pkg-config to lttngpy (`#130 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Nathan Wiebe Neufeldt, Scott K Logan, Silvio Traversaro + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mcap_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update mcap (`#1774 `__) Update mcap cpp to last version +* Update mcap-releases-cpp- into CMakeLists.txt (`#1612 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`message_filters `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed windows warnings (`#171 `__) +* More generic subscriber implementation using NodeInterfaces from rclcpp (`#113 `__) +* Feature/time sequencer python (`#156 `__) +* Add sync_arrival_time flag to ApproximateTimeSynchronizer (`#166 `__) +* fix: add ``rclcpp::shutdown`` (`#167 `__) +* fix typo: Cache.getLastestTime -> Cache.getLatestTime (`#165 `__) +* Add temporal offset between topics between ApproximateTimeSynchronizer (`#154 `__) +* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#158 `__) +* Updated Python docs (`#150 `__) +* Adds an input aligner filter (`#148 `__) +* Stop using python_cmake_module. (`#114 `__) +* Fix the wording in the deprecation messages. (`#144 `__) +* Apply some simplifications and deduplications to ExactTime sync policy (`#142 `__) +* Minor fixes for `#93 `__ (`#143 `__) +* Bugfix/segfault when getting surrounding interval of empty cache (`#116 `__) +* Migrate to C++11 variadic templates (`#93 `__) +* [LatestTimeSync] Fix crash when Synchronizeris started before the messges are available. (`#137 `__) +* Fix cppcheck warning on Windwos (`#138 `__) +* Adding ament_lint_common (`#120 `__) +* Deprecating all C headers (`#135 `__) +* Cleanups (`#134 `__) +* fix link of index.rst in README.md (`#133 `__) +* Revert "Adding explicit constructors (`#129 `__)" (`#132 `__) +* fix: fallback Time used incorrect clock (`#118 `__) +* Adding explicit constructors (`#129 `__) +* Deprecated qos_profile in Subscriber (`#127 `__) +* Adding cpplint (`#125 `__) +* Move Docs From Wiki (`#119 `__) +* Adding lint_cmake (`#126 `__) +* Adding Uncrustify Changes (`#124 `__) +* Adding Copyright Linter (`#122 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christopher Wecht, Clément Chupin, Dominik, Dr. Denis, Iván López Broceño, Kalvik, Lucas Wendland, Matthias Holoch, Michal Staniaszek, Russ, Saif Sidhik, Sascha Arnold, Yuyuan Yuan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`mimick_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update hash to fix windows failures (`#39 `__) +* Update to the commit that includes DT_GNU_HASH. (`#37 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`nav_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Move geometry_msgs/PoseStampedArray to nav_msgs/Goals (`#269 `__) +* Contributors: Tully Foote + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`orocos_kdl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use the same cmake version (`#36 `__) +* Resolve compatibility issue with newer cmake (`#35 `__) +* fix: add cxx_standard to avoid c++ check error (`#30 `__) +* Ensure that orocos_kdl_vendor doesn't accidentally find itself. (`#27 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Homalozoa X, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Merge pull request `#103 `__ from christophebedard/christophebedard/fix-typo-on-each-verb +* Align stdeb dependencies with setup.py (`#101 `__) Follow-up to 4b2f3a8e4969f33dced1dc2db2296230e7a55b1d +* Add '+upstream' suffix to published deb version (`#102 `__) Using a debian version suffix which falls late alphabetically appears to give our packages preference by apt. If a user enables a repository which distributes packages created by OSRF or ROS, it is likely that they wish to use these packages instead of the ones packaged by their platform. +* Upload coverage results to codecov (`#100 `__) +* Update ci.yaml (`#96 `__) fix node.js <20 deprecation Co-authored-by: Scott K Logan +* Updated python version (`#97 `__) Python version 3.7 is no longer supported as of June 27, 2023 Co-authored-by: Scott K Logan +* Resolve outstanding resource warnings when running tests (`#99 `__) +* Update deb platforms for release (`#95 `__) Added: * Ubuntu Noble (24.04 LTS pre-release) * Debian Trixie (testing) Dropped: * Debian Bullseye (oldstable) Retained: * Debian Bookworm (stable) * Ubuntu Focal (20.04 LTS) * Ubuntu Jammy (22.04 LTS) +* Remove CODEOWNERS. (`#98 `__) It is out of date and no longer serving its intended purpose. +* Contributors: Chris Lalancette, Christophe Bedard, Scott K Logan, Steven! Ragnarök, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`osrf_testing_tools_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update CMakeLists.txt (`#85 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_control `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#711 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#707 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pendulum_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`performance_test_fixture `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix a warning when building on Ubuntu Noble. (`#26 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`pluginlib `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Heavily cleanup pluginlib. (`#265 `__) +* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#268 `__) +* Fix Minor Spelling Mistakes (`#260 `__) +* Removed deprecated method (`#256 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, David V. Lu!! + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`point_cloud_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ``rclcpp::shutdown`` (`#110 `__) +* Updated deprecated message filter headers (`#94 `__) +* Removed warning (`#89 `__) +* republisher: qos override pub and sub (`#88 `__) +* Stop using ament_target_dependencies. (`#86 `__) We are slowly moving away from its use, so stop using it here. While we are in here, notice some things that makes this easier: 1. pluginlib is absolutely a public dependency of this package. Because of that, we can just rely on the PUBLIC export of it, and we don't need to link it into every test. But that also means we don't need some of the forward-declarations that were in loader_fwds.hpp, as we can just get those through the header file. 2. republish.hpp doesn't really need to exist at all. That's because it is only a header file, but the implementation is in an executable. Thus, no downstream could ever use it. So just remove the file and put the declaration straight into the cpp file. +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Yuyuan Yuan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`point_cloud_transport_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in dependency on python3-dev. (`#103 `__) +* Remove use of python_cmake_module. (`#63 `__) +* remove extra semicolon (`#98 `__) +* Contributors: Chris Lalancette, Manu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_orocos_kdl_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* fix: use fetchcontent_makeavailable to fix CMP0169 (`#32 `__) +* Remove the use of python_cmake_module (`#26 `__) +* Contributors: Chris Lalancette, Homalozoa X + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`python_qt_binding `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Skip running the tests on Windows Debug. (`#142 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_dotgraph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Convert qt_dotgraph to a pure Python package. (`#300 `__) +* Cleanup qt_dotgraph and make the tests more robust. (`#296 `__) +* Skip running the tests on Windows Debug. (`#292 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`qt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#302 `__) +* Add common linters and make them happy to qt_gui_cpp (`#295 `__) +* Deprecated h headers (`#294 `__) +* Contributors: Alejandro Hernández Cordero, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) demo_nodes_cpp/CMakeLists.txt require cmake min version 3.12 other modules cmake 3.5. It is proposed to standardize with version 3.12. This also fixes cmake <3.10 deprecation warnings +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`quality_of_service_demo_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) +* Change all of the demos to use the new rclpy context manager. (`#694 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#1218 `__) +* Fix typo in message header include in doc (`#1219 `__) +* use rmw_event_type_is_supported (`#1214 `__) +* No need to add public symbol visibility macros in implementation. (`#1213 `__) +* Add new interfaces to enable intropsection for action (`#1207 `__) +* Use FASTDDS_DEFAULT_PROFILES_FILE instead. (`#1211 `__) +* Relieve timer test period not to miss the cycle. (`#1209 `__) +* fix(rcl_action): Allow to pass the timer to action during initialization (`#1201 `__) * fix(timer): Use impl pointer in jump callback The interface description does not explicitly state that a rcl_timer_t may not be copied around. Therefore users may do this. By using a known never changing pointer in the callbacks, we avoid segfaults, even if the 'user' decides to copy the rcl_timer_t around. +* move qos_profile_rosout_default to rmw. (`#1195 `__) +* Update example usage for rcl_wait_set_init to pass correct number of args (`#1204 `__) +* Clean up error handling in many rcl{_action,_lifecycle} codepaths (`#1202 `__) * Shorten the delay in test_action_server setup. Instead of waiting 250ms between setting up 10 goals (for at least 2.5 seconds), just wait 100ms which reduces this to 1 second. * Small style cleanups in test_action_server.cpp * Reset the error in rcl_node_type_cache_register_type(). That is, if rcutils_hash_map_set() fails, it sets its own error, so overriding it with our own will cause a warning to print. Make sure to clear it before setting our own. * Only unregister a clock jump callback if we have installed it. This avoids a warning on cleanup in rcl_timer_init2. * Record the return value from rcl_node_type_cache_register_type. Otherwise, in a failure situation we set the error but we actually return RCL_RET_OK to the upper layers, which is odd. * Get rid of completely unnecessary return value translation. This generated code was translating an RCL error to an RCL error, which doesn't make much sense. Just remove the duplicate code. * Use the rcl_timer_init2 functionality to start the timer disabled. Rather than starting it enabled, and then immediately canceling it. * Don't overwrite the error from rcl_action_goal_handle_get_info() It already sets the error, so rcl_action_server_goal_exists() should not set it again. * Reset errors before setting new ones when checking action validity That way we avoid an ugly warning in the error paths. * Move the copying of the options earlier in rcl_subscription_init. That way when we go to cleanup in the "fail" case, the options actually exist and are valid. This avoids an ugly warning during cleanup. * Make sure to set the error on failure of rcl_action_get\_##_service_name This makes it match the generated code for the action_client. * Reset the errors during RCUTILS_FAULT_INJECTION testing. That way subsequent failures won't print out ugly error strings. * Make sure to return errors in _rcl_parse_resource_match . That is, if rcl_lexer_lookahead2_expect() returns an error, we should pass that along to higher layers rather than just ignoring it. * Don't overwrite error by rcl_validate_enclave_name. It leads to ugly warnings. * Add acomment that rmw_validate_namespace_with_size sets the error * Make sure to reset error in rcl_node_type_cache_init. Otherwise we get a warning about overwriting the error from rcutils_hash_map_init. * Conditionally set error message in rcl_publisher_is_valid. Only when rcl_context_is_valid doesn't set the error. * Don't overwrite error from rcl_node_get_logger_name. It already sets the error in the failure case. * Make sure to reset errors when testing network flow endpoints. That's because some of the RMW implementations may not support this feature, and thus set errors. * Make sure to reset errors in rcl_expand_topic_name. That way we can set more useful errors for the upper layers. * Cleanup wait.c error handling. In particular, make sure to not overwrite errors as we get into error-handling paths, which should clean up warnings we get. * Make sure to reset errors in rcl_lifecycle tests. That way we won't get ugly "overwritten" warnings on subsequent tests. --------- +* Make the event skipping more generic. (`#1197 `__) +* Heavy cleanup of test_events.cpp. (`#1196 `__) +* Cleanup test_graph.cpp. (`#1193 `__) +* Expect a minimum of two nodes to be alive in test_graph (`#1192 `__) +* escalate RCL_RET_ACTION_xxx to 40XX. (`#1191 `__) +* Fix NULL allocator and racy condition. (`#1188 `__) +* Properly initialize the char array used in type hash calculations. (`#1182 `__) +* Increased timeouts (`#1181 `__) +* Skip some event tests on rmw_zenoh (`#1180 `__) +* doc: rcl_logging_spdlog is the default impl. (`#1177 `__) +* Update wait.h documentation for rcl_wait (`#1176 `__) +* Change the starting time of the goal expiration timeout (`#1121 `__) +* Removed deprecated localhost_only (`#1169 `__) +* Fix typo in rcl_validate_enclave_name_with_size() doc (`#1168 `__) +* Removed deprecated rcl_init_timer() (`#1167 `__) +* Cleanup test_count_matched test to handle non-DDS RMWs (`#1164 `__) * Make check_state a class method in test_count_matched. This allows us to pass fewer parameters into each each invocation, and allows us to hide some more of the implementation inside the class. * Rename "ops" to "opts" in test_count_matched. It just better reflects what these structures are. * Cleanup pub/subs with a scope_exit in test_count_matched. This just ensures that they are always cleaned up, even if we exit early. Note that we specifically do *not* use it for test_count_matched_functions, since the cleanup is intentionally interleaved with other tests. * Check with the RMW layer to see whether QoS is compatible. Some RMWs may have different compatibility than DDS, so check with the RMW layer to see what we should expect for the number of publishers and subscriptions. +* Add mechanism to disable workaround for dependency groups (`#1151 `__) +* remap_impl: minor typo (`#1158 `__) +* Fix up rmw_cyclonedds timestamp testing. (`#1156 `__) +* Add 'mimick' label to tests which use Mimick (`#1152 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Felix Penzlin, G.A. vd. Hoorn, Janosch Machowinski, Scott K Logan, Tomoya Fujita, Yadu, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#1218 `__) +* No need to add public symbol visibility macros in implementation. (`#1213 `__) +* fix 'rcl_action_server_configure_action_introspection': inconsistent dll linkage. (`#1212 `__) +* Add new interfaces to enable intropsection for action (`#1207 `__) +* fix(rcl_action): Allow to pass the timer to action during initialization (`#1201 `__) * fix(timer): Use impl pointer in jump callback The interface description does not explicitly state that a rcl_timer_t may not be copied around. Therefore users may do this. By using a known never changing pointer in the callbacks, we avoid segfaults, even if the 'user' decides to copy the rcl_timer_t around. +* Added remapping resolution for action names (`#1170 `__) * Added remapping resolution for action names * Fix cpplint/uncrustify * Simplified returned error codes in case name resolution failes. * Renamed action_name field to remapped_action_name. * Removed unnecessary resolved_action_name stack variable * Added tests for action name remapping. * Add tests for action name remapping using local arguments --------- +* Clean up error handling in many rcl{_action,_lifecycle} codepaths (`#1202 `__) * Shorten the delay in test_action_server setup. Instead of waiting 250ms between setting up 10 goals (for at least 2.5 seconds), just wait 100ms which reduces this to 1 second. * Small style cleanups in test_action_server.cpp * Reset the error in rcl_node_type_cache_register_type(). That is, if rcutils_hash_map_set() fails, it sets its own error, so overriding it with our own will cause a warning to print. Make sure to clear it before setting our own. * Only unregister a clock jump callback if we have installed it. This avoids a warning on cleanup in rcl_timer_init2. * Record the return value from rcl_node_type_cache_register_type. Otherwise, in a failure situation we set the error but we actually return RCL_RET_OK to the upper layers, which is odd. * Get rid of completely unnecessary return value translation. This generated code was translating an RCL error to an RCL error, which doesn't make much sense. Just remove the duplicate code. * Use the rcl_timer_init2 functionality to start the timer disabled. Rather than starting it enabled, and then immediately canceling it. * Don't overwrite the error from rcl_action_goal_handle_get_info() It already sets the error, so rcl_action_server_goal_exists() should not set it again. * Reset errors before setting new ones when checking action validity That way we avoid an ugly warning in the error paths. * Move the copying of the options earlier in rcl_subscription_init. That way when we go to cleanup in the "fail" case, the options actually exist and are valid. This avoids an ugly warning during cleanup. * Make sure to set the error on failure of rcl_action_get\_##_service_name This makes it match the generated code for the action_client. * Reset the errors during RCUTILS_FAULT_INJECTION testing. That way subsequent failures won't print out ugly error strings. * Make sure to return errors in _rcl_parse_resource_match . That is, if rcl_lexer_lookahead2_expect() returns an error, we should pass that along to higher layers rather than just ignoring it. * Don't overwrite error by rcl_validate_enclave_name. It leads to ugly warnings. * Add acomment that rmw_validate_namespace_with_size sets the error * Make sure to reset error in rcl_node_type_cache_init. Otherwise we get a warning about overwriting the error from rcutils_hash_map_init. * Conditionally set error message in rcl_publisher_is_valid. Only when rcl_context_is_valid doesn't set the error. * Don't overwrite error from rcl_node_get_logger_name. It already sets the error in the failure case. * Make sure to reset errors when testing network flow endpoints. That's because some of the RMW implementations may not support this feature, and thus set errors. * Make sure to reset errors in rcl_expand_topic_name. That way we can set more useful errors for the upper layers. * Cleanup wait.c error handling. In particular, make sure to not overwrite errors as we get into error-handling paths, which should clean up warnings we get. * Make sure to reset errors in rcl_lifecycle tests. That way we won't get ugly "overwritten" warnings on subsequent tests. --------- +* Cleanup test_graph.cpp. (`#1193 `__) +* Expect a minimum of two nodes to be alive in test_graph (`#1192 `__) +* escalate RCL_RET_ACTION_xxx to 40XX. (`#1191 `__) +* Fix NULL allocator and racy condition. (`#1188 `__) +* Increased timeouts (`#1181 `__) +* Change the starting time of the goal expiration timeout (`#1121 `__) +* Increase the test_action_interaction timeouts. (`#1172 `__) While I can't reproduce the problem locally, I suspect that waiting only 1 second for the entities to become ready isn't enough in all cases, particularly on Windows, with Connext, and when we are running in parallel with other tests. Thus, increase the timeout for the rcl_wait() in all of the test_action_interaction tests, which should hopefully be enough to make this always pass. +* Stop compiling rcl_action tests multiple times. (`#1165 `__) We don't need to compile the tests once for each RMW; we can just compile it once and then use the RMW_IMPLEMENTATION environment variable to run the tests on the different RMWs. This speeds up compilation. +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Janosch Machowinski, Justus Braun, Tomoya Fujita, Yadu, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* add rcl_print_transition_map. (`#1217 `__) +* Enable test isolation in rcl_lifecycle (`#1216 `__) +* Clean up error handling in many rcl{_action,_lifecycle} codepaths (`#1202 `__) * Shorten the delay in test_action_server setup. Instead of waiting 250ms between setting up 10 goals (for at least 2.5 seconds), just wait 100ms which reduces this to 1 second. * Small style cleanups in test_action_server.cpp * Reset the error in rcl_node_type_cache_register_type(). That is, if rcutils_hash_map_set() fails, it sets its own error, so overriding it with our own will cause a warning to print. Make sure to clear it before setting our own. * Only unregister a clock jump callback if we have installed it. This avoids a warning on cleanup in rcl_timer_init2. * Record the return value from rcl_node_type_cache_register_type. Otherwise, in a failure situation we set the error but we actually return RCL_RET_OK to the upper layers, which is odd. * Get rid of completely unnecessary return value translation. This generated code was translating an RCL error to an RCL error, which doesn't make much sense. Just remove the duplicate code. * Use the rcl_timer_init2 functionality to start the timer disabled. Rather than starting it enabled, and then immediately canceling it. * Don't overwrite the error from rcl_action_goal_handle_get_info() It already sets the error, so rcl_action_server_goal_exists() should not set it again. * Reset errors before setting new ones when checking action validity That way we avoid an ugly warning in the error paths. * Move the copying of the options earlier in rcl_subscription_init. That way when we go to cleanup in the "fail" case, the options actually exist and are valid. This avoids an ugly warning during cleanup. * Make sure to set the error on failure of rcl_action_get\_##_service_name This makes it match the generated code for the action_client. * Reset the errors during RCUTILS_FAULT_INJECTION testing. That way subsequent failures won't print out ugly error strings. * Make sure to return errors in _rcl_parse_resource_match . That is, if rcl_lexer_lookahead2_expect() returns an error, we should pass that along to higher layers rather than just ignoring it. * Don't overwrite error by rcl_validate_enclave_name. It leads to ugly warnings. * Add acomment that rmw_validate_namespace_with_size sets the error * Make sure to reset error in rcl_node_type_cache_init. Otherwise we get a warning about overwriting the error from rcutils_hash_map_init. * Conditionally set error message in rcl_publisher_is_valid. Only when rcl_context_is_valid doesn't set the error. * Don't overwrite error from rcl_node_get_logger_name. It already sets the error in the failure case. * Make sure to reset errors when testing network flow endpoints. That's because some of the RMW implementations may not support this feature, and thus set errors. * Make sure to reset errors in rcl_expand_topic_name. That way we can set more useful errors for the upper layers. * Cleanup wait.c error handling. In particular, make sure to not overwrite errors as we get into error-handling paths, which should clean up warnings we get. * Make sure to reset errors in rcl_lifecycle tests. That way we won't get ugly "overwritten" warnings on subsequent tests. --------- +* Fix NULL allocator and racy condition. (`#1188 `__) +* Fix typo in rcl_lifecycle_com_interface_t doc (`#1174 `__) +* Fix a memory leak in test_rcl_lifecycle. (`#1173 `__) This one came about probably as a result of a bad merge. But essentially we were forcing the srv_change_state com_interface to be nullptr, but forgetting to save off the old pointer early enough. Thus, we could never restore the old one before we went to "fini", and the memory would be leaked. Fix this by remembering the impl pointer earlier. +* Contributors: Chris Lalancette, Christophe Bedard, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_noop `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rcl_logging_interface is only valid path with build environment. (`#122 `__) +* README update and some cleanups. (`#120 `__) +* Contributors: Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_logging_spdlog `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* rcl_logging_interface is only valid path with build environment. (`#122 `__) +* README update and some cleanups. (`#120 `__) +* Updated deprecated API (`#117 `__) +* Contributors: Alejandro Hernández Cordero, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcl_yaml_param_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Cleanup errors after error paths in rcl_yaml_param_parser tests. (`#1203 `__) This gets rid of ugly "overwritten" warnings in the tests. +* Add 'mimick' label to tests which use Mimick (`#1152 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix a race condition (`#2819 `__) +* Remove redundant typesupport check in serialization module (`#2808 `__) +* Remove get_typesupport_handle implementation. (`#2806 `__) +* Use NodeParameterInterface instead of /parameter_event to update "use_sim_time" (`#2378 `__) +* Remove cancel_clock_executor_promise\_. (`#2797 `__) +* Enable parameter update recursively only when QoS override parameters. (`#2742 `__) +* Removed trailing whitespace from the codebase. (`#2791 `__) +* Expanded docstring of ``get_rmw_qos_profile()`` (`#2787 `__) +* Set envars to run tests with rmw_zenoh_cpp with multicast discovery (`#2776 `__) +* fix: Compilefix for clang (`#2775 `__) +* add exception doc for configure_introspection. (`#2773 `__) +* feat: Add ClockWaiter and ClockConditionalVariable (`#2691 `__) +* doc: Added warning to not instantiate Clock directly with RCL_ROS_TIME (`#2768 `__) +* Use rmw_event_type_is_supported in test_qos_event (`#2761 `__) +* Support action typesupport helper (`#2750 `__) +* use maybe_unused attribute for the portability. (`#2758 `__) +* Executor strong reference fix (`#2745 `__) +* Cleanup of https://github.com/ros2/rclcpp/pull/2683 (`#2714 `__) +* Fix typo in doc section for get_service_typesupport_handle (`#2751 `__) +* Test case and fix for for https://github.com/ros2/rclcpp/issues/2652 (`#2713 `__) +* fix(timer): Delete node, after executor thread terminated (`#2737 `__) +* update doc section for spin_xxx methods. (`#2730 `__) +* fix: Expose timers used by rclcpp::Waitables (`#2699 `__) +* use rmw_qos_profile_rosout_default instead of rcl. (`#2663 `__) +* fix(Executor): Fixed entities not beeing executed after just beeing added (`#2724 `__) +* fix: make the loop condition align with the description (`#2726 `__) +* Collect log messages from rcl, and reset. (`#2720 `__) +* Fix transient local IPC publish (`#2708 `__) +* apply actual QoS from rmw to the IPC publisher. (`#2707 `__) +* Adding in topic name to logging on IPC issues (`#2706 `__) +* fix TestTimeSource.ROS_time_valid_attach_detach. (`#2700 `__) +* Update docstring for ``rclcpp::Node::now()`` (`#2696 `__) +* Re-enable executor test on rmw_connextdds. (`#2693 `__) +* Fix warnings on Windows. (`#2692 `__) +* Omnibus fixes for running tests with Connext. (`#2684 `__) +* fix(Executor): Fix segfault if callback group is deleted during rmw_wait (`#2683 `__) +* accept custom allocator for LoanedMessage. (`#2672 `__) +* a couple of typo fixes in doc section for LoanedMessage. (`#2676 `__) +* Make sure callback_end tracepoint is triggered in AnyServiceCallback (`#2670 `__) +* Correct the incorrect comments in generic_client.hpp (`#2662 `__) +* Fix NodeOptions assignment operator (`#2656 `__) +* set QoS History KEEP_ALL explicitly for statistics publisher. (`#2650 `__) +* Fix test_intra_process_manager.cpp with rmw_zenoh_cpp (`#2653 `__) +* Fixed test_events_executors in zenoh (`#2643 `__) +* rmw_fastrtps supports service event gid uniqueness test. (`#2638 `__) +* print warning if event callback is not supported instead of passing exception. (`#2648 `__) +* Implement callback support of async_send_request for service generic client (`#2614 `__) +* Fixed test qos rmw zenoh (`#2639 `__) +* verify client gid uniqueness for a single service event. (`#2636 `__) +* Skip some tests in test_qos_event and run others with event types supported by rmw_zenoh (`#2626 `__) +* Shutdown the context before context's destructor is invoked in tests (`#2633 `__) +* Skip rmw zenoh content filtering tests (`#2627 `__) +* Use InvalidServiceTypeError for unavailable service type in GenericClient (`#2629 `__) +* Implement generic service (`#2617 `__) +* fix events-executor warm-up bug and add unit-tests (`#2591 `__) +* remove unnecessary gtest-skip in test_executors (`#2600 `__) +* Correct node name in service test code (`#2615 `__) +* Minor naming fixes for ParameterValue to_string() function (`#2609 `__) +* Removed clang warnings (`#2605 `__) +* Fix a couple of issues in the documentation. (`#2608 `__) +* deprecate the static single threaded executor (`#2598 `__) +* Fix name of ParameterEventHandler class in doc (`#2604 `__) +* subscriber_statistics_collectors\_ should be protected by mutex. (`#2592 `__) +* Fix bug in timers lifecycle for events executor (`#2586 `__) +* fix rclcpp/test/rclcpp/CMakeLists.txt to check for the correct targets existance (`#2596 `__) +* Shut down context during init if logging config fails (`#2594 `__) +* Make more of the Waitable API abstract (`#2593 `__) +* Only compile the tests once. (`#2590 `__) +* Updated rcpputils path API (`#2579 `__) +* Make the subscriber_triggered_to_receive_message test more reliable. (`#2584 `__) * Make the subscriber_triggered_to_receive_message test more reliable. In the current code, inside of the timer we create the subscription and the publisher, publish immediately, and expect the subscription to get it immediately. But it may be the case that discovery hasn't even happened between the publisher and the subscription by the time the publish call happens. To make this more reliable, create the subscription and publish *before* we ever create and spin on the timer. This at least gives 100 milliseconds for discovery to happen. That may not be quite enough to make this reliable on all platforms, but in my local testing this helps a lot. Prior to this change I can make this fail one out of 10 times, and after the change I've run 100 times with no failures. +* Have the EventsExecutor use more common code (`#2570 `__) * move notify waitable setup to its own function * move mutex lock to retrieve_entity utility * use entities_need_rebuild\_ atomic bool in events-executors * remove duplicated set_on_ready_callback for notify_waitable * use mutex from base class rather than a new recursive mutex * use current_collection\_ member in events-executor * delay adding notify waitable to collection * postpone clearing the current collection * commonize notify waitable and collection * commonize add/remove node/cbg methods * fix linter errors --------- +* Removed deprecated methods and classes (`#2575 `__) +* Release ownership of entities after spinning cancelled (`#2556 `__) * Release ownership of entities after spinning cancelled * Move release action to every exit point in different spin functions * Move wait_result\_.reset() before setting spinning to false * Update test code * Move test code to test_executors.cpp --------- +* Split test_executors.cpp even further. (`#2572 `__) That's because it is too large for Windows Debug to compile, so split into smaller bits. Even with this split, the file is too big; that's likely because we are using TYPED_TEST here, which generates multiple symbols per test case. To deal with this, without further breaking up the file, also add in the /bigobj flag when compiling on Windows Debug. +* avoid adding notify waitable twice to events-executor collection (`#2564 `__) * avoid adding notify waitable twice to events-executor entities collection * remove redundant mutex lock --------- +* Remove unnecessary msg includes in tests (`#2566 `__) +* Fix copy-paste errors in function docs (`#2565 `__) +* Fix typo in function doc (`#2563 `__) +* Add test creating two content filter topics with the same topic name (`#2546 `__) (`#2549 `__) +* add impl pointer for ExecutorOptions (`#2523 `__) +* Fixup Executor::spin_all() regression fix (`#2517 `__) +* Add 'mimick' label to tests which use Mimick (`#2516 `__) +* Contributors: Abhishek Kashyap, Alberto Soragna, Alejandro Hernández Cordero, Alexis Pojomovsky, Barry Xu, Chris Lalancette, Christophe Bedard, Hsin-Yi, Janosch Machowinski, Jeffery Hsu, Kang, Leander Stephen D'Souza, Patrick Roncagliolo, Pedro de Azeredo, Romain DESILLE, Scott K Logan, Steve Macenski, Tanishq Chaudhary, Tomoya Fujita, William Woodall, Yuyuan Yuan, jmachowinski + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use std::recursive_mutex for action requests. (`#2798 `__) +* Remove warning (`#2790 `__) +* Harden rclcpp_action::convert(). (`#2786 `__) +* Add new interfaces to enable introspection for action (`#2743 `__) +* use maybe_unused attribute for the portability. (`#2758 `__) +* fix: Expose timers used by rclcpp::Waitables (`#2699 `__) +* Collect log messages from rcl, and reset. (`#2720 `__) +* Make ament_cmake a buildtool dependency (`#2689 `__) +* Fix documentation typo in server_goal_handle.hpp (`#2669 `__) +* Increase the timeout for the cppcheck on rclcpp_action. (`#2640 `__) +* add smart pointer macros definitions to action server and client base classes (`#2631 `__) +* Fix typo in function doc (`#2563 `__) +* Add 'mimick' label to tests which use Mimick (`#2516 `__) +* Contributors: Alberto Soragna, Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Janosch Machowinski, Nathan Wiebe Neufeldt, Scott K Logan, Tomoya Fujita, YR + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_components `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Removed trailing whitespace from the codebase. (`#2791 `__) +* add NO_UNDEFINED_SYMBOLS to rclcpp_components_register_node cmake macro (`#2746 `__) (`#2764 `__) +* use maybe_unused attribute for the portability. (`#2758 `__) +* ComponentManager should just ignore unknown extra argument in the bas… (`#2723 `__) +* Add parsing for rest of obvious boolean extra arguments and throw for unsupported ones (`#2685 `__) +* Shutdown the context before context's destructor is invoked in tests (`#2633 `__) +* Fix typo in rclcpp_components benchmark_components (`#2602 `__) +* Updated rcpputils path API (`#2579 `__) +* remove deprecated APIs from component_manager.hpp (`#2585 `__) +* Contributors: Alberto Soragna, Alejandro Hernández Cordero, Christophe Bedard, Jonas Otto, Leander Stephen D'Souza, Tomoya Fujita, rcp1 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclcpp_lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* should pull valid transition before trying to change the state. (`#2774 `__) +* use maybe_unused attribute for the portability. (`#2758 `__) +* Collect log messages from rcl, and reset. (`#2720 `__) +* Update docstring for ``rclcpp::Node::now()`` (`#2696 `__) +* Fix error message in rclcpp_lifecycle::State::reset() (`#2647 `__) +* Shutdown the context before context's destructor is invoked in tests (`#2633 `__) +* LifecycleNode bugfix and add test cases (`#2562 `__) +* Properly test get_service_names_and_types_by_node in rclcpp_lifecycle (`#2599 `__) +* Removed deprecated methods and classes (`#2575 `__) +* Fix the lifecycle tests on RHEL-9. (`#2583 `__) * Fix the lifecycle tests on RHEL-9. The full explanation is in the comment, but basically since RHEL doesn't support mocking_utils::inject_on_return, we have to split out certain tests to make sure resources within a process don't collide. Co-authored-by: Alejandro Hernández Cordero +* revert call shutdown in LifecycleNode destructor (`#2557 `__) +* LifecycleNode shutdown on dtor only with valid context. (`#2545 `__) +* call shutdown in LifecycleNode dtor to avoid leaving the device in unknown state (2nd) (`#2528 `__) +* rclcpp::shutdown should not be called before LifecycleNode dtor. (`#2527 `__) +* Revert "call shutdown in LifecycleNode dtor to avoid leaving the device in un… (`#2450 `__)" (`#2522 `__) +* Add 'mimick' label to tests which use Mimick (`#2516 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Patrick Roncagliolo, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rclpy `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update parameter types (`#1441 `__) +* Add TypeError string arg for better clarity (`#1442 `__) +* Fix loading parameter behavior from yaml file. (`#1193 `__) +* Update ``lifecycle`` types (`#1440 `__) +* Update _rclpy_pybind11.pyi order and add EventsExecutor (`#1436 `__) +* Update Clock Types (`#1433 `__) +* Introduce EventsExecutor implementation (`#1391 `__) +* Fix Duration, Clock, and QoS Docs (`#1428 `__) +* Add exception doc for configure_introspection. (`#1434 `__) +* Fix Task constructor type bug (`#1431 `__) +* Add new interfaces to enable intropsection for action (`#1413 `__) +* Check parameter callback signature during registration. (`#1425 `__) +* Fix function params indentation (`#1426 `__) +* Update Service and Action Protocols (`#1409 `__) +* Remove ``SHARED`` from ``pybind11_add_module`` (`#1305 `__) +* Publish action goal status once accepted before execution. (`#1228 `__) +* Add missing dependencies so that rosdoc2 shows Node (`#1408 `__) +* add QoS Profile/Depth support to Node. (`#1376 `__) +* Various typing fixes (`#1402 `__) +* Add types to Action with rhel roscli fix (`#1361 `__) +* Check if Task(Future) is canceled. (`#1377 `__) +* Executors types (`#1370 `__) +* event_handler.py types (`#1340 `__) +* Add support for operator overloading of ``Duration`` (`#1387 `__) +* Service/Client Implementation types (`#1384 `__) +* avoid lifecycle node transition exception (`#1319 `__) +* Client:call generates TimeoutError exception when it is timed out. (`#1271 `__) +* Add in python3-dev build dependency. (`#1380 `__) +* Fix the race condition while calling rcl_shutdown (`#1353 `__) +* Use @deprecated to mark deprecated APIs for type checkers. (`#1350 `__) +* init (`#1358 `__) +* Avoid redundant done callbacks of the future while repeatedly calling spin_until_future_complete (`#1374 `__) +* Clean qos zenoh tests (`#1369 `__) +* adjust warn message that requested goal is already expired. (`#1363 `__) +* Adds types to Lifecycle Objects (`#1338 `__) +* Remove python_cmake_module use (`#1220 `__) +* TestClient.test_service_timestamps failing consistently. (`#1364 `__) +* Revert "Add types to Action Server and Action Client (`#1349 `__)" (`#1359 `__) +* Revert "Executors types (`#1345 `__)" (`#1360 `__) +* remove mock_compat (`#1357 `__) +* Executors types (`#1345 `__) +* Add types to Action Server and Action Client (`#1349 `__) +* Remove TODO for OpenSplice DDS issue. (`#1354 `__) +* Add types to parameter_client.py (`#1348 `__) +* Add types to Node.py (`#1346 `__) +* Add types to signals.py (`#1344 `__) +* Fixes spin_until_future_complete inside callback (`#1316 `__) +* add types (`#1339 `__) +* Add types to wait_for_message.py and moves Handles into type stubs (`#1325 `__) +* Add types to waitable.py (`#1328 `__) +* Replace rclpyHandle with type stubs (`#1326 `__) +* Fix time subtraction (`#1312 `__) +* Adds types to TypeDescriptionService. (`#1329 `__) +* Import DurationHandle not DurationType (`#1332 `__) +* Creates PublisherHandle and updates publisher.py (`#1310 `__) +* Subscription types (`#1281 `__) +* Add types to qos.py (`#1255 `__) +* minor improvements (`#1330 `__) +* Initialize signal handlers after context (`#1331 `__) +* shutdown ThreadPoolExecutor in MultiThreadedExecutor. (`#1309 `__) +* Generics Services and Clients (`#1275 `__) +* Add types to ParameterService (`#1262 `__) +* Add types to timer.py (`#1260 `__) +* Add types to rcutils_logger.py (`#1249 `__) +* Add types to topic_endpoint_info.oy (`#1253 `__) +* Add types to parameter.py. (`#1246 `__) +* Guard condition types. (`#1252 `__) +* Add types to callback_groups.py (`#1251 `__) +* Utilities.py types. (`#1250 `__) +* reduce result_timeout to 10 secs from 15 mins. (`#1171 `__) +* Add TimerInfo to timer callback. (`#1292 `__) +* Add types to task.py (`#1254 `__) +* Fix a bad bug in fetching the lifecycle transitions. (`#1321 `__) +* Fix a bug when using multiple rclpy.init context managers. (`#1314 `__) +* Executor executes the tasks in FIFO order. (`#1304 `__) +* Add top-level try_shutdown method. (`#1302 `__) +* Make rclpy initialization context-manager aware. (`#1298 `__) +* Docstring specifying proper destruction and creation of Rate, Timer and GuardCondition (`#1286 `__) +* Make timers context-aware. (`#1296 `__) +* Make service lients context-aware. (`#1295 `__) +* Make service servers context-manager aware. (`#1294 `__) +* Make nodes context-manager aware. (`#1293 `__) +* Make subscriptions context-manager aware. (`#1291 `__) +* Make publishers context-manager aware. (`#1289 `__) +* (NumberOfEntities) improve performance (`#1285 `__) +* Using Generics for messages (`#1239 `__) +* Contributors: Alejandro Hernández Cordero, Arjo Chakravarty, Barry Xu, Brad Martin, Chris Lalancette, Christophe Bedard, Elian NEPPEL, Jonathan, Matthijs van der Burgh, Michael Carlstrom, Nadav Elkabets, R Kent James, Shane Loretz, Tomoya Fujita, Wolf Vollprecht, Zahi Kakish + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcpputils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#211 `__) +* Added marco to disable deprecation warnings (`#210 `__) +* Added missing include (`#207 `__) +* Clear the rcutils error when throwing an exception. (`#206 `__) +* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#204 `__) +* fix memory leak for remove_all(). (`#201 `__) +* Suppress clang error because of deprecation (`#199 `__) +* Deprecated path class (`#196 `__) +* Replace create_temp_directory with the new create_temporary_directory (`#198 `__) * Replace create_temp_directory with the new create_temporary_directory - The newly added ``create_temporary_directory(..)`` uses std::filesystem::path and doesn't have platform-specific code. - Also deprecated ``create_temp_directory(..)`` and ``temp_directory_path`` +* Removed deprecated header get_env.hpp (`#195 `__) +* Removed rolling mean accumulator deprecated header (`#194 `__) +* Removed deprecated clamp methods (`#193 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Janosch Machowinski, Michael Carroll, Michael Orlov, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rcutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Handle spaces in start_process arguments on Windows (`#494 `__) +* Add utility functions for invoking a subprocess (`#491 `__) (`#492 `__) +* Add rcutils_join function for concatenating strings (`#490 `__) +* Switch to ament_cmake_ros_core package (`#489 `__) +* Cleanup error handling in rcutils. (`#485 `__) +* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#483 `__) +* Fix setting allocator to NULL. (`#478 `__) +* Add new API to set envar while specifying overwrite (`#473 `__) +* Remove completely unnecessary use of CLASSNAME. (`#471 `__) +* load dll built by MINGW with lib prefix (`#470 `__) +* add mingw support (`#468 `__) +* Fix filesystem iteration on Windows (`#469 `__) +* Add 'mimick' label to tests which use Mimick (`#466 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Felix F Xu, Michael Carroll, Scott K Logan, Yadu + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`resource_retriever `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed clang compile error (`#112 `__) +* Removed windows warnings (`#111 `__) +* Add a plugin mechanism to resource_retriever (`#103 `__) +* uniform MinCMakeVersion (`#108 `__) +* Stop using python_cmake_module. (`#94 `__) +* Allow spaces (`#100 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michael Carroll, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#397 `__) +* Added rmw_event_type_is_supported (`#395 `__) +* add enclave option functions. (`#393 `__) +* a couple of typo fixes for doc section. (`#391 `__) +* update cmake version (`#389 `__) +* get_zero_initialized_xxx functions return zero initialized structure. (`#380 `__) * get_zero_initialized_xxx functions return zero initialized structure. * introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. * add a comment and more tests for rmw_event_type. --------- +* move qos_profile_rosout_default from rcl. (`#381 `__) +* Fix ugly overwritten warning messages on error paths. (`#387 `__) This mostly has to do with calling rmw_reset_error() in the proper time in the tests, but we also change one test for an allocator to properly check for a valid allocator. +* Fix rmw_validate_namespace{_with_size} error handling. (`#386 `__) * Fix rmw_validate_namespace{_with_size} error handling. It should always set an error, even on invalid arguments. +* Fix arg name in rmw_take_response() doc (`#384 `__) +* Initialize the NULL strucutre with static value. (`#378 `__) +* remove rmw_localhost_only_t. (`#376 `__) +* Fix typo with RMW_DURATION_UNSPECIFIED (`#375 `__) +* Fix typo in rmw_validate\_*_with_size() doc (`#374 `__) +* removed deprecated rmw_node_assert_liveliness() (`#373 `__) +* add mingw support (`#370 `__) +* Minor typo fix (`#368 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Felix F Xu, G.A. vd. Hoorn, Michael Carroll, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch buildtool to ament_cmake package (`#183 `__) +* Export a modern CMake target (`#179 `__) +* Added rmw_event_type_is_supported (`#173 `__) +* Contributors: Alejandro Hernández Cordero, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextdds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address cpplit and gcc warnings. (`#184 `__) +* Support topic instances (`#178 `__) +* Switch buildtool to ament_cmake package (`#183 `__) +* Discovery race condition mitigation (`#174 `__) +* Added rmw_event_type_is_supported (`#173 `__) +* use rmw_enclave_options_xxx APIs instead. (`#172 `__) +* fix security certificate error message format. (`#171 `__) +* Use rmw_security_common (`#167 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#169 `__) +* introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. (`#162 `__) +* Instrument client/service for end-to-end request/response tracking (`#163 `__) +* fix: "Failed to parse type hash" message was overly spammy (ros2-50) (`#149 `__) +* remove rmw_localhost_only_t. (`#156 `__) +* Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT (`#150 `__) +* Use rmw_namespace_validation_result_string() in rmw_create_node (`#151 `__) +* Make rmw_destroy_wait_set return RMW_RET_INVALID_ARGUMENT (`#152 `__) +* Contributors: Alejandro Hernández Cordero, Christophe Bedard, Francisco Gallego Salido, Scott K Logan, Shane Loretz, Taxo Rubio RTI, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_connextddsmicro `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Mark the package rmw_connextddsmicro as deprecated (`#182 `__) +* Switch buildtool to ament_cmake package (`#183 `__) +* Added rmw_event_type_is_supported (`#173 `__) +* Contributors: Alejandro Hernández Cordero, Francisco Gallego Salido, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_cyclonedds_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#538 `__) +* Added rmw_event_type_is_supported (`#532 `__) +* use rmw_enclave_options_xxx APIs instead. (`#531 `__) +* use rmw_security_common (`#529 `__) +* introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. (`#518 `__) +* Reset the error before setting a new one. (`#526 `__) +* Instrument client/service for end-to-end request/response tracking (`#521 `__) +* Drop support for float128. (`#522 `__) +* use RMW_GID_STORAGE_SIZE to client_service_id_t. (`#515 `__) +* remove rmw_localhost_only_t. (`#508 `__) +* Fix the triggering of guard conditions. (`#504 `__) When a guard condition goes active, we have to remember to increase the trig_idx so we look at the next trigger. Otherwise, we can get into situations where we skip a triggered member. +* Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT (`#496 `__) +* Use rmw_namespace_validation_result_string() in rmw_create_node (`#497 `__) +* Make rmw_destroy_wait_set return RMW_RET_INVALID_ARGUMENT (`#498 `__) +* Set received_timestamp to system_clock::now() in message_info (`#491 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Erik Boasson, Joe Speed, Jose Tomas Lorente, Michael Orlov, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_dds_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Deprecated security methods (`#77 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address RHEL warnings and missing includes. (`#819 `__) +* Support topic instances (`#753 `__) +* Switch to ament_cmake_ros_core package (`#818 `__) +* Added rmw_event_type_is_supported (`#809 `__) +* use rmw_enclave_options_xxx APIs instead. (`#808 `__) +* Add deprecation warning for FASTRTPS_DEFAULT_PROFILES_FILE (`#806 `__) +* Export a modern CMake target (`#805 `__) +* Changes to build against Fast DDS 3.0 (`#776 `__) +* Fix some overwritten errors in rmw_fastrtps. (`#799 `__) +* Instrument client/service for end-to-end request/response tracking (`#787 `__) +* Contributors: Alejandro Hernández Cordero, Carlos Espinoza Curto, Chris Lalancette, Christophe Bedard, Miguel Company, Scott K Logan, Shane Loretz, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_dynamic_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address RHEL warnings and missing includes. (`#819 `__) +* Support topic instances (`#753 `__) +* Switch to ament_cmake_ros_core package (`#818 `__) +* Make rmw_fastrtps_dynamic_cpp export a modern CMake target (`#814 `__) +* Added rmw_event_type_is_supported (`#809 `__) +* use rmw_enclave_options_xxx APIs instead. (`#808 `__) +* Add deprecation warning for FASTRTPS_DEFAULT_PROFILES_FILE (`#806 `__) +* Changes to build against Fast DDS 3.0 (`#776 `__) +* Fix some overwritten errors in rmw_fastrtps. (`#799 `__) +* Instrument client/service for end-to-end request/response tracking (`#787 `__) +* Add tracing instrumentation to rmw_fastrtps_dynamic_cpp (`#772 `__) +* Contributors: Alejandro Hernández Cordero, Carlos Espinoza Curto, Chris Lalancette, Christophe Bedard, Miguel Company, Scott K Logan, Shane Loretz, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_fastrtps_shared_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Address RHEL warnings and missing includes. (`#819 `__) +* Support topic instances (`#753 `__) +* Switch to ament_cmake_ros_core package (`#818 `__) +* Added rmw_event_type_is_supported (`#809 `__) +* use rmw_enclave_options_xxx APIs instead. (`#808 `__) +* Add deprecation warning for FASTRTPS_DEFAULT_PROFILES_FILE (`#806 `__) +* Use rmw_security_common (`#803 `__) +* introduce RMW_EVENT_TYPE_MAX in rmw_event_type_t. (`#785 `__) +* Changes to build against Fast DDS 3.0 (`#776 `__) +* Cleanup one test in rmw_fastrtps_shared_cpp. (`#794 `__) +* Instrument client/service for end-to-end request/response tracking (`#787 `__) +* Drop support for float128. (`#788 `__) +* Keep reference to ``DomainParticipantFactory`` (`#770 `__) +* Use client's reader guid for service introspection event gid (`#781 `__) +* Revert "Unique Client GID for Service Introspectino Event. (`#779 `__)" (`#780 `__) +* Unique Client GID for Service Introspectino Event. (`#779 `__) +* remove rmw_localhost_only_t. (`#773 `__) +* Make rmw_service_server_is_available return RMW_RET_INVALID_ARGUMENT (`#763 `__) +* Use rmw_namespace_validation_result_string() in rmw_create_node (`#765 `__) +* Make rmw_destroy_wait_set return RMW_RET_INVALID_ARGUMENT (`#766 `__) +* Use unique mangled names when creating Content Filter Topics (`#762 `__) +* Add support for data representation (`#756 `__) +* Contributors: Alejandro Hernández Cordero, Carlos Espinoza Curto, Chris Lalancette, Christophe Bedard, Jorge J. Perez, Mario Domínguez López, Miguel Company, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added rmw_event_type_is_supported (`#250 `__) +* Make sure to find_package(rmw) in rmw_implementation. (`#242 `__) +* Add mechanism to disable workaround for dependency groups (`#229 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_implementation_cmake `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* update cmake version (`#389 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_security_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Export rmw dependency (`#400 `__) +* Added rmw_security_common (`#388 `__) +* Contributors: Alejandro Hernández Cordero, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_test_fixture `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Resolve windows warnings in rmw_test_fixture (`#22 `__) +* Add rmw_test_fixture for supporting RMW-isolated testing (`#21 `__) +* Contributors: Alejandro Hernández Cordero, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_test_fixture_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Don't set ROS_AUTOMATIC_DISCOVERY_RANGE in rmw_test_fixture (`#33 `__) +* Fix rmw_test_fixture DLL import on Windows (`#32 `__) +* Fix range for rmw_test_fixture_default port locking (`#31 `__) +* Stop loading RMW to load the test fixture (`#30 `__) +* Add 'default' rmw_test_fixture based on domain_coordinator (`#26 `__) +* Install run_rmw_isolated executable to lib subdirectory (`#25 `__) +* Ignore Ctrl-C in run_rmw_isolated on Windows (`#24 `__) +* Resolve windows warnings in rmw_test_fixture (`#22 `__) +* Add rmw_test_fixture for supporting RMW-isolated testing (`#21 `__) +* Contributors: Alejandro Hernández Cordero, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rmw_zenoh_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Change serialization format in attachment_helpers.cpp (`#601 `__) +* Bump Zenoh to v1.3.2 and improve e2e reliability with HeartbeatSporadic (`#591 `__) +* Implement rmw_test_fixture to start the Zenoh router (`#583 `__) +* Add quality declaration (`#483 `__) +* Trigger qos event callback if there are changes before registration (`#587 `__) +* Set wait_set->triggered flag to false (`#575 `__) +* Add space after ``id`` token in ``rmw_zenohd`` log string (`#576 `__) +* Use ``std::unique_lock`` to unlock correctly on Windows (`#570 `__) +* Switch to std::map for TopicTypeMap (`#546 `__) +* Support zenoh config override (`#551 `__) +* Align the config with the latest Zenoh. (`#556 `__) +* Added documentation note in the code (`#540 `__) +* fix: unlock the mutex before making get (`#537 `__) +* Take wait_set_lock before condition_variable notification for subscriptions (`#528 `__) +* Switch default durability to volatile (`#521 `__) +* Added rmw_event_type_is_supported (`#502 `__) +* Fixed windows warning (`#500 `__) +* Config: tune some values for ROS use case, especially with large number of Nodes (>200) (`#509 `__) +* Honor ignore_local_publications in subscription options (`#508 `__) +* Bump zenoh-cpp to 2a127bb, zenoh-c to 3540a3c, and zenoh to f735bf5 (`#503 `__) +* Fix calculation of current_count_change when event status is updated (`#504 `__) +* Fix checks for invalid arguments (`#497 `__) +* Fail creation of entities if qos contains unknown settings (`#494 `__) +* use rmw_enclave_options_xxx APIs instead. (`#491 `__) +* Enable Zenoh UDP transport (`#486 `__) +* fix: use the default destructor that automatically drops the zenoh reply/query and hence sends the final signal (`#473 `__) +* Introduce the advanced publisher and subscriber (`#368 `__) +* Switch to debug log if topic_name not in topic_map (`#454 `__) +* Bump Zenoh to commit id 3bbf6af (1.2.1 + few commits) (`#456 `__) +* Bump Zenoh to commit id e4ea6f0 (1.2.0 + few commits) (`#446 `__) +* Inform users that peers will not discover and communicate with one another until the router is started (`#440 `__) +* Clear the error after rmw_serialized_message_resize() (`#435 `__) +* Fix ``ZENOH_ROUTER_CHECK_ATTEMPTS`` which was not respected (`#427 `__) +* fix: use the default destructor to drop the member ``Payload`` (`#419 `__) +* Remove ``gid_hash\_`` from ``AttachmentData`` (`#416 `__) +* Sync the config with the default config in Zenoh. (`#396 `__) +* fix: check the context validity before accessing the session (`#403 `__) +* Fix wan't typo (`#400 `__) +* An alternative middleware for ROS 2 based on Zenoh. +* Contributors: Alejandro Hernández Cordero, Alex Day, Bernd Pfrommer, ChenYing Kuo (CY), Chris Lalancette, Christophe Bedard, CihatAltiparmak, Esteve Fernandez, Franco Cipollone, Geoffrey Biggs, Hans-Martin, Hugal31, James Mount, Julien Enoch, Luca Cominardi, Mahmoud Mazouz, Morgan Quigley, Nate Koenig, Patrick Roncagliolo, Scott K Logan, Shivang Vijay, Tim Clephas, Tomoya Fujita, Yadunund, Yuyuan Yuan, methylDragon, yadunund, yellowhatter + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`robot_state_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use ``emplace()`` with ``std::map`` (`#231 `__) +* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#229 `__) +* update urdf model header (`#223 `__) +* Contributors: Alejandro Hernández Cordero, Patrick Roncagliolo + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2action `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow zenoh tests to run with multicast (`#992 `__) +* Support 'ros2 action echo' (`#978 `__) +* Correct the license content (`#979 `__) +* Maintaining consistency of automatically putting time stamps in the service and action calls similiar to publishing in rostopics. (`#961 `__) +* ros2action: add SIGINT handler to manage cancel request. (`#956 `__) +* node name print bug fix with ros2 action info. (`#926 `__) +* Switch to using rclpy.init context manager. (`#918 `__) +* support 'ros2 action find'. (`#917 `__) +* Contributors: Barry Xu, Chris Lalancette, Michael Carroll, Sukhvansh Jain, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add actions replay feature (`#1955 `__) +* Implement actions recording and displaying information about recorded actions features (`#1939 `__) +* Fix for failing test_record_qos_profiles on Windows (`#1949 `__) +* Progress bar for ros2 bag play (`#1836 `__) +* Update CLI play verb metavar (`#1906 `__) +* Add test_xmllint.py to python packages. (`#1879 `__) +* Add support for replaying based on publication timestamp (`#1876 `__) +* Publish clock after delay is over and disable delay on next loops (`#1861 `__) +* Support replaying multiple bags (`#1848 `__) +* Rename rclpy.qos.QoS*Policy to rclpy.qos.*Policy (`#1832 `__) +* Add "--sort" CLI option to the "ros2 bag info" command (`#1804 `__) +* Add cli option compression-threads-priority (`#1768 `__) +* Add computation of size contribution to info verb (`#1726 `__) +* fix(start-offset): allow specifying a start offset of 0 (`#1682 `__) +* Exclude recorded /clock topic when --clock option is specified (`#1646 `__) +* Sweep cleanup in rosbag2 recorder CLI args verification code (`#1633 `__) +* Add --log-level to ros2 bag play and record (`#1625 `__) +* Add optional '--topics' CLI argument for 'ros2 bag record' (`#1632 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Kosuke Takeuchi, Michael Orlov, Nicola Loi, Patrick Roncagliolo, Rein Appeldoorn, Roman, Sanoronas + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow zenoh tests to run with multicast (`#992 `__) +* Rename the test\_{daemon,direct}.py tests. (`#959 `__) +* replace removeprefix with string slicing. (`#953 `__) +* Fix instability in the ros2 daemon. (`#947 `__) +* Drop dependency on python3-pkg-resources (`#946 `__) +* NodeStrategy supports node name argument. (`#941 `__) +* Switch to using the rclpy.init context manager. (`#920 `__) +* Contributors: Chris Lalancette, Michael Carroll, Scott K Logan, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2doctor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow zenoh tests to run with multicast (`#992 `__) +* Skip QoS compatibility test on Zenoh (`#985 `__) +* New flag and code update for its use (`#942 `__) +* Switch to using rclpy.init context manager. (`#918 `__) +* Revamp how we get network information in ros2doctor. (`#910 `__) +* Contributors: Alejandro Hernández Cordero, Angel LoGa, Chris Lalancette, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint to the ament_python packages. (`#423 `__) +* Fix url in setup.py (`#413 `__) +* Add mechanism to disable workaround for dependency groups (`#397 `__) +* Contributors: Chris Lalancette, Scott K Logan, Wei HU + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow zenoh tests to run with multicast (`#992 `__) +* Contributors: Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2lifecycle_test_fixtures `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use target_link_libraries instead of ament_target_dependencies (`#973 `__) +* Contributors: Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2node `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Allow zenoh tests to run with multicast (`#992 `__) +* ros2node requires fully qualified node name. (`#923 `__) +* Switch to using rclpy.init context manager. (`#918 `__) +* Contributors: Chris Lalancette, Michael Carroll, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2param `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix loading parameter behavior from yaml file (`#864 `__) +* Allow zenoh tests to run with multicast (`#992 `__) +* cosmetic fixes for ros2param dump command. (`#933 `__) +* Switch to using rclpy.init context manager. (`#918 `__) +* Contributors: Chris Lalancette, Michael Carroll, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2pkg `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use modern C++17 syntax. (`#982 `__) +* Use target_link_libraries instead of ament_target_dependencies (`#973 `__) +* Try to use the git global user.name for maintainer-name (`#968 `__) +* Update minimum CMake version CMakeLists.txt.em (`#969 `__) +* Add ament_xmllint test by default to ament_python packages. (`#957 `__) +* Drop dependency on python3-pkg-resources (`#946 `__) +* Support empy4 and empy3 (`#921 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Larry Gezelius, Scott K Logan, Sebastian Castro, Shane Loretz, Shynur + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2run `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add signal handler SIGIN/SIGTERM to ros2run (`#899 `__) +* Contributors: Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use ``get_service`` in ``ros2service call`` (`#994 `__) +* Allow zenoh tests to run with multicast (`#992 `__) +* Support QoS options for ``ros2 service call`` (`#966 `__) +* Maintaining consistency of automatically putting time stamps in the service and action calls similiar to publishing in rostopics. (`#961 `__) +* Switch to using the rclpy.init context manager. (`#920 `__) +* Switch to using rclpy.init context manager. (`#918 `__) +* Contributors: Chris Lalancette, Michael Carlstrom, Michael Carroll, Sukhvansh Jain, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in test_xmllint to ros2test. (`#13 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Custom Completion Finder for fetching topic prototype (`#995 `__) +* Documented now and auto keywords (`#1008 `__) +* Conditional deserialization of message for ``ros2 topic hz`` (`#1005 `__) +* Enable ``ros2 topic echo`` with entries of array fields (`#996 `__) +* Allow zenoh tests to run with multicast (`#992 `__) +* Adapt tests to Zenoh (`#988 `__) +* Adjust topic hz and bw command description (`#987 `__) +* Add support for topic QOS for ros2topic bw, delay and hz (`#935 `__) +* Start the simulation from 1 second for the test (`#975 `__) +* Support QoS options for ``ros2 service call`` (`#966 `__) +* Support ros2 topic pub yaml file input (`#925 `__) +* support multiple fields in ros2topic echo (`#964 `__) +* NodeStrategy supports node name argument. (`#941 `__) +* feat(echo --clear): add --clear option to echo (`#819 `__) +* Support multiple topics via ros2 topic hz. (`#929 `__) +* Remove TODO for OpenSplice DDS issue. (`#928 `__) +* Switch to using rclpy.init context manager. (`#918 `__) +* Contributors: Alejandro Hernández Cordero, Anthony Welte, Chris Lalancette, Fabian Thomsen, Florencia, Guillaume Beuzeboc, Kostubh Khandelwal, Leander Stephen D'Souza, Martin Pecka, Michael Carroll, SangtaekLee, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose types for tracing tools (`#153 `__) +* Contributors: Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`ros_environment `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update ROS_DISTRO for Kilted Kaiju (`#41 `__) +* Remove CODEOWNERS. (`#40 `__) +* Contributors: Chris Lalancette, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Support replaying multiple bags (`#1848 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_compression `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bugfix: Update metadata with new file_info before saving it first time (`#1843 `__) +* Make snapshot writing into a new file each time it is triggered (`#1842 `__) +* Add cli option compression-threads-priority (`#1768 `__) +* Bugfix for bag_split event callbacks called to early with file compression (`#1643 `__) +* Fix for regression in ``open_succeeds_twice`` and ``minimal_writer_example`` tests (`#1667 `__) +* Bugfix for writer not being able to open again after closing (`#1599 `__) +* Contributors: Alejandro Hernández Cordero, Michael Orlov, Roman, yschulz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for finding action types message definitions in the ``LocalMessageDefinitionSource`` class to be able to store actions message definitions during recording. (`#1965 `__) +* Add message sequence number to the messages write API (`#1961 `__) +* Implement actions recording and displaying information about recorded actions features (`#1939 `__) +* Set environment variables to run tests with ``rmw_zenoh_cpp`` with multicast discovery (`#1946 `__) +* Add more logging info to storage and reader/writer open operations (`#1881 `__) +* Add PlayerClock::wakeup() to interrupt sleeping (`#1869 `__) +* Support replaying multiple bags (`#1848 `__) +* Bugfix: Update metadata with new file_info before saving it first time (`#1843 `__) +* Make snapshot writing into a new file each time it is triggered (`#1842 `__) +* Bugfix for rosbag2_cpp serialization converter (`#1814 `__) +* Allow unknown types in bag rewrite (`#1812 `__) +* Add computation of size contribution to info verb (`#1726 `__) +* [WIP] Remove rcpputils::fs dependencies in rosbag2 packages (`#1740 `__) +* Removed deprecated write method (`#1738 `__) +* Bugfix for bag_split event callbacks called to early with file compression (`#1643 `__) +* Add topics with zero message counts to the SQLiteStorage::get_metadata(). (`#1725 `__) +* Propagate "custom_data" and "ros_distro" in to the metadata.yaml file during re-indexing (`#1700 `__) +* Bugfix for writer not being able to open again after closing (`#1599 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Christophe Bedard, Cole Tucker, Michael Orlov, Nicola Loi, Tomoya Fujita, Yadunund, yschulz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_examples_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add rosbag2_examples_cpp/simple_bag_reader.cpp. (`#1683 `__) +* Contributors: Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_examples_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* avoid using internal modules for examples. (`#1905 `__) +* Add test_xmllint.py to python packages. (`#1879 `__) +* simple_bag_reader.py should publish the data for each timer callback. (`#1767 `__) +* Change the python examples to use the rclpy context manager. (`#1758 `__) +* Add rosbag2_examples_cpp/simple_bag_reader.cpp. (`#1683 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add message sequence number to the messages write API (`#1961 `__) +* Add actions replay feature (`#1955 `__) +* Implement actions recording and displaying information about recorded actions features (`#1939 `__) +* Add bindings to close method in PyReader and PyCompressionReader (`#1935 `__) +* Remove SHARED from pybind11_add_module (`#1929 `__) +* Progress bar for ros2 bag play (`#1836 `__) +* Upstream quality changes from Apex.AI part 1 (`#1903 `__) +* Add support for replaying based on publication timestamp (`#1876 `__) +* Support replaying multiple bags (`#1848 `__) +* Add in python3-dev build dependency. (`#1863 `__) +* Add "--sort" CLI option to the "ros2 bag info" command (`#1804 `__) +* Remove use of python_cmake_module (`#1570 `__) +* Added method to introspect QoS in Python (`#1648 `__) +* Update CI scripts to use Ubuntu Noble distros and bump action scripts to latest versions (`#1709 `__) +* Add cli option compression-threads-priority (`#1768 `__) +* Add computation of size contribution to info verb (`#1726 `__) +* Bugfix for wrong timestamps in ros2 bag info (`#1745 `__) +* Add bindings for LocalMessageDefinitionSource (`#1697 `__) +* Add --log-level to ros2 bag play and record (`#1625 `__) +* Included to_rclcpp_qos_vector to Python wrappers (`#1642 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Michael Orlov, Nicola Loi, Roman, Sanoronas, Silvio Traversaro, methylDragon, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add message sequence number to the messages write API (`#1961 `__) +* Add actions replay feature (`#1955 `__) +* Add more logging info to storage and reader/writer open operations (`#1881 `__) +* Contributors: Barry Xu, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_mcap `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add message sequence number to the messages write API (`#1961 `__) +* Add actions replay feature (`#1955 `__) +* Upstream quality changes from Apex.AI part 1 (`#1903 `__) +* Add vscode gitignore rule and remove vscode folder (`#1698 `__) +* Contributors: Barry Xu, Michael Orlov, methylDragon + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_storage_sqlite3 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add actions replay feature (`#1955 `__) +* Fix incorrect zero size for sqlite storage (`#1759 `__) +* Fix for failing throws_on_invalid_pragma_in_config_file on Windows (`#1742 `__) +* Add topics with zero message counts to the SQLiteStorage::get_metadata(). (`#1725 `__) +* Contributors: Barry Xu, Michael Orlov, Roman, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add actions replay feature (`#1955 `__) +* Implement actions recording and displaying information about recorded actions features (`#1939 `__) +* Upstream quality changes from Apex.AI part 1 (`#1903 `__) +* Use tmpfs in rosbag2 temporary_directory_fixture (`#1901 `__) +* Add debug information for flaky can_record_again_after_stop test (`#1871 `__) +* Remove use of python_cmake_module (`#1570 `__) +* Improve the reliability of rosbag2 tests (`#1796 `__) +* Small cleanups to the rosbag2 tests. (`#1792 `__) +* [WIP] Remove rcpputils::fs dependencies in rosbag2 packages (`#1740 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Michael Orlov + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_test_msgdefs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add support for finding action types message definitions in the ``LocalMessageDefinitionSource`` class to be able to store actions message definitions during recording. (`#1965 `__) +* Contributors: Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Implement actions recording and displaying information about recorded actions features (`#1939 `__) +* Upstream quality changes from Apex.AI part 1 (`#1903 `__) +* Increase timeout to 180s for test_rosbag2_record_end_to_end (`#1889 `__) +* Add "--sort" CLI option to the "ros2 bag info" command (`#1804 `__) +* Improve the reliability of rosbag2 tests (`#1796 `__) +* Small cleanups to the rosbag2 tests. (`#1792 `__) +* Add computation of size contribution to info verb (`#1726 `__) +* Bugfix for wrong timestamps in ros2 bag info (`#1745 `__) +* Fix for a false negative integration test with bag split in recorder (`#1743 `__) +* Propagate "custom_data" and "ros_distro" in to the metadata.yaml file during re-indexing (`#1700 `__) +* Sweep cleanup in rosbag2 recorder CLI args verification code (`#1633 `__) +* Fix for regression in ``open_succeeds_twice`` and ``minimal_writer_example`` tests (`#1667 `__) +* Add optional '--topics' CLI argument for 'ros2 bag record' (`#1632 `__) +* Bugfix for writer not being able to open again after closing (`#1599 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Cole Tucker, Michael Orlov, Nicola Loi, Sanoronas, yadunund, yschulz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosbag2_transport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add actions replay feature (`#1955 `__) +* Implement actions recording and displaying information about recorded actions features (`#1939 `__) +* Set environment variables to run tests with ``rmw_zenoh_cpp`` with multicast discovery (`#1946 `__) +* Initialize filter with namespaced updated topics and services. (rolling) (`#1944 `__) +* Fix: QoS incompatibilities are not expected with rmw_zenoh_cpp (`#1936 `__) +* Address windows warnings in the progress bar class (`#1927 `__) +* Don't delete existing subscription if failed to create a new one (`#1923 `__) +* Progress bar for ros2 bag play (`#1836 `__) +* Upstream quality changes from Apex.AI part 1 (`#1903 `__) +* Use tmpfs in rosbag2 temporary_directory_fixture (`#1901 `__) +* Bugfix: Recorder discovery does not restart after being stopped (`#1894 `__) +* Bugfix. Event publisher not starting for second run after stop (`#1888 `__) +* Add support for replaying based on publication timestamp (`#1876 `__) +* Publish clock after delay is over and disable delay on next loops (`#1861 `__) +* Add PlayerClock::wakeup() to interrupt sleeping (`#1869 `__) +* Add debug information for flaky can_record_again_after_stop test (`#1871 `__) +* Support replaying multiple bags (`#1848 `__) +* Reintroduce ``Don't warn for unknown types if topics are not selected`` (`#1825 `__) +* Allow unknown types in bag rewrite (`#1812 `__) +* Improve the reliability of rosbag2 tests (`#1796 `__) +* Removed warnings (`#1794 `__) +* Small cleanups to the rosbag2 tests. (`#1792 `__) +* Add cli option compression-threads-priority (`#1768 `__) +* [WIP] Remove rcpputils::fs dependencies in rosbag2 packages (`#1740 `__) +* Bugfix for bag_split event callbacks called to early with file compression (`#1643 `__) +* Bugfix for issue where unable to create composable nodes with compression (`#1679 `__) +* Add support for "all" and "exclude" in RecordOptions YAML decoder (`#1664 `__) +* Add unit tests to cover message's send and received timestamps during recording (`#1641 `__) +* Contributors: Alejandro Hernández Cordero, Barry Xu, Chris Lalancette, Christophe Bedard, Michael Orlov, Nicola Loi, Ramon Wijnands, Roderick Taylor, Roman, Yuyuan Yuan, Øystein Sture + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_adapter `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Types for rosidl_adapter (`#828 `__) +* Support empy3 and empy4 (`#821 `__) +* Contributors: Alejandro Hernández Cordero, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Rosidl cli types with ``specs_set`` fix (`#831 `__) +* Contributors: Chris Lalancette, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_core_generators `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add mechanism to disable workaround for dependency groups (`#3 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_core_runtime `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add mechanism to disable workaround for dependency groups (`#3 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_default_runtime `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Minor update to quality declaration (`#27 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_dynamic_typesupport `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#15 `__) +* Bump minimum CMake version to 3.20 (`#14 `__) +* Drop support for long double/float128. (`#12 `__) +* Contributors: Chris Lalancette, Michael Carroll, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_dynamic_typesupport_fastrtps `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#8 `__) +* Changes to build against Fast DDS 3.0 (`#5 `__) +* Drop support for long double/float128. (`#6 `__) +* Contributors: Chris Lalancette, Miguel Company, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#856 `__) +* Deterministic iteration order for reproducible codegen (`#846 `__) +* Add types ``rosidl_pycommon`` (`#824 `__) +* Contributors: Harry Sarson, Michael Carlstrom, Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add name and data_type traits for actions (`#848 `__) +* Add types ``rosidl_pycommon`` (`#824 `__) +* Contributors: Michael Carlstrom, Nathan Wiebe Neufeldt + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_dds_idl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update cmake version requirements (`#64 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix ``__eq__`` for Array fields (`#224 `__) +* Remove use of ament_target_dependencies (`#222 `__) +* Revamp how we check for the correct class. (`#218 `__) +* Remove python_cmake_module and set hints (`#204 `__) +* Add rosidl_generator_py to the rosidl_runtime_packages group (`#212 `__) +* Contributors: Chris Lalancette, Michael Carlstrom, Scott K Logan, Shane Loretz + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add name and data_type traits for actions (`#848 `__) +* Silence one more gcc false-positive. (`#814 `__) +* Switch to using fastjsonschema for schema validation. (`#809 `__) +* Contributors: Chris Lalancette, Nathan Wiebe Neufeldt + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_generator_type_description `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#856 `__) +* Contributors: Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_parser `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Finish adding types to ``rosidl_parser`` (`#832 `__) +* Add types to definition.py in ``rosidl_parser`` (`#791 `__) +* Contributors: Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_pycommon `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_xmllint to rosidl_pycommon. (`#833 `__) +* Add types ``rosidl_pycommon`` (`#824 `__) +* Support empy3 and empy4 (`#821 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#856 `__) +* Implement ``resize`` function for String (`#806 `__) +* Fix u16 docs and improve docs formatting (`#805 `__) +* Contributors: Christophe Bedard, Michael Carroll, WATANABE Aoi + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Suppress warnings in the benchmarks for upstream GCC false positives. (`#810 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_runtime_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use deepcopy in set_message_fields for safety. (`#34 `__) +* Remove CODEOWNERS and mirror-rolling-to-master. (`#31 `__) +* Contributors: Chris Lalancette, Tomoya Fujita + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#166 `__) +* Uniform cmake requirement (`#163 `__) +* Cleanup warning message in rosidl_typesupport_c tests. (`#161 `__) +* Add mechanism to disable workaround for dependency groups (`#157 `__) +* Add 'mimick' label to tests which use Mimick (`#158 `__) +* Contributors: Chris Lalancette, Scott K Logan, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#166 `__) +* Uniform cmake requirement (`#163 `__) +* Add mechanism to disable workaround for dependency groups (`#157 `__) +* Contributors: Scott K Logan, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#127 `__) +* Remove dependency on fastrtps_cmake_module (`#120 `__) +* Remove CODEOWNERS and mirror-rolling-to-master workflow (`#124 `__) +* Remove deprecated functions benchmark tests (`#122 `__) +* Contributors: Chris Lalancette, Miguel Company, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_fastrtps_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#127 `__) +* Remove dependency on fastrtps_cmake_module (`#120 `__) +* Remove CODEOWNERS and mirror-rolling-to-master workflow (`#124 `__) +* Remove deprecated functions benchmark tests (`#122 `__) +* Contributors: Chris Lalancette, Miguel Company, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_c `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#860 `__) +* Add types ``rosidl_pycommon`` (`#824 `__) +* Contributors: Michael Carlstrom, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#860 `__) +* Add types ``rosidl_pycommon`` (`#824 `__) +* Contributors: Michael Carlstrom, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_introspection_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Suppress false positive warnings from gcc. (`#811 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rosidl_typesupport_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake requirement (`#163 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rpyutils `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add py.typed to Package Data (`#16 `__) +* Add Create py.typed (`#15 `__) +* Remove CODEOWNERS and mirror-rolling-to-master workflow. (`#13 `__) +* Add types and ament_mypy to rpyutils. (`#12 `__) +* Contributors: Chris Lalancette, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add standard tests for rqt_bag and rqt_bag_plugins (`#171 `__) +* Updated player QoS (`#164 `__) +* Adapted to rosbag2_py (`#156 `__) +* Fixed button icons (`#159 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_bag_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add standard tests for rqt_bag and rqt_bag_plugins (`#171 `__) +* Adapted to rosbag2_py (`#156 `__) +* Fixed image timeline renderer (`#158 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in standard tests. (`#48 `__) +* Remove CODEOWNERS and mirror-rolling-to-main workflow (`#46 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_graph `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in standard tests. (`#104 `__) +* Remove CODEOWNERS (`#102 `__) +* Fixed fit_in_view icon button (`#95 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in standard tests for rqt_gui and rqt_gui_py (`#318 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added common test to rqt_gui_cpp and deprecate h headers (`#311 `__) +* Updated deprecated qt_gui_cpp headers (`#309 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_gui_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in standard tests for rqt_gui and rqt_gui_py (`#318 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_plot `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add unit tests for topic name validation & field expansion (`#108 `__) +* Fix double slash when plotting all sub-fields with trailing slash (`#107 `__) +* Fix listing of nested basic type fields (`#101 `__) +* Fix f-string and add single quote around field name (`#100 `__) +* Add single quotes around topic in validation msg for consistency (`#99 `__) This is more consistent with the other messages below. +* Add in the rest of the standard ament_python tests. (`#98 `__) +* Remove CODEOWNERS (`#96 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_publisher `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in the remaining standard ament_python tests. (`#49 `__) +* Add in LICENSE. (`#46 `__) +* Remove CODEOWNERS (`#47 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Stop using python_cmake_module. (`#304 `__) +* Use an rclpy context manager. (`#312 `__) +* Added common test to rqt_py_common (`#310 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_py_console `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add the standard tests to rqt_py_console. (`#19 `__) +* Remove CODEOWNERS (`#17 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_service_caller `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update rqt_service_caller to our standard policies. (`#31 `__) +* Remove CODEOWNERS (`#29 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_shell `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in standard tests to rqt_shell. (`#24 `__) That way we know it conforms to our standards. +* Remove CODEOWNERS (`#22 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rqt_topic `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Override subscriber qos (`#51 `__) +* Remove CODEOWNERS (`#52 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rti_connext_dds_cmake_module `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update Connext to 7.3.0 (`#181 `__) +* Quiet a warning when CONNEXTDDS_DIR or NDDSHOME is not found. (`#158 `__) +* Contributors: Chris Lalancette, lobolanja + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rttest `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Don't try to build on BSD (`#126 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Expose the possibility to create ROS node with custom ``NodeOptions`` (`#1347 `__) +* uniform CMAKE requirement (`#1335 `__) +* Detect wayland and make sure X rendering is used. (`#1253 `__) +* Fixed RViz2 linters (`#1231 `__) +* Contributors: Alejandro Hernández Cordero, Matthew Elwin, Patrick Roncagliolo, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_assimp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Revert "Update ASSIMP_VENDOR CMakeLists.txt (`#1226 `__)" (`#1249 `__) +* Update ASSIMP_VENDOR CMakeLists.txt (`#1226 `__) CLEAN UNUSED CHECK SE MIN ASSIMP VERSION TO 5.3.1 SET C++ VERSION TO 17 +* Contributors: Chris Lalancette, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_common `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Work in progress using the new resource retriever apis (`#1262 `__) +* addTrackedObject Function Fails to Handle Null Pointer, Causing Crash When nullptr is Passed (`#1375 `__) +* Add test to check mapGetString when key is missing (`#1361 `__) +* UniformStringStream::parseFloat Fails to Handle Invalid Float Formats Correctly (`#1360 `__) +* Fix Potential Null Pointer Dereference in VisualizerApp::getRenderWindow() to Prevent Crashes (`#1359 `__) +* Extend support for type adaptation (REP 2007) in rviz_common for TF-filtered displays (`#1346 `__) +* Expose the possibility to create ROS node with custom ``NodeOptions`` (`#1347 `__) +* uniform CMAKE requirement (`#1335 `__) +* Add basic support for type adaptation (REP 2007) in ``rviz_common`` for displays (`#1331 `__) +* Fix preferred tools loading names (`#1321 `__) +* Add RVIZ_COMMON_PUBLIC macro to ToolManager (`#1323 `__) +* Clean visualization_manager.cpp (`#1317 `__) +* Fix Deprecated tf2 headers (`#1289 `__) +* include QString (`#1298 `__) +* Handle time source exception (`#1285 `__) +* Fully handle ``Tool::processKeyEvent`` return value (`#1270 `__) +* Handle ``Tool::Finished`` returned by ``processKeyEvent`` (`#1257 `__) +* Added more time to copyright on Windwos (`#1252 `__) +* Added common test for rviz_common (`#1232 `__) +* Set ContentsMargins for RenderPanel to 0 to avoid borders in fullscreen mode. Fixes `#1024 `__ (`#1228 `__) +* Updated deprecated message filter headers (`#1239 `__) +* Correclty load icons of panels with whitespaces in their name (`#1241 `__) +* Prepping for qos deprecation (`#1214 `__) +* Replace ESC shortcut for exiting full screen with solution from https://github.com/ros-visualization/rviz/pull/1416 (`#1205 `__) +* Contributors: Alejandro Hernández Cordero, Bo Chen, Lucas Wendland, Matthew Foran, Michael Carroll, Michael Ripperger, Patrick Roncagliolo, RaduPopescu, Silvio Traversaro, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_default_plugins `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* PointCloudDisplay: Fix decay time 0 keeping more than the last message (`#1400 `__) +* Work in progress using the new resource retriever apis (`#1262 `__) +* Include chrono (`#1353 `__) +* fix: add rclcpp::shutdown (`#1343 `__) +* Nv12 color format (`#1318 `__) Co-authored-by: zycczy +* uniform CMAKE requirement (`#1335 `__) +* Initialize lookup table only once at compile time (`#1330 `__) Co-authored-by: Alejandro Hernández Cordero +* Fixed the XY Orbit controller move (`#1327 `__) Co-authored-by: Terry Scott +* Fix Deprecated tf2 headers (`#1289 `__) +* Change EffortDisplay superclass from MessageFilterDisplay to RosTopicDisplay to avoid dropping messages with empty frame_id. (`#1312 `__) +* Fix access control for Accel, Effort and Twist displays (`#1311 `__) +* remove unused variable (`#1301 `__) +* include QString (`#1298 `__) +* Clean code for Image display (`#1271 `__) +* Handle time source exception (`#1285 `__) +* replace deprecated encodings 'yuv422' and 'yuv422_yuy2' (`#1276 `__) +* Update urdf model.h deprecation (`#1266 `__) +* Enabling manual space width for TextViewFacingMarker (`#1261 `__) +* Added more time to copyright on Windwos (`#1252 `__) +* Updated deprecated message filter headers (`#1239 `__) +* Fixed RViz default plugin license linter (`#1230 `__) +* Contributors: Alejandro Hernández Cordero, Christian Rauch, Lucas Wendland, Matthew Foran, Michael Carroll, Patrick Roncagliolo, Peng Wang, Stefan Fabian, Terry Scott, Tom Moore, Yuyuan Yuan, disRecord, mosfet80, quic-zhaoyuan, suchetanrs + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_ogre_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing glew dependency for ogre vendor package (`#1350 `__) +* Use official freetype github mirror instead of savannah (`#1348 `__) +* Fix flags for both clang and gcc. (`#1219 `__) +* Update freetype lib (`#1216 `__) +* Update zlib into CMakeLists.txt (`#1128 `__) Changes in 1.3 (18 Aug 2023) - Remove K&R function definitions and zlib2ansi - Fix bug in deflateBound() for level 0 and memLevel 9 - Fix bug when gzungetc() is used immediately after gzopen() - Fix bug when using gzflush() with a very small buffer - Fix crash when gzsetparams() attempted for transparent write - Fix test/example.c to work with FORCE_STORED - Rewrite of zran in examples (see zran.c version history) - Fix minizip to allow it to open an empty zip file - Fix reading disk number start on zip64 files in minizip - Fix logic error in minizip argument processing - Add minizip testing to Makefile - Read multiple bytes instead of byte-by-byte in minizip unzip.c - Add memory sanitizer to configure (--memory) - Various portability improvements - Various documentation improvements - Various spelling and typo corrections Co-authored-by: Chris Lalancette +* Contributors: Chris Lalancette, Silvio Traversaro, Stefan Fabian, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* BillboardLine::addPoint() does not throw an exception when exceeding max_points_per_line limit (`#1436 `__) +* Constructor ScrewVisual::ScrewVisual does not handle null pointers, leading to crashes (`#1435 `__) +* Removed Windows warnings (`#1413 `__) +* Memory Access Error When Handling Empty Strings in splitStringIntoTrimmedItems Function (`#1412 `__) +* Crash due to Unhandled Null Pointer in ParameterEventsFilter Constructor (`#1411 `__) +* MovableText constructor does not validate invalid character height, default fallback missing (`#1398 `__) +* Invalid Parameter Handling in CovarianceVisual::CovarianceVisual Constructor (`#1396 `__) +* Lack of Validity Check for Invalid Parameters in EffortVisual::EffortVisual Constructor (`#1395 `__) +* Grid Class Constructor Does Not Handle Null Pointer, Leading to Program Crash (`#1394 `__) +* Crash in MovableText::update() when caption is an empty string due to uninitialized resource usage (`#1393 `__) +* Work in progress using the new resource retriever apis (`#1262 `__) +* uniform CMAKE requirement (`#1335 `__) +* Clean ogre_render_window_impl.cpp (`#1334 `__) +* include QString (`#1298 `__) +* Use consistent conditionals in render_system.hpp (`#1294 `__) +* Avoid redefinition of default color materials (`#1281 `__) +* Added more time to copyright on Windwos (`#1252 `__) +* Fix: issue `#1220 `__. (`#1237 `__) Co-authored-by: Alejandro Hernández Cordero +* Added common test: rviz_rendering (`#1233 `__) +* Contributors: Alejandro Hernández Cordero, Masayoshi Dohi, Matthew Foran, Michael Carroll, Scott K Logan, chama1176, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_rendering_tests `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Work in progress using the new resource retriever apis (`#1262 `__) +* uniform CMAKE requirement (`#1335 `__) +* Added common test to rviz_rendering_tests (`#1234 `__) +* Contributors: Alejandro Hernández Cordero, Michael Carroll, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_resource_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Work in progress using the new resource retriever apis (`#1262 `__) +* Contributors: Michael Carroll + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`rviz_visual_testing_framework `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* uniform CMAKE requirement (`#1335 `__) +* Fix Deprecated tf2 headers (`#1289 `__) +* include QString (`#1298 `__) +* Added common test to rviz_visual_testing_framework (`#1235 `__) +* Contributors: Alejandro Hernández Cordero, Lucas Wendland, Matthew Foran, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add NV12 to color formats (`#253 `__) +* Contributors: Lukas Schäper + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sensor_msgs_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add ament_xmllint to sensor_msgs_py. (`#259 `__) +* Fix formatting in sensor_msgs_py (`#248 `__) +* Contributors: Chris Lalancette, Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`service_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sqlite3_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump sqlite3 to 3.45.1 (`#1737 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`sros2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to get_rmw_additional_env (`#339 `__) +* Fix github-workflow mypy error (`#336 `__) +* Give more time to generate policies in tests (`#323 `__) +* Switch to context manager for rclpy tests. (`#322 `__) +* [FIX] remove dangerous mutable default arguments in generate_artifacts (`#318 `__) +* Fix sros2 tests on Windows Debug. (`#317 `__) +* [TESTS] Update tests and add test for generate_artifacts (`#311 `__) +* remove deprecated create_key and list_keys verbs (`#302 `__) +* Fix linux tutorial: cloning example policies and set of default policies for a node (`#295 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Mikael Arguedas, Tomoya Fujita, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Stop using python_cmake_module. (`#536 `__) +* Use rclpy.init context manager where we can. (`#547 `__) This allows us to cleanup, while using a lot less code to try and track it. +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_cli_remapping `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Stop using python_cmake_module. (`#536 `__) +* Use rclpy.init context manager where we can. (`#547 `__) This allows us to cleanup, while using a lot less code to try and track it. +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_communication `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use EnableRmwIsolation in launch tests (`#571 `__) +* Switch to isolated test fixture macros (`#571 `__) +* Add tests for Keyed types (`#568 `__) +* Remove use of ament_target_dependencies (`#566 `__) +* Skip all multi-vendor pub/sub tests with zenoh (`#560 `__) +* Stop using python_cmake_module. (`#536 `__) +* Use rclpy.init context manager where we can. (`#547 `__) This allows us to cleanup, while using a lot less code to try and track it. +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Francisco Gallego Salido, Scott K Logan, Shane Loretz, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_interface_files `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Drop long double from the IDL. (`#22 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_launch_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add python3-pytest-timeout to test_launch_ros. (`#454 `__) +* Autostarting lifecycle nodes and example launch file demo (`#430 `__) +* Add ament_xmllint to the ament_python packages. (`#423 `__) +* Add in a timeout for test_launch_ros. (`#417 `__) +* Fix url in setup.py (`#413 `__) +* Revamp the test_load_composable_nodes test. (`#403 `__) +* Switch to use rclpy.init context manager. (`#402 `__) +* Contributors: Chris Lalancette, Steve Macenski, Tomoya Fujita, Wei HU + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added test messages with keys (`#173 `__) +* Contributors: Francisco Gallego Salido + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_osrf_testing_tools_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Update CMakeLists.txt (`#85 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_quality_of_service `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to isolated test fixture macros (`#571 `__) +* Use rmw_event_type_is_supported to skip tests (`#563 `__) +* Fixed some qos test related with Zenoh (`#551 `__) +* Contributors: Alejandro Hernández Cordero, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rclcpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Use EnableRmwIsolation in launch tests (`#571 `__) +* Ensure test verifies the existence of all spawning nodes (`#558 `__) +* chore: Adopted to API changes in rclcpp (`#556 `__) +* Implement the pure-virtual functions in the Waitable class. (`#548 `__) +* Update deprecated methods (`#546 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Janosch Machowinski, Scott K Logan, Yuyuan Yuan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_rmw_implementation `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added rmw_event_type_is_supported (`#250 `__) * Added rmw_event_check_compatible * fix return typoe * updated name and use in wait_set test --------- +* Update expectations of tests to remain compatible with non-DDS middlewares (`#248 `__) +* use rmw_enclave_options_xxx APIs instead. (`#247 `__) +* Fix up some overwritten errors. (`#246 `__) That is, make sure to clear out errors where we should. We also slightly rewrite some of the testing around unsupported APIs, so that they make more sense. +* Do not deref msg ptr for rmw\_{publish,return}_loaned_message*() (`#240 `__) +* remove rmw_localhost_only_t. (`#239 `__) +* Expect rmw_service_server_is_available to ret RMW_RET_INVALID_ARGUMENT (`#231 `__) +* Expect rmw_destroy_wait_set to ret RMW_RET_INVALID_ARGUMENT (`#234 `__) +* Add test creating two content filter topics with the same topic name (`#230 `__) (`#233 `__) +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Christophe Bedard, Tomoya Fujita, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_ros2trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add timeout to test_ros2trace tests that wait on stdout (`#167 `__) +* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Add ``rclcpp::shutdown`` (`#762 `__) +* Remove many extra conversions from Matrix3x3 to Quaternion (`#741 `__) Co-authored-by: jmachowinski Co-authored-by: Katherine Scott +* Deprecate C Headers (`#720 `__) +* Switch to using a context manager for the python examples. (`#700 `__) That way we can be sure to always clean up, but use less code doing so. +* Contributors: Chris Lalancette, Lucas Wendland, Yuyuan Yuan, kyle-basis, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Run test_tracetools tests against rmw_zenoh_cpp (`#140 `__) +* Use ament_add_ros_isolated\_* in test_tracetools (`#159 `__) +* Instrument client/service for end-to-end request/response tracking (`#145 `__) +* Don't try to build on BSD (`#142 `__) The 'BSD' variable was added in CMake 3.25. Note that variables which are not defined will evaluate to 'False', so this shouldn't regress platforms using CMake versions older than 3.25. +* Refactor and split test_service into test\_{service,client} (`#144 `__) +* Change expected rmw GID array size to 16 bytes (`#138 `__) +* Run test_tracetools tests against rmw_fastrtps_dynamic_cpp too (`#127 `__) +* Make test_tracetools ping pubs/subs transient_local (`#125 `__) +* Run relevant test_tracetools tests with all instrumented rmw impls (`#116 `__) +* Contributors: Christophe Bedard, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`test_tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix or ignore new mypy issues (`#161 `__) +* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) +* Contributors: Christophe Bedard + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2 `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add isnan support (`#780 `__) +* Overflow Issue in durationFromSec() Function when Handling Extremely Large or Small Values (`#785 `__) +* Do not clobber callback handles when cancelling pending transformable requests (`#779 `__) +* Uniform cmake min version (`#764 `__) +* Remove many extra conversions from Matrix3x3 to Quaternion (`#741 `__) Co-authored-by: jmachowinski Co-authored-by: Katherine Scott +* Cleanup deprecation warnings. (`#744 `__) The deprecation warnings were not printing out properly on GCC, at least; it would warn that #warning was not standard, and it would also not print out the actual warning. Also "deprecated" was spelled wrong. Fix all of these issues here. +* Deprecate C Headers (`#720 `__) +* Removed unused var in tf2 (`#735 `__) +* Error String Filled (`#715 `__) +* Removed deprecated enuns (`#699 `__) +* [TimeCache] Improve performance for insertData() and pruneList() (`#680 `__) Co-authored-by: Chris Lalancette +* Removed warning (`#682 `__) +* Add cache_benchmark (`#679 `__) * Add cache_benchmark Co-authored-by: Chris Lalancette +* [cache_unittest] Add direct implementation testing on ordering, pruning (`#678 `__) * [cache_unittest] Add direct implementation testing on ordering, pruning * do getAllItems() approach * Return a reference instead. * mark getAllItems as internal * Fix warning on Windows. Co-authored-by: Chris Lalancette +* Contributors: Alejandro Hernández Cordero, Chris Lalancette, Eric Cousineau, Lucas Wendland, Michael Carlstrom, Timo Röhling, cramke, kyle-basis, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_bullet `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Deprecate C Headers (`#720 `__) +* Contributors: Lucas Wendland, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Deprecate C Headers (`#720 `__) +* Contributors: Lucas Wendland, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_eigen_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Deprecate C Headers (`#720 `__) +* Contributors: Lucas Wendland, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_geometry_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Remove many extra conversions from Matrix3x3 to Quaternion (`#741 `__) Co-authored-by: jmachowinski Co-authored-by: Katherine Scott +* Deprecate C Headers (`#720 `__) +* Add a python3-dev dependency to tf2_py. (`#733 `__) +* Fix tf2_geometry_msgs_INCLUDE_DIRS. (`#729 `__) +* Remove use of python_cmake_module (`#651 `__) +* Contributors: Chris Lalancette, Lucas Wendland, kyle-basis, rkeating-planted + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_kdl `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Fix external docs mappings (`#757 `__) +* tf2_kdl: add python_orocos_kdl_vendor dependency (`#745 `__) * tf2_kdl: add python_orocos_kdl_vendor dependency The tf2_kdl Python API depends on PyKDL, which is provided by python_orocos_kdl_vendor. * tf2_kdl: remove tf2_msgs test dependency This dependency is not needed. +* Deprecate C Headers (`#720 `__) +* Contributors: Ben Wolsieffer, Emmanuel, Lucas Wendland, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Deprecate C Headers (`#720 `__) +* Add a python3-dev dependency to tf2_py. (`#733 `__) +* Remove use of python_cmake_module (`#651 `__) +* Contributors: Chris Lalancette, Lucas Wendland + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform cmake min version (`#764 `__) +* Add ``rclcpp::shutdown`` (`#762 `__) +* Fix external docs mappings (`#757 `__) +* Deprecate C Headers (`#720 `__) +* specified quaternion order to be xyzw (`#718 `__) +* Add configurable TF topics (`#709 `__) +* Adding static transform listener (`#673 `__) +* Updated deprecated message filter headers (`#702 `__) +* Update qos for deprecation (`#695 `__) +* Cli tools documentation (`#653 `__) +* Contributors: Abhishek Kashyap, Alejandro Hernández Cordero, Emmanuel, Lucas Wendland, Ryan, Tom Moore, Yuyuan Yuan, mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_ros_py `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix external docs mappings (`#757 `__) +* Add in the linters for tf2_ros_py. (`#740 `__) +* Adding StaticTransformListener in Python (`#719 `__) +* Add in test_xmllint for geometry2 python packages. (`#725 `__) +* Add configurable TF topics (`#709 `__) +* Fix the time_jump_callback signature. (`#711 `__) +* Switch to using a context manager for the python examples. (`#700 `__) That way we can be sure to always clean up, but use less code doing so. +* Contributors: Chris Lalancette, Emmanuel, Lucas Wendland, Ryan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_sensor_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Deprecate C Headers (`#720 `__) +* Add a python3-dev dependency to tf2_py. (`#733 `__) +* Remove use of python_cmake_module (`#651 `__) +* Contributors: Chris Lalancette, Lucas Wendland + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tf2_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add in test_xmllint for geometry2 python packages. (`#725 `__) +* Add configurable TF topics (`#709 `__) +* [view_frames] log filenames after it's been determined (`#674 `__) +* Contributors: Chris Lalancette, Mikael Arguedas, Ryan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fixed link (`#15 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tlsf_cpp `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Explicitly shutdown context before test exits (`#129 `__) +* Reduce the number of files we compile. (`#125 `__) +* Contributors: Chris Lalancette, yadunund + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_monitor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add test_xmllint.py to all of the ament_python packages. (`#704 `__) +* Contributors: Chris Lalancette + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`topic_statistics_demo `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Uniform CMAKE min VERSION (`#714 `__) +* Contributors: mosfet80 + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Switch to ament_cmake_ros_core package (`#162 `__) +* Instrument client/service for end-to-end request/response tracking (`#145 `__) +* Don't try to build on BSD (`#142 `__) +* Change expected rmw GID array size to 16 bytes (`#138 `__) +* Fix up two different C problems. (`#129 `__) +* Ignore zero-variadic-macro-arguments warnings from lttng-ust macros (`#126 `__) +* Remove deprecated TRACEPOINT macros (`#123 `__) +* Fix type for buffer index argument in tracepoint event declaration. (`#117 `__) +* Contributors: Chris Lalancette, Christophe Bedard, Mattis Kieffer, Michael Carroll, Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_launch `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix or ignore new mypy issues (`#161 `__) +* Improve Python typing annotations (`#152 `__) +* Expose types for tracing tools (`#153 `__) +* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) +* Contributors: Christophe Bedard, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_read `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve Python typing annotations (`#152 `__) +* Expose types for tracing tools (`#153 `__) +* Contributors: Christophe Bedard, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_test `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Fix or ignore new mypy issues (`#161 `__) +* Improve Python typing annotations (`#152 `__) +* Expose types for tracing tools (`#153 `__) +* Run relevant test_tracetools tests with all instrumented rmw impls (`#116 `__) +* Contributors: Christophe Bedard, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`tracetools_trace `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Improve Python typing annotations (`#152 `__) +* Expose types for tracing tools (`#153 `__) +* Remove unnecessary 'type: ignore' comments in tracetools_trace (`#151 `__) +* Instrument client/service for end-to-end request/response tracking (`#145 `__) +* Allow enabling syscalls through ``ros2 trace`` or the Trace action (`#137 `__) +* Contributors: Christophe Bedard, Michael Carlstrom + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`turtlesim `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Create turtlesim_msgs (`#169 `__) +* Add icon for Jazzy. (`#167 `__) +* [teleop_turtle_key] update usage string to match keys captured by keyboard (`#165 `__) +* Contributors: Alejandro Hernández Cordero, Marco A. Gutierrez, Mikael Arguedas + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`turtlesim_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Create turtlesim_msgs (`#169 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`type_description_interfaces `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing build_export_depend on rosidl_core_runtime (`#165 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`unique_identifier_msgs `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add missing build_export_depend on rosidl_core_runtime (`#30 `__) +* Contributors: Scott K Logan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* make linters happy (`#45 `__) +* Added documentation with rosdoc2 (`#40 `__) +* Added commom linters (`#39 `__) +* Use rcutils to log (`#37 `__) +* Enable test_robot_model_parser test (`#38 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`urdf_parser_plugin `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Added commom linters (`#39 `__) +* Contributors: Alejandro Hernández Cordero + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`zenoh_cpp_vendor `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Bump Zenoh to v1.3.2 and improve e2e reliability with HeartbeatSporadic (`#591 `__) +* Add quality declaration (`#483 `__) +* Fix liveliness crash in debug mode (`#544 `__) +* Bump zenoh-cpp to 2a127bb, zenoh-c to 3540a3c, and zenoh to f735bf5 (`#503 `__) +* Enable Zenoh UDP transport (`#486 `__) +* Bump zenoh-c to 261493 and zenoh-cpp to 5dfb68c (`#463 `__) +* Bump Zenoh to commit id 3bbf6af (1.2.1 + few commits) (`#456 `__) +* Bump Zenoh to commit id e4ea6f0 (1.2.0 + few commits) (`#446 `__) +* Bump zenoh-c and zenoh-cpp to 1.1.1 (`#424 `__) +* Update Zenoh version (`#405 `__) +* Vendors zenoh-cpp for rmw_zenoh. +* Contributors: Alejandro Hernández Cordero, ChenYing Kuo (CY), Chris Lalancette, Franco Cipollone, Hugal31, Julien Enoch, Luca Cominardi, Yadunund, Yuyuan Yuan + + +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +`zenoh_security_tools `__ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +* Add zenoh_security_tools (`#595 `__) +* Contributors: yadunund + + diff --git a/source/Get-Started/Releases/Release-Ardent-Apalone.rst b/source/Get-Started/Releases/Release-Ardent-Apalone.rst index 752457fc925..ea85cf1e675 100644 --- a/source/Get-Started/Releases/Release-Ardent-Apalone.rst +++ b/source/Get-Started/Releases/Release-Ardent-Apalone.rst @@ -1,156 +1,157 @@ -.. redirect-from:: - - Release-Ardent-Apalone - -Ardent Apalone (``ardent``) -=========================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Welcome to the first non-beta release of ROS 2 software named *Ardent Apalone*! - -Supported Platforms -------------------- - -This version of ROS 2 is supported on three platforms: - - -* Ubuntu 16.04 (Xenial) -* Mac macOS 10.12 (Sierra) -* Windows 10 - -Binary packages as well as instructions for how to compile from source are provided for all 3 platforms (see `install instructions <../../Installation>` as well as `documentation `__). - -+--------------+-----------------------+----------------------+--------------------+ -| Required support | -+--------------+-----------------------+----------------------+--------------------+ -| Architecture | Ubuntu Xenial (16.04) | MacOS Sierra (10.12) | Windows 10 (VS2015)| -+==============+=======================+======================+====================+ -| amd64 | X | X | X | -+--------------+-----------------------+----------------------+--------------------+ -| arm64 | X | | | -+--------------+-----------------------+----------------------+--------------------+ - -Minimum language requirements: - -- C11[^2] -- C++14 -- Python 3.5 - -[^2]: C11 is required, but support for some non-compliant systems is - also provided, e.g. MSVC. - -Dependency Requirements: - -+--------------+----------------+------------+--------------+ -| Package | Ubuntu Xenial | MacOS** | Windows 10** | -+==============+================+============+==============+ -| CMake | 3.5.1 | 3.11.0 | 3.10.2 | -+--------------+----------------+------------+--------------+ -| EmPY | 3.3.2 | 3.6.5 | 3.3.2 | -+--------------+----------------+------------+--------------+ -| Ogre | 1.10* | 1.10* | 1.10* | -+--------------+----------------+------------+--------------+ -| OpenCV | 2.4.9 | 3.4.1 | 2.4.13.2* | -+--------------+----------------+------------+--------------+ -| Poco | 1.7.7* | 1.7.7* | 1.7.7* | -+--------------+----------------+------------+--------------+ -| Python | 3.5.1 | 3.6.5 | 3.6.4 | -+--------------+----------------+------------+--------------+ -| Qt | 5.5.1 | 5.10.0 | 5.10.0 | -+--------------+----------------+------------+--------------+ -| **Linux only (used for turtlebot demo)** | -+--------------+----------------+------------+--------------+ -| PCL | 1.7.2 | N/A | N/A | -+--------------+----------------+------------+--------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu Xenial: apt -- MacOS: Homebrew, pip -- Windows: Chocolatey, pip - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Middleware Implementation Support: - -- eProsima Fast-RTPS -- RTI Connext -- ADLINK OpenSplice - -Features --------- - -New features in this ROS 2 release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - -* Distributed discovery, publish / subscribe, request / response communication - - * Provided by a C API - * Implemented using different vendors: - - * eProsima's Fast RTPS as well as ADLINK's OpenSplice (from binary and source) - * RTI's Connext (only from source) - - * Numerous quality of service settings for handling non-ideal networks - * DDS Security support (with Connext and Fast RTPS) - -* C++ and Python 3 client libraries - - * Sharing common code in C to unify the implementation - * Execution model separated from the nodes, composable nodes - * Node-specific parameters (only in C++ atm) - * Life cycle (only in C++ atm) - * Optionally intra-process communication using the same API (only in C++) - -* Message definitions (with bounded arrays and strings as well as default values) -* Command line tools (e.g. ``ros2 run``) -* ``rviz`` with a few display types (the Windows version will likely follow in a few weeks) -* File system-based resource index (querying information without recursive crawling) -* Realtime safe code paths for pub / sub (with compatible DDS implementations only) -* Bridge between ROS 1 and ROS 2 -* HSR demo `see Beta 3 ` -* Turtlebot demo `see Beta 2 ` - -For a more detailed description please see the `Features <../../The-ROS2-Project/Features>` page. - -Changes since Beta 3 release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Improvements since the Beta 3 release: - - -* ``rviz`` -* Different initialization options for message data structures in C++ (see `design doc `__) -* Logging API improvements, now also used in the demos -* Time support in C++ with different clocks -* wait-for-service support in the Python client library -* Draft implementation of `REP 149 `__ specifying format 3 of the package manifest files - -Known Issues ------------- - - -* Fast RTPS performance with larger data like the image demo -* Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). -* Listing of node names (e.g. using ``ros2 node list``) does not work across some rmw implementations. -* On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. +.. redirect-from:: + + Release-Ardent-Apalone + Releases/Release-Ardent-Apalone + +Ardent Apalone (``ardent``) +=========================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Welcome to the first non-beta release of ROS 2 software named *Ardent Apalone*! + +Supported Platforms +------------------- + +This version of ROS 2 is supported on three platforms: + + +* Ubuntu 16.04 (Xenial) +* Mac macOS 10.12 (Sierra) +* Windows 10 + +Binary packages as well as instructions for how to compile from source are provided for all 3 platforms (see `install instructions <../../Installation>` as well as `documentation `__). + ++--------------+-----------------------+----------------------+--------------------+ +| Required support | ++--------------+-----------------------+----------------------+--------------------+ +| Architecture | Ubuntu Xenial (16.04) | MacOS Sierra (10.12) | Windows 10 (VS2015)| ++==============+=======================+======================+====================+ +| amd64 | X | X | X | ++--------------+-----------------------+----------------------+--------------------+ +| arm64 | X | | | ++--------------+-----------------------+----------------------+--------------------+ + +Minimum language requirements: + +- C11[^2] +- C++14 +- Python 3.5 + +[^2]: C11 is required, but support for some non-compliant systems is + also provided, e.g. MSVC. + +Dependency Requirements: + ++--------------+----------------+------------+--------------+ +| Package | Ubuntu Xenial | MacOS** | Windows 10** | ++==============+================+============+==============+ +| CMake | 3.5.1 | 3.11.0 | 3.10.2 | ++--------------+----------------+------------+--------------+ +| EmPY | 3.3.2 | 3.6.5 | 3.3.2 | ++--------------+----------------+------------+--------------+ +| Ogre | 1.10* | 1.10* | 1.10* | ++--------------+----------------+------------+--------------+ +| OpenCV | 2.4.9 | 3.4.1 | 2.4.13.2* | ++--------------+----------------+------------+--------------+ +| Poco | 1.7.7* | 1.7.7* | 1.7.7* | ++--------------+----------------+------------+--------------+ +| Python | 3.5.1 | 3.6.5 | 3.6.4 | ++--------------+----------------+------------+--------------+ +| Qt | 5.5.1 | 5.10.0 | 5.10.0 | ++--------------+----------------+------------+--------------+ +| **Linux only (used for turtlebot demo)** | ++--------------+----------------+------------+--------------+ +| PCL | 1.7.2 | N/A | N/A | ++--------------+----------------+------------+--------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu Xenial: apt +- MacOS: Homebrew, pip +- Windows: Chocolatey, pip + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Middleware Implementation Support: + +- eProsima Fast-RTPS +- RTI Connext +- ADLINK OpenSplice + +Features +-------- + +New features in this ROS 2 release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +* Distributed discovery, publish / subscribe, request / response communication + + * Provided by a C API + * Implemented using different vendors: + + * eProsima's Fast RTPS as well as ADLINK's OpenSplice (from binary and source) + * RTI's Connext (only from source) + + * Numerous quality of service settings for handling non-ideal networks + * DDS Security support (with Connext and Fast RTPS) + +* C++ and Python 3 client libraries + + * Sharing common code in C to unify the implementation + * Execution model separated from the nodes, composable nodes + * Node-specific parameters (only in C++ atm) + * Life cycle (only in C++ atm) + * Optionally intra-process communication using the same API (only in C++) + +* Message definitions (with bounded arrays and strings as well as default values) +* Command line tools (e.g. ``ros2 run``) +* ``rviz`` with a few display types (the Windows version will likely follow in a few weeks) +* File system-based resource index (querying information without recursive crawling) +* Realtime safe code paths for pub / sub (with compatible DDS implementations only) +* Bridge between ROS 1 and ROS 2 +* HSR demo `see Beta 3 ` +* Turtlebot demo `see Beta 2 ` + +For a more detailed description please see the `Features <../../The-ROS2-Project/Features>` page. + +Changes since Beta 3 release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Improvements since the Beta 3 release: + + +* ``rviz`` +* Different initialization options for message data structures in C++ (see `design doc `__) +* Logging API improvements, now also used in the demos +* Time support in C++ with different clocks +* wait-for-service support in the Python client library +* Draft implementation of `REP 149 `__ specifying format 3 of the package manifest files + +Known Issues +------------ + + +* Fast RTPS performance with larger data like the image demo +* Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). +* Listing of node names (e.g. using ``ros2 node list``) does not work across some rmw implementations. +* On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Bouncy-Bolson.rst b/source/Get-Started/Releases/Release-Bouncy-Bolson.rst index 50a3b63b1bc..dd0f3001c6b 100644 --- a/source/Get-Started/Releases/Release-Bouncy-Bolson.rst +++ b/source/Get-Started/Releases/Release-Bouncy-Bolson.rst @@ -1,159 +1,160 @@ -.. redirect-from:: - - Release-Bouncy-Bolson - -Bouncy Bolson (``bouncy``) -========================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Bouncy Bolson* is the second release of ROS 2. - -Supported Platforms -------------------- - -This version of ROS 2 is supported on four platforms (see `REP 2000 `__ for full details): - - -* Ubuntu 18.04 (Bionic) - - * Debian packages for amd64 as well as arm64 - -* Ubuntu 16.04 (Xenial) - - * no Debian packages but building from source is supported - -* Mac macOS 10.12 (Sierra) -* Windows 10 with Visual Studio 2017 - -Binary packages as well as instructions for how to compile from source are provided (see `install instructions <../../Installation>` as well as `documentation `__). - -Targeted platforms: - -+--------------+------------------------------------------------------------------------------------------------+------------------------+ -| | Required Support | Recommended Support | -+--------------+-----------------------+----------------------+---------------------+---------------------------+------------------------+ -| Architecture | Ubuntu Bionic (18.04) | MacOS Sierra (10.12) | Windows 10 (VS2017) | Ubuntu Xenial (16.04) [s] | Debian Stretch (9) [s] | -+==============+=======================+======================+=====================+===========================+========================+ -| amd64 | X | X | X | X [s] | X [s] | -+--------------+-----------------------+----------------------+---------------------+---------------------------+------------------------+ -| arm64 | X | | | X [s] | X [s] | -+--------------+-----------------------+----------------------+---------------------+---------------------------+------------------------+ - -\" \[s\] \" Compilation from source, the ROS buildfarm will not produce -any binary packages for these platforms. - -Minimum language requirements: - -- C11[^3] -- C++14 -- Python 3.5 - -Dependency Requirements: - -+---------+-------------------------------------------------------+---------------------+ -| | Required Support | Recommended Support | -+---------+---------------+-----------+------------+--------------+---------------------+ -| Package | Ubuntu Bionic | MacOS** | Windows 10 | Ubuntu | Debian | -| | | | ** | Xenial [s] | Stretch [s] | -+=========+===============+===========+============+==============+=====================+ -| CMake | 3.10.2 | 3.11.0 | 3.10.2 | 3.5.1 | 3.7.2 | -+---------+---------------+-----------+------------+--------------+---------------------+ -| EmPY | 3.3.2 | 3.6.5 | 3.3.2 | 3.3.2 | 3.3.2 | -+---------+---------------+-----------+------------+--------------+---------------------+ -| Ogre | 1.10* | 1.10* | 1.10* | 1.10* | 1.10* | -+---------+---------------+-----------+------------+--------------+---------------------+ -| OpenCV | 3.2.0 | 3.4.1 | 3.4.1* | 2.4.9 | 3.2* | -+---------+---------------+-----------+------------+--------------+---------------------+ -| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.8.0* | 1.8.0* | -+---------+---------------+-----------+------------+--------------+---------------------+ -| Python | 3.6.5 | 3.6.5 | 3.6.5 | 3.5.1 | 3.5.3 | -+---------+---------------+-----------+------------+--------------+---------------------+ -| Qt | 5.9.5 | 5.10.0 | 5.10.0 | 5.5.1 | 5.7.1 | -+---------+---------------+-----------+------------+--------------+---------------------+ -| **Linux only (used for turtlebot demo)** | -+---------+---------------+-----------+------------+--------------+---------------------+ -| PCL | 1.8.1 | N/A | N/A | 1.7.2 | 1.8.0 | -+---------+---------------+-----------+------------+--------------+---------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. - -\" \[s\] \" Compilation from source, the ROS buildfarm will not produce -any binary packages for these platforms. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu Bionic: apt -- MacOS: Homebrew, pip -- Windows: Chocolatey, pip -- Ubuntu Xenial, Debian Stretch: apt - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Middleware Implementation Support: - -- eProsima Fast-RTPS -- RTI Connext -- ADLINK OpenSplice - -Features --------- - -New features in this ROS 2 release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - -* `New launch system <../Tutorials/Intermediate/Launch/Launch-system>` featuring a much more capable and flexible Python API. -* Parameters can be passed as `command line arguments <../How-To-Guides/Node-arguments>` to C++ executables. -* Static remapping via `command line arguments <../How-To-Guides/Node-arguments>`. -* Various improvements to the Python client library. -* Support for publishing and subscribing to serialized data. - This is the foundation for the upcoming work towards a native rosbag implementation. -* More `command line tools <../../Concepts/Basic/About-Command-Line-Tools>`\ , e.g. for working with parameters and lifecycle states. -* Binary packages / fat archives support three RMW implementations by default (without the need to build from source): - - * eProsima's Fast RTPS (default) - * RTI's Connext - * ADLINK's OpenSplice - -For an overview of all features available, including those from earlier releases, please see the `Features <../../The-ROS2-Project/Features>` page. - -Changes since the Ardent release -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Changes since the `Ardent Apalone ` release: - - -* The Python package ``launch`` has been redesigned. - The previous Python API has been moved into a submodule ``launch.legacy``. - You can update existing launch files to continue to use the legacy API if a transition to the new Python API is not desired. -* The ROS topic names containing namespaces are mapped to DDS topics including their namespaces. - DDS partitions are not being used anymore for this. -* The recommended build tool is now ``colcon`` instead of ``ament_tools``. - This switch has no `implications `__ for the code in each ROS 2 package. - The install instructions have been updated and the `read-the-docs page `__ describes how to map an existing ``ament_tools`` call to ``colcon``. -* The argument order of `this rclcpp::Node::create_subscription() signature `__ has been modified. - -Known Issues ------------- - - -* New-style launch files `may hang on shutdown `__ for some combinations of platform and RMW implementation. -* Static remapping of namespaces `not working correctly `__ when addressed to a particular node. -* `Opensplice error messages may be printed `__ when using ``ros2 param`` and ``ros2 lifecycle`` command-line tools. +.. redirect-from:: + + Release-Bouncy-Bolson + Releases/Release-Bouncy-Bolson + +Bouncy Bolson (``bouncy``) +========================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Bouncy Bolson* is the second release of ROS 2. + +Supported Platforms +------------------- + +This version of ROS 2 is supported on four platforms (see `REP 2000 `__ for full details): + + +* Ubuntu 18.04 (Bionic) + + * Debian packages for amd64 as well as arm64 + +* Ubuntu 16.04 (Xenial) + + * no Debian packages but building from source is supported + +* Mac macOS 10.12 (Sierra) +* Windows 10 with Visual Studio 2017 + +Binary packages as well as instructions for how to compile from source are provided (see `install instructions <../../Installation>` as well as `documentation `__). + +Targeted platforms: + ++--------------+------------------------------------------------------------------------------------------------+------------------------+ +| | Required Support | Recommended Support | ++--------------+-----------------------+----------------------+---------------------+---------------------------+------------------------+ +| Architecture | Ubuntu Bionic (18.04) | MacOS Sierra (10.12) | Windows 10 (VS2017) | Ubuntu Xenial (16.04) [s] | Debian Stretch (9) [s] | ++==============+=======================+======================+=====================+===========================+========================+ +| amd64 | X | X | X | X [s] | X [s] | ++--------------+-----------------------+----------------------+---------------------+---------------------------+------------------------+ +| arm64 | X | | | X [s] | X [s] | ++--------------+-----------------------+----------------------+---------------------+---------------------------+------------------------+ + +\" \[s\] \" Compilation from source, the ROS buildfarm will not produce +any binary packages for these platforms. + +Minimum language requirements: + +- C11[^3] +- C++14 +- Python 3.5 + +Dependency Requirements: + ++---------+-------------------------------------------------------+---------------------+ +| | Required Support | Recommended Support | ++---------+---------------+-----------+------------+--------------+---------------------+ +| Package | Ubuntu Bionic | MacOS** | Windows 10 | Ubuntu | Debian | +| | | | ** | Xenial [s] | Stretch [s] | ++=========+===============+===========+============+==============+=====================+ +| CMake | 3.10.2 | 3.11.0 | 3.10.2 | 3.5.1 | 3.7.2 | ++---------+---------------+-----------+------------+--------------+---------------------+ +| EmPY | 3.3.2 | 3.6.5 | 3.3.2 | 3.3.2 | 3.3.2 | ++---------+---------------+-----------+------------+--------------+---------------------+ +| Ogre | 1.10* | 1.10* | 1.10* | 1.10* | 1.10* | ++---------+---------------+-----------+------------+--------------+---------------------+ +| OpenCV | 3.2.0 | 3.4.1 | 3.4.1* | 2.4.9 | 3.2* | ++---------+---------------+-----------+------------+--------------+---------------------+ +| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.8.0* | 1.8.0* | ++---------+---------------+-----------+------------+--------------+---------------------+ +| Python | 3.6.5 | 3.6.5 | 3.6.5 | 3.5.1 | 3.5.3 | ++---------+---------------+-----------+------------+--------------+---------------------+ +| Qt | 5.9.5 | 5.10.0 | 5.10.0 | 5.5.1 | 5.7.1 | ++---------+---------------+-----------+------------+--------------+---------------------+ +| **Linux only (used for turtlebot demo)** | ++---------+---------------+-----------+------------+--------------+---------------------+ +| PCL | 1.8.1 | N/A | N/A | 1.7.2 | 1.8.0 | ++---------+---------------+-----------+------------+--------------+---------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. + +\" \[s\] \" Compilation from source, the ROS buildfarm will not produce +any binary packages for these platforms. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu Bionic: apt +- MacOS: Homebrew, pip +- Windows: Chocolatey, pip +- Ubuntu Xenial, Debian Stretch: apt + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Middleware Implementation Support: + +- eProsima Fast-RTPS +- RTI Connext +- ADLINK OpenSplice + +Features +-------- + +New features in this ROS 2 release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +* `New launch system <../Tutorials/Intermediate/Launch/Launch-system>` featuring a much more capable and flexible Python API. +* Parameters can be passed as `command line arguments <../How-To-Guides/Node-arguments>` to C++ executables. +* Static remapping via `command line arguments <../How-To-Guides/Node-arguments>`. +* Various improvements to the Python client library. +* Support for publishing and subscribing to serialized data. + This is the foundation for the upcoming work towards a native rosbag implementation. +* More `command line tools <../../Concepts/Basic/About-Command-Line-Tools>`\ , e.g. for working with parameters and lifecycle states. +* Binary packages / fat archives support three RMW implementations by default (without the need to build from source): + + * eProsima's Fast RTPS (default) + * RTI's Connext + * ADLINK's OpenSplice + +For an overview of all features available, including those from earlier releases, please see the `Features <../../The-ROS2-Project/Features>` page. + +Changes since the Ardent release +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Changes since the `Ardent Apalone ` release: + + +* The Python package ``launch`` has been redesigned. + The previous Python API has been moved into a submodule ``launch.legacy``. + You can update existing launch files to continue to use the legacy API if a transition to the new Python API is not desired. +* The ROS topic names containing namespaces are mapped to DDS topics including their namespaces. + DDS partitions are not being used anymore for this. +* The recommended build tool is now ``colcon`` instead of ``ament_tools``. + This switch has no `implications `__ for the code in each ROS 2 package. + The install instructions have been updated and the `read-the-docs page `__ describes how to map an existing ``ament_tools`` call to ``colcon``. +* The argument order of `this rclcpp::Node::create_subscription() signature `__ has been modified. + +Known Issues +------------ + + +* New-style launch files `may hang on shutdown `__ for some combinations of platform and RMW implementation. +* Static remapping of namespaces `not working correctly `__ when addressed to a particular node. +* `Opensplice error messages may be printed `__ when using ``ros2 param`` and ``ros2 lifecycle`` command-line tools. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Crystal-Clemmys.rst b/source/Get-Started/Releases/Release-Crystal-Clemmys.rst index 9389d6e8160..83160fde304 100644 --- a/source/Get-Started/Releases/Release-Crystal-Clemmys.rst +++ b/source/Get-Started/Releases/Release-Crystal-Clemmys.rst @@ -1,273 +1,274 @@ -.. redirect-from:: - - Release-Crystal-Clemmys - -Crystal Clemmys (``crystal``) -============================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Crystal Clemmys* is the third release of ROS 2. - -Supported Platforms -------------------- - -Crystal Clemmys supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 18.04 (Bionic) -* Mac macOS 10.12 (Sierra) -* Windows 10 - -Tier 2 platforms: - -* Ubuntu 16.04 (Xenial) - -Targeted platforms: - -+--------------+-----------------------+----------------------+--------------------+-----------------------+-------------------+ -| Architecture | Ubuntu Bionic (18.04) | MacOS Sierra (10.12) | Windows 10 (VS2017)| Ubuntu Xenial (16.04) | Debian Stretch (9)| -+==============+=======================+======================+====================+=======================+===================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 2 [s] | Tier 3 [s] | -+--------------+-----------------------+----------------------+--------------------+-----------------------+-------------------+ -| arm64 | Tier 1 [d][a][s] | | | Tier 2 [s] | Tier 3 [s] | -+--------------+-----------------------+----------------------+--------------------+-----------------------+-------------------+ - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Debian packages will be provided for this platform for -packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Crystal ROS 2 repos file[^4]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=====================+===============+=============================+================================+ -| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ -| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except Debian | All Architectures except arm64 | -+--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ -| rmw_opensplice_cpp | ADLINK OpenSplice | Tier 2 | All Platforms except Debian | All Architectures | -+--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ -| rmw_connext_dynamic_cpp | RTI Connext | Tier 2 | All platforms except Debian | All architectures except arm64 | -+--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C11[^5] -- C++14 -- Python 3.5 - -Dependency Requirements: - -+------------+----------------------------------------------------------+--------------------+ -| | Required Support | Recommended Support| -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Package | Ubuntu Bionic | MacOS** | Windows 10* | Ubuntu Xenial[s]| Debian Stretch [s] | -+============+===============+==========+=============+=================+====================+ -| CMake | 3.10.2 | 3.13.3 | 3.13.3 | 3.5.1 | 3.7.2 | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| EmPY | 3.3.2 | 3.3.2 | 3.3.2 | 3.3.2 | 3.3.2 | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Gazebo | 9.0.0 | 9.9.0 | N/A | 9.9.0* | 9.8.0* | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Ogre | 1.10* | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| OpenCV | 3.2.0 | 4.0.1 | 3.4.1* | 2.4.9 | 3.2* | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| OpenSSL | 1.1.0g | 1.0.2q | 1.0.2q | 1.0.2g | 1.1.0j | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.8.0* | 1.8.0* | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Python | 3.6.5 | 3.7.2 | 3.7.2 | 3.5.1 | 3.5.3 | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Qt | 5.9.5 | 5.12.0 | 5.10.0 | 5.5.1 | 5.7.1 | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| | **Linux only** | | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| PCL | 1.8.1 | N/A | N/A | 1.7.2 | 1.8.0 | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| **RMW DDS Middleware Providers** | -+------------+---------------+----------+-------------+-----------------+--------------------+ -| Connext DDS| 5.3.1 | N/A | -+------------+----------------------------------------------------------+--------------------+ -| Fast-RTPS | 1.7.0 | -+------------+-------------------------------------------------------------------------------+ -| OpenSplice | 6.9.181127OSS | -+------------+-------------------------------------------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. - -\" \[s\] \" Compilation from source, the ROS buildfarm will not produce -any binary packages for these platforms. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- MacOS: Homebrew, pip -- Windows: Chocolatey, pip - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -New features in this ROS 2 release ----------------------------------- - -* Actions in C / C++ (`server `__ / `client `__ examples) -* `gazebo_ros_pkgs `__ -* `image_transport `__ -* `navigation2 `__ -* `rosbag2 `__ -* `rqt <../../Concepts/Intermediate/About-RQt>` -* Improvement in memory management -* Introspection information about nodes -* Launch system improvements - - * `Arguments `__ - * `Nested launch files `__ - * `Conditions `__ - * `Pass params to Nodes `__ - -* Laid the groundwork for `file-based logging and /rosout publishing `__ -* `Time and Duration API in Python `__ -* `Parameters work with Python nodes `__ - - -Changes since the Bouncy release --------------------------------- - -Changes since the `Bouncy Bolson ` release: - -* geometry2 - ``tf2_ros::Buffer`` API Change - - ``tf2_ros::Buffer`` now uses ``rclcpp::Time``, with the constructor requiring a ``shared_ptr`` to a ``rclcpp::Clock`` instance. - See https://github.com/ros2/geometry2/pull/67 for details, with example usage: - - .. code-block:: c++ - - #include - #include - ... - # Assuming you have a rclcpp::Node my_node - tf2_ros::Buffer buffer(my_node.get_clock()); - tf2_ros::TransformListener tf_listener(buffer); - -* All ``rclcpp`` and ``rcutils`` logging macros require semicolons. - - See https://github.com/ros2/rcutils/issues/113 for details. - -* ``rcutils_get_error_string_safe()`` and ``rcl_get_error_string_safe()`` have been replaced with ``rcutils_get_error_string().str`` and ``rcl_get_error_string().str``. - - See https://github.com/ros2/rcutils/pull/121 for details. - -* rmw - ``rmw_init`` API Change - - There are two new structs, the ``rcl_context_t`` and the ``rcl_init_options_t``, which are used with ``rmw_init``. - The init options struct is used to pass options down to the middleware and is an input to ``rmw_init``. - The context is a handle which is an output of ``rmw_init`` function is used to identify which init-shutdown cycle each entity is associated with, where an "entity" is anything created like a node, guard condition, etc. - - This is listed here because maintainers of alternative rmw implementations will need to implement these new functions to have their rmw implementation work in Crystal. - - This is the function that had a signature change: - - * `rmw_init `__ - - Additionally, there are these new functions which need to be implemented by each rmw implementation: - - * `rmw_shutdown `__ - * `rmw_init_options_init `__ - * `rmw_init_options_copy `__ - * `rmw_init_options_fini `__ - - Here's an example of what minimally needs to be changed in an rmw implementation to adhere to this API change: - - * `rmw_fastrtps pr `_ - -* rcl - ``rcl_init`` API Change - - Like the ``rmw`` change above, there's two new structs in ``rcl`` called ``rcl_context_t`` and ``rcl_init_options_t``. - The init options are passed into ``rcl_init`` as an input and the context is passed in as an output. - The context is used to associate all other rcl entities to a specific init-shutdown cycle, effectively making init and shutdown no longer global functions, or rather those functions no longer use an global state and instead encapsulate all state within the context type. - - Any maintainers of a client library implementation (that also uses ``rcl`` under the hood) will need to make changes to work with Crystal. - - These functions were removed: - - * ``rcl_get_global_arguments`` - * ``rcl_get_instance_id`` - * ``rcl_ok`` - - These functions had signature changes: - - * `rcl_init `__ - * `rcl_shutdown `__ - * `rcl_guard_condition_init `__ - * `rcl_guard_condition_init_from_rmw `__ - * `rcl_node_init `__ - * `rcl_timer_init `__ - - These are the new functions and types: - - * `rcl_context_t `__ - * `rcl_get_zero_initialized_context `__ - * `rcl_context_fini `__ - * `rcl_context_get_init_options `__ - * `rcl_context_get_instance_id `__ - * `rcl_context_is_valid `__ - * `rcl_init_options_t `__ - * `rcl_get_zero_initialized_init_options `__ - * `rcl_init_options_init `__ - * `rcl_init_options_copy `__ - * `rcl_init_options_fini `__ - * `rcl_init_options_get_rmw_init_options `__ - * `rcl_node_is_valid_except_context `__ - * `rcl_publisher_get_context `__ - * `rcl_publisher_is_valid_except_context `__ - - These new and changed functions will impact how you handle init and shutdown in your client library. - For examples, look at the following ``rclcpp`` and ``rclpy`` PR's: - - * `rclcpp `__ - * `rclpy `__ - - However, you may just continue to offer a single, global init and shutdown in your client library, and just store a single global context object. - -Known Issues ------------- - -* A race condition in Fast-RTPS 1.7.0 may cause messages to drop under stress (`Issue `__). -* Using the TRANSIENT_LOCAL QoS setting with rmw_fastrtps_cpp can crash applications with large messages (`Issue `__). -* Cross-vendor communication between rmw_fastrtps_cpp and other implementations is not functioning on Windows (`Issue `__). -* When using OpenSplice (version < 6.9.190227) on macOS and Windows you might experience naming conflicts when when referencing field types with names from other packages if the same name also exist in the current package (`Issue `__). - By updating to a newer OpenSplice version as well as at least the third patch release of Crystal the problem should be resolved. - On Linux updating to the latest Debian packages will include the newest OpenSplice version. +.. redirect-from:: + + Release-Crystal-Clemmys + Releases/Release-Crystal-Clemmys + +Crystal Clemmys (``crystal``) +============================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Crystal Clemmys* is the third release of ROS 2. + +Supported Platforms +------------------- + +Crystal Clemmys supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 18.04 (Bionic) +* Mac macOS 10.12 (Sierra) +* Windows 10 + +Tier 2 platforms: + +* Ubuntu 16.04 (Xenial) + +Targeted platforms: + ++--------------+-----------------------+----------------------+--------------------+-----------------------+-------------------+ +| Architecture | Ubuntu Bionic (18.04) | MacOS Sierra (10.12) | Windows 10 (VS2017)| Ubuntu Xenial (16.04) | Debian Stretch (9)| ++==============+=======================+======================+====================+=======================+===================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 2 [s] | Tier 3 [s] | ++--------------+-----------------------+----------------------+--------------------+-----------------------+-------------------+ +| arm64 | Tier 1 [d][a][s] | | | Tier 2 [s] | Tier 3 [s] | ++--------------+-----------------------+----------------------+--------------------+-----------------------+-------------------+ + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Debian packages will be provided for this platform for +packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Crystal ROS 2 repos file[^4]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=====================+===============+=============================+================================+ +| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ +| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except Debian | All Architectures except arm64 | ++--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ +| rmw_opensplice_cpp | ADLINK OpenSplice | Tier 2 | All Platforms except Debian | All Architectures | ++--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ +| rmw_connext_dynamic_cpp | RTI Connext | Tier 2 | All platforms except Debian | All architectures except arm64 | ++--------------------------+---------------------+---------------+-----------------------------+--------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C11[^5] +- C++14 +- Python 3.5 + +Dependency Requirements: + ++------------+----------------------------------------------------------+--------------------+ +| | Required Support | Recommended Support| ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Package | Ubuntu Bionic | MacOS** | Windows 10* | Ubuntu Xenial[s]| Debian Stretch [s] | ++============+===============+==========+=============+=================+====================+ +| CMake | 3.10.2 | 3.13.3 | 3.13.3 | 3.5.1 | 3.7.2 | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| EmPY | 3.3.2 | 3.3.2 | 3.3.2 | 3.3.2 | 3.3.2 | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Gazebo | 9.0.0 | 9.9.0 | N/A | 9.9.0* | 9.8.0* | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Ogre | 1.10* | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| OpenCV | 3.2.0 | 4.0.1 | 3.4.1* | 2.4.9 | 3.2* | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| OpenSSL | 1.1.0g | 1.0.2q | 1.0.2q | 1.0.2g | 1.1.0j | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.8.0* | 1.8.0* | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Python | 3.6.5 | 3.7.2 | 3.7.2 | 3.5.1 | 3.5.3 | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Qt | 5.9.5 | 5.12.0 | 5.10.0 | 5.5.1 | 5.7.1 | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| | **Linux only** | | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| PCL | 1.8.1 | N/A | N/A | 1.7.2 | 1.8.0 | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| **RMW DDS Middleware Providers** | ++------------+---------------+----------+-------------+-----------------+--------------------+ +| Connext DDS| 5.3.1 | N/A | ++------------+----------------------------------------------------------+--------------------+ +| Fast-RTPS | 1.7.0 | ++------------+-------------------------------------------------------------------------------+ +| OpenSplice | 6.9.181127OSS | ++------------+-------------------------------------------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. + +\" \[s\] \" Compilation from source, the ROS buildfarm will not produce +any binary packages for these platforms. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- MacOS: Homebrew, pip +- Windows: Chocolatey, pip + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +New features in this ROS 2 release +---------------------------------- + +* Actions in C / C++ (`server `__ / `client `__ examples) +* `gazebo_ros_pkgs `__ +* `image_transport `__ +* `navigation2 `__ +* `rosbag2 `__ +* `rqt <../../Concepts/Intermediate/About-RQt>` +* Improvement in memory management +* Introspection information about nodes +* Launch system improvements + + * `Arguments `__ + * `Nested launch files `__ + * `Conditions `__ + * `Pass params to Nodes `__ + +* Laid the groundwork for `file-based logging and /rosout publishing `__ +* `Time and Duration API in Python `__ +* `Parameters work with Python nodes `__ + + +Changes since the Bouncy release +-------------------------------- + +Changes since the `Bouncy Bolson ` release: + +* geometry2 - ``tf2_ros::Buffer`` API Change + + ``tf2_ros::Buffer`` now uses ``rclcpp::Time``, with the constructor requiring a ``shared_ptr`` to a ``rclcpp::Clock`` instance. + See https://github.com/ros2/geometry2/pull/67 for details, with example usage: + + .. code-block:: c++ + + #include + #include + ... + # Assuming you have a rclcpp::Node my_node + tf2_ros::Buffer buffer(my_node.get_clock()); + tf2_ros::TransformListener tf_listener(buffer); + +* All ``rclcpp`` and ``rcutils`` logging macros require semicolons. + + See https://github.com/ros2/rcutils/issues/113 for details. + +* ``rcutils_get_error_string_safe()`` and ``rcl_get_error_string_safe()`` have been replaced with ``rcutils_get_error_string().str`` and ``rcl_get_error_string().str``. + + See https://github.com/ros2/rcutils/pull/121 for details. + +* rmw - ``rmw_init`` API Change + + There are two new structs, the ``rcl_context_t`` and the ``rcl_init_options_t``, which are used with ``rmw_init``. + The init options struct is used to pass options down to the middleware and is an input to ``rmw_init``. + The context is a handle which is an output of ``rmw_init`` function is used to identify which init-shutdown cycle each entity is associated with, where an "entity" is anything created like a node, guard condition, etc. + + This is listed here because maintainers of alternative rmw implementations will need to implement these new functions to have their rmw implementation work in Crystal. + + This is the function that had a signature change: + + * `rmw_init `__ + + Additionally, there are these new functions which need to be implemented by each rmw implementation: + + * `rmw_shutdown `__ + * `rmw_init_options_init `__ + * `rmw_init_options_copy `__ + * `rmw_init_options_fini `__ + + Here's an example of what minimally needs to be changed in an rmw implementation to adhere to this API change: + + * `rmw_fastrtps pr `_ + +* rcl - ``rcl_init`` API Change + + Like the ``rmw`` change above, there's two new structs in ``rcl`` called ``rcl_context_t`` and ``rcl_init_options_t``. + The init options are passed into ``rcl_init`` as an input and the context is passed in as an output. + The context is used to associate all other rcl entities to a specific init-shutdown cycle, effectively making init and shutdown no longer global functions, or rather those functions no longer use an global state and instead encapsulate all state within the context type. + + Any maintainers of a client library implementation (that also uses ``rcl`` under the hood) will need to make changes to work with Crystal. + + These functions were removed: + + * ``rcl_get_global_arguments`` + * ``rcl_get_instance_id`` + * ``rcl_ok`` + + These functions had signature changes: + + * `rcl_init `__ + * `rcl_shutdown `__ + * `rcl_guard_condition_init `__ + * `rcl_guard_condition_init_from_rmw `__ + * `rcl_node_init `__ + * `rcl_timer_init `__ + + These are the new functions and types: + + * `rcl_context_t `__ + * `rcl_get_zero_initialized_context `__ + * `rcl_context_fini `__ + * `rcl_context_get_init_options `__ + * `rcl_context_get_instance_id `__ + * `rcl_context_is_valid `__ + * `rcl_init_options_t `__ + * `rcl_get_zero_initialized_init_options `__ + * `rcl_init_options_init `__ + * `rcl_init_options_copy `__ + * `rcl_init_options_fini `__ + * `rcl_init_options_get_rmw_init_options `__ + * `rcl_node_is_valid_except_context `__ + * `rcl_publisher_get_context `__ + * `rcl_publisher_is_valid_except_context `__ + + These new and changed functions will impact how you handle init and shutdown in your client library. + For examples, look at the following ``rclcpp`` and ``rclpy`` PR's: + + * `rclcpp `__ + * `rclpy `__ + + However, you may just continue to offer a single, global init and shutdown in your client library, and just store a single global context object. + +Known Issues +------------ + +* A race condition in Fast-RTPS 1.7.0 may cause messages to drop under stress (`Issue `__). +* Using the TRANSIENT_LOCAL QoS setting with rmw_fastrtps_cpp can crash applications with large messages (`Issue `__). +* Cross-vendor communication between rmw_fastrtps_cpp and other implementations is not functioning on Windows (`Issue `__). +* When using OpenSplice (version < 6.9.190227) on macOS and Windows you might experience naming conflicts when when referencing field types with names from other packages if the same name also exist in the current package (`Issue `__). + By updating to a newer OpenSplice version as well as at least the third patch release of Crystal the problem should be resolved. + On Linux updating to the latest Debian packages will include the newest OpenSplice version. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Dashing-Diademata.rst b/source/Get-Started/Releases/Release-Dashing-Diademata.rst index 22f8e88edbc..73bbe6e4660 100644 --- a/source/Get-Started/Releases/Release-Dashing-Diademata.rst +++ b/source/Get-Started/Releases/Release-Dashing-Diademata.rst @@ -1,937 +1,941 @@ -Dashing Diademata (``dashing``) -=============================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Dashing Diademata* is the fourth release of ROS 2. - -Supported Platforms -------------------- - -Dashing Diademata supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 18.04 (Bionic): ``amd64`` and ``arm64`` -* Mac macOS 10.12 (Sierra) -* Windows 10 (Visual Studio 2019) - -Tier 2 platforms: - -* Ubuntu 18.04 (Bionic): ``arm32`` - -Tier 3 platforms: - -* Debian Stretch (9): ``amd64``, ``arm64`` and ``arm32`` -* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` - -Targeted platforms: - -+--------------+----------------------+----------------------+--------------------+--------------------+----------------+ -| Architecture | Ubuntu Bionic | MacOS Sierra | Windows 10 | Debian Stretch | OpenEmbedded / | -| | (18.04) | (10.12) | (VS2019) | (9) | webOS OSE | -+==============+======================+======================+====================+====================+================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 3 [s] | | -+--------------+----------------------+----------------------+--------------------+--------------------+----------------+ -| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+----------------------+--------------------+--------------------+----------------+ -| arm32 | Tier 2 [a][s] | | | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+----------------------+--------------------+--------------------+----------------+ - - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Debian packages will be provided for this platform for -packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Dashing ROS 2 repos file[^6]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+---------------------+---------------+--------------------------+--------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=====================+===============+==========================+==========================+ -| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+--------------------------+--------------------------+ -| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except | All Architectures except | -| | | | Debian and OpenEmbedded | arm64/arm32 | -+--------------------------+---------------------+---------------+--------------------------+--------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 2 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+--------------------------+--------------------------+ -| rmw_opensplice_cpp | ADLink OpenSplice | Tier 2 | All Platforms except | All Architectures | -| | | | Debian and OpenEmbedded | | -+--------------------------+---------------------+---------------+--------------------------+--------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+--------------------------+--------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++14 -- Python 3.5 - -Dependency Requirements: - -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| | Required Support | Recommended Support | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Package | Ubuntu Bionic | MacOS** | Windows 10** | Debian Stretch | OpenEmbedded** | -+==============+=================+=================+=================+=================+=======================+ -| CMake | 3.10.2 | 3.14.4 | 3.14.4 | 3.7.2 | 3.16.1 / 3.12.2*** | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| EmPY | 3.3.2 | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Gazebo | 9.0.0 | 9.9.0 | N/A | 9.8.0* | N/A | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Ogre | 1.10* | N/A | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| OpenCV | 3.2.0 | 4.1.0 | 3.4.6* | 3.2* | 4.1.0 / 3.2.0*** | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| OpenSSL | 1.1.0g | 1.0.2r | 1.0.2r | 1.1.0j | 1.1.1d / 1.1.1b*** | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.8.0* | 1.9.4 | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Python | 3.6.5 | 3.7.3 | 3.7.3 | 3.5.3 | 3.8.2 / 3.7.5*** | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Qt | 5.9.5 | 5.12.3 | 5.10.0 | 5.7.1 | 5.14.1 / 5.12.5*** | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| | | **Linux only** | | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| PCL | 1.8.1 | N/A | N/A | 1.8.0 | 1.8.1 | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| **RMW DDS Middleware Providers** | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Connext DDS | 5.3.1 | N/A | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Cyclone DDS | 0.7.x (Coquette) | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| Fast-RTPS | 1.8.0 | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ -| OpenSplice | 6.9.190403OSS | N/A | -+--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. The versions shown for -OpenEmbedded are those provided by the 3.1 Dunfell release series; the -versions provided by the other supported release series are listed here: - . -Note that the OpenEmbedded releases series for which a ROS distro has -support will change during its support time frame, as per the -OpenEmbedded support policy shown here: - -. However, it will always be supported by least one stable OpenEmbedded -release series. - -\" \*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- MacOS: Homebrew, pip -- Windows: Chocolatey, pip -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Dashing Diademata <../../dashing/Installation.html>`__ - -New features in this ROS 2 release ----------------------------------- - -A few features and improvements we would like to highlight: - -* :doc:`Components <../Tutorials/Intermediate/Composition>` are now the recommended way to write your node. - They can be used standalone as well as being composed within a process and both ways are fully support from ``launch`` files. -* The :doc:`intra-process communication <../Tutorials/Demos/Intra-Process-Communication>` (C++ only) has been improved - both in terms of latency as well as minimizing copies. -* The Python client library has been updated to match most of the C++ equivalent and some important bug fixes and improvements have landed related to memory usage and performance. -* Parameters are now a complete alternative to ``dynamic_reconfigure`` from ROS 1 including constraints like ranges or being read-only. -* By relying on (a subset of) `IDL 4.2 `__ for the message generation pipeline it is now possible to use ``.idl`` files (beside ``.msg`` / ``.srv`` / ``.action`` files). - This change comes with support for optional UTF-8 encoding for ordinary strings as well as UTF-16 encoded multi-byte strings (see `wide strings design article `__). -* Command line tools related to ``actions`` and ``components``. -* Support for Deadline, Lifespan & Liveliness quality of service settings. -* MoveIt 2 `alpha release `__. - -Please see the `Dashing meta ticket `__ on GitHub, which contains more information as well as references to specific tickets with additional details. - - -Changes since the Crystal release ---------------------------------- - -Declaring Parameters -^^^^^^^^^^^^^^^^^^^^ - -There have been some changes to the behavior of parameters starting in Dashing, which have also lead to some new API's and the deprecation of other API's. -See the ``rclcpp`` and ``rclpy`` sections below for more information about API changes. - -Getting and Setting Undeclared Parameters -""""""""""""""""""""""""""""""""""""""""" - -As of Dashing, parameters now need to be declared before being accessed or set. - -Before Dashing, you could call ``get_parameter(name)`` and get either a value, if it had been previously set, or a parameter of type ``PARAMETER_NOT_SET``. -You could also call ``set_parameter(name, value)`` at any point, even if the parameter was previously unset. - -Since Dashing, you need to first declare a parameter before getting or setting it. -If you try to get or set an undeclared parameter you will either get an exception thrown, e.g. ParameterNotDeclaredException, or in certain cases you will get an unsuccessful result communicated in a variety of ways (see specific functions for more details). - -However, you can get the old behavior (mostly, see the note in the next paragraph) by using the ``allow_undeclared_parameters`` option when creating your node. -You might want to do this in order to avoid code changes for now, or in order to fulfill some uncommon use cases. -For example, a "global parameter server" or "parameter blackboard" may want to allow external nodes to set new parameters on itself without first declaring them, so it may use the ``allow_undeclared_parameters`` option to accomplish that. -In most cases, however, this option is not recommended because it makes the rest of the parameter API less safe to bugs like parameter name typos and "use before set" logical errors. - -Note that using ``allow_undeclared_parameters`` will get you most of the old behavior specifically for "get" and "set" methods, but it will not revert all the behavior changes related to parameters back to how it was for ROS Crystal. -For that you need to also set the ``automatically_declare_parameters_from_overrides`` option to ``true``, which is described below in :ref:`Parameter Configuration using a YAML File `. - -Declaring a Parameter with a ParameterDescriptor -"""""""""""""""""""""""""""""""""""""""""""""""" - -Another benefit to declaring your parameters before using them, is that it allows you to declare a parameter descriptor at the same time. - -Now when declaring a parameter you may include a custom ``ParameterDescriptor`` as well as a name and default value. -The ``ParameterDescriptor`` is defined as a message in ``rcl_interfaces/msg/ParameterDescriptor`` and contains meta data like ``description`` and constraints like ``read_only`` or ``integer_range``. -These constraints can be used to reject invalid values when setting parameters and/or as hints to external tools about what values are valid for a given parameter. -The ``read_only`` constraint will prevent the parameter's value from changing after being declared, as well as prevent if from being undeclared. - -For reference, here's a link to the ``ParameterDescriptor`` message as of the time of writing this: - -https://github.com/ros2/rcl_interfaces/blob/0aba5a142878c2077d7a03977087e7d74d40ee68/rcl_interfaces/msg/ParameterDescriptor.msg#L1 - -.. _parameter-configuration-using-a-yaml-file: - -Parameter Configuration using a YAML File -""""""""""""""""""""""""""""""""""""""""" - -As of Dashing, parameters in a YAML configuration file, e.g. passed to the node via the command line argument ``__params:=``, are only used to override a parameter's default value when declaring the parameter. - -Before Dashing, any parameters you passed via a YAML file would be implicitly set on the node. - -Since Dashing, this is no longer the case, as parameters need to be declared in order to appear on the node to external observers, like ``ros2 param list``. - -The old behavior may be achieved using the ``automatically_declare_parameters_from_overrides`` option when creating a node. -This option, if set to ``true``, will automatically declare all parameters in the input YAML file when the node is constructed. -This may be used to avoid major changes to your existing code or to serve specific use cases. -For example, a "global parameter server" may want to be seeded with arbitrary parameters on launch, which it could not have declared ahead of time. -Most of the time, however, this option is not recommended, as it may lead to setting a parameter in a YAML file with the assumption that the node will use it, even if the node does not actually use it. - -In the future we hope to have a checker that will warn you if you pass a parameter to a node that it was not expecting. - -The parameters in the YAML file will continue to influence the value of parameters when they are first declared. - -ament_cmake -^^^^^^^^^^^ - -The CMake function ``ament_index_has_resource`` was returning either ``TRUE`` or ``FALSE``. -As of `this release `_ it returns either the prefix path in case the resource was found or ``FALSE``. - -If you are using the return value in a CMake condition like this: - -.. code-block:: cmake - - ament_index_has_resource(var ...) - if(${var}) - -you need to update the condition to ensure it considers a string value as ``TRUE``: - -.. code-block:: cmake - - if(var) - -rclcpp -^^^^^^ - -Behavior Change for ``Node::get_node_names()`` -"""""""""""""""""""""""""""""""""""""""""""""" - -The function ``NodeGraph::get_node_names()``, and therefore also ``Node::get_node_names()``, now returns a ``std::vector`` containing fully qualified node names with their namespaces included, instead of just the node names. - -Changed the Way that Options are Passed to Nodes -"""""""""""""""""""""""""""""""""""""""""""""""" - -Extended arguments (beyond name and namespace) to the ``rclcpp::Node()`` constructor have been replaced with a ``rclcpp::NodeOptions`` structure. -See `ros2/rclcpp#622 `__ for details about the structure and default values of the options. - -If you are using any of the extended arguments to ``rclcpp::Node()`` like this: - -.. code-block:: cpp - - auto context = rclcpp::contexts::default_context::get_global_default_context(); - std::vector args; - std::vector params = { rclcpp::Parameter("use_sim_time", true) }; - auto node = std::make_shared("foo_node", "bar_namespace", context, args, params); - -You need to update to use the ``NodeOptions`` structure - -.. code-block:: cpp - - std::vector args; - std::vector params = { rclcpp::Parameter("use_sim_time", true) }; - rclcpp::NodeOptions node_options; - node_options.arguments(args); - node_options.parameter_overrides(params); - auto node = std::make_shared("foo_node", "bar_namespace", node_options); - -Changes to Creating Publishers and Subscriptions -"""""""""""""""""""""""""""""""""""""""""""""""" - -There have been a few changes to creating publishers and subscriptions which are new in Dashing: - -- QoS settings are now passed using the new ``rclcpp::QoS`` class, and the API encourages the user to specify at least the history depth. -- Options are now passed as an object, i.e. ``rclcpp::PublisherOptions`` and ``rclcpp::SubscriptionOptions``. - -All changes are backwards compatible (no code changes are required), but several existing call styles have been deprecated. -Users are encouraged to update to the new signatures. - ----- - -In the past, when creating a publisher or subscription, you could either not specify any QoS settings (e.g. just provide topic name for a publisher) or you could specify a "qos profile" data structure (of type ``rmw_qos_profile_t``) with all the settings already set. -Now you must use the new ``rclcpp::QoS`` object to specify your QoS and at least the history settings for your QoS. -This encourages the user to specify a history depth when using ``KEEP_LAST``, rather than defaulting it to a value that may or may not be appropriate. - -In ROS 1, this was known as the ``queue_size`` and it was required in both C++ and Python. -We're changing the ROS 2 API to bring this requirement back. - ----- - -Also, any options which could previously be passed during creation of a publisher or subscription have now been encapsulated in an ``rclcpp::PublisherOptions`` and ``rclcpp::SubscriptionOptions`` class respectively. -This allows for shorter signatures, more convenient use, and for adding new future options without breaking API. - ----- - -Some signatures for creating publishers and subscribers are now deprecated, and new signatures have been added to allow you to use the new ``rclcpp::QoS`` and publisher/subscription option classes. - -These are the new and recommended API's: - -.. code-block:: cpp - - template< - typename MessageT, - typename AllocatorT = std::allocator, - typename PublisherT = ::rclcpp::Publisher> - std::shared_ptr - create_publisher( - const std::string & topic_name, - const rclcpp::QoS & qos, - const PublisherOptionsWithAllocator & options = - PublisherOptionsWithAllocator() - ); - - template< - typename MessageT, - typename CallbackT, - typename AllocatorT = std::allocator, - typename SubscriptionT = rclcpp::Subscription< - typename rclcpp::subscription_traits::has_message_type::type, AllocatorT>> - std::shared_ptr - create_subscription( - const std::string & topic_name, - const rclcpp::QoS & qos, - CallbackT && callback, - const SubscriptionOptionsWithAllocator & options = - SubscriptionOptionsWithAllocator(), - typename rclcpp::message_memory_strategy::MessageMemoryStrategy< - typename rclcpp::subscription_traits::has_message_type::type, AllocatorT - >::SharedPtr - msg_mem_strat = nullptr); - -And these are the deprecated ones: - -.. code-block:: cpp - - template< - typename MessageT, - typename AllocatorT = std::allocator, - typename PublisherT = ::rclcpp::Publisher> - [[deprecated("use create_publisher(const std::string &, const rclcpp::QoS &, ...) instead")]] - std::shared_ptr - create_publisher( - const std::string & topic_name, - size_t qos_history_depth, - std::shared_ptr allocator); - - template< - typename MessageT, - typename AllocatorT = std::allocator, - typename PublisherT = ::rclcpp::Publisher> - [[deprecated("use create_publisher(const std::string &, const rclcpp::QoS &, ...) instead")]] - std::shared_ptr - create_publisher( - const std::string & topic_name, - const rmw_qos_profile_t & qos_profile = rmw_qos_profile_default, - std::shared_ptr allocator = nullptr); - - template< - typename MessageT, - typename CallbackT, - typename Alloc = std::allocator, - typename SubscriptionT = rclcpp::Subscription< - typename rclcpp::subscription_traits::has_message_type::type, Alloc>> - [[deprecated( - "use create_subscription(const std::string &, const rclcpp::QoS &, CallbackT, ...) instead" - )]] - std::shared_ptr - create_subscription( - const std::string & topic_name, - CallbackT && callback, - const rmw_qos_profile_t & qos_profile = rmw_qos_profile_default, - rclcpp::callback_group::CallbackGroup::SharedPtr group = nullptr, - bool ignore_local_publications = false, - typename rclcpp::message_memory_strategy::MessageMemoryStrategy< - typename rclcpp::subscription_traits::has_message_type::type, Alloc>::SharedPtr - msg_mem_strat = nullptr, - std::shared_ptr allocator = nullptr); - - template< - typename MessageT, - typename CallbackT, - typename Alloc = std::allocator, - typename SubscriptionT = rclcpp::Subscription< - typename rclcpp::subscription_traits::has_message_type::type, Alloc>> - [[deprecated( - "use create_subscription(const std::string &, const rclcpp::QoS &, CallbackT, ...) instead" - )]] - std::shared_ptr - create_subscription( - const std::string & topic_name, - CallbackT && callback, - size_t qos_history_depth, - rclcpp::callback_group::CallbackGroup::SharedPtr group = nullptr, - bool ignore_local_publications = false, - typename rclcpp::message_memory_strategy::MessageMemoryStrategy< - typename rclcpp::subscription_traits::has_message_type::type, Alloc>::SharedPtr - msg_mem_strat = nullptr, - std::shared_ptr allocator = nullptr); - ----- - -The change to how QoS is passed is most likely to impact users. - -A typical change for a publisher looks like this: - -.. code-block:: diff - - - pub_ = create_publisher("chatter"); - + pub_ = create_publisher("chatter", 10); - -And for a subscription: - -.. code-block:: diff - - - sub_ = create_subscription("chatter", callback); - + sub_ = create_subscription("chatter", 10, callback); - -If you have no idea what depth to use and don't care right now (maybe just prototyping), then we recommend using ``10``, as that was the default before and should preserve existing behavior. - -More in depth documentation about how to select an appropriate depth is forthcoming. - -This is an example of a slightly more involved change to avoid the newly deprecated API's: - -.. code-block:: diff - - - // Creates a latched topic - - rmw_qos_profile_t qos = rmw_qos_profile_default; - - qos.depth = 1; - - qos.durability = RMW_QOS_POLICY_DURABILITY_TRANSIENT_LOCAL; - - - model_xml_.data = model_xml; - node_handle->declare_parameter("robot_description", model_xml); - description_pub_ = node_handle->create_publisher( - - "robot_description", qos); - + "robot_description", - + // Transient local is similar to latching in ROS 1. - + rclcpp::QoS(1).transient_local()); - -See the pull request (and connected pull requests) that introduced the QoS change for more examples and details: - -- https://github.com/ros2/rclcpp/pull/713 - - - https://github.com/ros2/demos/pull/332 - - https://github.com/ros2/robot_state_publisher/pull/19 - - and others... - - -Changes Due to Declare Parameter Change -""""""""""""""""""""""""""""""""""""""" - -For details about the actual behavior change, see `Declaring Parameters`_ above. - -There are several new API calls in the ``rclcpp::Node``'s interface: - -- Methods that declare parameters given a name, optional default value, optional descriptor, and return the value actually set: - - .. code-block:: c++ - - const rclcpp::ParameterValue & - rclcpp::Node::declare_parameter( - const std::string & name, - const rclcpp::ParameterValue & default_value = rclcpp::ParameterValue(), - const rcl_interfaces::msg::ParameterDescriptor & parameter_descriptor = - rcl_interfaces::msg::ParameterDescriptor()); - - template - auto - rclcpp::Node::declare_parameter( - const std::string & name, - const ParameterT & default_value, - const rcl_interfaces::msg::ParameterDescriptor & parameter_descriptor = - rcl_interfaces::msg::ParameterDescriptor()); - - template - std::vector - rclcpp::Node::declare_parameters( - const std::string & namespace_, - const std::map & parameters); - - template - std::vector - rclcpp::Node::declare_parameters( - const std::string & namespace_, - const std::map< - std::string, - std::pair - > & parameters); - -- A method to undeclare parameters and to check if a parameter has been declared: - - .. code-block:: c++ - - void - rclcpp::Node::undeclare_parameter(const std::string & name); - - bool - rclcpp::Node::has_parameter(const std::string & name) const; - -- Some convenience methods that did not previously exist: - - .. code-block:: c++ - - rcl_interfaces::msg::SetParametersResult - rclcpp::Node::set_parameter(const rclcpp::Parameter & parameter); - - std::vector - rclcpp::Node::get_parameters(const std::vector & names) const; - - rcl_interfaces::msg::ParameterDescriptor - rclcpp::Node::describe_parameter(const std::string & name) const; - -- A new method to set the callback which is called anytime a parameter will be changed, giving you the opportunity to reject it: - - .. code-block:: c++ - - using OnParametersSetCallbackType = - rclcpp::node_interfaces::NodeParametersInterface::OnParametersSetCallbackType; - - OnParametersSetCallbackType - rclcpp::Node::set_on_parameters_set_callback( - OnParametersSetCallbackType callback); - -There were also several deprecated methods: - - .. code-block:: c++ - - template - [[deprecated("use declare_parameter() instead")]] - void - rclcpp::Node::set_parameter_if_not_set( - const std::string & name, - const ParameterT & value); - - template - [[deprecated("use declare_parameters() instead")]] - void - rclcpp::Node::set_parameters_if_not_set( - const std::string & name, - const std::map & values); - - template - [[deprecated("use declare_parameter() and it's return value instead")]] - void - rclcpp::Node::get_parameter_or_set( - const std::string & name, - ParameterT & value, - const ParameterT & alternative_value); - - template - [[deprecated("use set_on_parameters_set_callback() instead")]] - void - rclcpp::Node::register_param_change_callback(CallbackT && callback); - -Memory Strategy -""""""""""""""" - -The interface ``rclcpp::memory_strategy::MemoryStrategy`` was using the typedef ``WeakNodeVector`` in various method signatures. -As of Dashing the typedef has been been changed to ``WeakNodeList`` and with it the type of the parameter in various methods. -Any custom memory strategy needs to be updated to match the modified interface. - -The relevant API change can be found in `ros2/rclcpp#741 `__. - -rclcpp_components -^^^^^^^^^^^^^^^^^ - -The correct way to implement composition in Dashing is by utilizing the ``rclcpp_components`` package. - -The following changes must be made to nodes in order to correctly implement runtime composition: - -The Node must have a constructor that takes ``rclcpp::NodeOptions``: - -.. code-block:: cpp - - class Listener: public rclcpp::Node { - Listener(const rclcpp::NodeOptions & options) - : Node("listener", options) - { - } - }; - -C++ registration macros (if present) need to be updated to use the ``rclcpp_components`` equivalent. -If not present, registration macros must be added in one translation unit. - -.. code-block:: cpp - - // Insert at bottom of translation unit, e.g. listener.cpp - #include "rclcpp_components/register_node_macro.hpp" - // Use fully-qualifed name in registration - RCLCPP_COMPONENTS_REGISTER_NODE(composition::Listener); - -CMake registration macros (if present) need to be updated. -If not present, registration macros must be added to the project's CMake. - -.. code-block:: cmake - - add_library(listener src/listener.cpp) - rclcpp_components_register_nodes(listener "composition::Listener") - -For more information on composition, see `the tutorial <../Tutorials/Intermediate/Writing-a-Composable-Node>` - -rclpy -^^^^^ - -Changes to Creating Publishers, Subscriptions, and QoS Profiles -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Prior to Dashing, you could optionally provide a ``QoSProfile`` object when creating a publisher or subscription. -In an effort to encourage users to specify a history depth for message queues, we now **require** that a depth value or ``QoSProfile`` object is given when creating publishers or subscriptions. - -To create a publisher, previously you would have written: - -.. code-block:: python - - node.create_publisher(Empty, 'chatter') - # Or using a keyword argument for QoSProfile - node.create_publisher(Empty, 'chatter', qos_profile=qos_profile_sensor_data) - -In Dashing, prefer the following API that provides a depth value or ``QoSProfile`` object as a third positional argument: - -.. code-block:: python - - # Assume a history setting of KEEP_LAST with depth 10 - node.create_publisher(Empty, 'chatter', 10) - # Or pass a QoSProfile object directly - node.create_publisher(Empty, 'chatter', qos_profile_sensor_data) - -Likewise for subscriptions, previously you would have written: - -.. code-block:: python - - node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg)) - # Or using a keyword argument for QoSProfile - node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg), qos_profile=qos_profile_sensor_data) - -In Dashing: - -.. code-block:: python - - # Assume a history setting of KEEP_LAST with depth 10 - node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg), 10) - # Or pass a QoSProfile object directly - node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg), qos_profile_sensor_data) - -To ease the transition, users who do not use the new API will see deprecation warnings. - -Furthermore, we also require that when constructing ``QoSProfile`` objects that a history policy and/or depth is set. -If a history policy of ``KEEP_LAST`` is provided, then a depth argument is also required. -For example, these calls are valid: - -.. code-block:: python - - QoSProfile(history=QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_ALL) - QoSProfile(history=QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_LAST, depth=10) - QoSProfile(depth=10) # equivalent to the previous line - -And these calls will cause a deprecation warning: - -.. code-block:: python - - QoSProfile() - QoSProfile(reliability=QoSReliabilityPolicy.RMW_QOS_POLICY_RELIABILITY_BEST_EFFORT) - # KEEP_LAST but no depth - QoSProfile(history=QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_LAST) - -See the issue and pull request related to introducing this change for more details: - -- https://github.com/ros2/rclpy/issues/342 -- https://github.com/ros2/rclpy/pull/344 - - -Changes Due to Declare Parameter Change -""""""""""""""""""""""""""""""""""""""" - -For details about the actual behavior change, see `Declaring Parameters`_ above. The changes are analogous to the ones in ``rclcpp``. - -These are the new API methods available in ``rclpy.node.Node`` interface: - -- To declare parameters given a name, an optional default value (supported by ``rcl_interfaces.msg.ParameterValue``) and an optional descriptor, returning the value actually set: - - .. code-block:: python - - def declare_parameter( - name: str, - value: Any = None, - descriptor: ParameterDescriptor = ParameterDescriptor() - ) -> Parameter - - def declare_parameters( - namespace: str, - parameters: List[Union[ - Tuple[str], - Tuple[str, Any], - Tuple[str, Any, ParameterDescriptor], - ]] - ) -> List[Parameter] - -- To undeclare previously declared parameters and to check if a parameter has been declared beforehand: - - .. code-block:: python - - def undeclare_parameter(name: str) -> None - - def has_parameter(name: str) -> bool - -- To get and set parameter descriptors: - - .. code-block:: python - - def describe_parameter(name: str) -> ParameterDescriptor - - def describe_parameters(names: List[str]) -> List[ParameterDescriptor] - - def set_descriptor( - name: str, - descriptor: ParameterDescriptor, - alternative_value: Optional[ParameterValue] = None - ) -> ParameterValue - -- A convenience method to get parameters that may not have been declared: - - .. code-block:: python - - def get_parameter_or(name: str, alternative_value: Optional[Parameter] = None) -> Parameter - -Other changes -""""""""""""" - -``rclpy.parameter.Parameter`` can now guess its type without explicitly setting it (as long as it's one of the supported ones by ``rcl_interfaces.msg.ParameterValue``). -For example, this code: - - .. code-block:: python - - p = Parameter('myparam', Parameter.Type.DOUBLE, 2.41) - -Is equivalent to this code: - - .. code-block:: python - - p = Parameter('myparam', value=2.41) - -This change does not break existing API. - -rosidl -^^^^^^ - -Until Crystal each message generator package registered itself using the ``ament_cmake`` extension point ``rosidl_generate_interfaces`` and was passed a set of ``.msg`` / ``.srv`` / ``.action`` files. -As of Dashing the message generation pipeline is based on ``.idl`` files instead. - -Any message generator package needs to change and register itself using the new extension point ``rosidl_generate_idl_interfaces`` which passes only ``.idl`` files instead. -The message generators for the commonly supported languages C, C++, and Python as well as the typesupport packages for introspection, Fast RTPS, Connext and OpenSplice have already been updated (see `ros2/rosidl#334 `__). -The CMake code calling ``rosidl_generate_interfaces()`` can either pass ``.idl`` files directly or pass ``.msg`` / ``.srv`` / ``.action`` which will then internally be converted into ``.idl`` files before being passed to each message generator. - -The format of ``.msg`` / ``.srv`` / ``.action`` files is not being evolved in the future. -The mapping between ``.msg`` / ``.srv`` / ``.action`` files and ``.idl`` files is described in `this design article `__. -A `second design article `__ describes the supported features in ``.idl`` files. -In order to leverage any of the new features existing interfaces need to be converted (e.g. using the command line tools ``msg2idl`` / ``srv2idl`` / ``action2idl``). - -To distinguish same type names, but with different namespaces, the introspection structs now contain a namespace field that replaces the package name (see `ros2/rosidl#335 `_). - -Mapping of char in .msg files -""""""""""""""""""""""""""""" - -In `ROS 1 `__ ``char`` has been deprecated for a long time and is being mapped to ``uint8``. -In ROS 2 until Crystal ``char`` was mapped to a single character (``char`` in C / C++, ``str`` with length 1 in Python) in an effort to provide a more natural mapping. -As of Dashing the ROS 1 semantic has been restored and ``char`` maps to ``uint8`` again. - -rosidl_generator_cpp -^^^^^^^^^^^^^^^^^^^^ - -The C++ data structures generated for messages, services and actions provide setter methods for each field. -Until Crystal each setter returned a pointer to the data structure itself to enable the named parameter idiom. -As of Dashing these setters `return a reference `__ instead since that seems to be the more common signature as well as it clarifies that the returned value can't be a ``nullptr``. - -rosidl_generator_py -^^^^^^^^^^^^^^^^^^^ - -Until Crystal an array (fixed size) or sequence (dynamic size, optionally with an upper boundary) field in a message was stored as a ``list`` in Python. -As of Dashing the Python type for arrays / sequences of numeric values has been changed: - -* an array of numeric values is stored as a ``numpy.ndarray`` (the ``dtype`` is chosen to match the type of the numeric value) -* a sequence of numeric values is stored as an ``array.array`` (the ``typename`` is chosen to match the type of the numeric value) - -As before an array / sequence of non-numeric types is still represented as a ``list`` in Python. - -This change brings a number of benefits: - -* The new data structures ensure that each item in the array / sequence complies with the value range restrictions of the numeric type. -* The numeric values can be stored more efficiently in memory which avoid the overhead of Python objects for each item. -* The memory layout of both data structures allows to read and write all items of the array / sequence in a single operation which makes the conversion from and to Python significantly faster / more efficient. - -launch -^^^^^^ - -The ``launch_testing`` package caught up with the ``launch`` package redesign done in Bouncy Bolson. -The legacy Python API, already moved into the ``launch.legacy`` submodule, has thus been deprecated and removed. - -See ``launch`` `examples `__ and `documentation `__ for reference on how to use its new API. - -See `demos tests `__ for reference on how to use the new ``launch_testing`` API. - -rmw -^^^ - -Changes since the `Crystal Clemmys ` release: - -* New API in ``rmw``, a fini function for ``rmw_context_t``: - - * `rmw_context_fini `_ - -* Modification of ``rmw``, now passes ``rmw_context_t`` to ``rmw_create_wait_set``: - - * `rmw_create_wait_set `_ - -* New APIs in ``rmw`` for preallocating space for published and subscribed messages: - - * `rmw_init_publisher_allocation `_ - * `rmw_fini_publisher_allocation `_ - * `rmw_init_subscription_allocation `_ - * `rmw_fini_subscription_allocation `_ - * `rmw_serialized_message_size `_ - -* Modification of ``rmw``, now passes ``rmw_publisher_allocation_t`` or ``rmw_subscription_allocation_t`` to ``rmw_publish`` and ``rmw_take``, respectively. - Note that this argument can be ``NULL`` or ``nullptr``, which keeps existing Crystal behavior. - - * `rmw_publish `_ - * `rmw_take `_ - -* Type names returned by ``rmw_get_*_names_and_types*`` functions should have a fully-qualified namespace. - For example, instead of ``rcl_interfaces/Parameter`` and ``rcl_interfaces/GetParameters``, the returned type names should be ``rcl_interface/msg/Parameter`` and ``rcl_interfaces/srv/GetParameters``. - -actions -^^^^^^^ - -* Changes to ``rclcpp_action::Client`` signatures: - - The signature of `rclcpp_action::Client::async_send_goal `_ has changed. - Now users can optionally provide callback functions for the **goal response** and the **result** using the new - `SendGoalOptions `_ struct. - The goal response callback is called when an action server accepts or rejects the goal and the result callback is called when the result for the goal is received. - Optional callbacks were also added to `rclcpp_action::Client::async_cancel_goal `_ - and `rclcpp_action::Client::async_get_result `_. - -* Changes to goal transition names: - - The names of goal state transitions have been refactored to reflect the design documention. - This affects ``rcl_action``, ``rclcpp_action``, and ``rclpy``. - Here is a list of the event name changes (*Old name -> New name*): - - * GOAL_EVENT_CANCEL -> GOAL_EVENT_CANCEL_GOAL - * GOAL_EVENT_SET_SUCCEEDED -> GOAL_EVENT_SUCCEED - * GOAL_EVENT_SET_ABORTED -> GOAL_EVENT_ABORT - * GOAL_EVENT_SET_CANCELED -> GOAL_EVENT_CANCELED - -* Changes to ``CancelGoal.srv``: - - A ``return_code`` field was added to the response message of the ``CancelGoal`` service. - This is to better communicate a reason for a failed service call. - See the `pull request `_ and connected issue for details. - -rviz -^^^^ - -* Plugins should use fully qualified type names otherwise a warning will be logged. - For `example `_, use the type ``sensor_msgs/msg/Image`` instead of ``sensor_msgs/Image``. - See `PR introducing this change `_ for more details. - -Known Issues ------------- - -* `[ros2/rclcpp#715] `_ There is an inconsistency in the way that parameter YAML files are loaded between standalone ROS 2 nodes and composed ROS 2 nodes. - Currently available workarounds are noted in an `issue comment `_ -* `[ros2/rclpy#360] `_ rclpy nodes ignore :kbd:`ctrl-c` when using OpenSplice on Windows. -* `[ros2/rosidl_typesupport_opensplice#30] `_ There is a bug preventing nesting a message inside of a service or action definition with the same name when using OpenSplice. -* `[ros2/rclcpp#781] `_ Calling ``get_parameter``/``list_parameter`` from within ``on_set_parameter_callback`` causes a deadlock on Dashing. This is fixed for Eloquent, but is an ABI break so has not been backported to Dashing. -* `[ros2/rclcpp#912] `_ Inter-process communication forces a message copy when intra-process communication takes place between an ``std::unique_ptr`` publisher and a single ``std::unique_ptr`` subscription (published ``std::unique_ptr`` is internally being promoted to an ``std::shared_ptr``). -* `[ros2/rosbag2#125] `_ Topics with unreliable QOS are not recorded. -* `[ros2/rclcpp#715] `_ Composable nodes cannot receive parameters via remapping. Supplying parameters to composable nodes can be accomplished using the methods described in `[this comment] `_. -* `[ros2/rclcpp#893] `_ ``rclcpp::Context`` is not destroyed because of a reference cycle with ``rclcpp::GraphListener``. This causes a memory leak. A fix has not been backported because of the risk of breaking ABI. - -Timeline before the release ---------------------------- - -A few milestones leading up to the release: - - Mon. Apr 8th (alpha) - First releases of core packages available. - Testing can happen from now on (some features might not have landed yet). - - Thu. May 2nd - API freeze for core packages - - Mon. May 6th (beta) - Updated releases of core packages available. - Additional testing of the latest features. - - Thu. May 16th - Feature freeze. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. May 20th (release candidate) - Updated releases of core packages available. - - Wed. May 29th - Freeze rosdistro. - No PRs for Dashing on the `rosdistro` repo will be merged (reopens after the release announcement). +.. redirect-from:: + + Releases/Release-Dashing-Diademata + +Dashing Diademata (``dashing``) +=============================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Dashing Diademata* is the fourth release of ROS 2. + +Supported Platforms +------------------- + +Dashing Diademata supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 18.04 (Bionic): ``amd64`` and ``arm64`` +* Mac macOS 10.12 (Sierra) +* Windows 10 (Visual Studio 2019) + +Tier 2 platforms: + +* Ubuntu 18.04 (Bionic): ``arm32`` + +Tier 3 platforms: + +* Debian Stretch (9): ``amd64``, ``arm64`` and ``arm32`` +* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` + +Targeted platforms: + ++--------------+----------------------+----------------------+--------------------+--------------------+----------------+ +| Architecture | Ubuntu Bionic | MacOS Sierra | Windows 10 | Debian Stretch | OpenEmbedded / | +| | (18.04) | (10.12) | (VS2019) | (9) | webOS OSE | ++==============+======================+======================+====================+====================+================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 3 [s] | | ++--------------+----------------------+----------------------+--------------------+--------------------+----------------+ +| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+----------------------+--------------------+--------------------+----------------+ +| arm32 | Tier 2 [a][s] | | | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+----------------------+--------------------+--------------------+----------------+ + + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Debian packages will be provided for this platform for +packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Dashing ROS 2 repos file[^6]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+---------------------+---------------+--------------------------+--------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=====================+===============+==========================+==========================+ +| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+--------------------------+--------------------------+ +| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except | All Architectures except | +| | | | Debian and OpenEmbedded | arm64/arm32 | ++--------------------------+---------------------+---------------+--------------------------+--------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 2 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+--------------------------+--------------------------+ +| rmw_opensplice_cpp | ADLink OpenSplice | Tier 2 | All Platforms except | All Architectures | +| | | | Debian and OpenEmbedded | | ++--------------------------+---------------------+---------------+--------------------------+--------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+--------------------------+--------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++14 +- Python 3.5 + +Dependency Requirements: + ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| | Required Support | Recommended Support | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Package | Ubuntu Bionic | MacOS** | Windows 10** | Debian Stretch | OpenEmbedded** | ++==============+=================+=================+=================+=================+=======================+ +| CMake | 3.10.2 | 3.14.4 | 3.14.4 | 3.7.2 | 3.16.1 / 3.12.2*** | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| EmPY | 3.3.2 | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Gazebo | 9.0.0 | 9.9.0 | N/A | 9.8.0* | N/A | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Ogre | 1.10* | N/A | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| OpenCV | 3.2.0 | 4.1.0 | 3.4.6* | 3.2* | 4.1.0 / 3.2.0*** | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| OpenSSL | 1.1.0g | 1.0.2r | 1.0.2r | 1.1.0j | 1.1.1d / 1.1.1b*** | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.8.0* | 1.9.4 | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Python | 3.6.5 | 3.7.3 | 3.7.3 | 3.5.3 | 3.8.2 / 3.7.5*** | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Qt | 5.9.5 | 5.12.3 | 5.10.0 | 5.7.1 | 5.14.1 / 5.12.5*** | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| | | **Linux only** | | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| PCL | 1.8.1 | N/A | N/A | 1.8.0 | 1.8.1 | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| **RMW DDS Middleware Providers** | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Connext DDS | 5.3.1 | N/A | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Cyclone DDS | 0.7.x (Coquette) | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| Fast-RTPS | 1.8.0 | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ +| OpenSplice | 6.9.190403OSS | N/A | ++--------------+-----------------+-----------------+-----------------+-----------------+-----------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. The versions shown for +OpenEmbedded are those provided by the 3.1 Dunfell release series; the +versions provided by the other supported release series are listed here: + . +Note that the OpenEmbedded releases series for which a ROS distro has +support will change during its support time frame, as per the +OpenEmbedded support policy shown here: + +. However, it will always be supported by least one stable OpenEmbedded +release series. + +\" \*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- MacOS: Homebrew, pip +- Windows: Chocolatey, pip +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Dashing Diademata <../../dashing/Installation.html>`__ + +New features in this ROS 2 release +---------------------------------- + +A few features and improvements we would like to highlight: + +* :doc:`Components <../../ROS-Framework/nodes/Working-with-nodes/Composition>` are now the recommended way to write your node. + They can be used standalone as well as being composed within a process and both ways are fully support from ``launch`` files. +* The :doc:`intra-process communication <../../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>` (C++ only) has been improved - both in terms of latency as well as minimizing copies. +* The Python client library has been updated to match most of the C++ equivalent and some important bug fixes and improvements have landed related to memory usage and performance. +* Parameters are now a complete alternative to ``dynamic_reconfigure`` from ROS 1 including constraints like ranges or being read-only. +* By relying on (a subset of) `IDL 4.2 `__ for the message generation pipeline it is now possible to use ``.idl`` files (beside ``.msg`` / ``.srv`` / ``.action`` files). + This change comes with support for optional UTF-8 encoding for ordinary strings as well as UTF-16 encoded multi-byte strings (see `wide strings design article `__). +* Command line tools related to ``actions`` and ``components``. +* Support for Deadline, Lifespan & Liveliness quality of service settings. +* MoveIt 2 `alpha release `__. + +Please see the `Dashing meta ticket `__ on GitHub, which contains more information as well as references to specific tickets with additional details. + + +Changes since the Crystal release +--------------------------------- + +Declaring Parameters +^^^^^^^^^^^^^^^^^^^^ + +There have been some changes to the behavior of parameters starting in Dashing, which have also lead to some new API's and the deprecation of other API's. +See the ``rclcpp`` and ``rclpy`` sections below for more information about API changes. + +Getting and Setting Undeclared Parameters +""""""""""""""""""""""""""""""""""""""""" + +As of Dashing, parameters now need to be declared before being accessed or set. + +Before Dashing, you could call ``get_parameter(name)`` and get either a value, if it had been previously set, or a parameter of type ``PARAMETER_NOT_SET``. +You could also call ``set_parameter(name, value)`` at any point, even if the parameter was previously unset. + +Since Dashing, you need to first declare a parameter before getting or setting it. +If you try to get or set an undeclared parameter you will either get an exception thrown, e.g. ParameterNotDeclaredException, or in certain cases you will get an unsuccessful result communicated in a variety of ways (see specific functions for more details). + +However, you can get the old behavior (mostly, see the note in the next paragraph) by using the ``allow_undeclared_parameters`` option when creating your node. +You might want to do this in order to avoid code changes for now, or in order to fulfill some uncommon use cases. +For example, a "global parameter server" or "parameter blackboard" may want to allow external nodes to set new parameters on itself without first declaring them, so it may use the ``allow_undeclared_parameters`` option to accomplish that. +In most cases, however, this option is not recommended because it makes the rest of the parameter API less safe to bugs like parameter name typos and "use before set" logical errors. + +Note that using ``allow_undeclared_parameters`` will get you most of the old behavior specifically for "get" and "set" methods, but it will not revert all the behavior changes related to parameters back to how it was for ROS Crystal. +For that you need to also set the ``automatically_declare_parameters_from_overrides`` option to ``true``, which is described below in :ref:`Parameter Configuration using a YAML File `. + +Declaring a Parameter with a ParameterDescriptor +"""""""""""""""""""""""""""""""""""""""""""""""" + +Another benefit to declaring your parameters before using them, is that it allows you to declare a parameter descriptor at the same time. + +Now when declaring a parameter you may include a custom ``ParameterDescriptor`` as well as a name and default value. +The ``ParameterDescriptor`` is defined as a message in ``rcl_interfaces/msg/ParameterDescriptor`` and contains meta data like ``description`` and constraints like ``read_only`` or ``integer_range``. +These constraints can be used to reject invalid values when setting parameters and/or as hints to external tools about what values are valid for a given parameter. +The ``read_only`` constraint will prevent the parameter's value from changing after being declared, as well as prevent if from being undeclared. + +For reference, here's a link to the ``ParameterDescriptor`` message as of the time of writing this: + +https://github.com/ros2/rcl_interfaces/blob/0aba5a142878c2077d7a03977087e7d74d40ee68/rcl_interfaces/msg/ParameterDescriptor.msg#L1 + +.. _parameter-configuration-using-a-yaml-file: + +Parameter Configuration using a YAML File +""""""""""""""""""""""""""""""""""""""""" + +As of Dashing, parameters in a YAML configuration file, e.g. passed to the node via the command line argument ``__params:=``, are only used to override a parameter's default value when declaring the parameter. + +Before Dashing, any parameters you passed via a YAML file would be implicitly set on the node. + +Since Dashing, this is no longer the case, as parameters need to be declared in order to appear on the node to external observers, like ``ros2 param list``. + +The old behavior may be achieved using the ``automatically_declare_parameters_from_overrides`` option when creating a node. +This option, if set to ``true``, will automatically declare all parameters in the input YAML file when the node is constructed. +This may be used to avoid major changes to your existing code or to serve specific use cases. +For example, a "global parameter server" may want to be seeded with arbitrary parameters on launch, which it could not have declared ahead of time. +Most of the time, however, this option is not recommended, as it may lead to setting a parameter in a YAML file with the assumption that the node will use it, even if the node does not actually use it. + +In the future we hope to have a checker that will warn you if you pass a parameter to a node that it was not expecting. + +The parameters in the YAML file will continue to influence the value of parameters when they are first declared. + +ament_cmake +^^^^^^^^^^^ + +The CMake function ``ament_index_has_resource`` was returning either ``TRUE`` or ``FALSE``. +As of `this release `_ it returns either the prefix path in case the resource was found or ``FALSE``. + +If you are using the return value in a CMake condition like this: + +.. code-block:: cmake + + ament_index_has_resource(var ...) + if(${var}) + +you need to update the condition to ensure it considers a string value as ``TRUE``: + +.. code-block:: cmake + + if(var) + +rclcpp +^^^^^^ + +Behavior Change for ``Node::get_node_names()`` +"""""""""""""""""""""""""""""""""""""""""""""" + +The function ``NodeGraph::get_node_names()``, and therefore also ``Node::get_node_names()``, now returns a ``std::vector`` containing fully qualified node names with their namespaces included, instead of just the node names. + +Changed the Way that Options are Passed to Nodes +"""""""""""""""""""""""""""""""""""""""""""""""" + +Extended arguments (beyond name and namespace) to the ``rclcpp::Node()`` constructor have been replaced with a ``rclcpp::NodeOptions`` structure. +See `ros2/rclcpp#622 `__ for details about the structure and default values of the options. + +If you are using any of the extended arguments to ``rclcpp::Node()`` like this: + +.. code-block:: cpp + + auto context = rclcpp::contexts::default_context::get_global_default_context(); + std::vector args; + std::vector params = { rclcpp::Parameter("use_sim_time", true) }; + auto node = std::make_shared("foo_node", "bar_namespace", context, args, params); + +You need to update to use the ``NodeOptions`` structure + +.. code-block:: cpp + + std::vector args; + std::vector params = { rclcpp::Parameter("use_sim_time", true) }; + rclcpp::NodeOptions node_options; + node_options.arguments(args); + node_options.parameter_overrides(params); + auto node = std::make_shared("foo_node", "bar_namespace", node_options); + +Changes to Creating Publishers and Subscriptions +"""""""""""""""""""""""""""""""""""""""""""""""" + +There have been a few changes to creating publishers and subscriptions which are new in Dashing: + +- QoS settings are now passed using the new ``rclcpp::QoS`` class, and the API encourages the user to specify at least the history depth. +- Options are now passed as an object, i.e. ``rclcpp::PublisherOptions`` and ``rclcpp::SubscriptionOptions``. + +All changes are backwards compatible (no code changes are required), but several existing call styles have been deprecated. +Users are encouraged to update to the new signatures. + +---- + +In the past, when creating a publisher or subscription, you could either not specify any QoS settings (e.g. just provide topic name for a publisher) or you could specify a "qos profile" data structure (of type ``rmw_qos_profile_t``) with all the settings already set. +Now you must use the new ``rclcpp::QoS`` object to specify your QoS and at least the history settings for your QoS. +This encourages the user to specify a history depth when using ``KEEP_LAST``, rather than defaulting it to a value that may or may not be appropriate. + +In ROS 1, this was known as the ``queue_size`` and it was required in both C++ and Python. +We're changing the ROS 2 API to bring this requirement back. + +---- + +Also, any options which could previously be passed during creation of a publisher or subscription have now been encapsulated in an ``rclcpp::PublisherOptions`` and ``rclcpp::SubscriptionOptions`` class respectively. +This allows for shorter signatures, more convenient use, and for adding new future options without breaking API. + +---- + +Some signatures for creating publishers and subscribers are now deprecated, and new signatures have been added to allow you to use the new ``rclcpp::QoS`` and publisher/subscription option classes. + +These are the new and recommended API's: + +.. code-block:: cpp + + template< + typename MessageT, + typename AllocatorT = std::allocator, + typename PublisherT = ::rclcpp::Publisher> + std::shared_ptr + create_publisher( + const std::string & topic_name, + const rclcpp::QoS & qos, + const PublisherOptionsWithAllocator & options = + PublisherOptionsWithAllocator() + ); + + template< + typename MessageT, + typename CallbackT, + typename AllocatorT = std::allocator, + typename SubscriptionT = rclcpp::Subscription< + typename rclcpp::subscription_traits::has_message_type::type, AllocatorT>> + std::shared_ptr + create_subscription( + const std::string & topic_name, + const rclcpp::QoS & qos, + CallbackT && callback, + const SubscriptionOptionsWithAllocator & options = + SubscriptionOptionsWithAllocator(), + typename rclcpp::message_memory_strategy::MessageMemoryStrategy< + typename rclcpp::subscription_traits::has_message_type::type, AllocatorT + >::SharedPtr + msg_mem_strat = nullptr); + +And these are the deprecated ones: + +.. code-block:: cpp + + template< + typename MessageT, + typename AllocatorT = std::allocator, + typename PublisherT = ::rclcpp::Publisher> + [[deprecated("use create_publisher(const std::string &, const rclcpp::QoS &, ...) instead")]] + std::shared_ptr + create_publisher( + const std::string & topic_name, + size_t qos_history_depth, + std::shared_ptr allocator); + + template< + typename MessageT, + typename AllocatorT = std::allocator, + typename PublisherT = ::rclcpp::Publisher> + [[deprecated("use create_publisher(const std::string &, const rclcpp::QoS &, ...) instead")]] + std::shared_ptr + create_publisher( + const std::string & topic_name, + const rmw_qos_profile_t & qos_profile = rmw_qos_profile_default, + std::shared_ptr allocator = nullptr); + + template< + typename MessageT, + typename CallbackT, + typename Alloc = std::allocator, + typename SubscriptionT = rclcpp::Subscription< + typename rclcpp::subscription_traits::has_message_type::type, Alloc>> + [[deprecated( + "use create_subscription(const std::string &, const rclcpp::QoS &, CallbackT, ...) instead" + )]] + std::shared_ptr + create_subscription( + const std::string & topic_name, + CallbackT && callback, + const rmw_qos_profile_t & qos_profile = rmw_qos_profile_default, + rclcpp::callback_group::CallbackGroup::SharedPtr group = nullptr, + bool ignore_local_publications = false, + typename rclcpp::message_memory_strategy::MessageMemoryStrategy< + typename rclcpp::subscription_traits::has_message_type::type, Alloc>::SharedPtr + msg_mem_strat = nullptr, + std::shared_ptr allocator = nullptr); + + template< + typename MessageT, + typename CallbackT, + typename Alloc = std::allocator, + typename SubscriptionT = rclcpp::Subscription< + typename rclcpp::subscription_traits::has_message_type::type, Alloc>> + [[deprecated( + "use create_subscription(const std::string &, const rclcpp::QoS &, CallbackT, ...) instead" + )]] + std::shared_ptr + create_subscription( + const std::string & topic_name, + CallbackT && callback, + size_t qos_history_depth, + rclcpp::callback_group::CallbackGroup::SharedPtr group = nullptr, + bool ignore_local_publications = false, + typename rclcpp::message_memory_strategy::MessageMemoryStrategy< + typename rclcpp::subscription_traits::has_message_type::type, Alloc>::SharedPtr + msg_mem_strat = nullptr, + std::shared_ptr allocator = nullptr); + +---- + +The change to how QoS is passed is most likely to impact users. + +A typical change for a publisher looks like this: + +.. code-block:: diff + + - pub_ = create_publisher("chatter"); + + pub_ = create_publisher("chatter", 10); + +And for a subscription: + +.. code-block:: diff + + - sub_ = create_subscription("chatter", callback); + + sub_ = create_subscription("chatter", 10, callback); + +If you have no idea what depth to use and don't care right now (maybe just prototyping), then we recommend using ``10``, as that was the default before and should preserve existing behavior. + +More in depth documentation about how to select an appropriate depth is forthcoming. + +This is an example of a slightly more involved change to avoid the newly deprecated API's: + +.. code-block:: diff + + - // Creates a latched topic + - rmw_qos_profile_t qos = rmw_qos_profile_default; + - qos.depth = 1; + - qos.durability = RMW_QOS_POLICY_DURABILITY_TRANSIENT_LOCAL; + - + model_xml_.data = model_xml; + node_handle->declare_parameter("robot_description", model_xml); + description_pub_ = node_handle->create_publisher( + - "robot_description", qos); + + "robot_description", + + // Transient local is similar to latching in ROS 1. + + rclcpp::QoS(1).transient_local()); + +See the pull request (and connected pull requests) that introduced the QoS change for more examples and details: + +- https://github.com/ros2/rclcpp/pull/713 + + - https://github.com/ros2/demos/pull/332 + - https://github.com/ros2/robot_state_publisher/pull/19 + - and others... + + +Changes Due to Declare Parameter Change +""""""""""""""""""""""""""""""""""""""" + +For details about the actual behavior change, see `Declaring Parameters`_ above. + +There are several new API calls in the ``rclcpp::Node``'s interface: + +- Methods that declare parameters given a name, optional default value, optional descriptor, and return the value actually set: + + .. code-block:: c++ + + const rclcpp::ParameterValue & + rclcpp::Node::declare_parameter( + const std::string & name, + const rclcpp::ParameterValue & default_value = rclcpp::ParameterValue(), + const rcl_interfaces::msg::ParameterDescriptor & parameter_descriptor = + rcl_interfaces::msg::ParameterDescriptor()); + + template + auto + rclcpp::Node::declare_parameter( + const std::string & name, + const ParameterT & default_value, + const rcl_interfaces::msg::ParameterDescriptor & parameter_descriptor = + rcl_interfaces::msg::ParameterDescriptor()); + + template + std::vector + rclcpp::Node::declare_parameters( + const std::string & namespace_, + const std::map & parameters); + + template + std::vector + rclcpp::Node::declare_parameters( + const std::string & namespace_, + const std::map< + std::string, + std::pair + > & parameters); + +- A method to undeclare parameters and to check if a parameter has been declared: + + .. code-block:: c++ + + void + rclcpp::Node::undeclare_parameter(const std::string & name); + + bool + rclcpp::Node::has_parameter(const std::string & name) const; + +- Some convenience methods that did not previously exist: + + .. code-block:: c++ + + rcl_interfaces::msg::SetParametersResult + rclcpp::Node::set_parameter(const rclcpp::Parameter & parameter); + + std::vector + rclcpp::Node::get_parameters(const std::vector & names) const; + + rcl_interfaces::msg::ParameterDescriptor + rclcpp::Node::describe_parameter(const std::string & name) const; + +- A new method to set the callback which is called anytime a parameter will be changed, giving you the opportunity to reject it: + + .. code-block:: c++ + + using OnParametersSetCallbackType = + rclcpp::node_interfaces::NodeParametersInterface::OnParametersSetCallbackType; + + OnParametersSetCallbackType + rclcpp::Node::set_on_parameters_set_callback( + OnParametersSetCallbackType callback); + +There were also several deprecated methods: + + .. code-block:: c++ + + template + [[deprecated("use declare_parameter() instead")]] + void + rclcpp::Node::set_parameter_if_not_set( + const std::string & name, + const ParameterT & value); + + template + [[deprecated("use declare_parameters() instead")]] + void + rclcpp::Node::set_parameters_if_not_set( + const std::string & name, + const std::map & values); + + template + [[deprecated("use declare_parameter() and it's return value instead")]] + void + rclcpp::Node::get_parameter_or_set( + const std::string & name, + ParameterT & value, + const ParameterT & alternative_value); + + template + [[deprecated("use set_on_parameters_set_callback() instead")]] + void + rclcpp::Node::register_param_change_callback(CallbackT && callback); + +Memory Strategy +""""""""""""""" + +The interface ``rclcpp::memory_strategy::MemoryStrategy`` was using the typedef ``WeakNodeVector`` in various method signatures. +As of Dashing the typedef has been been changed to ``WeakNodeList`` and with it the type of the parameter in various methods. +Any custom memory strategy needs to be updated to match the modified interface. + +The relevant API change can be found in `ros2/rclcpp#741 `__. + +rclcpp_components +^^^^^^^^^^^^^^^^^ + +The correct way to implement composition in Dashing is by utilizing the ``rclcpp_components`` package. + +The following changes must be made to nodes in order to correctly implement runtime composition: + +The Node must have a constructor that takes ``rclcpp::NodeOptions``: + +.. code-block:: cpp + + class Listener: public rclcpp::Node { + Listener(const rclcpp::NodeOptions & options) + : Node("listener", options) + { + } + }; + +C++ registration macros (if present) need to be updated to use the ``rclcpp_components`` equivalent. +If not present, registration macros must be added in one translation unit. + +.. code-block:: cpp + + // Insert at bottom of translation unit, e.g. listener.cpp + #include "rclcpp_components/register_node_macro.hpp" + // Use fully-qualifed name in registration + RCLCPP_COMPONENTS_REGISTER_NODE(composition::Listener); + +CMake registration macros (if present) need to be updated. +If not present, registration macros must be added to the project's CMake. + +.. code-block:: cmake + + add_library(listener src/listener.cpp) + rclcpp_components_register_nodes(listener "composition::Listener") + +For more information on composition, see `the tutorial <../Tutorials/Intermediate/Writing-a-Composable-Node>` + +rclpy +^^^^^ + +Changes to Creating Publishers, Subscriptions, and QoS Profiles +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Prior to Dashing, you could optionally provide a ``QoSProfile`` object when creating a publisher or subscription. +In an effort to encourage users to specify a history depth for message queues, we now **require** that a depth value or ``QoSProfile`` object is given when creating publishers or subscriptions. + +To create a publisher, previously you would have written: + +.. code-block:: python + + node.create_publisher(Empty, 'chatter') + # Or using a keyword argument for QoSProfile + node.create_publisher(Empty, 'chatter', qos_profile=qos_profile_sensor_data) + +In Dashing, prefer the following API that provides a depth value or ``QoSProfile`` object as a third positional argument: + +.. code-block:: python + + # Assume a history setting of KEEP_LAST with depth 10 + node.create_publisher(Empty, 'chatter', 10) + # Or pass a QoSProfile object directly + node.create_publisher(Empty, 'chatter', qos_profile_sensor_data) + +Likewise for subscriptions, previously you would have written: + +.. code-block:: python + + node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg)) + # Or using a keyword argument for QoSProfile + node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg), qos_profile=qos_profile_sensor_data) + +In Dashing: + +.. code-block:: python + + # Assume a history setting of KEEP_LAST with depth 10 + node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg), 10) + # Or pass a QoSProfile object directly + node.create_subscription(BasicTypes, 'chatter', lambda msg: print(msg), qos_profile_sensor_data) + +To ease the transition, users who do not use the new API will see deprecation warnings. + +Furthermore, we also require that when constructing ``QoSProfile`` objects that a history policy and/or depth is set. +If a history policy of ``KEEP_LAST`` is provided, then a depth argument is also required. +For example, these calls are valid: + +.. code-block:: python + + QoSProfile(history=QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_ALL) + QoSProfile(history=QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_LAST, depth=10) + QoSProfile(depth=10) # equivalent to the previous line + +And these calls will cause a deprecation warning: + +.. code-block:: python + + QoSProfile() + QoSProfile(reliability=QoSReliabilityPolicy.RMW_QOS_POLICY_RELIABILITY_BEST_EFFORT) + # KEEP_LAST but no depth + QoSProfile(history=QoSHistoryPolicy.RMW_QOS_POLICY_HISTORY_KEEP_LAST) + +See the issue and pull request related to introducing this change for more details: + +- https://github.com/ros2/rclpy/issues/342 +- https://github.com/ros2/rclpy/pull/344 + + +Changes Due to Declare Parameter Change +""""""""""""""""""""""""""""""""""""""" + +For details about the actual behavior change, see `Declaring Parameters`_ above. The changes are analogous to the ones in ``rclcpp``. + +These are the new API methods available in ``rclpy.node.Node`` interface: + +- To declare parameters given a name, an optional default value (supported by ``rcl_interfaces.msg.ParameterValue``) and an optional descriptor, returning the value actually set: + + .. code-block:: python + + def declare_parameter( + name: str, + value: Any = None, + descriptor: ParameterDescriptor = ParameterDescriptor() + ) -> Parameter + + def declare_parameters( + namespace: str, + parameters: List[Union[ + Tuple[str], + Tuple[str, Any], + Tuple[str, Any, ParameterDescriptor], + ]] + ) -> List[Parameter] + +- To undeclare previously declared parameters and to check if a parameter has been declared beforehand: + + .. code-block:: python + + def undeclare_parameter(name: str) -> None + + def has_parameter(name: str) -> bool + +- To get and set parameter descriptors: + + .. code-block:: python + + def describe_parameter(name: str) -> ParameterDescriptor + + def describe_parameters(names: List[str]) -> List[ParameterDescriptor] + + def set_descriptor( + name: str, + descriptor: ParameterDescriptor, + alternative_value: Optional[ParameterValue] = None + ) -> ParameterValue + +- A convenience method to get parameters that may not have been declared: + + .. code-block:: python + + def get_parameter_or(name: str, alternative_value: Optional[Parameter] = None) -> Parameter + +Other changes +""""""""""""" + +``rclpy.parameter.Parameter`` can now guess its type without explicitly setting it (as long as it's one of the supported ones by ``rcl_interfaces.msg.ParameterValue``). +For example, this code: + + .. code-block:: python + + p = Parameter('myparam', Parameter.Type.DOUBLE, 2.41) + +Is equivalent to this code: + + .. code-block:: python + + p = Parameter('myparam', value=2.41) + +This change does not break existing API. + +rosidl +^^^^^^ + +Until Crystal each message generator package registered itself using the ``ament_cmake`` extension point ``rosidl_generate_interfaces`` and was passed a set of ``.msg`` / ``.srv`` / ``.action`` files. +As of Dashing the message generation pipeline is based on ``.idl`` files instead. + +Any message generator package needs to change and register itself using the new extension point ``rosidl_generate_idl_interfaces`` which passes only ``.idl`` files instead. +The message generators for the commonly supported languages C, C++, and Python as well as the typesupport packages for introspection, Fast RTPS, Connext and OpenSplice have already been updated (see `ros2/rosidl#334 `__). +The CMake code calling ``rosidl_generate_interfaces()`` can either pass ``.idl`` files directly or pass ``.msg`` / ``.srv`` / ``.action`` which will then internally be converted into ``.idl`` files before being passed to each message generator. + +The format of ``.msg`` / ``.srv`` / ``.action`` files is not being evolved in the future. +The mapping between ``.msg`` / ``.srv`` / ``.action`` files and ``.idl`` files is described in `this design article `__. +A `second design article `__ describes the supported features in ``.idl`` files. +In order to leverage any of the new features existing interfaces need to be converted (e.g. using the command line tools ``msg2idl`` / ``srv2idl`` / ``action2idl``). + +To distinguish same type names, but with different namespaces, the introspection structs now contain a namespace field that replaces the package name (see `ros2/rosidl#335 `_). + +Mapping of char in .msg files +""""""""""""""""""""""""""""" + +In `ROS 1 `__ ``char`` has been deprecated for a long time and is being mapped to ``uint8``. +In ROS 2 until Crystal ``char`` was mapped to a single character (``char`` in C / C++, ``str`` with length 1 in Python) in an effort to provide a more natural mapping. +As of Dashing the ROS 1 semantic has been restored and ``char`` maps to ``uint8`` again. + +rosidl_generator_cpp +^^^^^^^^^^^^^^^^^^^^ + +The C++ data structures generated for messages, services and actions provide setter methods for each field. +Until Crystal each setter returned a pointer to the data structure itself to enable the named parameter idiom. +As of Dashing these setters `return a reference `__ instead since that seems to be the more common signature as well as it clarifies that the returned value can't be a ``nullptr``. + +rosidl_generator_py +^^^^^^^^^^^^^^^^^^^ + +Until Crystal an array (fixed size) or sequence (dynamic size, optionally with an upper boundary) field in a message was stored as a ``list`` in Python. +As of Dashing the Python type for arrays / sequences of numeric values has been changed: + +* an array of numeric values is stored as a ``numpy.ndarray`` (the ``dtype`` is chosen to match the type of the numeric value) +* a sequence of numeric values is stored as an ``array.array`` (the ``typename`` is chosen to match the type of the numeric value) + +As before an array / sequence of non-numeric types is still represented as a ``list`` in Python. + +This change brings a number of benefits: + +* The new data structures ensure that each item in the array / sequence complies with the value range restrictions of the numeric type. +* The numeric values can be stored more efficiently in memory which avoid the overhead of Python objects for each item. +* The memory layout of both data structures allows to read and write all items of the array / sequence in a single operation which makes the conversion from and to Python significantly faster / more efficient. + +launch +^^^^^^ + +The ``launch_testing`` package caught up with the ``launch`` package redesign done in Bouncy Bolson. +The legacy Python API, already moved into the ``launch.legacy`` submodule, has thus been deprecated and removed. + +See ``launch`` `examples `__ and `documentation `__ for reference on how to use its new API. + +See `demos tests `__ for reference on how to use the new ``launch_testing`` API. + +rmw +^^^ + +Changes since the `Crystal Clemmys ` release: + +* New API in ``rmw``, a fini function for ``rmw_context_t``: + + * `rmw_context_fini `_ + +* Modification of ``rmw``, now passes ``rmw_context_t`` to ``rmw_create_wait_set``: + + * `rmw_create_wait_set `_ + +* New APIs in ``rmw`` for preallocating space for published and subscribed messages: + + * `rmw_init_publisher_allocation `_ + * `rmw_fini_publisher_allocation `_ + * `rmw_init_subscription_allocation `_ + * `rmw_fini_subscription_allocation `_ + * `rmw_serialized_message_size `_ + +* Modification of ``rmw``, now passes ``rmw_publisher_allocation_t`` or ``rmw_subscription_allocation_t`` to ``rmw_publish`` and ``rmw_take``, respectively. + Note that this argument can be ``NULL`` or ``nullptr``, which keeps existing Crystal behavior. + + * `rmw_publish `_ + * `rmw_take `_ + +* Type names returned by ``rmw_get_*_names_and_types*`` functions should have a fully-qualified namespace. + For example, instead of ``rcl_interfaces/Parameter`` and ``rcl_interfaces/GetParameters``, the returned type names should be ``rcl_interface/msg/Parameter`` and ``rcl_interfaces/srv/GetParameters``. + +actions +^^^^^^^ + +* Changes to ``rclcpp_action::Client`` signatures: + + The signature of `rclcpp_action::Client::async_send_goal `_ has changed. + Now users can optionally provide callback functions for the **goal response** and the **result** using the new + `SendGoalOptions `_ struct. + The goal response callback is called when an action server accepts or rejects the goal and the result callback is called when the result for the goal is received. + Optional callbacks were also added to `rclcpp_action::Client::async_cancel_goal `_ + and `rclcpp_action::Client::async_get_result `_. + +* Changes to goal transition names: + + The names of goal state transitions have been refactored to reflect the design documention. + This affects ``rcl_action``, ``rclcpp_action``, and ``rclpy``. + Here is a list of the event name changes (*Old name -> New name*): + + * GOAL_EVENT_CANCEL -> GOAL_EVENT_CANCEL_GOAL + * GOAL_EVENT_SET_SUCCEEDED -> GOAL_EVENT_SUCCEED + * GOAL_EVENT_SET_ABORTED -> GOAL_EVENT_ABORT + * GOAL_EVENT_SET_CANCELED -> GOAL_EVENT_CANCELED + +* Changes to ``CancelGoal.srv``: + + A ``return_code`` field was added to the response message of the ``CancelGoal`` service. + This is to better communicate a reason for a failed service call. + See the `pull request `_ and connected issue for details. + +rviz +^^^^ + +* Plugins should use fully qualified type names otherwise a warning will be logged. + For `example `_, use the type ``sensor_msgs/msg/Image`` instead of ``sensor_msgs/Image``. + See `PR introducing this change `_ for more details. + +Known Issues +------------ + +* `[ros2/rclcpp#715] `_ There is an inconsistency in the way that parameter YAML files are loaded between standalone ROS 2 nodes and composed ROS 2 nodes. + Currently available workarounds are noted in an `issue comment `_ +* `[ros2/rclpy#360] `_ rclpy nodes ignore :kbd:`ctrl-c` when using OpenSplice on Windows. +* `[ros2/rosidl_typesupport_opensplice#30] `_ There is a bug preventing nesting a message inside of a service or action definition with the same name when using OpenSplice. +* `[ros2/rclcpp#781] `_ Calling ``get_parameter``/``list_parameter`` from within ``on_set_parameter_callback`` causes a deadlock on Dashing. This is fixed for Eloquent, but is an ABI break so has not been backported to Dashing. +* `[ros2/rclcpp#912] `_ Inter-process communication forces a message copy when intra-process communication takes place between an ``std::unique_ptr`` publisher and a single ``std::unique_ptr`` subscription (published ``std::unique_ptr`` is internally being promoted to an ``std::shared_ptr``). +* `[ros2/rosbag2#125] `_ Topics with unreliable QOS are not recorded. +* `[ros2/rclcpp#715] `_ Composable nodes cannot receive parameters via remapping. Supplying parameters to composable nodes can be accomplished using the methods described in `[this comment] `_. +* `[ros2/rclcpp#893] `_ ``rclcpp::Context`` is not destroyed because of a reference cycle with ``rclcpp::GraphListener``. This causes a memory leak. A fix has not been backported because of the risk of breaking ABI. + +Timeline before the release +--------------------------- + +A few milestones leading up to the release: + + Mon. Apr 8th (alpha) + First releases of core packages available. + Testing can happen from now on (some features might not have landed yet). + + Thu. May 2nd + API freeze for core packages + + Mon. May 6th (beta) + Updated releases of core packages available. + Additional testing of the latest features. + + Thu. May 16th + Feature freeze. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. May 20th (release candidate) + Updated releases of core packages available. + + Wed. May 29th + Freeze rosdistro. + No PRs for Dashing on the `rosdistro` repo will be merged (reopens after the release announcement). \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Eloquent-Elusor.rst b/source/Get-Started/Releases/Release-Eloquent-Elusor.rst index c22101e8699..0d0a85e0b51 100644 --- a/source/Get-Started/Releases/Release-Eloquent-Elusor.rst +++ b/source/Get-Started/Releases/Release-Eloquent-Elusor.rst @@ -1,390 +1,394 @@ -Eloquent Elusor (``eloquent``) -============================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Eloquent Elusor* is the fifth release of ROS 2. - -Supported Platforms -------------------- - -Eloquent Elusor supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 18.04 (Bionic): ``amd64`` and ``arm64`` -* Mac macOS 10.14 (Mojave) -* Windows 10 (Visual Studio 2019) - -Tier 2 platforms: - -* Ubuntu 18.04 (Bionic): ``arm32`` - -Tier 3 platforms: - -* Debian Stretch (9): ``amd64``, ``arm64`` and ``arm32`` -* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` - -Targeted platforms: - -+--------------+----------------------+----------------------+----------------------+-------------------+----------------+ -| Architecture | Ubuntu Bionic (18.04)| MacOS Mojave (10.14) | Windows 10 (VS2019) | Debian Buster (10)| OpenEmbedded / | -| | | | | | webOS OSE | -+==============+======================+======================+======================+===================+================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 3 [s] | | -+--------------+----------------------+----------------------+----------------------+-------------------+----------------+ -| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+----------------------+----------------------+-------------------+----------------+ -| arm32 | Tier 2 [a][s] | | | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+----------------------+----------------------+-------------------+----------------+ - - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Debian packages will be provided for this platform for -packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Eloquent ROS 2 repos file[^7]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=====================+===============+===================================+===================================+ -| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ -| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except Debian and | All Architectures except | -| | | | OpenEmbedded | arm64/arm32 | -+--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 2 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ -| rmw_opensplice_cpp | ADLINK OpenSplice | Tier 2 | All Platforms except Debian and | All Architectures | -| | | | OpenEmbedded | | -+--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | -+--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++14 -- Python 3.6 - -Dependency Requirements: - -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| | Required Support | Recommended Support | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Package | Ubuntu Bionic | MacOS** | Windows 10** | Debian Buster | OpenEmbedded** | -+==============+===================+================+================+================+=======================+ -| CMake | 3.10.2 | 3.14.4 | 3.14.4 | 3.13.4 | 3.16.1 / 3.12.2**** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| EmPY | 3.3.2 | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Gazebo | 9.0.0 | 9.9.0 | N/A | 9.8.0* | N/A | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Ogre | 1.10* | N/A | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| OpenCV | 3.2.0 | 4.1.0 | 3.4.6* | 3.2.0 | 4.1.0 / 3.2.0**** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| OpenSSL | 1.1.0g | 1.0.2r | 1.0.2r | 1.1.1c | 1.1.1d / 1.1.1b**** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.9.0 | 1.9.4 | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Python | 3.6.5 | 3.7.3 | 3.7.3 | 3.7.3 | 3.8.2 / 3.7.5**** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Qt | 5.9.5 | 5.12.3 | 5.10.0 | 5.11.3 | 5.14.1 / 5.12.5**** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| | **Linux only** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| PCL | 1.8.1 | N/A | N/A | 1.9.1 | 1.8.1 | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| **RMW DDS Middleware Providers** | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Connext DDS | 5.3.1*** | N/A | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Cyclone DDS | 0.7.x (Coquette) | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| Fast-RTPS | 1.9.0 | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ -| OpenSplice | 6.9.190705OSS | N/A | -+--------------+-------------------+----------------+----------------+----------------+-----------------------+ - - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. The versions shown for -OpenEmbedded are those provided by the 3.1 Dunfell release series; the -versions provided by the other supported release series are listed here: - . -Note that the OpenEmbedded releases series for which a ROS distro has -support will change during its support time frame, as per the -OpenEmbedded support policy shown here: - -. However, it will always be supported by least one stable OpenEmbedded -release series. - -\" \*\*\* \" It is anticipated that this will be increased to Connext -DDS 6.0.0 pending migration patches[^8]. - -\" \*\*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- MacOS: Homebrew, pip -- Windows: Chocolatey, pip -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Eloquent Elusor <../../eloquent/Installation.html>`__ - -New features in this ROS 2 release ----------------------------------- - -A few features and improvements we would like to highlight: - -* `Support for markup-based launch files (XML/YAML) `__ -* `Improved launch-based testing `__ -* `Passing key-value parameters on CLI `__ -* `Support stream logging macros `__ -* `Per-node logging `__ - All stdout/stderr output from nodes are logged in ~/.ros -* `ros2doctor `__ -* `Improved performance of sourcing setup files `__ -* rviz: `interactive markers `__, `torque ring `__, `tf message filters `__ -* rqt: `parameter plugin `__, `tf tree plugin `__, `robot steering plugin `__ (also backported to Dashing) -* `turtlesim `__ (also backported to Dashing) -* RMW implementations: - - * `API to loan message for zero copy `__, used by `rmw_iceoryx `__ - * `Fast RTPS 1.9.3 `__ - * New Tier-2 implementation: `rmw_cyclonedds `__ (also backported to Dashing) - -* Environment variable `ROS_LOCALHOST_ONLY `__ to limit communication to localhost -* MacOS Mojave Support -* `Tracing instrumentation `__ for rcl and rclcpp - - -During the development the `Eloquent meta ticket `__ on GitHub contains an up-to-date state of the ongoing high level tasks as well as references specific tickets with more details. - -Changes since the Dashing release ---------------------------------- - -geometry_msgs -^^^^^^^^^^^^^ - -The ``geometry_msgs/msg/Quaternion.msg`` interface now default initializes to a valid quaternion, with the following values: - -.. math:: - - x = 0 \\ - y = 0 \\ - z = 0 \\ - w = 1 - -Here is the pull request for more detail: `https://github.com/ros2/common_interfaces/pull/74 `_ - -Static transform broadcasters and listeners now use QoS durability ``transient_local`` on the ``/tf_static`` topic. -Similar to the latched setting in ROS 1, static transforms only need to be published once. -New listeners will receive transforms from all static broadcasters that are alive and have published before. -All publishers must be updated to use this durability setting or their messages won't be received by transform listeners. -See this pull request for more detail: `https://github.com/ros2/geometry2/pull/160 `_ - -rclcpp -^^^^^^ - -API Break with ``get_actual_qos()`` -""""""""""""""""""""""""""""""""""" - -Introduced in Dashing, the ``get_actual_qos()`` method on the ``PublisherBase`` and ``SubscriptionBase`` previously returned an rmw type, ``rmw_qos_profile_t``, but that made it awkward to reuse with the creation of other entities. -Therefore it was updated to return a ``rclcpp::QoS`` instead. - -Existing code will need to use the ``rclcpp::QoS::get_rmw_qos_profile()`` method if the rmw profile is still required. -For example: - -.. code-block:: cpp - - void my_func(const rmw_qos_profile_t & rmw_qos); - - /* Previously: */ - // my_func(some_pub->get_actual_qos()); - /* Now: */ - my_func(some_pub->get_actual_qos()->get_rmw_qos_profile()); - -The rationale for breaking this directly rather than doing a tick-tock is that it is a new function and is expected to be used infrequently by users. -Also, since only the return type is changing, adding a new function with a different would be to only way to do a deprecation cycle and ``get_actual_qos()`` is the most appropriate name, so we would be forced to pick a less obvious name for the method. - -API Break with Publisher and Subscription Classes -""""""""""""""""""""""""""""""""""""""""""""""""" - -In an effort to streamline the construction of Publishers and Subscriptions, the API of the constructors were changed. - -It would be impossible to support a deprecation cycle, because the old signature takes an rcl type and the new one takes the ``NodeBaseInterface`` type so that it can get additional information it now needs, and there's no way to get the additional information needed from just the rcl type. -The new signature could possibly be backported if that would help contributors, but since the publishers and subscriptions are almost always created using the factory functions or some other higher level API, we do not expect this to be a problem for most users. - -Please see the original pr for more detail and comment there if this causes issues: - -`https://github.com/ros2/rclcpp/pull/867 `_ - -Compiler warning about unused result of ``add_on_set_parameters_callback`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -*Since Eloquent Patch Release 2 (2020-12-04)* - -Users should retain the handle returned by ``rclcpp::Node::add_on_set_parameters_callback``, otherwise their callback may be unregistered. -A warning has been added to help identify bugs where the returned handle is not used. - -`https://github.com/ros2/rclcpp/pull/1243 `_ - -rmw -^^^ - -API Break Due to Addition of Publisher and Subscription Options -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The ``rmw_create_publisher()`` method had a new argument added of type ``const rmw_publisher_options_t *``. -This new structure holds options (beyond the typesupport, topic name, and QoS) for new publishers. - -The ``rmw_create_subscription()`` method had one argument removed, ``bool ignore_local_publications``, and replaced by the new options of type ``const rmw_subscription_options_t *``. -The ``ignore_local_publications`` option was moved into the new ``rmw_subscription_options_t`` type. - -In both cases the new argument, which are pointers, may never be null, and so the rmw implementations should check to make sure the options are not null. -Additionally, the options should be copied into the corresponding rmw structure. - -See this pull request, and the associated pull requests for more details: - -`https://github.com/ros2/rmw/pull/187 `_ - -ros2cli -^^^^^^^ - -ros2msg and ros2srv deprecated -"""""""""""""""""""""""""""""" - -The CLI tools ``ros2msg`` and ``ros2srv`` are deprecated. -They have been replaced by the tool ``ros2interface``, which also supports action and IDL interfaces. -You can run ``ros2 interface --help`` for usage. - -ros2node -"""""""" - -Service clients have been added to ros2node info. -As part of that change the Python function ``ros2node.api.get_service_info`` -has been renamed to ``ros2node.api.get_service_server_info``. - -rviz -^^^^ - -Renamed '2D Nav Goal' tool -"""""""""""""""""""""""""" - -The tool was renamed to '2D Goal Pose' and the default topic was changed from ``/move_base_simple/goal`` to ``/goal_pose``. - -Here is the related pull request: - -`https://github.com/ros2/rviz/pull/455 `_ - -TF2 Buffer -^^^^^^^^^^ - -TF2 buffers now have to be given a timer interface. - -If a timer interface is not given, an exception will be thrown. - -For example: - -.. code-block:: cpp - - tf = std::make_shared(get_clock()); - // The next two lines are new in Eloquent - auto timer_interface = std::make_shared( - this->get_node_base_interface(), - this->get_node_timers_interface()); - tf->setCreateTimerInterface(timer_interface); - // Pass the Buffer to the TransformListener as before - transform_listener = std::make_shared(*tf); - -rcl -^^^ - -ROS command line argument changes -""""""""""""""""""""""""""""""""" - -To cope with an increasingly complex interface, with a now extended set of configuration options, ROS CLI syntax has been changed. -As an example, a command line using Dashing syntax like: - -.. code-block:: console - - $ ros2 run some_package some_node foo:=bar __params:=/path/to/params.yaml __log_level:=WARN --user-flag - -is written using Eloquent (and onwards) syntax as: - -.. code-block:: console - - $ ros2 run some_package some_node --ros-args --remap foo:=bar --params-file /path/to/params.yaml --log-level WARN -- --user-flag - -This explicit syntax affords new features, like single parameter assignment ``--param name:=value``. -For further reference and rationale, check the `ROS command line arguments design document `__. - -.. warning:: - - Former syntax has been deprecated and is due for removal in the next release. - -Known Issues ------------- - -* `[ros2/rosidl#402] `_ ``find_package(PCL)`` interferes with ROS interface generation. - Workaround: invoke ``find_package(PCL)`` *after* ``rosidl_generate_interfaces()``. -* `[ros2/rclcpp#893] `_ ``rclcpp::Context`` is not destroyed because of a reference cycle with ``rclcpp::GraphListener``. This causes a memory leak. A fix has not been backported because of the risk of breaking ABI. - -Timeline before the release ---------------------------- - -A few milestones leading up to the release: - - Mon. Sep 30th (alpha) - First releases of core packages available. - Testing can happen from now on (some features might not have landed yet). - - Fri. Oct 18th - API and feature freeze for core packages - Only bug fix releases should be made after this point. - New packages can be released independently. - - Thu. Oct 24th (beta) - Updated releases of core packages available. - Additional testing of the latest features. - - Wed. Nov 13th (release candidate) - Updated releases of core packages available. - - Tue. Nov 19th - Freeze rosdistro. - No PRs for Eloquent on the `rosdistro` repo will be merged (reopens after the release announcement). +.. redirect-from:: + + Releases/Release-Eloquent-Elusor + +Eloquent Elusor (``eloquent``) +============================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Eloquent Elusor* is the fifth release of ROS 2. + +Supported Platforms +------------------- + +Eloquent Elusor supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 18.04 (Bionic): ``amd64`` and ``arm64`` +* Mac macOS 10.14 (Mojave) +* Windows 10 (Visual Studio 2019) + +Tier 2 platforms: + +* Ubuntu 18.04 (Bionic): ``arm32`` + +Tier 3 platforms: + +* Debian Stretch (9): ``amd64``, ``arm64`` and ``arm32`` +* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` + +Targeted platforms: + ++--------------+----------------------+----------------------+----------------------+-------------------+----------------+ +| Architecture | Ubuntu Bionic (18.04)| MacOS Mojave (10.14) | Windows 10 (VS2019) | Debian Buster (10)| OpenEmbedded / | +| | | | | | webOS OSE | ++==============+======================+======================+======================+===================+================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 3 [s] | | ++--------------+----------------------+----------------------+----------------------+-------------------+----------------+ +| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+----------------------+----------------------+-------------------+----------------+ +| arm32 | Tier 2 [a][s] | | | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+----------------------+----------------------+-------------------+----------------+ + + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Debian packages will be provided for this platform for +packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Eloquent ROS 2 repos file[^7]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=====================+===============+===================================+===================================+ +| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ +| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except Debian and | All Architectures except | +| | | | OpenEmbedded | arm64/arm32 | ++--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 2 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ +| rmw_opensplice_cpp | ADLINK OpenSplice | Tier 2 | All Platforms except Debian and | All Architectures | +| | | | OpenEmbedded | | ++--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | ++--------------------------+---------------------+---------------+-----------------------------------+-----------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++14 +- Python 3.6 + +Dependency Requirements: + ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| | Required Support | Recommended Support | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Package | Ubuntu Bionic | MacOS** | Windows 10** | Debian Buster | OpenEmbedded** | ++==============+===================+================+================+================+=======================+ +| CMake | 3.10.2 | 3.14.4 | 3.14.4 | 3.13.4 | 3.16.1 / 3.12.2**** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| EmPY | 3.3.2 | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Gazebo | 9.0.0 | 9.9.0 | N/A | 9.8.0* | N/A | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Ogre | 1.10* | N/A | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| OpenCV | 3.2.0 | 4.1.0 | 3.4.6* | 3.2.0 | 4.1.0 / 3.2.0**** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| OpenSSL | 1.1.0g | 1.0.2r | 1.0.2r | 1.1.1c | 1.1.1d / 1.1.1b**** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Poco | 1.8.0 | 1.9.0 | 1.8.0* | 1.9.0 | 1.9.4 | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Python | 3.6.5 | 3.7.3 | 3.7.3 | 3.7.3 | 3.8.2 / 3.7.5**** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Qt | 5.9.5 | 5.12.3 | 5.10.0 | 5.11.3 | 5.14.1 / 5.12.5**** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| | **Linux only** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| PCL | 1.8.1 | N/A | N/A | 1.9.1 | 1.8.1 | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| **RMW DDS Middleware Providers** | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Connext DDS | 5.3.1*** | N/A | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Cyclone DDS | 0.7.x (Coquette) | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| Fast-RTPS | 1.9.0 | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ +| OpenSplice | 6.9.190705OSS | N/A | ++--------------+-------------------+----------------+----------------+----------------+-----------------------+ + + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. The versions shown for +OpenEmbedded are those provided by the 3.1 Dunfell release series; the +versions provided by the other supported release series are listed here: + . +Note that the OpenEmbedded releases series for which a ROS distro has +support will change during its support time frame, as per the +OpenEmbedded support policy shown here: + +. However, it will always be supported by least one stable OpenEmbedded +release series. + +\" \*\*\* \" It is anticipated that this will be increased to Connext +DDS 6.0.0 pending migration patches[^8]. + +\" \*\*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- MacOS: Homebrew, pip +- Windows: Chocolatey, pip +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Eloquent Elusor <../../eloquent/Installation.html>`__ + +New features in this ROS 2 release +---------------------------------- + +A few features and improvements we would like to highlight: + +* `Support for markup-based launch files (XML/YAML) `__ +* `Improved launch-based testing `__ +* `Passing key-value parameters on CLI `__ +* `Support stream logging macros `__ +* `Per-node logging `__ - All stdout/stderr output from nodes are logged in ~/.ros +* `ros2doctor `__ +* `Improved performance of sourcing setup files `__ +* rviz: `interactive markers `__, `torque ring `__, `tf message filters `__ +* rqt: `parameter plugin `__, `tf tree plugin `__, `robot steering plugin `__ (also backported to Dashing) +* `turtlesim `__ (also backported to Dashing) +* RMW implementations: + + * `API to loan message for zero copy `__, used by `rmw_iceoryx `__ + * `Fast RTPS 1.9.3 `__ + * New Tier-2 implementation: `rmw_cyclonedds `__ (also backported to Dashing) + +* Environment variable `ROS_LOCALHOST_ONLY `__ to limit communication to localhost +* MacOS Mojave Support +* `Tracing instrumentation `__ for rcl and rclcpp + + +During the development the `Eloquent meta ticket `__ on GitHub contains an up-to-date state of the ongoing high level tasks as well as references specific tickets with more details. + +Changes since the Dashing release +--------------------------------- + +geometry_msgs +^^^^^^^^^^^^^ + +The ``geometry_msgs/msg/Quaternion.msg`` interface now default initializes to a valid quaternion, with the following values: + +.. math:: + + x = 0 \\ + y = 0 \\ + z = 0 \\ + w = 1 + +Here is the pull request for more detail: `https://github.com/ros2/common_interfaces/pull/74 `_ + +Static transform broadcasters and listeners now use QoS durability ``transient_local`` on the ``/tf_static`` topic. +Similar to the latched setting in ROS 1, static transforms only need to be published once. +New listeners will receive transforms from all static broadcasters that are alive and have published before. +All publishers must be updated to use this durability setting or their messages won't be received by transform listeners. +See this pull request for more detail: `https://github.com/ros2/geometry2/pull/160 `_ + +rclcpp +^^^^^^ + +API Break with ``get_actual_qos()`` +""""""""""""""""""""""""""""""""""" + +Introduced in Dashing, the ``get_actual_qos()`` method on the ``PublisherBase`` and ``SubscriptionBase`` previously returned an rmw type, ``rmw_qos_profile_t``, but that made it awkward to reuse with the creation of other entities. +Therefore it was updated to return a ``rclcpp::QoS`` instead. + +Existing code will need to use the ``rclcpp::QoS::get_rmw_qos_profile()`` method if the rmw profile is still required. +For example: + +.. code-block:: cpp + + void my_func(const rmw_qos_profile_t & rmw_qos); + + /* Previously: */ + // my_func(some_pub->get_actual_qos()); + /* Now: */ + my_func(some_pub->get_actual_qos()->get_rmw_qos_profile()); + +The rationale for breaking this directly rather than doing a tick-tock is that it is a new function and is expected to be used infrequently by users. +Also, since only the return type is changing, adding a new function with a different would be to only way to do a deprecation cycle and ``get_actual_qos()`` is the most appropriate name, so we would be forced to pick a less obvious name for the method. + +API Break with Publisher and Subscription Classes +""""""""""""""""""""""""""""""""""""""""""""""""" + +In an effort to streamline the construction of Publishers and Subscriptions, the API of the constructors were changed. + +It would be impossible to support a deprecation cycle, because the old signature takes an rcl type and the new one takes the ``NodeBaseInterface`` type so that it can get additional information it now needs, and there's no way to get the additional information needed from just the rcl type. +The new signature could possibly be backported if that would help contributors, but since the publishers and subscriptions are almost always created using the factory functions or some other higher level API, we do not expect this to be a problem for most users. + +Please see the original pr for more detail and comment there if this causes issues: + +`https://github.com/ros2/rclcpp/pull/867 `_ + +Compiler warning about unused result of ``add_on_set_parameters_callback`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +*Since Eloquent Patch Release 2 (2020-12-04)* + +Users should retain the handle returned by ``rclcpp::Node::add_on_set_parameters_callback``, otherwise their callback may be unregistered. +A warning has been added to help identify bugs where the returned handle is not used. + +`https://github.com/ros2/rclcpp/pull/1243 `_ + +rmw +^^^ + +API Break Due to Addition of Publisher and Subscription Options +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The ``rmw_create_publisher()`` method had a new argument added of type ``const rmw_publisher_options_t *``. +This new structure holds options (beyond the typesupport, topic name, and QoS) for new publishers. + +The ``rmw_create_subscription()`` method had one argument removed, ``bool ignore_local_publications``, and replaced by the new options of type ``const rmw_subscription_options_t *``. +The ``ignore_local_publications`` option was moved into the new ``rmw_subscription_options_t`` type. + +In both cases the new argument, which are pointers, may never be null, and so the rmw implementations should check to make sure the options are not null. +Additionally, the options should be copied into the corresponding rmw structure. + +See this pull request, and the associated pull requests for more details: + +`https://github.com/ros2/rmw/pull/187 `_ + +ros2cli +^^^^^^^ + +ros2msg and ros2srv deprecated +"""""""""""""""""""""""""""""" + +The CLI tools ``ros2msg`` and ``ros2srv`` are deprecated. +They have been replaced by the tool ``ros2interface``, which also supports action and IDL interfaces. +You can run ``ros2 interface --help`` for usage. + +ros2node +"""""""" + +Service clients have been added to ros2node info. +As part of that change the Python function ``ros2node.api.get_service_info`` +has been renamed to ``ros2node.api.get_service_server_info``. + +rviz +^^^^ + +Renamed '2D Nav Goal' tool +"""""""""""""""""""""""""" + +The tool was renamed to '2D Goal Pose' and the default topic was changed from ``/move_base_simple/goal`` to ``/goal_pose``. + +Here is the related pull request: + +`https://github.com/ros2/rviz/pull/455 `_ + +TF2 Buffer +^^^^^^^^^^ + +TF2 buffers now have to be given a timer interface. + +If a timer interface is not given, an exception will be thrown. + +For example: + +.. code-block:: cpp + + tf = std::make_shared(get_clock()); + // The next two lines are new in Eloquent + auto timer_interface = std::make_shared( + this->get_node_base_interface(), + this->get_node_timers_interface()); + tf->setCreateTimerInterface(timer_interface); + // Pass the Buffer to the TransformListener as before + transform_listener = std::make_shared(*tf); + +rcl +^^^ + +ROS command line argument changes +""""""""""""""""""""""""""""""""" + +To cope with an increasingly complex interface, with a now extended set of configuration options, ROS CLI syntax has been changed. +As an example, a command line using Dashing syntax like: + +.. code-block:: console + + $ ros2 run some_package some_node foo:=bar __params:=/path/to/params.yaml __log_level:=WARN --user-flag + +is written using Eloquent (and onwards) syntax as: + +.. code-block:: console + + $ ros2 run some_package some_node --ros-args --remap foo:=bar --params-file /path/to/params.yaml --log-level WARN -- --user-flag + +This explicit syntax affords new features, like single parameter assignment ``--param name:=value``. +For further reference and rationale, check the `ROS command line arguments design document `__. + +.. warning:: + + Former syntax has been deprecated and is due for removal in the next release. + +Known Issues +------------ + +* `[ros2/rosidl#402] `_ ``find_package(PCL)`` interferes with ROS interface generation. + Workaround: invoke ``find_package(PCL)`` *after* ``rosidl_generate_interfaces()``. +* `[ros2/rclcpp#893] `_ ``rclcpp::Context`` is not destroyed because of a reference cycle with ``rclcpp::GraphListener``. This causes a memory leak. A fix has not been backported because of the risk of breaking ABI. + +Timeline before the release +--------------------------- + +A few milestones leading up to the release: + + Mon. Sep 30th (alpha) + First releases of core packages available. + Testing can happen from now on (some features might not have landed yet). + + Fri. Oct 18th + API and feature freeze for core packages + Only bug fix releases should be made after this point. + New packages can be released independently. + + Thu. Oct 24th (beta) + Updated releases of core packages available. + Additional testing of the latest features. + + Wed. Nov 13th (release candidate) + Updated releases of core packages available. + + Tue. Nov 19th + Freeze rosdistro. + No PRs for Eloquent on the `rosdistro` repo will be merged (reopens after the release announcement). \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst b/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst index 941b3f6da8f..e9a01e67bc3 100644 --- a/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst +++ b/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst @@ -1,607 +1,611 @@ -Foxy Fitzroy (``foxy``) -======================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Foxy Fitzroy* is the sixth release of ROS 2. - -Supported Platforms -------------------- - -Foxy Fitzroy supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 20.04 (Focal): ``amd64`` and ``arm64`` -* Mac macOS 10.14 (Mojave) -* Windows 10 (Visual Studio 2019) - -Tier 3 platforms: - -* Ubuntu 20.04 (Focal): ``arm32`` -* Debian Buster (10): ``amd64``, ``arm64`` and ``arm32`` -* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` - -Targeted platforms: - -+--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ -| Architecture | Ubuntu Focal (20.04) | MacOS Mojave (10.14) | Windows 10 (VS2019)| Debian Buster (10)| OpenEmbedded / | -| | | | | | webOS OSE | -+==============+=======================+======================+====================+===================+================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 3 [s] | | -+--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ -| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ -| arm32 | Tier 3 [s] | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Debian packages will be provided for this platform for -packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Foxy ROS 2 repos file[^9]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=======================+===============+=========================+===================================+ -| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ -| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except | All Architectures except | -| | | | Debian and OpenEmbedded | arm64/arm32 | -+--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | -+--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks | Tier 3 | Ubuntu and Windows | All Architectures except arm32 | -| | GurumDDS | | | | -+--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ - - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++14 -- Python 3.7 - -Dependency Requirements: - -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| | Required Support | Recommended Support | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Package | Ubuntu Focal | MacOS** | Windows 10** | Debian Buster | OpenEmbedded** | -+==============+==================+==================+==================+==================+=======================+ -| CMake | 3.16.3 | 3.14.4 | 3.14.4 | 3.13.4 | 3.16.1 / 3.12.2**** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| EmPY | 3.3.2 | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Gazebo | 11.0.0* | 11.0.0 | N/A | 11.0.0* | N/A | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Ignition | Citadel* | N/A | Citadel* | N/A | -+--------------+-------------------------------------+------------------+------------------+-----------------------+ -| Ogre | 1.10* | N/A | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| OpenCV | 4.2.0 | 4.2.0 | 3.4.6* | 3.2.0 | 4.1.0 / 3.2.0**** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| OpenSSL | 1.1.1d | 1.1.1f | 1.1.1f | 1.1.1d | 1.1.1d / 1.1.1b**** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Poco | 1.9.2 | 1.9.0 | 1.8.0* | 1.9.0 | 1.9.4 | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Python | 3.8.0 | 3.8.2 | 3.8.0 | 3.7.3 | 3.8.2 / 3.7.5**** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Qt | 5.12.5 | 5.12.3 | 5.10.0 | 5.11.3 | 5.14.1 / 5.12.5**** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| | **Linux only** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| PCL | 1.10.0 | N/A | N/A | 1.9.1 | 1.10.0 | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| **RMW DDS Middleware Providers** | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Connext DDS | 5.3.1 | N/A | -+--------------+-------------------------------------+------------------+------------------------------------------+ -| Cyclone DDS | 0.7.x (Coquette) | -+--------------+---------------------------------------------------------------------------------------------------+ -| Fast-RTPS | 2.0.x | -+--------------+------------------+------------------+------------------+------------------+-----------------------+ -| Gurum DDS | 2.7.x | N/A | 2.7.x | N/A | -+--------------+------------------+------------------+------------------+------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. The versions shown for -OpenEmbedded are those provided by the 3.1 Dunfell release series; the -versions provided by the other supported release series are listed here: - . -Note that the OpenEmbedded releases series for which a ROS distro has -support will change during its support time frame, as per the -OpenEmbedded support policy shown here: - -. However, it will always be supported by least one stable OpenEmbedded -release series. - -\" \*\*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- MacOS: Homebrew, pip -- Windows: Chocolatey, pip -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Foxy Fitzroy <../../foxy/Installation.html>`__ - -New features in this ROS 2 release ----------------------------------- - -During the development the `Foxy meta-ticket `__ on GitHub contains an up-to-date state of the ongoing high-level tasks as well as references specific tickets with more details. - -Changes in Patch Release 8 (2022-09-28) ---------------------------------------- - -Launch GroupAction scopes environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``SetEnvironmentVariable`` action is now scoped to any ``GroupAction`` it is returned from. - -For example, consider the following launch files, - -.. tabs:: - - .. group-tab:: Python - - .. code-block:: python - - import launch - from launch.actions import SetEnvironmentVariable - from launch.actions import GroupAction - from launch_ros.actions import Node - - - def generate_launch_description(): - return launch.LaunchDescription([ - SetEnvironmentVariable(name='my_env_var', value='1'), - Node(package='foo', executable='foo', output='screen'), - GroupAction([ - SetEnvironmentVariable(name='my_env_var', value='2'), - ]), - ]) - - .. group-tab:: XML - - .. code-block:: xml - - - - - - - - - -Before patch release 8, the node ``foo`` will start with ``my_env_var=2``, but now it will start with ``my_env_var=1``. - -To opt-out of the new behavior, you can set the argument ``scoped=False`` on the ``GroupAction``. - -Related tickets: - - -* `ros2#1244 `_ -* `launch#630 `_ - -Changes in Patch Release 7 (2022-02-08) ---------------------------------------- - -Launch set_env frontend behavior change -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -`launch#468 `_ inadvertently changed behavior to the scope of the ``set_env`` action in frontend launch files. -Changes to environment variables using the ``set_env`` action are no longer scoped to parent ``group`` actions, and instead apply globally. -Since it was backported, the change affects this release. - -We consider this change a regression and intend to fix the behavior in the next patch release and in future ROS distributions. -We also plan to fix the behavior in Python launch files, which have never scoped setting environment variables properly. - -Related issues: - -* `ros2#1244 `_ -* `launch#597 `_ - -Fix launch frontend parser -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A refactor of the launch frontend parser fixed some `issues parsing special characters `_. -As a result, there has been a small behavior change when it comes to parsing strings. -For example, previously to pass a number as a string you would have to add extra quotation marks (two sets of quotation marks were needed if using a substitution): - -.. code-block:: xml - - - - -After the refactor, the above will result in the the string ``"''3''"`` (note the extra set of quotation marks). -Now, users should use the ``type`` attribute to signal that the value should be interpreted as a string: - -.. code-block:: xml - - - -Related pull requests: - -* `launch#530 `_ -* `launch_ros#265 `_ - -Fix memory leaks and undefined behavior in rmw_fastrtps_dynamic_cpp -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -API was changed in the following header files: - -- ``rmw_fastrtps_dynamic_cpp/TypeSupport.hpp`` -- ``rmw_fastrtps_dynamic_cpp/TypeSupport_impl.hpp`` - -Though technically they are publically accessible, it is unlikely people are using them directly. -Therefore, we decided to break API in order to fix memory leaks and undefined behavior. - -The fix was originally submitted in `rmw_fastrtps#429 `_ and later backported to Foxy in `rmw_fastrtps#577 `_. - -Changes in Patch Release 2 (2020-08-07) ---------------------------------------- - -Bug in static_transform_publisher -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -During the development of Foxy, a bug was introduced into the tf2_ros static_transform_publisher program. -The implementation of the order of the Euler angles passed to static_transform_publisher disagrees with the documentation. -Foxy patch release 2 `fixes `_ the order so that the implementation agrees with the documentation (yaw, pitch, roll). -For users who have started using the initial Foxy release or patch release 1, this means that any launch files that use static_transform_publisher will have to have the command-line order swapped according to the new order. -For users who are coming from ROS 2 Dashing, ROS 2 Eloquent, or ROS 1, no changes need to be made to port to Foxy patch release 2. - -Changes since the Eloquent release ----------------------------------- - -Classic CMake vs. modern CMake -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In "classic" CMake a package provides CMake variables like ``_INCLUDE_DIRS`` and ``_LIBRARIES`` when being ``find_package()``-ed. -With ``ament_cmake`` that is achieved by calling ``ament_export_include_directories`` and ``ament_export_libraries``. -In combination with ``ament_export_dependencies``, ``ament_cmake`` ensures that all include directories and libraries of recursive dependencies are concatenated and included in these variables. - -In "modern" CMake a package provides an interface target instead (commonly named ``::``) which in itself encapsulates all recursive dependencies. -In order to export a library target to use modern CMake ``ament_export_targets`` needs to be called with an export name which is also used when installing the libraries using ``install(TARGETS EXPORT ...)``. -The exported interface targets are available through the CMake variable ``_TARGETS``. -For library targets to be exportable like this they must not rely on classic functions affecting global state like ``include_directories()`` but set the include directories on the target itself - for the build as well as install environment - using generator expressions, e.g. ``target_include_directories( PUBLIC "$" "$")``. - -When ``ament_target_dependencies`` is used to add dependencies to a library target the function uses modern CMake targets when they are available. -Otherwise it falls back to using classic CMake variables. -As a consequence you should only export modern CMake targets if all dependencies are also providing modern CMake targets. -**Otherwise the exported interface target will contain the absolute paths to include directories / libraries in the generated CMake logic which makes the package non-relocatable.** - -For examples how packages have been updated to modern CMake in Foxy see `ros2/ros2#904 `_. - -ament_export_interfaces replaced by ament_export_targets -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The CMake function ``ament_export_interfaces`` from the package ``ament_cmake_export_interfaces`` has been deprecated in favor of the function ``ament_export_targets`` in the new package ``ament_cmake_export_targets``. -See the GitHub ticket `ament/ament_cmake#237 `_ for more context. - -rosidl_generator_c|cpp namespace / API changes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The packages ``rosidl_generator_c`` and ``rosidl_generator_cpp`` have been refactored with many headers and sources moved into the new packages ``rosidl_runtime_c`` and ``rosidl_runtime_cpp``. -The intention is to remove run dependencies on the generator packages and therefore the code generation tools using Python. -While moving the headers the include paths / namespaces were updated accordingly so in many cases changing include directives from the generator package to the runtime package is sufficient. - -The generated C / C++ code has also been refactored. -The files ending in ``__struct.h|hpp``, ``__functions.h``, ``__traits.hpp``, etc. have been moved into a subdirectory ``detail`` but most code only includes the header named after the interface without any of these suffixes. - -Some types regarding string and sequence bounds have also been renamed to match the naming conventions but they aren't expected to be used in user code (above RMW implementation and type support packages) - -For more information see `ros2/rosidl#446 (for C) `_ and `ros2/rosidl#447 (for C++) `_. - -Default working directory for ament_add_test -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default working directory for tests added with ``ament_add_test`` has been changed to ``CMAKE_CURRENT_BINARY_DIR`` to match the behavior of CMake ``add_test``. -Either update the tests to work with the new default or pass ``WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}`` to restore the previous value. - -Default Console Logging Format -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The default console logging output format was changed to include the timestamp by default, see: - -- `https://github.com/ros2/rcutils/pull/190 `_ -- `https://discourse.ros.org/t/ros2-logging-format/11549 `_ - -Default Console Logging Output Stream -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As of Foxy, all logging messages at all severity levels get logged to stderr by default. -This ensures that logging messages come out immediately, and brings the ROS 2 logging system into alignment with most other logging systems. -It is possible to change the stream to stdout at runtime via the RCUTILS_LOGGING_USE_STDOUT environment variable, but all logging messages will still go to the same stream. -See `https://github.com/ros2/rcutils/pull/196 `_ for more details. - -launch_ros -^^^^^^^^^^ - -Node name and namespace parameters changed -"""""""""""""""""""""""""""""""""""""""""" - -The ``Node`` action parameters related to naming have been changed: - -- ``node_name`` has been renamed to ``name`` -- ``node_namespace`` has been renamed to ``namespace`` -- ``node_executable`` has been renamed to ``executable`` -- ``exec_name`` has been added for naming the process associated with the node. - Previously, users would have used the ``name`` keyword argument. - -The old parameters have been deprecated. - -These changes were made to make the launch frontend more idiomatic. -For example, instead of - -.. code-block:: xml - - - -we can now write - -.. code-block:: xml - - - -This change also applies to ``ComposableNodeContainer``, ``ComposableNode``, and ``LifecycleNode``. -For examples, see the `relevant changes to the demos. `_ - -`Related pull request in launch_ros. `_ - -rclcpp -^^^^^^ - -Change in Advanced Subscription Callback Signature -"""""""""""""""""""""""""""""""""""""""""""""""""" - -With the pull request `https://github.com/ros2/rclcpp/pull/1047 `_ the signature of callbacks which receive the message info with the message has changed. -Previously it used the ``rmw`` type ``rmw_message_info_t``, but now uses the ``rclcpp`` type ``rclcpp::MessageInfo``. -The required changes are straightforward, and can be seen demonstrated in these pull requests: - -- `https://github.com/ros2/system_tests/pull/423/files `_ -- `https://github.com/ros2/rosbag2/pull/375/files `_ -- `https://github.com/ros2/ros1_bridge/pull/253/files `_ - -Change in Serialized Message Callback Signature -""""""""""""""""""""""""""""""""""""""""""""""" - -The pull request `ros2/rclcpp#1081 `_ introduces a new signature of the callbacks for retrieving ROS messages in serialized form. -The previously used C-Struct `rcl_serialized_message_t `_ is being superseded by a C++ data type `rclcpp::SerializedMessage `_. - -The example nodes in ``demo_nodes_cpp``, namely ``talker_serialized_message`` as well as ``listener_serialized_message`` reflect these changes. - -Breaking change in Node Interface getters' signature -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -With pull request `ros2/rclcpp#1069 `_, the signature of node interface getters has been modified to return shared ownership of node interfaces (i.e. an ``std::shared_ptr``) instead of a non-owning raw pointer. -Required changes in downstream packages that relied on the previous signature are simple and straightforward: use the ``std::shared_ptr::get()`` method. - -Deprecate set_on_parameters_set_callback -"""""""""""""""""""""""""""""""""""""""" - -Instead, use the ``rclcpp::Node`` methods ``add_on_set_parameters_callback`` and ``remove_on_set_parameters_callback`` for adding and removing functions that are called when parameters are set. - -Related pull request: https://github.com/ros2/rclcpp/pull/1123 - -Breaking change in Publisher getter signature -"""""""""""""""""""""""""""""""""""""""""""""" - -With pull request `ros2/rclcpp#1119 `_, the signature of publisher handle getter has been modified to return shared ownership of the underlying rcl structure (i.e. an ``std::shared_ptr``) instead of a non-owning raw pointer. -This was necessary to fix a segfault in certain circumstances. -Required changes in downstream packages that relied on the previous signature are simple and straightforward: use the ``std::shared_ptr::get()`` method. - -rclcpp_action -^^^^^^^^^^^^^ - -Deprecate ClientGoalHandle::async_result() -"""""""""""""""""""""""""""""""""""""""""" - -Using this API, it is possible to run into a race condition causing an exception to be thrown. -Instead, prefer to use ``Client::async_get_result()``, which is safer. - -See `ros2/rclcpp#1120 `_ and the connected issue for more info. - -rclpy -^^^^^ - -Support for multiple on parameter set callbacks -""""""""""""""""""""""""""""""""""""""""""""""" - -Use the ``Node`` methods ``add_on_set_parameters_callback`` and ``remove_on_set_parameters_callback`` for adding and removing functions that are called when parameters are set. - -The method ``set_parameters_callback`` has been deprecated. - -Related pull requests: https://github.com/ros2/rclpy/pull/457, https://github.com/ros2/rclpy/pull/504 - -rmw_connext_cpp -^^^^^^^^^^^^^^^ - -Connext 5.1 locator kinds compatibility mode -"""""""""""""""""""""""""""""""""""""""""""" - -Up to and including ``Eloquent``, ``rmw_connext_cpp`` was setting ``dds.transport.use_510_compatible_locator_kinds`` property to ``true``. -This property is not being forced anymore, and shared transport communication between ``Foxy`` and previous releases will stop working. -Logs similar to: - -.. code-block:: bash - - PRESParticipant_checkTransportInfoMatching:Warning: discovered remote participant 'RTI Administration Console' using the 'shmem' transport with class ID 16777216. - This class ID does not match the class ID 2 of the same transport in the local participant 'talker'. - These two participants will not communicate over the 'shmem' transport. - Check the value of the property 'dds.transport.use_510_compatible_locator_kinds' in the local participant. - See https://community.rti.com/kb/what-causes-error-discovered-remote-participant for additional info. - -will be observed when this incompatibility happens. - -If compatibility is needed, it can be set up in an external QoS profiles files containing: - -.. code-block:: xml - - - - - - - dds.transport.use_510_compatible_locator_kinds - - 1 - - - - - -Remember to set the ``NDDS_QOS_PROFILES`` environment variable to the QoS profiles file path. -For more information, see ``How to Change Transport Settings in 5.2.0 Applications for Compatibility with 5.1.0`` section of `Transport_Compatibility `_. - -rviz -^^^^ - -Tools timestamp messages using ROS time -""""""""""""""""""""""""""""""""""""""" - -'2D Pose Estimate', '2D Nav Goal', and 'Publish Point' tools now timestamp their messages using ROS time instead of system time, in order for the ``use_sim_time`` parameter to have an effect on them. - -Related pull request: https://github.com/ros2/rviz/pull/519 - -std_msgs -^^^^^^^^ - -Deprecation of messages -""""""""""""""""""""""" - -Although discouraged for a long time we have officially deprecated the following messages in ``std_msgs``. -There are copies in `example_interfaces `_ - -- ``std_msgs/msg/Bool`` -- ``std_msgs/msg/Byte`` -- ``std_msgs/msg/ByteMultiArray`` -- ``std_msgs/msg/Char`` -- ``std_msgs/msg/Float32`` -- ``std_msgs/msg/Float32MultiArray`` -- ``std_msgs/msg/Float64`` -- ``std_msgs/msg/Float64MultiArray`` -- ``std_msgs/msg/Int16`` -- ``std_msgs/msg/Int16MultiArray`` -- ``std_msgs/msg/Int32`` -- ``std_msgs/msg/Int32MultiArray`` -- ``std_msgs/msg/Int64`` -- ``std_msgs/msg/Int64MultiArray`` -- ``std_msgs/msg/Int8`` -- ``std_msgs/msg/Int8MultiArray`` -- ``std_msgs/msg/MultiArrayDimension`` -- ``std_msgs/msg/MultiArrayLayout`` -- ``std_msgs/msg/String`` -- ``std_msgs/msg/UInt16`` -- ``std_msgs/msg/UInt16MultiArray`` -- ``std_msgs/msg/UInt32`` -- ``std_msgs/msg/UInt32MultiArray`` -- ``std_msgs/msg/UInt64`` -- ``std_msgs/msg/UInt64MultiArray`` -- ``std_msgs/msg/UInt8`` -- ``std_msgs/msg/UInt8MultiArray`` - -Security features -^^^^^^^^^^^^^^^^^ - -Use of security enclaves -"""""""""""""""""""""""" - -As of Foxy, domain participants are no longer mapped directly to ROS nodes. -As a result, ROS 2 security features (which are specific to domain participants) are also no longer mapped directly to ROS nodes. -Instead, Foxy introduces the concept of a security "enclave", where an "enclave" is a process or group of processes that will share the same identity and access control rules. - -This means that security artifacts are **not** retrieved based on the node name anymore but based on the Security enclave name. -A node enclave name can be set by using the ROS argument ``--enclave``, e.g. ``ros2 run demo_nodes_py talker --ros-args --enclave /my_enclave`` - -Related design document: https://github.com/ros2/design/pull/274 - -Note that permissions files are limited by the underlying transport packet size, so grouping many permissions under the same enclave will **not** work if the resulting permissions file exceed 64kB. -Related issue `[ros2/sros2#228] `_ - -Renaming of the environment variables -""""""""""""""""""""""""""""""""""""" - -.. list-table:: Environment variables renaming - :widths: 25 25 - :header-rows: 1 - - * - Name in Eloquent - - Name in Foxy - * - ROS_SECURITY_ROOT_DIRECTORY - - ROS_SECURITY_KEYSTORE - * - ROS_SECURITY_NODE_DIRECTORY - - ROS_SECURITY_ENCLAVE_OVERRIDE - - -Known Issues ------------- - -* `[ros2/ros2#922] `_ Services' performance is flaky for ``rclcpp`` nodes using eProsima Fast-RTPS or ADLINK CycloneDDS as RMW implementation. - Specifically, service clients sometimes do not receive the response from servers. - -* `[ros2/rclcpp#1212] `_ Ready reentrant Waitable objects can attempt to execute multiple times. - - -Timeline before the release ---------------------------- - -A few milestones leading up to the release: - - .. note:: - - The dates below reflect an extension by roughly two weeks due to the coronavirus pandemic. - - Wed. April 22nd, 2020 - API and feature freeze for ``ros_core`` [1]_ packages. - Note that this includes ``rmw``, which is a recursive dependency of ``ros_core``. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 29th, 2020 (beta) - Updated releases of ``desktop`` [2]_ packages available. - Testing of the new features. - - Wed. May 27th, 2020 (release candidate) - Updated releases of ``desktop`` [2]_ packages available. - - Wed. June 3rd, 2020 - Freeze rosdistro. - No PRs for Foxy on the `rosdistro` repo will be merged (reopens after the release announcement). - -.. [1] The ``ros_core`` variant described in the `variants `_ repository. -.. [2] The ``desktop`` variant described in the `variants `_ repository. +.. redirect-from:: + + Releases/Release-Foxy-Fitzroy + +Foxy Fitzroy (``foxy``) +======================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Foxy Fitzroy* is the sixth release of ROS 2. + +Supported Platforms +------------------- + +Foxy Fitzroy supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 20.04 (Focal): ``amd64`` and ``arm64`` +* Mac macOS 10.14 (Mojave) +* Windows 10 (Visual Studio 2019) + +Tier 3 platforms: + +* Ubuntu 20.04 (Focal): ``arm32`` +* Debian Buster (10): ``amd64``, ``arm64`` and ``arm32`` +* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` + +Targeted platforms: + ++--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ +| Architecture | Ubuntu Focal (20.04) | MacOS Mojave (10.14) | Windows 10 (VS2019)| Debian Buster (10)| OpenEmbedded / | +| | | | | | webOS OSE | ++==============+=======================+======================+====================+===================+================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 1 [a][s] | Tier 3 [s] | | ++--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ +| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ +| arm32 | Tier 3 [s] | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-----------------------+----------------------+--------------------+-------------------+----------------+ + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Debian packages will be provided for this platform for +packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Foxy ROS 2 repos file[^9]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=======================+===============+=========================+===================================+ +| rmw_fastrtps_cpp* | eProsima Fast-RTPS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ +| rmw_connext_cpp | RTI Connext | Tier 1 | All Platforms except | All Architectures except | +| | | | Debian and OpenEmbedded | arm64/arm32 | ++--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-RTPS | Tier 2 | All Platforms | All Architectures | ++--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks | Tier 3 | Ubuntu and Windows | All Architectures except arm32 | +| | GurumDDS | | | | ++--------------------------+-----------------------+---------------+-------------------------+-----------------------------------+ + + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++14 +- Python 3.7 + +Dependency Requirements: + ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| | Required Support | Recommended Support | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Package | Ubuntu Focal | MacOS** | Windows 10** | Debian Buster | OpenEmbedded** | ++==============+==================+==================+==================+==================+=======================+ +| CMake | 3.16.3 | 3.14.4 | 3.14.4 | 3.13.4 | 3.16.1 / 3.12.2**** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| EmPY | 3.3.2 | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Gazebo | 11.0.0* | 11.0.0 | N/A | 11.0.0* | N/A | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Ignition | Citadel* | N/A | Citadel* | N/A | ++--------------+-------------------------------------+------------------+------------------+-----------------------+ +| Ogre | 1.10* | N/A | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| OpenCV | 4.2.0 | 4.2.0 | 3.4.6* | 3.2.0 | 4.1.0 / 3.2.0**** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| OpenSSL | 1.1.1d | 1.1.1f | 1.1.1f | 1.1.1d | 1.1.1d / 1.1.1b**** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Poco | 1.9.2 | 1.9.0 | 1.8.0* | 1.9.0 | 1.9.4 | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Python | 3.8.0 | 3.8.2 | 3.8.0 | 3.7.3 | 3.8.2 / 3.7.5**** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Qt | 5.12.5 | 5.12.3 | 5.10.0 | 5.11.3 | 5.14.1 / 5.12.5**** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| | **Linux only** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| PCL | 1.10.0 | N/A | N/A | 1.9.1 | 1.10.0 | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| **RMW DDS Middleware Providers** | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Connext DDS | 5.3.1 | N/A | ++--------------+-------------------------------------+------------------+------------------------------------------+ +| Cyclone DDS | 0.7.x (Coquette) | ++--------------+---------------------------------------------------------------------------------------------------+ +| Fast-RTPS | 2.0.x | ++--------------+------------------+------------------+------------------+------------------+-----------------------+ +| Gurum DDS | 2.7.x | N/A | 2.7.x | N/A | ++--------------+------------------+------------------+------------------+------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. The versions shown for +OpenEmbedded are those provided by the 3.1 Dunfell release series; the +versions provided by the other supported release series are listed here: + . +Note that the OpenEmbedded releases series for which a ROS distro has +support will change during its support time frame, as per the +OpenEmbedded support policy shown here: + +. However, it will always be supported by least one stable OpenEmbedded +release series. + +\" \*\*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- MacOS: Homebrew, pip +- Windows: Chocolatey, pip +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Foxy Fitzroy <../../foxy/Installation.html>`__ + +New features in this ROS 2 release +---------------------------------- + +During the development the `Foxy meta-ticket `__ on GitHub contains an up-to-date state of the ongoing high-level tasks as well as references specific tickets with more details. + +Changes in Patch Release 8 (2022-09-28) +--------------------------------------- + +Launch GroupAction scopes environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``SetEnvironmentVariable`` action is now scoped to any ``GroupAction`` it is returned from. + +For example, consider the following launch files, + +.. tabs:: + + .. group-tab:: Python + + .. code-block:: python + + import launch + from launch.actions import SetEnvironmentVariable + from launch.actions import GroupAction + from launch_ros.actions import Node + + + def generate_launch_description(): + return launch.LaunchDescription([ + SetEnvironmentVariable(name='my_env_var', value='1'), + Node(package='foo', executable='foo', output='screen'), + GroupAction([ + SetEnvironmentVariable(name='my_env_var', value='2'), + ]), + ]) + + .. group-tab:: XML + + .. code-block:: xml + + + + + + + + + +Before patch release 8, the node ``foo`` will start with ``my_env_var=2``, but now it will start with ``my_env_var=1``. + +To opt-out of the new behavior, you can set the argument ``scoped=False`` on the ``GroupAction``. + +Related tickets: + + +* `ros2#1244 `_ +* `launch#630 `_ + +Changes in Patch Release 7 (2022-02-08) +--------------------------------------- + +Launch set_env frontend behavior change +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +`launch#468 `_ inadvertently changed behavior to the scope of the ``set_env`` action in frontend launch files. +Changes to environment variables using the ``set_env`` action are no longer scoped to parent ``group`` actions, and instead apply globally. +Since it was backported, the change affects this release. + +We consider this change a regression and intend to fix the behavior in the next patch release and in future ROS distributions. +We also plan to fix the behavior in Python launch files, which have never scoped setting environment variables properly. + +Related issues: + +* `ros2#1244 `_ +* `launch#597 `_ + +Fix launch frontend parser +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A refactor of the launch frontend parser fixed some `issues parsing special characters `_. +As a result, there has been a small behavior change when it comes to parsing strings. +For example, previously to pass a number as a string you would have to add extra quotation marks (two sets of quotation marks were needed if using a substitution): + +.. code-block:: xml + + + + +After the refactor, the above will result in the the string ``"''3''"`` (note the extra set of quotation marks). +Now, users should use the ``type`` attribute to signal that the value should be interpreted as a string: + +.. code-block:: xml + + + +Related pull requests: + +* `launch#530 `_ +* `launch_ros#265 `_ + +Fix memory leaks and undefined behavior in rmw_fastrtps_dynamic_cpp +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +API was changed in the following header files: + +- ``rmw_fastrtps_dynamic_cpp/TypeSupport.hpp`` +- ``rmw_fastrtps_dynamic_cpp/TypeSupport_impl.hpp`` + +Though technically they are publically accessible, it is unlikely people are using them directly. +Therefore, we decided to break API in order to fix memory leaks and undefined behavior. + +The fix was originally submitted in `rmw_fastrtps#429 `_ and later backported to Foxy in `rmw_fastrtps#577 `_. + +Changes in Patch Release 2 (2020-08-07) +--------------------------------------- + +Bug in static_transform_publisher +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +During the development of Foxy, a bug was introduced into the tf2_ros static_transform_publisher program. +The implementation of the order of the Euler angles passed to static_transform_publisher disagrees with the documentation. +Foxy patch release 2 `fixes `_ the order so that the implementation agrees with the documentation (yaw, pitch, roll). +For users who have started using the initial Foxy release or patch release 1, this means that any launch files that use static_transform_publisher will have to have the command-line order swapped according to the new order. +For users who are coming from ROS 2 Dashing, ROS 2 Eloquent, or ROS 1, no changes need to be made to port to Foxy patch release 2. + +Changes since the Eloquent release +---------------------------------- + +Classic CMake vs. modern CMake +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In "classic" CMake a package provides CMake variables like ``_INCLUDE_DIRS`` and ``_LIBRARIES`` when being ``find_package()``-ed. +With ``ament_cmake`` that is achieved by calling ``ament_export_include_directories`` and ``ament_export_libraries``. +In combination with ``ament_export_dependencies``, ``ament_cmake`` ensures that all include directories and libraries of recursive dependencies are concatenated and included in these variables. + +In "modern" CMake a package provides an interface target instead (commonly named ``::``) which in itself encapsulates all recursive dependencies. +In order to export a library target to use modern CMake ``ament_export_targets`` needs to be called with an export name which is also used when installing the libraries using ``install(TARGETS EXPORT ...)``. +The exported interface targets are available through the CMake variable ``_TARGETS``. +For library targets to be exportable like this they must not rely on classic functions affecting global state like ``include_directories()`` but set the include directories on the target itself - for the build as well as install environment - using generator expressions, e.g. ``target_include_directories( PUBLIC "$" "$")``. + +When ``ament_target_dependencies`` is used to add dependencies to a library target the function uses modern CMake targets when they are available. +Otherwise it falls back to using classic CMake variables. +As a consequence you should only export modern CMake targets if all dependencies are also providing modern CMake targets. +**Otherwise the exported interface target will contain the absolute paths to include directories / libraries in the generated CMake logic which makes the package non-relocatable.** + +For examples how packages have been updated to modern CMake in Foxy see `ros2/ros2#904 `_. + +ament_export_interfaces replaced by ament_export_targets +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The CMake function ``ament_export_interfaces`` from the package ``ament_cmake_export_interfaces`` has been deprecated in favor of the function ``ament_export_targets`` in the new package ``ament_cmake_export_targets``. +See the GitHub ticket `ament/ament_cmake#237 `_ for more context. + +rosidl_generator_c|cpp namespace / API changes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The packages ``rosidl_generator_c`` and ``rosidl_generator_cpp`` have been refactored with many headers and sources moved into the new packages ``rosidl_runtime_c`` and ``rosidl_runtime_cpp``. +The intention is to remove run dependencies on the generator packages and therefore the code generation tools using Python. +While moving the headers the include paths / namespaces were updated accordingly so in many cases changing include directives from the generator package to the runtime package is sufficient. + +The generated C / C++ code has also been refactored. +The files ending in ``__struct.h|hpp``, ``__functions.h``, ``__traits.hpp``, etc. have been moved into a subdirectory ``detail`` but most code only includes the header named after the interface without any of these suffixes. + +Some types regarding string and sequence bounds have also been renamed to match the naming conventions but they aren't expected to be used in user code (above RMW implementation and type support packages) + +For more information see `ros2/rosidl#446 (for C) `_ and `ros2/rosidl#447 (for C++) `_. + +Default working directory for ament_add_test +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default working directory for tests added with ``ament_add_test`` has been changed to ``CMAKE_CURRENT_BINARY_DIR`` to match the behavior of CMake ``add_test``. +Either update the tests to work with the new default or pass ``WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}`` to restore the previous value. + +Default Console Logging Format +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The default console logging output format was changed to include the timestamp by default, see: + +- `https://github.com/ros2/rcutils/pull/190 `_ +- `https://discourse.ros.org/t/ros2-logging-format/11549 `_ + +Default Console Logging Output Stream +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As of Foxy, all logging messages at all severity levels get logged to stderr by default. +This ensures that logging messages come out immediately, and brings the ROS 2 logging system into alignment with most other logging systems. +It is possible to change the stream to stdout at runtime via the RCUTILS_LOGGING_USE_STDOUT environment variable, but all logging messages will still go to the same stream. +See `https://github.com/ros2/rcutils/pull/196 `_ for more details. + +launch_ros +^^^^^^^^^^ + +Node name and namespace parameters changed +"""""""""""""""""""""""""""""""""""""""""" + +The ``Node`` action parameters related to naming have been changed: + +- ``node_name`` has been renamed to ``name`` +- ``node_namespace`` has been renamed to ``namespace`` +- ``node_executable`` has been renamed to ``executable`` +- ``exec_name`` has been added for naming the process associated with the node. + Previously, users would have used the ``name`` keyword argument. + +The old parameters have been deprecated. + +These changes were made to make the launch frontend more idiomatic. +For example, instead of + +.. code-block:: xml + + + +we can now write + +.. code-block:: xml + + + +This change also applies to ``ComposableNodeContainer``, ``ComposableNode``, and ``LifecycleNode``. +For examples, see the `relevant changes to the demos. `_ + +`Related pull request in launch_ros. `_ + +rclcpp +^^^^^^ + +Change in Advanced Subscription Callback Signature +"""""""""""""""""""""""""""""""""""""""""""""""""" + +With the pull request `https://github.com/ros2/rclcpp/pull/1047 `_ the signature of callbacks which receive the message info with the message has changed. +Previously it used the ``rmw`` type ``rmw_message_info_t``, but now uses the ``rclcpp`` type ``rclcpp::MessageInfo``. +The required changes are straightforward, and can be seen demonstrated in these pull requests: + +- `https://github.com/ros2/system_tests/pull/423/files `_ +- `https://github.com/ros2/rosbag2/pull/375/files `_ +- `https://github.com/ros2/ros1_bridge/pull/253/files `_ + +Change in Serialized Message Callback Signature +""""""""""""""""""""""""""""""""""""""""""""""" + +The pull request `ros2/rclcpp#1081 `_ introduces a new signature of the callbacks for retrieving ROS messages in serialized form. +The previously used C-Struct `rcl_serialized_message_t `_ is being superseded by a C++ data type `rclcpp::SerializedMessage `_. + +The example nodes in ``demo_nodes_cpp``, namely ``talker_serialized_message`` as well as ``listener_serialized_message`` reflect these changes. + +Breaking change in Node Interface getters' signature +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +With pull request `ros2/rclcpp#1069 `_, the signature of node interface getters has been modified to return shared ownership of node interfaces (i.e. an ``std::shared_ptr``) instead of a non-owning raw pointer. +Required changes in downstream packages that relied on the previous signature are simple and straightforward: use the ``std::shared_ptr::get()`` method. + +Deprecate set_on_parameters_set_callback +"""""""""""""""""""""""""""""""""""""""" + +Instead, use the ``rclcpp::Node`` methods ``add_on_set_parameters_callback`` and ``remove_on_set_parameters_callback`` for adding and removing functions that are called when parameters are set. + +Related pull request: https://github.com/ros2/rclcpp/pull/1123 + +Breaking change in Publisher getter signature +"""""""""""""""""""""""""""""""""""""""""""""" + +With pull request `ros2/rclcpp#1119 `_, the signature of publisher handle getter has been modified to return shared ownership of the underlying rcl structure (i.e. an ``std::shared_ptr``) instead of a non-owning raw pointer. +This was necessary to fix a segfault in certain circumstances. +Required changes in downstream packages that relied on the previous signature are simple and straightforward: use the ``std::shared_ptr::get()`` method. + +rclcpp_action +^^^^^^^^^^^^^ + +Deprecate ClientGoalHandle::async_result() +"""""""""""""""""""""""""""""""""""""""""" + +Using this API, it is possible to run into a race condition causing an exception to be thrown. +Instead, prefer to use ``Client::async_get_result()``, which is safer. + +See `ros2/rclcpp#1120 `_ and the connected issue for more info. + +rclpy +^^^^^ + +Support for multiple on parameter set callbacks +""""""""""""""""""""""""""""""""""""""""""""""" + +Use the ``Node`` methods ``add_on_set_parameters_callback`` and ``remove_on_set_parameters_callback`` for adding and removing functions that are called when parameters are set. + +The method ``set_parameters_callback`` has been deprecated. + +Related pull requests: https://github.com/ros2/rclpy/pull/457, https://github.com/ros2/rclpy/pull/504 + +rmw_connext_cpp +^^^^^^^^^^^^^^^ + +Connext 5.1 locator kinds compatibility mode +"""""""""""""""""""""""""""""""""""""""""""" + +Up to and including ``Eloquent``, ``rmw_connext_cpp`` was setting ``dds.transport.use_510_compatible_locator_kinds`` property to ``true``. +This property is not being forced anymore, and shared transport communication between ``Foxy`` and previous releases will stop working. +Logs similar to: + +.. code-block:: bash + + PRESParticipant_checkTransportInfoMatching:Warning: discovered remote participant 'RTI Administration Console' using the 'shmem' transport with class ID 16777216. + This class ID does not match the class ID 2 of the same transport in the local participant 'talker'. + These two participants will not communicate over the 'shmem' transport. + Check the value of the property 'dds.transport.use_510_compatible_locator_kinds' in the local participant. + See https://community.rti.com/kb/what-causes-error-discovered-remote-participant for additional info. + +will be observed when this incompatibility happens. + +If compatibility is needed, it can be set up in an external QoS profiles files containing: + +.. code-block:: xml + + + + + + + dds.transport.use_510_compatible_locator_kinds + + 1 + + + + + +Remember to set the ``NDDS_QOS_PROFILES`` environment variable to the QoS profiles file path. +For more information, see ``How to Change Transport Settings in 5.2.0 Applications for Compatibility with 5.1.0`` section of `Transport_Compatibility `_. + +rviz +^^^^ + +Tools timestamp messages using ROS time +""""""""""""""""""""""""""""""""""""""" + +'2D Pose Estimate', '2D Nav Goal', and 'Publish Point' tools now timestamp their messages using ROS time instead of system time, in order for the ``use_sim_time`` parameter to have an effect on them. + +Related pull request: https://github.com/ros2/rviz/pull/519 + +std_msgs +^^^^^^^^ + +Deprecation of messages +""""""""""""""""""""""" + +Although discouraged for a long time we have officially deprecated the following messages in ``std_msgs``. +There are copies in `example_interfaces `_ + +- ``std_msgs/msg/Bool`` +- ``std_msgs/msg/Byte`` +- ``std_msgs/msg/ByteMultiArray`` +- ``std_msgs/msg/Char`` +- ``std_msgs/msg/Float32`` +- ``std_msgs/msg/Float32MultiArray`` +- ``std_msgs/msg/Float64`` +- ``std_msgs/msg/Float64MultiArray`` +- ``std_msgs/msg/Int16`` +- ``std_msgs/msg/Int16MultiArray`` +- ``std_msgs/msg/Int32`` +- ``std_msgs/msg/Int32MultiArray`` +- ``std_msgs/msg/Int64`` +- ``std_msgs/msg/Int64MultiArray`` +- ``std_msgs/msg/Int8`` +- ``std_msgs/msg/Int8MultiArray`` +- ``std_msgs/msg/MultiArrayDimension`` +- ``std_msgs/msg/MultiArrayLayout`` +- ``std_msgs/msg/String`` +- ``std_msgs/msg/UInt16`` +- ``std_msgs/msg/UInt16MultiArray`` +- ``std_msgs/msg/UInt32`` +- ``std_msgs/msg/UInt32MultiArray`` +- ``std_msgs/msg/UInt64`` +- ``std_msgs/msg/UInt64MultiArray`` +- ``std_msgs/msg/UInt8`` +- ``std_msgs/msg/UInt8MultiArray`` + +Security features +^^^^^^^^^^^^^^^^^ + +Use of security enclaves +"""""""""""""""""""""""" + +As of Foxy, domain participants are no longer mapped directly to ROS nodes. +As a result, ROS 2 security features (which are specific to domain participants) are also no longer mapped directly to ROS nodes. +Instead, Foxy introduces the concept of a security "enclave", where an "enclave" is a process or group of processes that will share the same identity and access control rules. + +This means that security artifacts are **not** retrieved based on the node name anymore but based on the Security enclave name. +A node enclave name can be set by using the ROS argument ``--enclave``, e.g. ``ros2 run demo_nodes_py talker --ros-args --enclave /my_enclave`` + +Related design document: https://github.com/ros2/design/pull/274 + +Note that permissions files are limited by the underlying transport packet size, so grouping many permissions under the same enclave will **not** work if the resulting permissions file exceed 64kB. +Related issue `[ros2/sros2#228] `_ + +Renaming of the environment variables +""""""""""""""""""""""""""""""""""""" + +.. list-table:: Environment variables renaming + :widths: 25 25 + :header-rows: 1 + + * - Name in Eloquent + - Name in Foxy + * - ROS_SECURITY_ROOT_DIRECTORY + - ROS_SECURITY_KEYSTORE + * - ROS_SECURITY_NODE_DIRECTORY + - ROS_SECURITY_ENCLAVE_OVERRIDE + + +Known Issues +------------ + +* `[ros2/ros2#922] `_ Services' performance is flaky for ``rclcpp`` nodes using eProsima Fast-RTPS or ADLINK CycloneDDS as RMW implementation. + Specifically, service clients sometimes do not receive the response from servers. + +* `[ros2/rclcpp#1212] `_ Ready reentrant Waitable objects can attempt to execute multiple times. + + +Timeline before the release +--------------------------- + +A few milestones leading up to the release: + + .. note:: + + The dates below reflect an extension by roughly two weeks due to the coronavirus pandemic. + + Wed. April 22nd, 2020 + API and feature freeze for ``ros_core`` [1]_ packages. + Note that this includes ``rmw``, which is a recursive dependency of ``ros_core``. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 29th, 2020 (beta) + Updated releases of ``desktop`` [2]_ packages available. + Testing of the new features. + + Wed. May 27th, 2020 (release candidate) + Updated releases of ``desktop`` [2]_ packages available. + + Wed. June 3rd, 2020 + Freeze rosdistro. + No PRs for Foxy on the `rosdistro` repo will be merged (reopens after the release announcement). + +.. [1] The ``ros_core`` variant described in the `variants `_ repository. +.. [2] The ``desktop`` variant described in the `variants `_ repository. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Galactic-Geochelone.rst b/source/Get-Started/Releases/Release-Galactic-Geochelone.rst index 0be4ab4f7fa..02f6e1d0684 100644 --- a/source/Get-Started/Releases/Release-Galactic-Geochelone.rst +++ b/source/Get-Started/Releases/Release-Galactic-Geochelone.rst @@ -1,1126 +1,1130 @@ -.. _galactic-release: - -Galactic Geochelone (``galactic``) -================================== - -.. toctree:: - :hidden: - - Galactic-Geochelone-Complete-Changelog - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Galactic Geochelone* is the seventh release of ROS 2. -What follows is highlights of the important changes and features in Galactic Geochelone since the last release. -For a list of all of the changes since Foxy, see the `long form changelog `. - -Supported Platforms -------------------- - -Galactic Geochelone supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 20.04 (Focal): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019): ``amd64`` - -Tier 2 platforms: - -* RHEL 8: ``amd64`` - -Tier 3 platforms: - -* Ubuntu 20.04 (Focal): ``arm32`` -* Debian Bullseye (11): ``amd64``, ``arm64`` and ``arm32`` -* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``arm64`` -* Mac macOS 10.14 (Mojave): ``amd64`` - -Targeted platforms: - -+--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ -| Architecture | Ubuntu Focal | Windows 10 | RHEL 8 | macOS | Debian Bullseye | OpenEmbedded / | -| | (20.04) | (VS2019) | | | (11) | webOS OSE | -+==============+==================+==============+==================+===========+=================+=================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s]| Tier 2 [d][a][s] | Tier 3 [s]| Tier 3 [s] | | -+--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ -| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ -| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ - - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be -provided for this platform for packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Galactic ROS 2 repos file[^10]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+-------------------------+---------------+----------------------------+------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=========================+===============+============================+==============================+ -| rmw_cyclonedds_cpp* | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+------------------------------+ -| rmw_fastrtps_cpp | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+------------------------------+ -| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except | -| | | | | arm64 | -+--------------------------+-------------------------+---------------+----------------------------+------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except | -| | | | | arm32 | -+--------------------------+-------------------------+---------------+----------------------------+------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++17 -- Python 3.6 - -Dependency Requirements: - -+------------+----------------------------+--------------------------------------------------------------------------------+ -| | Required Support | Recommended Support | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Package | Ubuntu Focal| Windows 10** | RHEL 8 | macOS** | Debian Bullseye | OpenEmbedded** | -+============+=============+==============+==========+==========+=================+========================================+ -| CMake | 3.16.3 | 3.19.1 | 3.18.2 | 3.14.4 | 3.18.4 | 3.16.1 / 3.12.2**** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| EmPY | 3.3.2 | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Gazebo | 11.0.0* | N/A | N/A | 11.0.0 | 11.0.0* | N/A | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Ignition | Edifice* | N/A | N/A | Edifice* | Edifice* | N/A | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Ogre | 1.10* | N/A | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| OpenCV | 4.2.0 | 3.4.6* | 3.4.6 | 4.2.0 | 4.5.1 | 4.1.0 / 3.2.0**** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| OpenSSL | 1.1.1d | 1.1.1i | 1.1.1g | 1.1.1f | 1.1.1i | 1.1.1d / 1.1.1b**** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Python | 3.8.0 | 3.8.3 | 3.6.8 | 3.8.2 | 3.9.1 | 3.8.2 / 3.7.5**** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Qt | 5.12.5 | 5.12.10 | 5.12.5 | 5.12.3 | 5.15.2 | 5.14.1 / 5.12.5**** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| | **Linux only** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| PCL | 1.10.0 | N/A | 1.11.1 | N/A | 1.11.1 | 1.10.0 | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| **RMW DDS Middleware Providers** | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Cyclone DDS| 0.8.x (Réplique) | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Fast-DDS | 2.3.x | -+------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ -| Connext DDS| 5.3.1 | N/A | 5.3.1 | N/A | -+------------+----------------------------+----------+----------+----------------------------------------------------------+ -| Gurum DDS | 2.7.x | N/A | -+------------+----------------------------+--------------------------------------------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" Rolling distributions will see multiple version changes of -these dependencies during their lifetime. The versions shown for -OpenEmbedded are those provided by the 3.1 Dunfell release series; the -versions provided by the other supported release series are listed here: - . -Note that the OpenEmbedded releases series for which a ROS distro has -support will change during its support time frame, as per the -OpenEmbedded support policy shown here: - -. However, it will always be supported by least one stable OpenEmbedded -release series. - -\" \*\*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- Windows: Chocolatey, pip -- macOS: Homebrew, pip -- RHEL: dnf -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Galactic Geochelone <../../galactic/Installation.html>`__ - -New features in this ROS 2 release ----------------------------------- - -Ability to specify per-logger log levels -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to specify different logging levels for different loggers on the command line: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --log-level WARN --log-level talker:=DEBUG - -The above command sets a global log level of WARN, but sets the log level of the talker node messages to DEBUG. -The ``--log-level`` command-line option can be passed an arbitrary number of times to set different log levels for each logger. - -Ability to configure logging directory through environment variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to configure the logging directory through two environment variables: ``ROS_LOG_DIR`` and ``ROS_HOME``. -The logic is as follows: - -* Use ``$ROS_LOG_DIR`` if ``ROS_LOG_DIR`` is set and not empty. -* Otherwise, use ``$ROS_HOME/log``, using ``~/.ros`` for ``ROS_HOME`` if not set or if empty. - -Thus the default value stays the same: ``~/.ros/log``. - -Related PRs: `ros2/rcl_logging#53 `_ and `ros2/launch#460 `_. - -For example: - -.. code-block:: bash - - ROS_LOG_DIR=/tmp/foo ros2 run demo_nodes_cpp talker - -Will place all logs in ``/tmp/foo``. - -.. code-block:: bash - - ROS_HOME=/path/to/home ros2 run demo_nodes_cpp talker - -Will place all logs in ``/path/to/home/log``. - -Ability to invoke ``rosidl`` pipeline outside CMake -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now straightforward to invoke the ``rosidl`` interface generation pipeline outside CMake. -Source code generators and interface definition translators are accessible through a unified command line interface. - -For example, given a ``Demo`` message in some ``demo`` package like: - -.. code-block:: console - - $ mkdir -p demo/msg - $ cd demo - $ cat << EOF > msg/Demo.msg - std_msgs/Header header - geometry_msgs/Twist twist - geometry_msgs/Accel accel - EOF - -it is easy to generate C, C++, and Python support source code: - -.. code-block:: console - - $ rosidl generate -o gen -t c -t cpp -t py -I$(ros2 pkg prefix --share std_msgs)/.. \ - -I$(ros2 pkg prefix --share geometry_msgs)/.. demo msg/Demo.msg - -Generated source code will be put in the ``gen`` directory. - -One may also translate the message definition to a different format for a third-party code generation tool to consume: - -.. code-block:: console - - $ rosidl translate -o gen --to idl -I$(ros2 pkg prefix --share std_msgs)/.. \ - -I$(ros2 pkg prefix --share geometry_msgs)/.. demo msg/Demo.msg - -The translated message definition will be put in the ``gen`` directory. - -Note that these tools generate sources but do not build it -- that responsibility is still on the caller. -This is a first step towards enabling ``rosidl`` interface generation in build systems other than CMake. -See the `design document `_ for further reference and next steps. - -Externally configure QoS at start-up -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to externally configure the QoS settings for a node at start-up time. -QoS settings are **not** configurable during runtime; they are only configurable at start-up. -Node authors must opt-in to enable changing QoS settings at start-up. -If the feature is enabled on a node, then QoS settings can be set with ROS parameters when a node first starts. - -`Demos in C++ and Python can be found here. `_ - -See the `design document for more details `_. - -Note, user code handling parameter changes with registered callbacks should avoid rejecting updates for unknown parameters. -It was considered bad practice prior to Galactic, but with externally configurable QoS enabled it will result in a hard failure. - -Related PRs: `ros2/rclcpp#1408 `_ and `ros2/rclpy#635 `_ - -Python point_cloud2 utilities available -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Several utilities for interacting with `PointCloud2 messages `__ in Python were `ported to ROS 2 `__. -These utilities allow one to get a list of points from a PointCloud2 message (``read_points`` and ``read_points_list``), and to create a PointCloud2 message from a list of points (``create_cloud`` and ``create_cloud_xyz32``). - -An example of creating PointCloud 2 message, then reading it back: - -.. code-block:: python - - import sensor_msgs_py.point_cloud2 - from std_msgs.msg import Header - - pointlist = [[0.0, 0.1, 0.2]] - - pointcloud = sensor_msgs_py.point_cloud2.create_cloud_xyz32(Header(frame_id='frame'), pointlist) - - for point in sensor_msgs_py.point_cloud2.read_points(pointcloud): - print(point) - -RViz2 Time Panel -^^^^^^^^^^^^^^^^ - -The Rviz2 Time Panel, which shows the current Wall and ROS time, along with the elapsed Wall and ROS time, has been `ported to RViz2 `__. -To enable the Time Panel, click on Panels -> Add New Panel, and select "Time". -A panel that looks like the following will appear: - -.. image:: rviz2-time-panel-2021-05-17.png - -ros2 topic echo can print serialized data -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -When debugging middleware issues, it can be useful to see the raw serialized data that the RMW is sending. -The `--raw command-line flag `__ was added to ``ros2 topic echo`` to show this data. -To see this in action, run the following commands. - -Terminal 1: - -.. code-block:: console - - $ ros2 topic pub /chatter std_msgs/msg/String "data: 'hello'" - -Terminal 2: - -.. code-block:: console - - $ ros2 topic echo --raw /chatter - b'\x00\x01\x00\x00\x06\x00\x00\x00hello\x00\x00\x00' - --- - -Get the YAML representation of messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to get a YAML representation of all messages in C++ using the `to_yaml `__ function. -An example of code that prints out the YAML representation: - -.. code-block:: c++ - - #include - - #include - - int main() - { - std_msgs::msg::String msg; - msg.data = "hello world"; - printf("%s", rosidl_generator_traits::to_yaml(msg).c_str()); - return 0; - } - -Ability to load parameter files at runtime through the ros2 command -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 has long had the ability to specify parameter values at startup (through command-line arguments or a YAML file), and to dump current parameters out to a file (through ``ros2 param dump``). -Galactic adds the ability to `load parameter values at runtime `__ from a YAML file using the ``ros2 param load`` verb. -For example: - -Terminal 1: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp parameter_blackboard - -Terminal 2: - -.. code-block:: console - - $ ros2 param set /parameter_blackboard foo bar # sets 'foo' parameter to value 'bar' - $ ros2 param dump /parameter_blackboard # dumps current value of parameters to ./parameter_blackboard.yaml - $ ros2 param set /parameter_blackboard foo different # sets 'foo' parameter to value 'different' - $ ros2 param load /parameter_blackboard ./parameter_blackboard.yaml # reloads previous state of parameters, 'foo' is back to 'bar' - -Tools to check for QoS incompatibilities -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Built on top of new QoS compatibility check APIs, ``ros2doctor`` and ``rqt_graph`` can now detect and report QoS incompatibilities between publishers and subscriptions. - -Given a publisher and a subscription with `incompatible QoS settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>`: - -Terminal 1: - -.. code-block:: console - - $ ros2 run demo_nodes_py talker_qos -n 1000 # i.e. best_effort publisher - -Terminal 2: - -.. code-block:: console - - $ ros2 run demo_nodes_py listener_qos --reliable -n 1000 # i.e. reliable subscription - -``ros2doctor`` reports: - -.. code-block:: console - - $ ros2 doctor --report - ~ ... - QOS COMPATIBILITY LIST - topic [type] : /chatter [std_msgs/msg/String] - publisher node : talker_qos - subscriber node : listener_qos - compatibility status : ERROR: Best effort publisher and reliable subscription; - ~ ... - -while ``rqt_graph`` shows: - -.. image:: images/rqt_graph-qos-incompatibility-2021-05-17.png - -Related PRs: `ros2/ros2cli#621 `_, `ros-visualization/rqt_graph#61 `_ - -Use launch substitutions in parameter files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Just like ``rosparam`` tags in ROS 1 ``roslaunch``, ``launch_ros`` can now evaluate substitutions in parameter files. - -For example, given some ``parameter_file_with_substitutions.yaml`` like the following: - -.. code-block:: yaml - - /**: - ros__parameters: - launch_date: $(command date) - -Set ``allow_substs`` to ``True`` to get substitutions evaluated upon ``Node`` launch: - -.. code-block:: python - - import launch - import launch_ros.parameter_descriptions - import launch_ros.actions - - def generate_launch_description(): - return launch.LaunchDescription([ - launch_ros.actions.Node( - package='demo_nodes_cpp', - executable='parameter_blackboard', - parameters=[ - launch_ros.parameter_descriptions.ParameterFile( - param_file='parameter_file_with_substitutions.yaml', - allow_substs=True) - ] - ) - ]) - -XML launch files also support this. - -.. code-block:: xml - - - - - - - -Related PR: `ros2/launch_ros#168 `_ - -Support for unique network flows -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Applications may now require UDP/TCP and IP-based RMW implementations to provide unique *network flows* (i.e. unique `Differentiated Services Code Points `_ and/or unique `IPv6 Flow Labels `_ and/or unique ports in IP packet headers) for publishers and subscriptions, enabling QoS specifications for these IP streams in network architectures that support such a feature, like 5G networks. - -To see this in action, you may run these C++ examples (to be found in the `ros2/examples `__ repository): - -Terminal 1: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_publisher publisher_member_function_with_unique_network_flow_endpoints - - -Terminal 2: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function_with_unique_network_flow_endpoints - - -See the `Unique Network Flows design document `_ for further reference. - -Rosbag2 New Features -^^^^^^^^^^^^^^^^^^^^ - -Split recording by time -""""""""""""""""""""""" - -In Foxy, you could only split bags as they were recording by the size of the bag, now you can also split by the elapsed time. -The following command will split bagfiles into 100-second chunks. - -.. code-block:: console - - $ ros2 bag record --all --max-bag-duration 100 - -ros2 bag list -""""""""""""" - -This new command lists installed plugins of various types that rosbag2 uses. - -.. code-block:: console - - $ ros2 bag list storage - rosbag2_v2 - sqlite3 - - $ ros2 bag list converter - rosbag_v2_converter - - -Compression implementation is a plugin -"""""""""""""""""""""""""""""""""""""" - -In Foxy, rosbag2 compression was hardcoded with a Zstd library implementation. -This has been rearchitected so that compression implementations are a plugin, and can be swapped out without modifying the core rosbag2 codebase. -The default plugin that ships with ``ros-galactic-rosbag2`` is still the Zstd plugin - but now more can be released and used, and by selectively installing packages Zstd could be excluded from an installation. - - -Compress per-message -"""""""""""""""""""" - -In Foxy, you could automatically compress each rosbag file as it was split (per-file compression), but now you can also specify per-message compression. - -.. code-block:: console - - $ ros2 bag record --all --compression-format zstd --compression-mode message - - -Rosbag2 Python API -""""""""""""""""""""" - -A new package ``rosbag2_py`` has been released in Galactic, which provides a Python API. -This package is a ``pybind11`` binding around the C++ API. -As of the initial Galactic release, it does not yet expose all functionality available via the ``rosbag2_cpp`` API, but it is the sole connection for the ``ros2 bag`` CLI tool, so a good deal of functionality is available. - - -performance testing package and performance improvements -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -A thorough performance analysis project was performed on rosbag2 since the Foxy release. -The full initial report is available at https://github.com/ros2/rosbag2/blob/galactic/rosbag2_performance/rosbag2_performance_benchmarking/docs/rosbag2_performance_improvements.pdf . -The package ``rosbag2_performance_benchmarking`` provides tools to run performance analyses, especially on recording, which helps us maintain and improve the performance of rosbag2. - -Following this report, key work was done do improve the performance to a much more usable state for actual robot workflows. -To highlight a key metric - in a high bandwidth stress test (200Mbps), the Foxy release dropped up to 70% of messages, whereas the Galactic version was approximately 100% retention. -Please see the linked report for more details. - -``--regex`` and ``--exclude`` options for topic selection -""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The new recording options ``--regex`` and ``--exclude`` allow for fine-tuning the topics recorded in a bag, without having to explicitly list all topics. -These options may be used together or separately, and in conjunction with ``--all`` - -The following command will record only topics with "scan" in the name. - -.. code-block:: console - - $ ros2 bag record --regex "*scan*" - -The following command will record all topics except for ones in ``/my_namespace/`` - -.. code-block:: console - - $ ros2 bag record --all --exclude "/my_namespace/*" - - -``ros2 bag reindex`` -"""""""""""""""""""" - -ROS 2 bags are represented by a directory, instead of a single file. -This directory contains a ``metadata.yaml`` file, and one or more bag files. -When the ``metadata.yaml`` file is lost or missing, ``ros2 bag reindex $bag_dir`` will attempt to reconstruct it by reading all the bag files in the directory. - -Playback time control -""""""""""""""""""""" - -New controls have been added for rosbag2 playback - pause & resume, change rate, and play-next. -As of the Galactic release, these controls are exposed only as services on the rosbag2 player node. -Development is in progress to expose them to keyboard controls as well in ``ros2 bag play``, but until then a user application with buttons or keyboard controls may be trivially implemented to call these services. - -In one shell: - -.. code-block:: console - - $ ros2 bag play my_bag - -In another shell: - -.. code-block:: console - - $ ros2 service list -t - /rosbag2_player/get_rate [rosbag2_interfaces/srv/GetRate] - /rosbag2_player/is_paused [rosbag2_interfaces/srv/IsPaused] - /rosbag2_player/pause [rosbag2_interfaces/srv/Pause] - /rosbag2_player/play_next [rosbag2_interfaces/srv/PlayNext] - /rosbag2_player/resume [rosbag2_interfaces/srv/Resume] - /rosbag2_player/set_rate [rosbag2_interfaces/srv/SetRate] - /rosbag2_player/toggle_paused [rosbag2_interfaces/srv/TogglePaused] - - $ ros2 service call /rosbag2_player/is_paused rosbag2_interfaces/IsPaused - -To pause playback: - -.. code-block:: console - - $ ros2 service call /rosbag2_player/pause rosbag2_interfaces/Pause - -To resume playback: - -.. code-block:: console - - $ ros2 service call /rosbag2_player/resume rosbag2_interfaces/Resume - -To change the paused state of playback to its opposite. -If playing, pauses. -If paused, resumes. - -.. code-block:: console - - $ ros2 service call /rosbag2_player/toggle_paused rosbag2_interfaces/TogglePaused - -To get the current playback rate: - -.. code-block:: console - - $ ros2 service call /rosbag2_player/get_rate - -To set the current playback rate (must be > 0): - -.. code-block:: console - - $ ros2 service call /rosbag2_player/set_rate rosbag2_interfaces/SetRate "rate: 0.1" - -To play a single next message (only works while paused): - -.. code-block:: console - - $ ros2 service call /rosbag2_player/play_next rosbag2_interfaces/PlayNext - - -Playback publishes /clock -""""""""""""""""""""""""" - -Rosbag2 can also dictate "simulation time" by publishing to the ``/clock`` topic during playback. -The following commands will publish the clock message at a regular interval. - -To publish at the default rate of 40Hz: - -.. code-block:: console - - $ ros2 bag play my_bag --clock - - -To publish at a specific rate, e.g., 100Hz: - -.. code-block:: console - - $ ros2 bag play my_bag --clock 100 - -Changes since the Foxy release ------------------------------- - -Default RMW changed to Eclipse Cyclone DDS -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -During the Galactic development process, the ROS 2 Technical Steering Committee `voted `__ to change the default ROS middleware (RMW) to `Eclipse Cyclone DDS `__ project of `Eclipse Foundation `__. -Without any configuration changes, users will get Eclipse Cyclone DDS by default. -Fast DDS and Connext are still Tier-1 supported RMW vendors, and users can opt-in to use one of these RMWs at their discretion by using the ``RMW_IMPLEMENTATION`` environment variable. -See the `Working with multiple RMW implementations guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` for more information. - -Connext RMW changed to rmw_connextdds -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A new RMW for Connext called `rmw_connextdds `_ was merged for Galactic. -This RMW has better performance and fixes many of the issues with the older RMW ``rmw_connext_cpp``. - -Large improvements in testing and overall quality -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Galactic contains many changes that fix race conditions, plug memory leaks, and fix user reported problems. -Besides these changes, there was a concerted effort during Galactic development to improve overall quality of the system by implementing `REP 2004 `__. -The ``rclcpp`` package and all of its dependencies (which include most of the ROS 2 non-Python core packages) were brought up to `Quality Level 1 `__ by: - -* Having a version policy (QL1 requirement 1) -* Having a documented change control process (QL1 requirement 2) -* Documenting all features and public APIs (QL1 requirement 3) -* Adding many additional tests (QL1 requirement 4): - - * System tests for all features - * Unit tests for all public APIs - * Nightly performance tests - * Code coverage at 95% - -* Having all runtime dependencies of packages be at least as high as the package (QL1 requirement 5) -* Supporting all of the REP-2000 platforms (QL1 requirement 6) -* Having a vulnerability disclosure policy (QL1 requirement 7) - -rmw -^^^ - -New API for checking QoS profile compatibility -"""""""""""""""""""""""""""""""""""""""""""""" - -``rmw_qos_profile_check_compatible`` is a new function for checking the compatibility of two QoS profiles. - -RMW vendors should implement this API for QoS debugging and introspection features in tools such as ``rqt_graph`` to work correctly. - -Related PR: `ros2/rmw#299 `_ - -ament_cmake -^^^^^^^^^^^ - -``ament_install_python_package()`` now installs a Python egg -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -By installing a flat Python egg, Python packages installed using ``ament_install_python_package()`` can be discovered using modules such as ``pkg_resources`` and ```importlib.metadata``. Also, additional metadata can be provided in a ``setup.cfg`` file (including entry points). - -Related PR: `ament/ament_cmake#326 `_ - -``ament_target_dependencies()`` handles SYSTEM dependencies -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Some package dependencies can now be marked as SYSTEM dependencies, helping to cope with warnings in external code. Typically, SYSTEM dependencies are also excluded from dependency calculations -- use them with care. - -Related PR: `ament/ament_cmake#297 `_ - -nav2 -^^^^ - -Changes include, but are not limited to, a number of stability improvements, new plugins, interface changes, costmap filters. -See `Migration Guides `_ for full list - -tf2_ros Python split out of tf2_ros -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Python code that used to live in tf2_ros has been moved into its own package named tf2_ros_py. -Any existing Python code that depends on tf2_ros will continue to work, but the package.xml of those packages should be amended to ``exec_depend`` on tf2_ros_py. - -tf2_ros Python TransformListener uses global namespace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The Python ``TransformListener`` now subscribes to ``/tf`` and ``/tf_static`` in the global namespace. -Previously, it was susbcribing in the node's namespace. -This means that the node's namespace will no longer have an effect on the ``/tf`` and ``/tf_static`` subscriptions. - -For example: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo --ros-args -r __ns:=/test -- odom base_link - -will subscribe to ``/tf`` and ``/tf_static``, as ``ros2 topic list`` will show. - -Related PR: `ros2/geometry2#390 `_ - -rclcpp -^^^^^^ - -Change in spin_until_future_complete template parameters -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The first template parameter of ``Executor::spin_until_future_complete`` was the future result type ``ResultT``, and the method only accepted a ``std::shared_future``. -In order to accept other types of futures (e.g.: ``std::future``), that parameter was changed to the future type itself. - -In places where a ``spin_until_future_complete`` call was relying on template argument deduction, no change is needed. -If not, this is an example diff: - -.. code-block:: dpatch - - std::shared_future future; - ... - -executor.spin_until_future_complete(future); - +executor.spin_until_future_complete>(future); - - -For more details, see `ros2/rclcpp#1160 `_. -For an example of the needed changes in user code, see `ros-visualization/interactive_markers#72 `_. - -Change in default ``/clock`` subscription QoS profile -""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The default was changed from a reliable communication with history depth 10 to a best effort communication with history depth 1. -See `ros2/rclcpp#1312 `_. - -Waitable API -"""""""""""" - -Waitable API was modified to avoid issues with the ``MultiThreadedExecutor``. -This only affects users implementing a custom waitable. -See `ros2/rclcpp#1241 `_ for more details. - -Change in ``rclcpp``'s logging macros -""""""""""""""""""""""""""""""""""""" -Previously, the logging macros were vulnerable to a `format string attack `_, where the format string is evaluated and can potentially execute code, read the stack, or cause a segmentation fault in the running program. -To address this security issue, the logging macro now accepts only string literals for it's format string argument. - -If you previously had code like: - -.. code-block:: - - const char *my_const_char_string format = "Foo"; - RCLCPP_DEBUG(get_logger(), my_const_char_string); - -you should now replace it with: - -.. code-block:: - - const char *my_const_char_string format = "Foo"; - RCLCPP_DEBUG(get_logger(), "%s", my_const_char_string); - -or: - -.. code-block:: - - RCLCPP_DEBUG(get_logger(), "Foo"); - - -This change removes some convenience from the logging macros, as ``std::string``\s are no longer accepted as the format argument. - - -If you previously had code with no format arguments like: - -.. code-block:: - - std::string my_std_string = "Foo"; - RCLCPP_DEBUG(get_logger(), my_std_string); - -you should now replace it with: - -.. code-block:: - - std::string my_std_string = "Foo"; - RCLCPP_DEBUG(get_logger(), "%s", my_std_string.c_str()); - -.. note:: - If you are using a ``std::string`` as a format string with format arguments, converting that string to a ``char *`` and using it as the format string will yield a format security warning. That's because the compiler has no way at compile to introspect into the ``std::string`` to verify the arguments. To avoid the security warning, we recommend you build the string manually and pass it in with no format arguments like the previous example. - -``std::stringstream`` types are still accepted as arguments to the stream logging macros. -See `ros2/rclcpp#1442 `_ for more details. - -Parameter types are now static by default -""""""""""""""""""""""""""""""""""""""""" - -Previously, the type of a parameter could be changed when a parameter was set. -For example, if a parameter was declared as an integer, a later call to set the parameter could change that type to a string. -This behavior could lead to bugs, and is rarely what the user wants. -As of Galactic parameter types are static by default, and attempts to change the type will fail. -If the previous dynamic behavior is desired, there is an mechanism to opt it in (see the code below). - -.. code-block:: cpp - - // declare integer parameter with default value, trying to set it to a different type will fail. - node->declare_parameter("my_int", 5); - // declare string parameter with no default and mandatory user provided override. - // i.e. the user must pass a parameter file setting it or a command line rule -p := - node->declare_parameter("string_mandatory_override", rclcpp::PARAMETER_STRING); - // Conditionally declare a floating point parameter with a mandatory override. - // Useful when the parameter is only needed depending on other conditions and no default is reasonable. - if (mode == "modeA") { - node->declare_parameter("conditionally_declare_double_parameter", rclcpp::PARAMETER_DOUBLE); - } - // You can also get the old dynamic typing behavior if you want: - rcl_interfaces::msg::ParameterDescriptor descriptor; - descriptor.dynamic_typing = true; - node->declare_parameter("dynamically_typed_param", rclcpp::ParameterValue{}, descriptor); - -For more details see https://github.com/ros2/rclcpp/blob/galactic/rclcpp/doc/notes_on_statically_typed_parameters.md. - -New API for checking QoS profile compatibility -"""""""""""""""""""""""""""""""""""""""""""""" - -``qos_check_compatible`` is a new function for checking the compatibility of two QoS profiles. - -Related PR: `ros2/rclcpp#1554 `_ - -rclpy -^^^^^ - -Removal of deprecated Node.set_parameters_callback -"""""""""""""""""""""""""""""""""""""""""""""""""" - -The method ``Node.set_parameters_callback`` was `deprecated in ROS Foxy `_ and has been `removed in ROS Galactic `_. -Use ``Node.add_on_set_parameters_callback()`` instead. -Here is some example code using it. - -.. code-block:: python - - import rclpy - import rclpy.node - from rcl_interfaces.msg import ParameterType - from rcl_interfaces.msg import SetParametersResult - - - rclpy.init() - node = rclpy.node.Node('callback_example') - node.declare_parameter('my_param', 'initial value') - - - def on_parameter_event(parameter_list): - for parameter in parameter_list: - node.get_logger().info(f'Got {parameter.name}={parameter.value}') - return SetParametersResult(successful=True) - - - node.add_on_set_parameters_callback(on_parameter_event) - rclpy.spin(node) - -Run this command to see the parameter callback in action. - -.. code-block:: - - ros2 param set /callback_example my_param "Hello World" - -Parameter types are now static by default -""""""""""""""""""""""""""""""""""""""""" - -In Foxy and earlier a call to set a parameter could change its type. -As of Galactic parameter types are static and cannot be changed by default. -If the previous behavior is desired, then set ``dynamic_typing`` to true in the parameter descriptor. -Here is an example. - -.. code-block:: python - - import rclpy - import rclpy.node - from rcl_interfaces.msg import ParameterDescriptor - - rclpy.init() - node = rclpy.node.Node('static_param_example') - node.declare_parameter('static_param', 'initial value') - node.declare_parameter('dynamic_param', 'initial value', descriptor=ParameterDescriptor(dynamic_typing=True)) - rclpy.spin(node) - -Run these commands to see how statically and dynamically typed parameters are different. - -.. code-block:: console - - $ ros2 param set /static_param_example dynamic_param 42 - Set parameter successful - $ ros2 param set /static_param_example static_param 42 - Setting parameter failed: Wrong parameter type, expected 'Type.STRING' got 'Type.INTEGER' - -For more details see https://github.com/ros2/rclcpp/blob/galactic/rclcpp/doc/notes_on_statically_typed_parameters.md. - -New API for checking QoS profile compatibility -"""""""""""""""""""""""""""""""""""""""""""""" - -``rclpy.qos.qos_check_compatible`` is `a new function `_ for checking the compatibility of two QoS profiles. -If the profiles are compatible, then a publisher and subscriber using them will be able to talk to each other. - -.. code-block:: python - - import rclpy.qos - - publisher_profile = rclpy.qos.qos_profile_sensor_data - subscription_profile = rclpy.qos.qos_profile_parameter_events - - print(rclpy.qos.qos_check_compatible(publisher_profile, subscription_profile)) - -.. code-block:: console - - $ python3 qos_check_compatible_example.py - (QoSCompatibility.ERROR, 'ERROR: Best effort publisher and reliable subscription;') - -rclcpp_action -^^^^^^^^^^^^^ - -Action client goal response callback signature changed -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The goal response callback should now take a shared pointer to a goal handle, instead of a future. - -For `example `_, old signature: - -.. code-block:: c++ - - void goal_response_callback(std::shared_future future) - -New signature: - -.. code-block:: c++ - - void goal_response_callback(GoalHandleFibonacci::SharedPtr goal_handle) - -Related PR: `ros2/rclcpp#1311 `_ - -rosidl_typesupport_introspection_c -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -API break in function that gets an element from an array -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The signature of the function was changed because it was semantically different to all the other functions used to get an element from an array or sequence. -This only affects authors of rmw implementations using the introspection typesupport. - -For further details, see `ros2/rosidl#531 `_. - -rcl_lifecycle and rclcpp_lifecycle -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -RCL's lifecycle state machine gets new init API -""""""""""""""""""""""""""""""""""""""""""""""" - -The lifecycle state machine in rcl_lifecycle was modified to expect a newly introduced options struct, combining general configurations for the state machine. -The option struct allows to indicate whether the state machine shall be initialized with default values, whether its attached services are active and which allocator to be used. - -.. code-block:: c - - rcl_ret_t - rcl_lifecycle_state_machine_init( - rcl_lifecycle_state_machine_t * state_machine, - rcl_node_t * node_handle, - const rosidl_message_type_support_t * ts_pub_notify, - const rosidl_service_type_support_t * ts_srv_change_state, - const rosidl_service_type_support_t * ts_srv_get_state, - const rosidl_service_type_support_t * ts_srv_get_available_states, - const rosidl_service_type_support_t * ts_srv_get_available_transitions, - const rosidl_service_type_support_t * ts_srv_get_transition_graph, - const rcl_lifecycle_state_machine_options_t * state_machine_options); - -RCL's lifecycle state machine stores allocator instance -""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The options struct (discussed above) entails an instance of the allocator being used for initializing the state machine. -This options struct and there the embodied allocator are being stored within the lifecycle state machine. -As a direct consequence, the ``rcl_lifecycle_fini function`` no longer expects an allocator in its fini function but rather uses the allocator set in the options struct for deallocating its internal data structures. - -.. code-block:: c - - rcl_ret_t - rcl_lifecycle_state_machine_fini( - rcl_lifecycle_state_machine_t * state_machine, - rcl_node_t * node_handle); - -RCLCPP's lifecycle node exposes option to not instantiate services -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -In order to use rclcpp's lifecycle nodes without exposing its internal services such as ``change_state``, ``get_state`` et. al., the constructor of a lifecycle node has a newly introduced parameter indicating whether or not the services shall be available. -This boolean flag is set to true by default, not requiring any changes to existing API if not wished. - -.. code-block:: c++ - - explicit LifecycleNode( - const std::string & node_name, - const rclcpp::NodeOptions & options = rclcpp::NodeOptions(), - bool enable_communication_interface = true); - -Related PRs: `ros2/rcl#882 `_ and `ros2/rclcpp#1507 `_ - -rcl_lifecycle and rclcpp_lifecycle -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Recording - Split by time -""""""""""""""""""""""""""""""""""""""""""""""" - - - -Known Issues ------------- - -ros2cli -^^^^^^^ - -Daemon slows down CLI on Windows -"""""""""""""""""""""""""""""""" - -As a workaround, CLI commands may be used without a daemon e.g.: - -.. code-block:: console - - $ ros2 topic list --no-daemon - - -Issue is tracked by `ros2/ros2cli#637 `_. - -rqt -^^^ - -Some rqt_bag icons are missing -"""""""""""""""""""""""""""""" - -The icons to "Zoom In", "Zoom Out", "Zoom Home", and "Toggle Thumbnails" are missing in ``rqt_bag``. -The issue is tracked in `ros-visualization/rqt_bag#102 `_ - -Most rqt utilities don't work standalone on Windows -""""""""""""""""""""""""""""""""""""""""""""""""""" - -Launching the rqt utilities "standalone" on Windows (like ``ros2 run rqt_graph rqt_graph``) generally doesn't work. -The workaround is to launch the rqt container process (``rqt``), and then insert the plugins to be used. - -rviz2 -^^^^^ - -RViz2 panel close buttons are blank -""""""""""""""""""""""""""""""""""" - -The upper right-hand corner of every RViz2 panel should contain an "X" to allow one to close the panel. -Those buttons are there, but the "X" inside of them is missing on all platforms. -The issue is being tracked in `ros2/rviz2#692 `__. - -Timeline before the release ---------------------------- - - Mon. March 22, 2021 - Alpha - Preliminary testing and stabilization of ROS Core [1]_ packages. - - Mon. April 5, 2021 - Freeze - API and feature freeze for ROS Core [1]_ packages in Rolling Ridley. - Note that this includes ``rmw``, which is a recursive dependency of ``ros_core``. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 19, 2021 - Branch - Branch from Rolling Ridley. - ``rosdistro`` is reopened for Rolling PRs for ROS Core [1]_ packages. - Galactic development shifts from ``ros-rolling-*`` packages to ``ros-galactic-*`` packages. - - Mon. April 26, 2021 - Beta - Updated releases of ROS Desktop [2]_ packages available. - Call for general testing. - - Mon. May 17, 2021 - RC - Release Candidate packages are built. - Updated releases of ROS Desktop [2]_ packages available. - - Thu. May 20, 2021 - Distro Freeze - Freeze rosdistro. - No PRs for Galactic on the ``rosdistro`` repo will be merged (reopens after the release announcement). - - Sun. May 23, 2021 - General Availability - Release announcement. - ``rosdistro`` is reopened for Galactic PRs. - -.. [1] The ``ros_core`` variant is described in `REP 2001 (ros-core) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. +.. redirect-from:: + + Releases/Release-Galactic-Geochelone + +.. _galactic-release: + +Galactic Geochelone (``galactic``) +================================== + +.. toctree:: + :hidden: + + Galactic-Geochelone-Complete-Changelog + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Galactic Geochelone* is the seventh release of ROS 2. +What follows is highlights of the important changes and features in Galactic Geochelone since the last release. +For a list of all of the changes since Foxy, see the `long form changelog `. + +Supported Platforms +------------------- + +Galactic Geochelone supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 20.04 (Focal): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019): ``amd64`` + +Tier 2 platforms: + +* RHEL 8: ``amd64`` + +Tier 3 platforms: + +* Ubuntu 20.04 (Focal): ``arm32`` +* Debian Bullseye (11): ``amd64``, ``arm64`` and ``arm32`` +* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``arm64`` +* Mac macOS 10.14 (Mojave): ``amd64`` + +Targeted platforms: + ++--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ +| Architecture | Ubuntu Focal | Windows 10 | RHEL 8 | macOS | Debian Bullseye | OpenEmbedded / | +| | (20.04) | (VS2019) | | | (11) | webOS OSE | ++==============+==================+==============+==================+===========+=================+=================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s]| Tier 2 [d][a][s] | Tier 3 [s]| Tier 3 [s] | | ++--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ +| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ +| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+------------------+--------------+------------------+-----------+-----------------+-----------------+ + + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be +provided for this platform for packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Galactic ROS 2 repos file[^10]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+-------------------------+---------------+----------------------------+------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=========================+===============+============================+==============================+ +| rmw_cyclonedds_cpp* | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+------------------------------+ +| rmw_fastrtps_cpp | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+------------------------------+ +| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except | +| | | | | arm64 | ++--------------------------+-------------------------+---------------+----------------------------+------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except | +| | | | | arm32 | ++--------------------------+-------------------------+---------------+----------------------------+------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++17 +- Python 3.6 + +Dependency Requirements: + ++------------+----------------------------+--------------------------------------------------------------------------------+ +| | Required Support | Recommended Support | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Package | Ubuntu Focal| Windows 10** | RHEL 8 | macOS** | Debian Bullseye | OpenEmbedded** | ++============+=============+==============+==========+==========+=================+========================================+ +| CMake | 3.16.3 | 3.19.1 | 3.18.2 | 3.14.4 | 3.18.4 | 3.16.1 / 3.12.2**** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| EmPY | 3.3.2 | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Gazebo | 11.0.0* | N/A | N/A | 11.0.0 | 11.0.0* | N/A | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Ignition | Edifice* | N/A | N/A | Edifice* | Edifice* | N/A | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Ogre | 1.10* | N/A | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| OpenCV | 4.2.0 | 3.4.6* | 3.4.6 | 4.2.0 | 4.5.1 | 4.1.0 / 3.2.0**** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| OpenSSL | 1.1.1d | 1.1.1i | 1.1.1g | 1.1.1f | 1.1.1i | 1.1.1d / 1.1.1b**** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Python | 3.8.0 | 3.8.3 | 3.6.8 | 3.8.2 | 3.9.1 | 3.8.2 / 3.7.5**** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Qt | 5.12.5 | 5.12.10 | 5.12.5 | 5.12.3 | 5.15.2 | 5.14.1 / 5.12.5**** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| | **Linux only** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| PCL | 1.10.0 | N/A | 1.11.1 | N/A | 1.11.1 | 1.10.0 | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| **RMW DDS Middleware Providers** | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Cyclone DDS| 0.8.x (Réplique) | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Fast-DDS | 2.3.x | ++------------+-------------+--------------+----------+----------+-----------------+----------------------------------------+ +| Connext DDS| 5.3.1 | N/A | 5.3.1 | N/A | ++------------+----------------------------+----------+----------+----------------------------------------------------------+ +| Gurum DDS | 2.7.x | N/A | ++------------+----------------------------+--------------------------------------------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" Rolling distributions will see multiple version changes of +these dependencies during their lifetime. The versions shown for +OpenEmbedded are those provided by the 3.1 Dunfell release series; the +versions provided by the other supported release series are listed here: + . +Note that the OpenEmbedded releases series for which a ROS distro has +support will change during its support time frame, as per the +OpenEmbedded support policy shown here: + +. However, it will always be supported by least one stable OpenEmbedded +release series. + +\" \*\*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- Windows: Chocolatey, pip +- macOS: Homebrew, pip +- RHEL: dnf +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Galactic Geochelone <../../galactic/Installation.html>`__ + +New features in this ROS 2 release +---------------------------------- + +Ability to specify per-logger log levels +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to specify different logging levels for different loggers on the command line: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --log-level WARN --log-level talker:=DEBUG + +The above command sets a global log level of WARN, but sets the log level of the talker node messages to DEBUG. +The ``--log-level`` command-line option can be passed an arbitrary number of times to set different log levels for each logger. + +Ability to configure logging directory through environment variables +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to configure the logging directory through two environment variables: ``ROS_LOG_DIR`` and ``ROS_HOME``. +The logic is as follows: + +* Use ``$ROS_LOG_DIR`` if ``ROS_LOG_DIR`` is set and not empty. +* Otherwise, use ``$ROS_HOME/log``, using ``~/.ros`` for ``ROS_HOME`` if not set or if empty. + +Thus the default value stays the same: ``~/.ros/log``. + +Related PRs: `ros2/rcl_logging#53 `_ and `ros2/launch#460 `_. + +For example: + +.. code-block:: bash + + ROS_LOG_DIR=/tmp/foo ros2 run demo_nodes_cpp talker + +Will place all logs in ``/tmp/foo``. + +.. code-block:: bash + + ROS_HOME=/path/to/home ros2 run demo_nodes_cpp talker + +Will place all logs in ``/path/to/home/log``. + +Ability to invoke ``rosidl`` pipeline outside CMake +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now straightforward to invoke the ``rosidl`` interface generation pipeline outside CMake. +Source code generators and interface definition translators are accessible through a unified command line interface. + +For example, given a ``Demo`` message in some ``demo`` package like: + +.. code-block:: console + + $ mkdir -p demo/msg + $ cd demo + $ cat << EOF > msg/Demo.msg + std_msgs/Header header + geometry_msgs/Twist twist + geometry_msgs/Accel accel + EOF + +it is easy to generate C, C++, and Python support source code: + +.. code-block:: console + + $ rosidl generate -o gen -t c -t cpp -t py -I$(ros2 pkg prefix --share std_msgs)/.. \ + -I$(ros2 pkg prefix --share geometry_msgs)/.. demo msg/Demo.msg + +Generated source code will be put in the ``gen`` directory. + +One may also translate the message definition to a different format for a third-party code generation tool to consume: + +.. code-block:: console + + $ rosidl translate -o gen --to idl -I$(ros2 pkg prefix --share std_msgs)/.. \ + -I$(ros2 pkg prefix --share geometry_msgs)/.. demo msg/Demo.msg + +The translated message definition will be put in the ``gen`` directory. + +Note that these tools generate sources but do not build it -- that responsibility is still on the caller. +This is a first step towards enabling ``rosidl`` interface generation in build systems other than CMake. +See the `design document `_ for further reference and next steps. + +Externally configure QoS at start-up +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to externally configure the QoS settings for a node at start-up time. +QoS settings are **not** configurable during runtime; they are only configurable at start-up. +Node authors must opt-in to enable changing QoS settings at start-up. +If the feature is enabled on a node, then QoS settings can be set with ROS parameters when a node first starts. + +`Demos in C++ and Python can be found here. `_ + +See the `design document for more details `_. + +Note, user code handling parameter changes with registered callbacks should avoid rejecting updates for unknown parameters. +It was considered bad practice prior to Galactic, but with externally configurable QoS enabled it will result in a hard failure. + +Related PRs: `ros2/rclcpp#1408 `_ and `ros2/rclpy#635 `_ + +Python point_cloud2 utilities available +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Several utilities for interacting with `PointCloud2 messages `__ in Python were `ported to ROS 2 `__. +These utilities allow one to get a list of points from a PointCloud2 message (``read_points`` and ``read_points_list``), and to create a PointCloud2 message from a list of points (``create_cloud`` and ``create_cloud_xyz32``). + +An example of creating PointCloud 2 message, then reading it back: + +.. code-block:: python + + import sensor_msgs_py.point_cloud2 + from std_msgs.msg import Header + + pointlist = [[0.0, 0.1, 0.2]] + + pointcloud = sensor_msgs_py.point_cloud2.create_cloud_xyz32(Header(frame_id='frame'), pointlist) + + for point in sensor_msgs_py.point_cloud2.read_points(pointcloud): + print(point) + +RViz2 Time Panel +^^^^^^^^^^^^^^^^ + +The Rviz2 Time Panel, which shows the current Wall and ROS time, along with the elapsed Wall and ROS time, has been `ported to RViz2 `__. +To enable the Time Panel, click on Panels -> Add New Panel, and select "Time". +A panel that looks like the following will appear: + +.. image:: rviz2-time-panel-2021-05-17.png + +ros2 topic echo can print serialized data +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +When debugging middleware issues, it can be useful to see the raw serialized data that the RMW is sending. +The `--raw command-line flag `__ was added to ``ros2 topic echo`` to show this data. +To see this in action, run the following commands. + +Terminal 1: + +.. code-block:: console + + $ ros2 topic pub /chatter std_msgs/msg/String "data: 'hello'" + +Terminal 2: + +.. code-block:: console + + $ ros2 topic echo --raw /chatter + b'\x00\x01\x00\x00\x06\x00\x00\x00hello\x00\x00\x00' + --- + +Get the YAML representation of messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to get a YAML representation of all messages in C++ using the `to_yaml `__ function. +An example of code that prints out the YAML representation: + +.. code-block:: c++ + + #include + + #include + + int main() + { + std_msgs::msg::String msg; + msg.data = "hello world"; + printf("%s", rosidl_generator_traits::to_yaml(msg).c_str()); + return 0; + } + +Ability to load parameter files at runtime through the ros2 command +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 has long had the ability to specify parameter values at startup (through command-line arguments or a YAML file), and to dump current parameters out to a file (through ``ros2 param dump``). +Galactic adds the ability to `load parameter values at runtime `__ from a YAML file using the ``ros2 param load`` verb. +For example: + +Terminal 1: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp parameter_blackboard + +Terminal 2: + +.. code-block:: console + + $ ros2 param set /parameter_blackboard foo bar # sets 'foo' parameter to value 'bar' + $ ros2 param dump /parameter_blackboard # dumps current value of parameters to ./parameter_blackboard.yaml + $ ros2 param set /parameter_blackboard foo different # sets 'foo' parameter to value 'different' + $ ros2 param load /parameter_blackboard ./parameter_blackboard.yaml # reloads previous state of parameters, 'foo' is back to 'bar' + +Tools to check for QoS incompatibilities +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Built on top of new QoS compatibility check APIs, ``ros2doctor`` and ``rqt_graph`` can now detect and report QoS incompatibilities between publishers and subscriptions. + +Given a publisher and a subscription with `incompatible QoS settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>`: + +Terminal 1: + +.. code-block:: console + + $ ros2 run demo_nodes_py talker_qos -n 1000 # i.e. best_effort publisher + +Terminal 2: + +.. code-block:: console + + $ ros2 run demo_nodes_py listener_qos --reliable -n 1000 # i.e. reliable subscription + +``ros2doctor`` reports: + +.. code-block:: console + + $ ros2 doctor --report + ~ ... + QOS COMPATIBILITY LIST + topic [type] : /chatter [std_msgs/msg/String] + publisher node : talker_qos + subscriber node : listener_qos + compatibility status : ERROR: Best effort publisher and reliable subscription; + ~ ... + +while ``rqt_graph`` shows: + +.. image:: images/rqt_graph-qos-incompatibility-2021-05-17.png + +Related PRs: `ros2/ros2cli#621 `_, `ros-visualization/rqt_graph#61 `_ + +Use launch substitutions in parameter files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Just like ``rosparam`` tags in ROS 1 ``roslaunch``, ``launch_ros`` can now evaluate substitutions in parameter files. + +For example, given some ``parameter_file_with_substitutions.yaml`` like the following: + +.. code-block:: yaml + + /**: + ros__parameters: + launch_date: $(command date) + +Set ``allow_substs`` to ``True`` to get substitutions evaluated upon ``Node`` launch: + +.. code-block:: python + + import launch + import launch_ros.parameter_descriptions + import launch_ros.actions + + def generate_launch_description(): + return launch.LaunchDescription([ + launch_ros.actions.Node( + package='demo_nodes_cpp', + executable='parameter_blackboard', + parameters=[ + launch_ros.parameter_descriptions.ParameterFile( + param_file='parameter_file_with_substitutions.yaml', + allow_substs=True) + ] + ) + ]) + +XML launch files also support this. + +.. code-block:: xml + + + + + + + +Related PR: `ros2/launch_ros#168 `_ + +Support for unique network flows +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Applications may now require UDP/TCP and IP-based RMW implementations to provide unique *network flows* (i.e. unique `Differentiated Services Code Points `_ and/or unique `IPv6 Flow Labels `_ and/or unique ports in IP packet headers) for publishers and subscriptions, enabling QoS specifications for these IP streams in network architectures that support such a feature, like 5G networks. + +To see this in action, you may run these C++ examples (to be found in the `ros2/examples `__ repository): + +Terminal 1: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_publisher publisher_member_function_with_unique_network_flow_endpoints + + +Terminal 2: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function_with_unique_network_flow_endpoints + + +See the `Unique Network Flows design document `_ for further reference. + +Rosbag2 New Features +^^^^^^^^^^^^^^^^^^^^ + +Split recording by time +""""""""""""""""""""""" + +In Foxy, you could only split bags as they were recording by the size of the bag, now you can also split by the elapsed time. +The following command will split bagfiles into 100-second chunks. + +.. code-block:: console + + $ ros2 bag record --all --max-bag-duration 100 + +ros2 bag list +""""""""""""" + +This new command lists installed plugins of various types that rosbag2 uses. + +.. code-block:: console + + $ ros2 bag list storage + rosbag2_v2 + sqlite3 + + $ ros2 bag list converter + rosbag_v2_converter + + +Compression implementation is a plugin +"""""""""""""""""""""""""""""""""""""" + +In Foxy, rosbag2 compression was hardcoded with a Zstd library implementation. +This has been rearchitected so that compression implementations are a plugin, and can be swapped out without modifying the core rosbag2 codebase. +The default plugin that ships with ``ros-galactic-rosbag2`` is still the Zstd plugin - but now more can be released and used, and by selectively installing packages Zstd could be excluded from an installation. + + +Compress per-message +"""""""""""""""""""" + +In Foxy, you could automatically compress each rosbag file as it was split (per-file compression), but now you can also specify per-message compression. + +.. code-block:: console + + $ ros2 bag record --all --compression-format zstd --compression-mode message + + +Rosbag2 Python API +""""""""""""""""""""" + +A new package ``rosbag2_py`` has been released in Galactic, which provides a Python API. +This package is a ``pybind11`` binding around the C++ API. +As of the initial Galactic release, it does not yet expose all functionality available via the ``rosbag2_cpp`` API, but it is the sole connection for the ``ros2 bag`` CLI tool, so a good deal of functionality is available. + + +performance testing package and performance improvements +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +A thorough performance analysis project was performed on rosbag2 since the Foxy release. +The full initial report is available at https://github.com/ros2/rosbag2/blob/galactic/rosbag2_performance/rosbag2_performance_benchmarking/docs/rosbag2_performance_improvements.pdf . +The package ``rosbag2_performance_benchmarking`` provides tools to run performance analyses, especially on recording, which helps us maintain and improve the performance of rosbag2. + +Following this report, key work was done do improve the performance to a much more usable state for actual robot workflows. +To highlight a key metric - in a high bandwidth stress test (200Mbps), the Foxy release dropped up to 70% of messages, whereas the Galactic version was approximately 100% retention. +Please see the linked report for more details. + +``--regex`` and ``--exclude`` options for topic selection +""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The new recording options ``--regex`` and ``--exclude`` allow for fine-tuning the topics recorded in a bag, without having to explicitly list all topics. +These options may be used together or separately, and in conjunction with ``--all`` + +The following command will record only topics with "scan" in the name. + +.. code-block:: console + + $ ros2 bag record --regex "*scan*" + +The following command will record all topics except for ones in ``/my_namespace/`` + +.. code-block:: console + + $ ros2 bag record --all --exclude "/my_namespace/*" + + +``ros2 bag reindex`` +"""""""""""""""""""" + +ROS 2 bags are represented by a directory, instead of a single file. +This directory contains a ``metadata.yaml`` file, and one or more bag files. +When the ``metadata.yaml`` file is lost or missing, ``ros2 bag reindex $bag_dir`` will attempt to reconstruct it by reading all the bag files in the directory. + +Playback time control +""""""""""""""""""""" + +New controls have been added for rosbag2 playback - pause & resume, change rate, and play-next. +As of the Galactic release, these controls are exposed only as services on the rosbag2 player node. +Development is in progress to expose them to keyboard controls as well in ``ros2 bag play``, but until then a user application with buttons or keyboard controls may be trivially implemented to call these services. + +In one shell: + +.. code-block:: console + + $ ros2 bag play my_bag + +In another shell: + +.. code-block:: console + + $ ros2 service list -t + /rosbag2_player/get_rate [rosbag2_interfaces/srv/GetRate] + /rosbag2_player/is_paused [rosbag2_interfaces/srv/IsPaused] + /rosbag2_player/pause [rosbag2_interfaces/srv/Pause] + /rosbag2_player/play_next [rosbag2_interfaces/srv/PlayNext] + /rosbag2_player/resume [rosbag2_interfaces/srv/Resume] + /rosbag2_player/set_rate [rosbag2_interfaces/srv/SetRate] + /rosbag2_player/toggle_paused [rosbag2_interfaces/srv/TogglePaused] + + $ ros2 service call /rosbag2_player/is_paused rosbag2_interfaces/IsPaused + +To pause playback: + +.. code-block:: console + + $ ros2 service call /rosbag2_player/pause rosbag2_interfaces/Pause + +To resume playback: + +.. code-block:: console + + $ ros2 service call /rosbag2_player/resume rosbag2_interfaces/Resume + +To change the paused state of playback to its opposite. +If playing, pauses. +If paused, resumes. + +.. code-block:: console + + $ ros2 service call /rosbag2_player/toggle_paused rosbag2_interfaces/TogglePaused + +To get the current playback rate: + +.. code-block:: console + + $ ros2 service call /rosbag2_player/get_rate + +To set the current playback rate (must be > 0): + +.. code-block:: console + + $ ros2 service call /rosbag2_player/set_rate rosbag2_interfaces/SetRate "rate: 0.1" + +To play a single next message (only works while paused): + +.. code-block:: console + + $ ros2 service call /rosbag2_player/play_next rosbag2_interfaces/PlayNext + + +Playback publishes /clock +""""""""""""""""""""""""" + +Rosbag2 can also dictate "simulation time" by publishing to the ``/clock`` topic during playback. +The following commands will publish the clock message at a regular interval. + +To publish at the default rate of 40Hz: + +.. code-block:: console + + $ ros2 bag play my_bag --clock + + +To publish at a specific rate, e.g., 100Hz: + +.. code-block:: console + + $ ros2 bag play my_bag --clock 100 + +Changes since the Foxy release +------------------------------ + +Default RMW changed to Eclipse Cyclone DDS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +During the Galactic development process, the ROS 2 Technical Steering Committee `voted `__ to change the default ROS middleware (RMW) to `Eclipse Cyclone DDS `__ project of `Eclipse Foundation `__. +Without any configuration changes, users will get Eclipse Cyclone DDS by default. +Fast DDS and Connext are still Tier-1 supported RMW vendors, and users can opt-in to use one of these RMWs at their discretion by using the ``RMW_IMPLEMENTATION`` environment variable. +See the `Working with multiple RMW implementations guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` for more information. + +Connext RMW changed to rmw_connextdds +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A new RMW for Connext called `rmw_connextdds `_ was merged for Galactic. +This RMW has better performance and fixes many of the issues with the older RMW ``rmw_connext_cpp``. + +Large improvements in testing and overall quality +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Galactic contains many changes that fix race conditions, plug memory leaks, and fix user reported problems. +Besides these changes, there was a concerted effort during Galactic development to improve overall quality of the system by implementing `REP 2004 `__. +The ``rclcpp`` package and all of its dependencies (which include most of the ROS 2 non-Python core packages) were brought up to `Quality Level 1 `__ by: + +* Having a version policy (QL1 requirement 1) +* Having a documented change control process (QL1 requirement 2) +* Documenting all features and public APIs (QL1 requirement 3) +* Adding many additional tests (QL1 requirement 4): + + * System tests for all features + * Unit tests for all public APIs + * Nightly performance tests + * Code coverage at 95% + +* Having all runtime dependencies of packages be at least as high as the package (QL1 requirement 5) +* Supporting all of the REP-2000 platforms (QL1 requirement 6) +* Having a vulnerability disclosure policy (QL1 requirement 7) + +rmw +^^^ + +New API for checking QoS profile compatibility +"""""""""""""""""""""""""""""""""""""""""""""" + +``rmw_qos_profile_check_compatible`` is a new function for checking the compatibility of two QoS profiles. + +RMW vendors should implement this API for QoS debugging and introspection features in tools such as ``rqt_graph`` to work correctly. + +Related PR: `ros2/rmw#299 `_ + +ament_cmake +^^^^^^^^^^^ + +``ament_install_python_package()`` now installs a Python egg +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +By installing a flat Python egg, Python packages installed using ``ament_install_python_package()`` can be discovered using modules such as ``pkg_resources`` and ```importlib.metadata``. Also, additional metadata can be provided in a ``setup.cfg`` file (including entry points). + +Related PR: `ament/ament_cmake#326 `_ + +``ament_target_dependencies()`` handles SYSTEM dependencies +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Some package dependencies can now be marked as SYSTEM dependencies, helping to cope with warnings in external code. Typically, SYSTEM dependencies are also excluded from dependency calculations -- use them with care. + +Related PR: `ament/ament_cmake#297 `_ + +nav2 +^^^^ + +Changes include, but are not limited to, a number of stability improvements, new plugins, interface changes, costmap filters. +See `Migration Guides `_ for full list + +tf2_ros Python split out of tf2_ros +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The Python code that used to live in tf2_ros has been moved into its own package named tf2_ros_py. +Any existing Python code that depends on tf2_ros will continue to work, but the package.xml of those packages should be amended to ``exec_depend`` on tf2_ros_py. + +tf2_ros Python TransformListener uses global namespace +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The Python ``TransformListener`` now subscribes to ``/tf`` and ``/tf_static`` in the global namespace. +Previously, it was susbcribing in the node's namespace. +This means that the node's namespace will no longer have an effect on the ``/tf`` and ``/tf_static`` subscriptions. + +For example: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo --ros-args -r __ns:=/test -- odom base_link + +will subscribe to ``/tf`` and ``/tf_static``, as ``ros2 topic list`` will show. + +Related PR: `ros2/geometry2#390 `_ + +rclcpp +^^^^^^ + +Change in spin_until_future_complete template parameters +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The first template parameter of ``Executor::spin_until_future_complete`` was the future result type ``ResultT``, and the method only accepted a ``std::shared_future``. +In order to accept other types of futures (e.g.: ``std::future``), that parameter was changed to the future type itself. + +In places where a ``spin_until_future_complete`` call was relying on template argument deduction, no change is needed. +If not, this is an example diff: + +.. code-block:: dpatch + + std::shared_future future; + ... + -executor.spin_until_future_complete(future); + +executor.spin_until_future_complete>(future); + + +For more details, see `ros2/rclcpp#1160 `_. +For an example of the needed changes in user code, see `ros-visualization/interactive_markers#72 `_. + +Change in default ``/clock`` subscription QoS profile +""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The default was changed from a reliable communication with history depth 10 to a best effort communication with history depth 1. +See `ros2/rclcpp#1312 `_. + +Waitable API +"""""""""""" + +Waitable API was modified to avoid issues with the ``MultiThreadedExecutor``. +This only affects users implementing a custom waitable. +See `ros2/rclcpp#1241 `_ for more details. + +Change in ``rclcpp``'s logging macros +""""""""""""""""""""""""""""""""""""" +Previously, the logging macros were vulnerable to a `format string attack `_, where the format string is evaluated and can potentially execute code, read the stack, or cause a segmentation fault in the running program. +To address this security issue, the logging macro now accepts only string literals for it's format string argument. + +If you previously had code like: + +.. code-block:: + + const char *my_const_char_string format = "Foo"; + RCLCPP_DEBUG(get_logger(), my_const_char_string); + +you should now replace it with: + +.. code-block:: + + const char *my_const_char_string format = "Foo"; + RCLCPP_DEBUG(get_logger(), "%s", my_const_char_string); + +or: + +.. code-block:: + + RCLCPP_DEBUG(get_logger(), "Foo"); + + +This change removes some convenience from the logging macros, as ``std::string``\s are no longer accepted as the format argument. + + +If you previously had code with no format arguments like: + +.. code-block:: + + std::string my_std_string = "Foo"; + RCLCPP_DEBUG(get_logger(), my_std_string); + +you should now replace it with: + +.. code-block:: + + std::string my_std_string = "Foo"; + RCLCPP_DEBUG(get_logger(), "%s", my_std_string.c_str()); + +.. note:: + If you are using a ``std::string`` as a format string with format arguments, converting that string to a ``char *`` and using it as the format string will yield a format security warning. That's because the compiler has no way at compile to introspect into the ``std::string`` to verify the arguments. To avoid the security warning, we recommend you build the string manually and pass it in with no format arguments like the previous example. + +``std::stringstream`` types are still accepted as arguments to the stream logging macros. +See `ros2/rclcpp#1442 `_ for more details. + +Parameter types are now static by default +""""""""""""""""""""""""""""""""""""""""" + +Previously, the type of a parameter could be changed when a parameter was set. +For example, if a parameter was declared as an integer, a later call to set the parameter could change that type to a string. +This behavior could lead to bugs, and is rarely what the user wants. +As of Galactic parameter types are static by default, and attempts to change the type will fail. +If the previous dynamic behavior is desired, there is an mechanism to opt it in (see the code below). + +.. code-block:: cpp + + // declare integer parameter with default value, trying to set it to a different type will fail. + node->declare_parameter("my_int", 5); + // declare string parameter with no default and mandatory user provided override. + // i.e. the user must pass a parameter file setting it or a command line rule -p := + node->declare_parameter("string_mandatory_override", rclcpp::PARAMETER_STRING); + // Conditionally declare a floating point parameter with a mandatory override. + // Useful when the parameter is only needed depending on other conditions and no default is reasonable. + if (mode == "modeA") { + node->declare_parameter("conditionally_declare_double_parameter", rclcpp::PARAMETER_DOUBLE); + } + // You can also get the old dynamic typing behavior if you want: + rcl_interfaces::msg::ParameterDescriptor descriptor; + descriptor.dynamic_typing = true; + node->declare_parameter("dynamically_typed_param", rclcpp::ParameterValue{}, descriptor); + +For more details see https://github.com/ros2/rclcpp/blob/galactic/rclcpp/doc/notes_on_statically_typed_parameters.md. + +New API for checking QoS profile compatibility +"""""""""""""""""""""""""""""""""""""""""""""" + +``qos_check_compatible`` is a new function for checking the compatibility of two QoS profiles. + +Related PR: `ros2/rclcpp#1554 `_ + +rclpy +^^^^^ + +Removal of deprecated Node.set_parameters_callback +"""""""""""""""""""""""""""""""""""""""""""""""""" + +The method ``Node.set_parameters_callback`` was `deprecated in ROS Foxy `_ and has been `removed in ROS Galactic `_. +Use ``Node.add_on_set_parameters_callback()`` instead. +Here is some example code using it. + +.. code-block:: python + + import rclpy + import rclpy.node + from rcl_interfaces.msg import ParameterType + from rcl_interfaces.msg import SetParametersResult + + + rclpy.init() + node = rclpy.node.Node('callback_example') + node.declare_parameter('my_param', 'initial value') + + + def on_parameter_event(parameter_list): + for parameter in parameter_list: + node.get_logger().info(f'Got {parameter.name}={parameter.value}') + return SetParametersResult(successful=True) + + + node.add_on_set_parameters_callback(on_parameter_event) + rclpy.spin(node) + +Run this command to see the parameter callback in action. + +.. code-block:: + + ros2 param set /callback_example my_param "Hello World" + +Parameter types are now static by default +""""""""""""""""""""""""""""""""""""""""" + +In Foxy and earlier a call to set a parameter could change its type. +As of Galactic parameter types are static and cannot be changed by default. +If the previous behavior is desired, then set ``dynamic_typing`` to true in the parameter descriptor. +Here is an example. + +.. code-block:: python + + import rclpy + import rclpy.node + from rcl_interfaces.msg import ParameterDescriptor + + rclpy.init() + node = rclpy.node.Node('static_param_example') + node.declare_parameter('static_param', 'initial value') + node.declare_parameter('dynamic_param', 'initial value', descriptor=ParameterDescriptor(dynamic_typing=True)) + rclpy.spin(node) + +Run these commands to see how statically and dynamically typed parameters are different. + +.. code-block:: console + + $ ros2 param set /static_param_example dynamic_param 42 + Set parameter successful + $ ros2 param set /static_param_example static_param 42 + Setting parameter failed: Wrong parameter type, expected 'Type.STRING' got 'Type.INTEGER' + +For more details see https://github.com/ros2/rclcpp/blob/galactic/rclcpp/doc/notes_on_statically_typed_parameters.md. + +New API for checking QoS profile compatibility +"""""""""""""""""""""""""""""""""""""""""""""" + +``rclpy.qos.qos_check_compatible`` is `a new function `_ for checking the compatibility of two QoS profiles. +If the profiles are compatible, then a publisher and subscriber using them will be able to talk to each other. + +.. code-block:: python + + import rclpy.qos + + publisher_profile = rclpy.qos.qos_profile_sensor_data + subscription_profile = rclpy.qos.qos_profile_parameter_events + + print(rclpy.qos.qos_check_compatible(publisher_profile, subscription_profile)) + +.. code-block:: console + + $ python3 qos_check_compatible_example.py + (QoSCompatibility.ERROR, 'ERROR: Best effort publisher and reliable subscription;') + +rclcpp_action +^^^^^^^^^^^^^ + +Action client goal response callback signature changed +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The goal response callback should now take a shared pointer to a goal handle, instead of a future. + +For `example `_, old signature: + +.. code-block:: c++ + + void goal_response_callback(std::shared_future future) + +New signature: + +.. code-block:: c++ + + void goal_response_callback(GoalHandleFibonacci::SharedPtr goal_handle) + +Related PR: `ros2/rclcpp#1311 `_ + +rosidl_typesupport_introspection_c +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +API break in function that gets an element from an array +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The signature of the function was changed because it was semantically different to all the other functions used to get an element from an array or sequence. +This only affects authors of rmw implementations using the introspection typesupport. + +For further details, see `ros2/rosidl#531 `_. + +rcl_lifecycle and rclcpp_lifecycle +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +RCL's lifecycle state machine gets new init API +""""""""""""""""""""""""""""""""""""""""""""""" + +The lifecycle state machine in rcl_lifecycle was modified to expect a newly introduced options struct, combining general configurations for the state machine. +The option struct allows to indicate whether the state machine shall be initialized with default values, whether its attached services are active and which allocator to be used. + +.. code-block:: c + + rcl_ret_t + rcl_lifecycle_state_machine_init( + rcl_lifecycle_state_machine_t * state_machine, + rcl_node_t * node_handle, + const rosidl_message_type_support_t * ts_pub_notify, + const rosidl_service_type_support_t * ts_srv_change_state, + const rosidl_service_type_support_t * ts_srv_get_state, + const rosidl_service_type_support_t * ts_srv_get_available_states, + const rosidl_service_type_support_t * ts_srv_get_available_transitions, + const rosidl_service_type_support_t * ts_srv_get_transition_graph, + const rcl_lifecycle_state_machine_options_t * state_machine_options); + +RCL's lifecycle state machine stores allocator instance +""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The options struct (discussed above) entails an instance of the allocator being used for initializing the state machine. +This options struct and there the embodied allocator are being stored within the lifecycle state machine. +As a direct consequence, the ``rcl_lifecycle_fini function`` no longer expects an allocator in its fini function but rather uses the allocator set in the options struct for deallocating its internal data structures. + +.. code-block:: c + + rcl_ret_t + rcl_lifecycle_state_machine_fini( + rcl_lifecycle_state_machine_t * state_machine, + rcl_node_t * node_handle); + +RCLCPP's lifecycle node exposes option to not instantiate services +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +In order to use rclcpp's lifecycle nodes without exposing its internal services such as ``change_state``, ``get_state`` et. al., the constructor of a lifecycle node has a newly introduced parameter indicating whether or not the services shall be available. +This boolean flag is set to true by default, not requiring any changes to existing API if not wished. + +.. code-block:: c++ + + explicit LifecycleNode( + const std::string & node_name, + const rclcpp::NodeOptions & options = rclcpp::NodeOptions(), + bool enable_communication_interface = true); + +Related PRs: `ros2/rcl#882 `_ and `ros2/rclcpp#1507 `_ + +rcl_lifecycle and rclcpp_lifecycle +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Recording - Split by time +""""""""""""""""""""""""""""""""""""""""""""""" + + + +Known Issues +------------ + +ros2cli +^^^^^^^ + +Daemon slows down CLI on Windows +"""""""""""""""""""""""""""""""" + +As a workaround, CLI commands may be used without a daemon e.g.: + +.. code-block:: console + + $ ros2 topic list --no-daemon + + +Issue is tracked by `ros2/ros2cli#637 `_. + +rqt +^^^ + +Some rqt_bag icons are missing +"""""""""""""""""""""""""""""" + +The icons to "Zoom In", "Zoom Out", "Zoom Home", and "Toggle Thumbnails" are missing in ``rqt_bag``. +The issue is tracked in `ros-visualization/rqt_bag#102 `_ + +Most rqt utilities don't work standalone on Windows +""""""""""""""""""""""""""""""""""""""""""""""""""" + +Launching the rqt utilities "standalone" on Windows (like ``ros2 run rqt_graph rqt_graph``) generally doesn't work. +The workaround is to launch the rqt container process (``rqt``), and then insert the plugins to be used. + +rviz2 +^^^^^ + +RViz2 panel close buttons are blank +""""""""""""""""""""""""""""""""""" + +The upper right-hand corner of every RViz2 panel should contain an "X" to allow one to close the panel. +Those buttons are there, but the "X" inside of them is missing on all platforms. +The issue is being tracked in `ros2/rviz2#692 `__. + +Timeline before the release +--------------------------- + + Mon. March 22, 2021 - Alpha + Preliminary testing and stabilization of ROS Core [1]_ packages. + + Mon. April 5, 2021 - Freeze + API and feature freeze for ROS Core [1]_ packages in Rolling Ridley. + Note that this includes ``rmw``, which is a recursive dependency of ``ros_core``. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 19, 2021 - Branch + Branch from Rolling Ridley. + ``rosdistro`` is reopened for Rolling PRs for ROS Core [1]_ packages. + Galactic development shifts from ``ros-rolling-*`` packages to ``ros-galactic-*`` packages. + + Mon. April 26, 2021 - Beta + Updated releases of ROS Desktop [2]_ packages available. + Call for general testing. + + Mon. May 17, 2021 - RC + Release Candidate packages are built. + Updated releases of ROS Desktop [2]_ packages available. + + Thu. May 20, 2021 - Distro Freeze + Freeze rosdistro. + No PRs for Galactic on the ``rosdistro`` repo will be merged (reopens after the release announcement). + + Sun. May 23, 2021 - General Availability + Release announcement. + ``rosdistro`` is reopened for Galactic PRs. + +.. [1] The ``ros_core`` variant is described in `REP 2001 (ros-core) `_. +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Humble-Hawksbill.rst b/source/Get-Started/Releases/Release-Humble-Hawksbill.rst index 3c7c8ea84e3..0ffd9cd9402 100644 --- a/source/Get-Started/Releases/Release-Humble-Hawksbill.rst +++ b/source/Get-Started/Releases/Release-Humble-Hawksbill.rst @@ -1,1121 +1,1125 @@ -.. _humble-release: - -Humble Hawksbill (``humble``) -============================= - -.. toctree:: - :hidden: - - Humble-Hawksbill-Complete-Changelog - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Humble Hawksbill* is the eighth release of ROS 2. -What follows is highlights of the important changes and features in Humble Hawksbill since the last release. -For a list of all of the changes since Galactic, see the `long form changelog `. - -Supported Platforms -------------------- - -Humble Hawksbill supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 22.04 (Jammy): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019): ``amd64`` - -Tier 2 platforms: - -* RHEL 8: ``amd64`` - -Tier 3 platforms: - -* Ubuntu 20.04 (Focal): ``amd64`` -* macOS: ``amd64`` -* Debian Bullseye: ``amd64`` - -Targeted platforms: - -+--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ -| Architecture | Ubuntu Jammy (22.04) | Windows 10 (VS2019) | RHEL 8 | Ubuntu Focal (20.04) | macOS | Debian Bullseye (11) | OpenEmbedded / Yocto Project | -+==============+======================+=====================+==================+======================+============+======================+==============================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s] | Tier 3 [s] | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ -| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ -| arm32 | Tier 3 [s] | | | Tier 3 [s] | | Tier 3 [s] | Tier 3 [s] | -+--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be -provided for this platform for packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Humble ROS 2 repos file[^11]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=========================+===============+============================+===============================+ -| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64| -+--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32| -+--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ - - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++17 -- Python 3.6 - -Dependency Requirements: - -+------------------+-------------------+-----------------------------------------------------------------------------------------------------------+ -| | Required Support | Recommended Support | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Package | Ubuntu | Windows| RHEL 8 | Ubuntu Focal | macOS** | Debian Bullseye | OpenEmbedded** | -| | Jammy | 10** | | | | | | -+==================+==========+========+========+==============+==========+==================+=====================================================+ -| CMake | 3.22.1 | 3.22.0 | 3.20.2 | 3.16.3 | 3.14.4 | 3.18.4 | 3.22.3 / 3.16.5*** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| EmPY | 3.3.4 | 3.3.2 | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Gazebo Classic | 11.x.x* | N/A | N/A | 11.0.0* | 11.x.x | 11.x.x* | N/A | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Gazebo (Ignition)| Fortress*| N/A | N/A | Fortress* | Fortress*| Fortress* | N/A | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| NumPy | 1.21.5 | 1.18.4 | 1.14.3 | 1.17.4 | 1.18.4 | 1.19.5 | N/A | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Ogre | 1.12.1* | N/A | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| OpenCV | 4.5.4 | 3.4.6* | 3.4.6 | 4.2.0 | 4.2.0 | 4.5.1 | 4.1.0 / 3.2.0*** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| OpenSSL | 1.1.1l | 1.1.1l | 1.1.1k | 1.1.1d | 1.1.1f | 1.1.1i | 1.1.1d / 1.1.1b*** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Python | 3.10.4 | 3.8.3 | 3.6.8 | 3.8.0 | 3.8.2 | 3.9.1 | 3.8.2 / 3.7.5*** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Qt | 5.15.3 | 5.12.12| 5.15.2 | 5.12.5 | 5.12.3 | 5.15.2 | 5.14.1 / 5.12.5*** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| | **Linux only** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| PCL | 1.12.1 | N/A | 1.11.1 | 1.10.0 | N/A | 1.11.1 | 1.10.0 | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| **RMW DDS Middleware Providers** | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Cyclone DDS | 0.9.x (Papillons) | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Fast-DDS | 2.6.x | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Connext DDS | 6.0.1 | N/A | 6.0.1 | N/A | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ -| Gurum DDS | 2.7.x | N/A | 2.7.x | N/A | -+------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" means that the dependency may see multiple version changes, -because the dependency uses a package manager that continually updates -the dependency without a stable API. - -\" \*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- Windows: Chocolatey, pip -- macOS: Homebrew, pip -- RHEL: dnf -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Humble Hawksbill <../../humble/Installation.html>`__ - -Changes in Patch Release 1 (2022-11-23) ---------------------------------------- - -ros2topic -^^^^^^^^^ - -``now`` as keyword for ``builtin_interfaces.msg.Time`` and ``auto`` for ``std_msgs.msg.Header`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -``ros2 topic pub`` now allows to set a ``builtin_interfaces.msg.Time`` message to the current time via the ``now`` keyword. -Similarly, a ``std_msg.msg.Header`` message will be automatically generated when passed the keyword ``auto``. -This behavior matches that of ROS 1's ``rostopic`` (http://wiki.ros.org/ROS/YAMLCommandLine#Headers.2Ftimestamps) - -Related PR: `ros2/ros2cli#751 `_ - -New features in this ROS 2 release ----------------------------------- - -ament_cmake_gen_version_h -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Generating a C/C++ header with version info -""""""""""""""""""""""""""""""""""""""""""" -A new CMake function to generate a header with the package version info was added to the ``ament_cmake_gen_version_h`` in `ament/ament_cmake#377 `__. -Here's the simplest use case: - -.. code-block:: CMake - - project(my_project) - add_library(my_lib ...) - ament_generate_version_header(my_lib) - -It will generate a header with version info from the ``package.xml`` and make it available to targets that link against the ``my_lib`` library. - -How to include the header: - -.. code-block:: C - - #include - -Where the header is installed to: - -.. code-block:: cmake - - set(VERSION_HEADER ${CMAKE_INSTALL_PREFIX}/include/my_project/my_project/version.h) - -launch -^^^^^^ - -Scoping environment variables in group actions -"""""""""""""""""""""""""""""""""""""""""""""" - -Similar to launch configurations, now by default, the state of environment variables are scoped to group actions. - -For example, in the following launch files the executed processe will echo the value ``1`` (before Humble it would echo ``2``): - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: xml - - - - - - - - - - .. group-tab:: Python - - .. code-block:: python - - import launch - import launch.actions - - def generate_launch_description(): - return launch.LaunchDescription([ - launch.actions.SetEnvironmentVariable(name='FOO', value='1'), - launch.actions.GroupAction([ - launch.actions.SetEnvironmentVariable(name='FOO', value='2'), - ]), - launch.actions.ExecuteProcess(cmd=['echo', '$FOO'], output='screen', shell=True), - ]) - -If you would like disable scoping for launch configurations and and environment variables you can set the ``scoped`` argument (or attribute) to false. - -Related PR: `ros2/launch#601 `_ - -launch_pytest -""""""""""""" - -We've added a new package, ``launch_pytest``, that acts as an alternative to ``launch_testing``. -``launch_pytest`` is a simple pytest plugin that provides pytest fixtures to manage the lifetime of a launch service. - -Check out the `package README for details and examples. `_ - -Related PR: `ros2/launch#528 `_ - -Allow matching target actions with a callable -""""""""""""""""""""""""""""""""""""""""""""" - -Event handlers that take a target action object to match can now also take a callable instead to do the matching. - -Related PR: `ros2/launch#540 `_ - -Access to math module when evaluating Python expressions -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Inside ``PythonExpression`` substitutions (``eval``) we can now use symbols from Python's math module. -For example, - -.. code-block:: xml - - - - - -Related PR: `ros2/launch#557 `_ - -Boolean substitutions -""""""""""""""""""""" - -New substitutions ``NotSubstitution``, ``AndSubstitution``, and ``OrSubstitution`` provide a convenient way to perform logical operations, for example - -.. code-block:: xml - - - - - - - - - - - - - - - -Related PR: `ros2/launch#598 `_ - -New actions -""""""""""" - -* ``AppendEnvironmentVariable`` appends a value to an existing environment variable. - - * Related PR: `ros2/launch#543 `_ - -* ``ResetLaunchConfigurations`` resets any configuration applied to the launch configuration. - - * Related PR: `ros2/launch#515 `_ - -launch_ros -^^^^^^^^^^ - -Passing ROS arguments to node actions -""""""""""""""""""""""""""""""""""""" - -It is now possible to provide `ROS-specific node arguments <../../How-To-Guides/Node-arguments>` directly, without needing to use ``args`` with a leading ``--ros-args`` flag: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: xml - - - - - - .. group-tab:: YAML - - .. code-block:: yaml - - launch: - - node: - pkg: demo_nodes_cpp - exec: talker - ros_args: '--log-level debug' - -The corresponding parameter for the ``Node`` action in Python launch files is ``ros_arguments``: - -.. code-block:: python - - from launch import LaunchDescription - import launch_ros.actions - - def generate_launch_description(): - return LaunchDescription([ - launch_ros.actions.Node( - package='demo_nodes_cpp', - executable='talker', - ros_arguments=['--log-level', 'debug'], - ), - ]) - -Related PRs: `ros2/launch_ros#249 `_ and `ros2/launch_ros#253 `_. - -Frontend support for composable nodes -""""""""""""""""""""""""""""""""""""" - -We can now start node containers and load components into them from frontend launch files, for example: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: xml - - - - - - - - - - - .. group-tab:: YAML - - .. code-block:: yaml - - launch: - - node_container: - pkg: rclcpp_components - exec: component_container - name: my_container - namespace: '' - composable_node: - - pkg: composition - plugin: composition::Talker - name: talker - - load_composable_node: - target: my_container - composable_node: - - pkg: composition - plugin: composition::Listener - name: listener - -Related PR: `ros2/launch_ros#235 `_ - -Parameter substitution -"""""""""""""""""""""" - -The new ``ParameterSubstitution`` lets you substitute the value of a parameter set previously in launch with the ``SetParameter`` action. -For example, - -.. code-block:: xml - - - - - - -Related PR: `ros2/launch_ros#297 `_ - -New actions -""""""""""" - -* ``RosTimer`` acts like the launch ``TimerAction``, but uses a ROS clock (so it can use simulation time, for example). - - * Related PRs: `ros2/launch_ros#244 `_ and `ros2/launch_ros#264 `_ - -* ``SetParametersFromFile`` passes a ROS parameters file to all nodes in a launch file (including node components). - - * Related PRs: `ros2/launch_ros#260 `_ and `ros2/launch_ros#281 `_ - -SROS2 Security enclaves support Certificate Revocation Lists -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Certificate Revocation Lists (CRLs) are a concept where particular certificates can be revoked before their expiration. -As of Humble, it is now possible to put a CRL in an SROS2 security enclave and have it be honored. -See `the SROS2 tutorials `__ for an example of how to use it. - -Content Filtered Topics -^^^^^^^^^^^^^^^^^^^^^^^ - -Content Filtered Topics supports a more sophisticated subscription that indicates the subscriber does not want to necessarily see all values of each instance published under the Topic. -Content Filtered Topics can be used to request content-based subscriptions when underlying RMW implementation supports this feature. - -.. list-table:: RMW Content Filtered Topics support - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - -To learn more, see the `content_filtering `_ examples. - -Related design PR: `ros2/design#282 `_. - -ros2cli -^^^^^^^ - -``ros2 launch`` has a ``--launch-prefix`` argument -"""""""""""""""""""""""""""""""""""""""""""""""""" - -This allows passing a prefix to all executables in a launch file, which is useful in many debugging situations. -See the associated `pull request `__, as well as the :ref:`tutorial ` for more information. - -Relatedly, the ``--launch-prefix-filter`` command-line option was added to selectively add the prefix from ``--launch-prefix`` to executables. -See the `pull request `__ for more information. - -``ros2 topic echo`` has a ``--flow-style`` argument -""""""""""""""""""""""""""""""""""""""""""""""""""" - -This allows the user to force ``flow style`` for the YAML representation of data on a topic. -Without this option, the output from ``ros2 topic echo /tf_static`` could look something like: - -.. code-block:: - - transforms: - - header: - stamp: - sec: 1651172841 - nanosec: 433705575 - frame_id: single_rrbot_link3 - child_frame_id: single_rrbot_camera_link - transform: - translation: - x: 0.05 - y: 0.0 - z: 0.9 - rotation: - x: 0.0 - y: 0.0 - z: 0.0 - w: 1.0 - -With this option, the output would look something like: - -.. code-block:: - - transforms: [{header: {stamp: {sec: 1651172841, nanosec: 433705575}, frame_id: single_rrbot_link3}, child_frame_id: single_rrbot_camera_link, transform: {translation: {x: 0.05, y: 0.0, z: 0.9}, rotation: {x: 0.0, y: 0.0, z: 0.0, w: 1.0}}}] - -See the `PyYAML documentation `__ for more information. - -``ros2 topic echo`` can filter data based on message contents -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This allows the user to only print out data on a topic that matches a certain Python expression. -For instance, using the following argument will only print out string messages that start with 'foo': - -.. code-block:: - - ros2 topic echo --filter 'm.data.startswith("foo")` /chatter - -See the `pull request `__ for more information. - - -rviz2 -^^^^^ - -Apply textures to arbitrary triangle lists -"""""""""""""""""""""""""""""""""""""""""" - -We've added `the ability to apply textures defined via URI to arbitrary triangle lists using UV Coordinates `__. -Now we can create a gradient pull from a texture map instead of the default grayscale. -This will enable complex coloring of markers. -To use this, you should use the ``visualization_msgs/Marker.msg`` and fill the ``texture_resource``, ``texture``, ``uv_coordinates`` and ``mesh_file`` fields. -You can find more information `here `__. - -.. image:: images/triangle_marker_with_gradient.png - -Visualization of mass properties (including inertia) -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -We also added the ability to visualize inertias. To do this, you select enable 'Inertia' in the 'Mass Properties' under the robot model: - -.. image:: images/rviz_mass_inertia.png - -You can see an image of an inertia below. - -.. image:: images/tb4_inertia.png - -Visualize YUV images in RViz -"""""""""""""""""""""""""""" - -It is now possible to directly visualize YUV images inside of RViz, rather than having to convert to RGB first. -See `ros2/rviz#701 `__ for details. - -Allow rendering of objects > 100 meters -""""""""""""""""""""""""""""""""""""""" - -By default, RViz only renders objects that are within 100 meters of a camera. -A new configuration property called "Far Plane Distance" in the rviz camera plugin allows that rendering distance to be configured. - -.. image:: images/rviz2-far-plane-distance.png - -See `ros2/rviz#849 `__ for more information. - -Changes since the Galactic release ----------------------------------- - -C++ headers are installed in a subdirectory -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In ROS 2 releases prior to Humble, C++ headers for all packages were installed into a single include directory. -For instance, in Galactic, the directory structure looks like this (reduced for brevity): - -.. code:: - - /opt/ros/galactic/include/ - ├── rcl - │   ├── node.h - ├── rclcpp - │   ├── node.hpp - - -This structure can cause serious problems when trying to use overlays. -That is, it is very possible to get the wrong set of header files due to include directory order. -See https://colcon.readthedocs.io/en/released/user/overriding-packages.html for a detailed explanation of the problems. - -To help combat this, in Humble (and in all ROS 2 releases going forward), the directory structure has changed: - -.. code:: - - /opt/ros/humble/include - ├── rcl - │   └── rcl - │   ├── node.h - ├── rclcpp - │   └── rclcpp - │   ├── node.hpp - -Note that downstream packages that use these headers do *not* have to change; using ``#include `` works as it always did before. -However, when using IDEs that are looking for include directories, it may be necessary to add the individual include directories to the search path. - -See https://github.com/ros2/ros2/issues/1150 for more information, including the reasoning behind this change. - -common_interfaces -^^^^^^^^^^^^^^^^^ - -Support Textures and Embedded Meshes for Marker Messages -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -These two additions will improve the ability to both visualize data in new ways with standard messages and, simultaneously, enable the ability to track this data in rosbag. - -**Textures** bring the addition of three new fields to markers: - -.. code-block:: bash - - # Texture resource is a special URI that can either reference a texture file in - # a format acceptable to (resource retriever)[https://index.ros.org/p/resource_retriever/] - # or an embedded texture via a string matching the format: - # "embedded://texture_name" - string texture_resource - # An image to be loaded into the rendering engine as the texture for this marker. - # This will be used iff texture_resource is set to embedded. - sensor_msgs/CompressedImage texture - # Location of each vertex within the texture; in the range: [0.0-1.0] - UVCoordinate[] uv_coordinates - -RViz will fully support texture rendering through the embedded format. - -To those familiar with ``mesh_resource``, ``resource_retriever`` should be familiar. -This will allow the programmer to choose where they want to load data from, either a local file or a networked file. -In the interest of being able to record all data in a rosbag, the ability to embed the texture image is included. - -**Meshes** were modified in a similar way to add the ability to embed a raw Mesh file for the purpose of recording and are modified in a similar way. The Meshfile message has two fields: - -.. code-block:: bash - - # The filename is used for both debug purposes and to provide a file extension - # for whatever parser is used. - string filename - - # This stores the raw text of the mesh file. - uint8[] data - -The embedded ``Meshfile`` message is not yet supported in implementation. - -Related PRs: `ros2/common_interfaces#153 `_ `ros2/rviz#719 `_ - -Added ``PRISM`` type to SolidPrimitive -"""""""""""""""""""""""""""""""""""""" - -The ``SolidPrimitive`` message had a new ``PRISM`` type added, along with the appropriate metadata. -See `ros2/common_interfaces#167 `_ for more information. - -rmw -^^^ - -``struct`` type name suffix changed from ``_t`` to ``_s`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -To avoid type name duplication errors between ``struct`` type names and their ``typedef``-ed aliases when generating code documentation, the suffix for all ``struct`` type names has been changed from ``_t`` to ``_s``. -Aliases with ``_t`` suffixes remain in place. -Thus, this change is a breaking change only for code that uses full ``struct`` type specifiers i.e. ``struct type_name_t``. - -See `ros2/rmw#313 `__ for more details. - -rmw_connextdds -^^^^^^^^^^^^^^ - -Use Connext 6 by default -"""""""""""""""""""""""" - -By default, Humble Hawksbill uses Connext 6.0.1 as the DDS implementation for ``rmw_connextdds``. -It is still possible to use Connext 5.3.1 with ``rmw_connextdds``, but it must be rebuilt from source. - -rcl -^^^ - -``struct`` type name suffix changed from ``_t`` to ``_s`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -To avoid type name duplication errors between ``struct`` type names and their ``typedef``-ed aliases when generating code documentation, the suffix for all ``struct`` type names has been changed from ``_t`` to ``_s``. -Aliases with ``_t`` suffixes remain in place. -Thus, this change is a breaking change only for code that uses full ``struct`` type specifiers i.e. ``struct type_name_t``. - -See `ros2/rcl#932 `__ for more details. - -ROS_DISABLE_LOANED_MESSAGES environment variable added -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This environment variable can be used to disable loaned messages support, independently if the rmw supports them or not. -For more details, see the guide :doc:`Configure Zero Copy Loaned Messages <../How-To-Guides/Configure-ZeroCopy-loaned-messages>`. - -rclcpp -^^^^^^ - -Support Type Adaption for Publishers and Subscriptions -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -After defining a type adapter, custom data structures can be used directly by publishers and subscribers, which helps to avoid additional work for the programmer and potential sources of errors. -This is especially useful when working with complex data types, such as when converting OpenCV's ``cv::Mat`` to ROS's ``sensor_msgs/msg/Image`` type. - -Here is an example of a type adapter that converts ``std_msgs::msg::String`` to ``std::string``: - -.. code-block:: cpp - - template<> - struct rclcpp::TypeAdapter< - std::string, - std_msgs::msg::String - > - { - using is_specialized = std::true_type; - using custom_type = std::string; - using ros_message_type = std_msgs::msg::String; - - static - void - convert_to_ros_message( - const custom_type & source, - ros_message_type & destination) - { - destination.data = source; - } - - static - void - convert_to_custom( - const ros_message_type & source, - custom_type & destination) - { - destination = source.data; - } - }; - -And an example of how the type adapter can be used: - -.. code-block:: cpp - - using MyAdaptedType = TypeAdapter; - - // Publish a std::string - auto pub = node->create_publisher(...); - std::string custom_msg = "My std::string" - pub->publish(custom_msg); - - // Pass a std::string to a subscription's callback - auto sub = node->create_subscription( - "topic", - 10, - [](const std::string & msg) {...}); - -To learn more, see the `publisher `_ and `subscription `_ examples, as well as a more complex `demo `_. -For more details, see `REP 2007 `_. - -``Client::asnyc_send_request(request)`` returns a ``std::future`` instead of a ``std::shared_future`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This change was implemented in `rclcpp#1734 `_. -This breaks API, as ``std::future::get()`` methods extracts the value from the future. -That means, if that method is called for a second time it will throw an exception. -That doesn't happen with a ``std::shared_future``, as its ``get()`` method returns a ``const &``. -Example: - -.. code-block:: cpp - - auto future = client->async_send_request(req); - ... - do_something_with_response(future.get()); - ... - do_something_else_with_response(future.get()); // this will throw an exception now!! - -should be updated to: - -.. code-block:: cpp - - auto future = client->async_send_request(req); - ... - auto response = future.get(); - do_something_with_response(response); - ... - do_something_else_with_response(response); - -If a shared future is needed, the ``std::future::share()`` method can be used. - -``wait_for_all_acked`` method added to ``Publisher`` -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -This new method will block until all messages in the publisher queue are acked by the matching subscriptions or the specified timeout expires. -It is only useful for reliable publishers, as in the case of best effort QoS there's no acking. -Examples: - -.. code-block:: cpp - - auto pub = node->create_publisher(...); - ... - pub->publish(my_msg); - ... - pub->wait_for_all_acked(); // or pub->wait_for_all_acked(timeout) - -For a more complete example, see `here `__. - -``get_callback_groups`` method removed from ``NodeBase`` and ``Node`` classes -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -``for_each_callback_group()`` method has replaced ``get_callback_groups()`` by providing a thread-safe way to access ``callback_groups_`` vector. -``for_each_callback_group()`` accepts a function as an argument, iterates over the stored callback groups, and calls the passed function to ones that are valid. - -For more details, please refer to this `pull request `_. - -``add_to_wait_set`` method from ``Waitable`` class changes its return type from ``bool`` to ``void`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -Before, classes derived from ``Waitable`` overriding ``add_to_wait_set`` were returning false when failing to add elements to the wait set, so the caller had to check this return value and throw or handle the error. -This error handling should now be done directly on ``add_to_wait_set`` method, throwing if necessary. -It is not required to return anything if no errors happened. -Thus, this is a breaking change for downstream uses of ``Waitable``. - -See `ros2/rclcpp#1612 `__ for more details. - -``get_notify_guard_condition`` method return type from ``NodeBaseInterface`` class changed -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -Now ``rclcpp`` uses the ``GuardCondition`` class wrapper around ``rcl_guard_condition_t``, so ``get_notify_guard_condition`` returns a reference to the node's ``rclcpp::GuardCondition``. -Thus, this is a breaking change for downstream uses of ``NodeBaseInterface`` and ``NodeBase``. - -See `ros2/rclcpp#1612 `__ for more details. - -``sleep_until`` and ``sleep_for`` methods added to ``Clock`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -Two new methods were added to allow sleeping on a particular clock in `ros2/rclcpp#1814 `__ and `ros2/rclcpp#1828 `__. -``Clock::sleep_until`` will suspend the current thread until the clock reaches a particular time. -``Clock::sleep_for`` will suspend the current thread until the clock advances a certain amount of time from when the method was called. -Both methods will wake early if the ``Context`` is shutdown. - -rclcpp_lifecycle -^^^^^^^^^^^^^^^^ - -Active and deactivate transitions of publishers will be triggered automatically -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Before, users needed to override ``LifecylceNode::on_activate()`` and ``LifecylceNode::on_deactivate()`` and call the similarly named methods on ``LifecyclePublisher`` to make the transition actually happen. -Now, ``LifecylceNode`` provides a default interface of these methods that already do this. -See the implementation of the ``lifecycle_talker`` node `here `__. - -rclpy -^^^^^ - -Managed nodes -""""""""""""" - -Lifecycle nodes support was added to rclpy. -A complete demo can be found `here `__. - -``wait_for_all_acked`` method added to ``Publisher`` -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -Similar to the feature added to rclcpp. - -``sleep_until`` and ``sleep_for`` methods added to ``Clock`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -Two new methods were added to allow sleeping on a particular clock in `ros2/rclpy#858 `__ and `ros2/rclpy#864 `__. -``sleep_until`` will suspend the current thread until the clock reaches a particular time. -``sleep_for`` will suspend the current thread until the clock advances a certain amount of time from when the method was called. -Both methods will wake early if the ``Context`` is shutdown. - -ros1_bridge -^^^^^^^^^^^ - -Since there is no official ROS 1 distribution on Ubuntu Jammy and forward, ``ros1_bridge`` is now compatible with the Ubuntu-packaged versions of ROS 1. -More details about using ``ros1_bridge`` with Jammy packages are available in :doc:`the how-to guides <../How-To-Guides/Using-ros1_bridge-Jammy-upstream>`. - -ros2cli -^^^^^^^ - -``ros2`` commands disable output buffering by default -""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Prior to this release, running a command like - -.. code-block:: - - ros2 echo /chatter | grep "Hello" - -would not print any data until the output buffer was full. -Users could work around this by setting ``PYTHONUNBUFFERED=1``, but that was not very user friendly. - -Instead, all ``ros2`` commands now do line-buffering by default, so commands like the above work as soon as a newline is printed. -To disable this behavior and use default python buffering rules, use the option ``--use-python-default-buffering``. -See the `original issue `__ and the `pull request `__ for more information. - -``ros2 topic pub`` will wait for one matching subscription when using ``--times/--once/-1`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -When using ``--times/--once/-1`` flags, ``ros2 topic pub`` will wait for one matching subscription to be found before starting to publish. -This avoids the issue of the ros2cli node starting to publish before discovering a matching subscription, which results in some of the first messages being lost. -This is particularly unexpected when using a reliable qos profile. - -The number of matching subscriptions to wait before starting publishing can be configured with the ``-w/--wait-matching-subscriptions`` flags, e.g.: - -.. code-block:: console - - $ ros2 topic pub -1 -w 3 /chatter std_msgs/msg/String "{data: 'foo'}" - -to wait for three matching subscriptions before starting to publish. - -``-w`` can also be used independently of ``--times/--once/-1`` but it only defaults to one when combined with them, otherwise the ``-w`` default is zero. - -See https://github.com/ros2/ros2cli/pull/642 for more details. - -``ros2 param dump`` default output changed -"""""""""""""""""""""""""""""""""""""""""" - - * ``--print`` option for dump command was `deprecated `_. - - It prints to stdout by default: - - .. code-block:: console - - $ ros2 param dump /my_node_name - - * ``--output-dir`` option for dump command was `deprecated `_. - - To dump parameters to a file, run: - - .. code-block:: console - - $ ros2 param dump /my_node_name > my_node_name.yaml - -``ros2 param set`` now accepts more YAML syntax -""""""""""""""""""""""""""""""""""""""""""""""" - -Previously, attempting to set a string like "off" to a parameter that was of string type did not work. -That's because ``ros2 param set`` interprets the command-line arguments as YAML, and YAML considers "off" to be a boolean type. -As of https://github.com/ros2/ros2cli/pull/684 , ``ros2 param set`` now accepts the YAML escape sequence of "!!str off" to ensure that the value is considered a string. - -``ros2 pkg create`` can automatically generate a LICENSE file -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -If the ``--license`` flag is passed to ``ros2 pkg create``, and the license is one of the known licenses, ``ros2 pkg create`` will now automatically generate a LICENSE file in the root of the package. -For a list of known licenses, run ``ros2 pkg create --license ? ``. -See the associated `pull request `__ for more information. - -robot_state_publisher -^^^^^^^^^^^^^^^^^^^^^ - -Added ``frame_prefix`` parameter -"""""""""""""""""""""""""""""""" -A new parameter ``frame_prefix`` was added in `ros/robot_state_publisher#159 `__. -This parameter is a string which is prepended to all frame names published by ``robot_state_publisher``. -Similar to ``tf_prefix`` in the original ``tf`` library in ROS 1, this parameter can be used to publish the same robot description multiple times with different frame names. - -Removal of deprecated ``use_tf_static`` parameter -""""""""""""""""""""""""""""""""""""""""""""""""" - -The deprecated ``use_tf_static`` parameter has been removed from ``robot_state_publisher``. -This means that static transforms are unconditionally published to the ``/tf_static`` topic, and that the static transforms are published in a ``transient_local`` Quality of Service. -This was the default behavior, and the behavior which the ``tf2_ros::TransformListener`` class expected before, so most code will not have to be changed. -Any code that was relying on ``robot_state_publisher`` to periodically publish static transforms to ``/tf`` will have to be updated to subscribe to ``/tf_static`` as a ``transient_local`` subscription instead. - - -rosidl_cmake -^^^^^^^^^^^^ - -Deprecation of ``rosidl_target_interfaces()`` -""""""""""""""""""""""""""""""""""""""""""""" - -The CMake function ``rosidl_target_interfaces()`` has been deprecated, and now issues a CMake warning when called. -Users wanting to use messages/services/actions in the same ROS package that generated them should instead call ``rosidl_get_typesupport_target()`` and then ``target_link_libraries()`` to make their targets depend on the returned typesupport target. -See https://github.com/ros2/rosidl/pull/606 for more details, and https://github.com/ros2/demos/pull/529 for an example of using the new function. - - -rviz2 -^^^^^ - -* `improved the efficiency of 3-bytes pixel formats `__ -* `changed the way inertias are computed to use ignition math rather than Ogre's math libraries `__. - - -geometry2 -^^^^^^^^^ - -Deprecation of TF2Error::NO_ERROR, etc -"""""""""""""""""""""""""""""""""""""" - -The ``tf2`` library uses an enumeration called ``TF2Error`` to return errors. -Unfortunately, one of the enumerators in there is called ``NO_ERROR``, which conflicts with a macro on Windows. -To remedy this, a new set of enumerators in ``TF2Error`` were created, each with a ``TF2`` prefix. -The previous enumerators are still available, but are now deprecated and will print a deprecation warning if used. -All code that uses the ``TF2Error`` enumerator should be updated to use the new ``TF2`` prefixed errors. -See https://github.com/ros2/geometry2/pull/349 for more details. - -More intuitive command-line arguments for static_transform_publisher -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The ``static_transform_publisher`` program used to take arguments like: ``ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 1 foo bar``. -The first three numbers are the translation x, y, and z, the next 4 are the quaternion x, y, z, and w, and the last two arguments are the parent and child frame IDs. -While this worked, it had a couple of problems: - -* The user had to specify *all* of the arguments, even if only setting one number -* Reading the command-line to figure out what it was publishing was tricky - -To fix both of these issues, the command-line handling has been changed to use flags instead, and all flags except for ``--frame-id`` and ``--child-frame-id`` are optional. -Thus, the above command-line can be simplified to: ``ros2 run tf2_ros static_transform_publisher --frame-id foo --child-frame-id bar`` -To change just the translation x, the command-line would be: ``ros2 run tf2_ros static_transform_publisher --x 1.5 --frame-id foo --child-frame-id bar``. - -The old-style arguments are still allowed in this release, but are deprecated and will print a warning. -They will be removed in future releases. -See https://github.com/ros2/geometry2/pull/392 for more details. - -Transform listener spin thread no longer executes node callbacks -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -``tf2_ros::TransformListener`` no longer spins on the provided node object. -Instead, it creates a callback group to execute callbacks on the entities it creates internally. -This means if you have set the parameter ``spin_thread=true`` when creating a transform listener, you -can no longer depend on your own callbacks to be executed. -You must call a ``spin`` function on your node (e.g. ``rclcpp::spin``), or add your node to your own executor. - -Related pull request: `geometry2#442 `_ - -rosbag2 -^^^^^^^ - -New playback and recording controls -""""""""""""""""""""""""""""""""""" - -Several pull requests have been added to enhance the user's control over playback of bags. -Pull request `931 `_ adds the ability to specify a time stamp to begin playing from. -Due to pull request `789 `_ it is now possible to delay the start of playback by a specified interval. - -Relatedly, ``rosbag2`` has gained new ways for users to control playback as it is happening. -Pull request `847 `_ adds keyboard controls for pausing, resuming, and playing the next message during playback from a terminal. -It is also possible to start playback paused thanks to pull requests `905 `_ and `904 `_, which makes it easy for the user to initiate playback and then step through messages, such as when debugging a pipeline. -Pull request `836 `_ adds an interface for seeking within bags, allowing the user to move around within a bag during playback. - -Finally, a new snapshot mode has been added to recording in pull request `851 `_. -This mode, useful for incident recording, allows recording to begin filling up buffers, but not begin writing data to disc until a service is called. - -Burst-mode playback -""""""""""""""""""" - -While the playback of data from a bag in real-time is the most well-known use case for bag files, there are situations where you want the data in the bag as fast as possible. -With pull request `977 `_, ``rosbag2`` has gained the ability to "burst" data from the bag. -In burst mode, the data is played back as fast as possible. -This is useful in applications such as machine learning. - -Zero-Copy playback -"""""""""""""""""" - -By default, if loaned message can be used, playback messages are published as loaned message. -This can help to reduce the number of data copies, so there is a greater benefit for sending big data. -Pull request `981 `_ adds ``--disable-loan-message`` option for playback. - -Wait for an acknowledgment -"""""""""""""""""""""""""" - -This new option will wait until all published messages are acknowledged by all subscribers or until the timeout elapses in millisecond before play is terminated. -Especially for the case of sending message with big size in a short time. -This option is valid only if the publisher's QOS profile is RELIABLE. -Pull request `951 `_ adds ``--wait-for-all-acked`` option for playback. - -Bag editing -""""""""""" - -``rosbag2`` is taking steps towards enabling the editing of bags, such as removing all messages for one topic or merging multiple bags into a single bag. -Pull request `921 `_ adds bag rewriting and the ``ros2 bag convert`` verb. - -Other changes -""""""""""""" - -Pull request `925 `_ makes ``rosbag2`` ignore "leaf topics" (topics without a publisher) when recording. -These topics will no longer be automatically added to the bag. - -Known Issues ------------- - -* When `installing ROS 2 on an Ubuntu 22.04 Jammy host <../../humble/Installation/Ubuntu-Install-Debians.html>`__ it is important to update your system before installing ROS 2 packages. - It is *particularly* important to make sure that ``systemd`` and ``udev`` are updated to the latest available version otherwise installing ``ros-humble-desktop``, which depends on ``libudev1``, could cause the removal of system critical packages. - Details can be found in `ros2/ros2#1272 `_ and `Launchpad #1974196 `_ - -* When ROS 2 apt repositories are available, ROS 1 packages in Ubuntu are not installable. See the :doc:`ros1_bridge on Ubuntu Jammy <../How-To-Guides/Using-ros1_bridge-Jammy-upstream>` document for more information. - -* Some major Linux distributions have started patching Python to install packages to ``/usr/local``, which is breaking some parts of ``ament_package`` and builds with ``colcon``. - In particular, using Ubuntu Jammy with ``setuptools`` installed from pip will manifest this misbehavior, and is therefore not recommended. - There is currently a `proposed solution `_ which requires further testing before widespread release. - -* ROS 2 bags that are split by size or duration are not played correctly. - Only the last bag recorded is played. - It is recommended to avoid splitting bags by size or duration. - Details can be found in `ros2/rosbag2#966 `__. - -Release Timeline ----------------- - - Mon. March 21, 2022 - Alpha + RMW freeze - Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. - - Mon. April 4, 2022 - Freeze - API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 18, 2022 - Branch - Branch from Rolling Ridley. - ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. - Humble development shifts from ``ros-rolling-*`` packages to ``ros-humble-*`` packages. - - Mon. April 25, 2022 - Beta - Updated releases of ROS Desktop [2]_ packages available. - Call for general testing. - - Mon. May 16, 2022 - Release Candidate - Release Candidate packages are built. - Updated releases of ROS Desktop [2]_ packages available. - - Thu. May 19, 2022 - Distro Freeze - Freeze rosdistro. - No PRs for Humble on the ``rosdistro`` repo will be merged (reopens after the release announcement). - - Mon. May 23, 2022 - General Availability - Release announcement. - ``rosdistro`` is reopened for Humble PRs. - -.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. +.. redirect-from:: + + Releases/Release-Humble-Hawksbill + +.. _humble-release: + +Humble Hawksbill (``humble``) +============================= + +.. toctree:: + :hidden: + + Humble-Hawksbill-Complete-Changelog + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Humble Hawksbill* is the eighth release of ROS 2. +What follows is highlights of the important changes and features in Humble Hawksbill since the last release. +For a list of all of the changes since Galactic, see the `long form changelog `. + +Supported Platforms +------------------- + +Humble Hawksbill supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 22.04 (Jammy): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019): ``amd64`` + +Tier 2 platforms: + +* RHEL 8: ``amd64`` + +Tier 3 platforms: + +* Ubuntu 20.04 (Focal): ``amd64`` +* macOS: ``amd64`` +* Debian Bullseye: ``amd64`` + +Targeted platforms: + ++--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ +| Architecture | Ubuntu Jammy (22.04) | Windows 10 (VS2019) | RHEL 8 | Ubuntu Focal (20.04) | macOS | Debian Bullseye (11) | OpenEmbedded / Yocto Project | ++==============+======================+=====================+==================+======================+============+======================+==============================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s] | Tier 3 [s] | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ +| arm64 | Tier 1 [d][a][s] | | | Tier 3 [s] | | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ +| arm32 | Tier 3 [s] | | | Tier 3 [s] | | Tier 3 [s] | Tier 3 [s] | ++--------------+----------------------+---------------------+------------------+----------------------+------------+----------------------+------------------------------+ + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be +provided for this platform for packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Humble ROS 2 repos file[^11]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=========================+===============+============================+===============================+ +| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64| ++--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32| ++--------------------------+-------------------------+---------------+----------------------------+-------------------------------+ + + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++17 +- Python 3.6 + +Dependency Requirements: + ++------------------+-------------------+-----------------------------------------------------------------------------------------------------------+ +| | Required Support | Recommended Support | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Package | Ubuntu | Windows| RHEL 8 | Ubuntu Focal | macOS** | Debian Bullseye | OpenEmbedded** | +| | Jammy | 10** | | | | | | ++==================+==========+========+========+==============+==========+==================+=====================================================+ +| CMake | 3.22.1 | 3.22.0 | 3.20.2 | 3.16.3 | 3.14.4 | 3.18.4 | 3.22.3 / 3.16.5*** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| EmPY | 3.3.4 | 3.3.2 | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Gazebo Classic | 11.x.x* | N/A | N/A | 11.0.0* | 11.x.x | 11.x.x* | N/A | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Gazebo (Ignition)| Fortress*| N/A | N/A | Fortress* | Fortress*| Fortress* | N/A | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| NumPy | 1.21.5 | 1.18.4 | 1.14.3 | 1.17.4 | 1.18.4 | 1.19.5 | N/A | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Ogre | 1.12.1* | N/A | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| OpenCV | 4.5.4 | 3.4.6* | 3.4.6 | 4.2.0 | 4.2.0 | 4.5.1 | 4.1.0 / 3.2.0*** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| OpenSSL | 1.1.1l | 1.1.1l | 1.1.1k | 1.1.1d | 1.1.1f | 1.1.1i | 1.1.1d / 1.1.1b*** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Python | 3.10.4 | 3.8.3 | 3.6.8 | 3.8.0 | 3.8.2 | 3.9.1 | 3.8.2 / 3.7.5*** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Qt | 5.15.3 | 5.12.12| 5.15.2 | 5.12.5 | 5.12.3 | 5.15.2 | 5.14.1 / 5.12.5*** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| | **Linux only** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| PCL | 1.12.1 | N/A | 1.11.1 | 1.10.0 | N/A | 1.11.1 | 1.10.0 | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| **RMW DDS Middleware Providers** | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Cyclone DDS | 0.9.x (Papillons) | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Fast-DDS | 2.6.x | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Connext DDS | 6.0.1 | N/A | 6.0.1 | N/A | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ +| Gurum DDS | 2.7.x | N/A | 2.7.x | N/A | ++------------------+----------+--------+--------+--------------+----------+------------------+-----------------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" means that the dependency may see multiple version changes, +because the dependency uses a package manager that continually updates +the dependency without a stable API. + +\" \*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- Windows: Chocolatey, pip +- macOS: Homebrew, pip +- RHEL: dnf +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Humble Hawksbill <../../humble/Installation.html>`__ + +Changes in Patch Release 1 (2022-11-23) +--------------------------------------- + +ros2topic +^^^^^^^^^ + +``now`` as keyword for ``builtin_interfaces.msg.Time`` and ``auto`` for ``std_msgs.msg.Header`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +``ros2 topic pub`` now allows to set a ``builtin_interfaces.msg.Time`` message to the current time via the ``now`` keyword. +Similarly, a ``std_msg.msg.Header`` message will be automatically generated when passed the keyword ``auto``. +This behavior matches that of ROS 1's ``rostopic`` (http://wiki.ros.org/ROS/YAMLCommandLine#Headers.2Ftimestamps) + +Related PR: `ros2/ros2cli#751 `_ + +New features in this ROS 2 release +---------------------------------- + +ament_cmake_gen_version_h +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Generating a C/C++ header with version info +""""""""""""""""""""""""""""""""""""""""""" +A new CMake function to generate a header with the package version info was added to the ``ament_cmake_gen_version_h`` in `ament/ament_cmake#377 `__. +Here's the simplest use case: + +.. code-block:: CMake + + project(my_project) + add_library(my_lib ...) + ament_generate_version_header(my_lib) + +It will generate a header with version info from the ``package.xml`` and make it available to targets that link against the ``my_lib`` library. + +How to include the header: + +.. code-block:: C + + #include + +Where the header is installed to: + +.. code-block:: cmake + + set(VERSION_HEADER ${CMAKE_INSTALL_PREFIX}/include/my_project/my_project/version.h) + +launch +^^^^^^ + +Scoping environment variables in group actions +"""""""""""""""""""""""""""""""""""""""""""""" + +Similar to launch configurations, now by default, the state of environment variables are scoped to group actions. + +For example, in the following launch files the executed processe will echo the value ``1`` (before Humble it would echo ``2``): + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: xml + + + + + + + + + + .. group-tab:: Python + + .. code-block:: python + + import launch + import launch.actions + + def generate_launch_description(): + return launch.LaunchDescription([ + launch.actions.SetEnvironmentVariable(name='FOO', value='1'), + launch.actions.GroupAction([ + launch.actions.SetEnvironmentVariable(name='FOO', value='2'), + ]), + launch.actions.ExecuteProcess(cmd=['echo', '$FOO'], output='screen', shell=True), + ]) + +If you would like disable scoping for launch configurations and and environment variables you can set the ``scoped`` argument (or attribute) to false. + +Related PR: `ros2/launch#601 `_ + +launch_pytest +""""""""""""" + +We've added a new package, ``launch_pytest``, that acts as an alternative to ``launch_testing``. +``launch_pytest`` is a simple pytest plugin that provides pytest fixtures to manage the lifetime of a launch service. + +Check out the `package README for details and examples. `_ + +Related PR: `ros2/launch#528 `_ + +Allow matching target actions with a callable +""""""""""""""""""""""""""""""""""""""""""""" + +Event handlers that take a target action object to match can now also take a callable instead to do the matching. + +Related PR: `ros2/launch#540 `_ + +Access to math module when evaluating Python expressions +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Inside ``PythonExpression`` substitutions (``eval``) we can now use symbols from Python's math module. +For example, + +.. code-block:: xml + + + + + +Related PR: `ros2/launch#557 `_ + +Boolean substitutions +""""""""""""""""""""" + +New substitutions ``NotSubstitution``, ``AndSubstitution``, and ``OrSubstitution`` provide a convenient way to perform logical operations, for example + +.. code-block:: xml + + + + + + + + + + + + + + + +Related PR: `ros2/launch#598 `_ + +New actions +""""""""""" + +* ``AppendEnvironmentVariable`` appends a value to an existing environment variable. + + * Related PR: `ros2/launch#543 `_ + +* ``ResetLaunchConfigurations`` resets any configuration applied to the launch configuration. + + * Related PR: `ros2/launch#515 `_ + +launch_ros +^^^^^^^^^^ + +Passing ROS arguments to node actions +""""""""""""""""""""""""""""""""""""" + +It is now possible to provide `ROS-specific node arguments <../../How-To-Guides/Node-arguments>` directly, without needing to use ``args`` with a leading ``--ros-args`` flag: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: xml + + + + + + .. group-tab:: YAML + + .. code-block:: yaml + + launch: + - node: + pkg: demo_nodes_cpp + exec: talker + ros_args: '--log-level debug' + +The corresponding parameter for the ``Node`` action in Python launch files is ``ros_arguments``: + +.. code-block:: python + + from launch import LaunchDescription + import launch_ros.actions + + def generate_launch_description(): + return LaunchDescription([ + launch_ros.actions.Node( + package='demo_nodes_cpp', + executable='talker', + ros_arguments=['--log-level', 'debug'], + ), + ]) + +Related PRs: `ros2/launch_ros#249 `_ and `ros2/launch_ros#253 `_. + +Frontend support for composable nodes +""""""""""""""""""""""""""""""""""""" + +We can now start node containers and load components into them from frontend launch files, for example: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: xml + + + + + + + + + + + .. group-tab:: YAML + + .. code-block:: yaml + + launch: + - node_container: + pkg: rclcpp_components + exec: component_container + name: my_container + namespace: '' + composable_node: + - pkg: composition + plugin: composition::Talker + name: talker + - load_composable_node: + target: my_container + composable_node: + - pkg: composition + plugin: composition::Listener + name: listener + +Related PR: `ros2/launch_ros#235 `_ + +Parameter substitution +"""""""""""""""""""""" + +The new ``ParameterSubstitution`` lets you substitute the value of a parameter set previously in launch with the ``SetParameter`` action. +For example, + +.. code-block:: xml + + + + + + +Related PR: `ros2/launch_ros#297 `_ + +New actions +""""""""""" + +* ``RosTimer`` acts like the launch ``TimerAction``, but uses a ROS clock (so it can use simulation time, for example). + + * Related PRs: `ros2/launch_ros#244 `_ and `ros2/launch_ros#264 `_ + +* ``SetParametersFromFile`` passes a ROS parameters file to all nodes in a launch file (including node components). + + * Related PRs: `ros2/launch_ros#260 `_ and `ros2/launch_ros#281 `_ + +SROS2 Security enclaves support Certificate Revocation Lists +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Certificate Revocation Lists (CRLs) are a concept where particular certificates can be revoked before their expiration. +As of Humble, it is now possible to put a CRL in an SROS2 security enclave and have it be honored. +See `the SROS2 tutorials `__ for an example of how to use it. + +Content Filtered Topics +^^^^^^^^^^^^^^^^^^^^^^^ + +Content Filtered Topics supports a more sophisticated subscription that indicates the subscriber does not want to necessarily see all values of each instance published under the Topic. +Content Filtered Topics can be used to request content-based subscriptions when underlying RMW implementation supports this feature. + +.. list-table:: RMW Content Filtered Topics support + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + +To learn more, see the `content_filtering `_ examples. + +Related design PR: `ros2/design#282 `_. + +ros2cli +^^^^^^^ + +``ros2 launch`` has a ``--launch-prefix`` argument +"""""""""""""""""""""""""""""""""""""""""""""""""" + +This allows passing a prefix to all executables in a launch file, which is useful in many debugging situations. +See the associated `pull request `__, as well as the :ref:`tutorial ` for more information. + +Relatedly, the ``--launch-prefix-filter`` command-line option was added to selectively add the prefix from ``--launch-prefix`` to executables. +See the `pull request `__ for more information. + +``ros2 topic echo`` has a ``--flow-style`` argument +""""""""""""""""""""""""""""""""""""""""""""""""""" + +This allows the user to force ``flow style`` for the YAML representation of data on a topic. +Without this option, the output from ``ros2 topic echo /tf_static`` could look something like: + +.. code-block:: + + transforms: + - header: + stamp: + sec: 1651172841 + nanosec: 433705575 + frame_id: single_rrbot_link3 + child_frame_id: single_rrbot_camera_link + transform: + translation: + x: 0.05 + y: 0.0 + z: 0.9 + rotation: + x: 0.0 + y: 0.0 + z: 0.0 + w: 1.0 + +With this option, the output would look something like: + +.. code-block:: + + transforms: [{header: {stamp: {sec: 1651172841, nanosec: 433705575}, frame_id: single_rrbot_link3}, child_frame_id: single_rrbot_camera_link, transform: {translation: {x: 0.05, y: 0.0, z: 0.9}, rotation: {x: 0.0, y: 0.0, z: 0.0, w: 1.0}}}] + +See the `PyYAML documentation `__ for more information. + +``ros2 topic echo`` can filter data based on message contents +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This allows the user to only print out data on a topic that matches a certain Python expression. +For instance, using the following argument will only print out string messages that start with 'foo': + +.. code-block:: + + ros2 topic echo --filter 'm.data.startswith("foo")` /chatter + +See the `pull request `__ for more information. + + +rviz2 +^^^^^ + +Apply textures to arbitrary triangle lists +"""""""""""""""""""""""""""""""""""""""""" + +We've added `the ability to apply textures defined via URI to arbitrary triangle lists using UV Coordinates `__. +Now we can create a gradient pull from a texture map instead of the default grayscale. +This will enable complex coloring of markers. +To use this, you should use the ``visualization_msgs/Marker.msg`` and fill the ``texture_resource``, ``texture``, ``uv_coordinates`` and ``mesh_file`` fields. +You can find more information `here `__. + +.. image:: images/triangle_marker_with_gradient.png + +Visualization of mass properties (including inertia) +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +We also added the ability to visualize inertias. To do this, you select enable 'Inertia' in the 'Mass Properties' under the robot model: + +.. image:: images/rviz_mass_inertia.png + +You can see an image of an inertia below. + +.. image:: images/tb4_inertia.png + +Visualize YUV images in RViz +"""""""""""""""""""""""""""" + +It is now possible to directly visualize YUV images inside of RViz, rather than having to convert to RGB first. +See `ros2/rviz#701 `__ for details. + +Allow rendering of objects > 100 meters +""""""""""""""""""""""""""""""""""""""" + +By default, RViz only renders objects that are within 100 meters of a camera. +A new configuration property called "Far Plane Distance" in the rviz camera plugin allows that rendering distance to be configured. + +.. image:: images/rviz2-far-plane-distance.png + +See `ros2/rviz#849 `__ for more information. + +Changes since the Galactic release +---------------------------------- + +C++ headers are installed in a subdirectory +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In ROS 2 releases prior to Humble, C++ headers for all packages were installed into a single include directory. +For instance, in Galactic, the directory structure looks like this (reduced for brevity): + +.. code:: + + /opt/ros/galactic/include/ + ├── rcl + │   ├── node.h + ├── rclcpp + │   ├── node.hpp + + +This structure can cause serious problems when trying to use overlays. +That is, it is very possible to get the wrong set of header files due to include directory order. +See https://colcon.readthedocs.io/en/released/user/overriding-packages.html for a detailed explanation of the problems. + +To help combat this, in Humble (and in all ROS 2 releases going forward), the directory structure has changed: + +.. code:: + + /opt/ros/humble/include + ├── rcl + │   └── rcl + │   ├── node.h + ├── rclcpp + │   └── rclcpp + │   ├── node.hpp + +Note that downstream packages that use these headers do *not* have to change; using ``#include `` works as it always did before. +However, when using IDEs that are looking for include directories, it may be necessary to add the individual include directories to the search path. + +See https://github.com/ros2/ros2/issues/1150 for more information, including the reasoning behind this change. + +common_interfaces +^^^^^^^^^^^^^^^^^ + +Support Textures and Embedded Meshes for Marker Messages +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +These two additions will improve the ability to both visualize data in new ways with standard messages and, simultaneously, enable the ability to track this data in rosbag. + +**Textures** bring the addition of three new fields to markers: + +.. code-block:: bash + + # Texture resource is a special URI that can either reference a texture file in + # a format acceptable to (resource retriever)[https://index.ros.org/p/resource_retriever/] + # or an embedded texture via a string matching the format: + # "embedded://texture_name" + string texture_resource + # An image to be loaded into the rendering engine as the texture for this marker. + # This will be used iff texture_resource is set to embedded. + sensor_msgs/CompressedImage texture + # Location of each vertex within the texture; in the range: [0.0-1.0] + UVCoordinate[] uv_coordinates + +RViz will fully support texture rendering through the embedded format. + +To those familiar with ``mesh_resource``, ``resource_retriever`` should be familiar. +This will allow the programmer to choose where they want to load data from, either a local file or a networked file. +In the interest of being able to record all data in a rosbag, the ability to embed the texture image is included. + +**Meshes** were modified in a similar way to add the ability to embed a raw Mesh file for the purpose of recording and are modified in a similar way. The Meshfile message has two fields: + +.. code-block:: bash + + # The filename is used for both debug purposes and to provide a file extension + # for whatever parser is used. + string filename + + # This stores the raw text of the mesh file. + uint8[] data + +The embedded ``Meshfile`` message is not yet supported in implementation. + +Related PRs: `ros2/common_interfaces#153 `_ `ros2/rviz#719 `_ + +Added ``PRISM`` type to SolidPrimitive +"""""""""""""""""""""""""""""""""""""" + +The ``SolidPrimitive`` message had a new ``PRISM`` type added, along with the appropriate metadata. +See `ros2/common_interfaces#167 `_ for more information. + +rmw +^^^ + +``struct`` type name suffix changed from ``_t`` to ``_s`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +To avoid type name duplication errors between ``struct`` type names and their ``typedef``-ed aliases when generating code documentation, the suffix for all ``struct`` type names has been changed from ``_t`` to ``_s``. +Aliases with ``_t`` suffixes remain in place. +Thus, this change is a breaking change only for code that uses full ``struct`` type specifiers i.e. ``struct type_name_t``. + +See `ros2/rmw#313 `__ for more details. + +rmw_connextdds +^^^^^^^^^^^^^^ + +Use Connext 6 by default +"""""""""""""""""""""""" + +By default, Humble Hawksbill uses Connext 6.0.1 as the DDS implementation for ``rmw_connextdds``. +It is still possible to use Connext 5.3.1 with ``rmw_connextdds``, but it must be rebuilt from source. + +rcl +^^^ + +``struct`` type name suffix changed from ``_t`` to ``_s`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +To avoid type name duplication errors between ``struct`` type names and their ``typedef``-ed aliases when generating code documentation, the suffix for all ``struct`` type names has been changed from ``_t`` to ``_s``. +Aliases with ``_t`` suffixes remain in place. +Thus, this change is a breaking change only for code that uses full ``struct`` type specifiers i.e. ``struct type_name_t``. + +See `ros2/rcl#932 `__ for more details. + +ROS_DISABLE_LOANED_MESSAGES environment variable added +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This environment variable can be used to disable loaned messages support, independently if the rmw supports them or not. +For more details, see the guide :doc:`Configure Zero Copy Loaned Messages <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages>`. + +rclcpp +^^^^^^ + +Support Type Adaption for Publishers and Subscriptions +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +After defining a type adapter, custom data structures can be used directly by publishers and subscribers, which helps to avoid additional work for the programmer and potential sources of errors. +This is especially useful when working with complex data types, such as when converting OpenCV's ``cv::Mat`` to ROS's ``sensor_msgs/msg/Image`` type. + +Here is an example of a type adapter that converts ``std_msgs::msg::String`` to ``std::string``: + +.. code-block:: cpp + + template<> + struct rclcpp::TypeAdapter< + std::string, + std_msgs::msg::String + > + { + using is_specialized = std::true_type; + using custom_type = std::string; + using ros_message_type = std_msgs::msg::String; + + static + void + convert_to_ros_message( + const custom_type & source, + ros_message_type & destination) + { + destination.data = source; + } + + static + void + convert_to_custom( + const ros_message_type & source, + custom_type & destination) + { + destination = source.data; + } + }; + +And an example of how the type adapter can be used: + +.. code-block:: cpp + + using MyAdaptedType = TypeAdapter; + + // Publish a std::string + auto pub = node->create_publisher(...); + std::string custom_msg = "My std::string" + pub->publish(custom_msg); + + // Pass a std::string to a subscription's callback + auto sub = node->create_subscription( + "topic", + 10, + [](const std::string & msg) {...}); + +To learn more, see the `publisher `_ and `subscription `_ examples, as well as a more complex `demo `_. +For more details, see `REP 2007 `_. + +``Client::asnyc_send_request(request)`` returns a ``std::future`` instead of a ``std::shared_future`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This change was implemented in `rclcpp#1734 `_. +This breaks API, as ``std::future::get()`` methods extracts the value from the future. +That means, if that method is called for a second time it will throw an exception. +That doesn't happen with a ``std::shared_future``, as its ``get()`` method returns a ``const &``. +Example: + +.. code-block:: cpp + + auto future = client->async_send_request(req); + ... + do_something_with_response(future.get()); + ... + do_something_else_with_response(future.get()); // this will throw an exception now!! + +should be updated to: + +.. code-block:: cpp + + auto future = client->async_send_request(req); + ... + auto response = future.get(); + do_something_with_response(response); + ... + do_something_else_with_response(response); + +If a shared future is needed, the ``std::future::share()`` method can be used. + +``wait_for_all_acked`` method added to ``Publisher`` +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +This new method will block until all messages in the publisher queue are acked by the matching subscriptions or the specified timeout expires. +It is only useful for reliable publishers, as in the case of best effort QoS there's no acking. +Examples: + +.. code-block:: cpp + + auto pub = node->create_publisher(...); + ... + pub->publish(my_msg); + ... + pub->wait_for_all_acked(); // or pub->wait_for_all_acked(timeout) + +For a more complete example, see `here `__. + +``get_callback_groups`` method removed from ``NodeBase`` and ``Node`` classes +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +``for_each_callback_group()`` method has replaced ``get_callback_groups()`` by providing a thread-safe way to access ``callback_groups_`` vector. +``for_each_callback_group()`` accepts a function as an argument, iterates over the stored callback groups, and calls the passed function to ones that are valid. + +For more details, please refer to this `pull request `_. + +``add_to_wait_set`` method from ``Waitable`` class changes its return type from ``bool`` to ``void`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +Before, classes derived from ``Waitable`` overriding ``add_to_wait_set`` were returning false when failing to add elements to the wait set, so the caller had to check this return value and throw or handle the error. +This error handling should now be done directly on ``add_to_wait_set`` method, throwing if necessary. +It is not required to return anything if no errors happened. +Thus, this is a breaking change for downstream uses of ``Waitable``. + +See `ros2/rclcpp#1612 `__ for more details. + +``get_notify_guard_condition`` method return type from ``NodeBaseInterface`` class changed +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +Now ``rclcpp`` uses the ``GuardCondition`` class wrapper around ``rcl_guard_condition_t``, so ``get_notify_guard_condition`` returns a reference to the node's ``rclcpp::GuardCondition``. +Thus, this is a breaking change for downstream uses of ``NodeBaseInterface`` and ``NodeBase``. + +See `ros2/rclcpp#1612 `__ for more details. + +``sleep_until`` and ``sleep_for`` methods added to ``Clock`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +Two new methods were added to allow sleeping on a particular clock in `ros2/rclcpp#1814 `__ and `ros2/rclcpp#1828 `__. +``Clock::sleep_until`` will suspend the current thread until the clock reaches a particular time. +``Clock::sleep_for`` will suspend the current thread until the clock advances a certain amount of time from when the method was called. +Both methods will wake early if the ``Context`` is shutdown. + +rclcpp_lifecycle +^^^^^^^^^^^^^^^^ + +Active and deactivate transitions of publishers will be triggered automatically +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Before, users needed to override ``LifecylceNode::on_activate()`` and ``LifecylceNode::on_deactivate()`` and call the similarly named methods on ``LifecyclePublisher`` to make the transition actually happen. +Now, ``LifecylceNode`` provides a default interface of these methods that already do this. +See the implementation of the ``lifecycle_talker`` node `here `__. + +rclpy +^^^^^ + +Managed nodes +""""""""""""" + +Lifecycle nodes support was added to rclpy. +A complete demo can be found `here `__. + +``wait_for_all_acked`` method added to ``Publisher`` +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +Similar to the feature added to rclcpp. + +``sleep_until`` and ``sleep_for`` methods added to ``Clock`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +Two new methods were added to allow sleeping on a particular clock in `ros2/rclpy#858 `__ and `ros2/rclpy#864 `__. +``sleep_until`` will suspend the current thread until the clock reaches a particular time. +``sleep_for`` will suspend the current thread until the clock advances a certain amount of time from when the method was called. +Both methods will wake early if the ``Context`` is shutdown. + +ros1_bridge +^^^^^^^^^^^ + +Since there is no official ROS 1 distribution on Ubuntu Jammy and forward, ``ros1_bridge`` is now compatible with the Ubuntu-packaged versions of ROS 1. +More details about using ``ros1_bridge`` with Jammy packages are available in :doc:`the how-to guides <../../Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream>`. + +ros2cli +^^^^^^^ + +``ros2`` commands disable output buffering by default +""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Prior to this release, running a command like + +.. code-block:: + + ros2 echo /chatter | grep "Hello" + +would not print any data until the output buffer was full. +Users could work around this by setting ``PYTHONUNBUFFERED=1``, but that was not very user friendly. + +Instead, all ``ros2`` commands now do line-buffering by default, so commands like the above work as soon as a newline is printed. +To disable this behavior and use default python buffering rules, use the option ``--use-python-default-buffering``. +See the `original issue `__ and the `pull request `__ for more information. + +``ros2 topic pub`` will wait for one matching subscription when using ``--times/--once/-1`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +When using ``--times/--once/-1`` flags, ``ros2 topic pub`` will wait for one matching subscription to be found before starting to publish. +This avoids the issue of the ros2cli node starting to publish before discovering a matching subscription, which results in some of the first messages being lost. +This is particularly unexpected when using a reliable qos profile. + +The number of matching subscriptions to wait before starting publishing can be configured with the ``-w/--wait-matching-subscriptions`` flags, e.g.: + +.. code-block:: console + + $ ros2 topic pub -1 -w 3 /chatter std_msgs/msg/String "{data: 'foo'}" + +to wait for three matching subscriptions before starting to publish. + +``-w`` can also be used independently of ``--times/--once/-1`` but it only defaults to one when combined with them, otherwise the ``-w`` default is zero. + +See https://github.com/ros2/ros2cli/pull/642 for more details. + +``ros2 param dump`` default output changed +"""""""""""""""""""""""""""""""""""""""""" + + * ``--print`` option for dump command was `deprecated `_. + + It prints to stdout by default: + + .. code-block:: console + + $ ros2 param dump /my_node_name + + * ``--output-dir`` option for dump command was `deprecated `_. + + To dump parameters to a file, run: + + .. code-block:: console + + $ ros2 param dump /my_node_name > my_node_name.yaml + +``ros2 param set`` now accepts more YAML syntax +""""""""""""""""""""""""""""""""""""""""""""""" + +Previously, attempting to set a string like "off" to a parameter that was of string type did not work. +That's because ``ros2 param set`` interprets the command-line arguments as YAML, and YAML considers "off" to be a boolean type. +As of https://github.com/ros2/ros2cli/pull/684 , ``ros2 param set`` now accepts the YAML escape sequence of "!!str off" to ensure that the value is considered a string. + +``ros2 pkg create`` can automatically generate a LICENSE file +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +If the ``--license`` flag is passed to ``ros2 pkg create``, and the license is one of the known licenses, ``ros2 pkg create`` will now automatically generate a LICENSE file in the root of the package. +For a list of known licenses, run ``ros2 pkg create --license ? ``. +See the associated `pull request `__ for more information. + +robot_state_publisher +^^^^^^^^^^^^^^^^^^^^^ + +Added ``frame_prefix`` parameter +"""""""""""""""""""""""""""""""" +A new parameter ``frame_prefix`` was added in `ros/robot_state_publisher#159 `__. +This parameter is a string which is prepended to all frame names published by ``robot_state_publisher``. +Similar to ``tf_prefix`` in the original ``tf`` library in ROS 1, this parameter can be used to publish the same robot description multiple times with different frame names. + +Removal of deprecated ``use_tf_static`` parameter +""""""""""""""""""""""""""""""""""""""""""""""""" + +The deprecated ``use_tf_static`` parameter has been removed from ``robot_state_publisher``. +This means that static transforms are unconditionally published to the ``/tf_static`` topic, and that the static transforms are published in a ``transient_local`` Quality of Service. +This was the default behavior, and the behavior which the ``tf2_ros::TransformListener`` class expected before, so most code will not have to be changed. +Any code that was relying on ``robot_state_publisher`` to periodically publish static transforms to ``/tf`` will have to be updated to subscribe to ``/tf_static`` as a ``transient_local`` subscription instead. + + +rosidl_cmake +^^^^^^^^^^^^ + +Deprecation of ``rosidl_target_interfaces()`` +""""""""""""""""""""""""""""""""""""""""""""" + +The CMake function ``rosidl_target_interfaces()`` has been deprecated, and now issues a CMake warning when called. +Users wanting to use messages/services/actions in the same ROS package that generated them should instead call ``rosidl_get_typesupport_target()`` and then ``target_link_libraries()`` to make their targets depend on the returned typesupport target. +See https://github.com/ros2/rosidl/pull/606 for more details, and https://github.com/ros2/demos/pull/529 for an example of using the new function. + + +rviz2 +^^^^^ + +* `improved the efficiency of 3-bytes pixel formats `__ +* `changed the way inertias are computed to use ignition math rather than Ogre's math libraries `__. + + +geometry2 +^^^^^^^^^ + +Deprecation of TF2Error::NO_ERROR, etc +"""""""""""""""""""""""""""""""""""""" + +The ``tf2`` library uses an enumeration called ``TF2Error`` to return errors. +Unfortunately, one of the enumerators in there is called ``NO_ERROR``, which conflicts with a macro on Windows. +To remedy this, a new set of enumerators in ``TF2Error`` were created, each with a ``TF2`` prefix. +The previous enumerators are still available, but are now deprecated and will print a deprecation warning if used. +All code that uses the ``TF2Error`` enumerator should be updated to use the new ``TF2`` prefixed errors. +See https://github.com/ros2/geometry2/pull/349 for more details. + +More intuitive command-line arguments for static_transform_publisher +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The ``static_transform_publisher`` program used to take arguments like: ``ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 1 foo bar``. +The first three numbers are the translation x, y, and z, the next 4 are the quaternion x, y, z, and w, and the last two arguments are the parent and child frame IDs. +While this worked, it had a couple of problems: + +* The user had to specify *all* of the arguments, even if only setting one number +* Reading the command-line to figure out what it was publishing was tricky + +To fix both of these issues, the command-line handling has been changed to use flags instead, and all flags except for ``--frame-id`` and ``--child-frame-id`` are optional. +Thus, the above command-line can be simplified to: ``ros2 run tf2_ros static_transform_publisher --frame-id foo --child-frame-id bar`` +To change just the translation x, the command-line would be: ``ros2 run tf2_ros static_transform_publisher --x 1.5 --frame-id foo --child-frame-id bar``. + +The old-style arguments are still allowed in this release, but are deprecated and will print a warning. +They will be removed in future releases. +See https://github.com/ros2/geometry2/pull/392 for more details. + +Transform listener spin thread no longer executes node callbacks +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +``tf2_ros::TransformListener`` no longer spins on the provided node object. +Instead, it creates a callback group to execute callbacks on the entities it creates internally. +This means if you have set the parameter ``spin_thread=true`` when creating a transform listener, you +can no longer depend on your own callbacks to be executed. +You must call a ``spin`` function on your node (e.g. ``rclcpp::spin``), or add your node to your own executor. + +Related pull request: `geometry2#442 `_ + +rosbag2 +^^^^^^^ + +New playback and recording controls +""""""""""""""""""""""""""""""""""" + +Several pull requests have been added to enhance the user's control over playback of bags. +Pull request `931 `_ adds the ability to specify a time stamp to begin playing from. +Due to pull request `789 `_ it is now possible to delay the start of playback by a specified interval. + +Relatedly, ``rosbag2`` has gained new ways for users to control playback as it is happening. +Pull request `847 `_ adds keyboard controls for pausing, resuming, and playing the next message during playback from a terminal. +It is also possible to start playback paused thanks to pull requests `905 `_ and `904 `_, which makes it easy for the user to initiate playback and then step through messages, such as when debugging a pipeline. +Pull request `836 `_ adds an interface for seeking within bags, allowing the user to move around within a bag during playback. + +Finally, a new snapshot mode has been added to recording in pull request `851 `_. +This mode, useful for incident recording, allows recording to begin filling up buffers, but not begin writing data to disc until a service is called. + +Burst-mode playback +""""""""""""""""""" + +While the playback of data from a bag in real-time is the most well-known use case for bag files, there are situations where you want the data in the bag as fast as possible. +With pull request `977 `_, ``rosbag2`` has gained the ability to "burst" data from the bag. +In burst mode, the data is played back as fast as possible. +This is useful in applications such as machine learning. + +Zero-Copy playback +"""""""""""""""""" + +By default, if loaned message can be used, playback messages are published as loaned message. +This can help to reduce the number of data copies, so there is a greater benefit for sending big data. +Pull request `981 `_ adds ``--disable-loan-message`` option for playback. + +Wait for an acknowledgment +"""""""""""""""""""""""""" + +This new option will wait until all published messages are acknowledged by all subscribers or until the timeout elapses in millisecond before play is terminated. +Especially for the case of sending message with big size in a short time. +This option is valid only if the publisher's QOS profile is RELIABLE. +Pull request `951 `_ adds ``--wait-for-all-acked`` option for playback. + +Bag editing +""""""""""" + +``rosbag2`` is taking steps towards enabling the editing of bags, such as removing all messages for one topic or merging multiple bags into a single bag. +Pull request `921 `_ adds bag rewriting and the ``ros2 bag convert`` verb. + +Other changes +""""""""""""" + +Pull request `925 `_ makes ``rosbag2`` ignore "leaf topics" (topics without a publisher) when recording. +These topics will no longer be automatically added to the bag. + +Known Issues +------------ + +* When `installing ROS 2 on an Ubuntu 22.04 Jammy host <../../humble/Installation/Ubuntu-Install-Debians.html>`__ it is important to update your system before installing ROS 2 packages. + It is *particularly* important to make sure that ``systemd`` and ``udev`` are updated to the latest available version otherwise installing ``ros-humble-desktop``, which depends on ``libudev1``, could cause the removal of system critical packages. + Details can be found in `ros2/ros2#1272 `_ and `Launchpad #1974196 `_ + +* When ROS 2 apt repositories are available, ROS 1 packages in Ubuntu are not installable. See the :doc:`ros1_bridge on Ubuntu Jammy <../../Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream>` document for more information. + +* Some major Linux distributions have started patching Python to install packages to ``/usr/local``, which is breaking some parts of ``ament_package`` and builds with ``colcon``. + In particular, using Ubuntu Jammy with ``setuptools`` installed from pip will manifest this misbehavior, and is therefore not recommended. + There is currently a `proposed solution `_ which requires further testing before widespread release. + +* ROS 2 bags that are split by size or duration are not played correctly. + Only the last bag recorded is played. + It is recommended to avoid splitting bags by size or duration. + Details can be found in `ros2/rosbag2#966 `__. + +Release Timeline +---------------- + + Mon. March 21, 2022 - Alpha + RMW freeze + Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. + + Mon. April 4, 2022 - Freeze + API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 18, 2022 - Branch + Branch from Rolling Ridley. + ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. + Humble development shifts from ``ros-rolling-*`` packages to ``ros-humble-*`` packages. + + Mon. April 25, 2022 - Beta + Updated releases of ROS Desktop [2]_ packages available. + Call for general testing. + + Mon. May 16, 2022 - Release Candidate + Release Candidate packages are built. + Updated releases of ROS Desktop [2]_ packages available. + + Thu. May 19, 2022 - Distro Freeze + Freeze rosdistro. + No PRs for Humble on the ``rosdistro`` repo will be merged (reopens after the release announcement). + + Mon. May 23, 2022 - General Availability + Release announcement. + ``rosdistro`` is reopened for Humble PRs. + +.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Iron-Irwini.rst b/source/Get-Started/Releases/Release-Iron-Irwini.rst index e9b9a6ebf35..30b1d3c0480 100644 --- a/source/Get-Started/Releases/Release-Iron-Irwini.rst +++ b/source/Get-Started/Releases/Release-Iron-Irwini.rst @@ -1,1020 +1,1024 @@ -.. _iron-release: - -Iron Irwini (``iron``) -====================== - -.. toctree:: - :hidden: - - Iron-Irwini-Complete-Changelog - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Iron Irwini* is the ninth release of ROS 2. -What follows is highlights of the important changes and features in Iron Irwini since the last release. -For a list of all of the changes since Humble, see the :doc:`long form changelog `. - -Supported Platforms -------------------- - -Iron Irwini supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 22.04 (Jammy): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019): ``amd64`` - -Tier 2 platforms: - -* RHEL 9: ``amd64`` - -Tier 3 platforms: - -* macOS: ``amd64`` -* Debian Bullseye: ``amd64`` - -Targeted platforms: - -+--------------+------------------+---------------+------------------+------------+-----------------+----------------+ -| Architecture | Ubuntu Jammy | Windows 10 | RHEL 9 | macOS | Debian Bullseye | OpenEmbedded / | -| | (22.04) | (VS2019) | | | (11) | Yocto Project | -+==============+==================+===============+==================+============+=================+================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s] | Tier 3 [s] | Tier 3 [s] | -+--------------+------------------+---------------+------------------+------------+-----------------+----------------+ -| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+------------------+---------------+------------------+------------+-----------------+----------------+ -| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+------------------+---------------+------------------+------------+-----------------+----------------+ - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be -provided for this platform for packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Iron ROS 2 repos file[^12]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=========================+===============+=============================+==============================+ -| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ -| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except | -| | | | | arm64 | -+--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except | -| | | | | arm32 | -+--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++17 -- Python 3.8 - -Dependency Requirements: - -+-------------------+-----------------------+-----------------------------------------------------------+ -| | Required Support | Recommended Support | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| Package | Ubuntu | Windows | RHEL 9 | macOS** | Debian | OpenEmbedded** | -| | Jammy | 10** | | | Bullseye | | -+===================+===========+===========+=========+===========+=================+===================+ -| CMake | 3.22.1 | 3.22.0 | 3.20.2 | 3.14.4 | 3.18.4 | 3.22.3 / 3.16.5***| -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| EmPY | 3.3.4 | 3.3.2 | 3.3.4 | 3.3.2 | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| Gazebo Classic | 11.x.x* | N/A | N/A | 11.x.x | 11.x.x* | N/A | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| Gazebo (Ignition) | Fortress* | N/A | N/A | Fortress* | Fortress* | N/A | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| NumPy | 1.21.5 | 1.18.4 | 1.20.1 | 1.18.4 | 1.19.5 | N/A | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| Ogre | 1.12.1* | N/A | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| OpenCV | 4.5.4 | 3.4.6* | 4.6.0 | 4.2.0 | 4.5.1 | 4.1.0 / 3.2.0*** | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| OpenSSL | 3.0.2 | 1.1.1l | 3.0.1 | 1.1.1f | 1.1.1i | 1.1.1d / 1.1.1b***| -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| Python | 3.10.6 | 3.8.3 | 3.9.14 | 3.10.8 | 3.9.1 | 3.8.2 / 3.7.5*** | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| Qt | 5.15.3 | 5.12.12 | 5.15.3 | 5.12.3 | 5.15.2 | 5.14.1 / 5.12.5***| -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| | **Linux only** | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| PCL | 1.12.1 | N/A | 1.12.0 | N/A | 1.11.1 | 1.10.0 | -+-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ -| **RMW DDS Middleware** | -+-------------------+-----------------------------------------------------------------------------------+ -| Cyclone DDS | 0.9 | -+-------------------+-----------------------------------------------------------------------------------+ -| Fast-DDS | 2.8 | -+-------------------+---------------------------------------------+-------------------------------------+ -| Connext DDS | 6.0.1 | N/A | -+-------------------+-----------------------+---------------------+-------------------------------------+ -| Gurum DDS | 2.8.x | N/A | -+-------------------+-----------------------+-----------------------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" means that the dependency may see multiple version changes, -because the dependency uses a package manager that continually updates -the dependency without a stable API. - -\" \*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt -- Windows: Chocolatey, pip -- macOS: Homebrew, pip -- RHEL: dnf -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Iron Irwini <../../iron/Installation.html>`__ - -New features in this ROS 2 release ----------------------------------- - -API documentation generation for Python packages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 has had automatic API documentation for C++ packages for several releases, e.g. https://docs.ros.org/en/rolling/p/rclcpp/generated/index.html. -Iron adds automatic API documentation for Python packages as well, e.g. https://docs.ros.org/en/rolling/p/rclpy/rclpy.html. - -See https://github.com/ros-infrastructure/rosdoc2/pull/28, https://github.com/ros-infrastructure/rosdoc2/pull/49, https://github.com/ros-infrastructure/rosdoc2/pull/51, and https://github.com/ros-infrastructure/rosdoc2/pull/52 for more details. - -Service introspection -^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to enable service introspection on a per-service basis. -When enabled, this allows users to see the metadata associated with the client requesting a service, the server accepting the request, the server sending the response, and the client accepting the response. -Optionally, the contents of the client/server requests/responses can also be introspected. -All of the information is published on a hidden topic generated from the name of the service. -So if the service is called ``/myservice``, then the information will be published on ``/myservice/_service_event``. - -Note that this functionality is disabled by default; to enable it, users must call ``configure_introspection`` after creating a service client or server. -There are examples showing how to do this in https://github.com/ros2/demos/tree/iron/demo_nodes_cpp/src/services (C++) and https://github.com/ros2/demos/blob/iron/demo_nodes_py/demo_nodes_py/services/introspection.py (Python). - -See `REP 2012 `__ and the tracking bug at https://github.com/ros2/ros2/issues/1285 for more information. - -Pre and post set parameter callback support -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For many releases now, users could register a callback to be called when parameters on a node were changed by an external entity (like ``ros2 param set``). -This callback could examine the changed parameter types and values, and reject the whole lot if one of them didn't meet certain criteria. -However, it could not modify the parameter list, nor should it have modified state (since there might be other callbacks after the set one that would reject the parameters). - -This release adds in a pre and post callback. -The callbacks are called in this order: - -* The "pre" set parameter callback, which can modify the list of parameters based on arbitrary criteria. -* The "set" parameter callback, which cannot modify the list and should only accept or reject the parameters based on their type and value (this is the existing callback). -* The "post" set parameter callback, which can make state changes based on parameters and is only called if the previous two callbacks are successful. - -There are examples of this in action in https://github.com/ros2/demos/blob/iron/demo_nodes_cpp/src/parameters/set_parameters_callback.cpp (C++) and https://github.com/ros2/demos/blob/iron/demo_nodes_py/demo_nodes_py/parameters/set_parameters_callback.py (Python). - -See https://github.com/ros2/rclcpp/pull/1947, https://github.com/ros2/rclpy/pull/966, and https://github.com/ros2/demos/pull/565 for more information. - -Improved discovery options -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Previous ROS 2 versions offered limited discovery options. -The default behavior for DDS based RMW implementations was to discover any node reachable via multicast. -It could be limited to the same machine by setting the environment variable ``ROS_LOCALHOST_ONLY``, but any additional configuration required configuring the middleware directly, usually via middleware specific XML files and environment variables. -ROS Iron retains the same default discovery behavior, but deprecates ``ROS_LOCALHOST_ONLY`` in favor of more granular options. - -* ``ROS_AUTOMATIC_DISCOVERY_RANGE`` controls how far ROS nodes will try to discover each other. Valid options are: - - * ``SUBNET`` - The default, and for DDS-based middlewares it will discover any node reachable via multicast. - * ``LOCALHOST`` - Will only try to discover other nodes on the same machine. - * ``OFF`` - Will not attempt to discover any other nodes automatically, even on the same machine. - * ``SYSTEM_DEFAULT`` - Will not change any discovery settings. This is useful when you already have custom settings for your middleware and don't want ROS to change them. - -* ``ROS_STATIC_PEERS`` - A semicolon (``;``) separated list of addresses that ROS should try to discover nodes on. This allows the user to connect to nodes on specifc machines (as long as their discovery range is not set to ``OFF``). - -For example, you might have several robots with ``ROS_AUTOMATIC_DISCOVERY_RANGE`` set to ``LOCALHOST`` so they don't communicate with each other. -When you want to connect RViz to one of them, you add it's address to ``ROS_STATIC_PEERS`` in your terminal. -Now you can use ROS 2 CLI and visualization tools to interact with the robot. - -See https://github.com/ros2/ros2/issues/1359 for more information about this feature. - -Matched events -^^^^^^^^^^^^^^ - -In addition to QoS events, matched events can be generated when any publisher and subscription establishes or drops the connection between them. -Users can provide each publisher and subscription with callback functions that are triggered by matched events and handle them in a way they see fit, similar to how messages received on a topic are handled. - -* publisher: this event happens when it finds a subscription which matches the topic and has compatible QoS or a connected subscription is disconnected. -* subscription: this event happens when it finds a publisher which matches the topic and has compatible QoS or a connected publisher is disconnected. - -See the tracking issue at https://github.com/ros2/rmw/issues/330 for more information. - -* C++ Demo of Matched Events: https://github.com/ros2/demos/blob/iron/demo_nodes_cpp/src/events/matched_event_detect.cpp -* Python Demo of Matched Events: https://github.com/ros2/demos/blob/iron/demo_nodes_py/demo_nodes_py/events/matched_event_detect.py - -External configuration services of loggers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to configure node logger levels remotely via a service. -When the ``enable_logger_service`` option is enabled during node creation, the ``set_logger_levels`` and ``get_logger_levels`` services will be available. - -Be advised that the ``enable_logger_service`` option is disabled by default, so the user needs to enable this option on node creation. - -See https://github.com/ros2/ros2/issues/1355 for more information. - -Type Description Distribution -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It is now possible to communicate information about the types of ROS 2 messages, so that systems with potentially-different types of the same name may discover their compatibility more transparently. -This umbrella of capabilities, which is defined by a subset of REP-2011: Evolving Message Types, has had many parts land in Iron. - -First, the introduction of the new package `type_description_interfaces `__ provides a common way to communicate the descriptions of ROS 2 communication interface types (msg, srv, action). - -Next, a method to hash type descriptions has been decided on, the ROS Interface Hashing Standard (RIHS) - starting with the first version RIHS01. -RIHS hashes are automatically calculated for all compiled ROS types at build time, and baked into the generated code so that they can be inspected. -These hashes are also communicated automatically during discovery, and included in ``rmw_topic_endpoint_info_t`` for graph introspection queries such as ``get_publishers_info_by_topic``. - -The full ``TypeDescription`` data structure, as well as the raw source text (such as ``.msg`` file) that were used to generate it are now baked in by default to the message libraries, so they can be used by ``typesupport`` or end users. -While we expect this data to provide value to most users, some users trying to minimize bytes in their install space can disable the feature when building ROS 2 Core by defining the CMake variable ``ROSIDL_GENERATOR_C_DISABLE_TYPE_DESCRIPTION_CODEGEN``. - -Finally, the new service ``type_description_interfaces/GetTypeDescription.srv`` has been defined to allow nodes, on encountering an unknown RIHS type hash, to request the full definition from the node advertising that type. -Work is in progress to provide this feature natively in ROS 2 Nodes, as an optional switch on node construction. -This feature has not yet shipped, but is expected to be backported into Iron sometime mid-2023. -Meanwhile, user nodes could implement this service indepedently, using the stable service interface. - -See `REP 2011 `__ for the design proposal. -See `Type Description Distribution `__ for tracking development on the feature set. - -Dynamic Types and Dynamic Messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Alongside the type description distribution feature mentioned above, is the ability to construct and access dynamically created types at runtime (i.e., dynamic types). -This feature is available in Iron for Fast DDS and ``rcl``, with new ``rmw`` interfaces for supporting the taking of messages as dynamic messages (i.e., messages built from or following the structure of the dynamic type). - -First, utilities were introduced into `rosidl `__ to aid in the construction and manipulation of type descriptions. - -Next, the `rosidl_dynamic_typesupport `__ package was written and provides a middleware-agnostic interface to construct dynamic types and dynamic messages at runtime. -Types can be constructed at runtime either programmatically, or by parsing a ``type_description_interfaces/TypeDescription`` message. - -.. note:: - - The ``rosidl_dynamic_typesupport`` library requires serialization support libraries to implement the middleware-specific dynamic type behavior. - A serialization support library for Fast DDS was implemented in `rosidl_dynamic_typesupport_fastrtps `__. - Ideally more middlewares will implement support libraries, expanding the number of middlewares that support this feature. - -Finally, to support the use of dynamic types and dynamic messages, new methods were added to `rmw `__ and `rcl `__ that support: - -- The ability to obtain of middleware-specific serialization support -- The ability to construct message type support at runtime that use dynamic types -- The ability to take dynamic messages using dynamic type - -Work is in progress to enable the use of dynamic types to create subscriptions in the client libraries (see the ``rclcpp`` issue below), though it is uncertain when the feature will land or be backported. -This will allow users to subscribe to topics whose type descriptions are only known at runtime. -In the meantime, users may write their own subscriptions that subscribe to dynamic types by using the new ``rmw`` and ``rcl`` features introduced as part of this feature set. - -See `REP 2011 `__ for the design proposal. -See `Dynamic Subscription `__ for tracking development on the feature set, with `rclcpp `__ needing the bulk of the work. - -``launch`` -^^^^^^^^^^ - -``PythonExpression`` now supports importing modules -""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to have a launch ``PythonExpression`` import modules before performing the evaluation. -This can be useful for pulling in additional functionality to be used when evaluating an expression. - -See https://github.com/ros2/launch/pull/655 for more information. - -``ReadyToTest`` can be called from an event handler -""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to register an event handler that uses ``ReadyToTest`` in its output. -This can be useful for doing things like downloading an asset before allowing a test to run. - -See https://github.com/ros2/launch/pull/665 for more information. - -Addition of ``AnySubstitution`` and ``AllSubstitution`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to specify a substitution to happen when any of the input arguments are true (``AnySubstitution``), or when all of the input arguments are true (``AllSubstitution``). - -See https://github.com/ros2/launch/pull/649 for more details. - -Addition of a new substitution to get the launch logging directory -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to use a substitution called ``LaunchLogDir`` to get the current logging directory for launch. - -See https://github.com/ros2/launch/pull/652 for more details. - -``launch_ros`` -^^^^^^^^^^^^^^ - -Add a ``LifecycleTransition`` action -"""""""""""""""""""""""""""""""""""" - -It is now possible to send a transition signal to a lifecycle node via the new ``LifeCycleTransition`` action. - -See https://github.com/ros2/launch_ros/pull/317 for more information. - -Add a ``SetROSLogDir`` action -""""""""""""""""""""""""""""" - -It is now possible to configure the directory used for logging via the ``SetROSLogDir`` action. - -See https://github.com/ros2/launch_ros/pull/325 for more information. - -Ability to specify a condition to a ``ComposableNode`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to specify a condition that must be satisfied in order for a ``ComposableNode`` to be inserted into its container. - -See https://github.com/ros2/launch_ros/pull/311 for more information. - -``launch_testing`` -^^^^^^^^^^^^^^^^^^ - -Timeout for process startup is now configurable -""""""""""""""""""""""""""""""""""""""""""""""" - -Prior to this release, the ``ReadyToTest`` action would wait exactly 15 seconds for processes to start up. -If the processes took longer than that, they would fail. -There is now a new decorator called ``ready_to_test_action_timeout`` that allows the user to configure the amount of time to wait for the processes to start. - -See https://github.com/ros2/launch/pull/625 for more information. - -``rclcpp`` -^^^^^^^^^^ - -Addition of a new paradigm for handling ``Node`` and ``LifecycleNode`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The ``Node`` and ``LifecycleNode`` classes are related in that they both provide the same base set of methods (though ``LifecycleNode`` provides additional methods as well). -Due to various implementation considerations, they are not derived from a common base class. - -This has led to some trouble for downstream code that wants to accept either a ``Node`` or a ``LifecycleNode``. -One solution is to have two method signatures, one that accepts a ``Node`` and one that accepts a ``LifecycleNode``. -The other, recommended solution is to have a method that accepts the "node interfaces" pointers that can be accessed from both classes, e.g. - -.. code-block:: C++ - - void do_thing(rclcpp::node_interfaces::NodeGraphInterface graph) - { - fprintf(stderr, "Doing a thing\n"); - } - - void do_thing(rclcpp::Node::SharedPtr node) - { - do_thing(node->get_node_graph_interface()); - } - - void do_thing(rclcpp::LifecycleNode::SharedPtr node) - { - do_thing(node->get_node_graph_interface()); - } - -This works, but can get a bit unwieldy when many node interfaces are needed. -To make this a bit better, there is now a new ``NodeInterfaces`` class that can be constructed to contain the interfaces, and then be used by other code. - -There are examples on how to use this in https://github.com/ros2/rclcpp/pull/2041. - -Introduction of a new executor type: the Events Executor -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The ``EventsExecutor`` from iRobot has been merged into the main ``rclcpp`` codebase. -This alternative executor implementation uses event-driven callbacks from the middleware implementations to fire callbacks at the ``rclcpp`` layer. -In addition to the push-based model, the ``EventsExecutor`` also moves timer management into a separate thread, which can allow for more accurate results and lower overhead, especially with many timers. - -The ``EventsExecutor`` has a substantial set of documentation and use-in-practice that make it a strong candidate for inclusion in the ``rclcpp`` codebase. -For information about the initial implementation proposal as well as performance benchmarks, see https://discourse.ros.org/t/ros2-middleware-change-proposal/15863. -For more information about the design, see the design PR: https://github.com/ros2/design/pull/305. - -Since the API is the same, trying the ``EventsExecutor`` is as straightforward as replacing your current Executor implementation (eg. ``SingleThreadedExecutor``): - -.. code-block:: C++ - - #include - using rclcpp::experimental::executors::EventsExecutor; - - EventsExecutor executor; - executor.add_node(node); - executor.spin(); - -**Note** The ``EventsExecutor`` and ``TimersManager`` are currently in the ``experimental`` namespace. -While it has been used as a standalone implementation for some time https://github.com/irobot-ros/events-executor, it was decided to use the ``experimental`` namespace for at least one release to give latitude in changing the API within the release. -Use caution as it will not be subject to the same API/ABI guarantees that the non-experimental code has. - -``rclpy`` -^^^^^^^^^ - -Ability to wait for another node to join the graph -"""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to wait for another node to join the network graph with code like the following: - -.. code-block:: Python - - node.wait_for_node('/fully_qualified_node_name') - -See https://github.com/ros2/rclpy/pull/930 for more information. - -Implementation of ``AsyncParameterClient`` -"""""""""""""""""""""""""""""""""""""""""" - -``rclpy`` now has an ``AsyncParameterClient`` class, bringing it to feature parity with ``rclcpp``. -This class is used to perform parameter actions on a remote node without blocking the calling node. - -See https://github.com/ros2/rclpy/pull/959 for more information and examples. - -Subscription callbacks can now optionally get the message info -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to register for a subscription callback with a function signature that takes both the message, and the message info, like: - -.. code-block:: Python - - def msg_info_cb(msg, msg_info): - print('Message info:', msg_info) - - node.create_subscription(msg_type=std_msgs.msg.String, topic='/chatter', qos_profile=10, callback=msg_info_cb) - -The message info structure contains various pieces of information like the sequence number of the message, the source and received timestamps, and the GID of the publisher. - -See https://github.com/ros2/rclpy/pull/922 for more information. - -Optional argument that hides assertions for messages class -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" -All message classes now include a new optional argument that allows the hiding of assertions for each field type from the message. -By default, assertions are hidden, which provides a performance improvement during runtime. -In order to enable the assertions for development/debugging purposes, you are given two choices: - -1. Define the environment variable ``ROS_PYTHON_CHECK_FIELDS`` to ``'1'`` (this would affect all the messages in your project): - -.. code-block:: Python - - import os - from std_msgs.msg import String - - os.environ['ROS_PYTHON_CHECK_FIELDS'] = '1' - new_message=String() - -2. Select the specific behavior for a single message by explicitly defining the new argument in the constructor: - -.. code-block:: Python - - from std_msgs.msg import String - - new_message=String(check_fields=True) - -See https://github.com/ros2/rosidl_python/pull/194 for more information. - -``ros2param`` -^^^^^^^^^^^^^ - -Option to timeout when waiting for a node with ``ros2 param`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to have the various ``ros2 param`` commands timeout by passing ``--timeout`` to the command. - -See https://github.com/ros2/ros2cli/pull/802 for more information. - -Deprecated options were removed -"""""""""""""""""""""""""""""""" - -``--output-dir`` and ``--print`` options with ``dump`` command have been removed. - -See https://github.com/ros2/ros2cli/pull/824 for more information. - -``ros2topic`` -^^^^^^^^^^^^^ - -``now`` as keyword for ``builtin_interfaces.msg.Time`` and ``auto`` for ``std_msgs.msg.Header`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -``ros2 topic pub`` now allows to set a ``builtin_interfaces.msg.Time`` message to the current time via the ``now`` keyword. -Similarly, a ``std_msg.msg.Header`` message will be automatically generated when passed the keyword ``auto``. -This behavior matches that of ROS 1's ``rostopic`` (http://wiki.ros.org/ROS/YAMLCommandLine#Headers.2Ftimestamps) - -Related PR: `ros2/ros2cli#749 `_ - -``ros2 topic pub`` can be configured to wait a maximum amount of time -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The command ``ros2 topic pub -w 1`` will wait for at least that number of subscribers before publishing a message. -This release adds in a ``--max-wait-time`` option so that the command will only wait a maximum amount of time before quitting if no subscribers are seen. - -See https://github.com/ros2/ros2cli/pull/800 for more information. - -``ros2 topic echo`` can be configured to wait a maximum amount of time -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The command ``ros2 topic echo`` now accepts a ``--timeout`` option, which controls the maximum amount of time that the command will wait for a publication to happen. - -See https://github.com/ros2/ros2cli/pull/792 for more information. - -Deprecated option was removed -""""""""""""""""""""""""""""" - -``--lost-messages`` option with ``echo`` command has been removed. - -See https://github.com/ros2/ros2cli/pull/824 for more information. - -Changes since the Humble release --------------------------------- - -Change to the default console logging file flushing behavior -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This specifically applies to the default ``spdlog`` based logging backend in ROS 2, implemented in ``rcl_logging_spdlog``. -Log file flushing was changed to flush every time an "error" log message is used, e.g. each ``RCLCPP_ERROR()`` call, and also periodically every five seconds. - -Previously, ``spdlog`` was used without configuring anything other than creating the sink for logging to a file. - -We tested the change and did not find that the CPU overhead was significant, even on machines with slow disks (e.g. sd cards). -However, if this change is causing you problems, you can get the old behavior by setting the ``RCL_LOGGING_SPDLOG_EXPERIMENTAL_OLD_FLUSHING_BEHAVIOR=1`` environment variable. - -Later we would like to have support for a full configuration file (see: https://github.com/ros2/rcl_logging/issues/92), giving you more flexibility in how the logging is done, but that is work that is only planned right now. - - Therefore, **this environment variable should be considered experimental and subject to removal without deprecation in the future**, when we add config file support for the ``rcl_logging_spdlog`` logging backend. - -See this pull request for more details about the change: https://github.com/ros2/rcl_logging/pull/95 - -``ament_cmake_auto`` -^^^^^^^^^^^^^^^^^^^^ - -Include dependencies are now marked as SYSTEM -""""""""""""""""""""""""""""""""""""""""""""" - -When using ``ament_auto_add_executable`` or ``ament_auto_add_library``, dependencies are now automatically added as ``SYSTEM``. -This means that warnings in the header files of the dependencies will not be reported. - -See https://github.com/ament/ament_cmake/pull/385 for more details. - -``ament_cmake_nose`` -^^^^^^^^^^^^^^^^^^^^ - -Package has been deprecated and removed -""""""""""""""""""""""""""""""""""""""" - -The Python ``nose`` package has long been deprecated. -Since none of the open-source packages currently released into Humble or Rolling currently depend on it, this release deprecates and removes the ament wrapper around it. - -See https://github.com/ament/ament_cmake/pull/415 for more information. - -``ament_lint`` -^^^^^^^^^^^^^^ - -Files can be excluded from linter checks -"""""""""""""""""""""""""""""""""""""""" - -Certain files can now be excluded from linter checks by setting the ``AMENT_LINT_AUTO_FILE_EXCLUDE`` CMake variable before calling ``ament_lint_auto_find_test_dependencies``. - -See https://github.com/ament/ament_lint/pull/386 for more information. - -``camera_info_manager`` -^^^^^^^^^^^^^^^^^^^^^^^ - -Lifecycle node support -"""""""""""""""""""""" - -``camera_info_manager`` now supports lifecycle nodes in additional to regular ROS 2 nodes. - -See https://github.com/ros-perception/image_common/pull/190 for more information. - -``launch`` -^^^^^^^^^^ - -``LaunchConfigurationEquals`` and ``LaunchConfigurationNotEquals`` are deprecated -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The ``LaunchConfigurationEquals`` and ``LaunchConfigurationNotEquals`` conditions are deprecated, and will be removed in a future release. -Instead, the more universal ``Equals`` and ``NotEquals`` substitutions should be used instead. - -See https://github.com/ros2/launch/pull/649 for more details. - -``launch_ros`` -^^^^^^^^^^^^^^ - -Renamed classes which used ``Ros`` in the name to use ``ROS`` in line with PEP8 -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Classes that were changed: - -* ``launch_ros.actions.RosTimer`` -> ``launch_ros.actions.ROSTimer`` -* ``launch_ros.actions.PushRosNamespace`` -> ``launch.actions.PushROSNamespace`` - -The old class names are still there, but will be deprecated. - -See https://github.com/ros2/launch_ros/pull/326 for more information. - -``launch_xml`` -^^^^^^^^^^^^^^ - -Expose ``emulate_tty`` to XML frontend -"""""""""""""""""""""""""""""""""""""" - -It has been possible for several releases to have the ``launch`` Python code use pseudo-terminals to emulate a TTY (and hence do things like print colors). -That functionality is now available in the XML frontend by passing the ``emulate_tty`` argument to an executable command. - -See https://github.com/ros2/launch/pull/669 for more information. - -Expose ``sigterm_timeout`` and ``sigkill_timeout`` to XML frontend -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It has been possible for several releases to configure the maximum timeout value for the SIGTERM and SIGKILL signals in the ``launch`` Python code. -That functionality is now available in the XML frontend by passing the ``sigterm_timeout`` or ``sigkill_timeout`` argument to an executable command. - -See https://github.com/ros2/launch/pull/667 for more information. - -``launch_yaml`` -^^^^^^^^^^^^^^^ - -Expose ``emulate_tty`` to YAML frontend -""""""""""""""""""""""""""""""""""""""" - -It has been possible for several releases to have the ``launch`` Python code use pseudo-terminals to emulate a TTY (and hence do things like print colors). -That functionality is now available in the YAML frontend by passing the ``emulate_tty`` argument to an executable command. - -See https://github.com/ros2/launch/pull/669 for more information. - -Expose ``sigterm_timeout`` and ``sigkill_timeout`` to YAML frontend -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It has been possible for several releases to configure the maximum timeout value for the SIGTERM and SIGKILL signals in the ``launch`` Python code. -That functionality is now available in the YAML frontend by passing the ``sigterm_timeout`` or ``sigkill_timeout`` argument to an executable command. - -See https://github.com/ros2/launch/pull/667 for more information. - -``message_filters`` -^^^^^^^^^^^^^^^^^^^ - -New approximate time policy -""""""""""""""""""""""""""" - -Add in a simpler approximate time policy called ``ApproximateEpsilonTime``. -This time policy works like ``ExactTime``, but allows timestamps being within a epsilon tolerance. -See https://github.com/ros2/message_filters/pull/84 for more information. - -New upsampling time policy -"""""""""""""""""""""""""" - -Adds in a new time policy called ``LatestTime``. -It can synchronize up to 9 messages by their rates with upsampling via zero-order-hold. -See https://github.com/ros2/message_filters/pull/73 for more information. - -``rcl_yaml_param_parser`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Support for YAML ``!!str`` syntax in parameter files -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to force the ROS parameter file parser to interpret a field as a string using the YAML ``!!str`` syntax. -See https://github.com/ros2/rcl/pull/999 for more information. - -``rclcpp`` -^^^^^^^^^^ - -Default number of threads for multi-threaded executor has been changed -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -If the user doesn't specify otherwise, the default number of threads for the multi-threaded executor will be set to the number of CPUs on the machine. -If the underlying OS doesn't support getting this information, it will be set to 2. - -See https://github.com/ros2/rclcpp/pull/2032 for more information. - -A warning is now printed when QoS of KEEP_LAST is specified with a depth of 0 -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Specifying a QoS of KEEP_LAST with a depth of 0 is a nonsensical arrangement, since the entity wouldn't be able to send or receive any data. -``rclcpp`` will now print a warning if this combination is specified, but will still continue on and let the underlying middleware choose a sane value (generally a depth of 1). - -See https://github.com/ros2/rclcpp/pull/2048 for more information. - -Deprecated ``RCLCPP_SCOPE_EXIT`` macro was removed -"""""""""""""""""""""""""""""""""""""""""""""""""" - -In Humble, the macro ``RCLCPP_SCOPE_EXIT`` was deprecated in favor of ``RCPPUTILS_SCOPE_EXIT``. -In Iron, the ``RCLCPP_SCOPE_EXIT`` macro has been completely removed. - -``rclpy`` -^^^^^^^^^ - -Default number of threads for multi-threaded executor has been changed -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -If the user doesn't specify otherwise, the default number of threads for the multi-threaded executor will be set to the number of CPUs on the machine. -If the underlying OS doesn't support getting this information, it will be set to 2. - -See https://github.com/ros2/rclpy/pull/1031 for more information. - -A warning is now printed when QoS of KEEP_LAST is specified with a depth of 0 -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Specifying a QoS of KEEP_LAST with a depth of 0 is a nonsensical arrangement, since the entity wouldn't be able to send or receive any data. -``rclpy`` will now print a warning if this combination is specified, but will still continue on and let the underlying middleware choose a sane value (generally a depth of 1). - -See https://github.com/ros2/rclpy/pull/1048 for more information. - -Time and Duration no longer raise exception when compared to another type -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to compare ``rclpy.time.Time`` and ``rclpy.duration.Duration`` to other types without getting exceptions. -If the types are not comparable, the comparison returns ``False``. -Note that this is a behavior change from previous releases. - -.. code-block:: Python - - print(None in [rclpy.time.Time(), rclpy.duration.Duration()]) # Prints "False" instead of raising TypeError - -See https://github.com/ros2/rclpy/pull/1007 for more information. - -``rcutils`` -^^^^^^^^^^^ - -Improve the performance of message logging -"""""""""""""""""""""""""""""""""""""""""" - -The code used to output a log message when ``RCUTILS_LOG_*`` or ``RCLCPP_*`` was optimized to reduce overhead. -These log messages should now be more efficient, though they should still not be called at high rates. -See https://github.com/ros2/rcutils/pull/381, https://github.com/ros2/rcutils/pull/372, https://github.com/ros2/rcutils/pull/369, and https://github.com/ros2/rcutils/pull/367 for more information. - -Deprecated ``rcutils/get_env.h`` header was removed -""""""""""""""""""""""""""""""""""""""""""""""""""" - -In Humble, the header ``rcutils/get_env.h`` was deprecated in favor of ``rcutils/env.h``. -In Iron, the ``rcutils/get_env.h`` header been completely removed. - -``rmw`` -^^^^^^^ - -Change the GID storage to 16 bytes -"""""""""""""""""""""""""""""""""" - -The GID in the RMW layer is meant to be a globally unique identifier for writers in the ROS graph. -Previously, this was erroneously set to 24 bytes based on a bug in an old RMW implementation. -But the ``rmw`` package should define this, and all of the implementations should conform to that. -Thus, this release defines it as 16 bytes (the DDS standard), and changes all implementations to use that definition. - -See https://github.com/ros2/rmw/pull/345 and the (closed, but relevant) https://github.com/ros2/rmw/pull/328 for more information. - -``rmw_dds_common`` -^^^^^^^^^^^^^^^^^^ - -Change the GID storage to 16 bytes -"""""""""""""""""""""""""""""""""" - -Along with the change in the ``rmw`` layer, change the message that sends out GID information to 16 bytes. - -See https://github.com/ros2/rmw_dds_common/pull/68 for more information. - -``ros2topic`` -^^^^^^^^^^^^^ - -``ros2 topic hz/bw/pub`` now respect ``use_sim_time`` -""""""""""""""""""""""""""""""""""""""""""""""""""""" - -When running under simulation, the ROS 2 ecosystem generally gets its time from a ``/clock`` topic published by the simulator (rather than using the system clock). -ROS 2 nodes are typically informed of this change by setting the ``use_sim_time`` parameter on the node. -The node created by the ``ros2 topic`` commands ``hz``, ``bw``, and ``pub`` now respect that parameter and will use simulation time as appropriate. - -See https://github.com/ros2/ros2cli/pull/754 for more information. - -``rosbag2`` -^^^^^^^^^^^ - -Change default bag file type to ``mcap`` -"""""""""""""""""""""""""""""""""""""""" - -Prior to this release, by default rosbag2 would record data into sqlite3 databases. -During testing, it was found that in many cases this was not performant enough and lacked certain features desirable for offline processing. - -To meet these needs, a new bag format (influenced by the original ROS 1 bag file format) called ``mcap`` was developed. -This bag file format has many of the missing features from the sqlite3 file format, and should also be more performant. - -This release switches to using ``mcap`` as the default file format for writing new bags. -The old ``sqlite3`` file format is still available and can be selected by the user for writing if desired. -This release also allows playing back data from either the ``sqlite3`` file format or the ``mcap`` file format. - -See https://github.com/ros2/rosbag2/pull/1160 for more information. - -Store message definitions in bag files with SQLite3 plugin -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Now we support saving message definitions to the ``sqlite3`` database file in the same format -as we are saving it to the ``mcap`` file. -This opens an opportunity for third-party tools to have -the ability to deserialize rosbag2 files without having the correct version of all the original -.msg files on the machine that is decoding the bag file recorded with ``sqlite3`` plugin. - -See https://github.com/ros2/rosbag2/issues/782 and https://github.com/ros2/rosbag2/pull/1293 for -more information. - - -New playback and recording controls -""""""""""""""""""""""""""""""""""" - -Several pull requests have been added to enhance the user's control over playback of bags. -Pull request `960 `_ adds the ability to play bag for -a specified number of seconds. -And pull request `1005 `_ allows to play bag until specified timestamp. -Another pull request `1007 `_ adds the ability to -stop playback remotely via service call. -Stop will unpause player if it was in pause mode, stop playback and force exit from play() method if it was in progress. - -Managing recording via service calls -"""""""""""""""""""""""""""""""""""" - -There are new options to control the recording process from remote nodes. -The pull request `1131 `_ adds the ability to pause and -resume recording via service calls. -Another pull request `1115 `_ adds the ability to split -bags during recording by sending service call. - -Filtering topics via regular expression during playback -""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Users sometimes need to replay only a subset of topics from recorded bags and the following two pull request -adds such capability. -Pull request `1034 `_ adds a new option -``--topics-regex`` that allows filtering topics via regular expressions. -The ``--topics-regex`` option accepts multiple regular expressions separated by space. -And pull request `1046 `_ adds the ability to exclude some -certain topics from being replayed by providing regular expression in a new ``--exclude`` -(and ``-x``) option. - -Allow plugins to register their own CLI verb arguments -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Pull request `1209 `_ adds the ability for ``rosbag2`` plugins to -register an optional Python entrypoint providing plugin-specific CLI argument values. -As a result the command line option ``--storage-preset-profile`` for ``ros2 bag record`` verb will have -different valid options depending on the underlying storage plugin. - -Other changes -""""""""""""" - -The pull request `1038 `_ adds the ability to record -any key/value pair in 'custom' field in metadata.yaml file. -It is useful when users need to save some hardware specific id or coordinates where the recording was captured. -And pull request `1180 `_ adds an option to change the underlying -node name for the recorder via providing the new command line ``--node-name`` option. -This option might be used for creating remote distributed recording with multiple rosbag2 recorder instances. -It provides the ability to send service calls for managing the recording process to the dedicated -rosbag2 recorder instances. - -``rosidl_python`` -^^^^^^^^^^^^^^^^^ - -Modification of content of ``__slots__`` attribute -"""""""""""""""""""""""""""""""""""""""""""""""""" - -So far, the attribute ``__slots__`` from the python message classes, have been used as the member that contains the field names of the message. -In Iron, this attribute no longer contains only the field names from the message structure, but the field names for all the class members. -Therefore, users shouldn't rely on this attribute to retrieve the field names information, instead, users should retrieve it using the method ``get_field_and_field_types()``. - -See https://github.com/ros2/rosidl_python/pull/194 for more information. - -``rviz`` -^^^^^^^^ - -Map display can now be shown as binary -"""""""""""""""""""""""""""""""""""""" - -The RViz map display can now display the map as binary, with a settable threshold. -This is useful in some cases to inspect maps or in combination with planners that have a settable threshold. - -See https://github.com/ros2/rviz/pull/846 for more information. - -Camera display plugin respects the ROI in the CameraInfo message -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The CameraDisplay plugin now honors the region-of-interest (ROI) settings in the CameraInfo message, if it is provided. -This accounts for the fact that an image was cropped by the camera driver to reduce the bandwidth. - -See https://github.com/ros2/rviz/pull/864 for more information. - -Binary STL files from SOLIDWORKS work without error -""""""""""""""""""""""""""""""""""""""""""""""""""" - -A change was made to the STL loader such that it accepts binary STL files from SOLIDWORKS that have the word "solid" in them. -This technically violates the STL specification, but is common enough that a special case is added to handle these files. - -See https://github.com/ros2/rviz/pull/917 for more information. - -``tracetools`` -^^^^^^^^^^^^^^ - -Tracing instrumentation is now included by default on Linux -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -The ROS 2 core has had tracing instrumentation for a while now. -However, it was compiled out by default. -To get the instrumentation, the LTTng tracer had to be manually installed before rebuilding ROS 2 from source. -In Iron, the tracing instrumentation and tracepoints are included by default; the LTTng tracer is therefore now a ROS 2 dependency. - -Note that this only applies to Linux. - -See https://github.com/ros2/ros2_tracing/pull/31 and https://github.com/ros2/ros2/issues/1177 for more information. -See :doc:`this how-to guide to remove the instrumentation (or add the instrumentation with Humble and older) <../How-To-Guides/Building-ROS-2-with-Tracing>`. - -New tracepoints for ``rclcpp`` intra-process are added -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -New tracepoints have been added to support ``rclcpp`` intra-process communication. -This allows the evaluation of the time between the message publishing and the callback start in intra-process communication. - -See https://github.com/ros2/ros2_tracing/pull/30 and https://github.com/ros2/rclcpp/pull/2091 for more information. - -Known Issues ------------- - -* ``rmw_connextdds`` does not work with Windows Binary release packages. - RTI is not longer distributing ``RTI ConnextDDS 6.0.1`` which was used by the packaging jobs to create the binaries for Windows. - Instead they now distribute ``RTI ConnextDDS 6.1.0`` which is ABI incompatible with the generated binaries. - The solution is to rely on source builds of ROS 2 and ``rmw_connextdds`` on Windows. - -* ``sros2`` on Windows requires users to downgrade the ``cryptography`` python module to ``cryptography==38.0.4`` as discussed `here `_. - -* ``ros1_bridge`` does not work with ROS Noetic packages from `upstream Ubuntu `_. The suggested workaround is to build ROS Noetic from sources, then build the ``ros1_bridge`` using that. - -Release Timeline ----------------- - - November, 2022 - Platform decisions - REP 2000 is updated with the target platforms and major dependency versions. - - By January, 2023 - Rolling platform shift - Build farm is updated with the new platform versions and dependency versions for Iron Irwini (if necessary). - - Mon. April 10, 2023 - Alpha + RMW freeze - Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. - - Mon. April 17, 2023 - Freeze - API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 24, 2023 - Branch - Branch from Rolling Ridley. - ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. - Iron development shifts from ``ros-rolling-*`` packages to ``ros-iron-*`` packages. - - Mon. May 1, 2023 - Beta - Updated releases of ROS Desktop [2]_ packages available. - Call for general testing. - - Mon. May 15, 2023 - Release Candidate - Release Candidate packages are built. - Updated releases of ROS Desktop [2]_ packages available. - - Thu. May 18, 2023 - Distro Freeze - Freeze rosdistro. - No PRs for Iron on the ``rosdistro`` repo will be merged (reopens after the release announcement). - - Tue. May 23, 2023 - General Availability - Release announcement. - ``rosdistro`` is reopened for Iron PRs. - -.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. - -Development progress --------------------- - -For progress on the development and release of Iron Irwini, see `the tracking GitHub issue `__. - -For the broad process followed by Iron Irwini, see the :doc:`process description page `. +.. redirect-from:: + + Releases/Release-Iron-Irwini + +.. _iron-release: + +Iron Irwini (``iron``) +====================== + +.. toctree:: + :hidden: + + Iron-Irwini-Complete-Changelog + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Iron Irwini* is the ninth release of ROS 2. +What follows is highlights of the important changes and features in Iron Irwini since the last release. +For a list of all of the changes since Humble, see the :doc:`long form changelog `. + +Supported Platforms +------------------- + +Iron Irwini supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 22.04 (Jammy): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019): ``amd64`` + +Tier 2 platforms: + +* RHEL 9: ``amd64`` + +Tier 3 platforms: + +* macOS: ``amd64`` +* Debian Bullseye: ``amd64`` + +Targeted platforms: + ++--------------+------------------+---------------+------------------+------------+-----------------+----------------+ +| Architecture | Ubuntu Jammy | Windows 10 | RHEL 9 | macOS | Debian Bullseye | OpenEmbedded / | +| | (22.04) | (VS2019) | | | (11) | Yocto Project | ++==============+==================+===============+==================+============+=================+================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s] | Tier 3 [s] | Tier 3 [s] | ++--------------+------------------+---------------+------------------+------------+-----------------+----------------+ +| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+------------------+---------------+------------------+------------+-----------------+----------------+ +| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+------------------+---------------+------------------+------------+-----------------+----------------+ + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be +provided for this platform for packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Iron ROS 2 repos file[^12]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=========================+===============+=============================+==============================+ +| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ +| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except | +| | | | | arm64 | ++--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except | +| | | | | arm32 | ++--------------------------+-------------------------+---------------+-----------------------------+------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++17 +- Python 3.8 + +Dependency Requirements: + ++-------------------+-----------------------+-----------------------------------------------------------+ +| | Required Support | Recommended Support | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| Package | Ubuntu | Windows | RHEL 9 | macOS** | Debian | OpenEmbedded** | +| | Jammy | 10** | | | Bullseye | | ++===================+===========+===========+=========+===========+=================+===================+ +| CMake | 3.22.1 | 3.22.0 | 3.20.2 | 3.14.4 | 3.18.4 | 3.22.3 / 3.16.5***| ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| EmPY | 3.3.4 | 3.3.2 | 3.3.4 | 3.3.2 | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| Gazebo Classic | 11.x.x* | N/A | N/A | 11.x.x | 11.x.x* | N/A | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| Gazebo (Ignition) | Fortress* | N/A | N/A | Fortress* | Fortress* | N/A | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| NumPy | 1.21.5 | 1.18.4 | 1.20.1 | 1.18.4 | 1.19.5 | N/A | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| Ogre | 1.12.1* | N/A | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| OpenCV | 4.5.4 | 3.4.6* | 4.6.0 | 4.2.0 | 4.5.1 | 4.1.0 / 3.2.0*** | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| OpenSSL | 3.0.2 | 1.1.1l | 3.0.1 | 1.1.1f | 1.1.1i | 1.1.1d / 1.1.1b***| ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| Python | 3.10.6 | 3.8.3 | 3.9.14 | 3.10.8 | 3.9.1 | 3.8.2 / 3.7.5*** | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| Qt | 5.15.3 | 5.12.12 | 5.15.3 | 5.12.3 | 5.15.2 | 5.14.1 / 5.12.5***| ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| | **Linux only** | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| PCL | 1.12.1 | N/A | 1.12.0 | N/A | 1.11.1 | 1.10.0 | ++-------------------+-----------+-----------+---------+-----------+-----------------+-------------------+ +| **RMW DDS Middleware** | ++-------------------+-----------------------------------------------------------------------------------+ +| Cyclone DDS | 0.9 | ++-------------------+-----------------------------------------------------------------------------------+ +| Fast-DDS | 2.8 | ++-------------------+---------------------------------------------+-------------------------------------+ +| Connext DDS | 6.0.1 | N/A | ++-------------------+-----------------------+---------------------+-------------------------------------+ +| Gurum DDS | 2.8.x | N/A | ++-------------------+-----------------------+-----------------------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" means that the dependency may see multiple version changes, +because the dependency uses a package manager that continually updates +the dependency without a stable API. + +\" \*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt +- Windows: Chocolatey, pip +- macOS: Homebrew, pip +- RHEL: dnf +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Iron Irwini <../../iron/Installation.html>`__ + +New features in this ROS 2 release +---------------------------------- + +API documentation generation for Python packages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 has had automatic API documentation for C++ packages for several releases, e.g. https://docs.ros.org/en/rolling/p/rclcpp/generated/index.html. +Iron adds automatic API documentation for Python packages as well, e.g. https://docs.ros.org/en/rolling/p/rclpy/rclpy.html. + +See https://github.com/ros-infrastructure/rosdoc2/pull/28, https://github.com/ros-infrastructure/rosdoc2/pull/49, https://github.com/ros-infrastructure/rosdoc2/pull/51, and https://github.com/ros-infrastructure/rosdoc2/pull/52 for more details. + +Service introspection +^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to enable service introspection on a per-service basis. +When enabled, this allows users to see the metadata associated with the client requesting a service, the server accepting the request, the server sending the response, and the client accepting the response. +Optionally, the contents of the client/server requests/responses can also be introspected. +All of the information is published on a hidden topic generated from the name of the service. +So if the service is called ``/myservice``, then the information will be published on ``/myservice/_service_event``. + +Note that this functionality is disabled by default; to enable it, users must call ``configure_introspection`` after creating a service client or server. +There are examples showing how to do this in https://github.com/ros2/demos/tree/iron/demo_nodes_cpp/src/services (C++) and https://github.com/ros2/demos/blob/iron/demo_nodes_py/demo_nodes_py/services/introspection.py (Python). + +See `REP 2012 `__ and the tracking bug at https://github.com/ros2/ros2/issues/1285 for more information. + +Pre and post set parameter callback support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For many releases now, users could register a callback to be called when parameters on a node were changed by an external entity (like ``ros2 param set``). +This callback could examine the changed parameter types and values, and reject the whole lot if one of them didn't meet certain criteria. +However, it could not modify the parameter list, nor should it have modified state (since there might be other callbacks after the set one that would reject the parameters). + +This release adds in a pre and post callback. +The callbacks are called in this order: + +* The "pre" set parameter callback, which can modify the list of parameters based on arbitrary criteria. +* The "set" parameter callback, which cannot modify the list and should only accept or reject the parameters based on their type and value (this is the existing callback). +* The "post" set parameter callback, which can make state changes based on parameters and is only called if the previous two callbacks are successful. + +There are examples of this in action in https://github.com/ros2/demos/blob/iron/demo_nodes_cpp/src/parameters/set_parameters_callback.cpp (C++) and https://github.com/ros2/demos/blob/iron/demo_nodes_py/demo_nodes_py/parameters/set_parameters_callback.py (Python). + +See https://github.com/ros2/rclcpp/pull/1947, https://github.com/ros2/rclpy/pull/966, and https://github.com/ros2/demos/pull/565 for more information. + +Improved discovery options +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Previous ROS 2 versions offered limited discovery options. +The default behavior for DDS based RMW implementations was to discover any node reachable via multicast. +It could be limited to the same machine by setting the environment variable ``ROS_LOCALHOST_ONLY``, but any additional configuration required configuring the middleware directly, usually via middleware specific XML files and environment variables. +ROS Iron retains the same default discovery behavior, but deprecates ``ROS_LOCALHOST_ONLY`` in favor of more granular options. + +* ``ROS_AUTOMATIC_DISCOVERY_RANGE`` controls how far ROS nodes will try to discover each other. Valid options are: + + * ``SUBNET`` - The default, and for DDS-based middlewares it will discover any node reachable via multicast. + * ``LOCALHOST`` - Will only try to discover other nodes on the same machine. + * ``OFF`` - Will not attempt to discover any other nodes automatically, even on the same machine. + * ``SYSTEM_DEFAULT`` - Will not change any discovery settings. This is useful when you already have custom settings for your middleware and don't want ROS to change them. + +* ``ROS_STATIC_PEERS`` - A semicolon (``;``) separated list of addresses that ROS should try to discover nodes on. This allows the user to connect to nodes on specifc machines (as long as their discovery range is not set to ``OFF``). + +For example, you might have several robots with ``ROS_AUTOMATIC_DISCOVERY_RANGE`` set to ``LOCALHOST`` so they don't communicate with each other. +When you want to connect RViz to one of them, you add it's address to ``ROS_STATIC_PEERS`` in your terminal. +Now you can use ROS 2 CLI and visualization tools to interact with the robot. + +See https://github.com/ros2/ros2/issues/1359 for more information about this feature. + +Matched events +^^^^^^^^^^^^^^ + +In addition to QoS events, matched events can be generated when any publisher and subscription establishes or drops the connection between them. +Users can provide each publisher and subscription with callback functions that are triggered by matched events and handle them in a way they see fit, similar to how messages received on a topic are handled. + +* publisher: this event happens when it finds a subscription which matches the topic and has compatible QoS or a connected subscription is disconnected. +* subscription: this event happens when it finds a publisher which matches the topic and has compatible QoS or a connected publisher is disconnected. + +See the tracking issue at https://github.com/ros2/rmw/issues/330 for more information. + +* C++ Demo of Matched Events: https://github.com/ros2/demos/blob/iron/demo_nodes_cpp/src/events/matched_event_detect.cpp +* Python Demo of Matched Events: https://github.com/ros2/demos/blob/iron/demo_nodes_py/demo_nodes_py/events/matched_event_detect.py + +External configuration services of loggers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to configure node logger levels remotely via a service. +When the ``enable_logger_service`` option is enabled during node creation, the ``set_logger_levels`` and ``get_logger_levels`` services will be available. + +Be advised that the ``enable_logger_service`` option is disabled by default, so the user needs to enable this option on node creation. + +See https://github.com/ros2/ros2/issues/1355 for more information. + +Type Description Distribution +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It is now possible to communicate information about the types of ROS 2 messages, so that systems with potentially-different types of the same name may discover their compatibility more transparently. +This umbrella of capabilities, which is defined by a subset of REP-2011: Evolving Message Types, has had many parts land in Iron. + +First, the introduction of the new package `type_description_interfaces `__ provides a common way to communicate the descriptions of ROS 2 communication interface types (msg, srv, action). + +Next, a method to hash type descriptions has been decided on, the ROS Interface Hashing Standard (RIHS) - starting with the first version RIHS01. +RIHS hashes are automatically calculated for all compiled ROS types at build time, and baked into the generated code so that they can be inspected. +These hashes are also communicated automatically during discovery, and included in ``rmw_topic_endpoint_info_t`` for graph introspection queries such as ``get_publishers_info_by_topic``. + +The full ``TypeDescription`` data structure, as well as the raw source text (such as ``.msg`` file) that were used to generate it are now baked in by default to the message libraries, so they can be used by ``typesupport`` or end users. +While we expect this data to provide value to most users, some users trying to minimize bytes in their install space can disable the feature when building ROS 2 Core by defining the CMake variable ``ROSIDL_GENERATOR_C_DISABLE_TYPE_DESCRIPTION_CODEGEN``. + +Finally, the new service ``type_description_interfaces/GetTypeDescription.srv`` has been defined to allow nodes, on encountering an unknown RIHS type hash, to request the full definition from the node advertising that type. +Work is in progress to provide this feature natively in ROS 2 Nodes, as an optional switch on node construction. +This feature has not yet shipped, but is expected to be backported into Iron sometime mid-2023. +Meanwhile, user nodes could implement this service indepedently, using the stable service interface. + +See `REP 2011 `__ for the design proposal. +See `Type Description Distribution `__ for tracking development on the feature set. + +Dynamic Types and Dynamic Messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Alongside the type description distribution feature mentioned above, is the ability to construct and access dynamically created types at runtime (i.e., dynamic types). +This feature is available in Iron for Fast DDS and ``rcl``, with new ``rmw`` interfaces for supporting the taking of messages as dynamic messages (i.e., messages built from or following the structure of the dynamic type). + +First, utilities were introduced into `rosidl `__ to aid in the construction and manipulation of type descriptions. + +Next, the `rosidl_dynamic_typesupport `__ package was written and provides a middleware-agnostic interface to construct dynamic types and dynamic messages at runtime. +Types can be constructed at runtime either programmatically, or by parsing a ``type_description_interfaces/TypeDescription`` message. + +.. note:: + + The ``rosidl_dynamic_typesupport`` library requires serialization support libraries to implement the middleware-specific dynamic type behavior. + A serialization support library for Fast DDS was implemented in `rosidl_dynamic_typesupport_fastrtps `__. + Ideally more middlewares will implement support libraries, expanding the number of middlewares that support this feature. + +Finally, to support the use of dynamic types and dynamic messages, new methods were added to `rmw `__ and `rcl `__ that support: + +- The ability to obtain of middleware-specific serialization support +- The ability to construct message type support at runtime that use dynamic types +- The ability to take dynamic messages using dynamic type + +Work is in progress to enable the use of dynamic types to create subscriptions in the client libraries (see the ``rclcpp`` issue below), though it is uncertain when the feature will land or be backported. +This will allow users to subscribe to topics whose type descriptions are only known at runtime. +In the meantime, users may write their own subscriptions that subscribe to dynamic types by using the new ``rmw`` and ``rcl`` features introduced as part of this feature set. + +See `REP 2011 `__ for the design proposal. +See `Dynamic Subscription `__ for tracking development on the feature set, with `rclcpp `__ needing the bulk of the work. + +``launch`` +^^^^^^^^^^ + +``PythonExpression`` now supports importing modules +""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to have a launch ``PythonExpression`` import modules before performing the evaluation. +This can be useful for pulling in additional functionality to be used when evaluating an expression. + +See https://github.com/ros2/launch/pull/655 for more information. + +``ReadyToTest`` can be called from an event handler +""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to register an event handler that uses ``ReadyToTest`` in its output. +This can be useful for doing things like downloading an asset before allowing a test to run. + +See https://github.com/ros2/launch/pull/665 for more information. + +Addition of ``AnySubstitution`` and ``AllSubstitution`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to specify a substitution to happen when any of the input arguments are true (``AnySubstitution``), or when all of the input arguments are true (``AllSubstitution``). + +See https://github.com/ros2/launch/pull/649 for more details. + +Addition of a new substitution to get the launch logging directory +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to use a substitution called ``LaunchLogDir`` to get the current logging directory for launch. + +See https://github.com/ros2/launch/pull/652 for more details. + +``launch_ros`` +^^^^^^^^^^^^^^ + +Add a ``LifecycleTransition`` action +"""""""""""""""""""""""""""""""""""" + +It is now possible to send a transition signal to a lifecycle node via the new ``LifeCycleTransition`` action. + +See https://github.com/ros2/launch_ros/pull/317 for more information. + +Add a ``SetROSLogDir`` action +""""""""""""""""""""""""""""" + +It is now possible to configure the directory used for logging via the ``SetROSLogDir`` action. + +See https://github.com/ros2/launch_ros/pull/325 for more information. + +Ability to specify a condition to a ``ComposableNode`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to specify a condition that must be satisfied in order for a ``ComposableNode`` to be inserted into its container. + +See https://github.com/ros2/launch_ros/pull/311 for more information. + +``launch_testing`` +^^^^^^^^^^^^^^^^^^ + +Timeout for process startup is now configurable +""""""""""""""""""""""""""""""""""""""""""""""" + +Prior to this release, the ``ReadyToTest`` action would wait exactly 15 seconds for processes to start up. +If the processes took longer than that, they would fail. +There is now a new decorator called ``ready_to_test_action_timeout`` that allows the user to configure the amount of time to wait for the processes to start. + +See https://github.com/ros2/launch/pull/625 for more information. + +``rclcpp`` +^^^^^^^^^^ + +Addition of a new paradigm for handling ``Node`` and ``LifecycleNode`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The ``Node`` and ``LifecycleNode`` classes are related in that they both provide the same base set of methods (though ``LifecycleNode`` provides additional methods as well). +Due to various implementation considerations, they are not derived from a common base class. + +This has led to some trouble for downstream code that wants to accept either a ``Node`` or a ``LifecycleNode``. +One solution is to have two method signatures, one that accepts a ``Node`` and one that accepts a ``LifecycleNode``. +The other, recommended solution is to have a method that accepts the "node interfaces" pointers that can be accessed from both classes, e.g. + +.. code-block:: C++ + + void do_thing(rclcpp::node_interfaces::NodeGraphInterface graph) + { + fprintf(stderr, "Doing a thing\n"); + } + + void do_thing(rclcpp::Node::SharedPtr node) + { + do_thing(node->get_node_graph_interface()); + } + + void do_thing(rclcpp::LifecycleNode::SharedPtr node) + { + do_thing(node->get_node_graph_interface()); + } + +This works, but can get a bit unwieldy when many node interfaces are needed. +To make this a bit better, there is now a new ``NodeInterfaces`` class that can be constructed to contain the interfaces, and then be used by other code. + +There are examples on how to use this in https://github.com/ros2/rclcpp/pull/2041. + +Introduction of a new executor type: the Events Executor +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The ``EventsExecutor`` from iRobot has been merged into the main ``rclcpp`` codebase. +This alternative executor implementation uses event-driven callbacks from the middleware implementations to fire callbacks at the ``rclcpp`` layer. +In addition to the push-based model, the ``EventsExecutor`` also moves timer management into a separate thread, which can allow for more accurate results and lower overhead, especially with many timers. + +The ``EventsExecutor`` has a substantial set of documentation and use-in-practice that make it a strong candidate for inclusion in the ``rclcpp`` codebase. +For information about the initial implementation proposal as well as performance benchmarks, see https://discourse.ros.org/t/ros2-middleware-change-proposal/15863. +For more information about the design, see the design PR: https://github.com/ros2/design/pull/305. + +Since the API is the same, trying the ``EventsExecutor`` is as straightforward as replacing your current Executor implementation (eg. ``SingleThreadedExecutor``): + +.. code-block:: C++ + + #include + using rclcpp::experimental::executors::EventsExecutor; + + EventsExecutor executor; + executor.add_node(node); + executor.spin(); + +**Note** The ``EventsExecutor`` and ``TimersManager`` are currently in the ``experimental`` namespace. +While it has been used as a standalone implementation for some time https://github.com/irobot-ros/events-executor, it was decided to use the ``experimental`` namespace for at least one release to give latitude in changing the API within the release. +Use caution as it will not be subject to the same API/ABI guarantees that the non-experimental code has. + +``rclpy`` +^^^^^^^^^ + +Ability to wait for another node to join the graph +"""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to wait for another node to join the network graph with code like the following: + +.. code-block:: Python + + node.wait_for_node('/fully_qualified_node_name') + +See https://github.com/ros2/rclpy/pull/930 for more information. + +Implementation of ``AsyncParameterClient`` +"""""""""""""""""""""""""""""""""""""""""" + +``rclpy`` now has an ``AsyncParameterClient`` class, bringing it to feature parity with ``rclcpp``. +This class is used to perform parameter actions on a remote node without blocking the calling node. + +See https://github.com/ros2/rclpy/pull/959 for more information and examples. + +Subscription callbacks can now optionally get the message info +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to register for a subscription callback with a function signature that takes both the message, and the message info, like: + +.. code-block:: Python + + def msg_info_cb(msg, msg_info): + print('Message info:', msg_info) + + node.create_subscription(msg_type=std_msgs.msg.String, topic='/chatter', qos_profile=10, callback=msg_info_cb) + +The message info structure contains various pieces of information like the sequence number of the message, the source and received timestamps, and the GID of the publisher. + +See https://github.com/ros2/rclpy/pull/922 for more information. + +Optional argument that hides assertions for messages class +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" +All message classes now include a new optional argument that allows the hiding of assertions for each field type from the message. +By default, assertions are hidden, which provides a performance improvement during runtime. +In order to enable the assertions for development/debugging purposes, you are given two choices: + +1. Define the environment variable ``ROS_PYTHON_CHECK_FIELDS`` to ``'1'`` (this would affect all the messages in your project): + +.. code-block:: Python + + import os + from std_msgs.msg import String + + os.environ['ROS_PYTHON_CHECK_FIELDS'] = '1' + new_message=String() + +2. Select the specific behavior for a single message by explicitly defining the new argument in the constructor: + +.. code-block:: Python + + from std_msgs.msg import String + + new_message=String(check_fields=True) + +See https://github.com/ros2/rosidl_python/pull/194 for more information. + +``ros2param`` +^^^^^^^^^^^^^ + +Option to timeout when waiting for a node with ``ros2 param`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to have the various ``ros2 param`` commands timeout by passing ``--timeout`` to the command. + +See https://github.com/ros2/ros2cli/pull/802 for more information. + +Deprecated options were removed +"""""""""""""""""""""""""""""""" + +``--output-dir`` and ``--print`` options with ``dump`` command have been removed. + +See https://github.com/ros2/ros2cli/pull/824 for more information. + +``ros2topic`` +^^^^^^^^^^^^^ + +``now`` as keyword for ``builtin_interfaces.msg.Time`` and ``auto`` for ``std_msgs.msg.Header`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +``ros2 topic pub`` now allows to set a ``builtin_interfaces.msg.Time`` message to the current time via the ``now`` keyword. +Similarly, a ``std_msg.msg.Header`` message will be automatically generated when passed the keyword ``auto``. +This behavior matches that of ROS 1's ``rostopic`` (http://wiki.ros.org/ROS/YAMLCommandLine#Headers.2Ftimestamps) + +Related PR: `ros2/ros2cli#749 `_ + +``ros2 topic pub`` can be configured to wait a maximum amount of time +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The command ``ros2 topic pub -w 1`` will wait for at least that number of subscribers before publishing a message. +This release adds in a ``--max-wait-time`` option so that the command will only wait a maximum amount of time before quitting if no subscribers are seen. + +See https://github.com/ros2/ros2cli/pull/800 for more information. + +``ros2 topic echo`` can be configured to wait a maximum amount of time +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The command ``ros2 topic echo`` now accepts a ``--timeout`` option, which controls the maximum amount of time that the command will wait for a publication to happen. + +See https://github.com/ros2/ros2cli/pull/792 for more information. + +Deprecated option was removed +""""""""""""""""""""""""""""" + +``--lost-messages`` option with ``echo`` command has been removed. + +See https://github.com/ros2/ros2cli/pull/824 for more information. + +Changes since the Humble release +-------------------------------- + +Change to the default console logging file flushing behavior +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This specifically applies to the default ``spdlog`` based logging backend in ROS 2, implemented in ``rcl_logging_spdlog``. +Log file flushing was changed to flush every time an "error" log message is used, e.g. each ``RCLCPP_ERROR()`` call, and also periodically every five seconds. + +Previously, ``spdlog`` was used without configuring anything other than creating the sink for logging to a file. + +We tested the change and did not find that the CPU overhead was significant, even on machines with slow disks (e.g. sd cards). +However, if this change is causing you problems, you can get the old behavior by setting the ``RCL_LOGGING_SPDLOG_EXPERIMENTAL_OLD_FLUSHING_BEHAVIOR=1`` environment variable. + +Later we would like to have support for a full configuration file (see: https://github.com/ros2/rcl_logging/issues/92), giving you more flexibility in how the logging is done, but that is work that is only planned right now. + + Therefore, **this environment variable should be considered experimental and subject to removal without deprecation in the future**, when we add config file support for the ``rcl_logging_spdlog`` logging backend. + +See this pull request for more details about the change: https://github.com/ros2/rcl_logging/pull/95 + +``ament_cmake_auto`` +^^^^^^^^^^^^^^^^^^^^ + +Include dependencies are now marked as SYSTEM +""""""""""""""""""""""""""""""""""""""""""""" + +When using ``ament_auto_add_executable`` or ``ament_auto_add_library``, dependencies are now automatically added as ``SYSTEM``. +This means that warnings in the header files of the dependencies will not be reported. + +See https://github.com/ament/ament_cmake/pull/385 for more details. + +``ament_cmake_nose`` +^^^^^^^^^^^^^^^^^^^^ + +Package has been deprecated and removed +""""""""""""""""""""""""""""""""""""""" + +The Python ``nose`` package has long been deprecated. +Since none of the open-source packages currently released into Humble or Rolling currently depend on it, this release deprecates and removes the ament wrapper around it. + +See https://github.com/ament/ament_cmake/pull/415 for more information. + +``ament_lint`` +^^^^^^^^^^^^^^ + +Files can be excluded from linter checks +"""""""""""""""""""""""""""""""""""""""" + +Certain files can now be excluded from linter checks by setting the ``AMENT_LINT_AUTO_FILE_EXCLUDE`` CMake variable before calling ``ament_lint_auto_find_test_dependencies``. + +See https://github.com/ament/ament_lint/pull/386 for more information. + +``camera_info_manager`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Lifecycle node support +"""""""""""""""""""""" + +``camera_info_manager`` now supports lifecycle nodes in additional to regular ROS 2 nodes. + +See https://github.com/ros-perception/image_common/pull/190 for more information. + +``launch`` +^^^^^^^^^^ + +``LaunchConfigurationEquals`` and ``LaunchConfigurationNotEquals`` are deprecated +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The ``LaunchConfigurationEquals`` and ``LaunchConfigurationNotEquals`` conditions are deprecated, and will be removed in a future release. +Instead, the more universal ``Equals`` and ``NotEquals`` substitutions should be used instead. + +See https://github.com/ros2/launch/pull/649 for more details. + +``launch_ros`` +^^^^^^^^^^^^^^ + +Renamed classes which used ``Ros`` in the name to use ``ROS`` in line with PEP8 +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Classes that were changed: + +* ``launch_ros.actions.RosTimer`` -> ``launch_ros.actions.ROSTimer`` +* ``launch_ros.actions.PushRosNamespace`` -> ``launch.actions.PushROSNamespace`` + +The old class names are still there, but will be deprecated. + +See https://github.com/ros2/launch_ros/pull/326 for more information. + +``launch_xml`` +^^^^^^^^^^^^^^ + +Expose ``emulate_tty`` to XML frontend +"""""""""""""""""""""""""""""""""""""" + +It has been possible for several releases to have the ``launch`` Python code use pseudo-terminals to emulate a TTY (and hence do things like print colors). +That functionality is now available in the XML frontend by passing the ``emulate_tty`` argument to an executable command. + +See https://github.com/ros2/launch/pull/669 for more information. + +Expose ``sigterm_timeout`` and ``sigkill_timeout`` to XML frontend +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It has been possible for several releases to configure the maximum timeout value for the SIGTERM and SIGKILL signals in the ``launch`` Python code. +That functionality is now available in the XML frontend by passing the ``sigterm_timeout`` or ``sigkill_timeout`` argument to an executable command. + +See https://github.com/ros2/launch/pull/667 for more information. + +``launch_yaml`` +^^^^^^^^^^^^^^^ + +Expose ``emulate_tty`` to YAML frontend +""""""""""""""""""""""""""""""""""""""" + +It has been possible for several releases to have the ``launch`` Python code use pseudo-terminals to emulate a TTY (and hence do things like print colors). +That functionality is now available in the YAML frontend by passing the ``emulate_tty`` argument to an executable command. + +See https://github.com/ros2/launch/pull/669 for more information. + +Expose ``sigterm_timeout`` and ``sigkill_timeout`` to YAML frontend +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It has been possible for several releases to configure the maximum timeout value for the SIGTERM and SIGKILL signals in the ``launch`` Python code. +That functionality is now available in the YAML frontend by passing the ``sigterm_timeout`` or ``sigkill_timeout`` argument to an executable command. + +See https://github.com/ros2/launch/pull/667 for more information. + +``message_filters`` +^^^^^^^^^^^^^^^^^^^ + +New approximate time policy +""""""""""""""""""""""""""" + +Add in a simpler approximate time policy called ``ApproximateEpsilonTime``. +This time policy works like ``ExactTime``, but allows timestamps being within a epsilon tolerance. +See https://github.com/ros2/message_filters/pull/84 for more information. + +New upsampling time policy +"""""""""""""""""""""""""" + +Adds in a new time policy called ``LatestTime``. +It can synchronize up to 9 messages by their rates with upsampling via zero-order-hold. +See https://github.com/ros2/message_filters/pull/73 for more information. + +``rcl_yaml_param_parser`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Support for YAML ``!!str`` syntax in parameter files +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to force the ROS parameter file parser to interpret a field as a string using the YAML ``!!str`` syntax. +See https://github.com/ros2/rcl/pull/999 for more information. + +``rclcpp`` +^^^^^^^^^^ + +Default number of threads for multi-threaded executor has been changed +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +If the user doesn't specify otherwise, the default number of threads for the multi-threaded executor will be set to the number of CPUs on the machine. +If the underlying OS doesn't support getting this information, it will be set to 2. + +See https://github.com/ros2/rclcpp/pull/2032 for more information. + +A warning is now printed when QoS of KEEP_LAST is specified with a depth of 0 +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Specifying a QoS of KEEP_LAST with a depth of 0 is a nonsensical arrangement, since the entity wouldn't be able to send or receive any data. +``rclcpp`` will now print a warning if this combination is specified, but will still continue on and let the underlying middleware choose a sane value (generally a depth of 1). + +See https://github.com/ros2/rclcpp/pull/2048 for more information. + +Deprecated ``RCLCPP_SCOPE_EXIT`` macro was removed +"""""""""""""""""""""""""""""""""""""""""""""""""" + +In Humble, the macro ``RCLCPP_SCOPE_EXIT`` was deprecated in favor of ``RCPPUTILS_SCOPE_EXIT``. +In Iron, the ``RCLCPP_SCOPE_EXIT`` macro has been completely removed. + +``rclpy`` +^^^^^^^^^ + +Default number of threads for multi-threaded executor has been changed +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +If the user doesn't specify otherwise, the default number of threads for the multi-threaded executor will be set to the number of CPUs on the machine. +If the underlying OS doesn't support getting this information, it will be set to 2. + +See https://github.com/ros2/rclpy/pull/1031 for more information. + +A warning is now printed when QoS of KEEP_LAST is specified with a depth of 0 +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Specifying a QoS of KEEP_LAST with a depth of 0 is a nonsensical arrangement, since the entity wouldn't be able to send or receive any data. +``rclpy`` will now print a warning if this combination is specified, but will still continue on and let the underlying middleware choose a sane value (generally a depth of 1). + +See https://github.com/ros2/rclpy/pull/1048 for more information. + +Time and Duration no longer raise exception when compared to another type +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to compare ``rclpy.time.Time`` and ``rclpy.duration.Duration`` to other types without getting exceptions. +If the types are not comparable, the comparison returns ``False``. +Note that this is a behavior change from previous releases. + +.. code-block:: Python + + print(None in [rclpy.time.Time(), rclpy.duration.Duration()]) # Prints "False" instead of raising TypeError + +See https://github.com/ros2/rclpy/pull/1007 for more information. + +``rcutils`` +^^^^^^^^^^^ + +Improve the performance of message logging +"""""""""""""""""""""""""""""""""""""""""" + +The code used to output a log message when ``RCUTILS_LOG_*`` or ``RCLCPP_*`` was optimized to reduce overhead. +These log messages should now be more efficient, though they should still not be called at high rates. +See https://github.com/ros2/rcutils/pull/381, https://github.com/ros2/rcutils/pull/372, https://github.com/ros2/rcutils/pull/369, and https://github.com/ros2/rcutils/pull/367 for more information. + +Deprecated ``rcutils/get_env.h`` header was removed +""""""""""""""""""""""""""""""""""""""""""""""""""" + +In Humble, the header ``rcutils/get_env.h`` was deprecated in favor of ``rcutils/env.h``. +In Iron, the ``rcutils/get_env.h`` header been completely removed. + +``rmw`` +^^^^^^^ + +Change the GID storage to 16 bytes +"""""""""""""""""""""""""""""""""" + +The GID in the RMW layer is meant to be a globally unique identifier for writers in the ROS graph. +Previously, this was erroneously set to 24 bytes based on a bug in an old RMW implementation. +But the ``rmw`` package should define this, and all of the implementations should conform to that. +Thus, this release defines it as 16 bytes (the DDS standard), and changes all implementations to use that definition. + +See https://github.com/ros2/rmw/pull/345 and the (closed, but relevant) https://github.com/ros2/rmw/pull/328 for more information. + +``rmw_dds_common`` +^^^^^^^^^^^^^^^^^^ + +Change the GID storage to 16 bytes +"""""""""""""""""""""""""""""""""" + +Along with the change in the ``rmw`` layer, change the message that sends out GID information to 16 bytes. + +See https://github.com/ros2/rmw_dds_common/pull/68 for more information. + +``ros2topic`` +^^^^^^^^^^^^^ + +``ros2 topic hz/bw/pub`` now respect ``use_sim_time`` +""""""""""""""""""""""""""""""""""""""""""""""""""""" + +When running under simulation, the ROS 2 ecosystem generally gets its time from a ``/clock`` topic published by the simulator (rather than using the system clock). +ROS 2 nodes are typically informed of this change by setting the ``use_sim_time`` parameter on the node. +The node created by the ``ros2 topic`` commands ``hz``, ``bw``, and ``pub`` now respect that parameter and will use simulation time as appropriate. + +See https://github.com/ros2/ros2cli/pull/754 for more information. + +``rosbag2`` +^^^^^^^^^^^ + +Change default bag file type to ``mcap`` +"""""""""""""""""""""""""""""""""""""""" + +Prior to this release, by default rosbag2 would record data into sqlite3 databases. +During testing, it was found that in many cases this was not performant enough and lacked certain features desirable for offline processing. + +To meet these needs, a new bag format (influenced by the original ROS 1 bag file format) called ``mcap`` was developed. +This bag file format has many of the missing features from the sqlite3 file format, and should also be more performant. + +This release switches to using ``mcap`` as the default file format for writing new bags. +The old ``sqlite3`` file format is still available and can be selected by the user for writing if desired. +This release also allows playing back data from either the ``sqlite3`` file format or the ``mcap`` file format. + +See https://github.com/ros2/rosbag2/pull/1160 for more information. + +Store message definitions in bag files with SQLite3 plugin +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Now we support saving message definitions to the ``sqlite3`` database file in the same format +as we are saving it to the ``mcap`` file. +This opens an opportunity for third-party tools to have +the ability to deserialize rosbag2 files without having the correct version of all the original +.msg files on the machine that is decoding the bag file recorded with ``sqlite3`` plugin. + +See https://github.com/ros2/rosbag2/issues/782 and https://github.com/ros2/rosbag2/pull/1293 for +more information. + + +New playback and recording controls +""""""""""""""""""""""""""""""""""" + +Several pull requests have been added to enhance the user's control over playback of bags. +Pull request `960 `_ adds the ability to play bag for +a specified number of seconds. +And pull request `1005 `_ allows to play bag until specified timestamp. +Another pull request `1007 `_ adds the ability to +stop playback remotely via service call. +Stop will unpause player if it was in pause mode, stop playback and force exit from play() method if it was in progress. + +Managing recording via service calls +"""""""""""""""""""""""""""""""""""" + +There are new options to control the recording process from remote nodes. +The pull request `1131 `_ adds the ability to pause and +resume recording via service calls. +Another pull request `1115 `_ adds the ability to split +bags during recording by sending service call. + +Filtering topics via regular expression during playback +""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Users sometimes need to replay only a subset of topics from recorded bags and the following two pull request +adds such capability. +Pull request `1034 `_ adds a new option +``--topics-regex`` that allows filtering topics via regular expressions. +The ``--topics-regex`` option accepts multiple regular expressions separated by space. +And pull request `1046 `_ adds the ability to exclude some +certain topics from being replayed by providing regular expression in a new ``--exclude`` +(and ``-x``) option. + +Allow plugins to register their own CLI verb arguments +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Pull request `1209 `_ adds the ability for ``rosbag2`` plugins to +register an optional Python entrypoint providing plugin-specific CLI argument values. +As a result the command line option ``--storage-preset-profile`` for ``ros2 bag record`` verb will have +different valid options depending on the underlying storage plugin. + +Other changes +""""""""""""" + +The pull request `1038 `_ adds the ability to record +any key/value pair in 'custom' field in metadata.yaml file. +It is useful when users need to save some hardware specific id or coordinates where the recording was captured. +And pull request `1180 `_ adds an option to change the underlying +node name for the recorder via providing the new command line ``--node-name`` option. +This option might be used for creating remote distributed recording with multiple rosbag2 recorder instances. +It provides the ability to send service calls for managing the recording process to the dedicated +rosbag2 recorder instances. + +``rosidl_python`` +^^^^^^^^^^^^^^^^^ + +Modification of content of ``__slots__`` attribute +"""""""""""""""""""""""""""""""""""""""""""""""""" + +So far, the attribute ``__slots__`` from the python message classes, have been used as the member that contains the field names of the message. +In Iron, this attribute no longer contains only the field names from the message structure, but the field names for all the class members. +Therefore, users shouldn't rely on this attribute to retrieve the field names information, instead, users should retrieve it using the method ``get_field_and_field_types()``. + +See https://github.com/ros2/rosidl_python/pull/194 for more information. + +``rviz`` +^^^^^^^^ + +Map display can now be shown as binary +"""""""""""""""""""""""""""""""""""""" + +The RViz map display can now display the map as binary, with a settable threshold. +This is useful in some cases to inspect maps or in combination with planners that have a settable threshold. + +See https://github.com/ros2/rviz/pull/846 for more information. + +Camera display plugin respects the ROI in the CameraInfo message +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The CameraDisplay plugin now honors the region-of-interest (ROI) settings in the CameraInfo message, if it is provided. +This accounts for the fact that an image was cropped by the camera driver to reduce the bandwidth. + +See https://github.com/ros2/rviz/pull/864 for more information. + +Binary STL files from SOLIDWORKS work without error +""""""""""""""""""""""""""""""""""""""""""""""""""" + +A change was made to the STL loader such that it accepts binary STL files from SOLIDWORKS that have the word "solid" in them. +This technically violates the STL specification, but is common enough that a special case is added to handle these files. + +See https://github.com/ros2/rviz/pull/917 for more information. + +``tracetools`` +^^^^^^^^^^^^^^ + +Tracing instrumentation is now included by default on Linux +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +The ROS 2 core has had tracing instrumentation for a while now. +However, it was compiled out by default. +To get the instrumentation, the LTTng tracer had to be manually installed before rebuilding ROS 2 from source. +In Iron, the tracing instrumentation and tracepoints are included by default; the LTTng tracer is therefore now a ROS 2 dependency. + +Note that this only applies to Linux. + +See https://github.com/ros2/ros2_tracing/pull/31 and https://github.com/ros2/ros2/issues/1177 for more information. +See :doc:`this how-to guide to remove the instrumentation (or add the instrumentation with Humble and older) <../../Developer-Tools/Debugging/Building-ROS-2-with-Tracing>`. + +New tracepoints for ``rclcpp`` intra-process are added +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +New tracepoints have been added to support ``rclcpp`` intra-process communication. +This allows the evaluation of the time between the message publishing and the callback start in intra-process communication. + +See https://github.com/ros2/ros2_tracing/pull/30 and https://github.com/ros2/rclcpp/pull/2091 for more information. + +Known Issues +------------ + +* ``rmw_connextdds`` does not work with Windows Binary release packages. + RTI is not longer distributing ``RTI ConnextDDS 6.0.1`` which was used by the packaging jobs to create the binaries for Windows. + Instead they now distribute ``RTI ConnextDDS 6.1.0`` which is ABI incompatible with the generated binaries. + The solution is to rely on source builds of ROS 2 and ``rmw_connextdds`` on Windows. + +* ``sros2`` on Windows requires users to downgrade the ``cryptography`` python module to ``cryptography==38.0.4`` as discussed `here `_. + +* ``ros1_bridge`` does not work with ROS Noetic packages from `upstream Ubuntu `_. The suggested workaround is to build ROS Noetic from sources, then build the ``ros1_bridge`` using that. + +Release Timeline +---------------- + + November, 2022 - Platform decisions + REP 2000 is updated with the target platforms and major dependency versions. + + By January, 2023 - Rolling platform shift + Build farm is updated with the new platform versions and dependency versions for Iron Irwini (if necessary). + + Mon. April 10, 2023 - Alpha + RMW freeze + Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. + + Mon. April 17, 2023 - Freeze + API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 24, 2023 - Branch + Branch from Rolling Ridley. + ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. + Iron development shifts from ``ros-rolling-*`` packages to ``ros-iron-*`` packages. + + Mon. May 1, 2023 - Beta + Updated releases of ROS Desktop [2]_ packages available. + Call for general testing. + + Mon. May 15, 2023 - Release Candidate + Release Candidate packages are built. + Updated releases of ROS Desktop [2]_ packages available. + + Thu. May 18, 2023 - Distro Freeze + Freeze rosdistro. + No PRs for Iron on the ``rosdistro`` repo will be merged (reopens after the release announcement). + + Tue. May 23, 2023 - General Availability + Release announcement. + ``rosdistro`` is reopened for Iron PRs. + +.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. + +Development progress +-------------------- + +For progress on the development and release of Iron Irwini, see `the tracking GitHub issue `__. + +For the broad process followed by Iron Irwini, see the :doc:`process description page `. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst b/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst index 54b11a5c1a2..028d88e921a 100644 --- a/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst +++ b/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst @@ -1,791 +1,795 @@ -.. _jazzy-release: - -Jazzy Jalisco (``jazzy``) -========================= - -.. toctree:: - :hidden: - - Jazzy-Jalisco-Complete-Changelog - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Jazzy Jalisco* is the tenth release of ROS 2. -What follows is highlights of the important changes and features in Jazzy Jalisco since the last release. -For a list of all of the changes since Iron, see the :doc:`long form changelog ` - -Supported Platforms -------------------- - -Jazzy Jalisco supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019): ``amd64`` - -Tier 2 platforms: - -* RHEL 9: ``amd64`` - -Tier 3 platforms: - -* macOS: ``amd64`` -* Debian Bookworm: ``amd64`` - -Targeted platforms: - -+--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ -| Architecture | Ubuntu Noble (24.04) | Windows 10 (VS2019) | RHEL 9 | Ubuntu Jammy (22.04) | macOS | Debian Bookworm (12) | OpenEmbedded / | -| | | | | | | | Yocto Project | -+==============+=======================+======================+======================+=======================+=========+=======================+=============================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s] | Tier 3 | Tier 3 [s] | Tier 3 [s] | -| | | | | | [s] | | | -+--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ -| arm64 | Tier 1 [d][a][s] | | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ -| arm32 | Tier 3 [s] | | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ - - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be -provided for this platform for packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Jazzy ROS 2 repos file[^13]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+==========================+=========================+===============+============================+================================+ -| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ -| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64 | -+--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | -+--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32 | -+--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++17 -- Python 3.8 - -Dependency Requirements: - -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| | Required Support | Recommended Support | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Package | Ubuntu Noble | Windows 10** | RHEL 9 | Ubuntu Jammy | macOS** | Debian Bookworm | OpenEmbedded** | -+=============+===============+===============+========+==============+============+=================+=====================+ -| CMake | 3.28.3 | 3.22.0 | 3.20.2 | 3.22.1 | 3.20.0 | 3.25.1 | 3.22.3 | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| EmPY | 3.3.4 | 3.3.2 | 3.3.4 | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Gazebo | Harmonic* | N/A | N/A | Harmonic* | Harmonic* | Harmonic* | N/A | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| NumPy | 1.26.4 | 1.18.4 | 1.20.1 | 1.21.5 | 1.18.4 | 1.24.2 | N/A | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Ogre | 1.12.10 | N/A | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| OpenCV | 4.6.0 | 3.4.6* | 4.6.0 | 4.5.4 | 4.2.0 | 4.6.0 | 4.1.0 / 3.2.0*** | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| OpenSSL | 3.0.13 | 1.1.1l | 3.0.7 | 1.1.1l | 1.1.1f | 3.0.11 | 1.1.1d / 1.1.1b*** | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Python | 3.12.3 | 3.8.3 | 3.9.16 | 3.10.4 | 3.10.8 | 3.11.2 | 3.8.2 / 3.7.5*** | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Qt | 5.15.10 | 5.12.12 | 5.15.3 | 5.15.3 | 5.12.3 | 5.15.8 | 5.14.1 / 5.12.5*** | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| | **Linux only** | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| PCL | 1.14.0 | N/A | 1.12.0 | 1.12.1 | N/A | 1.13.0 | 1.10.0 | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| **RMW DDS Middleware** | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Cyclone DDS | 0.10.4 | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Fast-DDS | 2.14.0 | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Connext DDS | 6.0.1 | N/A | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ -| Gurum DDS | 4.2.0 | N/A | -+-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" means that the dependency may see multiple version changes, -because the dependency uses a package manager that continually updates -the dependency without a stable API. - -\" \*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt, pip -- Windows: Chocolatey, pip -- macOS: Homebrew, pip -- RHEL: dnf -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cmake -- setuptools - -Installation ------------- - -`Install Jazzy Jalisco <../../jazzy/Installation.html>`__ - -Changes to how ROS 2 and Gazebo integrate ------------------------------------------ - -Starting with Jazzy Jalisco, we are streamlining how ROS 2 and `Gazebo `__ integrate. -For every ROS 2 release, there will be a recommended, supported Gazebo release that goes along with that release. -For Jazzy Jalisco, the recommended Gazebo release will be Harmonic. - -To make it easier for ROS 2 packages to consume Gazebo packages, there are now ``gz_*_vendor`` packages. -Those packages are: - -* gz_common_vendor: https://github.com/gazebo-release/gz_common_vendor -* gz_cmake_vendor: https://github.com/gazebo-release/gz_cmake_vendor -* gz_math_vendor: https://github.com/gazebo-release/gz_math_vendor -* gz_transport_vendor: https://github.com/gazebo-release/gz_transport_vendor -* gz_sensor_vendor: https://github.com/gazebo-release/gz_sensor_vendor -* gz_sim_vendor: https://github.com/gazebo-release/gz_sim_vendor -* gz_tools_vendor: https://github.com/gazebo-release/gz_tools_vendor -* gz_utils_vendor: https://github.com/gazebo-release/gz_utils_vendor -* sdformat_vendor: https://github.com/gazebo-release/sdformat_vendor - -ROS 2 packages can use the functionality in these packages by adding dependencies in ``package.xml``, e.g.: - -.. code:: - - gz_math_vendor - -And then using them in ``CMakeLists.txt``, e.g.: - -.. code:: - - find_package(gz_math_vendor REQUIRED) - find_package(gz-math) - - add_executable(my_executable src/exe.cpp) - target_link_libraries(my_executable gz-math::core) - -.. note:: - - It will still be possible to use alternate Gazebo versions with Jazzy Jalisco. But those will not be as well tested or integrated with ROS 2. See https://gazebosim.org/docs/harmonic/ros_installation for more information. - -New features in this ROS 2 release ----------------------------------- - -``common_interfaces`` -^^^^^^^^^^^^^^^^^^^^^ - -New VelocityStamped message -""""""""""""""""""""""""""" - -Added a new message with all fields needed to define a velocity and transform it. - -See https://github.com/ros2/common_interfaces/pull/240 for more details. - -Adds ARROW_STRIP to Marker.msg -"""""""""""""""""""""""""""""" - -Added new type of Marker, ``ARROW_STRIP``, to Marker.msg. - -See https://github.com/ros2/common_interfaces/pull/242 for more details. - -``image_transport`` -^^^^^^^^^^^^^^^^^^^ - -Support lazy subscribers -"""""""""""""""""""""""" - -See https://github.com/ros-perception/image_common/issues/272 for more details. - -Expose option to set callback groups -"""""""""""""""""""""""""""""""""""" - -See https://github.com/ros-perception/image_common/issues/274 for more details. - -Enable allow list -""""""""""""""""" - -Added parameter so users can selectively disable ``image_transport`` plugins at runtime. - -See https://github.com/ros-perception/image_common/issues/264 for more details. - -Advertise and subscribe with custom QoS -""""""""""""""""""""""""""""""""""""""" - -Allow users to pass in a custom quality-of-service when creating ``image_transport`` publishers and subscribers. - -See https://github.com/ros-perception/image_common/issues/288 for more detatils. - -Added rclcpp component to Republish -""""""""""""""""""""""""""""""""""" - -Users can now start the ``image_transport`` republisher node as an rclcpp_component. - -See https://github.com/ros-perception/image_common/issues/275 for more details. - - -``message_filters`` -^^^^^^^^^^^^^^^^^^^ - -TypeAdapters support -"""""""""""""""""""" - -Allows users to use Type Adaptation within message_filters. - -See https://github.com/ros2/message_filters/pull/96 for more information. - -``rcl`` -^^^^^^^ - -Add get type description service -"""""""""""""""""""""""""""""""" - -Implements the ``~/get_type_description`` service which allows external users to get descriptions of each type that a node offers. -This is offered by each node according to `REP 2016 `__. - -See https://github.com/ros2/rcl/pull/1052 for more details. - -``rclcpp`` -^^^^^^^^^^ - -Type support helper for services -"""""""""""""""""""""""""""""""" - -New type support helper for services ``rclcpp::get_service_typesupport_handle`` is added to extract service type support handle. - -See https://github.com/ros2/rclcpp/pull/2209 for more details. - -``rclpy`` -^^^^^^^^^^ - -ParameterEventHandler -""""""""""""""""""""" - -New class ``ParameterEventHandler`` allows us to monitor and respond changes to parameters via parameter events. - -See https://github.com/ros2/rclpy/pull/1135 for more details. - -``ros2cli`` -^^^^^^^^^^^ - -Added a ``--log-file-name`` command line argument -""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to use ``--log-file-name`` command line argument to specify the log file name prefix. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker --ros-args --log-file-name filename - -See https://github.com/ros2/ros2cli/issues/856 for more information. - -Added QoS to subscription options -""""""""""""""""""""""""""""""""" - -A user-settable QoS parameter was added to the ``TopicStatisticsOptions``, which allows the statistics to have a different QoS from the subscription itself. - -See https://github.com/ros2/rclcpp/pull/2323 for more details. - -Add clients and services count -"""""""""""""""""""""""""""""" - -It is now possible to get the number of clients created by a service. - -``ros2action`` -^^^^^^^^^^^^^^ - -``type`` sub-command supported -"""""""""""""""""""""""""""""" - -It is now possible to use the ``type`` sub-command to check the action type. - -.. code-block:: console - - $ ros2 action type /fibonacci - action_tutorials_interfaces/action/Fibonacci - -See https://github.com/ros2/ros2cli/pull/894 for more information. - -``rosbag2`` -^^^^^^^^^^^ - -Service recording and playback -"""""""""""""""""""""""""""""" - -It is now possible to record and play service data with the ``ros2bag`` command line interface. - -This features builds on `Service Introspection `__, which has been available since Iron Irwini. -`Service recording and display `__ adds the ability to record service data into a bag file. -And `Service playback `__ can play that service data from the bag file. - -Record all services data: - -.. code-block:: console - - $ ros2 bag record --all-services - -Record all services and all topic data: - -.. code-block:: console - - $ ros2 bag record --all - -Play service data from bag file: - -.. code-block:: console - - $ ros2 bag play --publish-service-requests bag_path - -See the `design document `__ for more information. - -New filter modes -"""""""""""""""" - -It is now possible to filter by topic type. - -.. code-block:: console - - $ ros2 bag record --topic_types sensor_msgs/msg/Image sensor_msgs/msg/CameraInfo - -.. code-block:: console - - $ ros2 bag record --topic_types sensor_msgs/msg/Image - -See more details https://github.com/ros2/rosbag2/pull/1577 and https://github.com/ros2/rosbag2/pull/1582. - -Player and Recorder are now exposed as rclcpp components -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This allows a "zero-copy" when using intra-process communication during data record or reply. -This can significantly reduce CPU load during recording or reply when dealing with high-bandwidth data streams and will help to avoid data loss in the transport layer. -It also provides the ability to use YAML configuration files for ``rosbag2_transport::Player`` and ``rosbag2_transport::Recorder`` composable nodes. - -See https://github.com/ros2/rosbag2/tree/jazzy?tab=readme-ov-file#using-with-composition for more details. - -Added option to disable recorder keyboard controls -"""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1607 for more details. - -Use middleware send and receive timestamps from ``message_info`` during recording -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Where available, ``rosbag2`` now uses the send and receive timestamps as provided by the middleware. -These timestamps are more indicative of when the data was actually sent and received, respectively. -Note that saving the timestamp into a bag is currently only supported for MCAP files (the default). - -See https://github.com/ros2/rosbag2/pull/1531 for more details. - -Added compression threads priority to record options -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to specify the priority of the thread that performs compression. - -See https://github.com/ros2/rosbag2/pull/1457 for more details. - -Added ability to split already existing ros2 bags by time -""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Added ``start_time_ns`` and ``end_time_ns`` to the ``StorageOptions`` to exclude messages not in -``[start_time;end_time]`` during the ``ros2 bag convert`` operation. - -See https://github.com/ros2/rosbag2/pull/1455 for more details. - -Store serialized metadata in bag files directly -""""""""""""""""""""""""""""""""""""""""""""""" - -``rosbag2`` has always stored metadata in the ``metadata.yaml`` file associated with a bag file. -Now the metadata is also stored in each bag file, once when opening the file and a second time when closing the written bag file. -This allows bag files to be self-contained, and used without the ``metadata.yaml`` file in the rosbag2 player or third-party applications. -``ros2 bag reindex`` can still be used to restore the ``metadata.yaml`` file, if desired. - -Store ROS_DISTRO name in the metadata -""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1241 for more details. - -Added introspection QoS methods to Python bindings -"""""""""""""""""""""""""""""""""""""""""""""""""" - -It is now possible to instrospect QoS setting from Python bindings. - -See https://github.com/ros2/rosbag2/pull/1648 for more details. - -``rosidl`` -^^^^^^^^^^ - -Added interfaces to support key annotation -"""""""""""""""""""""""""""""""""""""""""" - -The ``key`` annotation allows indicating that a data member is part of the key, which can have zero or more key fields and can be applied to structure fields of various types. - -See https://github.com/ros2/rosidl/pull/796 and https://github.com/ros2/rosidl_typesupport_fastrtps/pull/116 for more details. - -``rviz2`` -^^^^^^^^^ - -Added regex filter field for TF display -""""""""""""""""""""""""""""""""""""""" - -When there are many frames on ``/tf`` it can be hard to properly visualize them in RViz, especially if frames overlap. -The usual solution to this is to enable and disable desired frames in Frames field of the TF display. -Now it is possible to filter frames using regular expressions. - -See https://github.com/ros2/rviz/pull/1032 for more details. - -Append measured subscription frequency to topic status -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -It is possible to visualize Hz in the topic status widget. - -See https://github.com/ros2/rviz/issues/1113 for more details. - -Reset functionality -""""""""""""""""""" - -It is possible to reset Time using a new service or using the keyboard shortcut ``R``. - -See https://github.com/ros2/rviz/issues/1109 and https://github.com/ros2/rviz/issues/1088 for more details. - -Added support for point_cloud_transport -""""""""""""""""""""""""""""""""""""""" - -It is possible to subscribe to point clouds using the ``point_cloud_transport`` package. - -See https://github.com/ros2/rviz/pull/1008 for more details. - -Feature parity with RViz for ROS -"""""""""""""""""""""""""""""""" - -It is possible to use the same plugins available in the ROS 1 version. - -* DepthCloud -* AccelStamped -* TwistStamped -* WrenchStamped -* Effort - -Camera info display -""""""""""""""""""" - -It is possible to visualize CameraInfo messages in the 3D scene. - -See https://github.com/ros2/rviz/pull/1166 for more details. - -``rcpputils`` -^^^^^^^^^^^^^ - -Added tl_expected -""""""""""""""""" - -`std::expected `__ is C++23 feature, which is not yet supported in ROS 2. -However, it is possible to use ``tl::expected`` from rcpputils via a backported implementation. - -See https://github.com/ros2/rcpputils/pull/185 for more details. - -``rcutils`` -^^^^^^^^^^^ - -Add human readable date to logging formats -"""""""""""""""""""""""""""""""""""""""""" - -It is now possible to output dates in a human readable format when using console logging by using the ``{date_time_with_ms}`` token in the ``RCUTILS_CONSOLE_OUTPUT_FORMAT`` environment variable. - -See https://github.com/ros2/rcutils/pull/441 for more details. - -Changes since the Iron release ------------------------------- - -``common_interfaces`` -^^^^^^^^^^^^^^^^^^^^^ - -Added IDs to geometry_msgs/Polygon and PolygonStamped -""""""""""""""""""""""""""""""""""""""""""""""""""""" -Polygons are often used to represent specific objects but are difficult to rectify currently without any kind of specific identification. -This feature adds an ID field to disambiguate polygons. - -See https://github.com/ros2/common_interfaces/pull/232 for more details. - - -``geometry2`` -^^^^^^^^^^^^^ - -Removed deprecated headers -"""""""""""""""""""""""""" - -In Humble, the headers: ``tf2_bullet/tf2_bullet.h``, ``tf2_eigen/tf2_eigen.h``, ``tf2_geometry_msgs/tf2_geometry_msgs.h``, -``tf2_kdl/tf2_kdl.h``, ``tf2_sensor_msgs/tf2_sensor_msgs.h`` were deprecated in favor of: ``tf2_bullet/tf2_bullet.hpp``, -``tf2_eigen/tf2_eigen.hpp``, ``tf2_geometry_msgs/tf2_geometry_msgs.hpp``, ``tf2_kdl/tf2_kdl.hpp``, ``tf2_sensor_msgs/tf2_sensor_msgs.hpp`` -In Jazzy, the ``tf2_bullet/tf2_bullet.h``, ``tf2_eigen/tf2_eigen.h``, ``tf2_geometry_msgs/tf2_geometry_msgs.h``, -``tf2_kdl/tf2_kdl.h``, ``tf2_sensor_msgs/tf2_sensor_msgs.h`` headers have been completely removed. - -Changed return types of ``wait_for_transform_async`` and ``wait_for_transform_full_async`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Previously ``wait_for_transform_async`` and ``wait_for_transform_full_async`` of the ``Buffer`` class returned a future containing true or false -In Jazzy, the future will contain the information of the transform being waited on. - -Enabled Twist interpolator -"""""""""""""""""""""""""" - -Included new API to lookup the velocity of the moving frame in the reference frame. - -See https://github.com/ros2/geometry2/pull/646 for more information. - -``rcl`` -^^^^^^^ - -Actual and expected call time when timer is called -"""""""""""""""""""""""""""""""""""""""""""""""""" - -New timer API ``rcl_timer_call_with_info`` is added to collect actual and expected call time when the timer is called. -This allows users to get the timer information when the timer is expected to be called and actual time that timer is called. - -See https://github.com/ros2/rcl/pull/1113 for more details. - -Improved rcl_wait in the area of timeout computation and spurious wakeups -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Added special handling for timers with a clock that has time override enabled. -For these timer we should not compute a timeout, as the waitset is woken up by the associated guard condition. - -See https://github.com/ros2/rcl/issues/1146 for more details. - -``rclcpp`` -^^^^^^^^^^ - -Fixed data race conditions -"""""""""""""""""""""""""" - -Fixed data race conditions in executors. - -See https://github.com/ros2/rclcpp/issues/2500 for more details. - -Utilize ``rclcpp::WaitSet`` as part of the executors -"""""""""""""""""""""""""""""""""""""""""""""""""""" - -Improve the number of ``rcl_wait_set`` creations and deletions by making the default Single/Multithreaded executors work like the static single threaded executor -in terms of entity collection rebuilding. - -See https://github.com/ros2/rclcpp/pull/2142 for more details. - -Due to this change, callbacks in the executor are no longer ordered consistently, even within the same entity. - -See https://github.com/ros2/rclcpp/issues/2532 for more details. - -``rclcpp::get_typesupport_handle`` is deprecated -"""""""""""""""""""""""""""""""""""""""""""""""" - -The ``rclcpp::get_typesupport_handle`` that extracts message type support handle is deprecated, and will be removed in a future release. -Instead, ``rclcpp::get_message_typesupport_handle`` should be used. - -See https://github.com/ros2/rclcpp/pull/2209 for more details. - -Deprecated ``rclcpp/qos_event.hpp`` header was removed -"""""""""""""""""""""""""""""""""""""""""""""""""""""" - -In Iron, the header ``rclcpp/qos_event.hpp`` was deprecated in favor of ``rclcpp/event_handler.hpp``. -In Jazzy, the ``rclcpp/qos_event.hpp`` header has been completely removed. - -Deprecated subscription callback signatures were removed -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Back in Humble, subscription signatures of the form ``void callback(std::shared_ptr)`` and ``void callback(std::shared_ptr, const rclcpp::MessageInfo &)`` were deprecated. - -In Jazzy, these subscription signatures have been removed. -Users should switch to using ``void callback(std::shared_ptr)`` or ``void callback(std::shared_ptr, const rclcpp MessageInfo &)``. - -Actual and expected call time when timer is called -"""""""""""""""""""""""""""""""""""""""""""""""""" - -``rclcpp::TimerInfo`` argument is added to the timer callback to collect actual and expected call time when the timer is called. -This allows users to get the timer information when the timer is expected to be called and actual time that timer is called. - -See https://github.com/ros2/rclcpp/pull/2343 for more details. - -``rclcpp_action`` -^^^^^^^^^^^^^^^^^ - -Callback after cancel -""""""""""""""""""""" - -Added a function to stop callbacks of a goal handle after it has gone out of scope. -This function allows us to drop the handle in a locked context. - -See https://github.com/ros2/rclcpp/pull/2281 for more details. - -``rclcpp_lifecycle`` -^^^^^^^^^^^^^^^^^^^^ - -Add new node interface TypeDescriptionsInterface -"""""""""""""""""""""""""""""""""""""""""""""""" - -Add new node interface ``TypeDescriptionsInterface`` to provide the ``GetTypeDescription`` service. - -See https://github.com/ros2/rclcpp/pull/2224 for more details. - -``rclpy`` -^^^^^^^^^ - -``rclpy.node.Node.declare_parameter`` -""""""""""""""""""""""""""""""""""""" - -The ``rclpy.node.Node.declare_parameter`` does not allow statically typing parameter without a default value. - -See https://github.com/ros2/rclpy/pull/1216 for more details. - -Added types to method arguments -""""""""""""""""""""""""""""""" - -Added type checking to improve the experience for anyone using static type checking. - -See https://github.com/ros2/rclcpp/pull/2224, https://github.com/ros2/rclpy/issues/1240, https://github.com/ros2/rclpy/issues/1237, https://github.com/ros2/rclpy/issues/1231, https://github.com/ros2/rclpy/issues/1241, and https://github.com/ros2/rclpy/issues/1233. - -``rosbag2`` -^^^^^^^^^^^ - -Rename of the ``--exclude`` CLI option -"""""""""""""""""""""""""""""""""""""" - -The ``--exclude`` CLI option was renamed to the ``--exclude-regex`` to better reflect what it does. - -See https://github.com/ros2/rosbag2/pull/1480 for more information. - -Changes in representation of the ``offered_qos_profiles`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Enum values are now used for ``offered_qos_profiles`` in the code, in human-readable string values for QoS settings in the metadata, and in the overriding QoS profile YAML files. - -See https://github.com/ros2/rosbag2/tree/jazzy?tab=readme-ov-file#overriding-qos-profiles for an example. - -Added node name to the read and write bag split event messages -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1609 for more details. - -Added ``BagSplitInfo`` service call on bag close -"""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1422 for more details. - -Resolved multiple issues related to the handling SIGINT and SIGTERM signals in rosbag2 -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1557, https://github.com/ros2/rosbag2/pull/1301 and -https://github.com/ros2/rosbag2/pull/1464 for more details. - -Added ``topic_id`` returned by storage to the ``TopicMetadata`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1538 for more details. - -Added Python bindings for CompressionOptions and CompressionMode structures -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1425 for more details. - -Improve performance in ``SqliteStorage::get_bagfile_size()`` -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This minimizes the probability of losing messages during bag split operation when recording with the SQLite3 storage plugin. - -See https://github.com/ros2/rosbag2/pull/1516 for more details. - -``rqt_bag`` -^^^^^^^^^^^ - -Improved performance and updated rosbag API -""""""""""""""""""""""""""""""""""""""""""" - -There are some breaking changes in the rosbag2 API and Ubuntu Noble library versions that required some changes to ``rqt_bag``. - -See https://github.com/ros-visualization/rqt_bag/pull/156 for more details. - -Development progress --------------------- - -For progress on the development of Jazzy Jalisco, see `this project board `__. - -For the broad process followed by Jazzy Jalisco, see the :doc:`process description page `. - -Known Issues ------------- - -To come. - -Release Timeline ----------------- - - November, 2023 - Platform decisions - REP 2000 is updated with the target platforms and major dependency versions. - - By January, 2024 - Rolling platform shift - Build farm is updated with the new platform versions and dependency versions for Jazzy Jalisco. - - Mon. April 8, 2024 - Alpha + RMW freeze - Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. - - Mon. April 15, 2024 - Freeze - API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 22, 2024 - Branch - Branch from Rolling Ridley. - ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. - Jazzy development shifts from ``ros-rolling-*`` packages to ``ros-jazzy-*`` packages. - - Mon. April 29, 2024 - Beta - Updated releases of ROS Desktop [2]_ packages available. - Call for general testing. - - Wed, May 1, 2024 - Kick off of Tutorial Party - Tutorials hosted at https://github.com/osrf/ros2_test_cases are open for community testing. - - Mon. May 13, 2024 - Release Candidate - Release Candidate packages are built. - Updated releases of ROS Desktop [2]_ packages available. - - Mon. May 20, 2024 - Distro Freeze - Freeze all Jazzy branches on all `ROS 2 desktop packages `__ and ``rosdistro``. - No pull requests for any ``jazzy`` branch or targeting ``jazzy/distribution.yaml`` in ``rosdistro`` repo will be merged. - - Thu. May 23, 2024 - General Availability - Release announcement. - `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Jazzy pull requests. - -.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. +.. redirect-from:: + + Releases/Release-Jazzy-Jalisco + +.. _jazzy-release: + +Jazzy Jalisco (``jazzy``) +========================= + +.. toctree:: + :hidden: + + Jazzy-Jalisco-Complete-Changelog + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Jazzy Jalisco* is the tenth release of ROS 2. +What follows is highlights of the important changes and features in Jazzy Jalisco since the last release. +For a list of all of the changes since Iron, see the :doc:`long form changelog ` + +Supported Platforms +------------------- + +Jazzy Jalisco supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019): ``amd64`` + +Tier 2 platforms: + +* RHEL 9: ``amd64`` + +Tier 3 platforms: + +* macOS: ``amd64`` +* Debian Bookworm: ``amd64`` + +Targeted platforms: + ++--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ +| Architecture | Ubuntu Noble (24.04) | Windows 10 (VS2019) | RHEL 9 | Ubuntu Jammy (22.04) | macOS | Debian Bookworm (12) | OpenEmbedded / | +| | | | | | | | Yocto Project | ++==============+=======================+======================+======================+=======================+=========+=======================+=============================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s] | Tier 3 | Tier 3 [s] | Tier 3 [s] | +| | | | | | [s] | | | ++--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ +| arm64 | Tier 1 [d][a][s] | | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ +| arm32 | Tier 3 [s] | | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-----------------------+----------------------+----------------------+-----------------------+---------+-----------------------+-----------------------------+ + + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be +provided for this platform for packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Jazzy ROS 2 repos file[^13]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++==========================+=========================+===============+============================+================================+ +| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ +| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64 | ++--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | ++--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32 | ++--------------------------+-------------------------+---------------+----------------------------+--------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++17 +- Python 3.8 + +Dependency Requirements: + ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| | Required Support | Recommended Support | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Package | Ubuntu Noble | Windows 10** | RHEL 9 | Ubuntu Jammy | macOS** | Debian Bookworm | OpenEmbedded** | ++=============+===============+===============+========+==============+============+=================+=====================+ +| CMake | 3.28.3 | 3.22.0 | 3.20.2 | 3.22.1 | 3.20.0 | 3.25.1 | 3.22.3 | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| EmPY | 3.3.4 | 3.3.2 | 3.3.4 | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Gazebo | Harmonic* | N/A | N/A | Harmonic* | Harmonic* | Harmonic* | N/A | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| NumPy | 1.26.4 | 1.18.4 | 1.20.1 | 1.21.5 | 1.18.4 | 1.24.2 | N/A | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Ogre | 1.12.10 | N/A | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| OpenCV | 4.6.0 | 3.4.6* | 4.6.0 | 4.5.4 | 4.2.0 | 4.6.0 | 4.1.0 / 3.2.0*** | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| OpenSSL | 3.0.13 | 1.1.1l | 3.0.7 | 1.1.1l | 1.1.1f | 3.0.11 | 1.1.1d / 1.1.1b*** | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Python | 3.12.3 | 3.8.3 | 3.9.16 | 3.10.4 | 3.10.8 | 3.11.2 | 3.8.2 / 3.7.5*** | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Qt | 5.15.10 | 5.12.12 | 5.15.3 | 5.15.3 | 5.12.3 | 5.15.8 | 5.14.1 / 5.12.5*** | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| | **Linux only** | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| PCL | 1.14.0 | N/A | 1.12.0 | 1.12.1 | N/A | 1.13.0 | 1.10.0 | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| **RMW DDS Middleware** | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Cyclone DDS | 0.10.4 | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Fast-DDS | 2.14.0 | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Connext DDS | 6.0.1 | N/A | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ +| Gurum DDS | 4.2.0 | N/A | ++-------------+---------------+---------------+--------+--------------+------------+-----------------+---------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" means that the dependency may see multiple version changes, +because the dependency uses a package manager that continually updates +the dependency without a stable API. + +\" \*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt, pip +- Windows: Chocolatey, pip +- macOS: Homebrew, pip +- RHEL: dnf +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cmake +- setuptools + +Installation +------------ + +`Install Jazzy Jalisco <../../jazzy/Installation.html>`__ + +Changes to how ROS 2 and Gazebo integrate +----------------------------------------- + +Starting with Jazzy Jalisco, we are streamlining how ROS 2 and `Gazebo `__ integrate. +For every ROS 2 release, there will be a recommended, supported Gazebo release that goes along with that release. +For Jazzy Jalisco, the recommended Gazebo release will be Harmonic. + +To make it easier for ROS 2 packages to consume Gazebo packages, there are now ``gz_*_vendor`` packages. +Those packages are: + +* gz_common_vendor: https://github.com/gazebo-release/gz_common_vendor +* gz_cmake_vendor: https://github.com/gazebo-release/gz_cmake_vendor +* gz_math_vendor: https://github.com/gazebo-release/gz_math_vendor +* gz_transport_vendor: https://github.com/gazebo-release/gz_transport_vendor +* gz_sensor_vendor: https://github.com/gazebo-release/gz_sensor_vendor +* gz_sim_vendor: https://github.com/gazebo-release/gz_sim_vendor +* gz_tools_vendor: https://github.com/gazebo-release/gz_tools_vendor +* gz_utils_vendor: https://github.com/gazebo-release/gz_utils_vendor +* sdformat_vendor: https://github.com/gazebo-release/sdformat_vendor + +ROS 2 packages can use the functionality in these packages by adding dependencies in ``package.xml``, e.g.: + +.. code:: + + gz_math_vendor + +And then using them in ``CMakeLists.txt``, e.g.: + +.. code:: + + find_package(gz_math_vendor REQUIRED) + find_package(gz-math) + + add_executable(my_executable src/exe.cpp) + target_link_libraries(my_executable gz-math::core) + +.. note:: + + It will still be possible to use alternate Gazebo versions with Jazzy Jalisco. But those will not be as well tested or integrated with ROS 2. See https://gazebosim.org/docs/harmonic/ros_installation for more information. + +New features in this ROS 2 release +---------------------------------- + +``common_interfaces`` +^^^^^^^^^^^^^^^^^^^^^ + +New VelocityStamped message +""""""""""""""""""""""""""" + +Added a new message with all fields needed to define a velocity and transform it. + +See https://github.com/ros2/common_interfaces/pull/240 for more details. + +Adds ARROW_STRIP to Marker.msg +"""""""""""""""""""""""""""""" + +Added new type of Marker, ``ARROW_STRIP``, to Marker.msg. + +See https://github.com/ros2/common_interfaces/pull/242 for more details. + +``image_transport`` +^^^^^^^^^^^^^^^^^^^ + +Support lazy subscribers +"""""""""""""""""""""""" + +See https://github.com/ros-perception/image_common/issues/272 for more details. + +Expose option to set callback groups +"""""""""""""""""""""""""""""""""""" + +See https://github.com/ros-perception/image_common/issues/274 for more details. + +Enable allow list +""""""""""""""""" + +Added parameter so users can selectively disable ``image_transport`` plugins at runtime. + +See https://github.com/ros-perception/image_common/issues/264 for more details. + +Advertise and subscribe with custom QoS +""""""""""""""""""""""""""""""""""""""" + +Allow users to pass in a custom quality-of-service when creating ``image_transport`` publishers and subscribers. + +See https://github.com/ros-perception/image_common/issues/288 for more detatils. + +Added rclcpp component to Republish +""""""""""""""""""""""""""""""""""" + +Users can now start the ``image_transport`` republisher node as an rclcpp_component. + +See https://github.com/ros-perception/image_common/issues/275 for more details. + + +``message_filters`` +^^^^^^^^^^^^^^^^^^^ + +TypeAdapters support +"""""""""""""""""""" + +Allows users to use Type Adaptation within message_filters. + +See https://github.com/ros2/message_filters/pull/96 for more information. + +``rcl`` +^^^^^^^ + +Add get type description service +"""""""""""""""""""""""""""""""" + +Implements the ``~/get_type_description`` service which allows external users to get descriptions of each type that a node offers. +This is offered by each node according to `REP 2016 `__. + +See https://github.com/ros2/rcl/pull/1052 for more details. + +``rclcpp`` +^^^^^^^^^^ + +Type support helper for services +"""""""""""""""""""""""""""""""" + +New type support helper for services ``rclcpp::get_service_typesupport_handle`` is added to extract service type support handle. + +See https://github.com/ros2/rclcpp/pull/2209 for more details. + +``rclpy`` +^^^^^^^^^^ + +ParameterEventHandler +""""""""""""""""""""" + +New class ``ParameterEventHandler`` allows us to monitor and respond changes to parameters via parameter events. + +See https://github.com/ros2/rclpy/pull/1135 for more details. + +``ros2cli`` +^^^^^^^^^^^ + +Added a ``--log-file-name`` command line argument +""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to use ``--log-file-name`` command line argument to specify the log file name prefix. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker --ros-args --log-file-name filename + +See https://github.com/ros2/ros2cli/issues/856 for more information. + +Added QoS to subscription options +""""""""""""""""""""""""""""""""" + +A user-settable QoS parameter was added to the ``TopicStatisticsOptions``, which allows the statistics to have a different QoS from the subscription itself. + +See https://github.com/ros2/rclcpp/pull/2323 for more details. + +Add clients and services count +"""""""""""""""""""""""""""""" + +It is now possible to get the number of clients created by a service. + +``ros2action`` +^^^^^^^^^^^^^^ + +``type`` sub-command supported +"""""""""""""""""""""""""""""" + +It is now possible to use the ``type`` sub-command to check the action type. + +.. code-block:: console + + $ ros2 action type /fibonacci + action_tutorials_interfaces/action/Fibonacci + +See https://github.com/ros2/ros2cli/pull/894 for more information. + +``rosbag2`` +^^^^^^^^^^^ + +Service recording and playback +"""""""""""""""""""""""""""""" + +It is now possible to record and play service data with the ``ros2bag`` command line interface. + +This features builds on `Service Introspection `__, which has been available since Iron Irwini. +`Service recording and display `__ adds the ability to record service data into a bag file. +And `Service playback `__ can play that service data from the bag file. + +Record all services data: + +.. code-block:: console + + $ ros2 bag record --all-services + +Record all services and all topic data: + +.. code-block:: console + + $ ros2 bag record --all + +Play service data from bag file: + +.. code-block:: console + + $ ros2 bag play --publish-service-requests bag_path + +See the `design document `__ for more information. + +New filter modes +"""""""""""""""" + +It is now possible to filter by topic type. + +.. code-block:: console + + $ ros2 bag record --topic_types sensor_msgs/msg/Image sensor_msgs/msg/CameraInfo + +.. code-block:: console + + $ ros2 bag record --topic_types sensor_msgs/msg/Image + +See more details https://github.com/ros2/rosbag2/pull/1577 and https://github.com/ros2/rosbag2/pull/1582. + +Player and Recorder are now exposed as rclcpp components +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This allows a "zero-copy" when using intra-process communication during data record or reply. +This can significantly reduce CPU load during recording or reply when dealing with high-bandwidth data streams and will help to avoid data loss in the transport layer. +It also provides the ability to use YAML configuration files for ``rosbag2_transport::Player`` and ``rosbag2_transport::Recorder`` composable nodes. + +See https://github.com/ros2/rosbag2/tree/jazzy?tab=readme-ov-file#using-with-composition for more details. + +Added option to disable recorder keyboard controls +"""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1607 for more details. + +Use middleware send and receive timestamps from ``message_info`` during recording +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Where available, ``rosbag2`` now uses the send and receive timestamps as provided by the middleware. +These timestamps are more indicative of when the data was actually sent and received, respectively. +Note that saving the timestamp into a bag is currently only supported for MCAP files (the default). + +See https://github.com/ros2/rosbag2/pull/1531 for more details. + +Added compression threads priority to record options +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to specify the priority of the thread that performs compression. + +See https://github.com/ros2/rosbag2/pull/1457 for more details. + +Added ability to split already existing ros2 bags by time +""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Added ``start_time_ns`` and ``end_time_ns`` to the ``StorageOptions`` to exclude messages not in +``[start_time;end_time]`` during the ``ros2 bag convert`` operation. + +See https://github.com/ros2/rosbag2/pull/1455 for more details. + +Store serialized metadata in bag files directly +""""""""""""""""""""""""""""""""""""""""""""""" + +``rosbag2`` has always stored metadata in the ``metadata.yaml`` file associated with a bag file. +Now the metadata is also stored in each bag file, once when opening the file and a second time when closing the written bag file. +This allows bag files to be self-contained, and used without the ``metadata.yaml`` file in the rosbag2 player or third-party applications. +``ros2 bag reindex`` can still be used to restore the ``metadata.yaml`` file, if desired. + +Store ROS_DISTRO name in the metadata +""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1241 for more details. + +Added introspection QoS methods to Python bindings +"""""""""""""""""""""""""""""""""""""""""""""""""" + +It is now possible to instrospect QoS setting from Python bindings. + +See https://github.com/ros2/rosbag2/pull/1648 for more details. + +``rosidl`` +^^^^^^^^^^ + +Added interfaces to support key annotation +"""""""""""""""""""""""""""""""""""""""""" + +The ``key`` annotation allows indicating that a data member is part of the key, which can have zero or more key fields and can be applied to structure fields of various types. + +See https://github.com/ros2/rosidl/pull/796 and https://github.com/ros2/rosidl_typesupport_fastrtps/pull/116 for more details. + +``rviz2`` +^^^^^^^^^ + +Added regex filter field for TF display +""""""""""""""""""""""""""""""""""""""" + +When there are many frames on ``/tf`` it can be hard to properly visualize them in RViz, especially if frames overlap. +The usual solution to this is to enable and disable desired frames in Frames field of the TF display. +Now it is possible to filter frames using regular expressions. + +See https://github.com/ros2/rviz/pull/1032 for more details. + +Append measured subscription frequency to topic status +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +It is possible to visualize Hz in the topic status widget. + +See https://github.com/ros2/rviz/issues/1113 for more details. + +Reset functionality +""""""""""""""""""" + +It is possible to reset Time using a new service or using the keyboard shortcut ``R``. + +See https://github.com/ros2/rviz/issues/1109 and https://github.com/ros2/rviz/issues/1088 for more details. + +Added support for point_cloud_transport +""""""""""""""""""""""""""""""""""""""" + +It is possible to subscribe to point clouds using the ``point_cloud_transport`` package. + +See https://github.com/ros2/rviz/pull/1008 for more details. + +Feature parity with RViz for ROS +"""""""""""""""""""""""""""""""" + +It is possible to use the same plugins available in the ROS 1 version. + +* DepthCloud +* AccelStamped +* TwistStamped +* WrenchStamped +* Effort + +Camera info display +""""""""""""""""""" + +It is possible to visualize CameraInfo messages in the 3D scene. + +See https://github.com/ros2/rviz/pull/1166 for more details. + +``rcpputils`` +^^^^^^^^^^^^^ + +Added tl_expected +""""""""""""""""" + +`std::expected `__ is C++23 feature, which is not yet supported in ROS 2. +However, it is possible to use ``tl::expected`` from rcpputils via a backported implementation. + +See https://github.com/ros2/rcpputils/pull/185 for more details. + +``rcutils`` +^^^^^^^^^^^ + +Add human readable date to logging formats +"""""""""""""""""""""""""""""""""""""""""" + +It is now possible to output dates in a human readable format when using console logging by using the ``{date_time_with_ms}`` token in the ``RCUTILS_CONSOLE_OUTPUT_FORMAT`` environment variable. + +See https://github.com/ros2/rcutils/pull/441 for more details. + +Changes since the Iron release +------------------------------ + +``common_interfaces`` +^^^^^^^^^^^^^^^^^^^^^ + +Added IDs to geometry_msgs/Polygon and PolygonStamped +""""""""""""""""""""""""""""""""""""""""""""""""""""" +Polygons are often used to represent specific objects but are difficult to rectify currently without any kind of specific identification. +This feature adds an ID field to disambiguate polygons. + +See https://github.com/ros2/common_interfaces/pull/232 for more details. + + +``geometry2`` +^^^^^^^^^^^^^ + +Removed deprecated headers +"""""""""""""""""""""""""" + +In Humble, the headers: ``tf2_bullet/tf2_bullet.h``, ``tf2_eigen/tf2_eigen.h``, ``tf2_geometry_msgs/tf2_geometry_msgs.h``, +``tf2_kdl/tf2_kdl.h``, ``tf2_sensor_msgs/tf2_sensor_msgs.h`` were deprecated in favor of: ``tf2_bullet/tf2_bullet.hpp``, +``tf2_eigen/tf2_eigen.hpp``, ``tf2_geometry_msgs/tf2_geometry_msgs.hpp``, ``tf2_kdl/tf2_kdl.hpp``, ``tf2_sensor_msgs/tf2_sensor_msgs.hpp`` +In Jazzy, the ``tf2_bullet/tf2_bullet.h``, ``tf2_eigen/tf2_eigen.h``, ``tf2_geometry_msgs/tf2_geometry_msgs.h``, +``tf2_kdl/tf2_kdl.h``, ``tf2_sensor_msgs/tf2_sensor_msgs.h`` headers have been completely removed. + +Changed return types of ``wait_for_transform_async`` and ``wait_for_transform_full_async`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Previously ``wait_for_transform_async`` and ``wait_for_transform_full_async`` of the ``Buffer`` class returned a future containing true or false +In Jazzy, the future will contain the information of the transform being waited on. + +Enabled Twist interpolator +"""""""""""""""""""""""""" + +Included new API to lookup the velocity of the moving frame in the reference frame. + +See https://github.com/ros2/geometry2/pull/646 for more information. + +``rcl`` +^^^^^^^ + +Actual and expected call time when timer is called +"""""""""""""""""""""""""""""""""""""""""""""""""" + +New timer API ``rcl_timer_call_with_info`` is added to collect actual and expected call time when the timer is called. +This allows users to get the timer information when the timer is expected to be called and actual time that timer is called. + +See https://github.com/ros2/rcl/pull/1113 for more details. + +Improved rcl_wait in the area of timeout computation and spurious wakeups +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Added special handling for timers with a clock that has time override enabled. +For these timer we should not compute a timeout, as the waitset is woken up by the associated guard condition. + +See https://github.com/ros2/rcl/issues/1146 for more details. + +``rclcpp`` +^^^^^^^^^^ + +Fixed data race conditions +"""""""""""""""""""""""""" + +Fixed data race conditions in executors. + +See https://github.com/ros2/rclcpp/issues/2500 for more details. + +Utilize ``rclcpp::WaitSet`` as part of the executors +"""""""""""""""""""""""""""""""""""""""""""""""""""" + +Improve the number of ``rcl_wait_set`` creations and deletions by making the default Single/Multithreaded executors work like the static single threaded executor +in terms of entity collection rebuilding. + +See https://github.com/ros2/rclcpp/pull/2142 for more details. + +Due to this change, callbacks in the executor are no longer ordered consistently, even within the same entity. + +See https://github.com/ros2/rclcpp/issues/2532 for more details. + +``rclcpp::get_typesupport_handle`` is deprecated +"""""""""""""""""""""""""""""""""""""""""""""""" + +The ``rclcpp::get_typesupport_handle`` that extracts message type support handle is deprecated, and will be removed in a future release. +Instead, ``rclcpp::get_message_typesupport_handle`` should be used. + +See https://github.com/ros2/rclcpp/pull/2209 for more details. + +Deprecated ``rclcpp/qos_event.hpp`` header was removed +"""""""""""""""""""""""""""""""""""""""""""""""""""""" + +In Iron, the header ``rclcpp/qos_event.hpp`` was deprecated in favor of ``rclcpp/event_handler.hpp``. +In Jazzy, the ``rclcpp/qos_event.hpp`` header has been completely removed. + +Deprecated subscription callback signatures were removed +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Back in Humble, subscription signatures of the form ``void callback(std::shared_ptr)`` and ``void callback(std::shared_ptr, const rclcpp::MessageInfo &)`` were deprecated. + +In Jazzy, these subscription signatures have been removed. +Users should switch to using ``void callback(std::shared_ptr)`` or ``void callback(std::shared_ptr, const rclcpp MessageInfo &)``. + +Actual and expected call time when timer is called +"""""""""""""""""""""""""""""""""""""""""""""""""" + +``rclcpp::TimerInfo`` argument is added to the timer callback to collect actual and expected call time when the timer is called. +This allows users to get the timer information when the timer is expected to be called and actual time that timer is called. + +See https://github.com/ros2/rclcpp/pull/2343 for more details. + +``rclcpp_action`` +^^^^^^^^^^^^^^^^^ + +Callback after cancel +""""""""""""""""""""" + +Added a function to stop callbacks of a goal handle after it has gone out of scope. +This function allows us to drop the handle in a locked context. + +See https://github.com/ros2/rclcpp/pull/2281 for more details. + +``rclcpp_lifecycle`` +^^^^^^^^^^^^^^^^^^^^ + +Add new node interface TypeDescriptionsInterface +"""""""""""""""""""""""""""""""""""""""""""""""" + +Add new node interface ``TypeDescriptionsInterface`` to provide the ``GetTypeDescription`` service. + +See https://github.com/ros2/rclcpp/pull/2224 for more details. + +``rclpy`` +^^^^^^^^^ + +``rclpy.node.Node.declare_parameter`` +""""""""""""""""""""""""""""""""""""" + +The ``rclpy.node.Node.declare_parameter`` does not allow statically typing parameter without a default value. + +See https://github.com/ros2/rclpy/pull/1216 for more details. + +Added types to method arguments +""""""""""""""""""""""""""""""" + +Added type checking to improve the experience for anyone using static type checking. + +See https://github.com/ros2/rclcpp/pull/2224, https://github.com/ros2/rclpy/issues/1240, https://github.com/ros2/rclpy/issues/1237, https://github.com/ros2/rclpy/issues/1231, https://github.com/ros2/rclpy/issues/1241, and https://github.com/ros2/rclpy/issues/1233. + +``rosbag2`` +^^^^^^^^^^^ + +Rename of the ``--exclude`` CLI option +"""""""""""""""""""""""""""""""""""""" + +The ``--exclude`` CLI option was renamed to the ``--exclude-regex`` to better reflect what it does. + +See https://github.com/ros2/rosbag2/pull/1480 for more information. + +Changes in representation of the ``offered_qos_profiles`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Enum values are now used for ``offered_qos_profiles`` in the code, in human-readable string values for QoS settings in the metadata, and in the overriding QoS profile YAML files. + +See https://github.com/ros2/rosbag2/tree/jazzy?tab=readme-ov-file#overriding-qos-profiles for an example. + +Added node name to the read and write bag split event messages +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1609 for more details. + +Added ``BagSplitInfo`` service call on bag close +"""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1422 for more details. + +Resolved multiple issues related to the handling SIGINT and SIGTERM signals in rosbag2 +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1557, https://github.com/ros2/rosbag2/pull/1301 and +https://github.com/ros2/rosbag2/pull/1464 for more details. + +Added ``topic_id`` returned by storage to the ``TopicMetadata`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1538 for more details. + +Added Python bindings for CompressionOptions and CompressionMode structures +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1425 for more details. + +Improve performance in ``SqliteStorage::get_bagfile_size()`` +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This minimizes the probability of losing messages during bag split operation when recording with the SQLite3 storage plugin. + +See https://github.com/ros2/rosbag2/pull/1516 for more details. + +``rqt_bag`` +^^^^^^^^^^^ + +Improved performance and updated rosbag API +""""""""""""""""""""""""""""""""""""""""""" + +There are some breaking changes in the rosbag2 API and Ubuntu Noble library versions that required some changes to ``rqt_bag``. + +See https://github.com/ros-visualization/rqt_bag/pull/156 for more details. + +Development progress +-------------------- + +For progress on the development of Jazzy Jalisco, see `this project board `__. + +For the broad process followed by Jazzy Jalisco, see the :doc:`process description page `. + +Known Issues +------------ + +To come. + +Release Timeline +---------------- + + November, 2023 - Platform decisions + REP 2000 is updated with the target platforms and major dependency versions. + + By January, 2024 - Rolling platform shift + Build farm is updated with the new platform versions and dependency versions for Jazzy Jalisco. + + Mon. April 8, 2024 - Alpha + RMW freeze + Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. + + Mon. April 15, 2024 - Freeze + API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 22, 2024 - Branch + Branch from Rolling Ridley. + ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. + Jazzy development shifts from ``ros-rolling-*`` packages to ``ros-jazzy-*`` packages. + + Mon. April 29, 2024 - Beta + Updated releases of ROS Desktop [2]_ packages available. + Call for general testing. + + Wed, May 1, 2024 - Kick off of Tutorial Party + Tutorials hosted at https://github.com/osrf/ros2_test_cases are open for community testing. + + Mon. May 13, 2024 - Release Candidate + Release Candidate packages are built. + Updated releases of ROS Desktop [2]_ packages available. + + Mon. May 20, 2024 - Distro Freeze + Freeze all Jazzy branches on all `ROS 2 desktop packages `__ and ``rosdistro``. + No pull requests for any ``jazzy`` branch or targeting ``jazzy/distribution.yaml`` in ``rosdistro`` repo will be merged. + + Thu. May 23, 2024 - General Availability + Release announcement. + `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Jazzy pull requests. + +.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Kilted-Kaiju.rst b/source/Get-Started/Releases/Release-Kilted-Kaiju.rst index 4a18aff6ad8..4f13e9153b9 100644 --- a/source/Get-Started/Releases/Release-Kilted-Kaiju.rst +++ b/source/Get-Started/Releases/Release-Kilted-Kaiju.rst @@ -1,557 +1,561 @@ -.. _latest-release: - -.. _kilted-release: - -Kilted Kaiju (codename 'kilted'; May, 2025) -=========================================== - -.. toctree:: - :hidden: - - Kilted-Kaiju-Complete-Changelog - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Kilted Kaiju* is the eleventh release of ROS 2. -What follows is highlights of the important changes and features in Kilted Kaiju since the last release. -For a list of all of the changes since Jazzy, see the :doc:`long form changelog ` - -Supported Platforms -------------------- - -Kilted Kaiju supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019): ``amd64`` - -Tier 2 platforms: - -* RHEL 9: ``amd64`` - -Tier 3 platforms: - -* macOS: ``amd64`` -* Debian Bookworm: ``amd64`` - -Targeted platforms: - -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -| Architecture | Ubuntu Noble | Windows 10 | RHEL 9 | macOS | Debian Bookworm | OpenEmbedded / | -| | (24.04) | (VS2019) | | | (12) | Yocto Project | -+==============+===================+===============+===================+===========+=================+================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s]| Tier 3 [s] | Tier 3 [s] | -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be -provided for this platform for packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Jazzy ROS 2 repos file[^14]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+===========================+=========================+===============+============================+===============================+ -| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64| -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_zenoh_cpp | Eclipse Zenoh | Tier 1 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32| -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++17 -- Python 3.9 - -Dependency Requirements: - -+---------------+-------------------------------+-------------------------------------------------------------+ -| | Required Support | Recommended Support | -+===============+===============+===============+==========+==========+==================+====================+ -| Package | Ubuntu Noble | Windows 10** | RHEL 9 | macOS** | Debian Bookworm | OpenEmbedded** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| CMake | 3.28.3 | 3.28.3 | 3.26.5 | 3.31.1 | 3.25.1 | 3.22.3 | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| EmPY | 3.3.4 | 3.3.4 | 3.3.4a | 3.3.4 | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Gazebo | Ionic* | N/A | N/A | Ionic* | Ionic* | N/A | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| NumPy | 1.26.4 | 1.26.4 | 1.20.1 | 2.1.3 | 1.24.2 | N/A | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Ogre | 1.12.10 | N/A | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| OpenCV | 4.6.0 | 4.9.0 | 4.6.0 | 4.10.0 | 4.6.0 | 4.1.0 / 3.2.0*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| OpenSSL | 3.0.13 | 3.3.2 | 3.2.2 | 1.1.1w | 3.0.15 | 1.1.1d / 1.1.1b*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Python | 3.12.3 | 3.12.3 | 3.9.19 | 3.13.0 | 3.11.2 | 3.8.2 / 3.7.5*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Qt | 5.15.13 | 5.15.8 | 5.15.9 | 5.15.16 | 5.15.8 | 5.14.1 / 5.12.5*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| | **Linux only** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| PCL | 1.14.0 | N/A | 1.12.0 | 1.14.1 | 1.13.0 | 1.10.0 | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| **RMW Middleware** | -+---------------------------------------------------------------------+---------------------------------------+ -| Connext DDS | 7.3.0.0 | N/A | -+---------------+-----------------------------------------------------+---------------------------------------+ -| Cyclone DDS | 0.10.5 | -+---------------+---------------------------------------------------------------------------------------------+ -| Fast-DDS | 2.14.4 | -+---------------+-------------------------------+-------------------------------------------------------------+ -| Gurum DDS | 4.2.0 | N/A | -+---------------+-------------------------------+-------------------------------------------------------------+ -| Zenoh | 1.0.4 | -+---------------+---------------------------------------------------------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" means that the dependency may see multiple version changes, -because the dependency uses a package manager that continually updates -the dependency without a stable API. - -\" \*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt, pip -- Windows: pixi/conda, pip -- macOS: Homebrew, pip -- RHEL: dnf -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cargo -- cmake -- setuptools - -Installation ------------- - -`Install Kilted Kaiju <../../kilted/Installation.html>`__ - -Supported Gazebo Release ------------------------- -For Kilted Kaiju, the recommended Gazebo release is `Ionic `__. - -New features in this ROS 2 release ----------------------------------- - -``ament_cmake_ros`` -^^^^^^^^^^^^^^^^^^^ - -Add rmw_test_fixture for supporting RMW-isolated testing -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Included two new packages which provide an extensible mechanism for creating a test fixture for RMW-based communication isolation. -It is modeled closely after the rmw and rmw_implementation API. - -The ``rmw_test_fixture`` package currently provides only the API, which could be implemented by an RMW provider for configuring their RMW for a test to run. - -The ``rmw_test_fixture_implementation`` package provides the entry point for discovering, loading, and invoking the appropriate extension. - -See https://github.com/ros2/ament_cmake_ros/pull/21 for more details. - -``common_interfaces`` -^^^^^^^^^^^^^^^^^^^^^ - -New nav_msgs/Goals message -"""""""""""""""""""""""""" - -A new message type, {interface(nav_msgs/msg/Goals)}, has been introduced to support an array of navigation goals within the nav_msgs package. - -See https://github.com/ros2/common_interfaces/pull/269 for more details. - -``ros2cli`` -^^^^^^^^^^^ - -Action introspection -"""""""""""""""""""" - -This allows to instrospect an action with the command line. -Using ``ros2cli`` tools: ``ros2 action echo ``. - -See https://github.com/ros2/ros2cli/pull/978 for more information. -Visit :ref:`ros2 action echo ` and :doc:`Action Introspection <../Tutorials/Demos/Action-Introspection>` to learn more about this feature. - -``rclcpp`` -^^^^^^^^^^ - -Action generic client -""""""""""""""""""""" - -Support action generic client, this is used to support actions in rosbag2. - -See https://github.com/ros2/rclcpp/pull/2759 for more details. - -``rclpy`` -^^^^^^^^^ - -Static Type Checking -"""""""""""""""""""" - -Added static type hints to ``ActionClient`` and ``ActionServer``. - -See https://github.com/ros2/rclpy/pull/1349 for more details. - -Add support for `generics `_ in ``pub/sub/client/server/actions``, ``Future/Task``, and ``Parameter``. - -``Publisher``, ``Subscription``, ``Server``, ``Task``, and ``Parameter`` should need no updates to add support for generics. - -``Client`` will need to be updated to resemble the following to get the improved type checking. - -.. code-block:: python - - self._get_parameter_client: Client[GetParameters.Request, - GetParameters.Response] = self.node.create_client( - GetParameters, '/get_parameters', - qos_profile=qos_profile, callback_group=callback_group) - -``ActionClient`` will need to be updated to resemble the following to get the improved type checking. - -.. code-block:: python - - ac: ActionClient[Fibonacci.Goal, - Fibonacci.Result, - Fibonacci.Feedback] = ActionClient(self.node, Fibonacci, 'fibonacci') - -``Future`` will need to be updated to resemble the following to get the improved type checking. - -.. code-block:: python - - log_msgs_future: Future[bool] = Future() - -See https://github.com/ros2/rclpy/pull/1239, https://github.com/ros2/rclpy/pull/1275, https://github.com/ros2/rclpy/pull/1246, and https://github.com/ros2/rclpy/pull/1254/files for more details. - -Various other small improvements and corrections have also been made throughout all of ``rclpy``. - -Python types can be statically checked using `ament_mypy `_ which wraps `mypy `_. - -EventsExecutor -"""""""""""""" - -Support an experimental events executor for ``rclpy``, which is a port of the original ``rclcpp`` events executor concept. - -See https://github.com/ros2/rclpy/pull/1391 for more details. - -``Rosbag2`` -^^^^^^^^^^^ - -Action introspection Rosbag2 support -"""""""""""""""""""""""""""""""""""" - -Allow to record and play actions from a rosbag. - -See https://github.com/ros2/rosbag2/pull/1955 for more information. -Design document https://github.com/ros2/rosbag2/pull/1928. -Visit :ref:`Managing Action Data ` to learn more about this feature. - -Progress bar for ``ros2 bag play`` -"""""""""""""""""""""""""""""""""" - -Added a progress bar for ``ros2 bag play`` CLI, showing the bag time and duration, similar to -what is seen in ROS 1. - -See https://github.com/ros2/rosbag2/pull/1836 for more details. - -Added support for replaying multiple bags with ``ros2 bag play`` CLI -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -To replay multiple bags, use the new ``-i, --input`` CLI option: - -.. code-block:: console - - $ ros2 bag play -i bag1 -i bag2 -i bag3 [storage_id] - -See https://github.com/ros2/rosbag2/pull/1848 for more information. - -Added support for replaying messages chronologically based on their publication timestamp -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This is exposed through ``ros2 bag play`` with a new ``--message-order {received,sent}`` option. -The default behavior is to play messages in the order they were received. - -See https://github.com/ros2/rosbag2/pull/1876 for more information. - -Make snapshot writing into a new file each time it is triggered -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1842 for more details. - -New ``--sort`` CLI option in the ``ros2 bag info`` command -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -With new ``--sort`` CLI option user will be able to sort topics, services and actions by name, topic type or number of recorded messages. - -See https://github.com/ros2/rosbag2/pull/1804 for more details. - -Show size contribution of each topic with ``ros2 bag info`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -With new ``--size-contribution`` option together with ``ros2 bag info -v`` user will be able to see the size contribution of each topic in the bag file. - -See https://github.com/ros2/rosbag2/pull/1726 for more information. - -Added ``--log-level`` option to ``ros2 bag play`` and ``ros2 bag record`` to allow printing debug messages -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1625 for more details. - -``rosidl_rust`` -^^^^^^^^^^^^^^^ - -Added ``rosidl_rust`` -""""""""""""""""""""" - -A Rust idl generator was added to the list of default code generators. - -See https://github.com/ros2/ros2/pull/1674 for more details. - -``ros2`` -^^^^^^^^ - -Switch to using Pixi/Conda for Windows -"""""""""""""""""""""""""""""""""""""" - -This allows to easily manage dependencies, and to update them in the future. -The installation process is significantly simplified. -Instead of dozens of steps to install dependencies, it is just a couple of commands. -It is much easier to update dependencies. -The dependencies are installed in individual workspaces, with no “global” installation. - -See https://github.com/ros2/ci/pull/802 and https://github.com/ros2/ros2/pull/1642 for more details. -Visit :doc:`Windows source install instructions <../Installation/Alternatives/Windows-Development-Setup>` to install it on Windows. - -Support topic instances in DDS topics -""""""""""""""""""""""""""""""""""""" - -Topic instances are a way of multiplexing the transmission of updates of several objects of the same logical kind over the same resource, i.e. the topic. - -See https://github.com/ros2/ros2/issues/1538 for more information. -You can also check the documentation: https://github.com/ros2/design/pull/340/files. - -Changes since the Jazzy release -------------------------------- - -``common_interfaces`` -^^^^^^^^^^^^^^^^^^^^^ - -Added NV12 to pixel formats -""""""""""""""""""""""""""" - -Added NV12 to pixel formats, which is a common output format of hardware-accelerated decoders. - -See https://github.com/ros2/common_interfaces/pull/253 for more details. - -``rclcpp`` -^^^^^^^^^^ - -Consistent behavior for Subordinate nodes -""""""""""""""""""""""""""""""""""""""""" - -Inconsistent behavior of subordinate nodes was fixed. -The subordinate node is a secondary node associated with a primary node, that shares the same underlying context and resources while maintaining a separate name and namespace. -The behavioral modification may affect existing applications relying on the previous implementation: - -1. Generic clients created from a subordinate node now correctly respect the subordinate node's sub-namespace -2. Parameters obtained using a subordinate node now correctly use the (parent) node's ``rclcpp::node_interfaces::NodeParametersInterface`` - -See https://github.com/ros2/rclcpp/pull/2822 for more details. - -``rmw_connextdds_cpp`` -^^^^^^^^^^^^^^^^^^^^^^ - -Version bumped to 7.3 -""""""""""""""""""""" - -The RTI Connext DDS version was bumped to 7.3.0. - -See https://github.com/ros2/ci/pull/811 for more details. - -``Connextmicro`` -^^^^^^^^^^^^^^^^ - -deprecated Connextmicro -""""""""""""""""""""""" - -The RTI Connext Micro RMW package, ``rmw_connextddsmicro``, is going to stop receiving updates in Kilted Kaiju, and be removed in a future ROS 2 release. - -See https://github.com/ros2/rmw_connextdds/pull/182 for more information. - -``rosidl_dynamic_typesupport`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Removing support for float128 -""""""""""""""""""""""""""""" - -Removed support for float128 because there are inconsistencies in the definition. - -See https://github.com/ros2/rosidl_dynamic_typesupport/issues/11 for more details. - -``rmw_fastrtps_cpp`` -^^^^^^^^^^^^^^^^^^^^ - -Renaming package from fastrtps to fastdds -""""""""""""""""""""""""""""""""""""""""" - -``fastrtps`` was renamed to ``fastdds``. -The names of the rmw implementations stay the same. -XML Profile ENV strings will change. - -See https://github.com/ros2/ros2/pull/1641 for more details. - -ament_target_dependencies is deprecated -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The CMake macro ``ament_target_dependencies()`` has been deprecated in favor of ``target_link_libraries()`` with modern CMake targets. -The macro still works, but it emits a CMake deprecation warning at build time like this: - -.. code-block:: - - CMake Deprecation Warning at [...]/ament_cmake_target_dependencies/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:89 (message): - ament_target_dependencies() is deprecated. Use target_link_libraries() - with modern CMake targets instead. Try replacing this call with: - - target_link_libraries([...] PUBLIC - [...] - ) - -Try replacing the ``ament_target_dependencies()`` call with the ``target_link_libraries()`` call suggested by the warning. -For more information see `ament/ament_cmake#572 `__ and `ament/ament_cmake#292 `__. - -Note that the deprecation warning suggests a call to ``target_link_libraries`` with a scope keyword like ``PUBLIC``, ``PRIVATE``, or ``INTERFACE``. -If you have already used ``target_link_libraries()`` on this target without a scope keyword, then you must remove the scope keyword from the suggested call. -This can happen when using some ``ament_cmake`` macros, like ``ament_add_gtest``, which use the plain version of ``target_link_libraries`` internally. -You will know if you need to remove the keyword because CMake will emit an error saying: - -.. code-block:: - - All uses of target_link_libraries with a target must be either all-keyword or all-plain. - -For more information, see `ament/ament_cmake#580 `__. - - -``launch`` -^^^^^^^^^^ - -``PathJoinSubstitution`` -"""""""""""""""""""""""" - -``PathJoinSubstitution`` now supports concatenating strings or substitutions into a single path component. -For example: - -.. code-block:: python - - PathJoinSubstitution(['robot_description', 'urdf', [LaunchConfiguration('model'), '.xacro']]) - -If the ``model`` launch configuration was set to ``my_model``, this would result in a path equal to: - -.. code-block:: python - - 'robot_description/urdf/my_model.xacro' - -For more information, see `ros2/launch#835 `__ and `ros2/launch#838 `__. - -``rmw_zenoh_cpp`` -^^^^^^^^^^^^^^^^^ - -``Tier 1`` -"""""""""" - -The ``rmw_zenoh_cpp`` is now considered Tier 1. -There are many PRs (summarized in `ros2/rmw_zenoh#265 `__) in the ROS 2 core packages, such as: - - * Make the rmw pass all core tests. - * Implement and document security - * Make it work in the Tier 1 platforms. - * Added Quality declarations - * Added to REP 2005 - * A dedicated nightly CI job - * Among others - -For more information see https://github.com/ros2/rmw_zenoh/issues/265. - -Development progress --------------------- - -For progress on the development of Kiltled Kaiju, see `this project board `__. - -For the broad process followed by Kilted Kaiju, see the :doc:`process description page `. - -Release Timeline ----------------- - - December, 2024 - Platform decisions - REP 2000 is updated with the target platforms and major dependency versions. - - Mon. April 7, 2025 - Alpha + RMW freeze - Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. - - Mon. April 14, 2025 - Freeze - API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 21, 2025 - Branch - Branch from Rolling Ridley. - ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. - Kilted development shifts from ``ros-rolling-*`` packages to ``ros-kilted-*`` packages. - - Mon. April 28, 2025 - Beta - Updated releases of ROS Desktop [2]_ packages available. - Call for general testing. - - Thu, May 1, 2025 - Kick off of Tutorial Party - Tutorials hosted at https://github.com/ros2/kilted_tutorial_party are open for community testing. - - Mon. May 12, 2025 - Release Candidate - Release Candidate packages are built. - Updated releases of ROS Desktop [2]_ packages available. - - Mon. May 19, 2025 - Distro Freeze - Freeze all Kilted branches on all `ROS 2 desktop packages `__ and ``rosdistro``. - No pull requests for any ``kilted`` branch or targeting ``kilted/distribution.yaml`` in ``rosdistro`` repo will be merged. - - Fri. May 23, 2025 - General Availability - Release announcement. - `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Kilted pull requests. - -.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. +.. redirect-from:: + + Releases/Release-Kilted-Kaiju + +.. _latest-release: + +.. _kilted-release: + +Kilted Kaiju (codename 'kilted'; May, 2025) +=========================================== + +.. toctree:: + :hidden: + + Kilted-Kaiju-Complete-Changelog + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Kilted Kaiju* is the eleventh release of ROS 2. +What follows is highlights of the important changes and features in Kilted Kaiju since the last release. +For a list of all of the changes since Jazzy, see the :doc:`long form changelog ` + +Supported Platforms +------------------- + +Kilted Kaiju supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019): ``amd64`` + +Tier 2 platforms: + +* RHEL 9: ``amd64`` + +Tier 3 platforms: + +* macOS: ``amd64`` +* Debian Bookworm: ``amd64`` + +Targeted platforms: + ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ +| Architecture | Ubuntu Noble | Windows 10 | RHEL 9 | macOS | Debian Bookworm | OpenEmbedded / | +| | (24.04) | (VS2019) | | | (12) | Yocto Project | ++==============+===================+===============+===================+===========+=================+================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s]| Tier 3 [s] | Tier 3 [s] | ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ +| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ +| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be +provided for this platform for packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Jazzy ROS 2 repos file[^14]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++===========================+=========================+===============+============================+===============================+ +| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64| ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_zenoh_cpp | Eclipse Zenoh | Tier 1 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32| ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++17 +- Python 3.9 + +Dependency Requirements: + ++---------------+-------------------------------+-------------------------------------------------------------+ +| | Required Support | Recommended Support | ++===============+===============+===============+==========+==========+==================+====================+ +| Package | Ubuntu Noble | Windows 10** | RHEL 9 | macOS** | Debian Bookworm | OpenEmbedded** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| CMake | 3.28.3 | 3.28.3 | 3.26.5 | 3.31.1 | 3.25.1 | 3.22.3 | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| EmPY | 3.3.4 | 3.3.4 | 3.3.4a | 3.3.4 | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Gazebo | Ionic* | N/A | N/A | Ionic* | Ionic* | N/A | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| NumPy | 1.26.4 | 1.26.4 | 1.20.1 | 2.1.3 | 1.24.2 | N/A | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Ogre | 1.12.10 | N/A | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| OpenCV | 4.6.0 | 4.9.0 | 4.6.0 | 4.10.0 | 4.6.0 | 4.1.0 / 3.2.0*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| OpenSSL | 3.0.13 | 3.3.2 | 3.2.2 | 1.1.1w | 3.0.15 | 1.1.1d / 1.1.1b*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Python | 3.12.3 | 3.12.3 | 3.9.19 | 3.13.0 | 3.11.2 | 3.8.2 / 3.7.5*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Qt | 5.15.13 | 5.15.8 | 5.15.9 | 5.15.16 | 5.15.8 | 5.14.1 / 5.12.5*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| | **Linux only** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| PCL | 1.14.0 | N/A | 1.12.0 | 1.14.1 | 1.13.0 | 1.10.0 | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| **RMW Middleware** | ++---------------------------------------------------------------------+---------------------------------------+ +| Connext DDS | 7.3.0.0 | N/A | ++---------------+-----------------------------------------------------+---------------------------------------+ +| Cyclone DDS | 0.10.5 | ++---------------+---------------------------------------------------------------------------------------------+ +| Fast-DDS | 2.14.4 | ++---------------+-------------------------------+-------------------------------------------------------------+ +| Gurum DDS | 4.2.0 | N/A | ++---------------+-------------------------------+-------------------------------------------------------------+ +| Zenoh | 1.0.4 | ++---------------+---------------------------------------------------------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" means that the dependency may see multiple version changes, +because the dependency uses a package manager that continually updates +the dependency without a stable API. + +\" \*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt, pip +- Windows: pixi/conda, pip +- macOS: Homebrew, pip +- RHEL: dnf +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cargo +- cmake +- setuptools + +Installation +------------ + +`Install Kilted Kaiju <../../kilted/Installation.html>`__ + +Supported Gazebo Release +------------------------ +For Kilted Kaiju, the recommended Gazebo release is `Ionic `__. + +New features in this ROS 2 release +---------------------------------- + +``ament_cmake_ros`` +^^^^^^^^^^^^^^^^^^^ + +Add rmw_test_fixture for supporting RMW-isolated testing +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Included two new packages which provide an extensible mechanism for creating a test fixture for RMW-based communication isolation. +It is modeled closely after the rmw and rmw_implementation API. + +The ``rmw_test_fixture`` package currently provides only the API, which could be implemented by an RMW provider for configuring their RMW for a test to run. + +The ``rmw_test_fixture_implementation`` package provides the entry point for discovering, loading, and invoking the appropriate extension. + +See https://github.com/ros2/ament_cmake_ros/pull/21 for more details. + +``common_interfaces`` +^^^^^^^^^^^^^^^^^^^^^ + +New nav_msgs/Goals message +"""""""""""""""""""""""""" + +A new message type, {interface(nav_msgs/msg/Goals)}, has been introduced to support an array of navigation goals within the nav_msgs package. + +See https://github.com/ros2/common_interfaces/pull/269 for more details. + +``ros2cli`` +^^^^^^^^^^^ + +Action introspection +"""""""""""""""""""" + +This allows to instrospect an action with the command line. +Using ``ros2cli`` tools: ``ros2 action echo ``. + +See https://github.com/ros2/ros2cli/pull/978 for more information. +Visit :ref:`ros2 action echo ` and :doc:`Action Introspection <../../ROS-Framework/actions/Working-with-actions/Action-Introspection>` to learn more about this feature. + +``rclcpp`` +^^^^^^^^^^ + +Action generic client +""""""""""""""""""""" + +Support action generic client, this is used to support actions in rosbag2. + +See https://github.com/ros2/rclcpp/pull/2759 for more details. + +``rclpy`` +^^^^^^^^^ + +Static Type Checking +"""""""""""""""""""" + +Added static type hints to ``ActionClient`` and ``ActionServer``. + +See https://github.com/ros2/rclpy/pull/1349 for more details. + +Add support for `generics `_ in ``pub/sub/client/server/actions``, ``Future/Task``, and ``Parameter``. + +``Publisher``, ``Subscription``, ``Server``, ``Task``, and ``Parameter`` should need no updates to add support for generics. + +``Client`` will need to be updated to resemble the following to get the improved type checking. + +.. code-block:: python + + self._get_parameter_client: Client[GetParameters.Request, + GetParameters.Response] = self.node.create_client( + GetParameters, '/get_parameters', + qos_profile=qos_profile, callback_group=callback_group) + +``ActionClient`` will need to be updated to resemble the following to get the improved type checking. + +.. code-block:: python + + ac: ActionClient[Fibonacci.Goal, + Fibonacci.Result, + Fibonacci.Feedback] = ActionClient(self.node, Fibonacci, 'fibonacci') + +``Future`` will need to be updated to resemble the following to get the improved type checking. + +.. code-block:: python + + log_msgs_future: Future[bool] = Future() + +See https://github.com/ros2/rclpy/pull/1239, https://github.com/ros2/rclpy/pull/1275, https://github.com/ros2/rclpy/pull/1246, and https://github.com/ros2/rclpy/pull/1254/files for more details. + +Various other small improvements and corrections have also been made throughout all of ``rclpy``. + +Python types can be statically checked using `ament_mypy `_ which wraps `mypy `_. + +EventsExecutor +"""""""""""""" + +Support an experimental events executor for ``rclpy``, which is a port of the original ``rclcpp`` events executor concept. + +See https://github.com/ros2/rclpy/pull/1391 for more details. + +``Rosbag2`` +^^^^^^^^^^^ + +Action introspection Rosbag2 support +"""""""""""""""""""""""""""""""""""" + +Allow to record and play actions from a rosbag. + +See https://github.com/ros2/rosbag2/pull/1955 for more information. +Design document https://github.com/ros2/rosbag2/pull/1928. +Visit :ref:`Managing Action Data ` to learn more about this feature. + +Progress bar for ``ros2 bag play`` +"""""""""""""""""""""""""""""""""" + +Added a progress bar for ``ros2 bag play`` CLI, showing the bag time and duration, similar to +what is seen in ROS 1. + +See https://github.com/ros2/rosbag2/pull/1836 for more details. + +Added support for replaying multiple bags with ``ros2 bag play`` CLI +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +To replay multiple bags, use the new ``-i, --input`` CLI option: + +.. code-block:: console + + $ ros2 bag play -i bag1 -i bag2 -i bag3 [storage_id] + +See https://github.com/ros2/rosbag2/pull/1848 for more information. + +Added support for replaying messages chronologically based on their publication timestamp +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This is exposed through ``ros2 bag play`` with a new ``--message-order {received,sent}`` option. +The default behavior is to play messages in the order they were received. + +See https://github.com/ros2/rosbag2/pull/1876 for more information. + +Make snapshot writing into a new file each time it is triggered +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1842 for more details. + +New ``--sort`` CLI option in the ``ros2 bag info`` command +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +With new ``--sort`` CLI option user will be able to sort topics, services and actions by name, topic type or number of recorded messages. + +See https://github.com/ros2/rosbag2/pull/1804 for more details. + +Show size contribution of each topic with ``ros2 bag info`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +With new ``--size-contribution`` option together with ``ros2 bag info -v`` user will be able to see the size contribution of each topic in the bag file. + +See https://github.com/ros2/rosbag2/pull/1726 for more information. + +Added ``--log-level`` option to ``ros2 bag play`` and ``ros2 bag record`` to allow printing debug messages +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1625 for more details. + +``rosidl_rust`` +^^^^^^^^^^^^^^^ + +Added ``rosidl_rust`` +""""""""""""""""""""" + +A Rust idl generator was added to the list of default code generators. + +See https://github.com/ros2/ros2/pull/1674 for more details. + +``ros2`` +^^^^^^^^ + +Switch to using Pixi/Conda for Windows +"""""""""""""""""""""""""""""""""""""" + +This allows to easily manage dependencies, and to update them in the future. +The installation process is significantly simplified. +Instead of dozens of steps to install dependencies, it is just a couple of commands. +It is much easier to update dependencies. +The dependencies are installed in individual workspaces, with no “global” installation. + +See https://github.com/ros2/ci/pull/802 and https://github.com/ros2/ros2/pull/1642 for more details. +Visit :doc:`Windows source install instructions <../Installation/Alternatives/Windows-Development-Setup>` to install it on Windows. + +Support topic instances in DDS topics +""""""""""""""""""""""""""""""""""""" + +Topic instances are a way of multiplexing the transmission of updates of several objects of the same logical kind over the same resource, i.e. the topic. + +See https://github.com/ros2/ros2/issues/1538 for more information. +You can also check the documentation: https://github.com/ros2/design/pull/340/files. + +Changes since the Jazzy release +------------------------------- + +``common_interfaces`` +^^^^^^^^^^^^^^^^^^^^^ + +Added NV12 to pixel formats +""""""""""""""""""""""""""" + +Added NV12 to pixel formats, which is a common output format of hardware-accelerated decoders. + +See https://github.com/ros2/common_interfaces/pull/253 for more details. + +``rclcpp`` +^^^^^^^^^^ + +Consistent behavior for Subordinate nodes +""""""""""""""""""""""""""""""""""""""""" + +Inconsistent behavior of subordinate nodes was fixed. +The subordinate node is a secondary node associated with a primary node, that shares the same underlying context and resources while maintaining a separate name and namespace. +The behavioral modification may affect existing applications relying on the previous implementation: + +1. Generic clients created from a subordinate node now correctly respect the subordinate node's sub-namespace +2. Parameters obtained using a subordinate node now correctly use the (parent) node's ``rclcpp::node_interfaces::NodeParametersInterface`` + +See https://github.com/ros2/rclcpp/pull/2822 for more details. + +``rmw_connextdds_cpp`` +^^^^^^^^^^^^^^^^^^^^^^ + +Version bumped to 7.3 +""""""""""""""""""""" + +The RTI Connext DDS version was bumped to 7.3.0. + +See https://github.com/ros2/ci/pull/811 for more details. + +``Connextmicro`` +^^^^^^^^^^^^^^^^ + +deprecated Connextmicro +""""""""""""""""""""""" + +The RTI Connext Micro RMW package, ``rmw_connextddsmicro``, is going to stop receiving updates in Kilted Kaiju, and be removed in a future ROS 2 release. + +See https://github.com/ros2/rmw_connextdds/pull/182 for more information. + +``rosidl_dynamic_typesupport`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Removing support for float128 +""""""""""""""""""""""""""""" + +Removed support for float128 because there are inconsistencies in the definition. + +See https://github.com/ros2/rosidl_dynamic_typesupport/issues/11 for more details. + +``rmw_fastrtps_cpp`` +^^^^^^^^^^^^^^^^^^^^ + +Renaming package from fastrtps to fastdds +""""""""""""""""""""""""""""""""""""""""" + +``fastrtps`` was renamed to ``fastdds``. +The names of the rmw implementations stay the same. +XML Profile ENV strings will change. + +See https://github.com/ros2/ros2/pull/1641 for more details. + +ament_target_dependencies is deprecated +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The CMake macro ``ament_target_dependencies()`` has been deprecated in favor of ``target_link_libraries()`` with modern CMake targets. +The macro still works, but it emits a CMake deprecation warning at build time like this: + +.. code-block:: + + CMake Deprecation Warning at [...]/ament_cmake_target_dependencies/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:89 (message): + ament_target_dependencies() is deprecated. Use target_link_libraries() + with modern CMake targets instead. Try replacing this call with: + + target_link_libraries([...] PUBLIC + [...] + ) + +Try replacing the ``ament_target_dependencies()`` call with the ``target_link_libraries()`` call suggested by the warning. +For more information see `ament/ament_cmake#572 `__ and `ament/ament_cmake#292 `__. + +Note that the deprecation warning suggests a call to ``target_link_libraries`` with a scope keyword like ``PUBLIC``, ``PRIVATE``, or ``INTERFACE``. +If you have already used ``target_link_libraries()`` on this target without a scope keyword, then you must remove the scope keyword from the suggested call. +This can happen when using some ``ament_cmake`` macros, like ``ament_add_gtest``, which use the plain version of ``target_link_libraries`` internally. +You will know if you need to remove the keyword because CMake will emit an error saying: + +.. code-block:: + + All uses of target_link_libraries with a target must be either all-keyword or all-plain. + +For more information, see `ament/ament_cmake#580 `__. + + +``launch`` +^^^^^^^^^^ + +``PathJoinSubstitution`` +"""""""""""""""""""""""" + +``PathJoinSubstitution`` now supports concatenating strings or substitutions into a single path component. +For example: + +.. code-block:: python + + PathJoinSubstitution(['robot_description', 'urdf', [LaunchConfiguration('model'), '.xacro']]) + +If the ``model`` launch configuration was set to ``my_model``, this would result in a path equal to: + +.. code-block:: python + + 'robot_description/urdf/my_model.xacro' + +For more information, see `ros2/launch#835 `__ and `ros2/launch#838 `__. + +``rmw_zenoh_cpp`` +^^^^^^^^^^^^^^^^^ + +``Tier 1`` +"""""""""" + +The ``rmw_zenoh_cpp`` is now considered Tier 1. +There are many PRs (summarized in `ros2/rmw_zenoh#265 `__) in the ROS 2 core packages, such as: + + * Make the rmw pass all core tests. + * Implement and document security + * Make it work in the Tier 1 platforms. + * Added Quality declarations + * Added to REP 2005 + * A dedicated nightly CI job + * Among others + +For more information see https://github.com/ros2/rmw_zenoh/issues/265. + +Development progress +-------------------- + +For progress on the development of Kiltled Kaiju, see `this project board `__. + +For the broad process followed by Kilted Kaiju, see the :doc:`process description page `. + +Release Timeline +---------------- + + December, 2024 - Platform decisions + REP 2000 is updated with the target platforms and major dependency versions. + + Mon. April 7, 2025 - Alpha + RMW freeze + Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. + + Mon. April 14, 2025 - Freeze + API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 21, 2025 - Branch + Branch from Rolling Ridley. + ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. + Kilted development shifts from ``ros-rolling-*`` packages to ``ros-kilted-*`` packages. + + Mon. April 28, 2025 - Beta + Updated releases of ROS Desktop [2]_ packages available. + Call for general testing. + + Thu, May 1, 2025 - Kick off of Tutorial Party + Tutorials hosted at https://github.com/ros2/kilted_tutorial_party are open for community testing. + + Mon. May 12, 2025 - Release Candidate + Release Candidate packages are built. + Updated releases of ROS Desktop [2]_ packages available. + + Mon. May 19, 2025 - Distro Freeze + Freeze all Kilted branches on all `ROS 2 desktop packages `__ and ``rosdistro``. + No pull requests for any ``kilted`` branch or targeting ``kilted/distribution.yaml`` in ``rosdistro`` repo will be merged. + + Fri. May 23, 2025 - General Availability + Release announcement. + `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Kilted pull requests. + +.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Lyrical-Luth.rst b/source/Get-Started/Releases/Release-Lyrical-Luth.rst index 1d89ba6a3b6..d423556f2a4 100644 --- a/source/Get-Started/Releases/Release-Lyrical-Luth.rst +++ b/source/Get-Started/Releases/Release-Lyrical-Luth.rst @@ -1,788 +1,792 @@ -.. _upcoming-release: - -.. _lyrical-release: - -Lyrical Luth (codename 'lyrical'; May, 2026) -============================================ - -.. toctree:: - :hidden: - - Lyrical-Luth-Complete-Changelog - lyrical/release-timeline.rst - lyrical/supported-platforms.rst - -*Lyrical Luth* is the twelfth release of ROS 2. -It is a Long Term Support (LTS) release, and it is supported until May 2031. - -* `Install Lyrical Luth <../../lyrical/Installation.html>`_ -* :doc:`lyrical/release-timeline` -* :doc:`lyrical/supported-platforms` - -New Features in Lyrical ------------------------ - -This section highlights some of the new features in ROS Lyrical. -For all changes, see the :doc:`full ROS Lyrical changelog `. - -.. contents:: Table of Contents - :depth: 1 - :local: - -Callback Group Events executor (``rclcpp``) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Looking for better executor performance? -Check out the new Callback Group Events Executor. -Like its predecessor the ``EventsExecutor``, the ``EventsCBGExecutor`` uses an events queue to process ready entities. -However, ``EventsCBGExecutor`` adds support for multiple sources of ROS time and multiple threads. -Compared to the Single and Multithreaded executors, the ``EventsCBGExecutor`` uses 10% to 15% less CPU. - -Try it out by instantiating ``rclcpp::executors::EventsCBGExecutor``: - -.. code-block:: c++ - - #include - - // ... class MyNode ... - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - auto node = std::make_shared(); - rclcpp::executors::EventsCBGExecutor executor; - executor.add_node(node); - executor.spin(); - rclcpp::shutdown(); - return 0; - } - -Using composable nodes? -Launch a component container with the ``EventsCBGExecutor`` using the new ``--executor-type`` argument. - -.. code-block:: console - - ros2 run rclcpp_components component_container --executor-type events-cbg - -.. code-block:: xml - - - - - - - - -For more info, see `ros2/rclcpp#3097 `_, `ros2/rclcpp#3134 `_, and `ros2/rclcpp#3137 `_. - -Parameter range descriptors check bounds for integer and double arrays (``rclcpp``) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Do your nodes have integer or double arrays? -Do you need to constrain the values in those arrays? -``rclcpp`` nodes now validate range constraints on these arrays. -Using the code below, the node will only allow setting ``my_integer_array`` to a list containing even integers between 2 and 10 (inclusive). - -.. code-block:: c++ - - rcl_interfaces::msg::ParameterDescriptor descriptor; - descriptor.integer_range.resize(1); - auto & integer_range = descriptor.integer_range.at(0); - integer_range.from_value = 2; - integer_range.to_value = 10; - integer_range.step = 2; - node->declare_parameter("my_integer_array", std::vector{2, 4, 6, 8, 10}, descriptor); - -See `ros2/rclcpp#2828 `_ for more info. - -``AsyncNode`` lets you use ``asyncio`` (``rclpy``) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Want to use ``asyncio`` and ``rclpy`` at the same time? -Check out the new ``AsyncNode`` class. -This node runs an ``asyncio`` event loop. -Call ``await`` on any ``asyncio`` operation from any subscription, service, and timer callback. -Try ``await client.call(request)`` to wait for service calls, and the sim-time aware ``await clock.sleep(...)``. -This class uses significantly less CPU compared to the default ``SingleThreadedExecutor``. - -.. code-block:: python - - import asyncio - import rclpy - from rclpy.experimental import AsyncNode - - class HelloWorldNode(AsyncNode): - def __init__(self): - super().__init__('hello_world_node') - self._timer = self.create_timer(5.0, self._cb) - - async def _cb(self): - self.get_logger().info('Hello') - await self.get_clock().sleep(1.0) - self.get_logger().info('World!') - - async def _main(): - with rclpy.init(): - await HelloWorldNode().run() - - if __name__ == '__main__': - asyncio.run(_main()) - -See :doc:`../Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python` and `ros2/rclpy#1620 `_ for more details. - -Publish messages without copying data using ``rosidl::Buffer`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Are you publishing data on ROS topics, but using the data elsewhere, like a GPU? -Tired of copying data out of the GPU before publishing just to copy it back into the GPU in the subscriber? -Use ``rosidl::Buffer`` to publish and subscribe ROS messages without moving data from elsewhere. - -All ``uint8[]`` fields now have the type ``rosidl::Buffer`` in C++ instead of ``std::vector``. -Define your ROS messages with ``uint8[]`` fields and install an appropriate ``rosidl::BufferBackend`` implementation. -Note that only publishers and subscribers using ``rmw_fastrtps_cpp`` may use this feature for now, but `support in Zenoh is coming `_. - -Using a custom hardware accelerator or machine learning library? -You can benefit from this too. -See :doc:`../Tutorials/Advanced/Writing-a-Buffer-Backend` to learn how to implement your own ``rosidl::BufferBackend``. - -See :doc:`../Concepts/Intermediate/About-Buffer-Backends` and :doc:`../How-To-Guides/Using-Buffer-Backends` for more details. - -Annotate types in YAML Parameter Files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Tired of ``rcl`` interpreting ambiguous YAML parameter values as the wrong type? -In ROS Lyrical, use YAML tags to specify the correct type. - -.. code-block:: yaml - - my_node: - ros__parameters: - string_param: !!str true - bool_param: !!bool yes - int_param: !!int 0 - float_param: !!float 10 - seq_param: !!seq [10, 0, -10] - map_param: !!map {str: string, bool: true, int: 10, float: 1.1} - -See `ros2/rcl#1275 `_ for more info. - -Per-message log severity in launch files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS Lyrical now supports per-message log severity levels in launch files. -This makes it easier to find important messages or ignore unimportant ones in log files when debugging! - -Specify the log level using the new ``level`` argument on the ``log`` action. -Alternatively, use the new ``log_debug``, ``log_info``, ``log_warning``, or ``log_error`` actions. - -.. code-block:: xml - - - - - - - - - - - -For more info see `ros2/launch#866 `_. - -New substitutions in XML and YAML launch files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Use XML or YAML launch files? -:doc:`Substitutions <../Tutorials/Intermediate/Launch/Using-Substitutions>` make your launch files evaluate variables at launch time. -Launch frontends (the things that make it possible to use XML and YAML launch files) may now use ``string-join`` and ``path-join`` substitutions. - -.. code-block:: xml - - - - - - - - -See `ros2/launch#857 `_ and `ros2/launch#943 `_ for more info. - -Choose ROS logging backend at runtime -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Have you ever needed to use ROS with another framework that has its own logging system? -ROS supports replacing its logging backend, but it previously required rebuilding ``rcl`` from source. -Now you can change the logging implementation at runtime! -Set the ``RCL_LOGGING_IMPLEMENTATION`` environment variable to switch between logging backends. -Valid values are: - -* ``rcl_logging_spdlog`` -* ``rcl_logging_noop`` -* or your own custom logging implementation! - -If not specified, ROS uses ``rcl_logging_spdlog`` by default. - -See `ros2/rcl#1178 `_, `ros2/rcl#1276 `_, and `ros2/rcl_logging#135 `_ for more details. - -Control bag recording remotely using ROS services -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Want to remotely control bag recording? -Use ``rosbag2``'s new services to: - -* start recording ``~/record`` -* stop recording ``~/stop`` -* start topic discovery ``~/start_discovery`` -* stop topic discovery ``~/stop_discovery`` -* query discovery state ``~/is_discovery_running`` - -.. code-block:: bash - - ros2 bag record --all -o /tmp/my_awesome_bag - - # In another terminal, stop the existing recording - ros2 service call /rosbag2_recorder/stop rosbag2_interfaces/srv/Stop "{}" - # Start recording again at a new location - ros2 service call /rosbag2_recorder/record rosbag2_interfaces/srv/Record "{uri: 'file:///tmp/my_awesome_bag_2'}" - - -See `ros2/rosbag2#2248 `_ for more details. - -Control bag Playback and Recording using Python -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Want to control bag playback and recording programmatically? -Previously, Python users relied on blocking command-line style helpers. -Now Python users may call APIs to pause, resume, stop, seek, play next, control spinning, and wait for events. - -Recording example: - -.. code-block:: python - - import rclpy - import rosbag2_py - - with rclpy.init(): - # Configure storage and initialize the recorder - storage_opts = rosbag2_py.StorageOptions(uri='/tmp/my_awesome_bag', storage_id='mcap') - record_opts = rosbag2_py.RecordOptions() - record_opts.all_topics = True - - recorder = rosbag2_py.Recorder(storage_opts, record_opts) - - # Start the ROS node spinner and kick off the recording thread - recorder.start_spin() - recorder.record() - - # Pause the recording and verify the current state - recorder.pause() - print(recorder.is_paused()) - - # Terminate recording and shut down the spinner threads - recorder.stop() - recorder.stop_spin() - -Playback example: - -.. code-block:: python - - import rclpy - import rosbag2_py - - with rclpy.init(): - # Configure storage and initialize the player - storage_opts = rosbag2_py.StorageOptions(uri='/tmp/my_awesome_bag', storage_id='mcap') - play_opts = rosbag2_py.PlayOptions() - play_opts.start_paused = True - - player = rosbag2_py.Player(storage_opts, play_opts) - - # Start the ROS node spinner and kick off the playback thread - player.start_spin() - player.play() - - # Verify playback startup and retrieve bag timing metadata - print(player.wait_for_playback_to_start(1.0)) - print(player.wait_for_playback_to_start_exclusively(1.0)) - print(player.get_starting_time()) - print(player.get_playback_duration()) - - # Control the playback state and step through messages manually - print(player.is_paused()) - print(player.play_next()) - player.resume() - player.pause() - player.seek(0) - - # Await playback completion and terminate the worker threads - print(player.wait_for_playback_to_finish(1.0)) - print(player.wait_for_playback_to_finish_exclusively(1.0)) - player.stop() - player.stop_spin() - -See `ros2/rosbag2#2047 `_, `ros2/rosbag2#2062 `_, `ros2/rosbag2#2061 `_, and `ros2/rosbag2#2095 `_ for more details. - -Circular bag recording with limit on number of bags -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Recording data on your robot with limited disk space? -Try the new ``--max-bag-files`` option. -It limits the maximum number of bag files stored on disk by automatically deleting the oldest split files as new ones are created. - -.. code-block:: bash - - # Max bag size: 100MB - ros2 bag record --all --max-bag-size 100000000 --max-bag-files 5 - -See `ros2/rosbag2#2218 `_ for more details. - -More descriptive bag split names -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Do you have trouble identifying which bag is which? -``rosbag2`` now names bag splits so that each is self-descriptive and chronologically traceable. - -.. code-block:: text - - {counter}_{prefix}_{timestamp}.{extension} - -* **counter**: split index (integer starting from 0, *not zero-padded*) -* **prefix**: derived from the bag directory name, with any default timestamp suffix removed -* **timestamp**: local time at file creation, formatted as ``YYYY_MM_DD-HH_MM_SS`` -* **extension**: bag file extension. e.g., ``.mcap``, ``.db3`` - -See `ros2/rosbag2#2265 `_ for more details. - -Catch data loss early with ``rosbag2`` message-loss observability -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Say you've built a robust system for recording data on your robot, but there is a problem. -How do you *know* there's a problem? -With ``rosbag2``'s new message-loss observability of course! - -``rosbag2`` now collects message-loss statistics from the transport layer and recorder internals. -It publishes incremental per-topic loss events on the ``events/rosbag2_messages_lost`` topic. -Control the publishing rate using ``--stats_max_publishing_rate``. - -.. code-block:: bash - - # Publish message loss statistics at most 10 Hz - ros2 bag record --all --stats_max_publishing_rate 10 -o /tmp/my_awesome_bag - # If all is going well, you should see no output from this command - ros2 topic echo /events/rosbag2_messages_lost - -See `ros2/rosbag2#2039 `_, `ros2/rosbag2#2144 `_, and `ros2/rosbag2#2150 `_ for more details. - - -``fish`` shell support -^^^^^^^^^^^^^^^^^^^^^^ - -Do you enjoy `fish shell `_? -Do you want to use it with ROS? -Now you can! -Try out the new ``setup.fish`` script. - -.. code-block:: shell - - source /opt/ros/lyrical/setup.fish - -See `ros2/ros2cli#1211 `_ and `ament/ament_package#164 `_ for more info. -To use ``fish`` shell with ``colcon``, check out `@Sunrisepeak's `_ `colcon-fish package `_. - -``ros2 param get`` a parameter from all nodes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Are you using simulated time? -How do you know if all of your nodes are using simulated time? -Use ``ros2 param get `` to get a parameter value from all nodes. - -.. image:: images/ros2_param_get_use_sim_time.gif - -See `ros2/ros2cli#1174 `_ for more info. - -``ros2 param`` get and set multiple parameters on one node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Want to get and set multiple parameters on one node at the same time? -Use ``ros2 param get ...`` to get multiple values from a single node. - -.. code-block:: console - - $ ros2 param get /robot_state_publisher frame_prefix ignore_timestamp publish_frequency - frame_prefix: - String value is: - ignore_timestamp: - Boolean value is: False - publish_frequency: - Double value is: 20.0 - -Use ``ros2 param set ...`` to set multiple values on a single node. - -.. code-block:: console - - $ ros2 param set /robot_state_publisher frame_prefix foo ignore_timestamp True publish_frequency 10.0 - frame_prefix: Set parameter successful - ignore_timestamp: Set parameter successful - publish_frequency: Set parameter successful - - -See `ros2/ros2cli#1203 `_ and `ros2/ros2cli#1204 `_ for more details. - -``ros2 doctor --report`` now reports Actions, Services, and Environment variables -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``ros2 doctor --report`` now includes information about Actions, Services, and ROS-related environment variables. -Include this report in your GitHub issues or AI prompts to debug problems faster. - -.. code-block:: console - - $ ros2 doctor --report - - ACTION LIST - action : none - action server count : 0 - action client count : 0 - - ROS ENVIRONMENT - ROS environment variables : ROS_AUTOMATIC_DISCOVERY_RANGE=SUBNET, ROS_DISTRO=lyrical - rcutils environment variables : - rmw environment variables : - # ... - - SERVICE LIST - service : /dummy_joint_states/describe_parameters - service count : 1 - client count : 0 - service : /dummy_joint_states/get_parameter_types - service count : 1 - client count : 0 - # ... - - -For more information see `ros2/ros2cli#1059 `_, `ros2/ros2cli#1076 `_, and `ros2/ros2cli#1045 `_. - -Verbose service information ``ros2 service info --verbose`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Are you debugging mismatched QoS settings between ROS clients and ROS services? -Try out the new ``--verbose`` option to ``ros2 service info``. -Like ``ros2 topic info``, this flag outputs detailed information about clients and services to help you troubleshoot issues. - -.. code-block:: console - - $ ros2 service info --verbose /robot_state_publisher/list_parameters - Type: rcl_interfaces/srv/ListParameters - Clients count: 0 - Services count: 1 - Node name: robot_state_publisher - Node namespace: / - Service type: rcl_interfaces/srv/ListParameters - Service type hash: RIHS01_3e6062bfbb27bfb8730d4cef2558221f51a11646d78e7bb30a1e83afac3aad9d - Endpoint type: SERVER - Endpoint count: 2 - GIDs: - - Request Reader : 01.0f.c8.b6.fe.43.b3.44.00.00.00.00.00.00.0e.04 - - Response Writer : 01.0f.c8.b6.fe.43.b3.44.00.00.00.00.00.00.0f.03 - QoS profiles: - - Request Reader : - Reliability: RELIABLE - History (Depth): KEEP_LAST (1000) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Response Writer : - Reliability: RELIABLE - History (Depth): KEEP_LAST (1000) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -Want to get client and service information programmatically? -Use these new C++ and Python APIs. - -.. code-block:: python - - node.get_servers_info_by_service('some/service/name') - node.get_clients_info_by_service('some/service/name') - -.. code-block:: c++ - - node->get_servers_info_by_service("some/service/name"); - node->get_clients_info_by_service("some/service/name"); - -See `ros2/ros2cli#916 `_, `ros2/rclpy#1307 `_, and `ros2/rclcpp#2569 `_ for more info. - -``ros2 topic bw`` multiple topics at once -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Trying to figure out which topics are using most of your network bandwidth? -Now you can use ``ros2 topic bw`` with multiple topics at the same time. -Pass multiple topics by name: - -.. code-block:: bash - - ros2 topic bw /tf /joint_states - -Or pass ``--all`` to watch bandwidth statistics in real time. - -.. image:: images/ros2_topic_bw_all.gif - -See `ros2/ros2cli#1124 `_ and `ros2/ros2cli#1130 `_ for more info. - -URDF improvements -^^^^^^^^^^^^^^^^^ - -URDF released a few new features: - -* Quaternions -* Capsule geometry -* Acceleration, deceleration, and jerk limits - -Add ``version="1.2"`` to your robot description to start using them. - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -See `ros/urdfdom#235 `_, `ros/urdfdom#238 `_, and `ros/urdfdom#212 `_ for more info. - -Note that the Robot Model plugin `does not yet support capsule geometry `_. -Please consider opening a pull request for this feature! - -``robot_state_publisher`` can read the robot description from a topic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Most of the time in a ROS system the ``robot_state_publisher`` node does two things: - -* It publishes the ``robot_description`` on a topic, and -* It publishes TF transforms given joint positions. - -If you have ever tried to add ROS interfaces to a framework with its own internal robot model, you may have wished these were two separate utilities. -Now they can be! -Set the ``use_robot_description_topic`` parameter to ``true`` to make ``robot_state_publisher`` subscribe to the ``robot_description`` topic instead of publishing it. -Then, make the other robot framework publish its own robot description on that topic. - -See `ros/robot_state_publisher#234 `_ for more info. - -Resource retriever service -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Say you are debugging a robot in the field. -You open up RViz on your laptop, but you don't have the right version of the robot description installed. -In ROS Kilted, RViz added the ability to load meshes over the network using a ROS service ``/rviz/get_resource``; however, that ability was limited to RViz. -ROS Lyrical comes with a generic ``resource_retriever_service`` so that any node can load meshes over the network. - -.. code-block:: c++ - - resource_retriever::RetrieverVec plugins = resource_retriever::default_plugins(); - // Create a RosServiceResourceRetriever plugin - plugins.push_back(std::make_shared(*node)); - // Give that plugin to your Retriever instance - resource_retriever::Retriever retriever(plugins); - -See `ros2/rviz#1698 `_ for more details. - -Call ``ament_python_install_package`` multiple times -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Packages may now call ``ament_python_install_package()`` multiple times with the same Python package name. -This allows you to use ``rosidl_generate_interfaces()`` and ``ament_python_install_package()`` to put generated messages and code into the same Python package. - -While you can include code and message definitions in the same package, a best practice is to put message definitions in their own package. -This lets others depend on just the messages, as they might not need the code or its dependencies. - -See `ament/ament_cmake#587 `_ for more info. - -New CMake target: ``ament_cmake_ros_core::ament_ros_defaults`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Tired of specifying different C and C++ versions on different branches? -Let the new CMake target ``ament_cmake_ros_core::ament_ros_defaults`` set those for you. -This target uses `target_compile_features `_ to specify C and C++ version requirements. - -.. code-block:: cmake - - find_package(ament_cmake_ros REQUIRED) - target_link_libraries(my_library PUBLIC ament_cmake_ros_core::ament_ros_defaults) - -See `ros2/ament_cmake_ros#62 `_ for more info. - -New thread naming utilities -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Debugging multithreading issues? -Use two new utilities in ``rcpputils`` to get and set thread names. -This makes it easier to identify threads in debuggers like ``gdb``. - -.. code-block:: c++ - - #include - #include - - int main() { - rcpputils::set_thread_name("map_thread"); - std::cout << rcpputils::get_thread_name() << "\n"; - } - - -See `ros2/rcpputils#213 `_ for more details. - -New ``rcutils`` APIs -^^^^^^^^^^^^^^^^^^^^ - -The ``rcutils`` package includes some new utilities. -If your platform lacks ``strnlen``, you may now use ``rcutils_strnlen`` instead. - -.. code-block:: c - - #include - - #include - - int main() { - const char *str = "Hello world"; - size_t len = rcutils_strnlen(str, 100); - printf("%zu\n", len); - return 0; - } - -Need to encode or decode base64 data? -Try the new ``rcutils_encode_base64`` and ``rcutils_decode_base64`` functions. - -.. code-block:: c - - #include - #include - #include - - #include - #include - #include - - int main() { - rcutils_allocator_t allocator = rcutils_get_default_allocator(); - - rcutils_uint8_array_t input = rcutils_get_zero_initialized_uint8_array(); - assert(rcutils_uint8_array_init(&input, 11, &allocator) == RCUTILS_RET_OK); - memcpy(input.buffer, "Hello World", 11); - input.buffer_length = 11; - - char *encoded = NULL; - assert(rcutils_encode_base64(&input, &encoded, &allocator) == RCUTILS_RET_OK); - printf("%s\n", encoded); - - rcutils_uint8_array_t decoded = rcutils_get_zero_initialized_uint8_array(); - assert(rcutils_decode_base64(encoded, &decoded, &allocator) == RCUTILS_RET_OK); - printf("%.*s\n", (int)decoded.buffer_length, (char *)decoded.buffer); - - allocator.deallocate(encoded, allocator.state); - assert(rcutils_uint8_array_fini(&input) == RCUTILS_RET_OK); - assert(rcutils_uint8_array_fini(&decoded) == RCUTILS_RET_OK); - return 0; - } - -See `ros2/rcutils#430 `_ and `ros2/rcutils#533 `_ for more info. - -New ``rcl`` APIs -^^^^^^^^^^^^^^^^ - -If you maintain a ROS client library, you might be interested in these new ``rcl`` APIs: - -``rcl_lifecycle_get_transition_label_by_id`` -"""""""""""""""""""""""""""""""""""""""""""" -Retrieve the human-readable string label for a lifecycle transition ID. -Use this label to log, debug, or display state transitions without manually mapping IDs to strings. - -``rcl_subscription_is_cft_supported`` -""""""""""""""""""""""""""""""""""""" -Check whether a subscription supports Content Filtered Topics (CFT) on the underlying middleware. -Verify filtering support safely before applying or configuring message content filters. - -``rcl_action_count_clients`` -"""""""""""""""""""""""""""" -Query the ROS graph to count active action clients for a specific action name. -Action servers can verify client presence before expending resources, or tools can inspect graph state. - -``rcl_action_count_servers`` -"""""""""""""""""""""""""""" -Query the ROS graph to count active action servers for a specific action name. -Action clients can confirm a server is online before sending goal requests. - -``rcl_timer_exchange_callback_data`` -"""""""""""""""""""""""""""""""""""" -Update the user data pointer passed to a timer callback upon execution. -Dynamically swap callback context or state without recreating the active timer instance. - -``rcl_action_server_set_expired_event_callback`` -"""""""""""""""""""""""""""""""""""""""""""""""" -Register a custom event callback that triggers when an action server goal expiration timer fires. -Enable event-based execution patterns to asynchronously handle clean-up routines or notifications for expired goals. - -For more information see these pull requests: - -* `ros2/rcl#1229 `_ -* `ros2/rcl#1257 `_ -* `ros2/rcl#1293 `_ -* `ros2/rcl#1294 `_ -* `ros2/rcl#1295 `_ - -Pass constructor arguments to plugins using ``class_loader`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You may now pass arguments to plugins using ``class_loader``. -This removes the need for an initialization method in a plugin's API. -All you need to do is specialize ``class_loader::InterfaceTraits<>`` in your plugin's base class. - -.. code-block:: c++ - - class MyPluginWithConstructor - { - public: - // constructor parameters for the base class do not need to match the derived classes - explicit MyPluginWithConstructor(std::string) {} - virtual ~MyPluginWithConstructor() = default; - - virtual int some_api() = 0; - }; - - template<> - struct class_loader::InterfaceTraits - { - // Define constructor arguments that you must pass to instantiate a plugin - using constructor_parameters = class_loader::ConstructorParameters>; - }; - - -For more information see `ros/class_loader#223 `_. +.. redirect-from:: + + Releases/Release-Lyrical-Luth + +.. _upcoming-release: + +.. _lyrical-release: + +Lyrical Luth (codename 'lyrical'; May, 2026) +============================================ + +.. toctree:: + :hidden: + + Lyrical-Luth-Complete-Changelog + lyrical/release-timeline.rst + lyrical/supported-platforms.rst + +*Lyrical Luth* is the twelfth release of ROS 2. +It is a Long Term Support (LTS) release, and it is supported until May 2031. + +* `Install Lyrical Luth <../../lyrical/Installation.html>`_ +* :doc:`lyrical/release-timeline` +* :doc:`lyrical/supported-platforms` + +New Features in Lyrical +----------------------- + +This section highlights some of the new features in ROS Lyrical. +For all changes, see the :doc:`full ROS Lyrical changelog `. + +.. contents:: Table of Contents + :depth: 1 + :local: + +Callback Group Events executor (``rclcpp``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Looking for better executor performance? +Check out the new Callback Group Events Executor. +Like its predecessor the ``EventsExecutor``, the ``EventsCBGExecutor`` uses an events queue to process ready entities. +However, ``EventsCBGExecutor`` adds support for multiple sources of ROS time and multiple threads. +Compared to the Single and Multithreaded executors, the ``EventsCBGExecutor`` uses 10% to 15% less CPU. + +Try it out by instantiating ``rclcpp::executors::EventsCBGExecutor``: + +.. code-block:: c++ + + #include + + // ... class MyNode ... + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + auto node = std::make_shared(); + rclcpp::executors::EventsCBGExecutor executor; + executor.add_node(node); + executor.spin(); + rclcpp::shutdown(); + return 0; + } + +Using composable nodes? +Launch a component container with the ``EventsCBGExecutor`` using the new ``--executor-type`` argument. + +.. code-block:: console + + ros2 run rclcpp_components component_container --executor-type events-cbg + +.. code-block:: xml + + + + + + + + +For more info, see `ros2/rclcpp#3097 `_, `ros2/rclcpp#3134 `_, and `ros2/rclcpp#3137 `_. + +Parameter range descriptors check bounds for integer and double arrays (``rclcpp``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Do your nodes have integer or double arrays? +Do you need to constrain the values in those arrays? +``rclcpp`` nodes now validate range constraints on these arrays. +Using the code below, the node will only allow setting ``my_integer_array`` to a list containing even integers between 2 and 10 (inclusive). + +.. code-block:: c++ + + rcl_interfaces::msg::ParameterDescriptor descriptor; + descriptor.integer_range.resize(1); + auto & integer_range = descriptor.integer_range.at(0); + integer_range.from_value = 2; + integer_range.to_value = 10; + integer_range.step = 2; + node->declare_parameter("my_integer_array", std::vector{2, 4, 6, 8, 10}, descriptor); + +See `ros2/rclcpp#2828 `_ for more info. + +``AsyncNode`` lets you use ``asyncio`` (``rclpy``) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Want to use ``asyncio`` and ``rclpy`` at the same time? +Check out the new ``AsyncNode`` class. +This node runs an ``asyncio`` event loop. +Call ``await`` on any ``asyncio`` operation from any subscription, service, and timer callback. +Try ``await client.call(request)`` to wait for service calls, and the sim-time aware ``await clock.sleep(...)``. +This class uses significantly less CPU compared to the default ``SingleThreadedExecutor``. + +.. code-block:: python + + import asyncio + import rclpy + from rclpy.experimental import AsyncNode + + class HelloWorldNode(AsyncNode): + def __init__(self): + super().__init__('hello_world_node') + self._timer = self.create_timer(5.0, self._cb) + + async def _cb(self): + self.get_logger().info('Hello') + await self.get_clock().sleep(1.0) + self.get_logger().info('World!') + + async def _main(): + with rclpy.init(): + await HelloWorldNode().run() + + if __name__ == '__main__': + asyncio.run(_main()) + +See :doc:`../Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python` and `ros2/rclpy#1620 `_ for more details. + +Publish messages without copying data using ``rosidl::Buffer`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Are you publishing data on ROS topics, but using the data elsewhere, like a GPU? +Tired of copying data out of the GPU before publishing just to copy it back into the GPU in the subscriber? +Use ``rosidl::Buffer`` to publish and subscribe ROS messages without moving data from elsewhere. + +All ``uint8[]`` fields now have the type ``rosidl::Buffer`` in C++ instead of ``std::vector``. +Define your ROS messages with ``uint8[]`` fields and install an appropriate ``rosidl::BufferBackend`` implementation. +Note that only publishers and subscribers using ``rmw_fastrtps_cpp`` may use this feature for now, but `support in Zenoh is coming `_. + +Using a custom hardware accelerator or machine learning library? +You can benefit from this too. +See :doc:`../Tutorials/Advanced/Writing-a-Buffer-Backend` to learn how to implement your own ``rosidl::BufferBackend``. + +See :doc:`../Concepts/Intermediate/About-Buffer-Backends` and :doc:`../How-To-Guides/Using-Buffer-Backends` for more details. + +Annotate types in YAML Parameter Files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Tired of ``rcl`` interpreting ambiguous YAML parameter values as the wrong type? +In ROS Lyrical, use YAML tags to specify the correct type. + +.. code-block:: yaml + + my_node: + ros__parameters: + string_param: !!str true + bool_param: !!bool yes + int_param: !!int 0 + float_param: !!float 10 + seq_param: !!seq [10, 0, -10] + map_param: !!map {str: string, bool: true, int: 10, float: 1.1} + +See `ros2/rcl#1275 `_ for more info. + +Per-message log severity in launch files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS Lyrical now supports per-message log severity levels in launch files. +This makes it easier to find important messages or ignore unimportant ones in log files when debugging! + +Specify the log level using the new ``level`` argument on the ``log`` action. +Alternatively, use the new ``log_debug``, ``log_info``, ``log_warning``, or ``log_error`` actions. + +.. code-block:: xml + + + + + + + + + + + +For more info see `ros2/launch#866 `_. + +New substitutions in XML and YAML launch files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Use XML or YAML launch files? +:doc:`Substitutions <../../Developer-Tools/Launch/Using-Substitutions>` make your launch files evaluate variables at launch time. +Launch frontends (the things that make it possible to use XML and YAML launch files) may now use ``string-join`` and ``path-join`` substitutions. + +.. code-block:: xml + + + + + + + + +See `ros2/launch#857 `_ and `ros2/launch#943 `_ for more info. + +Choose ROS logging backend at runtime +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Have you ever needed to use ROS with another framework that has its own logging system? +ROS supports replacing its logging backend, but it previously required rebuilding ``rcl`` from source. +Now you can change the logging implementation at runtime! +Set the ``RCL_LOGGING_IMPLEMENTATION`` environment variable to switch between logging backends. +Valid values are: + +* ``rcl_logging_spdlog`` +* ``rcl_logging_noop`` +* or your own custom logging implementation! + +If not specified, ROS uses ``rcl_logging_spdlog`` by default. + +See `ros2/rcl#1178 `_, `ros2/rcl#1276 `_, and `ros2/rcl_logging#135 `_ for more details. + +Control bag recording remotely using ROS services +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Want to remotely control bag recording? +Use ``rosbag2``'s new services to: + +* start recording ``~/record`` +* stop recording ``~/stop`` +* start topic discovery ``~/start_discovery`` +* stop topic discovery ``~/stop_discovery`` +* query discovery state ``~/is_discovery_running`` + +.. code-block:: bash + + ros2 bag record --all -o /tmp/my_awesome_bag + + # In another terminal, stop the existing recording + ros2 service call /rosbag2_recorder/stop rosbag2_interfaces/srv/Stop "{}" + # Start recording again at a new location + ros2 service call /rosbag2_recorder/record rosbag2_interfaces/srv/Record "{uri: 'file:///tmp/my_awesome_bag_2'}" + + +See `ros2/rosbag2#2248 `_ for more details. + +Control bag Playback and Recording using Python +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Want to control bag playback and recording programmatically? +Previously, Python users relied on blocking command-line style helpers. +Now Python users may call APIs to pause, resume, stop, seek, play next, control spinning, and wait for events. + +Recording example: + +.. code-block:: python + + import rclpy + import rosbag2_py + + with rclpy.init(): + # Configure storage and initialize the recorder + storage_opts = rosbag2_py.StorageOptions(uri='/tmp/my_awesome_bag', storage_id='mcap') + record_opts = rosbag2_py.RecordOptions() + record_opts.all_topics = True + + recorder = rosbag2_py.Recorder(storage_opts, record_opts) + + # Start the ROS node spinner and kick off the recording thread + recorder.start_spin() + recorder.record() + + # Pause the recording and verify the current state + recorder.pause() + print(recorder.is_paused()) + + # Terminate recording and shut down the spinner threads + recorder.stop() + recorder.stop_spin() + +Playback example: + +.. code-block:: python + + import rclpy + import rosbag2_py + + with rclpy.init(): + # Configure storage and initialize the player + storage_opts = rosbag2_py.StorageOptions(uri='/tmp/my_awesome_bag', storage_id='mcap') + play_opts = rosbag2_py.PlayOptions() + play_opts.start_paused = True + + player = rosbag2_py.Player(storage_opts, play_opts) + + # Start the ROS node spinner and kick off the playback thread + player.start_spin() + player.play() + + # Verify playback startup and retrieve bag timing metadata + print(player.wait_for_playback_to_start(1.0)) + print(player.wait_for_playback_to_start_exclusively(1.0)) + print(player.get_starting_time()) + print(player.get_playback_duration()) + + # Control the playback state and step through messages manually + print(player.is_paused()) + print(player.play_next()) + player.resume() + player.pause() + player.seek(0) + + # Await playback completion and terminate the worker threads + print(player.wait_for_playback_to_finish(1.0)) + print(player.wait_for_playback_to_finish_exclusively(1.0)) + player.stop() + player.stop_spin() + +See `ros2/rosbag2#2047 `_, `ros2/rosbag2#2062 `_, `ros2/rosbag2#2061 `_, and `ros2/rosbag2#2095 `_ for more details. + +Circular bag recording with limit on number of bags +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Recording data on your robot with limited disk space? +Try the new ``--max-bag-files`` option. +It limits the maximum number of bag files stored on disk by automatically deleting the oldest split files as new ones are created. + +.. code-block:: bash + + # Max bag size: 100MB + ros2 bag record --all --max-bag-size 100000000 --max-bag-files 5 + +See `ros2/rosbag2#2218 `_ for more details. + +More descriptive bag split names +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Do you have trouble identifying which bag is which? +``rosbag2`` now names bag splits so that each is self-descriptive and chronologically traceable. + +.. code-block:: text + + {counter}_{prefix}_{timestamp}.{extension} + +* **counter**: split index (integer starting from 0, *not zero-padded*) +* **prefix**: derived from the bag directory name, with any default timestamp suffix removed +* **timestamp**: local time at file creation, formatted as ``YYYY_MM_DD-HH_MM_SS`` +* **extension**: bag file extension. e.g., ``.mcap``, ``.db3`` + +See `ros2/rosbag2#2265 `_ for more details. + +Catch data loss early with ``rosbag2`` message-loss observability +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Say you've built a robust system for recording data on your robot, but there is a problem. +How do you *know* there's a problem? +With ``rosbag2``'s new message-loss observability of course! + +``rosbag2`` now collects message-loss statistics from the transport layer and recorder internals. +It publishes incremental per-topic loss events on the ``events/rosbag2_messages_lost`` topic. +Control the publishing rate using ``--stats_max_publishing_rate``. + +.. code-block:: bash + + # Publish message loss statistics at most 10 Hz + ros2 bag record --all --stats_max_publishing_rate 10 -o /tmp/my_awesome_bag + # If all is going well, you should see no output from this command + ros2 topic echo /events/rosbag2_messages_lost + +See `ros2/rosbag2#2039 `_, `ros2/rosbag2#2144 `_, and `ros2/rosbag2#2150 `_ for more details. + + +``fish`` shell support +^^^^^^^^^^^^^^^^^^^^^^ + +Do you enjoy `fish shell `_? +Do you want to use it with ROS? +Now you can! +Try out the new ``setup.fish`` script. + +.. code-block:: shell + + source /opt/ros/lyrical/setup.fish + +See `ros2/ros2cli#1211 `_ and `ament/ament_package#164 `_ for more info. +To use ``fish`` shell with ``colcon``, check out `@Sunrisepeak's `_ `colcon-fish package `_. + +``ros2 param get`` a parameter from all nodes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Are you using simulated time? +How do you know if all of your nodes are using simulated time? +Use ``ros2 param get `` to get a parameter value from all nodes. + +.. image:: images/ros2_param_get_use_sim_time.gif + +See `ros2/ros2cli#1174 `_ for more info. + +``ros2 param`` get and set multiple parameters on one node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Want to get and set multiple parameters on one node at the same time? +Use ``ros2 param get ...`` to get multiple values from a single node. + +.. code-block:: console + + $ ros2 param get /robot_state_publisher frame_prefix ignore_timestamp publish_frequency + frame_prefix: + String value is: + ignore_timestamp: + Boolean value is: False + publish_frequency: + Double value is: 20.0 + +Use ``ros2 param set ...`` to set multiple values on a single node. + +.. code-block:: console + + $ ros2 param set /robot_state_publisher frame_prefix foo ignore_timestamp True publish_frequency 10.0 + frame_prefix: Set parameter successful + ignore_timestamp: Set parameter successful + publish_frequency: Set parameter successful + + +See `ros2/ros2cli#1203 `_ and `ros2/ros2cli#1204 `_ for more details. + +``ros2 doctor --report`` now reports Actions, Services, and Environment variables +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``ros2 doctor --report`` now includes information about Actions, Services, and ROS-related environment variables. +Include this report in your GitHub issues or AI prompts to debug problems faster. + +.. code-block:: console + + $ ros2 doctor --report + + ACTION LIST + action : none + action server count : 0 + action client count : 0 + + ROS ENVIRONMENT + ROS environment variables : ROS_AUTOMATIC_DISCOVERY_RANGE=SUBNET, ROS_DISTRO=lyrical + rcutils environment variables : + rmw environment variables : + # ... + + SERVICE LIST + service : /dummy_joint_states/describe_parameters + service count : 1 + client count : 0 + service : /dummy_joint_states/get_parameter_types + service count : 1 + client count : 0 + # ... + + +For more information see `ros2/ros2cli#1059 `_, `ros2/ros2cli#1076 `_, and `ros2/ros2cli#1045 `_. + +Verbose service information ``ros2 service info --verbose`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Are you debugging mismatched QoS settings between ROS clients and ROS services? +Try out the new ``--verbose`` option to ``ros2 service info``. +Like ``ros2 topic info``, this flag outputs detailed information about clients and services to help you troubleshoot issues. + +.. code-block:: console + + $ ros2 service info --verbose /robot_state_publisher/list_parameters + Type: rcl_interfaces/srv/ListParameters + Clients count: 0 + Services count: 1 + Node name: robot_state_publisher + Node namespace: / + Service type: rcl_interfaces/srv/ListParameters + Service type hash: RIHS01_3e6062bfbb27bfb8730d4cef2558221f51a11646d78e7bb30a1e83afac3aad9d + Endpoint type: SERVER + Endpoint count: 2 + GIDs: + - Request Reader : 01.0f.c8.b6.fe.43.b3.44.00.00.00.00.00.00.0e.04 + - Response Writer : 01.0f.c8.b6.fe.43.b3.44.00.00.00.00.00.00.0f.03 + QoS profiles: + - Request Reader : + Reliability: RELIABLE + History (Depth): KEEP_LAST (1000) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + - Response Writer : + Reliability: RELIABLE + History (Depth): KEEP_LAST (1000) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +Want to get client and service information programmatically? +Use these new C++ and Python APIs. + +.. code-block:: python + + node.get_servers_info_by_service('some/service/name') + node.get_clients_info_by_service('some/service/name') + +.. code-block:: c++ + + node->get_servers_info_by_service("some/service/name"); + node->get_clients_info_by_service("some/service/name"); + +See `ros2/ros2cli#916 `_, `ros2/rclpy#1307 `_, and `ros2/rclcpp#2569 `_ for more info. + +``ros2 topic bw`` multiple topics at once +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Trying to figure out which topics are using most of your network bandwidth? +Now you can use ``ros2 topic bw`` with multiple topics at the same time. +Pass multiple topics by name: + +.. code-block:: bash + + ros2 topic bw /tf /joint_states + +Or pass ``--all`` to watch bandwidth statistics in real time. + +.. image:: images/ros2_topic_bw_all.gif + +See `ros2/ros2cli#1124 `_ and `ros2/ros2cli#1130 `_ for more info. + +URDF improvements +^^^^^^^^^^^^^^^^^ + +URDF released a few new features: + +* Quaternions +* Capsule geometry +* Acceleration, deceleration, and jerk limits + +Add ``version="1.2"`` to your robot description to start using them. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +See `ros/urdfdom#235 `_, `ros/urdfdom#238 `_, and `ros/urdfdom#212 `_ for more info. + +Note that the Robot Model plugin `does not yet support capsule geometry `_. +Please consider opening a pull request for this feature! + +``robot_state_publisher`` can read the robot description from a topic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Most of the time in a ROS system the ``robot_state_publisher`` node does two things: + +* It publishes the ``robot_description`` on a topic, and +* It publishes TF transforms given joint positions. + +If you have ever tried to add ROS interfaces to a framework with its own internal robot model, you may have wished these were two separate utilities. +Now they can be! +Set the ``use_robot_description_topic`` parameter to ``true`` to make ``robot_state_publisher`` subscribe to the ``robot_description`` topic instead of publishing it. +Then, make the other robot framework publish its own robot description on that topic. + +See `ros/robot_state_publisher#234 `_ for more info. + +Resource retriever service +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Say you are debugging a robot in the field. +You open up RViz on your laptop, but you don't have the right version of the robot description installed. +In ROS Kilted, RViz added the ability to load meshes over the network using a ROS service ``/rviz/get_resource``; however, that ability was limited to RViz. +ROS Lyrical comes with a generic ``resource_retriever_service`` so that any node can load meshes over the network. + +.. code-block:: c++ + + resource_retriever::RetrieverVec plugins = resource_retriever::default_plugins(); + // Create a RosServiceResourceRetriever plugin + plugins.push_back(std::make_shared(*node)); + // Give that plugin to your Retriever instance + resource_retriever::Retriever retriever(plugins); + +See `ros2/rviz#1698 `_ for more details. + +Call ``ament_python_install_package`` multiple times +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Packages may now call ``ament_python_install_package()`` multiple times with the same Python package name. +This allows you to use ``rosidl_generate_interfaces()`` and ``ament_python_install_package()`` to put generated messages and code into the same Python package. + +While you can include code and message definitions in the same package, a best practice is to put message definitions in their own package. +This lets others depend on just the messages, as they might not need the code or its dependencies. + +See `ament/ament_cmake#587 `_ for more info. + +New CMake target: ``ament_cmake_ros_core::ament_ros_defaults`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Tired of specifying different C and C++ versions on different branches? +Let the new CMake target ``ament_cmake_ros_core::ament_ros_defaults`` set those for you. +This target uses `target_compile_features `_ to specify C and C++ version requirements. + +.. code-block:: cmake + + find_package(ament_cmake_ros REQUIRED) + target_link_libraries(my_library PUBLIC ament_cmake_ros_core::ament_ros_defaults) + +See `ros2/ament_cmake_ros#62 `_ for more info. + +New thread naming utilities +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Debugging multithreading issues? +Use two new utilities in ``rcpputils`` to get and set thread names. +This makes it easier to identify threads in debuggers like ``gdb``. + +.. code-block:: c++ + + #include + #include + + int main() { + rcpputils::set_thread_name("map_thread"); + std::cout << rcpputils::get_thread_name() << "\n"; + } + + +See `ros2/rcpputils#213 `_ for more details. + +New ``rcutils`` APIs +^^^^^^^^^^^^^^^^^^^^ + +The ``rcutils`` package includes some new utilities. +If your platform lacks ``strnlen``, you may now use ``rcutils_strnlen`` instead. + +.. code-block:: c + + #include + + #include + + int main() { + const char *str = "Hello world"; + size_t len = rcutils_strnlen(str, 100); + printf("%zu\n", len); + return 0; + } + +Need to encode or decode base64 data? +Try the new ``rcutils_encode_base64`` and ``rcutils_decode_base64`` functions. + +.. code-block:: c + + #include + #include + #include + + #include + #include + #include + + int main() { + rcutils_allocator_t allocator = rcutils_get_default_allocator(); + + rcutils_uint8_array_t input = rcutils_get_zero_initialized_uint8_array(); + assert(rcutils_uint8_array_init(&input, 11, &allocator) == RCUTILS_RET_OK); + memcpy(input.buffer, "Hello World", 11); + input.buffer_length = 11; + + char *encoded = NULL; + assert(rcutils_encode_base64(&input, &encoded, &allocator) == RCUTILS_RET_OK); + printf("%s\n", encoded); + + rcutils_uint8_array_t decoded = rcutils_get_zero_initialized_uint8_array(); + assert(rcutils_decode_base64(encoded, &decoded, &allocator) == RCUTILS_RET_OK); + printf("%.*s\n", (int)decoded.buffer_length, (char *)decoded.buffer); + + allocator.deallocate(encoded, allocator.state); + assert(rcutils_uint8_array_fini(&input) == RCUTILS_RET_OK); + assert(rcutils_uint8_array_fini(&decoded) == RCUTILS_RET_OK); + return 0; + } + +See `ros2/rcutils#430 `_ and `ros2/rcutils#533 `_ for more info. + +New ``rcl`` APIs +^^^^^^^^^^^^^^^^ + +If you maintain a ROS client library, you might be interested in these new ``rcl`` APIs: + +``rcl_lifecycle_get_transition_label_by_id`` +"""""""""""""""""""""""""""""""""""""""""""" +Retrieve the human-readable string label for a lifecycle transition ID. +Use this label to log, debug, or display state transitions without manually mapping IDs to strings. + +``rcl_subscription_is_cft_supported`` +""""""""""""""""""""""""""""""""""""" +Check whether a subscription supports Content Filtered Topics (CFT) on the underlying middleware. +Verify filtering support safely before applying or configuring message content filters. + +``rcl_action_count_clients`` +"""""""""""""""""""""""""""" +Query the ROS graph to count active action clients for a specific action name. +Action servers can verify client presence before expending resources, or tools can inspect graph state. + +``rcl_action_count_servers`` +"""""""""""""""""""""""""""" +Query the ROS graph to count active action servers for a specific action name. +Action clients can confirm a server is online before sending goal requests. + +``rcl_timer_exchange_callback_data`` +"""""""""""""""""""""""""""""""""""" +Update the user data pointer passed to a timer callback upon execution. +Dynamically swap callback context or state without recreating the active timer instance. + +``rcl_action_server_set_expired_event_callback`` +"""""""""""""""""""""""""""""""""""""""""""""""" +Register a custom event callback that triggers when an action server goal expiration timer fires. +Enable event-based execution patterns to asynchronously handle clean-up routines or notifications for expired goals. + +For more information see these pull requests: + +* `ros2/rcl#1229 `_ +* `ros2/rcl#1257 `_ +* `ros2/rcl#1293 `_ +* `ros2/rcl#1294 `_ +* `ros2/rcl#1295 `_ + +Pass constructor arguments to plugins using ``class_loader`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You may now pass arguments to plugins using ``class_loader``. +This removes the need for an initialization method in a plugin's API. +All you need to do is specialize ``class_loader::InterfaceTraits<>`` in your plugin's base class. + +.. code-block:: c++ + + class MyPluginWithConstructor + { + public: + // constructor parameters for the base class do not need to match the derived classes + explicit MyPluginWithConstructor(std::string) {} + virtual ~MyPluginWithConstructor() = default; + + virtual int some_api() = 0; + }; + + template<> + struct class_loader::InterfaceTraits + { + // Define constructor arguments that you must pass to instantiate a plugin + using constructor_parameters = class_loader::ConstructorParameters>; + }; + + +For more information see `ros/class_loader#223 `_. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Process.rst b/source/Get-Started/Releases/Release-Process.rst index 53ce233e460..a69aaff1d80 100644 --- a/source/Get-Started/Releases/Release-Process.rst +++ b/source/Get-Started/Releases/Release-Process.rst @@ -1,72 +1,76 @@ -Development process for a release -================================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -Each ROS 2 distribution goes through a process of development more than a year long that begins prior to the release of the previous distribution. -Below is a high-level view of this development process. -There is no specific due date for the items in this process, but in general earlier items should be completed before later items can be completed. - -For the progress through this process for a specific release, see that release's documentation page. - -.. list-table:: - :class: release-process - :header-rows: 1 - :widths: 30 70 - - * - Item - - Notes - * - Find the ROS Boss - - The "ROS Boss" is the person in charge of shepherding a distribution through the development, release, update, and EOL'ing stages of its life. They are chosen from the internal ROS 2 team at Open Robotics. - * - Run process to choose the distribution name - - The ROS Boss curates the process of choosing the distribution's name, using input from sources such as the community and potential naming conflicts. - * - Create distribution's documentation page - - Every distribution has a documentation page that lists its vital statistics, such as planned release date, EOL date, and significant changes since the previous release. - * - Set release timeline - - The final weeks leading up to release day (usually, World Turtle Day) are hectic and full of deadlines, such as when to freeze the default RMW implementation. These deadlines must be planned well in advance. - * - Produce roadmap - - While every contributor to ROS has their own planned features for each distribution, we try to maintain an overall roadmap of the new features and significant changes we expect to see in the distribution. The ROS Boss and the leader of the ROS 2 development team at Open Robotics work together with the ROS 2 TSC and other interested parties to produce a roadmap that is achievable in the time available and meets the needs of the ROS community. - * - Announce roadmap - - The list of planned features and significant changes is made public, via a GitHub issue that will track the progress on developing each item in the roadmap. Of course, this does not mean that the roadmap is fixed at this point, as development plans can change and we always (and frequently do) welcome new contributions even if they are not on the planned roadmap. - * - Set target platforms and major dependencies - - The target platforms, in terms of operating system, distribution and version, must be set far enough in advance for development work on the infrastructure (such as support in the build farm) to proceed. Similarly, the versions of each major dependency (which Python version, which compiler(s), which version of Eigen, etc.) must also be fixed. This is done via an update to `REP-2000 `__. - * - Add platform support to the build farm - - The build farm is a critical part of the infrastructure supporting a ROS 2 distribution. It provides continuous integration facilities that help us maintain quality, and it builds the binary packages the community relies on to avoid building ROS 2 and packages from source. If the target platforms differ from the previous ROS 2 distribution, then the necessary support must be added to the build farm. - * - Commission logo and related artwork - - A well-loved part of every ROS 2 distribution (and ROS distribution!) is the logo. The logo is commissioned from a professional artist based on the chosen distribution name. Based on the logo, other artwork such as the turtlesim icon are also produced. - * - Create mailing list for the distribution - - Vital for making critical announcements, a mailing list must be set up to contact people interested in knowing something about the distribution, such as that their package is failing to build into a binary on the build farm. - * - Create test cases - - As the development process enters the final few months, testing begins in earnest. The integration test cases that will be used during the final stages of development must be produced and provided to the release team who will be responsible for executing them. - * - Announce upcoming RMW freeze - - The RMW freeze is the point at which the default RMW implementation for the new distribution is feature-frozen. This gives developers a stable target to test their packages with, which is particularly important for the client library developers, who need to know what features of the RMW layer will be available for use by client libraries. - * - Upgrade dependency packages - - Packages depended on by ROS but not ROS software and not available in the platform package manager (such as aptitude for Ubuntu), the so-called "vendor packages", must be updated to the versions specified in REP-2000 (or an appropriate version, for those not listed in REP-2000). This is particularly important on Windows. - * - Create a detailed release plan - - Planning for the final two months of the development process is performed. This produces a detailed test plan, timelines of when certain packages must be available, and so on. It enables the finding of dependencies between steps in the release process and finding people to perform each of those steps. - * - Freeze RMW - - The RMW implementation is now feature-frozen. In theory, it can now be exhaustively tested to ensure it is working correctly by release day. - * - Announce upcoming overall freeze - - The next freeze after freezing the RMW implementation is to freeze the distribution as a whole. This is the point at which the core ROS packages become feature-frozen, giving developers of non-core packages a stable target to test their packages against, and giving distribution testers something to test that won't change right after they've tested it. - * - Freeze distribution - - From this point on, no new features can be added to any of the core ROS packages. Only bug fixes for the (inevitable) bugs found during the intensive integration test phases of development can be incorporated into the codebase. This means that Rolling Ridley is effectively frozen, temperarily. - * - Announce upcoming branch - - The branching of the new ROS 2 distribution from Rolling Ridley is an important moment. It is worth preparing for. - * - Announce upcoming beta - - When the distribution enters beta, it is ready for wider testing by the ROS community. This beta happens soon after the distribution is branched from Rolling Ridely. - * - Branch from Rolling Ridley - - The new ROS 2 distribution is created by making a new branch from Rolling Ridley. In effect, the new distribution is born at this point in time. Meanwhile, Rolling Ridley is free from the development process and can roll on into the future, once again receiving new features. - * - Add distribution to CI - - The continuous integration system is updated to allow building using the new distribution's branches and core ROS packages. This means that package developers can run CI for their packages against the new distribution, rather than Rolling Ridley. - * - Begin building interim testing tarballs - - The elite team of testers who will put the new distribution through its paces need something to test without compiling ROS 2 from source constantly. The build farm is used to produce a set of tarballs containing the distribution at a point in time for the testers to test. - * - Add distribution documentation - - Detailed documentation about the distribution, such as the significant changes since the previous distribution, is added to the ROS 2 documentation site. - * - Announce beta - - The beta release of the distribution is made and the ROS community as a whole is invited to contribute to testing it (for those who aren't already doing so). At this point, the more testers the better, because the distribution needs to be put through as wide a range of scenarios as possible to find bugs before the release. - * - Final release preparations - - As the new distribution enters is absolutely-completely-everything-frozen phase, the final preparations are made for the release. These include things like producing binary packages using the build farm so there will be something to release. - * - Release - - The big day, which if all goes to plan coincides with World Turtle Day on May 23rd. The distribution's binary packages are made available in the release repository, and an announcement is made. Parties are held and the ROS 2 development team takes a well-earned break. +.. redirect-from:: + + Releases/Release-Process + +Development process for a release +================================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +Each ROS 2 distribution goes through a process of development more than a year long that begins prior to the release of the previous distribution. +Below is a high-level view of this development process. +There is no specific due date for the items in this process, but in general earlier items should be completed before later items can be completed. + +For the progress through this process for a specific release, see that release's documentation page. + +.. list-table:: + :class: release-process + :header-rows: 1 + :widths: 30 70 + + * - Item + - Notes + * - Find the ROS Boss + - The "ROS Boss" is the person in charge of shepherding a distribution through the development, release, update, and EOL'ing stages of its life. They are chosen from the internal ROS 2 team at Open Robotics. + * - Run process to choose the distribution name + - The ROS Boss curates the process of choosing the distribution's name, using input from sources such as the community and potential naming conflicts. + * - Create distribution's documentation page + - Every distribution has a documentation page that lists its vital statistics, such as planned release date, EOL date, and significant changes since the previous release. + * - Set release timeline + - The final weeks leading up to release day (usually, World Turtle Day) are hectic and full of deadlines, such as when to freeze the default RMW implementation. These deadlines must be planned well in advance. + * - Produce roadmap + - While every contributor to ROS has their own planned features for each distribution, we try to maintain an overall roadmap of the new features and significant changes we expect to see in the distribution. The ROS Boss and the leader of the ROS 2 development team at Open Robotics work together with the ROS 2 TSC and other interested parties to produce a roadmap that is achievable in the time available and meets the needs of the ROS community. + * - Announce roadmap + - The list of planned features and significant changes is made public, via a GitHub issue that will track the progress on developing each item in the roadmap. Of course, this does not mean that the roadmap is fixed at this point, as development plans can change and we always (and frequently do) welcome new contributions even if they are not on the planned roadmap. + * - Set target platforms and major dependencies + - The target platforms, in terms of operating system, distribution and version, must be set far enough in advance for development work on the infrastructure (such as support in the build farm) to proceed. Similarly, the versions of each major dependency (which Python version, which compiler(s), which version of Eigen, etc.) must also be fixed. This is done via an update to `REP-2000 `__. + * - Add platform support to the build farm + - The build farm is a critical part of the infrastructure supporting a ROS 2 distribution. It provides continuous integration facilities that help us maintain quality, and it builds the binary packages the community relies on to avoid building ROS 2 and packages from source. If the target platforms differ from the previous ROS 2 distribution, then the necessary support must be added to the build farm. + * - Commission logo and related artwork + - A well-loved part of every ROS 2 distribution (and ROS distribution!) is the logo. The logo is commissioned from a professional artist based on the chosen distribution name. Based on the logo, other artwork such as the turtlesim icon are also produced. + * - Create mailing list for the distribution + - Vital for making critical announcements, a mailing list must be set up to contact people interested in knowing something about the distribution, such as that their package is failing to build into a binary on the build farm. + * - Create test cases + - As the development process enters the final few months, testing begins in earnest. The integration test cases that will be used during the final stages of development must be produced and provided to the release team who will be responsible for executing them. + * - Announce upcoming RMW freeze + - The RMW freeze is the point at which the default RMW implementation for the new distribution is feature-frozen. This gives developers a stable target to test their packages with, which is particularly important for the client library developers, who need to know what features of the RMW layer will be available for use by client libraries. + * - Upgrade dependency packages + - Packages depended on by ROS but not ROS software and not available in the platform package manager (such as aptitude for Ubuntu), the so-called "vendor packages", must be updated to the versions specified in REP-2000 (or an appropriate version, for those not listed in REP-2000). This is particularly important on Windows. + * - Create a detailed release plan + - Planning for the final two months of the development process is performed. This produces a detailed test plan, timelines of when certain packages must be available, and so on. It enables the finding of dependencies between steps in the release process and finding people to perform each of those steps. + * - Freeze RMW + - The RMW implementation is now feature-frozen. In theory, it can now be exhaustively tested to ensure it is working correctly by release day. + * - Announce upcoming overall freeze + - The next freeze after freezing the RMW implementation is to freeze the distribution as a whole. This is the point at which the core ROS packages become feature-frozen, giving developers of non-core packages a stable target to test their packages against, and giving distribution testers something to test that won't change right after they've tested it. + * - Freeze distribution + - From this point on, no new features can be added to any of the core ROS packages. Only bug fixes for the (inevitable) bugs found during the intensive integration test phases of development can be incorporated into the codebase. This means that Rolling Ridley is effectively frozen, temperarily. + * - Announce upcoming branch + - The branching of the new ROS 2 distribution from Rolling Ridley is an important moment. It is worth preparing for. + * - Announce upcoming beta + - When the distribution enters beta, it is ready for wider testing by the ROS community. This beta happens soon after the distribution is branched from Rolling Ridely. + * - Branch from Rolling Ridley + - The new ROS 2 distribution is created by making a new branch from Rolling Ridley. In effect, the new distribution is born at this point in time. Meanwhile, Rolling Ridley is free from the development process and can roll on into the future, once again receiving new features. + * - Add distribution to CI + - The continuous integration system is updated to allow building using the new distribution's branches and core ROS packages. This means that package developers can run CI for their packages against the new distribution, rather than Rolling Ridley. + * - Begin building interim testing tarballs + - The elite team of testers who will put the new distribution through its paces need something to test without compiling ROS 2 from source constantly. The build farm is used to produce a set of tarballs containing the distribution at a point in time for the testers to test. + * - Add distribution documentation + - Detailed documentation about the distribution, such as the significant changes since the previous distribution, is added to the ROS 2 documentation site. + * - Announce beta + - The beta release of the distribution is made and the ROS community as a whole is invited to contribute to testing it (for those who aren't already doing so). At this point, the more testers the better, because the distribution needs to be put through as wide a range of scenarios as possible to find bugs before the release. + * - Final release preparations + - As the new distribution enters is absolutely-completely-everything-frozen phase, the final preparations are made for the release. These include things like producing binary packages using the build farm so there will be something to release. + * - Release + - The big day, which if all goes to plan coincides with World Turtle Day on May 23rd. The distribution's binary packages are made available in the release repository, and an announcement is made. Parties are held and the ROS 2 development team takes a well-earned break. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Rolling-Ridley.rst b/source/Get-Started/Releases/Release-Rolling-Ridley.rst index 77616e3b7ac..7186bca18e3 100644 --- a/source/Get-Started/Releases/Release-Rolling-Ridley.rst +++ b/source/Get-Started/Releases/Release-Rolling-Ridley.rst @@ -1,43 +1,47 @@ -Rolling Ridley (``rolling``) -============================ - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Rolling Ridley* is a rolling development release of ROS 2. - -.. warning:: - - Rolling Ridley is continuously updated and is subject to in-place updates which will at times include breaking changes. - It is used for ROS 2 development and by maintainers who want their packages released and ready for the next stable distribution. - We recommend that most users of ROS 2 use the latest `stable distribution `. - -For more information see `REP-2002 `_ - -Currently Supported Platforms ------------------------------ - -Rolling Ridley supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019) - -Tier 3 platforms: - -* Debian Buster (10): ``amd64``, ``arm64`` and ``arm32`` -* Mac macOS 10.14 (Mojave) -* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` - -Installation ------------- - -`Install Rolling Ridley <../../Installation>` - -New features and changes in this release ----------------------------------------- - -Rolling Ridley is an ongoing development distribution. -Changes between the current stable release and the upcoming one can be found on the page for the `upcoming release `. +.. redirect-from:: + + Releases/Release-Rolling-Ridley + +Rolling Ridley (``rolling``) +============================ + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Rolling Ridley* is a rolling development release of ROS 2. + +.. warning:: + + Rolling Ridley is continuously updated and is subject to in-place updates which will at times include breaking changes. + It is used for ROS 2 development and by maintainers who want their packages released and ready for the next stable distribution. + We recommend that most users of ROS 2 use the latest `stable distribution `. + +For more information see `REP-2002 `_ + +Currently Supported Platforms +----------------------------- + +Rolling Ridley supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019) + +Tier 3 platforms: + +* Debian Buster (10): ``amd64``, ``arm64`` and ``arm32`` +* Mac macOS 10.14 (Mojave) +* OpenEmbedded Thud (2.6) / webOS OSE: ``arm32`` and ``x86`` + +Installation +------------ + +`Install Rolling Ridley <../../Installation>` + +New features and changes in this release +---------------------------------------- + +Rolling Ridley is an ongoing development distribution. +Changes between the current stable release and the upcoming one can be found on the page for the `upcoming release `. \ No newline at end of file diff --git a/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst b/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst index b2eaa1b248f..00c4a68031b 100644 --- a/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst +++ b/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst @@ -1,591 +1,592 @@ -.. redirect-from:: - - Deploying-ROS2-on-IBM-Cloud - Tutorials/Deploying-ROS-2-on-IBM-Cloud - -Deploying on IBM Cloud Kubernetes [community-contributed] -========================================================= - - -.. contents:: Table of Contents - :depth: 3 - :local: - -About ------ - -This article describes how to get ROS 2 running on IBM Cloud using Docker files. -It first gives a brief overview of docker images and how they work locally and then explores IBM Cloud and how the user can deploy their containers on it. -Afterwards, a short description of how the user can use their own custom packages for ROS 2 from github on IBM Cloud is provided. -A walkthrough of how to create a cluster and utilize Kubernetes on IBM Cloud is provided and finally the Docker image is deployed on the cluster. -Originally published `here `__ and `here `__. - -ROS 2 on IBM Cloud ------------------- - -In this tutorial, we show how you can easily integrate and run ROS 2 on -IBM Cloud with your custom packages. - -ROS 2 is the new generation of ROS which gives more control over multi-robot formations. -With the advancements of cloud computing, cloud robotics are becoming more important in today's age. -In this tutorial, we will go through a short introduction on running ROS 2 on IBM Cloud. -By the end of the tutorial, you will be able to create your own packages in -ROS 2 and deploy them to the cloud using docker files. - -The following instructions assume you're using Linux and have been -tested with Ubuntu 18.04 (Bionic Beaver). - -Step 1: Setting up your system -------------------------------- - -Before we go into how the exact process works, lets first make sure all the required software is properly installed. -We'll point you towards the appropriate sources to set up your system and only highlight the details that pertain to our use-case. - -a) Docker files? -^^^^^^^^^^^^^^^^ - -Docker files are a form of containers that can run separate from your -system, this way, you can set-up potentially hundreds of different -projects without affecting one another. -You can even set-up different versions of Linux on one machine, without the need for virtual machine. -Docker files have an advantage of saving space and only utilizing your system resources when running. -In addition, dockers are versatile and transferable. -They contain all the required pre-requisites to run -separately, meaning that you can easily use a docker file for a specific -system or service without any cubersome steps! - -Excited yet? -Let's start off by installing docker to your system by following the following `link `__. -From the tutorial, you should have done some sanity checks to make sure docker is properly set-up. -Just in case, however, let's run the following command once again that uses the hello-world docker image: - -.. code-block:: console - - $ sudo docker run hello-world - Hello from Docker! - This message shows that your installation appears to be working correctly. - - To generate this message, Docker took the following steps: - 1. The Docker client contacted the Docker daemon. - 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. - (amd64) - 3. The Docker daemon created a new container from that image which runs the - executable that produces the output you are currently reading. - 4. The Docker daemon streamed that output to the Docker client, which sent it - to your terminal. - - To try something more ambitious, you can run an Ubuntu container with: - $ docker run -it ubuntu bash - - Share images, automate workflows, and more with a free Docker ID: - https://hub.docker.com/ - - For more examples and ideas, visit: - https://docs.docker.com/get-started/ - -b) ROS 2 Image -^^^^^^^^^^^^^^ - -ROS -`announced `__ -image containers for several ROS distributions in January 2019. -More detailed instructions on the use of ROS 2 docker images can be found -`here `__. - -Let's skip through that and get to real-deal right away; creating a -local ROS 2 docker. -We'll create our own Dockerfile (instead of using a -ready Image) since we'll need this method for deployment on IBM Cloud. -First, we create a new directory which will hold our Dockerfile and any -other files we need later on and navigate to it. -Using your favorite $EDITOR of choice, open a new file named *Dockerfile* (make sure the -file naming is correct): - -.. code-block:: console - - $ mkdir ~/ros2_docker - - $ cd ~/ros2_docker - - $ $EDITOR Dockerfile - -Insert the following in the *Dockerfile*, and save it (also found -`here `__): - -.. code-block:: bash - - FROM ros:foxy - - # install ros package - RUN apt-get update && apt-get install -y \ - ros-${ROS_DISTRO}-demo-nodes-cpp \ - ros-${ROS_DISTRO}-demo-nodes-py && \ - rm -rf /var/lib/apt/lists/* && mkdir /ros2_home - - WORKDIR /ros2_home - - # launch ros package - CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"] - -- **FROM**: creates a layer from the ros:foxy Docker image -- **RUN**: builds your container by installing vim into it and creating - a directory called /ros2_home -- **WORKDIR**: informs the container where the working directory should - be for it - -Of course, you are free to change the ROS distribution (*foxy* is used -here) or change the directory name. -The above docker file sets up ROS-foxy and installs the demo nodes for C++ and Python. -Then it launches a file which runs a talker and a listener node. -We will see it in action in just a few, but they act very similar to the -publisher-subscriber example found in the `ROS -wiki `__ - -Now, we are ready to build the docker image to run ROS 2 in it (yes, it is THAT easy!). - -**Note**: if you have errors due to insufficient privileges or -*permission denied*, try running the command with *sudo* privileges: - -.. code-block:: console - - $ docker build . - - ~ You will see a bunch of lines that execute the docker file instructions followed by: - - Successfully built 0dc6ce7cb487 - -*0dc6ce7cb487* will most probably be different for you, so keep note of -it and copy it somewhere for reference. -You can always go back and check -the docker images you have on your system using: - -.. code-block:: console - - $ sudo docker ps -as - -Now, run the docker file using: - -.. code-block:: console - - $ docker run -it 0dc6ce7cb487 - [INFO] [launch]: All log files can be found below /root/.ros/log/2020-10-28-02-41-45-177546-0b5d9ed123be-1 - [INFO] [launch]: Default logging verbosity is set to INFO - [INFO] [talker-1]: process started with pid [28] - [INFO] [listener-2]: process started with pid [30] - [talker-1] [INFO] [1603852907.249886590] [talker]: Publishing: 'Hello World: 1' - [listener-2] [INFO] [1603852907.250964490] [listener]: I heard: [Hello World: 1] - [talker-1] [INFO] [1603852908.249786312] [talker]: Publishing: 'Hello World: 2' - [listener-2] [INFO] [1603852908.250453386] [listener]: I heard: [Hello World: 2] - [talker-1] [INFO] [1603852909.249882257] [talker]: Publishing: 'Hello World: 3' - [listener-2] [INFO] [1603852909.250536089] [listener]: I heard: [Hello World: 3] - [talker-1] [INFO] [1603852910.249845718] [talker]: Publishing: 'Hello World: 4' - [listener-2] [INFO] [1603852910.250509355] [listener]: I heard: [Hello World: 4] - [talker-1] [INFO] [1603852911.249506058] [talker]: Publishing: 'Hello World: 5' - [listener-2] [INFO] [1603852911.250152324] [listener]: I heard: [Hello World: 5] - [talker-1] [INFO] [1603852912.249556670] [talker]: Publishing: 'Hello World: 6' - [listener-2] [INFO] [1603852912.250212678] [listener]: I heard: [Hello World: 6] - -If it works correctly, you should see something similar to what is shown above. -As can be seen, there are two ROS nodes (a publisher and a -subscriber) running and their output is provided to us through ROS INFO. - -Step 2: Running the image on IBM Cloud --------------------------------------- - -The following steps assume you have an IBM cloud account and have -ibmcloud CLI installed. -If not, please check this -`link `__ -out to get that done first. - -We also need to make sure that the CLI plug-in for the IBM Cloud -Container Registry is installed by running the command - -.. code-block:: console - - $ ibmcloud plugin install container-registry - -Afterwards, login to your ibmcloud account through the terminal: - -.. code-block:: console - - $ ibmcloud login --sso - -From here, let's create a container registry name-space. -Make sure you use a unique name that is also descriptive as to what it is. -Here, I used *ros2nasr*. - -.. code-block:: console - - $ ibmcloud cr namespace-add ros2nasr - -IBM cloud has a lot of shortcuts that would help us get our container onto the cloud right away. -The command below builds the container and tags it with the name **ros2foxy** and the version of **1**. -Make sure you use the correct registry name you created and you are free to change the container name as you wish. -The ``.`` at the end indicates that the *Dockerfile* is in the current directory (and it is important), if not, -change it to point to the directory containing the Dockerfile. - -.. code-block:: console - - $ ibmcloud cr build --tag registry.bluemix.net/ros2nasr/ros2foxy:1 . - -You can now make sure that the container has been pushed to the registry -you created by running the following command - -.. code-block:: console - - $ ibmcloud cr image-list - Listing images... - - REPOSITORY TAG DIGEST NAMESPACE CREATED SIZE SECURITY STATUS - us.icr.io/ros2nasr/ros2foxy 1 031be29301e6 ros2nasr 36 seconds ago 120 MB No Issues - - OK - -Next, it is important to log-in to your registry to run the docker image. -Again, if you face a *permission denied* error, perform the command with sudo privileges. -Afterwards, run your docker file as shown below. - -.. code-block:: console - - $ ibmcloud cr login - Logging in to 'registry.ng.bluemix.net'... - Logged in to 'registry.ng.bluemix.net'. - Logging in to 'us.icr.io'... - Logged in to 'us.icr.io'. - - OK - - $ docker run -v -it registry.ng.bluemix.net/ros2nasr/ros2foxy:1 - -Where *ros2nasr* is the name of the registry you created and -*ros2foxy:1* is the tag of the docker container and the version as -explained previously. - -You should now see your docker file running and providing similar output -to that you saw when you ran it locally on your machine. - -Step 3: Using Custom ROS 2 Packages ------------------------------------ - -So now we have the full pipeline working, from creating the Dockerfile, all the way to deploying it and seeing it work on IBM Cloud. -But, what if we want to use a custom set of packages we (or someone else) created? - -Well that all has to do with how you set-up your Dockerfile. -Let's use the example provided by ROS 2 `here `__. -Create a new directory with a new Dockerfile (or overwrite the existing one) and add the following in it (or download the file -`here `__) - -.. code-block:: bash - - ARG FROM_IMAGE=ros:foxy - ARG OVERLAY_WS=/opt/ros/overlay_ws - - # multi-stage for caching - FROM $FROM_IMAGE AS cacher - - # clone overlay source - ARG OVERLAY_WS - WORKDIR $OVERLAY_WS/src - RUN echo "\ - repositories: \n\ - ros2/demos: \n\ - type: git \n\ - url: https://github.com/ros2/demos.git \n\ - version: ${ROS_DISTRO} \n\ - " > ../overlay.repos - RUN vcs import ./ < ../overlay.repos - - # copy manifests for caching - WORKDIR /opt - RUN mkdir -p /tmp/opt && \ - find ./ -name "package.xml" | \ - xargs cp --parents -t /tmp/opt && \ - find ./ -name "COLCON_IGNORE" | \ - xargs cp --parents -t /tmp/opt || true - - # multi-stage for building - FROM $FROM_IMAGE AS builder - - # install overlay dependencies - ARG OVERLAY_WS - WORKDIR $OVERLAY_WS - COPY --from=cacher /tmp/$OVERLAY_WS/src ./src - RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ - apt-get update && rosdep install -y \ - --from-paths \ - src/ros2/demos/demo_nodes_cpp \ - src/ros2/demos/demo_nodes_py \ - --ignore-src \ - && rm -rf /var/lib/apt/lists/* - - # build overlay source - COPY --from=cacher $OVERLAY_WS/src ./src - ARG OVERLAY_MIXINS="release" - RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ - colcon build \ - --packages-select \ - demo_nodes_cpp \ - demo_nodes_py \ - --mixin $OVERLAY_MIXINS - - # source entrypoint setup - ENV OVERLAY_WS $OVERLAY_WS - RUN sed --in-place --expression \ - '$isource "$OVERLAY_WS/install/setup.bash"' \ - /ros_entrypoint.sh - - # run launch file - CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"] - -Going through the lines shown, we can see how we can add custom packages -from github in 4 steps: - -1. Create an overlay with custom packages cloned from Github: - -.. code-block:: bash - - ARG OVERLAY_WS - WORKDIR $OVERLAY_WS/src - RUN echo "\ - repositories: \n\ - ros2/demos: \n\ - type: git \n\ - url: https://github.com/ros2/demos.git \n\ - version: ${ROS_DISTRO} \n\ - " > ../overlay.repos - RUN vcs import ./ < ../overlay.repos - -2. Install package dependencies using rosdep - -.. code-block:: bash - - # install overlay dependencies - ARG OVERLAY_WS - WORKDIR $OVERLAY_WS - COPY --from=cacher /tmp/$OVERLAY_WS/src ./src - RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ - apt-get update && rosdep install -y \ - --from-paths \ - src/ros2/demos/demo_nodes_cpp \ - src/ros2/demos/demo_nodes_py \ - --ignore-src \ - && rm -rf /var/lib/apt/lists/* - -3. Build the packages *you need* - -.. code-block:: bash - - # build overlay source - COPY --from=cacher $OVERLAY_WS/src ./src - ARG OVERLAY_MIXINS="release" - RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ - colcon build \ - --packages-select \ - demo_nodes_cpp \ - demo_nodes_py \ - --mixin $OVERLAY_MIXINS - -4. Running the launch file - -.. code-block:: bash - - # run launch file - CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"] - -Likewise, we can change the packages used, install their dependencies, -and then run them. - -**Back to IBM Cloud** - -With this Dockerfile, we can follow the same steps we did before to deploy it on IBM Cloud. -Since we already have our registry created, and we're logged in to IBM Cloud, we directly build our new Dockerfile. -Notice how I kept the tag the same but changed the version, this way I can update the docker image created previously. -(You are free to create a completely new one if you want) - -.. code-block:: console - - $ ibmcloud cr build --tag registry.bluemix.net/ros2nasr/ros2foxy:2 . - -Then, make sure you are logged in to the registry and run the new docker -image: - -.. code-block:: console - - $ ibmcloud cr login - Logging in to 'registry.ng.bluemix.net'... - Logged in to 'registry.ng.bluemix.net'. - Logging in to 'us.icr.io'... - Logged in to 'us.icr.io'. - - OK - - $ docker run -v -it registry.ng.bluemix.net/ros2nasr/ros2foxy:2 - -You should see, again, the same output. -However, this time we did it through custom packages from github, which allows us to utilize our personally created packages for ROS 2 on IBM Cloud. - -Extra: Deleting Docker Images -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As you may find yourself in need of deleting a specific docker image(s) -from IBM Cloud, this is how you should go about it! - -1. List all the images you have and find all the ones that share the - *IMAGE* name corresponding to - *registry.ng.bluemix.net/ros2nasr/ros2foxy:2* (in my case). - Then delete them using their *NAMES* - -.. code-block:: console - - $ docker rm your_docker_NAMES - -2. Delete the docker image from IBM Cloud using its *IMAGE* name - -.. code-block:: console - - $ docker rmi registry.ng.bluemix.net/ros2nasr/ros2foxy:2 - -Step 4: Kubernetes -------------------- - -a) Creating the Cluster -^^^^^^^^^^^^^^^^^^^^^^^ - -Create a cluster using the Console. -The instructions are found `here `__. -The settings used are detailed below. -These are merely suggestions and can be changed if you need to. -However, make sure you understand the implications of your choices: - -1. Plan: *Standard* - -2. Orchestration Service: *Kubernetes v1.18.10* - -3. Infrastructure: *Classic* - -4. Location: - -- Resource group: *Default* - -- Geography: *North America* (you are free to change this) - -- Availability: *Single zone* - (you are free to change this but make sure you understand the impact of your choices by checking the IBM Cloud documentation.) - -- Worker Zone: *Toronto 01* (choose the location that is physically - closest to you) - -5. Worker Pool: - -- Virtual - shared, Ubuntu 18 - -- Memory: 16 GB - -- Worker nodes per zone: *1* - -6. Master service endpoint: *Both private & public endpoints* - -7. Resource details (Totally flexible): - -- Cluster name: *mycluster-tor01-rosibm* - -- Tags: *version:1* - -After you create your cluster, you will be redirected to a page which details how you can set up the CLI tools and access your cluster. -Please follow these instructions (or check the instructions `here `__) -and wait for the progress bar to show that the worker nodes you created are -ready by indicating *Normal* next to the cluster name. -You can also reach this screen from the IBM Cloud Console inside the Kubernetes. - -b) Deploying your Docker Image *Finally!* -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -1. Create a deployment configuration yaml file named - *ros2-deployment.yaml* using your favorite $EDITOR and insert the - following in it: - -.. code-block:: bash - - apiVersion: apps/v1 - kind: Deployment - metadata: - name: - spec: - replicas: - selector: - matchLabels: - app: - template: - metadata: - labels: - app: - spec: - containers: - - name: - image: .icr.io//: - -You should replace the tags shown between *"<" ">"* as described -`here `__. -The file in my case would look something like this: - -.. code-block:: bash - - apiVersion: apps/v1 - kind: Deployment - metadata: - name: ros2-deployment - spec: - replicas: 1 - selector: - matchLabels: - app: ros2-ibmcloud - template: - metadata: - labels: - app: ros2-ibmcloud - spec: - containers: - - name: ros2-ibmcloud - image: us.icr.io/ros2nasr/ros2foxy:2 - -Deploy the file using the following command - -.. code-block:: console - - $ kubectl apply -f ros2-deployment.yaml - deployment.apps/ros2-deployment created - -Now your docker image is fully deployed on your cluster! - -Step 5: Using CLI for your Docker Image ---------------------------------------- - -1. Navigate to your cluster through the IBM Cloud console Kubernetes. - -2. Click on *Kubernetes dashboard* on the top right corner of the page. - -You should now be able to see a full list of all the different -parameters of your cluster as well as its CPU and Memory Usage. - -3. Navigate to *Pods* and click on your deployment. - -4. On the top right corner, click on *Exec into pod* - -Now you are inside your docker image! -You can source your workspace (if needed) and run ROS 2! -For example: - -.. code-block:: console - - root@ros2-deployment-xxxxxxxx:/opt/ros/overlay_ws# . install/setup.sh - root@ros2-deployment-xxxxxxxx:/opt/ros/overlay_ws# ros2 launch demo_nodes_cpp talker_listener_launch.py - -Final Remarks ---------------- - -At this point, you are capable of creating your own docker image using ROS 2 packages on github. -It is also possible, with little changes to utilize local ROS 2 packages as well. -This could be the topic of another article. -However, you are encouraged to check out the following `Dockerfile `__ which uses a local copy of the demos repository. -Similarly, you can use your own local package. +.. redirect-from:: + + Deploying-ROS2-on-IBM-Cloud + Tutorials/Deploying-ROS-2-on-IBM-Cloud + Tutorials/Miscellaneous/Deploying-ROS-2-on-IBM-Cloud + +Deploying on IBM Cloud Kubernetes [community-contributed] +========================================================= + + +.. contents:: Table of Contents + :depth: 3 + :local: + +About +----- + +This article describes how to get ROS 2 running on IBM Cloud using Docker files. +It first gives a brief overview of docker images and how they work locally and then explores IBM Cloud and how the user can deploy their containers on it. +Afterwards, a short description of how the user can use their own custom packages for ROS 2 from github on IBM Cloud is provided. +A walkthrough of how to create a cluster and utilize Kubernetes on IBM Cloud is provided and finally the Docker image is deployed on the cluster. +Originally published `here `__ and `here `__. + +ROS 2 on IBM Cloud +------------------ + +In this tutorial, we show how you can easily integrate and run ROS 2 on +IBM Cloud with your custom packages. + +ROS 2 is the new generation of ROS which gives more control over multi-robot formations. +With the advancements of cloud computing, cloud robotics are becoming more important in today's age. +In this tutorial, we will go through a short introduction on running ROS 2 on IBM Cloud. +By the end of the tutorial, you will be able to create your own packages in +ROS 2 and deploy them to the cloud using docker files. + +The following instructions assume you're using Linux and have been +tested with Ubuntu 18.04 (Bionic Beaver). + +Step 1: Setting up your system +------------------------------- + +Before we go into how the exact process works, lets first make sure all the required software is properly installed. +We'll point you towards the appropriate sources to set up your system and only highlight the details that pertain to our use-case. + +a) Docker files? +^^^^^^^^^^^^^^^^ + +Docker files are a form of containers that can run separate from your +system, this way, you can set-up potentially hundreds of different +projects without affecting one another. +You can even set-up different versions of Linux on one machine, without the need for virtual machine. +Docker files have an advantage of saving space and only utilizing your system resources when running. +In addition, dockers are versatile and transferable. +They contain all the required pre-requisites to run +separately, meaning that you can easily use a docker file for a specific +system or service without any cubersome steps! + +Excited yet? +Let's start off by installing docker to your system by following the following `link `__. +From the tutorial, you should have done some sanity checks to make sure docker is properly set-up. +Just in case, however, let's run the following command once again that uses the hello-world docker image: + +.. code-block:: console + + $ sudo docker run hello-world + Hello from Docker! + This message shows that your installation appears to be working correctly. + + To generate this message, Docker took the following steps: + 1. The Docker client contacted the Docker daemon. + 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. + (amd64) + 3. The Docker daemon created a new container from that image which runs the + executable that produces the output you are currently reading. + 4. The Docker daemon streamed that output to the Docker client, which sent it + to your terminal. + + To try something more ambitious, you can run an Ubuntu container with: + $ docker run -it ubuntu bash + + Share images, automate workflows, and more with a free Docker ID: + https://hub.docker.com/ + + For more examples and ideas, visit: + https://docs.docker.com/get-started/ + +b) ROS 2 Image +^^^^^^^^^^^^^^ + +ROS +`announced `__ +image containers for several ROS distributions in January 2019. +More detailed instructions on the use of ROS 2 docker images can be found +`here `__. + +Let's skip through that and get to real-deal right away; creating a +local ROS 2 docker. +We'll create our own Dockerfile (instead of using a +ready Image) since we'll need this method for deployment on IBM Cloud. +First, we create a new directory which will hold our Dockerfile and any +other files we need later on and navigate to it. +Using your favorite $EDITOR of choice, open a new file named *Dockerfile* (make sure the +file naming is correct): + +.. code-block:: console + + $ mkdir ~/ros2_docker + + $ cd ~/ros2_docker + + $ $EDITOR Dockerfile + +Insert the following in the *Dockerfile*, and save it (also found +`here `__): + +.. code-block:: bash + + FROM ros:foxy + + # install ros package + RUN apt-get update && apt-get install -y \ + ros-${ROS_DISTRO}-demo-nodes-cpp \ + ros-${ROS_DISTRO}-demo-nodes-py && \ + rm -rf /var/lib/apt/lists/* && mkdir /ros2_home + + WORKDIR /ros2_home + + # launch ros package + CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"] + +- **FROM**: creates a layer from the ros:foxy Docker image +- **RUN**: builds your container by installing vim into it and creating + a directory called /ros2_home +- **WORKDIR**: informs the container where the working directory should + be for it + +Of course, you are free to change the ROS distribution (*foxy* is used +here) or change the directory name. +The above docker file sets up ROS-foxy and installs the demo nodes for C++ and Python. +Then it launches a file which runs a talker and a listener node. +We will see it in action in just a few, but they act very similar to the +publisher-subscriber example found in the `ROS +wiki `__ + +Now, we are ready to build the docker image to run ROS 2 in it (yes, it is THAT easy!). + +**Note**: if you have errors due to insufficient privileges or +*permission denied*, try running the command with *sudo* privileges: + +.. code-block:: console + + $ docker build . + + ~ You will see a bunch of lines that execute the docker file instructions followed by: + + Successfully built 0dc6ce7cb487 + +*0dc6ce7cb487* will most probably be different for you, so keep note of +it and copy it somewhere for reference. +You can always go back and check +the docker images you have on your system using: + +.. code-block:: console + + $ sudo docker ps -as + +Now, run the docker file using: + +.. code-block:: console + + $ docker run -it 0dc6ce7cb487 + [INFO] [launch]: All log files can be found below /root/.ros/log/2020-10-28-02-41-45-177546-0b5d9ed123be-1 + [INFO] [launch]: Default logging verbosity is set to INFO + [INFO] [talker-1]: process started with pid [28] + [INFO] [listener-2]: process started with pid [30] + [talker-1] [INFO] [1603852907.249886590] [talker]: Publishing: 'Hello World: 1' + [listener-2] [INFO] [1603852907.250964490] [listener]: I heard: [Hello World: 1] + [talker-1] [INFO] [1603852908.249786312] [talker]: Publishing: 'Hello World: 2' + [listener-2] [INFO] [1603852908.250453386] [listener]: I heard: [Hello World: 2] + [talker-1] [INFO] [1603852909.249882257] [talker]: Publishing: 'Hello World: 3' + [listener-2] [INFO] [1603852909.250536089] [listener]: I heard: [Hello World: 3] + [talker-1] [INFO] [1603852910.249845718] [talker]: Publishing: 'Hello World: 4' + [listener-2] [INFO] [1603852910.250509355] [listener]: I heard: [Hello World: 4] + [talker-1] [INFO] [1603852911.249506058] [talker]: Publishing: 'Hello World: 5' + [listener-2] [INFO] [1603852911.250152324] [listener]: I heard: [Hello World: 5] + [talker-1] [INFO] [1603852912.249556670] [talker]: Publishing: 'Hello World: 6' + [listener-2] [INFO] [1603852912.250212678] [listener]: I heard: [Hello World: 6] + +If it works correctly, you should see something similar to what is shown above. +As can be seen, there are two ROS nodes (a publisher and a +subscriber) running and their output is provided to us through ROS INFO. + +Step 2: Running the image on IBM Cloud +-------------------------------------- + +The following steps assume you have an IBM cloud account and have +ibmcloud CLI installed. +If not, please check this +`link `__ +out to get that done first. + +We also need to make sure that the CLI plug-in for the IBM Cloud +Container Registry is installed by running the command + +.. code-block:: console + + $ ibmcloud plugin install container-registry + +Afterwards, login to your ibmcloud account through the terminal: + +.. code-block:: console + + $ ibmcloud login --sso + +From here, let's create a container registry name-space. +Make sure you use a unique name that is also descriptive as to what it is. +Here, I used *ros2nasr*. + +.. code-block:: console + + $ ibmcloud cr namespace-add ros2nasr + +IBM cloud has a lot of shortcuts that would help us get our container onto the cloud right away. +The command below builds the container and tags it with the name **ros2foxy** and the version of **1**. +Make sure you use the correct registry name you created and you are free to change the container name as you wish. +The ``.`` at the end indicates that the *Dockerfile* is in the current directory (and it is important), if not, +change it to point to the directory containing the Dockerfile. + +.. code-block:: console + + $ ibmcloud cr build --tag registry.bluemix.net/ros2nasr/ros2foxy:1 . + +You can now make sure that the container has been pushed to the registry +you created by running the following command + +.. code-block:: console + + $ ibmcloud cr image-list + Listing images... + + REPOSITORY TAG DIGEST NAMESPACE CREATED SIZE SECURITY STATUS + us.icr.io/ros2nasr/ros2foxy 1 031be29301e6 ros2nasr 36 seconds ago 120 MB No Issues + + OK + +Next, it is important to log-in to your registry to run the docker image. +Again, if you face a *permission denied* error, perform the command with sudo privileges. +Afterwards, run your docker file as shown below. + +.. code-block:: console + + $ ibmcloud cr login + Logging in to 'registry.ng.bluemix.net'... + Logged in to 'registry.ng.bluemix.net'. + Logging in to 'us.icr.io'... + Logged in to 'us.icr.io'. + + OK + + $ docker run -v -it registry.ng.bluemix.net/ros2nasr/ros2foxy:1 + +Where *ros2nasr* is the name of the registry you created and +*ros2foxy:1* is the tag of the docker container and the version as +explained previously. + +You should now see your docker file running and providing similar output +to that you saw when you ran it locally on your machine. + +Step 3: Using Custom ROS 2 Packages +----------------------------------- + +So now we have the full pipeline working, from creating the Dockerfile, all the way to deploying it and seeing it work on IBM Cloud. +But, what if we want to use a custom set of packages we (or someone else) created? + +Well that all has to do with how you set-up your Dockerfile. +Let's use the example provided by ROS 2 `here `__. +Create a new directory with a new Dockerfile (or overwrite the existing one) and add the following in it (or download the file +`here `__) + +.. code-block:: bash + + ARG FROM_IMAGE=ros:foxy + ARG OVERLAY_WS=/opt/ros/overlay_ws + + # multi-stage for caching + FROM $FROM_IMAGE AS cacher + + # clone overlay source + ARG OVERLAY_WS + WORKDIR $OVERLAY_WS/src + RUN echo "\ + repositories: \n\ + ros2/demos: \n\ + type: git \n\ + url: https://github.com/ros2/demos.git \n\ + version: ${ROS_DISTRO} \n\ + " > ../overlay.repos + RUN vcs import ./ < ../overlay.repos + + # copy manifests for caching + WORKDIR /opt + RUN mkdir -p /tmp/opt && \ + find ./ -name "package.xml" | \ + xargs cp --parents -t /tmp/opt && \ + find ./ -name "COLCON_IGNORE" | \ + xargs cp --parents -t /tmp/opt || true + + # multi-stage for building + FROM $FROM_IMAGE AS builder + + # install overlay dependencies + ARG OVERLAY_WS + WORKDIR $OVERLAY_WS + COPY --from=cacher /tmp/$OVERLAY_WS/src ./src + RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ + apt-get update && rosdep install -y \ + --from-paths \ + src/ros2/demos/demo_nodes_cpp \ + src/ros2/demos/demo_nodes_py \ + --ignore-src \ + && rm -rf /var/lib/apt/lists/* + + # build overlay source + COPY --from=cacher $OVERLAY_WS/src ./src + ARG OVERLAY_MIXINS="release" + RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ + colcon build \ + --packages-select \ + demo_nodes_cpp \ + demo_nodes_py \ + --mixin $OVERLAY_MIXINS + + # source entrypoint setup + ENV OVERLAY_WS $OVERLAY_WS + RUN sed --in-place --expression \ + '$isource "$OVERLAY_WS/install/setup.bash"' \ + /ros_entrypoint.sh + + # run launch file + CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"] + +Going through the lines shown, we can see how we can add custom packages +from github in 4 steps: + +1. Create an overlay with custom packages cloned from Github: + +.. code-block:: bash + + ARG OVERLAY_WS + WORKDIR $OVERLAY_WS/src + RUN echo "\ + repositories: \n\ + ros2/demos: \n\ + type: git \n\ + url: https://github.com/ros2/demos.git \n\ + version: ${ROS_DISTRO} \n\ + " > ../overlay.repos + RUN vcs import ./ < ../overlay.repos + +2. Install package dependencies using rosdep + +.. code-block:: bash + + # install overlay dependencies + ARG OVERLAY_WS + WORKDIR $OVERLAY_WS + COPY --from=cacher /tmp/$OVERLAY_WS/src ./src + RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ + apt-get update && rosdep install -y \ + --from-paths \ + src/ros2/demos/demo_nodes_cpp \ + src/ros2/demos/demo_nodes_py \ + --ignore-src \ + && rm -rf /var/lib/apt/lists/* + +3. Build the packages *you need* + +.. code-block:: bash + + # build overlay source + COPY --from=cacher $OVERLAY_WS/src ./src + ARG OVERLAY_MIXINS="release" + RUN . /opt/ros/$ROS_DISTRO/setup.sh && \ + colcon build \ + --packages-select \ + demo_nodes_cpp \ + demo_nodes_py \ + --mixin $OVERLAY_MIXINS + +4. Running the launch file + +.. code-block:: bash + + # run launch file + CMD ["ros2", "launch", "demo_nodes_cpp", "talker_listener_launch.py"] + +Likewise, we can change the packages used, install their dependencies, +and then run them. + +**Back to IBM Cloud** + +With this Dockerfile, we can follow the same steps we did before to deploy it on IBM Cloud. +Since we already have our registry created, and we're logged in to IBM Cloud, we directly build our new Dockerfile. +Notice how I kept the tag the same but changed the version, this way I can update the docker image created previously. +(You are free to create a completely new one if you want) + +.. code-block:: console + + $ ibmcloud cr build --tag registry.bluemix.net/ros2nasr/ros2foxy:2 . + +Then, make sure you are logged in to the registry and run the new docker +image: + +.. code-block:: console + + $ ibmcloud cr login + Logging in to 'registry.ng.bluemix.net'... + Logged in to 'registry.ng.bluemix.net'. + Logging in to 'us.icr.io'... + Logged in to 'us.icr.io'. + + OK + + $ docker run -v -it registry.ng.bluemix.net/ros2nasr/ros2foxy:2 + +You should see, again, the same output. +However, this time we did it through custom packages from github, which allows us to utilize our personally created packages for ROS 2 on IBM Cloud. + +Extra: Deleting Docker Images +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As you may find yourself in need of deleting a specific docker image(s) +from IBM Cloud, this is how you should go about it! + +1. List all the images you have and find all the ones that share the + *IMAGE* name corresponding to + *registry.ng.bluemix.net/ros2nasr/ros2foxy:2* (in my case). + Then delete them using their *NAMES* + +.. code-block:: console + + $ docker rm your_docker_NAMES + +2. Delete the docker image from IBM Cloud using its *IMAGE* name + +.. code-block:: console + + $ docker rmi registry.ng.bluemix.net/ros2nasr/ros2foxy:2 + +Step 4: Kubernetes +------------------- + +a) Creating the Cluster +^^^^^^^^^^^^^^^^^^^^^^^ + +Create a cluster using the Console. +The instructions are found `here `__. +The settings used are detailed below. +These are merely suggestions and can be changed if you need to. +However, make sure you understand the implications of your choices: + +1. Plan: *Standard* + +2. Orchestration Service: *Kubernetes v1.18.10* + +3. Infrastructure: *Classic* + +4. Location: + +- Resource group: *Default* + +- Geography: *North America* (you are free to change this) + +- Availability: *Single zone* + (you are free to change this but make sure you understand the impact of your choices by checking the IBM Cloud documentation.) + +- Worker Zone: *Toronto 01* (choose the location that is physically + closest to you) + +5. Worker Pool: + +- Virtual - shared, Ubuntu 18 + +- Memory: 16 GB + +- Worker nodes per zone: *1* + +6. Master service endpoint: *Both private & public endpoints* + +7. Resource details (Totally flexible): + +- Cluster name: *mycluster-tor01-rosibm* + +- Tags: *version:1* + +After you create your cluster, you will be redirected to a page which details how you can set up the CLI tools and access your cluster. +Please follow these instructions (or check the instructions `here `__) +and wait for the progress bar to show that the worker nodes you created are +ready by indicating *Normal* next to the cluster name. +You can also reach this screen from the IBM Cloud Console inside the Kubernetes. + +b) Deploying your Docker Image *Finally!* +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +1. Create a deployment configuration yaml file named + *ros2-deployment.yaml* using your favorite $EDITOR and insert the + following in it: + +.. code-block:: bash + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: + spec: + replicas: + selector: + matchLabels: + app: + template: + metadata: + labels: + app: + spec: + containers: + - name: + image: .icr.io//: + +You should replace the tags shown between *"<" ">"* as described +`here `__. +The file in my case would look something like this: + +.. code-block:: bash + + apiVersion: apps/v1 + kind: Deployment + metadata: + name: ros2-deployment + spec: + replicas: 1 + selector: + matchLabels: + app: ros2-ibmcloud + template: + metadata: + labels: + app: ros2-ibmcloud + spec: + containers: + - name: ros2-ibmcloud + image: us.icr.io/ros2nasr/ros2foxy:2 + +Deploy the file using the following command + +.. code-block:: console + + $ kubectl apply -f ros2-deployment.yaml + deployment.apps/ros2-deployment created + +Now your docker image is fully deployed on your cluster! + +Step 5: Using CLI for your Docker Image +--------------------------------------- + +1. Navigate to your cluster through the IBM Cloud console Kubernetes. + +2. Click on *Kubernetes dashboard* on the top right corner of the page. + +You should now be able to see a full list of all the different +parameters of your cluster as well as its CPU and Memory Usage. + +3. Navigate to *Pods* and click on your deployment. + +4. On the top right corner, click on *Exec into pod* + +Now you are inside your docker image! +You can source your workspace (if needed) and run ROS 2! +For example: + +.. code-block:: console + + root@ros2-deployment-xxxxxxxx:/opt/ros/overlay_ws# . install/setup.sh + root@ros2-deployment-xxxxxxxx:/opt/ros/overlay_ws# ros2 launch demo_nodes_cpp talker_listener_launch.py + +Final Remarks +--------------- + +At this point, you are capable of creating your own docker image using ROS 2 packages on github. +It is also possible, with little changes to utilize local ROS 2 packages as well. +This could be the topic of another article. +However, you are encouraged to check out the following `Dockerfile `__ which uses a local copy of the demos repository. +Similarly, you can use your own local package. \ No newline at end of file diff --git a/source/Integrations-and-related/Related-Projects.rst b/source/Integrations-and-related/Related-Projects.rst index 742dca97de4..177e85ed778 100644 --- a/source/Integrations-and-related/Related-Projects.rst +++ b/source/Integrations-and-related/Related-Projects.rst @@ -1,49 +1,53 @@ - -Related Projects -================ - -Gazebo ------- - -**Gazebo** `(gazebosim.org) `_ and its predecessor Gazebo Classic are the first open source choice for 3D physics simulation of ROS-based robots. - -Large Community Projects ------------------------- - -Large community projects involve multiple developers from all over the globe and are typically backed by a dedicated working group (cf. :doc:`The-ROS2-Project/Governance`). - -* **ros2_control** `(control.ros.org) `_: Flexible framework for real-time control of robots implemented with ROS 2. -* **Navigation2** `(nav2.org) `_: Comprehensive and flexible navigation stack for mobile robots using ROS 2. -* **MoveIt** `(moveit.ai) `_: A rich platform for building manipulation applications featuring advanced kinematics, motion planning, control, collision checking, and much more. -* **micro-ROS** `(micro.ros.org) `_: A platform for putting ROS 2 onto microcontrollers, starting at less than 100 kB of RAM. - -Community ``rosidl::Buffer`` backends -------------------------------------- - -Out-of-tree :doc:`buffer backend ` plugins let ``rosidl::Buffer`` fields (``uint8[]``, etc.) use vendor-specific memory domains such as GPU memory. -For background, see :doc:`How-To-Guides/Using-Buffer-Backends` and :doc:`Tutorials/Advanced/Writing-a-Buffer-Backend`. - -* **rosidl_buffer_backends** `(github.com/ros2/rosidl_buffer_backends) `_: CUDA buffer backend implementation for ``rosidl::Buffer`` plus ``tensor_msgs/msg/ExperimentalTensor`` and ``torch_conversions`` helpers, enabling zero-copy GPU memory sharing between ROS 2 publishers and subscribers. -* **rosidl_buffer_backends_tutorials** `(github.com/ros2/rosidl_buffer_backends_tutorials) `_: End-to-end demos exercising ``rosidl_buffer_backends``, including the ``robot_arm_demo`` featured in :doc:`Tutorials/Demos/GPU-Buffer-Transport`. - -Further Community Projects --------------------------- - -The global ROS community develops and maintains hundreds of further packages on top of the core ROS 2 stack. -Some of them come with their own websites for documentation. -Your best entry point to discover these works is the **ROS Index** `(index.ros.org) `_. - -*Hint for developers:* If you maintain a ``README.md`` file in the root of your package folder (which is not necessarily the root of your repository), this file is rendered into the overview page of your package at `index.ros.org `_. -The file may be used for documenting your package and supersedes the package documentation pages in the ROS Wiki from ROS 1. -See the `fmi_adapter package `_ as an example. - -Company-driven Projects ------------------------ - -.. toctree:: - :maxdepth: 1 - - Related-Projects/Intel-ROS2-Projects - Related-Projects/Nvidia-ROS2-Projects - Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge - Related-Projects/Visualizing-ROS-2-Data-With-Foxglove +.. redirect-from:: + + Related-Projects + + +Related Projects +================ + +Gazebo +------ + +**Gazebo** `(gazebosim.org) `_ and its predecessor Gazebo Classic are the first open source choice for 3D physics simulation of ROS-based robots. + +Large Community Projects +------------------------ + +Large community projects involve multiple developers from all over the globe and are typically backed by a dedicated working group (cf. :doc:`../The-ROS2-Project/Governance`). + +* **ros2_control** `(control.ros.org) `_: Flexible framework for real-time control of robots implemented with ROS 2. +* **Navigation2** `(nav2.org) `_: Comprehensive and flexible navigation stack for mobile robots using ROS 2. +* **MoveIt** `(moveit.ai) `_: A rich platform for building manipulation applications featuring advanced kinematics, motion planning, control, collision checking, and much more. +* **micro-ROS** `(micro.ros.org) `_: A platform for putting ROS 2 onto microcontrollers, starting at less than 100 kB of RAM. + +Community ``rosidl::Buffer`` backends +------------------------------------- + +Out-of-tree :doc:`buffer backend ` plugins let ``rosidl::Buffer`` fields (``uint8[]``, etc.) use vendor-specific memory domains such as GPU memory. +For background, see :doc:`How-To-Guides/Using-Buffer-Backends` and :doc:`Tutorials/Advanced/Writing-a-Buffer-Backend`. + +* **rosidl_buffer_backends** `(github.com/ros2/rosidl_buffer_backends) `_: CUDA buffer backend implementation for ``rosidl::Buffer`` plus ``tensor_msgs/msg/ExperimentalTensor`` and ``torch_conversions`` helpers, enabling zero-copy GPU memory sharing between ROS 2 publishers and subscribers. +* **rosidl_buffer_backends_tutorials** `(github.com/ros2/rosidl_buffer_backends_tutorials) `_: End-to-end demos exercising ``rosidl_buffer_backends``, including the ``robot_arm_demo`` featured in :doc:`Tutorials/Demos/GPU-Buffer-Transport`. + +Further Community Projects +-------------------------- + +The global ROS community develops and maintains hundreds of further packages on top of the core ROS 2 stack. +Some of them come with their own websites for documentation. +Your best entry point to discover these works is the **ROS Index** `(index.ros.org) `_. + +*Hint for developers:* If you maintain a ``README.md`` file in the root of your package folder (which is not necessarily the root of your repository), this file is rendered into the overview page of your package at `index.ros.org `_. +The file may be used for documenting your package and supersedes the package documentation pages in the ROS Wiki from ROS 1. +See the `fmi_adapter package `_ as an example. + +Company-driven Projects +----------------------- + +.. toctree:: + :maxdepth: 1 + + Related-Projects/Intel-ROS2-Projects + Related-Projects/Nvidia-ROS2-Projects + Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge + Related-Projects/Visualizing-ROS-2-Data-With-Foxglove \ No newline at end of file diff --git a/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst b/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst index bac7ae8ad6d..be48402d9ad 100644 --- a/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst +++ b/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst @@ -1,31 +1,32 @@ -.. redirect-from:: - - Intel-ROS2-Projects - -Intel ROS 2 Projects -==================== - -Intel® Robotics Open Source Project (Intel® ROS Project) to enable object detection/location/tracking, people detection, vehicle detection, industry robot arm grasp point analysis with kinds of Intel technologies and platforms, including CPU, GPU, `Intel® Movidius™ NCS `__ optimized deep learning backend, FPGA, `Intel® RealSense™ `__ camera, etc. - -Key Projects ------------- - -We are working on below ROS 2 projects and publish source code through https://github.com/intel/ or ROS 2 GitHub repo gradually. - -* `ROS2 OpenVINO `__: ROS 2 package for Intel® Visual Inference and Neural Network Optimization Toolkit to develop multiplatform computer vision solutions. -* `ROS2 RealSense Camera `__: ROS 2 package for Intel® RealSense™ D400 serial cameras -* `ROS2 Movidius NCS `__: ROS 2 package for object detection with Intel® Movidius™ Neural Computing Stick (NCS). -* `ROS2 Object Messages `__: ROS 2 messages for object. -* `ROS2 Object Analytics `__: ROS 2 package for object detection, tracking and 2D/3D localization. -* `ROS2 Message Filters `__: ROS 2 package for message synchronization with time stamp. -* `ROS2 CV Bridge `__: ROS 2 package to bridge with openCV. -* `ROS2 Object Map `__: ROS 2 package to mark tag of objects on map when SLAM based on information provided by ROS 2 object analytics. -* `ROS2 Moving Object `__: ROS 2 package to provide object motion information (like object velocity on x, y, z axis) based on information provided by ROS 2 object analytics. -* `ROS2 Grasp Library `__: ROS 2 package for grasp position analysis, and compatible with `MoveIt `__ grasp interfaces. -* `ROS2 Navigation `__: ROS 2 package for robot navigation, it's already integrated to ROS 2 Crystal release. -* `Intel Robot DevKit (SDK) `__: An open source project which enables developers to easily and efficiently create, customize, optimize, and deploy a robot software stack to an Autonomous Mobile Robot (AMR) platform based on the Robot Operating System 2 (ROS 2) framework. - -Reference ---------- - -ROS components at: https://wiki.ros.org/IntelROSProject shows the relationship among those packages, which also applies to ROS 2. +.. redirect-from:: + + Intel-ROS2-Projects + Related-Projects/Intel-ROS2-Projects + +Intel ROS 2 Projects +==================== + +Intel® Robotics Open Source Project (Intel® ROS Project) to enable object detection/location/tracking, people detection, vehicle detection, industry robot arm grasp point analysis with kinds of Intel technologies and platforms, including CPU, GPU, `Intel® Movidius™ NCS `__ optimized deep learning backend, FPGA, `Intel® RealSense™ `__ camera, etc. + +Key Projects +------------ + +We are working on below ROS 2 projects and publish source code through https://github.com/intel/ or ROS 2 GitHub repo gradually. + +* `ROS2 OpenVINO `__: ROS 2 package for Intel® Visual Inference and Neural Network Optimization Toolkit to develop multiplatform computer vision solutions. +* `ROS2 RealSense Camera `__: ROS 2 package for Intel® RealSense™ D400 serial cameras +* `ROS2 Movidius NCS `__: ROS 2 package for object detection with Intel® Movidius™ Neural Computing Stick (NCS). +* `ROS2 Object Messages `__: ROS 2 messages for object. +* `ROS2 Object Analytics `__: ROS 2 package for object detection, tracking and 2D/3D localization. +* `ROS2 Message Filters `__: ROS 2 package for message synchronization with time stamp. +* `ROS2 CV Bridge `__: ROS 2 package to bridge with openCV. +* `ROS2 Object Map `__: ROS 2 package to mark tag of objects on map when SLAM based on information provided by ROS 2 object analytics. +* `ROS2 Moving Object `__: ROS 2 package to provide object motion information (like object velocity on x, y, z axis) based on information provided by ROS 2 object analytics. +* `ROS2 Grasp Library `__: ROS 2 package for grasp position analysis, and compatible with `MoveIt `__ grasp interfaces. +* `ROS2 Navigation `__: ROS 2 package for robot navigation, it's already integrated to ROS 2 Crystal release. +* `Intel Robot DevKit (SDK) `__: An open source project which enables developers to easily and efficiently create, customize, optimize, and deploy a robot software stack to an Autonomous Mobile Robot (AMR) platform based on the Robot Operating System 2 (ROS 2) framework. + +Reference +--------- + +ROS components at: https://wiki.ros.org/IntelROSProject shows the relationship among those packages, which also applies to ROS 2. \ No newline at end of file diff --git a/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst b/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst index a3d1a8e75a6..25b86491248 100644 --- a/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst +++ b/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst @@ -1,36 +1,40 @@ -NVIDIA ROS 2 Projects -===================== - -NVIDIA Jetson is working towards developing ROS 2 packages to ease the development of AI applications for robotics. - - -ROS Projects ------------- -* `Isaac ROS Nvblox `__ : Hardware-accelerated 3D scene reconstruction and Nav2 local costmap provider using nvblox. -* `Isaac ROS Object Detection `__ : Deep learning model support for object detection including DetectNet. -* `Isaac ROS DNN Inference `__ : This repository provides two NVIDIA GPU-accelerated ROS 2 nodes that perform deep learning inference using custom models. - One node uses the TensorRT SDK, while the other uses the Triton SDK. -* `Isaac ROS Visual SLAM `__ : This repository provides a ROS 2 package that estimates stereo visual inertial odometry using the Isaac Elbrus GPU-accelerated library. -* `Isaac ROS Argus Camera `__ : This repository provides monocular and stereo nodes that enable ROS developers to use cameras connected to Jetson platforms over a CSI interface. -* `Isaac ROS image_pipeline `__ : This metapackage offers similar functionality as the standard, CPU-based image_pipeline metapackage, but does so by leveraging the Jetson platform's specialized computer vision hardware. -* `Isaac ROS Common `__ : Isaac ROS common utilities for use in conjunction with the Isaac ROS suite of packages. -* `Isaac ROS AprilTags `__ : ROS 2 node uses the NVIDIA GPU-accelerated AprilTags library to detect AprilTags in images and publish their poses, ids, and additional metadata. -* `ROS and ROS 2 Docker Images `__ : Docker images for easy deployment on the NVIDIA Jetson platform, consisting of ROS 2, PyTorch, and other important machine learning libraries. -* `ROS and ROS 2 DockerFiles `__: Dockerfiles for ROS 2 based on l4t which all you to build your own Docker image. -* `ROS 2 Packages for PyTorch and TensorRT `__: ROS 2 packageis for classification and object detection tasks using PyTorch and NVIDIA TensorRT. - This tutorial is a good starting point AI integration with ROS 2 on NVIDIA Jetson. -* `ROS / ROS 2 Packages for Accelerated Deep Learning Nodes `__: Deep learning image recognition, object detection, and semantic segmentation inference nodes and camera/video streaming nodes for ROS/ROS 2 using the `jetson-inference `__ library and `NVIDIA Hello AI World tutorial `__. -* `ROS 2 Package for Human Pose Estimation `__: A ROS 2 package for human pose estimation. -* `ROS 2 Package for Hand Pose Estimation and Gesture Classification `__: A ROS 2 package for real-time hand pose estimation and gesture classification using TensorRT. -* `GPU accelerated ROS 2 Packages for Monocular Depth Estimation `__: ROS 2 package for NVIDIA GPU-accelerated torch2trtxb examples such as monocular depth estimation and text detection. -* `ROS 2 Package for Jetson stats `__: ROS 2 package for monitoring and controlling your NVIDIA Jetson [Xavier NX, Nano, AGX Xavier, TX1, TX2]. -* `ROS 2 Packages for DeepStream SDK `__: ROS 2 package for NVIDIA DeepStream SDK. - -Simulation Projects -------------------- -* `Isaac Sim Nav2 `__ : In this ROS 2 sample, we are demonstrating Omniverse Isaac Sim integrated with the ROS 2 Nav2 project. -* `Isaac Sim Multiple Robot ROS 2 Navigation `__ : In this ROS 2 sample, we are demonstrating Omniverse Isaac Sim integrated with the ROS 2 Nav2 stack to perform simultaneous multiple robot navigation. - -References ----------- -More updates on NVIDIA Jetson ROS 2 can be found `here `__. +.. redirect-from:: + + Related-Projects/Nvidia-ROS2-Projects + +NVIDIA ROS 2 Projects +===================== + +NVIDIA Jetson is working towards developing ROS 2 packages to ease the development of AI applications for robotics. + + +ROS Projects +------------ +* `Isaac ROS Nvblox `__ : Hardware-accelerated 3D scene reconstruction and Nav2 local costmap provider using nvblox. +* `Isaac ROS Object Detection `__ : Deep learning model support for object detection including DetectNet. +* `Isaac ROS DNN Inference `__ : This repository provides two NVIDIA GPU-accelerated ROS 2 nodes that perform deep learning inference using custom models. + One node uses the TensorRT SDK, while the other uses the Triton SDK. +* `Isaac ROS Visual SLAM `__ : This repository provides a ROS 2 package that estimates stereo visual inertial odometry using the Isaac Elbrus GPU-accelerated library. +* `Isaac ROS Argus Camera `__ : This repository provides monocular and stereo nodes that enable ROS developers to use cameras connected to Jetson platforms over a CSI interface. +* `Isaac ROS image_pipeline `__ : This metapackage offers similar functionality as the standard, CPU-based image_pipeline metapackage, but does so by leveraging the Jetson platform's specialized computer vision hardware. +* `Isaac ROS Common `__ : Isaac ROS common utilities for use in conjunction with the Isaac ROS suite of packages. +* `Isaac ROS AprilTags `__ : ROS 2 node uses the NVIDIA GPU-accelerated AprilTags library to detect AprilTags in images and publish their poses, ids, and additional metadata. +* `ROS and ROS 2 Docker Images `__ : Docker images for easy deployment on the NVIDIA Jetson platform, consisting of ROS 2, PyTorch, and other important machine learning libraries. +* `ROS and ROS 2 DockerFiles `__: Dockerfiles for ROS 2 based on l4t which all you to build your own Docker image. +* `ROS 2 Packages for PyTorch and TensorRT `__: ROS 2 packageis for classification and object detection tasks using PyTorch and NVIDIA TensorRT. + This tutorial is a good starting point AI integration with ROS 2 on NVIDIA Jetson. +* `ROS / ROS 2 Packages for Accelerated Deep Learning Nodes `__: Deep learning image recognition, object detection, and semantic segmentation inference nodes and camera/video streaming nodes for ROS/ROS 2 using the `jetson-inference `__ library and `NVIDIA Hello AI World tutorial `__. +* `ROS 2 Package for Human Pose Estimation `__: A ROS 2 package for human pose estimation. +* `ROS 2 Package for Hand Pose Estimation and Gesture Classification `__: A ROS 2 package for real-time hand pose estimation and gesture classification using TensorRT. +* `GPU accelerated ROS 2 Packages for Monocular Depth Estimation `__: ROS 2 package for NVIDIA GPU-accelerated torch2trtxb examples such as monocular depth estimation and text detection. +* `ROS 2 Package for Jetson stats `__: ROS 2 package for monitoring and controlling your NVIDIA Jetson [Xavier NX, Nano, AGX Xavier, TX1, TX2]. +* `ROS 2 Packages for DeepStream SDK `__: ROS 2 package for NVIDIA DeepStream SDK. + +Simulation Projects +------------------- +* `Isaac Sim Nav2 `__ : In this ROS 2 sample, we are demonstrating Omniverse Isaac Sim integrated with the ROS 2 Nav2 project. +* `Isaac Sim Multiple Robot ROS 2 Navigation `__ : In this ROS 2 sample, we are demonstrating Omniverse Isaac Sim integrated with the ROS 2 Nav2 stack to perform simultaneous multiple robot navigation. + +References +---------- +More updates on NVIDIA Jetson ROS 2 can be found `here `__. \ No newline at end of file diff --git a/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst b/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst index fa8235cd855..8b86bd6c9e4 100644 --- a/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst +++ b/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst @@ -1,10 +1,14 @@ -Visualizing Data and Teleoperating with Phantom Bridge -====================================================== - -Redirecting to `https://docs.phntm.io/bridge `_... - -.. raw:: html - - +.. redirect-from:: + + Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge + +Visualizing Data and Teleoperating with Phantom Bridge +====================================================== + +Redirecting to `https://docs.phntm.io/bridge `_... + +.. raw:: html + + \ No newline at end of file diff --git a/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst b/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst index f846b8ea23a..da8eba9505f 100644 --- a/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst +++ b/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst @@ -1,225 +1,226 @@ -.. redirect-from:: - - Visualizing-ROS-2-Data-With-Foxglove-Studio - -Visualizing ROS 2 data with Foxglove -==================================== - -`Foxglove `__ is a visualization and observability tool for robotics developers. -It's available in the browser or as a standalone desktop app and is free for individual, small team, and academic use. - -Installation ------------- - -To use Foxglove, you'll need to `create an account `__. -It's free and all you need is a valid email address. - -Once you've created an account, you can use Foxglove on the web by opening Google Chrome and navigating to `app.foxglove.dev `__. - -To use the desktop app for Linux, macOS, or Windows, download it directly from the `Foxglove website `__. - -.. note:: - - Foxglove uses specific features of Google Chrome. - While some features may work, other browsers are not supported. - For the best experience, we recommend using Chrome or the desktop app. - -Connect to a live data source ------------------------------ - -To connect to a live ROS 2 stack, you will need to `install the Foxglove ROS 2 bridge `__ with: - -.. code-block:: console - - $ sudo apt install ros-$ROS_DISTRO-foxglove-bridge - -Once you have the bridge installed, launch it with: - -.. code-block:: console - - $ ros2 launch foxglove_bridge foxglove_bridge_launch.xml - -With the bridge running on your robot, you're ready to connect view data in Foxglove. -Make sure you are on the same network as your robot, open Foxglove (web or desktop) and click "Open connection". - -Select the option for "Foxglove WebSocket" and enter your robot's WebSocket URL. -The default is ``ws://localhost:8765``, however you can read about configuration options for the ROS Foxglove bridge `here `__. - -.. note:: - - Foxglove can also connect using rosbridge, however for performance and stability reasons we recommend using the Foxglove bridge. - -View and replay recorded data ------------------------------ - -If you'd rather visualize recorded data, you can use Foxglove to replay ROS 2 ``.mcap`` as well as older ROS 2 ``.db3``, and ROS 1 ``.bag`` files. -Foxglove is particularly convenient for recorded data because it does not require ROS 2 to be running to view data. - -Use the :doc:`ros2 bag command line tool <../Tutorials/Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` to record data from your robot to a ``.mcap`` file: - -.. code-block:: console - - $ ros2 bag record -a - -From the Foxglove dashboard or menu, select "Open local file" and navigate to your recorded ``.mcap`` file. - -See the Foxglove documentation for `more information about the types of data sources you can use with it `__. - -Building layouts with panels ----------------------------- - -`Panels `__ allow you to visualize different specific types of data such as logs, maps, plots, and 3D information. -You can arrange panels by dragging and dropping them into Foxglove `layouts `__ to view multiple types of data simultaneously. - -You can also save layouts for future use, or to share with your team. - -Find the full list of available panels by clicking the "Add panel" icon in the upper left of the menu bar. - -We've highlighted some particularly useful ones below: - -3D panel: View 3D data and visualization markers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Open the panel settings by clicking the gear icon in the upper right. -Choose the topics you want to display via the topic picker on the left, and configure each topic's visualization settings in the "Edit topic settings" menu. - -Publish marker messages to add primitive shapes (arrows, spheres, etc.) and more complex visualizations (occupancy grids, point clouds, etc.) to your 3D panel's scene. - -.. image:: foxglove/3d.png - :width: 500 px - :alt: Foxglove's 3D panel - -Reference the `docs `__ for a full list of `supported message types `__ and some useful `user interactions `__. - -Diagnostics panel: View and filter diagnostics messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Display the status of seen nodes (i.e. stale, error, warn, or OK) from topics with a ``diagnostic_msgs/msg/DiagnosticArray`` datatype in a running feed, and display the diagnostics data for a given ``diagnostic_name/hardware_id``. - -.. image:: foxglove/diagnostics.png - :width: 500 px - :alt: Foxglove's Diagnostics panel - -Reference the `docs `__ for more details. - -Image panel: View camera feed images -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Display raw and compressed images, as well as compressed videos, with 2D annotations like text labels, circles, and points. -Superimpose 3D markers for additional context. - -.. image:: foxglove/image.png - :width: 500 px - :alt: Foxglove's Image panel - -Reference the `docs `__ for more details. - -Log panel: View log messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To view ``rcl_interfaces/msg/Log`` messages live, use the desktop app to `connect `__ to your running ROS stack. -To view ``rcl_interfaces/msg/Log`` messages from a pre-recorded data file, you can drag-and-drop your file into either the `web `__ or desktop app. - -Next, add a `Log `__ panel to your layout. -If you've connected to your ROS stack correctly, you should now see a list of your log messages, with the ability to filter them by node name or severity level. - -Reference the `docs `__ for more details. - -Plot panel: Plot arbitrary values over time -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Plot arbitrary numeric values from topic `message paths `__ . - -When playing back local or remote data files, this panel will preload the data belonging to the specified topic message paths for the whole playback timeline. -Current playback time is indicated by a vertical gray bar. - -.. image:: foxglove/plot.png - :width: 500 px - :alt: Foxglove's Plot panel - -Reference the `docs `__ for more details. - -Raw Messages panel: View incoming topic messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Inspect a particular `message path `__ in your data source. - -As new messages are received for a given path, the collapsible tree will show just the latest message. -You will be able to expand and collapse keys, and have those changes persist across playback. - -.. image:: foxglove/raw-messages.png - :width: 500 px - :alt: Foxglove's Raw Messages panel - -Reference the `docs `__ for more details. - -Teleop panel: Teleoperate your robot -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Teleoperate your physical robot by publishing ``geometry_msgs/msg/Twist`` messages on a given topic back to your live ROS stack. - -.. image:: foxglove/teleop.png - :width: 300 px - :alt: Foxglove's URDF Viewer panel - -Reference the `docs `__ for more details. - -Visualize URDFs: View and manipulate your URDF model -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Foxglove's `3D panel supports displaying Unified Robotics Description Format (URDF) models `__ in the context of your robots' world. - -To visualize and control your robot model in Foxglove, open the web or desktop application and add a 3D panel to your layout. - -Add as many URDF models as you want as custom layers in the 3D panel, using HTTP/HTTPS URLs (web and desktop) or ``file://`` and ``package://``-prefixed URLs (desktop only). - -In addition to these URLs, the 3D panel can also display URDFs from a ``/robot_description`` topic. - -Once added to the 3D panel, the URDF file will populate the transform tree with frames and transforms based on the model's links and joints. - -It's important to note that Foxglove uses different defaults from RViz—if your meshes are not displaying properly, you may want to adjust the "Ignore COLLADA "" (for DAE meshes) and "Mesh up axis" (for STL and OBJ meshes) options in the panel settings' 'Scene' section. - -You can update this tree by publishing transform messages to move the URDF model's joints positions—if you've used JointState messages before, you can use a robot_state_publisher node to transform them into TF messages at runtime. - -You can also control your model's joints manually via the panel settings interface. - -.. image:: foxglove/urdf.png - :width: 500 px - :alt: Foxglove's URDF Viewer panel with editable joint positions - -Reference the `docs `__ for more details. - -Other basic actions -------------------- - -View your ROS topic graph -^^^^^^^^^^^^^^^^^^^^^^^^^ - -`Using the desktop app `__, `connect `__ to your running ROS stack. -Next, add a `Topic Graph `__ panel to your layout. -If you've connected to your ROS stack correctly, you should now see a computational graph of your ROS nodes, topics, and services in that panel. -Use the controls on the right side of the panel to select which topics to display or to toggle services. - -View and edit your ROS params -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -`Using the desktop app `__, `connect `__ to your running ROS stack. -Next, add a `Parameters `__ panel to your layout. -If you've connected to your ROS stack correctly, you should now see a live view of your current ``rosparams``. -You can edit these parameter values to publish ``rosparam`` updates back to your ROS stack. - -Publish messages back to your live ROS stack -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -`Using the desktop app `__, `connect `__ to your running ROS stack. -Next, add a `Publish `__ panel to your layout. - -Specify the topic you want to publish on to infer its datatype and populate the text field with a JSON message template. - -Selecting a datatype in the dropdown of common ROS datatypes will also populate the text field with a JSON message template. - -Edit the template to customize your message before hitting "Publish". - -.. image:: foxglove/publish.png - :width: 300 px - :alt: Foxglove's Publish panel +.. redirect-from:: + + Visualizing-ROS-2-Data-With-Foxglove-Studio + Related-Projects/Visualizing-ROS-2-Data-With-Foxglove + +Visualizing ROS 2 data with Foxglove +==================================== + +`Foxglove `__ is a visualization and observability tool for robotics developers. +It's available in the browser or as a standalone desktop app and is free for individual, small team, and academic use. + +Installation +------------ + +To use Foxglove, you'll need to `create an account `__. +It's free and all you need is a valid email address. + +Once you've created an account, you can use Foxglove on the web by opening Google Chrome and navigating to `app.foxglove.dev `__. + +To use the desktop app for Linux, macOS, or Windows, download it directly from the `Foxglove website `__. + +.. note:: + + Foxglove uses specific features of Google Chrome. + While some features may work, other browsers are not supported. + For the best experience, we recommend using Chrome or the desktop app. + +Connect to a live data source +----------------------------- + +To connect to a live ROS 2 stack, you will need to `install the Foxglove ROS 2 bridge `__ with: + +.. code-block:: console + + $ sudo apt install ros-$ROS_DISTRO-foxglove-bridge + +Once you have the bridge installed, launch it with: + +.. code-block:: console + + $ ros2 launch foxglove_bridge foxglove_bridge_launch.xml + +With the bridge running on your robot, you're ready to connect view data in Foxglove. +Make sure you are on the same network as your robot, open Foxglove (web or desktop) and click "Open connection". + +Select the option for "Foxglove WebSocket" and enter your robot's WebSocket URL. +The default is ``ws://localhost:8765``, however you can read about configuration options for the ROS Foxglove bridge `here `__. + +.. note:: + + Foxglove can also connect using rosbridge, however for performance and stability reasons we recommend using the Foxglove bridge. + +View and replay recorded data +----------------------------- + +If you'd rather visualize recorded data, you can use Foxglove to replay ROS 2 ``.mcap`` as well as older ROS 2 ``.db3``, and ROS 1 ``.bag`` files. +Foxglove is particularly convenient for recorded data because it does not require ROS 2 to be running to view data. + +Use the :doc:`ros2 bag command line tool <../../ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` to record data from your robot to a ``.mcap`` file: + +.. code-block:: console + + $ ros2 bag record -a + +From the Foxglove dashboard or menu, select "Open local file" and navigate to your recorded ``.mcap`` file. + +See the Foxglove documentation for `more information about the types of data sources you can use with it `__. + +Building layouts with panels +---------------------------- + +`Panels `__ allow you to visualize different specific types of data such as logs, maps, plots, and 3D information. +You can arrange panels by dragging and dropping them into Foxglove `layouts `__ to view multiple types of data simultaneously. + +You can also save layouts for future use, or to share with your team. + +Find the full list of available panels by clicking the "Add panel" icon in the upper left of the menu bar. + +We've highlighted some particularly useful ones below: + +3D panel: View 3D data and visualization markers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Open the panel settings by clicking the gear icon in the upper right. +Choose the topics you want to display via the topic picker on the left, and configure each topic's visualization settings in the "Edit topic settings" menu. + +Publish marker messages to add primitive shapes (arrows, spheres, etc.) and more complex visualizations (occupancy grids, point clouds, etc.) to your 3D panel's scene. + +.. image:: foxglove/3d.png + :width: 500 px + :alt: Foxglove's 3D panel + +Reference the `docs `__ for a full list of `supported message types `__ and some useful `user interactions `__. + +Diagnostics panel: View and filter diagnostics messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Display the status of seen nodes (i.e. stale, error, warn, or OK) from topics with a ``diagnostic_msgs/msg/DiagnosticArray`` datatype in a running feed, and display the diagnostics data for a given ``diagnostic_name/hardware_id``. + +.. image:: foxglove/diagnostics.png + :width: 500 px + :alt: Foxglove's Diagnostics panel + +Reference the `docs `__ for more details. + +Image panel: View camera feed images +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Display raw and compressed images, as well as compressed videos, with 2D annotations like text labels, circles, and points. +Superimpose 3D markers for additional context. + +.. image:: foxglove/image.png + :width: 500 px + :alt: Foxglove's Image panel + +Reference the `docs `__ for more details. + +Log panel: View log messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To view ``rcl_interfaces/msg/Log`` messages live, use the desktop app to `connect `__ to your running ROS stack. +To view ``rcl_interfaces/msg/Log`` messages from a pre-recorded data file, you can drag-and-drop your file into either the `web `__ or desktop app. + +Next, add a `Log `__ panel to your layout. +If you've connected to your ROS stack correctly, you should now see a list of your log messages, with the ability to filter them by node name or severity level. + +Reference the `docs `__ for more details. + +Plot panel: Plot arbitrary values over time +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Plot arbitrary numeric values from topic `message paths `__ . + +When playing back local or remote data files, this panel will preload the data belonging to the specified topic message paths for the whole playback timeline. +Current playback time is indicated by a vertical gray bar. + +.. image:: foxglove/plot.png + :width: 500 px + :alt: Foxglove's Plot panel + +Reference the `docs `__ for more details. + +Raw Messages panel: View incoming topic messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Inspect a particular `message path `__ in your data source. + +As new messages are received for a given path, the collapsible tree will show just the latest message. +You will be able to expand and collapse keys, and have those changes persist across playback. + +.. image:: foxglove/raw-messages.png + :width: 500 px + :alt: Foxglove's Raw Messages panel + +Reference the `docs `__ for more details. + +Teleop panel: Teleoperate your robot +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Teleoperate your physical robot by publishing ``geometry_msgs/msg/Twist`` messages on a given topic back to your live ROS stack. + +.. image:: foxglove/teleop.png + :width: 300 px + :alt: Foxglove's URDF Viewer panel + +Reference the `docs `__ for more details. + +Visualize URDFs: View and manipulate your URDF model +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Foxglove's `3D panel supports displaying Unified Robotics Description Format (URDF) models `__ in the context of your robots' world. + +To visualize and control your robot model in Foxglove, open the web or desktop application and add a 3D panel to your layout. + +Add as many URDF models as you want as custom layers in the 3D panel, using HTTP/HTTPS URLs (web and desktop) or ``file://`` and ``package://``-prefixed URLs (desktop only). + +In addition to these URLs, the 3D panel can also display URDFs from a ``/robot_description`` topic. + +Once added to the 3D panel, the URDF file will populate the transform tree with frames and transforms based on the model's links and joints. + +It's important to note that Foxglove uses different defaults from RViz—if your meshes are not displaying properly, you may want to adjust the "Ignore COLLADA "" (for DAE meshes) and "Mesh up axis" (for STL and OBJ meshes) options in the panel settings' 'Scene' section. + +You can update this tree by publishing transform messages to move the URDF model's joints positions—if you've used JointState messages before, you can use a robot_state_publisher node to transform them into TF messages at runtime. + +You can also control your model's joints manually via the panel settings interface. + +.. image:: foxglove/urdf.png + :width: 500 px + :alt: Foxglove's URDF Viewer panel with editable joint positions + +Reference the `docs `__ for more details. + +Other basic actions +------------------- + +View your ROS topic graph +^^^^^^^^^^^^^^^^^^^^^^^^^ + +`Using the desktop app `__, `connect `__ to your running ROS stack. +Next, add a `Topic Graph `__ panel to your layout. +If you've connected to your ROS stack correctly, you should now see a computational graph of your ROS nodes, topics, and services in that panel. +Use the controls on the right side of the panel to select which topics to display or to toggle services. + +View and edit your ROS params +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +`Using the desktop app `__, `connect `__ to your running ROS stack. +Next, add a `Parameters `__ panel to your layout. +If you've connected to your ROS stack correctly, you should now see a live view of your current ``rosparams``. +You can edit these parameter values to publish ``rosparam`` updates back to your ROS stack. + +Publish messages back to your live ROS stack +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +`Using the desktop app `__, `connect `__ to your running ROS stack. +Next, add a `Publish `__ panel to your layout. + +Specify the topic you want to publish on to infer its datatype and populate the text field with a JSON message template. + +Selecting a datatype in the dropdown of common ROS datatypes will also populate the text field with a JSON message template. + +Edit the template to customize your message before hitting "Publish". + +.. image:: foxglove/publish.png + :width: 300 px + :alt: Foxglove's Publish panel \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst b/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst index 4b36985e539..1e2ef8a6dcc 100644 --- a/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst +++ b/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst @@ -1,65 +1,66 @@ -.. redirect-from:: - - Tutorials/Simulators/Ignition/Setting-up-a-Robot-Simulation-Ignition - Tutorials/Advanced/Simulators/Ignition - Tutorials/Advanced/Simulators/Gazebo - -Setting up a robot simulation (Gazebo) -====================================== - -**Goal:** Launch a Simulation with Gazebo and ROS 2 - -**Tutorial level:** Advanced - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -.. note:: - - These instructions are about the current `Gazebo `__ (previously known as Ignition), not `Gazebo Classic `__. - -Prerequisites -------------- - -You'll need to install both ROS 2 and Gazebo. - -ROS 2 -^^^^^ - -For ROS 2 you should follow the :doc:`ROS 2 install instructions <../../../../Installation>`. - -Gazebo -^^^^^^ - -Gazebo and ROS support different combinations of versions. - -All supported combinations can be seen `here `__. - -`ROS REP-2000 `__ standardizes what the default version of Gazebo is for each ROS distribution. - -If you haven't installed a version of Gazebo on your system yet, you can install Gazebo by following the `installation instructions `__. - -Quick Check ------------ - -To verify your Gazebo installation is correct, check you can run it: - -.. code-block:: console - - $ gz sim - -Further Resources ------------------ - -Once Gazebo is installed and is all clear on the last quick test, you can move to the `Gazebo tutorials `__ to try out building your own robot! - -If you use a different version of Gazebo than the recommended version, make sure to use the dropdown to select the correct version of documentation. - -Summary -------- - -In this tutorial, you have installed Gazebo and set-up your workspace to start with the `Gazebo tutorials `__. +.. redirect-from:: + + Tutorials/Simulators/Ignition/Setting-up-a-Robot-Simulation-Ignition + Tutorials/Advanced/Simulators/Ignition + Tutorials/Advanced/Simulators/Gazebo + Tutorials/Advanced/Simulators/Gazebo/Gazebo + +Setting up a robot simulation (Gazebo) +====================================== + +**Goal:** Launch a Simulation with Gazebo and ROS 2 + +**Tutorial level:** Advanced + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +.. note:: + + These instructions are about the current `Gazebo `__ (previously known as Ignition), not `Gazebo Classic `__. + +Prerequisites +------------- + +You'll need to install both ROS 2 and Gazebo. + +ROS 2 +^^^^^ + +For ROS 2 you should follow the :doc:`ROS 2 install instructions <../../../Get-Started/Installation>`. + +Gazebo +^^^^^^ + +Gazebo and ROS support different combinations of versions. + +All supported combinations can be seen `here `__. + +`ROS REP-2000 `__ standardizes what the default version of Gazebo is for each ROS distribution. + +If you haven't installed a version of Gazebo on your system yet, you can install Gazebo by following the `installation instructions `__. + +Quick Check +----------- + +To verify your Gazebo installation is correct, check you can run it: + +.. code-block:: console + + $ gz sim + +Further Resources +----------------- + +Once Gazebo is installed and is all clear on the last quick test, you can move to the `Gazebo tutorials `__ to try out building your own robot! + +If you use a different version of Gazebo than the recommended version, make sure to use the dropdown to select the correct version of documentation. + +Summary +------- + +In this tutorial, you have installed Gazebo and set-up your workspace to start with the `Gazebo tutorials `__. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst b/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst index 2b31880dd62..a881050252e 100644 --- a/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst +++ b/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst @@ -1,13 +1,17 @@ -Gazebo -====== - -This set of tutorials will teach you how to configure the Gazebo simulator with ROS 2. - -.. contents:: Contents - :depth: 2 - :local: - -.. toctree:: - :maxdepth: 1 - - Gazebo +.. redirect-from:: + + Tutorials/Advanced/Simulators/Gazebo/Simulation-Gazebo + +Gazebo +====== + +This set of tutorials will teach you how to configure the Gazebo simulator with ROS 2. + +.. contents:: Contents + :depth: 2 + :local: + +.. toctree:: + :maxdepth: 1 + + Gazebo \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst index 7845df49bc4..c4085145faf 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst @@ -1,342 +1,346 @@ -Defining worlds, robots, and sensors -===================================== - -**Goal:** Learn the basics of defining MVSim world files, adding vehicles and sensors, and the main features available. - -**Tutorial level:** Advanced - -**Time:** 30 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -MVSim worlds are defined in XML files (``.world.xml``). -A world file describes the environment (ground, walls, obstacles), the vehicles (dynamics model, shape, sensors), -and simulation parameters (physics timestep, GUI options). - -MVSim provides a library of predefined vehicle and sensor definitions that you can reuse in your worlds via XML includes. -You can also define everything from scratch for full control. - -Prerequisites -------------- - -You should have completed the :doc:`Getting-Started-MVSim` tutorial and have MVSim installed. - -Tasks ------ - -1 Minimal world file -^^^^^^^^^^^^^^^^^^^^^^ - -Here is a minimal world file that creates an empty environment with one robot: - -.. code-block:: xml - - - - 5e-3 - - - - 15 - - - - - - - - - 0 0 0 - - - - - - - - - - - - - - - 4.1543 - 1.9118 - 0.0000 - 14.44 - 0.00 - - - - - - 100 5 50 - - - - -Save this as ``my_world.world.xml`` and launch it: - -.. code-block:: console - - $ mvsim launch my_world.world.xml - -2 Using predefined vehicles and sensors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Instead of defining vehicles from scratch, you can use the predefined definitions that ship with MVSim. -These are XML files in the ``definitions/`` directory of the MVSim package. - -**Available vehicles:** - -- ``turtlebot3_burger.vehicle.xml`` -- TurtleBot3 Burger (differential drive) -- ``jackal.vehicle.xml`` -- Clearpath Jackal UGV (4-wheel differential) -- ``ackermann.vehicle.xml`` -- Generic Ackermann (car-like) vehicle -- ``pickup.vehicle.xml`` -- Pickup truck (Ackermann) -- ``agricobiot2.vehicle.xml`` -- Agricultural robot (Ackermann drivetrain) - -**Available sensors:** - -- ``lidar2d.sensor.xml`` -- Generic 2D laser scanner -- ``rplidar-a2.sensor.xml`` -- RPLidar A2 -- ``velodyne-vlp16.sensor.xml`` -- Velodyne VLP-16 3D LiDAR -- ``ouster-os1.sensor.xml`` -- Ouster OS1 3D LiDAR -- ``helios-32-FOV-70.sensor.xml`` -- Helios 32-beam 3D LiDAR -- ``camera.sensor.xml`` -- RGB camera -- ``rgbd_camera.sensor.xml`` -- Depth camera (RGBD) -- ``imu.sensor.xml`` -- Inertial measurement unit -- ``gnss.sensor.xml`` -- GPS/GNSS receiver - -To use a predefined vehicle with sensors attached, use XML includes: - -.. code-block:: xml - - - 5e-3 - - - 15 - - - - - - - - - - 0 0 170 - 0 0 0 - - - - - - - - - - -10 -10 - -10 10 - 0.0 3.0 - NONE - https://mrpt.github.io/mvsim-models/textures-cgbookcase/wall-bricks-01.png - 2.5 - 2.5 - ${WALL_THICKNESS} - - - - 0.5 - 1.2 - 0.0 - 2.1 - main_entrance - - - - - - -3 World environment elements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -MVSim supports several types of environment elements: - -**Occupancy grid maps** load a grayscale image as a 2D obstacle map, commonly used for indoor navigation testing: - -.. code-block:: xml - - - map.png - 0.05 - - -**Elevation maps** define terrain height from a grayscale heightmap image, useful for outdoor scenarios: - -.. code-block:: xml - - - 1.0 - terrain.png - 0.0 - 5.0 - - -**Textured planes** add visual ground surfaces: - -.. code-block:: xml - - - BACK - -25 25 - -25 25 - 0.0 - asphalt.png - 5.0 - 5.0 - - -**Blocks** are static or dynamic rigid bodies (boxes, custom shapes) that serve as obstacles or manipulable objects: - -.. code-block:: xml - - - - - package://mvsim/models/box.dae - - 3.0 2.0 0 - 20 - - -4 Vehicle dynamics models -^^^^^^^^^^^^^^^^^^^^^^^^^ - -MVSim provides three main dynamics models: - -- **Differential drive** (``class="differential"``): Two-wheeled robots like TurtleBot3. - Controlled via linear and angular velocity. - -- **Ackermann** (``class="ackermann"``): Car-like vehicles with front-wheel steering. - Controlled via linear velocity and steering angle. - -- **Ackermann drivetrain** (``class="ackermann_drivetrain"``): Realistic drivetrain model with - open or Torsen differentials, useful for more accurate vehicle behavior simulation. - -Each vehicle can use different motor controllers: - -- ``twist_pid``: Accepts ``geometry_msgs/msg/Twist`` commands with PID velocity tracking. - This is the most common choice for ROS 2 integration. -- ``twist_ideal``: Instantaneous velocity commands (no dynamics delay). -- ``twist_front_steer_pid``: For Ackermann vehicles controlled via linear velocity and steering angle. -- ``raw``: Direct wheel torque control. - -5 Sensor noise and configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sensors in MVSim support configurable noise models. -For example, an IMU sensor with noise parameters: - -.. code-block:: xml - - - 0 0 0.5 0 0 0 - 100 - - - - 1e-3 - 1e-4 - 1e-6 - - - - - 1e-2 - 1e-3 - 1e-5 - - - -LiDAR sensors support parameters for range, angular resolution, and noise: - -.. code-block:: xml - - - 0.15 0 0.3 0 0 0 - 10 - 360 - 360 - 20.0 - 0.01 - true - - -6 Additional features -^^^^^^^^^^^^^^^^^^^^^^ - -**Multi-robot simulation:** -MVSim natively supports multiple vehicles in the same world. -Each vehicle gets its own ROS 2 namespace, TF tree, and set of topics. -Robots can detect each other with their sensors and physically interact through collisions. - -**Property regions:** -You can define regions in the world with different physical properties, such as varying friction coefficients -or GPS-denied zones where GNSS sensors stop reporting positions. - -**Animated actors:** -MVSim supports skeletal-animated 3D characters (e.g., pedestrians) that follow waypoint paths, -useful for testing perception and planning in dynamic environments. - -**Joints and articulated vehicles:** -Vehicles can be connected using distance joints (ropes/cables) or revolute joints (hinges), -enabling simulation of trailers, tow ropes, and articulated systems. - -**XML advanced features:** -World files support ```` directives, variable substitution, mathematical expressions, -```` loops, and ```` conditionals, making it possible to procedurally generate complex environments. - -**Headless and faster-than-real-time:** -MVSim can run without a GUI and at configurable simulation speed, -which is useful for automated testing and reinforcement learning workflows. - -Comparison with other simulators --------------------------------- - -MVSim occupies a different niche compared to other simulators: - -**Strengths:** - -- Very lightweight: low CPU and memory usage, fast startup times. -- Focused vehicle dynamics with multiple friction and drivetrain models. -- Simple XML-based world format, easy to get started. -- Native multi-robot support with per-vehicle ROS 2 namespaces. -- Faster-than-real-time simulation for batch testing. -- Procedural world generation via XML loops and conditionals. - -**Limitations:** - -- Physics is 2D (Box2D): no full 3D rigid body dynamics. - Objects do not tip over or fly. - Elevation maps add terrain height but the physics remains fundamentally 2D. -- Sensor simulation is less detailed than full 3D simulators: camera rendering and LiDAR models - are functional but not photorealistic. -- Smaller ecosystem of pre-built models and environments compared to Gazebo. -- Focused on wheeled mobile robots. - -Further resources ------------------ - -- `MVSim documentation `__ -- `MVSim GitHub repository `__ -- `MVSim paper (SoftwareX) `__ +.. redirect-from:: + + Tutorials/Advanced/Simulators/MVSim/Defining-Worlds-MVSim + +Defining worlds, robots, and sensors +===================================== + +**Goal:** Learn the basics of defining MVSim world files, adding vehicles and sensors, and the main features available. + +**Tutorial level:** Advanced + +**Time:** 30 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +MVSim worlds are defined in XML files (``.world.xml``). +A world file describes the environment (ground, walls, obstacles), the vehicles (dynamics model, shape, sensors), +and simulation parameters (physics timestep, GUI options). + +MVSim provides a library of predefined vehicle and sensor definitions that you can reuse in your worlds via XML includes. +You can also define everything from scratch for full control. + +Prerequisites +------------- + +You should have completed the :doc:`Getting-Started-MVSim` tutorial and have MVSim installed. + +Tasks +----- + +1 Minimal world file +^^^^^^^^^^^^^^^^^^^^^^ + +Here is a minimal world file that creates an empty environment with one robot: + +.. code-block:: xml + + + + 5e-3 + + + + 15 + + + + + + + + + 0 0 0 + + + + + + + + + + + + + + + 4.1543 + 1.9118 + 0.0000 + 14.44 + 0.00 + + + + + + 100 5 50 + + + + +Save this as ``my_world.world.xml`` and launch it: + +.. code-block:: console + + $ mvsim launch my_world.world.xml + +2 Using predefined vehicles and sensors +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Instead of defining vehicles from scratch, you can use the predefined definitions that ship with MVSim. +These are XML files in the ``definitions/`` directory of the MVSim package. + +**Available vehicles:** + +- ``turtlebot3_burger.vehicle.xml`` -- TurtleBot3 Burger (differential drive) +- ``jackal.vehicle.xml`` -- Clearpath Jackal UGV (4-wheel differential) +- ``ackermann.vehicle.xml`` -- Generic Ackermann (car-like) vehicle +- ``pickup.vehicle.xml`` -- Pickup truck (Ackermann) +- ``agricobiot2.vehicle.xml`` -- Agricultural robot (Ackermann drivetrain) + +**Available sensors:** + +- ``lidar2d.sensor.xml`` -- Generic 2D laser scanner +- ``rplidar-a2.sensor.xml`` -- RPLidar A2 +- ``velodyne-vlp16.sensor.xml`` -- Velodyne VLP-16 3D LiDAR +- ``ouster-os1.sensor.xml`` -- Ouster OS1 3D LiDAR +- ``helios-32-FOV-70.sensor.xml`` -- Helios 32-beam 3D LiDAR +- ``camera.sensor.xml`` -- RGB camera +- ``rgbd_camera.sensor.xml`` -- Depth camera (RGBD) +- ``imu.sensor.xml`` -- Inertial measurement unit +- ``gnss.sensor.xml`` -- GPS/GNSS receiver + +To use a predefined vehicle with sensors attached, use XML includes: + +.. code-block:: xml + + + 5e-3 + + + 15 + + + + + + + + + + 0 0 170 + 0 0 0 + + + + + + + + + + -10 -10 + -10 10 + 0.0 3.0 + NONE + https://mrpt.github.io/mvsim-models/textures-cgbookcase/wall-bricks-01.png + 2.5 + 2.5 + ${WALL_THICKNESS} + + + + 0.5 + 1.2 + 0.0 + 2.1 + main_entrance + + + + + + +3 World environment elements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +MVSim supports several types of environment elements: + +**Occupancy grid maps** load a grayscale image as a 2D obstacle map, commonly used for indoor navigation testing: + +.. code-block:: xml + + + map.png + 0.05 + + +**Elevation maps** define terrain height from a grayscale heightmap image, useful for outdoor scenarios: + +.. code-block:: xml + + + 1.0 + terrain.png + 0.0 + 5.0 + + +**Textured planes** add visual ground surfaces: + +.. code-block:: xml + + + BACK + -25 25 + -25 25 + 0.0 + asphalt.png + 5.0 + 5.0 + + +**Blocks** are static or dynamic rigid bodies (boxes, custom shapes) that serve as obstacles or manipulable objects: + +.. code-block:: xml + + + + + package://mvsim/models/box.dae + + 3.0 2.0 0 + 20 + + +4 Vehicle dynamics models +^^^^^^^^^^^^^^^^^^^^^^^^^ + +MVSim provides three main dynamics models: + +- **Differential drive** (``class="differential"``): Two-wheeled robots like TurtleBot3. + Controlled via linear and angular velocity. + +- **Ackermann** (``class="ackermann"``): Car-like vehicles with front-wheel steering. + Controlled via linear velocity and steering angle. + +- **Ackermann drivetrain** (``class="ackermann_drivetrain"``): Realistic drivetrain model with + open or Torsen differentials, useful for more accurate vehicle behavior simulation. + +Each vehicle can use different motor controllers: + +- ``twist_pid``: Accepts ``geometry_msgs/msg/Twist`` commands with PID velocity tracking. + This is the most common choice for ROS 2 integration. +- ``twist_ideal``: Instantaneous velocity commands (no dynamics delay). +- ``twist_front_steer_pid``: For Ackermann vehicles controlled via linear velocity and steering angle. +- ``raw``: Direct wheel torque control. + +5 Sensor noise and configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sensors in MVSim support configurable noise models. +For example, an IMU sensor with noise parameters: + +.. code-block:: xml + + + 0 0 0.5 0 0 0 + 100 + + + + 1e-3 + 1e-4 + 1e-6 + + + + + 1e-2 + 1e-3 + 1e-5 + + + +LiDAR sensors support parameters for range, angular resolution, and noise: + +.. code-block:: xml + + + 0.15 0 0.3 0 0 0 + 10 + 360 + 360 + 20.0 + 0.01 + true + + +6 Additional features +^^^^^^^^^^^^^^^^^^^^^^ + +**Multi-robot simulation:** +MVSim natively supports multiple vehicles in the same world. +Each vehicle gets its own ROS 2 namespace, TF tree, and set of topics. +Robots can detect each other with their sensors and physically interact through collisions. + +**Property regions:** +You can define regions in the world with different physical properties, such as varying friction coefficients +or GPS-denied zones where GNSS sensors stop reporting positions. + +**Animated actors:** +MVSim supports skeletal-animated 3D characters (e.g., pedestrians) that follow waypoint paths, +useful for testing perception and planning in dynamic environments. + +**Joints and articulated vehicles:** +Vehicles can be connected using distance joints (ropes/cables) or revolute joints (hinges), +enabling simulation of trailers, tow ropes, and articulated systems. + +**XML advanced features:** +World files support ```` directives, variable substitution, mathematical expressions, +```` loops, and ```` conditionals, making it possible to procedurally generate complex environments. + +**Headless and faster-than-real-time:** +MVSim can run without a GUI and at configurable simulation speed, +which is useful for automated testing and reinforcement learning workflows. + +Comparison with other simulators +-------------------------------- + +MVSim occupies a different niche compared to other simulators: + +**Strengths:** + +- Very lightweight: low CPU and memory usage, fast startup times. +- Focused vehicle dynamics with multiple friction and drivetrain models. +- Simple XML-based world format, easy to get started. +- Native multi-robot support with per-vehicle ROS 2 namespaces. +- Faster-than-real-time simulation for batch testing. +- Procedural world generation via XML loops and conditionals. + +**Limitations:** + +- Physics is 2D (Box2D): no full 3D rigid body dynamics. + Objects do not tip over or fly. + Elevation maps add terrain height but the physics remains fundamentally 2D. +- Sensor simulation is less detailed than full 3D simulators: camera rendering and LiDAR models + are functional but not photorealistic. +- Smaller ecosystem of pre-built models and environments compared to Gazebo. +- Focused on wheeled mobile robots. + +Further resources +----------------- + +- `MVSim documentation `__ +- `MVSim GitHub repository `__ +- `MVSim paper (SoftwareX) `__ \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst index fed890d0178..d34f237f423 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst @@ -1,142 +1,146 @@ -Getting started with MVSim -========================== - -**Goal:** Launch MVSim demo worlds both standalone and with ROS 2, and learn how to interact with simulated robots. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -MVSim ships with a collection of demo worlds that showcase different features such as multi-robot simulation, -sensor configurations, terrain types, human actors, articulated vehicles and environment layouts. -You can run these demos either as a standalone application using the ``mvsim`` CLI, -or as a ROS 2 node that publishes sensor data and accepts velocity commands through standard ROS 2 topics. - -.. image:: Image/mvsim_demos_screenshot.png - :alt: MVSim demo screenshots - -Prerequisites -------------- - -You should have MVSim installed following the :doc:`Installation-Ubuntu` tutorial. - -Tasks ------ - -1 Launch demo worlds with the standalone CLI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -MVSim includes a standalone launcher that does not require ROS 2. -This is useful for quickly testing world files or for non-ROS use cases. - -To launch the warehouse demo: - -.. code-block:: console - - $ mvsim launch ~/ros2_ws/src/mvsim/mvsim_tutorial/demo_warehouse.world.xml - -If you installed from binary packages, the demo files are typically found under -``/opt/ros/{DISTRO}/share/mvsim/mvsim_tutorial/``. - -Some other demo worlds you can try: - -- ``demo_turtlebot_world.world.xml`` -- A TurtleBot3 in a classic ROS-style environment with obstacles. -- ``demo_2robots.world.xml`` -- Two robots navigating among furniture blocks. -- ``demo_elevation_map.world.xml`` -- A Jackal robot driving over terrain with elevation data. -- ``demo_greenhouse.world.xml`` -- A complex greenhouse environment demonstrating XML loops for procedural content. - -2 Controlling the robot -^^^^^^^^^^^^^^^^^^^^^^^^ - -Once a world is running, you can control the robot using: - -- **Keyboard:** Press W/S to move forward/backward, A/D to turn left/right, and spacebar to stop. - If the world has multiple robots, click on a robot in the GUI to select it before using keyboard controls. -- **Joystick:** If a gamepad is connected, it will be automatically detected. - -.. image:: Image/mvsim_gui_controls.jpg - :alt: MVSim GUI control reference - -The GUI also provides controls for camera view, simulation speed, and visualization options. -You can toggle orthographic/perspective view and enable visualization of sensor data directly in the 3D window. - -3 Launch with ROS 2 -^^^^^^^^^^^^^^^^^^^^^ - -To launch MVSim as a ROS 2 node, use the provided launch files: - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 launch mvsim demo_warehouse.launch.py - -This starts the simulator and creates ROS 2 topics for each vehicle and sensor. - -4 Inspect ROS 2 topics -^^^^^^^^^^^^^^^^^^^^^^^^ - -With the demo running, open a new terminal and list the available topics: - -.. code-block:: console - - $ ros2 topic list - -You should see topics such as: - -- ``/robot1/cmd_vel`` -- Send ``geometry_msgs/msg/Twist`` commands to control the robot. -- ``/robot1/odom`` -- Odometry from wheel encoders (``nav_msgs/msg/Odometry``). -- ``/robot1/base_pose_ground_truth`` -- Perfect ground truth pose. -- ``/robot1/`` -- Sensor-specific topics (e.g., ``/robot1/lidar1_points`` for 3D LiDAR point clouds, ``/robot1/laser1`` for 2D scans). -- ``/tf`` and ``/tf_static`` -- TF2 transforms following `REP-105 `__ (``map`` → ``odom`` → ``base_link``). - -You can send velocity commands from the command line: - -.. code-block:: console - - $ ros2 topic pub /robot1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.5}, angular: {z: 0.3}}" - -Or use ``teleop_twist_keyboard`` for interactive control: - -.. code-block:: console - - $ ros2 run teleop_twist_keyboard teleop_twist_keyboard --ros-args -r cmd_vel:=/robot1/cmd_vel - -5 Visualize in RViz2 -^^^^^^^^^^^^^^^^^^^^ - -You can visualize MVSim sensor data in RViz2. -Some launch files include an ``use_rviz`` option: - -.. code-block:: console - - $ ros2 launch mvsim demo_warehouse.launch.py use_rviz:=True - -Alternatively, open RViz2 manually and add displays for the topics of interest (e.g., ``LaserScan``, ``PointCloud2``, ``Image``, ``Odometry``). - -.. image:: Image/mvsim_depth_camera_demo.png - :alt: MVSim depth camera visualization - -6 Headless mode -^^^^^^^^^^^^^^^ - -For CI pipelines or remote servers without a display, MVSim supports headless operation: - -.. code-block:: console - - $ ros2 launch mvsim demo_warehouse.launch.py headless:=True - -This runs the full simulation without opening a GUI window. - -Summary -------- - -In this tutorial, you launched MVSim demo worlds both standalone and with ROS 2. -You learned how to control robots with keyboard and ROS 2 topics, inspect the published topics, and visualize data in RViz2. -The next tutorial covers how to define your own worlds with custom robots and sensors. +.. redirect-from:: + + Tutorials/Advanced/Simulators/MVSim/Getting-Started-MVSim + +Getting started with MVSim +========================== + +**Goal:** Launch MVSim demo worlds both standalone and with ROS 2, and learn how to interact with simulated robots. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +MVSim ships with a collection of demo worlds that showcase different features such as multi-robot simulation, +sensor configurations, terrain types, human actors, articulated vehicles and environment layouts. +You can run these demos either as a standalone application using the ``mvsim`` CLI, +or as a ROS 2 node that publishes sensor data and accepts velocity commands through standard ROS 2 topics. + +.. image:: Image/mvsim_demos_screenshot.png + :alt: MVSim demo screenshots + +Prerequisites +------------- + +You should have MVSim installed following the :doc:`Installation-Ubuntu` tutorial. + +Tasks +----- + +1 Launch demo worlds with the standalone CLI +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +MVSim includes a standalone launcher that does not require ROS 2. +This is useful for quickly testing world files or for non-ROS use cases. + +To launch the warehouse demo: + +.. code-block:: console + + $ mvsim launch ~/ros2_ws/src/mvsim/mvsim_tutorial/demo_warehouse.world.xml + +If you installed from binary packages, the demo files are typically found under +``/opt/ros/{DISTRO}/share/mvsim/mvsim_tutorial/``. + +Some other demo worlds you can try: + +- ``demo_turtlebot_world.world.xml`` -- A TurtleBot3 in a classic ROS-style environment with obstacles. +- ``demo_2robots.world.xml`` -- Two robots navigating among furniture blocks. +- ``demo_elevation_map.world.xml`` -- A Jackal robot driving over terrain with elevation data. +- ``demo_greenhouse.world.xml`` -- A complex greenhouse environment demonstrating XML loops for procedural content. + +2 Controlling the robot +^^^^^^^^^^^^^^^^^^^^^^^^ + +Once a world is running, you can control the robot using: + +- **Keyboard:** Press W/S to move forward/backward, A/D to turn left/right, and spacebar to stop. + If the world has multiple robots, click on a robot in the GUI to select it before using keyboard controls. +- **Joystick:** If a gamepad is connected, it will be automatically detected. + +.. image:: Image/mvsim_gui_controls.jpg + :alt: MVSim GUI control reference + +The GUI also provides controls for camera view, simulation speed, and visualization options. +You can toggle orthographic/perspective view and enable visualization of sensor data directly in the 3D window. + +3 Launch with ROS 2 +^^^^^^^^^^^^^^^^^^^^^ + +To launch MVSim as a ROS 2 node, use the provided launch files: + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 launch mvsim demo_warehouse.launch.py + +This starts the simulator and creates ROS 2 topics for each vehicle and sensor. + +4 Inspect ROS 2 topics +^^^^^^^^^^^^^^^^^^^^^^^^ + +With the demo running, open a new terminal and list the available topics: + +.. code-block:: console + + $ ros2 topic list + +You should see topics such as: + +- ``/robot1/cmd_vel`` -- Send ``geometry_msgs/msg/Twist`` commands to control the robot. +- ``/robot1/odom`` -- Odometry from wheel encoders (``nav_msgs/msg/Odometry``). +- ``/robot1/base_pose_ground_truth`` -- Perfect ground truth pose. +- ``/robot1/`` -- Sensor-specific topics (e.g., ``/robot1/lidar1_points`` for 3D LiDAR point clouds, ``/robot1/laser1`` for 2D scans). +- ``/tf`` and ``/tf_static`` -- TF2 transforms following `REP-105 `__ (``map`` → ``odom`` → ``base_link``). + +You can send velocity commands from the command line: + +.. code-block:: console + + $ ros2 topic pub /robot1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.5}, angular: {z: 0.3}}" + +Or use ``teleop_twist_keyboard`` for interactive control: + +.. code-block:: console + + $ ros2 run teleop_twist_keyboard teleop_twist_keyboard --ros-args -r cmd_vel:=/robot1/cmd_vel + +5 Visualize in RViz2 +^^^^^^^^^^^^^^^^^^^^ + +You can visualize MVSim sensor data in RViz2. +Some launch files include an ``use_rviz`` option: + +.. code-block:: console + + $ ros2 launch mvsim demo_warehouse.launch.py use_rviz:=True + +Alternatively, open RViz2 manually and add displays for the topics of interest (e.g., ``LaserScan``, ``PointCloud2``, ``Image``, ``Odometry``). + +.. image:: Image/mvsim_depth_camera_demo.png + :alt: MVSim depth camera visualization + +6 Headless mode +^^^^^^^^^^^^^^^ + +For CI pipelines or remote servers without a display, MVSim supports headless operation: + +.. code-block:: console + + $ ros2 launch mvsim demo_warehouse.launch.py headless:=True + +This runs the full simulation without opening a GUI window. + +Summary +------- + +In this tutorial, you launched MVSim demo worlds both standalone and with ROS 2. +You learned how to control robots with keyboard and ROS 2 topics, inspect the published topics, and visualize data in RViz2. +The next tutorial covers how to define your own worlds with custom robots and sensors. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst index a7d2ef44643..196f61cf0fe 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst @@ -1,21 +1,25 @@ -MVSim -===== - -This set of tutorials will teach you how to configure the `MVSim `__ simulator with ROS 2. - -MVSim is a lightweight, open-source, multi-vehicle simulator focused on 2D+3D visualization of mobile robots. -It uses Box2D for 2D rigid body physics and provides realistic vehicle dynamics models (differential drive, Ackermann steering), -sensor simulation (2D/3D LiDARs, cameras, IMUs, GPS), and native ROS 2 integration. -MVSim is particularly well-suited for testing navigation, SLAM, and multi-robot coordination scenarios -with low computational overhead and fast iteration times. - -.. contents:: Contents - :depth: 2 - :local: - -.. toctree:: - :maxdepth: 1 - - Installation-Ubuntu - Getting-Started-MVSim - Defining-Worlds-MVSim +.. redirect-from:: + + Tutorials/Advanced/Simulators/MVSim/Simulation-MVSim + +MVSim +===== + +This set of tutorials will teach you how to configure the `MVSim `__ simulator with ROS 2. + +MVSim is a lightweight, open-source, multi-vehicle simulator focused on 2D+3D visualization of mobile robots. +It uses Box2D for 2D rigid body physics and provides realistic vehicle dynamics models (differential drive, Ackermann steering), +sensor simulation (2D/3D LiDARs, cameras, IMUs, GPS), and native ROS 2 integration. +MVSim is particularly well-suited for testing navigation, SLAM, and multi-robot coordination scenarios +with low computational overhead and fast iteration times. + +.. contents:: Contents + :depth: 2 + :local: + +.. toctree:: + :maxdepth: 1 + + Installation-Ubuntu + Getting-Started-MVSim + Defining-Worlds-MVSim \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Simulation-Main.rst b/source/Integrations-and-related/Simulators/Simulation-Main.rst index 36f294c07ac..79e71b154bd 100644 --- a/source/Integrations-and-related/Simulators/Simulation-Main.rst +++ b/source/Integrations-and-related/Simulators/Simulation-Main.rst @@ -1,25 +1,26 @@ -.. redirect-from:: - - Tutorials/Simulators/Simulation-Main - -.. _SimulationMain: - -Simulators -========== - -Several advanced robot simulators can be used with ROS 2, such as Gazebo, Webots, etc. -Unlike turtlesim, they provide fairly realistic results relying on physics-based models for robots, sensors, actuators and objects. -Hence, what you observe in simulation is very close to what you will get when transferring your ROS 2 controllers to a real robot. - -This set of tutorials will teach you how to configure different simulators with ROS 2. - -.. contents:: Contents - :depth: 2 - :local: - -.. toctree:: - :maxdepth: 1 - - Webots/Simulation-Webots - Gazebo/Simulation-Gazebo - MVSim/Simulation-MVSim +.. redirect-from:: + + Tutorials/Simulators/Simulation-Main + Tutorials/Advanced/Simulators/Simulation-Main + +.. _SimulationMain: + +Simulators +========== + +Several advanced robot simulators can be used with ROS 2, such as Gazebo, Webots, etc. +Unlike turtlesim, they provide fairly realistic results relying on physics-based models for robots, sensors, actuators and objects. +Hence, what you observe in simulation is very close to what you will get when transferring your ROS 2 controllers to a real robot. + +This set of tutorials will teach you how to configure different simulators with ROS 2. + +.. contents:: Contents + :depth: 2 + :local: + +.. toctree:: + :maxdepth: 1 + + Webots/Simulation-Webots + Gazebo/Simulation-Gazebo + MVSim/Simulation-MVSim \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst b/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst index efd142ae6f9..cc81eb6f79c 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst @@ -1,209 +1,213 @@ -Installation (macOS) -==================== - -**Goal:** Install the ``webots_ros2`` package and run simulation examples on macOS. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, including ``webots_ros2_driver``, which allows you to start Webots and communicate with it. -Other sub-packages are mainly examples that show multiple possible implementations using the interface. -In this tutorial, you are going to install the package and learn how to run one of these examples. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../../Tutorials`. -In particular, :doc:`../../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. - -It is necessary to install Webots natively on the mac in order to use the ``webots_ros2`` package in the virtual machine as explained below. -You can follow the `installation procedure `_ or `build it from sources `_. - -Tasks ------ - -On macOS, a solution based on UTM virtual machines provides an improved user experience with ROS 2 compared to native macOS installation, as it runs ROS in a Linux environment. -However, Webots should be installed natively on macOS and it will be able to communicate with the ROS nodes running in the Virtual Machine (VM). -This solution allows for native 3D hardware acceleration for Webots. -The VM runs all the ROS part (including RViz) and connects to the host machine through TCP to start Webots. -A shared folder allows the script to transfer the world and other resource files from the VM to macOS where Webots is running. - -The following steps explain how to create the VM image with the installation of the ``webots_ros2`` released package. -It is also possible to install it from sources. - -1 Create the VM image -^^^^^^^^^^^^^^^^^^^^^^ - -Install UTM on your macOS machine. -The link can be found on the `official UTM website `_. - -Download the ``.iso`` image of `Ubuntu 22.04 `_ for Humble and Rolling or `Ubuntu 20.04 `_ for Foxy. -Be sure to download the image corresponding to your CPU architecture. - -In the UTM software: - -* Create a new image and choose ``Virtualize`` option. -* Select the ISO image you have downloaded in the ``Boot ISO Image`` field. -* Leave all hardware settings at default (including hardware acceleration disabled). -* In the ``Shared Directory`` window, select a folder that will be used by ``webots_ros2`` to transfer all the Webots assets to the host. - In this example, the selected folder is ``/Users/username/shared``. -* Leave all the remaining parameters as default. -* Start the VM. - Note that you can select another shared folder each time you start the VM. -* During the first launch of the VM, install Ubuntu and choose a username for your account. - In this example, the username is ``ubuntu``. -* Once Ubuntu is installed, close the VM, remove the iso image from the CD/DVD field and restart the VM. - -2 Configure the VM -^^^^^^^^^^^^^^^^^^ -In this section, ROS 2 is installed in the VM and the shared folder is configured. -The following instructions and commands are all run inside the VM. - -* Open a terminal in the started VM and install the ROS 2 distribution you need by following the instructions in :doc:`../../../../Installation/Ubuntu-Install-Debs`: -* Create a folder in the VM to use as a shared folder. - In this example, the shared folder in the VM is ``/home/ubuntu/shared``. - - .. code-block:: console - - $ mkdir /home/ubuntu/shared - -* To mount this folder to the host, execute the following command. - Don't forget to modify the path to the shared folder, if it is different in your case. - - .. code-block:: console - - $ sudo mount -t 9p -o trans=virtio share /home/ubuntu/shared -oversion=9p2000.L - -* To automatically mount this folder to the host when starting the VM, add the following line to ``/etc/fstab``. - Don't forget to modify the path to the shared folder, if it is different in your case. - - .. code-block:: console - - share /home/ubuntu/shared 9p trans=virtio,version=9p2000.L,rw,_netdev,nofail 0 0 - -* The environment variable ``WEBOTS_SHARED_FOLDER`` must always be set in order for the package to work properly in the VM. - This variable specifies the location of the shared folder that is used to exchange data between the host machine and the virtual machine (VM) to the ``webots_ros2`` package. - The value to use for this variable should be in the format of ``:``, where ```` is the path to the shared folder on the host machine and ```` is the path to the same shared folder on the VM. - - In this example: - - .. code-block:: console - - $ export WEBOTS_SHARED_FOLDER=/Users/username/shared:/home/ubuntu/shared - - You can add this command line to the ``~/.bashrc`` file to automatically set this environment variable when starting a new terminal. - -3 Install ``webots_ros2`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can either install ``webots_ros2`` from the official released package, or install it from the latest up-to-date sources from `Github `_. - -.. tabs:: - - .. group-tab:: Install ``webots_ros2`` distributed package - - Run the following command in the VM terminal. - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-webots-ros2 - - .. group-tab:: Install ``webots_ros2`` from sources - - Install git. - - .. code-block:: console - - $ sudo apt-get install git - - Create a ROS 2 workspace with its ``src`` directory. - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - - Source the ROS 2 environment. - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Retrieve the sources from Github. - - .. code-block:: console - - $ cd ~/ros2_ws - $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 - - Install the package dependencies. - - .. code-block:: console - - $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions - $ sudo rosdep init && rosdep update - $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} - - Build the package using ``colcon``. - - .. code-block:: console - - $ colcon build - - Source this workspace. - - .. code-block:: console - - $ source install/local_setup.bash - -4 Launch the ``webots_ros2_universal_robot`` example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As mentioned in previous sections, the package uses the shared folder to communicate with Webots from the VM to the host. -In order for Webots to be started on the host from the VM's ROS package, a local TCP simulation server must be run. - -The server can be downloaded here: `local_simulation_server.py `_. -Specify the Webots installation folder in ``WEBOTS_HOME`` environment variable (e.g. ``/Applications/Webots.app``) and run the server using the following commands in a new terminal on the host (not in the VM): - -.. code-block:: console - - $ export WEBOTS_HOME=/Applications/Webots.app - $ python3 local_simulation_server.py - -In the VM, open a terminal and execute the following commands to start a package: - -First source the ROS 2 environment, if not done already. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -If installed from sources, source your ROS 2 workspace, if not done already. - -.. code-block:: console - - $ cd ~/ros2_ws - $ source install/local_setup.bash - -If not already set in ``~/.bashrc``, set ``WEBOTS_SHARED_FOLDER`` (see previous sections for details). -Be sure to change the paths according to the location of your respective directories. - -.. code-block:: console - - $ export WEBOTS_SHARED_FOLDER=/Users/username/shared:/home/ubuntu/shared - -Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). - -.. code-block:: console - - $ ros2 launch webots_ros2_universal_robot multirobot_launch.py - -If Webots is closed or the ROS 2 process is interrupted, the local server will automatically wait for a new package launch and the shared folder will be cleaned for the next run. +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Installation-MacOS + +Installation (macOS) +==================== + +**Goal:** Install the ``webots_ros2`` package and run simulation examples on macOS. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, including ``webots_ros2_driver``, which allows you to start Webots and communicate with it. +Other sub-packages are mainly examples that show multiple possible implementations using the interface. +In this tutorial, you are going to install the package and learn how to run one of these examples. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. + +It is necessary to install Webots natively on the mac in order to use the ``webots_ros2`` package in the virtual machine as explained below. +You can follow the `installation procedure `_ or `build it from sources `_. + +Tasks +----- + +On macOS, a solution based on UTM virtual machines provides an improved user experience with ROS 2 compared to native macOS installation, as it runs ROS in a Linux environment. +However, Webots should be installed natively on macOS and it will be able to communicate with the ROS nodes running in the Virtual Machine (VM). +This solution allows for native 3D hardware acceleration for Webots. +The VM runs all the ROS part (including RViz) and connects to the host machine through TCP to start Webots. +A shared folder allows the script to transfer the world and other resource files from the VM to macOS where Webots is running. + +The following steps explain how to create the VM image with the installation of the ``webots_ros2`` released package. +It is also possible to install it from sources. + +1 Create the VM image +^^^^^^^^^^^^^^^^^^^^^^ + +Install UTM on your macOS machine. +The link can be found on the `official UTM website `_. + +Download the ``.iso`` image of `Ubuntu 22.04 `_ for Humble and Rolling or `Ubuntu 20.04 `_ for Foxy. +Be sure to download the image corresponding to your CPU architecture. + +In the UTM software: + +* Create a new image and choose ``Virtualize`` option. +* Select the ISO image you have downloaded in the ``Boot ISO Image`` field. +* Leave all hardware settings at default (including hardware acceleration disabled). +* In the ``Shared Directory`` window, select a folder that will be used by ``webots_ros2`` to transfer all the Webots assets to the host. + In this example, the selected folder is ``/Users/username/shared``. +* Leave all the remaining parameters as default. +* Start the VM. + Note that you can select another shared folder each time you start the VM. +* During the first launch of the VM, install Ubuntu and choose a username for your account. + In this example, the username is ``ubuntu``. +* Once Ubuntu is installed, close the VM, remove the iso image from the CD/DVD field and restart the VM. + +2 Configure the VM +^^^^^^^^^^^^^^^^^^ +In this section, ROS 2 is installed in the VM and the shared folder is configured. +The following instructions and commands are all run inside the VM. + +* Open a terminal in the started VM and install the ROS 2 distribution you need by following the instructions in :doc:`../../../Get-Started/Installation/Ubuntu-Install-Debs`: +* Create a folder in the VM to use as a shared folder. + In this example, the shared folder in the VM is ``/home/ubuntu/shared``. + + .. code-block:: console + + $ mkdir /home/ubuntu/shared + +* To mount this folder to the host, execute the following command. + Don't forget to modify the path to the shared folder, if it is different in your case. + + .. code-block:: console + + $ sudo mount -t 9p -o trans=virtio share /home/ubuntu/shared -oversion=9p2000.L + +* To automatically mount this folder to the host when starting the VM, add the following line to ``/etc/fstab``. + Don't forget to modify the path to the shared folder, if it is different in your case. + + .. code-block:: console + + share /home/ubuntu/shared 9p trans=virtio,version=9p2000.L,rw,_netdev,nofail 0 0 + +* The environment variable ``WEBOTS_SHARED_FOLDER`` must always be set in order for the package to work properly in the VM. + This variable specifies the location of the shared folder that is used to exchange data between the host machine and the virtual machine (VM) to the ``webots_ros2`` package. + The value to use for this variable should be in the format of ``:``, where ```` is the path to the shared folder on the host machine and ```` is the path to the same shared folder on the VM. + + In this example: + + .. code-block:: console + + $ export WEBOTS_SHARED_FOLDER=/Users/username/shared:/home/ubuntu/shared + + You can add this command line to the ``~/.bashrc`` file to automatically set this environment variable when starting a new terminal. + +3 Install ``webots_ros2`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can either install ``webots_ros2`` from the official released package, or install it from the latest up-to-date sources from `Github `_. + +.. tabs:: + + .. group-tab:: Install ``webots_ros2`` distributed package + + Run the following command in the VM terminal. + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-webots-ros2 + + .. group-tab:: Install ``webots_ros2`` from sources + + Install git. + + .. code-block:: console + + $ sudo apt-get install git + + Create a ROS 2 workspace with its ``src`` directory. + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + + Source the ROS 2 environment. + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Retrieve the sources from Github. + + .. code-block:: console + + $ cd ~/ros2_ws + $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 + + Install the package dependencies. + + .. code-block:: console + + $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions + $ sudo rosdep init && rosdep update + $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} + + Build the package using ``colcon``. + + .. code-block:: console + + $ colcon build + + Source this workspace. + + .. code-block:: console + + $ source install/local_setup.bash + +4 Launch the ``webots_ros2_universal_robot`` example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As mentioned in previous sections, the package uses the shared folder to communicate with Webots from the VM to the host. +In order for Webots to be started on the host from the VM's ROS package, a local TCP simulation server must be run. + +The server can be downloaded here: `local_simulation_server.py `_. +Specify the Webots installation folder in ``WEBOTS_HOME`` environment variable (e.g. ``/Applications/Webots.app``) and run the server using the following commands in a new terminal on the host (not in the VM): + +.. code-block:: console + + $ export WEBOTS_HOME=/Applications/Webots.app + $ python3 local_simulation_server.py + +In the VM, open a terminal and execute the following commands to start a package: + +First source the ROS 2 environment, if not done already. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +If installed from sources, source your ROS 2 workspace, if not done already. + +.. code-block:: console + + $ cd ~/ros2_ws + $ source install/local_setup.bash + +If not already set in ``~/.bashrc``, set ``WEBOTS_SHARED_FOLDER`` (see previous sections for details). +Be sure to change the paths according to the location of your respective directories. + +.. code-block:: console + + $ export WEBOTS_SHARED_FOLDER=/Users/username/shared:/home/ubuntu/shared + +Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). + +.. code-block:: console + + $ ros2 launch webots_ros2_universal_robot multirobot_launch.py + +If Webots is closed or the ROS 2 process is interrupted, the local server will automatically wait for a new package launch and the shared folder will be cleaned for the next run. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst b/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst index 82c154bfcb8..490e18763e2 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst @@ -1,131 +1,135 @@ -Installation (Ubuntu) -====================================== - -**Goal:** Install the ``webots_ros2`` package and run simulation examples on Ubuntu. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, including ``webots_ros2_driver``, which allows you to start Webots and communicate with it. -This interface is used in most of the following tutorials, so it is required to install it beforehand. -Other sub-packages are mainly examples that show multiple possible implementations using the interface. -In this tutorial, you are going to install the package and learn how to run one of these examples. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../../Tutorials`. -In particular, :doc:`../../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. - -The Webots software should be installed in order to use the ``webots_ros2`` interface. -You can follow the `installation procedure `_ or `build it from sources `_. - -Alternatively, you can also let ``webots_ros2`` download and install Webots automatically. -This option appears when you launch an example of the package and no Webots installation is found. - -Multiple Installations of Webots -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have installed different versions of Webots on your computer, ``webots_ros2`` will look for Webots at the following locations (in this order): - -1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -3. If none of these variables is set, ``webots_ros2`` will look for Webots in the default installation paths for a compatible version: ``/usr/local/webots`` and ``/snap/webots/current/usr/share/webots``. -4. If Webots couldn't be found, ``webots_ros2`` will show a window offering the automatic installation of the latest compatible version of Webots. - -Tasks ------ - -1 Install ``webots_ros2`` -^^^^^^^^^^^^^^^^^^^^^^^^^ -You can either install the official released package, or install it from the latest up-to-date sources from `Github `_. - -.. tabs:: - - .. group-tab:: Install ``webots_ros2`` distributed package - - Run the following command in a terminal. - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-webots-ros2 - - .. group-tab:: Install ``webots_ros2`` from sources - - Create a ROS 2 workspace with its ``src`` directory. - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - - Source the ROS 2 environment. - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Retrieve the sources from Github. - - .. code-block:: console - - $ cd ~/ros2_ws - $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 - - Install the package dependencies. - - .. code-block:: console - - $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions - $ sudo rosdep init && rosdep update - $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} - - Build the package using ``colcon``. - - .. code-block:: console - - $ colcon build - - Source this workspace. - - .. code-block:: console - - $ source install/local_setup.bash - -2 Launch the ``webots_ros2_universal_robot`` example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following instructions explain how to start a provided example. - -First source the ROS 2 environment, if not done already. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation. - -.. code-block:: console - - $ export WEBOTS_HOME=/usr/local/webots - -If installed from sources, source your ROS 2 workspace, if not done already. - -.. code-block:: console - - $ cd ~/ros2_ws - $ source install/local_setup.bash - -Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). - -.. code-block:: console - - $ ros2 launch webots_ros2_universal_robot multirobot_launch.py +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Installation-Ubuntu + +Installation (Ubuntu) +====================================== + +**Goal:** Install the ``webots_ros2`` package and run simulation examples on Ubuntu. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, including ``webots_ros2_driver``, which allows you to start Webots and communicate with it. +This interface is used in most of the following tutorials, so it is required to install it beforehand. +Other sub-packages are mainly examples that show multiple possible implementations using the interface. +In this tutorial, you are going to install the package and learn how to run one of these examples. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. + +The Webots software should be installed in order to use the ``webots_ros2`` interface. +You can follow the `installation procedure `_ or `build it from sources `_. + +Alternatively, you can also let ``webots_ros2`` download and install Webots automatically. +This option appears when you launch an example of the package and no Webots installation is found. + +Multiple Installations of Webots +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have installed different versions of Webots on your computer, ``webots_ros2`` will look for Webots at the following locations (in this order): + +1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +3. If none of these variables is set, ``webots_ros2`` will look for Webots in the default installation paths for a compatible version: ``/usr/local/webots`` and ``/snap/webots/current/usr/share/webots``. +4. If Webots couldn't be found, ``webots_ros2`` will show a window offering the automatic installation of the latest compatible version of Webots. + +Tasks +----- + +1 Install ``webots_ros2`` +^^^^^^^^^^^^^^^^^^^^^^^^^ +You can either install the official released package, or install it from the latest up-to-date sources from `Github `_. + +.. tabs:: + + .. group-tab:: Install ``webots_ros2`` distributed package + + Run the following command in a terminal. + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-webots-ros2 + + .. group-tab:: Install ``webots_ros2`` from sources + + Create a ROS 2 workspace with its ``src`` directory. + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + + Source the ROS 2 environment. + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Retrieve the sources from Github. + + .. code-block:: console + + $ cd ~/ros2_ws + $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 + + Install the package dependencies. + + .. code-block:: console + + $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions + $ sudo rosdep init && rosdep update + $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} + + Build the package using ``colcon``. + + .. code-block:: console + + $ colcon build + + Source this workspace. + + .. code-block:: console + + $ source install/local_setup.bash + +2 Launch the ``webots_ros2_universal_robot`` example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following instructions explain how to start a provided example. + +First source the ROS 2 environment, if not done already. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation. + +.. code-block:: console + + $ export WEBOTS_HOME=/usr/local/webots + +If installed from sources, source your ROS 2 workspace, if not done already. + +.. code-block:: console + + $ cd ~/ros2_ws + $ source install/local_setup.bash + +Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). + +.. code-block:: console + + $ ros2 launch webots_ros2_universal_robot multirobot_launch.py \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst b/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst index 1a1d02d16fd..94feb0b08cf 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst @@ -1,199 +1,203 @@ -Installation (Windows) -====================================== - -**Goal:** Install the ``webots_ros2`` package and run simulation examples on Windows. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, including ``webots_ros2_driver``, which allows ROS nodes to communicate with Webots. -Other sub-packages are mainly examples that show multiple possible implementations using the interface. -In this tutorial, you are going to install the package and learn how to run one of these examples. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../../Tutorials`. -In particular, :doc:`../../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. - -Webots is a prerequisite to use the ``webots_ros2`` package. -You can follow the `installation procedure `_ or `build it from sources `_. - -Alternatively, you can also let ``webots_ros2`` download Webots automatically. -This option appears when you launch an example of the package and no Webots installation is found. - -Multiple Installations of Webots -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have more than one installation of Webots, ROS 2 will look for Webots at the following locations (in this order): - -1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -3. If none of the previous points is set/installed ROS 2 will look for Webots in the default installation paths for a compatible version: ``C:\Program Files\Webots``. -4. If Webots couldn't be found, ``webots_ros2`` will show a window and offer automatic Webots installation of the last compatible version. - -Tasks ------ - -1 Install WSL2 -^^^^^^^^^^^^^^^ - -On Windows, WSL (Windows Subsystem for Linux) improves the user experience with ROS 2 compared to native Windows installation, as it runs on a Linux platform. -Install WSL with an Ubuntu version which is compatible with your ROS distribution and upgrade to WSL2 following the `official Microsoft tutorial `_. - -2 Install ROS 2 in WSL -^^^^^^^^^^^^^^^^^^^^^^ - -Install ROS 2 inside Ubuntu WSL, following :doc:`../../../../Installation/Ubuntu-Install-Debs`. - -3 Install ``webots_ros2`` -^^^^^^^^^^^^^^^^^^^^^^^^^ -You can then either install ``webots_ros2`` from the official released package, or install it from the latest up-to-date sources from `Github `_. - -The following commands must be run inside the WSL environment. - -.. tabs:: - - .. group-tab:: Install ``webots_ros2`` distributed package - - Run the following command in a terminal. - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-webots-ros2 - - .. group-tab:: Install ``webots_ros2`` from sources - - Create a ROS 2 workspace with its ``src`` directory. - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - - Source the ROS 2 environment. - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Retrieve the sources from Github. - - .. code-block:: console - - $ cd ~/ros2_ws - $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 - - Install the package dependencies. - - .. code-block:: console - - $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions - $ sudo rosdep init && rosdep update - $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} - - Build the package using ``colcon``. - - .. code-block:: console - - $ colcon build - - Source this workspace. - - .. code-block:: console - - $ source install/local_setup.bash - - -4 Launch the ``webots_ros2_universal_robot`` example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -WSL doesn't support hardware acceleration (yet). -Therefore, Webots should be started on Windows, while the ROS part is running inside WSL. -To do so, the following commands must be run inside the WSL environment. - -First source the ROS 2 environment, if not done already. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation (e.g. ``C:\Program Files\Webots``). -Use the mount point "/mnt" to refer to a path on native Windows. - -.. code-block:: console - - $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots - -If installed from sources, source your ROS 2 workspace, if not done already. - -.. code-block:: console - - $ cd ~/ros2_ws - $ source install/local_setup.bash - -Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). - -.. code-block:: console - - $ ros2 launch webots_ros2_universal_robot multirobot_launch.py - - -5 RViz troubleshooting -^^^^^^^^^^^^^^^^^^^^^^ - -With recent versions of WSL2, RViz should work out of the box. - -You can check if it works correctly by running any example that uses RViz, for example: - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-slam-toolbox - $ ros2 launch webots_ros2_tiago robot_launch.py rviz:=true slam:=true - -The Tiago robot can be controlled using: - -.. code-block:: console - - $ ros2 run teleop_twist_keyboard teleop_twist_keyboard - -With older WSL versions, RViz2 may not work directly, as no display is available. -To use RViz, you can either upgrade WSL or enable X11 forwarding. - -.. tabs:: - .. group-tab:: Upgrade WSL - - In a Windows shell: - - .. code-block:: console - - $ wsl --update - - .. group-tab:: Enable X11 forwarding - - For older versions of WSL, the following steps can be followed: - - 1. Install `VcXsrv `_. - 2. Launch VcXsrv. - You can leave most of the parameters default, except the ``Extra settings`` page, where you must set ``Clipboard``, ``Primary Selection`` and ``Disable access control`` and unset ``Native opengl``. - 3. You can save the configuration for future launches. - 4. Click on ``Finish``, you will see that the X11 server is running in the icon tray. - 5. In your WSL environment, export the ``DISPLAY`` variable. - - .. code-block:: console - - $ export DISPLAY=$(ip route list default | awk '{print }'):0 - - You can add this to your ``.bashrc``, so that it is set for every future WSL environment. - - .. code-block:: console - - $ echo "export DISPLAY=$(ip route list default | awk '{print }'):0" >> ~/.bashrc +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Installation-Windows + +Installation (Windows) +====================================== + +**Goal:** Install the ``webots_ros2`` package and run simulation examples on Windows. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, including ``webots_ros2_driver``, which allows ROS nodes to communicate with Webots. +Other sub-packages are mainly examples that show multiple possible implementations using the interface. +In this tutorial, you are going to install the package and learn how to run one of these examples. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. + +Webots is a prerequisite to use the ``webots_ros2`` package. +You can follow the `installation procedure `_ or `build it from sources `_. + +Alternatively, you can also let ``webots_ros2`` download Webots automatically. +This option appears when you launch an example of the package and no Webots installation is found. + +Multiple Installations of Webots +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have more than one installation of Webots, ROS 2 will look for Webots at the following locations (in this order): + +1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +3. If none of the previous points is set/installed ROS 2 will look for Webots in the default installation paths for a compatible version: ``C:\Program Files\Webots``. +4. If Webots couldn't be found, ``webots_ros2`` will show a window and offer automatic Webots installation of the last compatible version. + +Tasks +----- + +1 Install WSL2 +^^^^^^^^^^^^^^^ + +On Windows, WSL (Windows Subsystem for Linux) improves the user experience with ROS 2 compared to native Windows installation, as it runs on a Linux platform. +Install WSL with an Ubuntu version which is compatible with your ROS distribution and upgrade to WSL2 following the `official Microsoft tutorial `_. + +2 Install ROS 2 in WSL +^^^^^^^^^^^^^^^^^^^^^^ + +Install ROS 2 inside Ubuntu WSL, following :doc:`../../../Get-Started/Installation/Ubuntu-Install-Debs`. + +3 Install ``webots_ros2`` +^^^^^^^^^^^^^^^^^^^^^^^^^ +You can then either install ``webots_ros2`` from the official released package, or install it from the latest up-to-date sources from `Github `_. + +The following commands must be run inside the WSL environment. + +.. tabs:: + + .. group-tab:: Install ``webots_ros2`` distributed package + + Run the following command in a terminal. + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-webots-ros2 + + .. group-tab:: Install ``webots_ros2`` from sources + + Create a ROS 2 workspace with its ``src`` directory. + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + + Source the ROS 2 environment. + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Retrieve the sources from Github. + + .. code-block:: console + + $ cd ~/ros2_ws + $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 + + Install the package dependencies. + + .. code-block:: console + + $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions + $ sudo rosdep init && rosdep update + $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} + + Build the package using ``colcon``. + + .. code-block:: console + + $ colcon build + + Source this workspace. + + .. code-block:: console + + $ source install/local_setup.bash + + +4 Launch the ``webots_ros2_universal_robot`` example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +WSL doesn't support hardware acceleration (yet). +Therefore, Webots should be started on Windows, while the ROS part is running inside WSL. +To do so, the following commands must be run inside the WSL environment. + +First source the ROS 2 environment, if not done already. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation (e.g. ``C:\Program Files\Webots``). +Use the mount point "/mnt" to refer to a path on native Windows. + +.. code-block:: console + + $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots + +If installed from sources, source your ROS 2 workspace, if not done already. + +.. code-block:: console + + $ cd ~/ros2_ws + $ source install/local_setup.bash + +Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). + +.. code-block:: console + + $ ros2 launch webots_ros2_universal_robot multirobot_launch.py + + +5 RViz troubleshooting +^^^^^^^^^^^^^^^^^^^^^^ + +With recent versions of WSL2, RViz should work out of the box. + +You can check if it works correctly by running any example that uses RViz, for example: + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-slam-toolbox + $ ros2 launch webots_ros2_tiago robot_launch.py rviz:=true slam:=true + +The Tiago robot can be controlled using: + +.. code-block:: console + + $ ros2 run teleop_twist_keyboard teleop_twist_keyboard + +With older WSL versions, RViz2 may not work directly, as no display is available. +To use RViz, you can either upgrade WSL or enable X11 forwarding. + +.. tabs:: + .. group-tab:: Upgrade WSL + + In a Windows shell: + + .. code-block:: console + + $ wsl --update + + .. group-tab:: Enable X11 forwarding + + For older versions of WSL, the following steps can be followed: + + 1. Install `VcXsrv `_. + 2. Launch VcXsrv. + You can leave most of the parameters default, except the ``Extra settings`` page, where you must set ``Clipboard``, ``Primary Selection`` and ``Disable access control`` and unset ``Native opengl``. + 3. You can save the configuration for future launches. + 4. Click on ``Finish``, you will see that the X11 server is running in the icon tray. + 5. In your WSL environment, export the ``DISPLAY`` variable. + + .. code-block:: console + + $ export DISPLAY=$(ip route list default | awk '{print }'):0 + + You can add this to your ``.bashrc``, so that it is set for every future WSL environment. + + .. code-block:: console + + $ echo "export DISPLAY=$(ip route list default | awk '{print }'):0" >> ~/.bashrc \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst index 97a659eec2a..5d4e30a373a 100644 --- a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst +++ b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst @@ -1,227 +1,231 @@ -Setting up a robot simulation (Advanced) -======================================== - -**Goal:** Extend a robot simulation with an obstacle avoider node. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial you will extend the package created in the first part of the tutorial: :doc:`./Setting-Up-Simulation-Webots-Basic`. -The aim is to implement a ROS 2 node that avoids obstacles using the robot's distance sensors. -This tutorial focuses on using robot devices with the ``webots_ros2_driver`` interface. - -Prerequisites -------------- - -This is a continuation of the first part of the tutorial: :doc:`./Setting-Up-Simulation-Webots-Basic`. -It is mandatory to start with the first part to set up the custom packages and necessary files. - -This tutorial is compatible with version 2023.1.0 of ``webots_ros2`` and Webots R2023b, as well as upcoming versions. - -Tasks ------ - -1 Updating ``my_robot.urdf`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As mentioned in :doc:`./Setting-Up-Simulation-Webots-Basic`, ``webots_ros2_driver`` contains plugins to interface most of Webots devices with ROS 2 directly. -These plugins can be loaded using the ```` tag in the URDF file of the robot. -The ``reference`` attribute should match the Webots device ``name`` parameter. -The list of all existing interfaces and the corresponding parameters can be found `on the devices reference page `_. -For available devices that are not configured in the URDF file, the interface will be automatically created and default values will be used for ROS parameters (e.g. ``update rate``, ``topic name``, and ``frame name``). - -In ``my_robot.urdf`` replace the whole contents with: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: Code/my_robot_with_sensors_python.urdf - :language: xml - - .. group-tab:: C++ - - .. literalinclude:: Code/my_robot_with_sensors_cpp.urdf - :language: xml - - -In addition to your custom plugin, the ``webots_ros2_driver`` will parse the ```` tags referring to the **DistanceSensor** nodes and use the standard parameters in the ```` tags to enable the sensors and name their topics. - -2 Creating a ROS node to avoid obstacles -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Python - - The robot will use a standard ROS node to detect the wall and send motor commands to avoid it. - In the ``my_package/my_package/`` folder, create a file named ``obstacle_avoider.py`` with this code: - - .. literalinclude:: Code/obstacle_avoider.py - :language: python - - This node will create a publisher for the command and subscribe to the sensors topics here: - - .. literalinclude:: Code/obstacle_avoider.py - :language: python - :dedent: 8 - :lines: 14-17 - - When a measurement is received from the left sensor it will be copied to a member field: - - .. literalinclude:: Code/obstacle_avoider.py - :language: python - :dedent: 4 - :lines: 19-20 - - Finally, a message will be sent to the ``/cmd_vel`` topic when a measurement from the right sensor is received. - The ``command_message`` will register at least a forward speed in ``linear.x`` in order to make the robot move when no obstacle is detected. - If any of the two sensors detect an obstacle, ``command_message`` will also register a rotational speed in ``angular.z`` in order to make the robot turn right. - - .. literalinclude:: Code/obstacle_avoider.py - :language: python - :dedent: 4 - :lines: 22-32 - - .. group-tab:: C++ - - The robot will use a standard ROS node to detect the wall and send motor commands to avoid it. - In the ``my_package/include/my_package`` folder, create a header file named ``ObstacleAvoider.hpp`` with this code: - - .. literalinclude:: Code/ObstacleAvoider.hpp - :language: cpp - - In the ``my_package/src`` folder, create a source file named ``ObstacleAvoider.cpp`` with this code: - - .. literalinclude:: Code/ObstacleAvoider.cpp - :language: cpp - - This node will create a publisher for the command and subscribe to the sensors topics here: - - .. literalinclude:: Code/ObstacleAvoider.cpp - :language: cpp - :lines: 6-20 - - When a measurement is received from the left sensor it will be copied to a member field: - - .. literalinclude:: Code/ObstacleAvoider.cpp - :language: cpp - :lines: 23-26 - - Finally, a message will be sent to the ``/cmd_vel`` topic when a measurement from the right sensor is received. - The ``command_message`` will register at least a forward speed in ``linear.x`` in order to make the robot move when no obstacle is detected. - If any of the two sensors detect an obstacle, ``command_message`` will also register a rotational speed in ``angular.z`` in order to make the robot turn right. - - .. literalinclude:: Code/ObstacleAvoider.cpp - :language: cpp - :lines: 28-42 - - -3 Updating additional files -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You have to modify these two other files to launch your new node. - -.. tabs:: - - .. group-tab:: Python - - Edit ``setup.py`` and replace ``'console_scripts'`` with: - - .. literalinclude:: Code/setup_sensor.py - :language: python - :dedent: 8 - :lines: 26-29 - - This will add an entry point for the ``obstacle_avoider`` node. - - .. group-tab:: C++ - - Edit ``CMakeLists.txt`` and add the compilation and installation of the ``obstacle_avoider``: - - .. literalinclude:: Code/CMakeLists_sensor.txt - :language: cmake - - -Go to the file ``robot_launch.py`` and replace it with: - -.. literalinclude:: Code/robot_launch_sensor.py - :language: python - -This will create an ``obstacle_avoider`` node that will be included in the ``LaunchDescription``. - -4 Test the obstacle avoidance code -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Launch the simulation from a terminal in your ROS 2 workspace: - -.. tabs:: - - .. group-tab:: Linux - - From a terminal in your ROS 2 workspace run: - - .. code-block:: console - - $ colcon build - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - .. group-tab:: Windows - - From a terminal in your WSL ROS 2 workspace run: - - .. code-block:: console - - $ colcon build - $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - Be sure to use the ``/mnt`` prefix in front of your path to the Webots installation folder to access the Windows file system from WSL. - - .. group-tab:: macOS - - In a terminal of the host machine (not in the VM), if not done already, specify the Webots installation folder (e.g. ``/Applications/Webots.app``) and start the server using the following commands: - - .. code-block:: console - - $ export WEBOTS_HOME=/Applications/Webots.app - $ python3 local_simulation_server.py - - Note that the server keeps running once the ROS 2 nodes are ended. - You don't need to restart it every time you want to launch a new simulation. - From a terminal in the Linux VM in your ROS 2 workspace, build and launch your custom package with: - - .. code-block:: console - - $ cd ~/ros2_ws - $ colcon build - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - -Your robot should go forward and before hitting the wall it should turn clockwise. -You can press ``Ctrl+F10`` in Webots or go to the ``View`` menu, ``Optional Rendering`` and ``Show DistanceSensor Rays`` to display the range of the distance sensors of the robot. - -.. image:: Image/Robot_turning_clockwise.png - -Summary -------- - -In this tutorial, you extended the basic simulation with a obstacle avoider ROS 2 node that publishes velocity commands based on the distance sensor values of the robot. - -Next steps ----------- - -You might want to improve the plugin or create new nodes to change the behavior of the robot. -You can also implement a reset handler to automatically restart your ROS nodes when the simulation is reset from the Webots interface: - -* :doc:`./Simulation-Reset-Handler`. +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced + +Setting up a robot simulation (Advanced) +======================================== + +**Goal:** Extend a robot simulation with an obstacle avoider node. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial you will extend the package created in the first part of the tutorial: :doc:`Setting-Up-Simulation-Webots-Basic`. +The aim is to implement a ROS 2 node that avoids obstacles using the robot's distance sensors. +This tutorial focuses on using robot devices with the ``webots_ros2_driver`` interface. + +Prerequisites +------------- + +This is a continuation of the first part of the tutorial: :doc:`Setting-Up-Simulation-Webots-Basic`. +It is mandatory to start with the first part to set up the custom packages and necessary files. + +This tutorial is compatible with version 2023.1.0 of ``webots_ros2`` and Webots R2023b, as well as upcoming versions. + +Tasks +----- + +1 Updating ``my_robot.urdf`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As mentioned in :doc:`Setting-Up-Simulation-Webots-Basic`, ``webots_ros2_driver`` contains plugins to interface most of Webots devices with ROS 2 directly. +These plugins can be loaded using the ```` tag in the URDF file of the robot. +The ``reference`` attribute should match the Webots device ``name`` parameter. +The list of all existing interfaces and the corresponding parameters can be found `on the devices reference page `_. +For available devices that are not configured in the URDF file, the interface will be automatically created and default values will be used for ROS parameters (e.g. ``update rate``, ``topic name``, and ``frame name``). + +In ``my_robot.urdf`` replace the whole contents with: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: Code/my_robot_with_sensors_python.urdf + :language: xml + + .. group-tab:: C++ + + .. literalinclude:: Code/my_robot_with_sensors_cpp.urdf + :language: xml + + +In addition to your custom plugin, the ``webots_ros2_driver`` will parse the ```` tags referring to the **DistanceSensor** nodes and use the standard parameters in the ```` tags to enable the sensors and name their topics. + +2 Creating a ROS node to avoid obstacles +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Python + + The robot will use a standard ROS node to detect the wall and send motor commands to avoid it. + In the ``my_package/my_package/`` folder, create a file named ``obstacle_avoider.py`` with this code: + + .. literalinclude:: Code/obstacle_avoider.py + :language: python + + This node will create a publisher for the command and subscribe to the sensors topics here: + + .. literalinclude:: Code/obstacle_avoider.py + :language: python + :dedent: 8 + :lines: 14-17 + + When a measurement is received from the left sensor it will be copied to a member field: + + .. literalinclude:: Code/obstacle_avoider.py + :language: python + :dedent: 4 + :lines: 19-20 + + Finally, a message will be sent to the ``/cmd_vel`` topic when a measurement from the right sensor is received. + The ``command_message`` will register at least a forward speed in ``linear.x`` in order to make the robot move when no obstacle is detected. + If any of the two sensors detect an obstacle, ``command_message`` will also register a rotational speed in ``angular.z`` in order to make the robot turn right. + + .. literalinclude:: Code/obstacle_avoider.py + :language: python + :dedent: 4 + :lines: 22-32 + + .. group-tab:: C++ + + The robot will use a standard ROS node to detect the wall and send motor commands to avoid it. + In the ``my_package/include/my_package`` folder, create a header file named ``ObstacleAvoider.hpp`` with this code: + + .. literalinclude:: Code/ObstacleAvoider.hpp + :language: cpp + + In the ``my_package/src`` folder, create a source file named ``ObstacleAvoider.cpp`` with this code: + + .. literalinclude:: Code/ObstacleAvoider.cpp + :language: cpp + + This node will create a publisher for the command and subscribe to the sensors topics here: + + .. literalinclude:: Code/ObstacleAvoider.cpp + :language: cpp + :lines: 6-20 + + When a measurement is received from the left sensor it will be copied to a member field: + + .. literalinclude:: Code/ObstacleAvoider.cpp + :language: cpp + :lines: 23-26 + + Finally, a message will be sent to the ``/cmd_vel`` topic when a measurement from the right sensor is received. + The ``command_message`` will register at least a forward speed in ``linear.x`` in order to make the robot move when no obstacle is detected. + If any of the two sensors detect an obstacle, ``command_message`` will also register a rotational speed in ``angular.z`` in order to make the robot turn right. + + .. literalinclude:: Code/ObstacleAvoider.cpp + :language: cpp + :lines: 28-42 + + +3 Updating additional files +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You have to modify these two other files to launch your new node. + +.. tabs:: + + .. group-tab:: Python + + Edit ``setup.py`` and replace ``'console_scripts'`` with: + + .. literalinclude:: Code/setup_sensor.py + :language: python + :dedent: 8 + :lines: 26-29 + + This will add an entry point for the ``obstacle_avoider`` node. + + .. group-tab:: C++ + + Edit ``CMakeLists.txt`` and add the compilation and installation of the ``obstacle_avoider``: + + .. literalinclude:: Code/CMakeLists_sensor.txt + :language: cmake + + +Go to the file ``robot_launch.py`` and replace it with: + +.. literalinclude:: Code/robot_launch_sensor.py + :language: python + +This will create an ``obstacle_avoider`` node that will be included in the ``LaunchDescription``. + +4 Test the obstacle avoidance code +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Launch the simulation from a terminal in your ROS 2 workspace: + +.. tabs:: + + .. group-tab:: Linux + + From a terminal in your ROS 2 workspace run: + + .. code-block:: console + + $ colcon build + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + .. group-tab:: Windows + + From a terminal in your WSL ROS 2 workspace run: + + .. code-block:: console + + $ colcon build + $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + Be sure to use the ``/mnt`` prefix in front of your path to the Webots installation folder to access the Windows file system from WSL. + + .. group-tab:: macOS + + In a terminal of the host machine (not in the VM), if not done already, specify the Webots installation folder (e.g. ``/Applications/Webots.app``) and start the server using the following commands: + + .. code-block:: console + + $ export WEBOTS_HOME=/Applications/Webots.app + $ python3 local_simulation_server.py + + Note that the server keeps running once the ROS 2 nodes are ended. + You don't need to restart it every time you want to launch a new simulation. + From a terminal in the Linux VM in your ROS 2 workspace, build and launch your custom package with: + + .. code-block:: console + + $ cd ~/ros2_ws + $ colcon build + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + +Your robot should go forward and before hitting the wall it should turn clockwise. +You can press ``Ctrl+F10`` in Webots or go to the ``View`` menu, ``Optional Rendering`` and ``Show DistanceSensor Rays`` to display the range of the distance sensors of the robot. + +.. image:: Image/Robot_turning_clockwise.png + +Summary +------- + +In this tutorial, you extended the basic simulation with a obstacle avoider ROS 2 node that publishes velocity commands based on the distance sensor values of the robot. + +Next steps +---------- + +You might want to improve the plugin or create new nodes to change the behavior of the robot. +You can also implement a reset handler to automatically restart your ROS nodes when the simulation is reset from the Webots interface: + +* :doc:`Simulation-Reset-Handler`. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst index 77992be868d..71a2dd4bff5 100644 --- a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst +++ b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst @@ -1,526 +1,527 @@ -.. redirect-from:: - - Tutorials/Simulators/Webots/Setting-up-a-Robot-Simulation-Webots - Tutorials/Advanced/Simulators/Webots - -Setting up a robot simulation (Basic) -====================================== - -**Goal:** Setup a robot simulation and control it from ROS 2. - -**Tutorial level:** Advanced - -**Time:** 30 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial, you are going to use the Webots robot simulator to set-up and run a very simple ROS 2 simulation scenario. - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, but in this tutorial, you are going to use only the ``webots_ros2_driver`` sub-package to implement a Python or C++ plugin controlling a simulated robot. -Some other sub-packages contain demos with different robots such as the TurtleBot3. -They are documented in the `Webots ROS 2 examples `_ page. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../../Tutorials`. -In particular, :doc:`../../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim`, :doc:`../../../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics`, :doc:`../../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`, :doc:`../../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package` and :doc:`../../../Intermediate/Launch/Creating-Launch-Files` are useful prerequisites. - -.. tabs:: - - .. group-tab:: Linux - - The Linux and ROS commands of this tutorial can be run in a standard Linux terminal. - The following page :doc:`./Installation-Ubuntu` explains how to install the ``webots_ros2`` package on Linux. - - .. group-tab:: Windows - - The Linux and ROS commands of this tutorial must be run in a WSL (Windows Subsystem for Linux) environment. - The following page :doc:`./Installation-Windows` explains how to install the ``webots_ros2`` package on Windows. - - .. group-tab:: macOS - - The Linux and ROS commands of this tutorial must be run in a pre-configured Linux Virtual Machine (VM). - The following page :doc:`./Installation-MacOS` explains how to install the ``webots_ros2`` package on macOS. - -This tutorial is compatible with version 2023.1.0 of ``webots_ros2`` and Webots R2023b, as well as upcoming versions. - -Tasks ------ - -1 Create the package structure -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's organize the code in a custom ROS 2 package. -Create a new package named ``my_package`` from the ``src`` folder of your ROS 2 workspace. -Change the current directory of your terminal to ``ros2_ws/src`` and run: - -.. tabs:: - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 --node-name my_robot_driver my_package --dependencies rclpy geometry_msgs webots_ros2_driver - - The ``--node-name my_robot_driver`` option will create a ``my_robot_driver.py`` template Python plugin in the ``my_package`` subfolder that you will modify later. - The ``--dependencies rclpy geometry_msgs webots_ros2_driver`` option specifies the packages needed by the ``my_robot_driver.py`` plugin in the ``package.xml`` file. - - Let's add a ``launch`` and a ``worlds`` folder inside the ``my_package`` folder. - - .. code-block:: console - - $ cd my_package - $ mkdir launch - $ mkdir worlds - - You should end up with the following folder structure: - - .. code-block:: console - - src/ - └── my_package/ - ├── launch/ - ├── my_package/ - │ ├── __init__.py - │ └── my_robot_driver.py - ├── resource/ - │ └── my_package - ├── test/ - │ ├── test_copyright.py - │ ├── test_flake8.py - │ └── test_pep257.py - ├── worlds/ - ├── package.xml - ├── setup.cfg - └── setup.py - - .. group-tab:: C++ - - .. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --node-name MyRobotDriver my_package --dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib - - The ``--node-name MyRobotDriver`` option will create a ``MyRobotDriver.cpp`` template C++ plugin in the ``my_package/src`` subfolder that you will modify later. - The ``--dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib`` option specifies the packages needed by the ``MyRobotDriver`` plugin in the ``package.xml`` file. - - - Let's add a ``launch``, a ``worlds`` and a ``resource`` folder inside the ``my_package`` folder. - - .. code-block:: console - - $ cd my_package - $ mkdir launch - $ mkdir worlds - $ mkdir resource - - Two additional files must be created: the header file for ``MyRobotDriver`` and the ``my_robot_driver.xml`` pluginlib description file. - - .. code-block:: console - - $ touch my_robot_driver.xml - $ touch include/my_package/MyRobotDriver.hpp - - You should end up with the following folder structure: - - .. code-block:: console - - src/ - └── my_package/ - ├── include/ - │ └── my_package/ - │ └── MyRobotDriver.hpp - ├── launch/ - ├── resource/ - ├── src/ - │ └── MyRobotDriver.cpp - ├── worlds/ - ├── CMakeList.txt - ├── my_robot_driver.xml - └── package.xml - -2 Setup the simulation world -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You will need a world file containing a robot to launch your simulation. -:download:`Download this world file ` and move it inside ``my_package/worlds/``. - -This is actually a fairly simple text file you can visualize in a text editor. -A simple robot is already included in this ``my_world.wbt`` world file. - -.. note:: - - In case you want to learn how to create your own robot model in Webots, you can check this `tutorial `_. - -3 Edit the ``my_robot_driver`` plugin -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``webots_ros2_driver`` sub-package automatically creates a ROS 2 interface for most sensors. -More details on existing device interfaces and how to configure them is given in the second part of the tutorial: :doc:`./Setting-Up-Simulation-Webots-Advanced`. -In this task, you will extend this interface by creating your own custom plugin. -This custom plugin is a ROS node equivalent to a robot controller. -You can use it to access the `Webots robot API `_ and create your own topics and services to control your robot. - -.. note:: - - The purpose of this tutorial is to show a basic example with a minimum number of dependencies. - However, you could avoid the use of this plugin by using another ``webots_ros2`` sub-package named ``webots_ros2_control``, introducing a new dependency. - This other sub-package creates an interface with the ``ros2_control`` package that facilitates the control of a differential wheeled robot. - - -.. tabs:: - - .. group-tab:: Python - - Open ``my_package/my_package/my_robot_driver.py`` in your favorite editor and replace its contents with the following: - - .. literalinclude:: Code/my_robot_driver.py - :language: python - - As you can see, the ``MyRobotDriver`` class implements three methods. - - The first method, named ``init(self, ...)``, is actually the ROS node counterpart of the Python ``__init__(self, ...)`` constructor. - The ``init`` method always takes two arguments: - - - The ``webots_node`` argument contains a reference on the Webots instance. - - The ``properties`` argument is a dictionary created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows you to pass parameters to the controller. - - The robot instance from the simulation ``self.__robot`` can be used to access the `Webots robot API `_. - Then, it gets the two motor instances and initializes them with a target position and a target velocity. - Finally a ROS node is created and a callback method is registered for a ROS topic named ``/cmd_vel`` that will handle ``Twist`` messages. - - .. literalinclude:: Code/my_robot_driver.py - :language: python - :dedent: 4 - :lines: 8-24 - - Then comes the implementation of the ``__cmd_vel_callback(self, twist)`` callback private method that will be called for each ``Twist`` message received on the ``/cmd_vel`` topic and will save it in the ``self.__target_twist`` member variable. - - .. literalinclude:: Code/my_robot_driver.py - :language: python - :dedent: 4 - :lines: 26-27 - - Finally, the ``step(self)`` method is called at every time step of the simulation. - The call to ``rclpy.spin_once()`` is needed to keep the ROS node running smoothly. - At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``self.__target_twist``. - As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. - This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. - - .. literalinclude:: Code/my_robot_driver.py - :language: python - :dedent: 4 - :lines: 29-39 - - .. group-tab:: C++ - - Open ``my_package/include/my_package/MyRobotDriver.hpp`` in your favorite editor and replace its contents with the following: - - .. literalinclude:: Code/MyRobotDriver.hpp - :language: cpp - - The class ``MyRobotDriver`` is defined, which inherits from the ``webots_ros2_driver::PluginInterface`` class. - The plugin has to override ``step(...)`` and ``init(...)`` functions. - More details are given in the ``MyRobotDriver.cpp`` file. - Several helper methods, callbacks and member variables that will be used internally by the plugin are declared privately. - - Then, open ``my_package/src/MyRobotDriver.cpp`` in your favorite editor and replace its contents with the following: - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - - The ``MyRobotDriver::init`` method is executed once the plugin is loaded by the ``webots_ros2_driver`` package. - It takes two arguments: - - * A pointer to the ``WebotsNode`` defined by ``webots_ros2_driver``, which allows to access the ROS 2 node functions. - * The ``parameters`` argument is an unordered map of strings, created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows to pass parameters to the controller. - It is not used in this example. - - It initializes the plugin by setting up the robot motors, setting their positions and velocities, and subscribing to the ``/cmd_vel`` topic. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 13-33 - - The subscription callback is declared as a lambda function, that will be called for each Twist message received on the ``/cmd_vel`` topic and will save it in the ``cmd_vel_msg`` member variable. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 28-31 - - The ``step()`` method is called at every time step of the simulation. - At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``cmd_vel_msg``. - As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. - This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 35-48 - - The final lines of the file define the end of the ``my_robot_driver`` namespace and include a macro to export the ``MyRobotDriver`` class as a plugin using the ``PLUGINLIB_EXPORT_CLASS`` macro. - This allows the plugin to be loaded by the Webots ROS2 driver at runtime. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 51-53 - - .. note:: - - While the plugin is implemented in C++, the C API must be used to interact with the Webots controller library. - -.. _4 Create the my_robot.urdf file: - -4 Create the ``my_robot.urdf`` file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You now have to create a URDF file to declare the ``MyRobotDriver`` plugin. -This will allow the ``webots_ros2_driver`` ROS node to launch the plugin and connect it to the target robot. - -In the ``my_package/resource`` folder create a text file named ``my_robot.urdf`` with this content: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: Code/my_robot_python.urdf - :language: xml - - The ``type`` attribute specifies the path to the class given by the hierarchical structure of files. - ``webots_ros2_driver`` is responsible for loading the class based on the specified package and modules. - - .. group-tab:: C++ - - .. literalinclude:: Code/my_robot_cpp.urdf - :language: xml - - The ``type`` attribute specifies the namespace and class name to load. - ``pluginlib`` is responsible for loading the class based on the specified information. - -.. note:: - - This simple URDF file doesn't contain any link or joint information about the robot as it is not needed in this tutorial. - However, URDF files usually contain much more information as explained in the :doc:`../../../Intermediate/URDF/URDF-Main` tutorial. - -.. note:: - - Here the plugin does not take any input parameter, but this can be achieved with a tag containing the parameter name. - - .. tabs:: - - .. group-tab:: Python - - .. code-block:: xml - - - someValue - - - .. group-tab:: C++ - - .. code-block:: xml - - - someValue - - - - This is namely used to pass parameters to existing Webots device plugins (see :doc:`./Setting-Up-Simulation-Webots-Advanced`). - -5 Create the launch file -^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's create the launch file to easily launch the simulation and the ROS controller with a single command. -In the ``my_package/launch`` folder create a new text file named ``robot_launch.py`` with this code: - -.. literalinclude:: Code/robot_launch.py - :language: python - -The ``WebotsLauncher`` object is a custom action that allows you to start a Webots simulation instance. -You have to specify in the constructor which world file the simulator will open. - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 4 - :lines: 13-15 - -Then, the ROS node interacting with the simulated robot is created. -This node, named ``WebotsController``, is located in the ``webots_ros2_driver`` package. - -.. tabs:: - - .. group-tab:: Linux - - The node will be able to communicate with the simulated robot by using a custom protocol based on IPC and shared memory. - - .. group-tab:: Windows - - The node (in WSL) will be able to communicate with the simulated robot (in Webots on native Windows) through a TCP connection. - - .. group-tab:: macOS - - The node (in the docker container) will be able to communicate with the simulated robot (in Webots on native macOS) through a TCP connection. - - -In your case, you need to run a single instance of this node, because you have a single robot in the simulation. -But if you had more robots in the simulation, you would have to run one instance of this node per robot. -The ``robot_name`` parameter is used to define the name of the robot the driver should connect to. -The ``robot_description`` parameter holds the path to the URDF file which refers to the ``MyRobotDriver`` plugin. -You can see the ``WebotsController`` node as the interface that connects your controller plugin to the target robot. - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 4 - :lines: 17-22 - -After that, the two nodes are set to be launched in the ``LaunchDescription`` constructor: - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 4 - :lines: 24-26 - -Finally, an optional part is added in order to shutdown all the nodes once Webots terminates (e.g. when it gets closed from the graphical user interface). - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 8 - :lines: 27-32 - -.. note:: - - More details on ``WebotsController`` and ``WebotsLauncher`` arguments can be found `on the nodes reference page `_. - -6 Edit additional files -^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Python - - Before you can start the launch file, you have to modify the ``setup.py`` file to include the extra files you added. - Open ``my_package/setup.py`` and replace its contents with: - - .. literalinclude:: Code/setup.py - :language: python - - This sets-up the package and adds in the ``data_files`` variable the newly added files: ``my_world.wbt``, ``my_robot.urdf`` and ``robot_launch.py``. - - .. group-tab:: C++ - - Before you can start the launch file, you have to modify ``CMakeLists.txt`` and ``my_robot_driver.xml`` files: - - * ``CMakeLists.txt`` defines the compilation rules of your plugin. - * ``my_robot_driver.xml`` is necessary for the pluginlib to find your Webots ROS 2 plugin. - - Open ``my_package/my_robot_driver.xml`` and replace its contents with: - - .. literalinclude:: Code/my_robot_driver.xml - :language: xml - - Open ``my_package/CMakeLists.txt`` and replace its contents with: - - .. literalinclude:: Code/CMakeLists.txt - :language: cmake - - The CMakeLists.txt exports the plugin configuration file with the ``pluginlib_export_plugin_description_file()``, defines a shared library of the C++ plugin ``src/MyRobotDriver.cpp``, and sets the include and library dependencies using ``target_link_libraries()``. - - The file then installs the library, the directories ``launch``, ``resource``, and ``worlds`` to the ``share/my_package`` directory. - Finally, it exports the include directories and libraries using ``ament_export_include_directories()`` and ``ament_export_libraries()``, respectively, and declares the package using ``ament_package()``. - - -7 Test the code -^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Linux - - From a terminal in your ROS 2 workspace run: - - .. code-block:: console - - $ colcon build - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - This will launch the simulation. - Webots will be automatically installed on the first run in case it was not already installed. - - .. group-tab:: Windows - - From a terminal in your WSL ROS 2 workspace run: - - .. code-block:: console - - $ colcon build - $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - Be sure to use the ``/mnt`` prefix in front of your path to the Webots installation folder to access the Windows file system from WSL. - - This will launch the simulation. - Webots will be automatically installed on the first run in case it was not already installed. - - .. group-tab:: macOS - - On macOS, a local server must be started on the host to start Webots from the VM. - The local server can be downloaded `on the webots-server repository `_. - - In a terminal of the host machine (not in the VM), specify the Webots installation folder (e.g. ``/Applications/Webots.app``) and start the server using the following commands: - - .. code-block:: console - - $ export WEBOTS_HOME=/Applications/Webots.app - $ python3 local_simulation_server.py - - From a terminal in the Linux VM in your ROS 2 workspace, build and launch your custom package with: - - .. code-block:: console - - $ colcon build - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - -.. note:: - - If you want to install Webots manually, you can download it `here `_. - - -Then, open a second terminal and send a command with: - -.. code-block:: console - - $ ros2 topic pub /cmd_vel geometry_msgs/Twist "linear: { x: 0.1 }" - -The robot is now moving forward. - -.. image:: Image/Robot_moving_forward.png - -At this point, the robot is able to blindly follow your motor commands. -But it will eventually bump into the wall as you order it to move forwards. - -.. image:: Image/Robot_colliding_wall.png - -Close the Webots window, this should also shutdown your ROS nodes started from the launcher. -Close also the topic command with ``Ctrl+C`` in the second terminal. - -Summary -------- - -In this tutorial, you set-up a realistic robot simulation with Webots and implemented a custom plugin to control the motors of the robot. - -Next steps ----------- - -To improve the simulation, the robot's sensors can be used to detect obstacles and avoid them. -The second part of the tutorial shows how to implement such behaviour: - -* :doc:`./Setting-Up-Simulation-Webots-Advanced`. +.. redirect-from:: + + Tutorials/Simulators/Webots/Setting-up-a-Robot-Simulation-Webots + Tutorials/Advanced/Simulators/Webots + Tutorials/Advanced/Simulators/Webots/Setting-Up-Simulation-Webots-Basic + +Setting up a robot simulation (Basic) +====================================== + +**Goal:** Setup a robot simulation and control it from ROS 2. + +**Tutorial level:** Advanced + +**Time:** 30 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial, you are going to use the Webots robot simulator to set-up and run a very simple ROS 2 simulation scenario. + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, but in this tutorial, you are going to use only the ``webots_ros2_driver`` sub-package to implement a Python or C++ plugin controlling a simulated robot. +Some other sub-packages contain demos with different robots such as the TurtleBot3. +They are documented in the `Webots ROS 2 examples `_ page. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim`, :doc:`../../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` and :doc:`../../../Developer-Tools/Launch/Creating-Launch-Files` are useful prerequisites. + +.. tabs:: + + .. group-tab:: Linux + + The Linux and ROS commands of this tutorial can be run in a standard Linux terminal. + The following page :doc:`Installation-Ubuntu` explains how to install the ``webots_ros2`` package on Linux. + + .. group-tab:: Windows + + The Linux and ROS commands of this tutorial must be run in a WSL (Windows Subsystem for Linux) environment. + The following page :doc:`Installation-Windows` explains how to install the ``webots_ros2`` package on Windows. + + .. group-tab:: macOS + + The Linux and ROS commands of this tutorial must be run in a pre-configured Linux Virtual Machine (VM). + The following page :doc:`Installation-MacOS` explains how to install the ``webots_ros2`` package on macOS. + +This tutorial is compatible with version 2023.1.0 of ``webots_ros2`` and Webots R2023b, as well as upcoming versions. + +Tasks +----- + +1 Create the package structure +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's organize the code in a custom ROS 2 package. +Create a new package named ``my_package`` from the ``src`` folder of your ROS 2 workspace. +Change the current directory of your terminal to ``ros2_ws/src`` and run: + +.. tabs:: + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 --node-name my_robot_driver my_package --dependencies rclpy geometry_msgs webots_ros2_driver + + The ``--node-name my_robot_driver`` option will create a ``my_robot_driver.py`` template Python plugin in the ``my_package`` subfolder that you will modify later. + The ``--dependencies rclpy geometry_msgs webots_ros2_driver`` option specifies the packages needed by the ``my_robot_driver.py`` plugin in the ``package.xml`` file. + + Let's add a ``launch`` and a ``worlds`` folder inside the ``my_package`` folder. + + .. code-block:: console + + $ cd my_package + $ mkdir launch + $ mkdir worlds + + You should end up with the following folder structure: + + .. code-block:: console + + src/ + └── my_package/ + ├── launch/ + ├── my_package/ + │ ├── __init__.py + │ └── my_robot_driver.py + ├── resource/ + │ └── my_package + ├── test/ + │ ├── test_copyright.py + │ ├── test_flake8.py + │ └── test_pep257.py + ├── worlds/ + ├── package.xml + ├── setup.cfg + └── setup.py + + .. group-tab:: C++ + + .. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --node-name MyRobotDriver my_package --dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib + + The ``--node-name MyRobotDriver`` option will create a ``MyRobotDriver.cpp`` template C++ plugin in the ``my_package/src`` subfolder that you will modify later. + The ``--dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib`` option specifies the packages needed by the ``MyRobotDriver`` plugin in the ``package.xml`` file. + + + Let's add a ``launch``, a ``worlds`` and a ``resource`` folder inside the ``my_package`` folder. + + .. code-block:: console + + $ cd my_package + $ mkdir launch + $ mkdir worlds + $ mkdir resource + + Two additional files must be created: the header file for ``MyRobotDriver`` and the ``my_robot_driver.xml`` pluginlib description file. + + .. code-block:: console + + $ touch my_robot_driver.xml + $ touch include/my_package/MyRobotDriver.hpp + + You should end up with the following folder structure: + + .. code-block:: console + + src/ + └── my_package/ + ├── include/ + │ └── my_package/ + │ └── MyRobotDriver.hpp + ├── launch/ + ├── resource/ + ├── src/ + │ └── MyRobotDriver.cpp + ├── worlds/ + ├── CMakeList.txt + ├── my_robot_driver.xml + └── package.xml + +2 Setup the simulation world +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You will need a world file containing a robot to launch your simulation. +:download:`Download this world file ` and move it inside ``my_package/worlds/``. + +This is actually a fairly simple text file you can visualize in a text editor. +A simple robot is already included in this ``my_world.wbt`` world file. + +.. note:: + + In case you want to learn how to create your own robot model in Webots, you can check this `tutorial `_. + +3 Edit the ``my_robot_driver`` plugin +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``webots_ros2_driver`` sub-package automatically creates a ROS 2 interface for most sensors. +More details on existing device interfaces and how to configure them is given in the second part of the tutorial: :doc:`Setting-Up-Simulation-Webots-Advanced`. +In this task, you will extend this interface by creating your own custom plugin. +This custom plugin is a ROS node equivalent to a robot controller. +You can use it to access the `Webots robot API `_ and create your own topics and services to control your robot. + +.. note:: + + The purpose of this tutorial is to show a basic example with a minimum number of dependencies. + However, you could avoid the use of this plugin by using another ``webots_ros2`` sub-package named ``webots_ros2_control``, introducing a new dependency. + This other sub-package creates an interface with the ``ros2_control`` package that facilitates the control of a differential wheeled robot. + + +.. tabs:: + + .. group-tab:: Python + + Open ``my_package/my_package/my_robot_driver.py`` in your favorite editor and replace its contents with the following: + + .. literalinclude:: Code/my_robot_driver.py + :language: python + + As you can see, the ``MyRobotDriver`` class implements three methods. + + The first method, named ``init(self, ...)``, is actually the ROS node counterpart of the Python ``__init__(self, ...)`` constructor. + The ``init`` method always takes two arguments: + + - The ``webots_node`` argument contains a reference on the Webots instance. + - The ``properties`` argument is a dictionary created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows you to pass parameters to the controller. + + The robot instance from the simulation ``self.__robot`` can be used to access the `Webots robot API `_. + Then, it gets the two motor instances and initializes them with a target position and a target velocity. + Finally a ROS node is created and a callback method is registered for a ROS topic named ``/cmd_vel`` that will handle ``Twist`` messages. + + .. literalinclude:: Code/my_robot_driver.py + :language: python + :dedent: 4 + :lines: 8-24 + + Then comes the implementation of the ``__cmd_vel_callback(self, twist)`` callback private method that will be called for each ``Twist`` message received on the ``/cmd_vel`` topic and will save it in the ``self.__target_twist`` member variable. + + .. literalinclude:: Code/my_robot_driver.py + :language: python + :dedent: 4 + :lines: 26-27 + + Finally, the ``step(self)`` method is called at every time step of the simulation. + The call to ``rclpy.spin_once()`` is needed to keep the ROS node running smoothly. + At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``self.__target_twist``. + As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. + This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. + + .. literalinclude:: Code/my_robot_driver.py + :language: python + :dedent: 4 + :lines: 29-39 + + .. group-tab:: C++ + + Open ``my_package/include/my_package/MyRobotDriver.hpp`` in your favorite editor and replace its contents with the following: + + .. literalinclude:: Code/MyRobotDriver.hpp + :language: cpp + + The class ``MyRobotDriver`` is defined, which inherits from the ``webots_ros2_driver::PluginInterface`` class. + The plugin has to override ``step(...)`` and ``init(...)`` functions. + More details are given in the ``MyRobotDriver.cpp`` file. + Several helper methods, callbacks and member variables that will be used internally by the plugin are declared privately. + + Then, open ``my_package/src/MyRobotDriver.cpp`` in your favorite editor and replace its contents with the following: + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + + The ``MyRobotDriver::init`` method is executed once the plugin is loaded by the ``webots_ros2_driver`` package. + It takes two arguments: + + * A pointer to the ``WebotsNode`` defined by ``webots_ros2_driver``, which allows to access the ROS 2 node functions. + * The ``parameters`` argument is an unordered map of strings, created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows to pass parameters to the controller. + It is not used in this example. + + It initializes the plugin by setting up the robot motors, setting their positions and velocities, and subscribing to the ``/cmd_vel`` topic. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 13-33 + + The subscription callback is declared as a lambda function, that will be called for each Twist message received on the ``/cmd_vel`` topic and will save it in the ``cmd_vel_msg`` member variable. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 28-31 + + The ``step()`` method is called at every time step of the simulation. + At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``cmd_vel_msg``. + As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. + This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 35-48 + + The final lines of the file define the end of the ``my_robot_driver`` namespace and include a macro to export the ``MyRobotDriver`` class as a plugin using the ``PLUGINLIB_EXPORT_CLASS`` macro. + This allows the plugin to be loaded by the Webots ROS2 driver at runtime. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 51-53 + + .. note:: + + While the plugin is implemented in C++, the C API must be used to interact with the Webots controller library. + +.. _4 Create the my_robot.urdf file: + +4 Create the ``my_robot.urdf`` file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You now have to create a URDF file to declare the ``MyRobotDriver`` plugin. +This will allow the ``webots_ros2_driver`` ROS node to launch the plugin and connect it to the target robot. + +In the ``my_package/resource`` folder create a text file named ``my_robot.urdf`` with this content: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: Code/my_robot_python.urdf + :language: xml + + The ``type`` attribute specifies the path to the class given by the hierarchical structure of files. + ``webots_ros2_driver`` is responsible for loading the class based on the specified package and modules. + + .. group-tab:: C++ + + .. literalinclude:: Code/my_robot_cpp.urdf + :language: xml + + The ``type`` attribute specifies the namespace and class name to load. + ``pluginlib`` is responsible for loading the class based on the specified information. + +.. note:: + + This simple URDF file doesn't contain any link or joint information about the robot as it is not needed in this tutorial. + However, URDF files usually contain much more information as explained in the :doc:`../../../Capabilities/Simulation/URDF/URDF-Main` tutorial. + +.. note:: + + Here the plugin does not take any input parameter, but this can be achieved with a tag containing the parameter name. + + .. tabs:: + + .. group-tab:: Python + + .. code-block:: xml + + + someValue + + + .. group-tab:: C++ + + .. code-block:: xml + + + someValue + + + + This is namely used to pass parameters to existing Webots device plugins (see :doc:`Setting-Up-Simulation-Webots-Advanced`). + +5 Create the launch file +^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's create the launch file to easily launch the simulation and the ROS controller with a single command. +In the ``my_package/launch`` folder create a new text file named ``robot_launch.py`` with this code: + +.. literalinclude:: Code/robot_launch.py + :language: python + +The ``WebotsLauncher`` object is a custom action that allows you to start a Webots simulation instance. +You have to specify in the constructor which world file the simulator will open. + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 4 + :lines: 13-15 + +Then, the ROS node interacting with the simulated robot is created. +This node, named ``WebotsController``, is located in the ``webots_ros2_driver`` package. + +.. tabs:: + + .. group-tab:: Linux + + The node will be able to communicate with the simulated robot by using a custom protocol based on IPC and shared memory. + + .. group-tab:: Windows + + The node (in WSL) will be able to communicate with the simulated robot (in Webots on native Windows) through a TCP connection. + + .. group-tab:: macOS + + The node (in the docker container) will be able to communicate with the simulated robot (in Webots on native macOS) through a TCP connection. + + +In your case, you need to run a single instance of this node, because you have a single robot in the simulation. +But if you had more robots in the simulation, you would have to run one instance of this node per robot. +The ``robot_name`` parameter is used to define the name of the robot the driver should connect to. +The ``robot_description`` parameter holds the path to the URDF file which refers to the ``MyRobotDriver`` plugin. +You can see the ``WebotsController`` node as the interface that connects your controller plugin to the target robot. + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 4 + :lines: 17-22 + +After that, the two nodes are set to be launched in the ``LaunchDescription`` constructor: + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 4 + :lines: 24-26 + +Finally, an optional part is added in order to shutdown all the nodes once Webots terminates (e.g. when it gets closed from the graphical user interface). + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 8 + :lines: 27-32 + +.. note:: + + More details on ``WebotsController`` and ``WebotsLauncher`` arguments can be found `on the nodes reference page `_. + +6 Edit additional files +^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Python + + Before you can start the launch file, you have to modify the ``setup.py`` file to include the extra files you added. + Open ``my_package/setup.py`` and replace its contents with: + + .. literalinclude:: Code/setup.py + :language: python + + This sets-up the package and adds in the ``data_files`` variable the newly added files: ``my_world.wbt``, ``my_robot.urdf`` and ``robot_launch.py``. + + .. group-tab:: C++ + + Before you can start the launch file, you have to modify ``CMakeLists.txt`` and ``my_robot_driver.xml`` files: + + * ``CMakeLists.txt`` defines the compilation rules of your plugin. + * ``my_robot_driver.xml`` is necessary for the pluginlib to find your Webots ROS 2 plugin. + + Open ``my_package/my_robot_driver.xml`` and replace its contents with: + + .. literalinclude:: Code/my_robot_driver.xml + :language: xml + + Open ``my_package/CMakeLists.txt`` and replace its contents with: + + .. literalinclude:: Code/CMakeLists.txt + :language: cmake + + The CMakeLists.txt exports the plugin configuration file with the ``pluginlib_export_plugin_description_file()``, defines a shared library of the C++ plugin ``src/MyRobotDriver.cpp``, and sets the include and library dependencies using ``target_link_libraries()``. + + The file then installs the library, the directories ``launch``, ``resource``, and ``worlds`` to the ``share/my_package`` directory. + Finally, it exports the include directories and libraries using ``ament_export_include_directories()`` and ``ament_export_libraries()``, respectively, and declares the package using ``ament_package()``. + + +7 Test the code +^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Linux + + From a terminal in your ROS 2 workspace run: + + .. code-block:: console + + $ colcon build + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + This will launch the simulation. + Webots will be automatically installed on the first run in case it was not already installed. + + .. group-tab:: Windows + + From a terminal in your WSL ROS 2 workspace run: + + .. code-block:: console + + $ colcon build + $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + Be sure to use the ``/mnt`` prefix in front of your path to the Webots installation folder to access the Windows file system from WSL. + + This will launch the simulation. + Webots will be automatically installed on the first run in case it was not already installed. + + .. group-tab:: macOS + + On macOS, a local server must be started on the host to start Webots from the VM. + The local server can be downloaded `on the webots-server repository `_. + + In a terminal of the host machine (not in the VM), specify the Webots installation folder (e.g. ``/Applications/Webots.app``) and start the server using the following commands: + + .. code-block:: console + + $ export WEBOTS_HOME=/Applications/Webots.app + $ python3 local_simulation_server.py + + From a terminal in the Linux VM in your ROS 2 workspace, build and launch your custom package with: + + .. code-block:: console + + $ colcon build + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + +.. note:: + + If you want to install Webots manually, you can download it `here `_. + + +Then, open a second terminal and send a command with: + +.. code-block:: console + + $ ros2 topic pub /cmd_vel geometry_msgs/Twist "linear: { x: 0.1 }" + +The robot is now moving forward. + +.. image:: Image/Robot_moving_forward.png + +At this point, the robot is able to blindly follow your motor commands. +But it will eventually bump into the wall as you order it to move forwards. + +.. image:: Image/Robot_colliding_wall.png + +Close the Webots window, this should also shutdown your ROS nodes started from the launcher. +Close also the topic command with ``Ctrl+C`` in the second terminal. + +Summary +------- + +In this tutorial, you set-up a realistic robot simulation with Webots and implemented a custom plugin to control the motors of the robot. + +Next steps +---------- + +To improve the simulation, the robot's sensors can be used to detect obstacles and avoid them. +The second part of the tutorial shows how to implement such behaviour: + +* :doc:`Setting-Up-Simulation-Webots-Advanced`. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst b/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst index 4a20c781177..1735d800ce0 100644 --- a/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst +++ b/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst @@ -1,193 +1,197 @@ -Setting up a Reset Handler -========================== - -**Goal:** Extend a robot simulation with a reset handler to restart nodes when the reset button of Webots is pressed. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial, you will learn how to implement a reset handler in a robot simulation using Webots. -The Webots reset button reverts the world to the initial state and restarts controllers. -It is convenient as it quickly resets the simulation, but in the context of ROS 2, robot controllers are not started again making the simulation stop. -The reset handler allows you to restart specific nodes or perform additional actions when the reset button in Webots is pressed. -This can be useful for scenarios where you need to reset the state of your simulation or restart specific components without completely restarting the complete ROS system. - -Prerequisites -------------- - -Before proceeding with this tutorial, make sure you have completed the following: - -- Understanding of ROS 2 nodes and topics covered in the beginner :doc:`../../../../Tutorials`. -- Knowledge of Webots and ROS 2 and its interface package. -- Familiarity with :doc:`./Setting-Up-Simulation-Webots-Basic`. - - -Reset Handler for Simple Cases (Controllers Only) -------------------------------------------------- - -In the launch file of your package, add the ``respawn`` parameter. - -.. code-block:: python - - def generate_launch_description(): - robot_driver = WebotsController( - robot_name='my_robot', - parameters=[ - {'robot_description': robot_description_path} - ], - - # Every time one resets the simulation the controller is automatically respawned - respawn=True - ) - - # Starts Webots - webots = WebotsLauncher(world=PathJoinSubstitution([package_dir, 'worlds', world])) - - return LaunchDescription([ - webots, - robot_driver - ]) - -On reset, Webots kills all driver nodes. -Therefore, to start them again after reset, you should set the ``respawn`` property of the driver node to ``True``. -It will ensure driver nodes are up and running after the reset. - -Reset Handler for Multiple Nodes (No Shutdown Required) -------------------------------------------------------- - -If you have some other nodes that have to be started along with the driver node (e.g. ``ros2_control`` nodes), then you can use the ``OnProcessExit`` event handler: - -.. code-block:: python - - def get_ros2_control_spawners(*args): - # Declare here all nodes that must be restarted at simulation reset - ros_control_node = Node( - package='controller_manager', - executable='spawner', - arguments=['diffdrive_controller'] - ) - return [ - ros_control_node - ] - - def generate_launch_description(): - robot_driver = WebotsController( - robot_name='my_robot', - parameters=[ - {'robot_description': robot_description_path} - ], - - # Every time one resets the simulation the controller is automatically respawned - respawn=True - ) - - # Starts Webots - webots = WebotsLauncher(world=PathJoinSubstitution([package_dir, 'worlds', world])) - - # Declare the reset handler that respawns nodes when robot_driver exits - reset_handler = launch.actions.RegisterEventHandler( - event_handler=launch.event_handlers.OnProcessExit( - target_action=robot_driver, - on_exit=get_ros2_control_spawners, - ) - ) - - return LaunchDescription([ - webots, - robot_driver, - reset_handler - ] + get_ros2_control_spawners()) - -It is not possible to use the ``respawn`` property on the ``ros2_control`` node, as the spawner exits during launch time and not when the simulation is reset. -Instead we should declare a list of nodes in a function (e.g. ``get_ros2_control_spawners``). -The nodes of this list are started along other nodes when executing the launch file. -With the ``reset_handler``, the function is also declared as action to start when the ``robot_driver`` node exits, which corresponds to the moment when the simulation is reset in the Webots interface. -The ``robot_driver`` node still has the ``respawn`` property set to ``True``, so that it gets restarted along with ``ros2_control`` nodes. - -Reset Handler Requiring Node Shutdown -------------------------------------- - -With the current ROS 2 launch API, there is no way to make the reset work in launch files where nodes need to be shutdown before the restart (e.g. ``Nav2`` or ``RViz``). -The reason is that currently, ROS 2 doesn't allow to shutdown specific nodes from a launch file. -There is a solution, but it requires to manually restart nodes after pushing the reset button. - -Webots needs to be started in a specific launch file without other nodes. - -.. code-block:: python - - def generate_launch_description(): - # Starts Webots - webots = WebotsLauncher(world=PathJoinSubstitution([package_dir, 'worlds', world])) - - return LaunchDescription([ - webots - ]) - - -A second launch file must be started from another process. -This launch file contains all other nodes, including robot controllers/plugins, Navigation2 nodes, RViz, state publishers, etc. - -.. code-block:: python - - def generate_launch_description(): - robot_driver = WebotsController( - robot_name='my_robot', - parameters=[ - {'robot_description': robot_description_path} - ] - ) - - ros_control_node = Node( - package='controller_manager', - executable='spawner', - arguments=['diffdrive_controller'] - ) - - nav2_node = IncludeLaunchDescription( - PythonLaunchDescriptionSource(os.path.join( - get_package_share_directory('nav2_bringup'), 'launch', 'bringup_launch.py')), - launch_arguments=[ - ('map', nav2_map), - ('params_file', nav2_params), - ], - ) - - rviz = Node( - package='rviz2', - executable='rviz2', - output='screen' - ) - - # Declare the handler that shuts all nodes down when robot_driver exits - shutdown_handler = launch.actions.RegisterEventHandler( - event_handler=launch.event_handlers.OnProcessExit( - target_action=robot_driver, - on_exit=[launch.actions.EmitEvent(event=launch.events.Shutdown())], - ) - ) - - return LaunchDescription([ - robot_driver, - ros_control_node, - nav2_node, - rviz, - shutdown_handler - ]) - -The second launch file contains a handler that triggers a shutdown event when the driver node exits (which is the case when the simulation is reset). -This second launch file must be manually restarted from the command line after pressing the reset button. - -Summary -------- - -In this tutorial, you learned how to implement a reset handler in a robot simulation using Webots. -The reset handler allows you to restart specific nodes or perform additional actions when the reset button in Webots is pressed. -You explored different approaches based on the complexity of your simulation and the requirements of your nodes. +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Simulation-Reset-Handler + +Setting up a Reset Handler +========================== + +**Goal:** Extend a robot simulation with a reset handler to restart nodes when the reset button of Webots is pressed. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial, you will learn how to implement a reset handler in a robot simulation using Webots. +The Webots reset button reverts the world to the initial state and restarts controllers. +It is convenient as it quickly resets the simulation, but in the context of ROS 2, robot controllers are not started again making the simulation stop. +The reset handler allows you to restart specific nodes or perform additional actions when the reset button in Webots is pressed. +This can be useful for scenarios where you need to reset the state of your simulation or restart specific components without completely restarting the complete ROS system. + +Prerequisites +------------- + +Before proceeding with this tutorial, make sure you have completed the following: + +- Understanding of ROS 2 nodes and topics covered in the beginner :doc:`../../../Tutorials`. +- Knowledge of Webots and ROS 2 and its interface package. +- Familiarity with :doc:`Setting-Up-Simulation-Webots-Basic`. + + +Reset Handler for Simple Cases (Controllers Only) +------------------------------------------------- + +In the launch file of your package, add the ``respawn`` parameter. + +.. code-block:: python + + def generate_launch_description(): + robot_driver = WebotsController( + robot_name='my_robot', + parameters=[ + {'robot_description': robot_description_path} + ], + + # Every time one resets the simulation the controller is automatically respawned + respawn=True + ) + + # Starts Webots + webots = WebotsLauncher(world=PathJoinSubstitution([package_dir, 'worlds', world])) + + return LaunchDescription([ + webots, + robot_driver + ]) + +On reset, Webots kills all driver nodes. +Therefore, to start them again after reset, you should set the ``respawn`` property of the driver node to ``True``. +It will ensure driver nodes are up and running after the reset. + +Reset Handler for Multiple Nodes (No Shutdown Required) +------------------------------------------------------- + +If you have some other nodes that have to be started along with the driver node (e.g. ``ros2_control`` nodes), then you can use the ``OnProcessExit`` event handler: + +.. code-block:: python + + def get_ros2_control_spawners(*args): + # Declare here all nodes that must be restarted at simulation reset + ros_control_node = Node( + package='controller_manager', + executable='spawner', + arguments=['diffdrive_controller'] + ) + return [ + ros_control_node + ] + + def generate_launch_description(): + robot_driver = WebotsController( + robot_name='my_robot', + parameters=[ + {'robot_description': robot_description_path} + ], + + # Every time one resets the simulation the controller is automatically respawned + respawn=True + ) + + # Starts Webots + webots = WebotsLauncher(world=PathJoinSubstitution([package_dir, 'worlds', world])) + + # Declare the reset handler that respawns nodes when robot_driver exits + reset_handler = launch.actions.RegisterEventHandler( + event_handler=launch.event_handlers.OnProcessExit( + target_action=robot_driver, + on_exit=get_ros2_control_spawners, + ) + ) + + return LaunchDescription([ + webots, + robot_driver, + reset_handler + ] + get_ros2_control_spawners()) + +It is not possible to use the ``respawn`` property on the ``ros2_control`` node, as the spawner exits during launch time and not when the simulation is reset. +Instead we should declare a list of nodes in a function (e.g. ``get_ros2_control_spawners``). +The nodes of this list are started along other nodes when executing the launch file. +With the ``reset_handler``, the function is also declared as action to start when the ``robot_driver`` node exits, which corresponds to the moment when the simulation is reset in the Webots interface. +The ``robot_driver`` node still has the ``respawn`` property set to ``True``, so that it gets restarted along with ``ros2_control`` nodes. + +Reset Handler Requiring Node Shutdown +------------------------------------- + +With the current ROS 2 launch API, there is no way to make the reset work in launch files where nodes need to be shutdown before the restart (e.g. ``Nav2`` or ``RViz``). +The reason is that currently, ROS 2 doesn't allow to shutdown specific nodes from a launch file. +There is a solution, but it requires to manually restart nodes after pushing the reset button. + +Webots needs to be started in a specific launch file without other nodes. + +.. code-block:: python + + def generate_launch_description(): + # Starts Webots + webots = WebotsLauncher(world=PathJoinSubstitution([package_dir, 'worlds', world])) + + return LaunchDescription([ + webots + ]) + + +A second launch file must be started from another process. +This launch file contains all other nodes, including robot controllers/plugins, Navigation2 nodes, RViz, state publishers, etc. + +.. code-block:: python + + def generate_launch_description(): + robot_driver = WebotsController( + robot_name='my_robot', + parameters=[ + {'robot_description': robot_description_path} + ] + ) + + ros_control_node = Node( + package='controller_manager', + executable='spawner', + arguments=['diffdrive_controller'] + ) + + nav2_node = IncludeLaunchDescription( + PythonLaunchDescriptionSource(os.path.join( + get_package_share_directory('nav2_bringup'), 'launch', 'bringup_launch.py')), + launch_arguments=[ + ('map', nav2_map), + ('params_file', nav2_params), + ], + ) + + rviz = Node( + package='rviz2', + executable='rviz2', + output='screen' + ) + + # Declare the handler that shuts all nodes down when robot_driver exits + shutdown_handler = launch.actions.RegisterEventHandler( + event_handler=launch.event_handlers.OnProcessExit( + target_action=robot_driver, + on_exit=[launch.actions.EmitEvent(event=launch.events.Shutdown())], + ) + ) + + return LaunchDescription([ + robot_driver, + ros_control_node, + nav2_node, + rviz, + shutdown_handler + ]) + +The second launch file contains a handler that triggers a shutdown event when the driver node exits (which is the case when the simulation is reset). +This second launch file must be manually restarted from the command line after pressing the reset button. + +Summary +------- + +In this tutorial, you learned how to implement a reset handler in a robot simulation using Webots. +The reset handler allows you to restart specific nodes or perform additional actions when the reset button in Webots is pressed. +You explored different approaches based on the complexity of your simulation and the requirements of your nodes. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst b/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst index 8432ecbdb13..34286484aaf 100644 --- a/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst +++ b/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst @@ -1,145 +1,149 @@ -The Ros2Supervisor Node -======================= - -**Goal:** Extend the interface with a default Supervisor robot, named ``Ros2Supervisor``. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial, you will learn how to enable the ``Ros2Supervisor`` node which enhances the interface by creating additional services and topics to interact with the simulation. -You can, for example, record animations or spawn Webots nodes directly from the ROS 2 interface while the simulation is running. -These instructions list in detail the current implemented features and how to use them. - -Prerequisites -------------- - -Before proceeding with this tutorial, make sure you have completed the following: - -- Understanding of ROS 2 nodes and topics covered in the beginner :doc:`../../../../Tutorials`. -- Knowledge of Webots and ROS 2 and its interface package. -- Familiarity with :doc:`./Setting-Up-Simulation-Webots-Basic`. - -The ``Ros2Supervisor`` ----------------------- - -The ``Ros2Supervisor`` is made of two main parts: - -* A Webots Robot node added to the simulation world. - Its ``supervisor`` field is set to TRUE. -* A ROS 2 node that connects to the Webots Robot as an external controller (in a similar way to your own robot plugin). - -The ROS 2 node acts as a controller that calls Supervisor API functions to control or interact with the simulation world. -User interactions with the ROS 2 node are mainly performed through services and topics. - -These nodes can be automatically created at the Webots launch using the ``ros2_supervisor`` parameter in the ``WebotsLauncher``. - -.. code-block:: python - - webots = WebotsLauncher( - world=PathJoinSubstitution([package_dir, 'worlds', world]), - mode=mode, - ros2_supervisor=True - ) - -The ``webots._supervisor`` object must also be included in the ``LaunchDescription`` returned by the launch file. - -.. code-block:: python - - return LaunchDescription([ - webots, - webots._supervisor, - - # This action will kill all nodes once the Webots simulation has exited - launch.actions.RegisterEventHandler( - event_handler=launch.event_handlers.OnProcessExit( - target_action=webots, - on_exit=[ - launch.actions.EmitEvent(event=launch.events.Shutdown()) - ], - ) - ) - ]) - -More information about launch files for ``webots_ros2`` projects can be found in :doc:`./Setting-Up-Simulation-Webots-Basic`. - -Clock topic ------------ - -The ``Ros2Supervisor`` node is responsible to get the time of the Webots simulation and publish it to the ``/clock`` topic. -This means that it is mandatory to spawn the ``Ros2Supervisor`` if some other nodes have their ``use_sim_time`` parameter set to ``true``. -More information about the ``/clock`` topic can be found in the `ROS wiki `_. - -Import a Webots node --------------------- - -The ``Ros2Supervisor`` node also allows you to spawn Webots nodes from strings through a service. - -The service is named ``/Ros2Supervisor/spawn_node_from_string`` and is of type ``webots_ros2_msgs/srv/SpawnNodeFromString``. -The ``SpawnNodeFromString`` type expects a ``data`` string as input and returns a ``success`` boolean. - -From the given string, the Supervisor node is getting the name of the imported node and adding it to an internal list for potential later removal (see :ref:`Remove a Webots imported node`). - -The node is imported using the ``importMFNodeFromString(nodeString)`` `API function `_. - -Here is an example to import a simple Robot named ``imported_robot``: - -.. code-block:: console - - $ ros2 service call /Ros2Supervisor/spawn_node_from_string webots_ros2_msgs/srv/SpawnNodeFromString "data: Robot { name \"imported_robot\" }" - -.. note:: - If you try to import some PROTOs in the node string, their respective URLs must be declared in the ``.wbt`` world file as EXTERNPROTO or as IMPORTABLE EXTERNPROTO. - -.. _Remove a Webots imported node: - -Remove a Webots imported node ------------------------------ - -Once a node has been imported with the ``/Ros2Supervisor/spawn_node_from_string`` service, it can also be removed. - -This can be achieved by sending the name of the node to the topic named ``/Ros2Supervisor/remove_node`` of type ``std_msgs/msg/String``. - -If the node is indeed in the imported list, it is removed with the ``remove()`` `API method `_. - -Here is an example on how to remove the ``imported_robot`` Robot: - -.. code-block:: console - - $ ros2 topic pub --once /Ros2Supervisor/remove_node std_msgs/msg/String "{data: imported_robot}" - -Record animations ------------------ - -The ``Ros2Supervisor`` node also creates two additional services to record HTML5 animations. - -The ``/Ros2Supervisor/animation_start_recording`` service is of type ``webots_ros2_msgs/srv/SetString`` and allows to start the animation. -The ``SetString`` type expects a ``value`` string as input and returns a ``success`` boolean. -The input ``value`` represents the absolute path to the directory where the animations files should be saved. - -Here is an example on how to start an animation: - -.. code-block:: console - - $ ros2 service call /Ros2Supervisor/animation_start_recording webots_ros2_msgs/srv/SetString "{value: "/index.html"}" - - -The ``/Ros2Supervisor/animation_stop_recording`` service is of type ``webots_ros2_msgs/srv/GetBool`` and allows to stop the animation. - -.. code-block:: console - - $ ros2 service call /Ros2Supervisor/animation_stop_recording webots_ros2_msgs/srv/GetBool "{ask: True}" - - -Summary -------- - -In this tutorial, you learned how to enable the ``Ros2Supervisor`` and how to extend the interface with the Webots simulation. -The node creates multiple services and topics to interact with and modify the simulation. +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Simulation-Supervisor + +The Ros2Supervisor Node +======================= + +**Goal:** Extend the interface with a default Supervisor robot, named ``Ros2Supervisor``. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial, you will learn how to enable the ``Ros2Supervisor`` node which enhances the interface by creating additional services and topics to interact with the simulation. +You can, for example, record animations or spawn Webots nodes directly from the ROS 2 interface while the simulation is running. +These instructions list in detail the current implemented features and how to use them. + +Prerequisites +------------- + +Before proceeding with this tutorial, make sure you have completed the following: + +- Understanding of ROS 2 nodes and topics covered in the beginner :doc:`../../../Tutorials`. +- Knowledge of Webots and ROS 2 and its interface package. +- Familiarity with :doc:`Setting-Up-Simulation-Webots-Basic`. + +The ``Ros2Supervisor`` +---------------------- + +The ``Ros2Supervisor`` is made of two main parts: + +* A Webots Robot node added to the simulation world. + Its ``supervisor`` field is set to TRUE. +* A ROS 2 node that connects to the Webots Robot as an external controller (in a similar way to your own robot plugin). + +The ROS 2 node acts as a controller that calls Supervisor API functions to control or interact with the simulation world. +User interactions with the ROS 2 node are mainly performed through services and topics. + +These nodes can be automatically created at the Webots launch using the ``ros2_supervisor`` parameter in the ``WebotsLauncher``. + +.. code-block:: python + + webots = WebotsLauncher( + world=PathJoinSubstitution([package_dir, 'worlds', world]), + mode=mode, + ros2_supervisor=True + ) + +The ``webots._supervisor`` object must also be included in the ``LaunchDescription`` returned by the launch file. + +.. code-block:: python + + return LaunchDescription([ + webots, + webots._supervisor, + + # This action will kill all nodes once the Webots simulation has exited + launch.actions.RegisterEventHandler( + event_handler=launch.event_handlers.OnProcessExit( + target_action=webots, + on_exit=[ + launch.actions.EmitEvent(event=launch.events.Shutdown()) + ], + ) + ) + ]) + +More information about launch files for ``webots_ros2`` projects can be found in :doc:`Setting-Up-Simulation-Webots-Basic`. + +Clock topic +----------- + +The ``Ros2Supervisor`` node is responsible to get the time of the Webots simulation and publish it to the ``/clock`` topic. +This means that it is mandatory to spawn the ``Ros2Supervisor`` if some other nodes have their ``use_sim_time`` parameter set to ``true``. +More information about the ``/clock`` topic can be found in the `ROS wiki `_. + +Import a Webots node +-------------------- + +The ``Ros2Supervisor`` node also allows you to spawn Webots nodes from strings through a service. + +The service is named ``/Ros2Supervisor/spawn_node_from_string`` and is of type ``webots_ros2_msgs/srv/SpawnNodeFromString``. +The ``SpawnNodeFromString`` type expects a ``data`` string as input and returns a ``success`` boolean. + +From the given string, the Supervisor node is getting the name of the imported node and adding it to an internal list for potential later removal (see :ref:`Remove a Webots imported node`). + +The node is imported using the ``importMFNodeFromString(nodeString)`` `API function `_. + +Here is an example to import a simple Robot named ``imported_robot``: + +.. code-block:: console + + $ ros2 service call /Ros2Supervisor/spawn_node_from_string webots_ros2_msgs/srv/SpawnNodeFromString "data: Robot { name \"imported_robot\" }" + +.. note:: + If you try to import some PROTOs in the node string, their respective URLs must be declared in the ``.wbt`` world file as EXTERNPROTO or as IMPORTABLE EXTERNPROTO. + +.. _Remove a Webots imported node: + +Remove a Webots imported node +----------------------------- + +Once a node has been imported with the ``/Ros2Supervisor/spawn_node_from_string`` service, it can also be removed. + +This can be achieved by sending the name of the node to the topic named ``/Ros2Supervisor/remove_node`` of type ``std_msgs/msg/String``. + +If the node is indeed in the imported list, it is removed with the ``remove()`` `API method `_. + +Here is an example on how to remove the ``imported_robot`` Robot: + +.. code-block:: console + + $ ros2 topic pub --once /Ros2Supervisor/remove_node std_msgs/msg/String "{data: imported_robot}" + +Record animations +----------------- + +The ``Ros2Supervisor`` node also creates two additional services to record HTML5 animations. + +The ``/Ros2Supervisor/animation_start_recording`` service is of type ``webots_ros2_msgs/srv/SetString`` and allows to start the animation. +The ``SetString`` type expects a ``value`` string as input and returns a ``success`` boolean. +The input ``value`` represents the absolute path to the directory where the animations files should be saved. + +Here is an example on how to start an animation: + +.. code-block:: console + + $ ros2 service call /Ros2Supervisor/animation_start_recording webots_ros2_msgs/srv/SetString "{value: "/index.html"}" + + +The ``/Ros2Supervisor/animation_stop_recording`` service is of type ``webots_ros2_msgs/srv/GetBool`` and allows to stop the animation. + +.. code-block:: console + + $ ros2 service call /Ros2Supervisor/animation_stop_recording webots_ros2_msgs/srv/GetBool "{ask: True}" + + +Summary +------- + +In this tutorial, you learned how to enable the ``Ros2Supervisor`` and how to extend the interface with the Webots simulation. +The node creates multiple services and topics to interact with and modify the simulation. \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst b/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst index 6120e8b1456..bf5803bcdce 100644 --- a/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst +++ b/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst @@ -1,19 +1,23 @@ -Webots -====== - -This set of tutorials will teach you how to configure the Webots simulator with ROS 2. - -.. contents:: Contents - :depth: 2 - :local: - -.. toctree:: - :maxdepth: 1 - - Installation-Ubuntu - Installation-Windows - Installation-MacOS - Setting-Up-Simulation-Webots-Basic - Setting-Up-Simulation-Webots-Advanced - Simulation-Reset-Handler - Simulation-Supervisor +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Simulation-Webots + +Webots +====== + +This set of tutorials will teach you how to configure the Webots simulator with ROS 2. + +.. contents:: Contents + :depth: 2 + :local: + +.. toctree:: + :maxdepth: 1 + + Installation-Ubuntu + Installation-Windows + Installation-MacOS + Setting-Up-Simulation-Webots-Basic + Setting-Up-Simulation-Webots-Advanced + Simulation-Reset-Handler + Simulation-Supervisor \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1.rst index 6b095ca63f8..45ea0433c43 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1.rst @@ -1,29 +1,33 @@ -Migrating from ROS 1 to ROS 2 -============================= - -These guides show how to convert existing ROS 1 packages to ROS 2. -If you are new to porting between ROS 1 and ROS 2, it is recommended to read through the guides in order. - -.. toctree:: - :maxdepth: 1 - - Migrating-from-ROS1/Migrating-Packages - Migrating-from-ROS1/Migrating-Package-XML - Migrating-from-ROS1/Migrating-Interfaces - Migrating-from-ROS1/Migrating-CPP-Package-Example - Migrating-from-ROS1/Migrating-CPP-Packages - Migrating-from-ROS1/Migrating-Python-Package-Example - Migrating-from-ROS1/Migrating-Python-Packages - Migrating-from-ROS1/Migrating-Launch-Files - Migrating-from-ROS1/Migrating-Parameters - Migrating-from-ROS1/Migrating-Scripts - -Automatic tools ---------------- - -There are also some automatic conversion tools that exist, though they are not exhaustive: - -* `Magical ROS 2 Conversion Tool `_ -* Launch File migrator that converts a ROS 1 XML launch file to a ROS 2 Python launch file: https://github.com/aws-robotics/ros2-launch-file-migrator -* Amazon has made their tools for porting from ROS 1 to ROS 2 available at: https://github.com/awslabs/ros2-migration-tools/tree/master/porting\_tools -* `rospy2 `_ Python project to automatically convert rospy calls to rclpy calls +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1 + +Migrating from ROS 1 to ROS 2 +============================= + +These guides show how to convert existing ROS 1 packages to ROS 2. +If you are new to porting between ROS 1 and ROS 2, it is recommended to read through the guides in order. + +.. toctree:: + :maxdepth: 1 + + Migrating-from-ROS1/Migrating-Packages + Migrating-from-ROS1/Migrating-Package-XML + Migrating-from-ROS1/Migrating-Interfaces + Migrating-from-ROS1/Migrating-CPP-Package-Example + Migrating-from-ROS1/Migrating-CPP-Packages + Migrating-from-ROS1/Migrating-Python-Package-Example + Migrating-from-ROS1/Migrating-Python-Packages + Migrating-from-ROS1/Migrating-Launch-Files + Migrating-from-ROS1/Migrating-Parameters + Migrating-from-ROS1/Migrating-Scripts + +Automatic tools +--------------- + +There are also some automatic conversion tools that exist, though they are not exhaustive: + +* `Magical ROS 2 Conversion Tool `_ +* Launch File migrator that converts a ROS 1 XML launch file to a ROS 2 Python launch file: https://github.com/aws-robotics/ros2-launch-file-migrator +* Amazon has made their tools for porting from ROS 1 to ROS 2 available at: https://github.com/awslabs/ros2-migration-tools/tree/master/porting\_tools +* `rospy2 `_ Python project to automatically convert rospy calls to rclpy calls \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst index 09893d4141f..616d2de3e20 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst @@ -1,439 +1,443 @@ -Migrating a C++ Package Example -=============================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -This example shows how to migrate an example C++ package from ROS 1 to ROS 2. - -Prerequisites -------------- - -You need a working ROS 2 installation, such as :doc:`ROS {DISTRO} <../../Installation>`. - -The ROS 1 code --------------- - -Say you have a ROS 1 package called ``talker`` that uses ``roscpp`` in one node, called ``talker``. -This package is in a catkin workspace, located at ``~/ros1_talker``. - -Your ROS 1 workspace has the following directory layout: - -.. code-block:: console - - $ cd ~/ros1_talker - $ find . - . - ./src - ./src/talker - ./src/talker/package.xml - ./src/talker/CMakeLists.txt - ./src/talker/talker.cpp - -The files have the following content: - -``src/talker/package.xml``: - -.. code-block:: xml - - - - - talker - 0.0.0 - talker - Brian Gerkey - Apache-2.0 - catkin - roscpp - std_msgs - - -``src/talker/CMakeLists.txt``: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 2.8.3) - project(talker) - find_package(catkin REQUIRED COMPONENTS roscpp std_msgs) - catkin_package() - include_directories(${catkin_INCLUDE_DIRS}) - add_executable(talker talker.cpp) - target_link_libraries(talker ${catkin_LIBRARIES}) - install(TARGETS talker - RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}) - -``src/talker/talker.cpp``: - -.. code-block:: cpp - - #include - #include "ros/ros.h" - #include "std_msgs/String.h" - int main(int argc, char **argv) - { - ros::init(argc, argv, "talker"); - ros::NodeHandle n; - ros::Publisher chatter_pub = n.advertise("chatter", 1000); - ros::Rate loop_rate(10); - int count = 0; - std_msgs::String msg; - while (ros::ok()) - { - std::stringstream ss; - ss << "hello world " << count++; - msg.data = ss.str(); - ROS_INFO("%s", msg.data.c_str()); - chatter_pub.publish(msg); - ros::spinOnce(); - loop_rate.sleep(); - } - return 0; - } - -Migrating to ROS 2 ------------------- - -Let's start by creating a new workspace in which to work: - -.. code-block:: console - - $ mkdir ~/ros2_talker - $ cd ~/ros2_talker - -We'll copy the source tree from our ROS 1 package into that workspace, where we can modify it: - -.. code-block:: console - - $ mkdir src - $ cp -a ~/ros1_talker/src/talker src - -Now we'll modify the C++ code in the node. -The ROS 2 C++ library, called ``rclcpp``, provides a different API from that -provided by ``roscpp``. -The concepts are very similar between the two libraries, which makes the changes -reasonably straightforward to make. - -Included headers -~~~~~~~~~~~~~~~~ - -In place of ``ros/ros.h``, which gave us access to the ``roscpp`` library API, we -need to include ``rclcpp/rclcpp.hpp``, which gives us access to the ``rclcpp`` -library API: - -.. code-block:: cpp - - //#include "ros/ros.h" - #include "rclcpp/rclcpp.hpp" - -To get the ``std_msgs/String`` message definition, in place of -``std_msgs/String.h``, we need to include ``std_msgs/msg/string.hpp``: - -.. code-block:: cpp - - //#include "std_msgs/String.h" - #include "std_msgs/msg/string.hpp" - -Changing C++ library calls -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Instead of passing the node's name to the library initialization call, we do -the initialization, then pass the node name to the creation of the node object: - -.. code-block:: cpp - - // ros::init(argc, argv, "talker"); - // ros::NodeHandle n; - rclcpp::init(argc, argv); - auto node = rclcpp::Node::make_shared("talker"); - -The creation of the publisher and rate objects looks pretty similar, with some -changes to the names of namespace and methods. - -.. code-block:: cpp - - // ros::Publisher chatter_pub = n.advertise("chatter", 1000); - // ros::Rate loop_rate(10); - auto chatter_pub = node->create_publisher("chatter", - 1000); - rclcpp::Rate loop_rate(10); - -To further control how message delivery is handled, a quality of service -(``QoS``) profile could be passed in. -The default profile is ``rmw_qos_profile_default``. -For more details, see the -`design document `__ -and :doc:`concept overview <../../Concepts/Intermediate/About-Quality-of-Service-Settings>`. - -The creation of the outgoing message is different in the namespace: - -.. code-block:: cpp - - // std_msgs::String msg; - std_msgs::msg::String msg; - -In place of ``ros::ok()``, we call ``rclcpp::ok()``: - -.. code-block:: cpp - - // while (ros::ok()) - while (rclcpp::ok()) - -Inside the publishing loop, we access the ``data`` field as before: - -.. code-block:: cpp - - msg.data = ss.str(); - -To print a console message, instead of using ``ROS_INFO()``, we use -``RCLCPP_INFO()`` and its various cousins. -The key difference is that ``RCLCPP_INFO()`` takes a Logger object as the first -argument. - -.. code-block:: cpp - - // ROS_INFO("%s", msg.data.c_str()); - RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); - -Change the publish call to use the ``->`` operator instead of ``.``. - -.. code-block:: cpp - - // chatter_pub.publish(msg); - chatter_pub->publish(msg); - -Spinning (i.e., letting the communications system process any pending -incoming/outgoing messages until no more work is available) is different -in that the call now takes the node and timeout as arguments: - -.. code-block:: cpp - - // ros::spinOnce(); - rclcpp::spin_all(node, 0s); - -Sleeping using the rate object is unchanged. - -Putting it all together, the new ``talker.cpp`` looks like this: - -.. code-block:: cpp - - #include - #include - // #include "ros/ros.h" - #include "rclcpp/rclcpp.hpp" - // #include "std_msgs/String.h" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - - int main(int argc, char **argv) - { - // ros::init(argc, argv, "talker"); - // ros::NodeHandle n; - rclcpp::init(argc, argv); - auto node = rclcpp::Node::make_shared("talker"); - // ros::Publisher chatter_pub = n.advertise("chatter", 1000); - // ros::Rate loop_rate(10); - auto chatter_pub = node->create_publisher("chatter", 1000); - rclcpp::Rate loop_rate(10); - int count = 0; - // std_msgs::String msg; - std_msgs::msg::String msg; - // while (ros::ok()) - while (rclcpp::ok()) - { - std::stringstream ss; - ss << "hello world " << count++; - msg.data = ss.str(); - // ROS_INFO("%s", msg.data.c_str()); - RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); - // chatter_pub.publish(msg); - chatter_pub->publish(msg); - // ros::spinOnce(); - rclcpp::spin_all(node, 0s); - loop_rate.sleep(); - } - return 0; - } - -Change the ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -ROS 2 packages use CMake functions and macros from ``ament_cmake_ros`` instead of ``catkin``. -Delete the dependency on ``catkin``: - -.. code-block:: - - - catkin` - -Add a new dependency on ``ament_cmake_ros``: - -.. code-block:: xml - - ament_cmake_ros - -ROS 2 C++ libraries use `rclcpp `__ instead of `roscpp `__. - -Delete the dependency on ``roscpp``: - -.. code-block:: - - - roscpp - -Add a dependency on ``rclcpp``: - -.. code-block:: xml - - rclcpp - - -Add an ```` section to tell colcon the package is an ``ament_cmake`` package instead of a ``catkin`` package. - -.. code-block:: xml - - - ament_cmake - - -Your ``package.xml`` now looks like this: - -.. code-block:: xml - - - - - talker - 0.0.0 - talker - Brian Gerkey - Apache-2.0 - ament_cmake - rclcpp - std_msgs - - ament_cmake - - - - -Changing the CMake code -~~~~~~~~~~~~~~~~~~~~~~~ - -Require a newer version of CMake so that ``ament_cmake`` functions work correctly. - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - -Use a newer C++ standard matching the version used by your target ROS distro in `REP 2000 `__. -If you are using C++20, then set that version with the following snippet after the ``project(talker)`` call. -Add extra compiler checks too because it is a good practice. - -.. code-block:: cmake - - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - -Replace the ``find_package(catkin ...)`` call with individual calls for each dependency. - -.. code-block:: cmake - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - -Delete the call to ``catkin_package()``. -Add a call to ``ament_package()`` at the bottom of the ``CMakeLists.txt``. - -.. code-block:: cmake - - ament_package() - -Make the ``target_link_libraries`` call modern CMake targets provided by ``rclcpp`` and ``std_msgs``. - -.. code-block:: cmake - - target_link_libraries(talker PUBLIC - rclcpp::rclcpp - std_msgs::std_msgs) - -Delete the call to ``include_directories()``. -Add a call to ``target_include_directories()`` below ``add_executable(talker talker.cpp)``. -Don't pass variables like ``rclcpp_INCLUDE_DIRS`` into ``target_include_directories()``. -The include directories are already handled by calling ``target_link_libraries()`` with modern CMake targets. - -.. code-block:: cmake - - target_include_directories(talker PUBLIC - "$" - "$") - -Change the call to ``install()`` so that the ``talker`` executable is installed into a project specific directory. - -.. code-block:: cmake - - install(TARGETS talker - DESTINATION lib/${PROJECT_NAME}) - -The new ``CMakeLists.txt`` looks like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(talker) - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - add_executable(talker talker.cpp) - target_include_directories(talker PUBLIC - "$" - "$") - target_link_libraries(talker PUBLIC - rclcpp::rclcpp - std_msgs::std_msgs) - install(TARGETS talker - DESTINATION lib/${PROJECT_NAME}) - ament_package() - -Building the ROS 2 code -~~~~~~~~~~~~~~~~~~~~~~~ - -We source an environment setup file (in this case the one generated by following -the ROS 2 installation tutorial, which builds in ``~/ros2_ws``, then we build our -package using ``colcon build``: - -.. code-block:: console - - $ . ~/ros2_ws/install/setup.bash - $ cd ~/ros2_talker - $ colcon build - -Running the ROS 2 node -~~~~~~~~~~~~~~~~~~~~~~ - -Because we installed the ``talker`` executable into the correct directory, after sourcing the -setup file, from our install tree, we can invoke it by running: - -.. code-block:: console - - $ . ~/ros2_ws/install/setup.bash - $ ros2 run talker talker - -Conclusion ----------- - -You have learned how to migrate an example C++ ROS 1 package to ROS 2. -Use the :doc:`Migrating C++ Packages reference page <./Migrating-CPP-Packages>` to help you migrate your own C++ packages from ROS 1 to ROS 2. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-CPP-Package-Example + +Migrating a C++ Package Example +=============================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +This example shows how to migrate an example C++ package from ROS 1 to ROS 2. + +Prerequisites +------------- + +You need a working ROS 2 installation, such as :doc:`ROS {DISTRO} <../../Get-Started/Installation>`. + +The ROS 1 code +-------------- + +Say you have a ROS 1 package called ``talker`` that uses ``roscpp`` in one node, called ``talker``. +This package is in a catkin workspace, located at ``~/ros1_talker``. + +Your ROS 1 workspace has the following directory layout: + +.. code-block:: console + + $ cd ~/ros1_talker + $ find . + . + ./src + ./src/talker + ./src/talker/package.xml + ./src/talker/CMakeLists.txt + ./src/talker/talker.cpp + +The files have the following content: + +``src/talker/package.xml``: + +.. code-block:: xml + + + + + talker + 0.0.0 + talker + Brian Gerkey + Apache-2.0 + catkin + roscpp + std_msgs + + +``src/talker/CMakeLists.txt``: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 2.8.3) + project(talker) + find_package(catkin REQUIRED COMPONENTS roscpp std_msgs) + catkin_package() + include_directories(${catkin_INCLUDE_DIRS}) + add_executable(talker talker.cpp) + target_link_libraries(talker ${catkin_LIBRARIES}) + install(TARGETS talker + RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}) + +``src/talker/talker.cpp``: + +.. code-block:: cpp + + #include + #include "ros/ros.h" + #include "std_msgs/String.h" + int main(int argc, char **argv) + { + ros::init(argc, argv, "talker"); + ros::NodeHandle n; + ros::Publisher chatter_pub = n.advertise("chatter", 1000); + ros::Rate loop_rate(10); + int count = 0; + std_msgs::String msg; + while (ros::ok()) + { + std::stringstream ss; + ss << "hello world " << count++; + msg.data = ss.str(); + ROS_INFO("%s", msg.data.c_str()); + chatter_pub.publish(msg); + ros::spinOnce(); + loop_rate.sleep(); + } + return 0; + } + +Migrating to ROS 2 +------------------ + +Let's start by creating a new workspace in which to work: + +.. code-block:: console + + $ mkdir ~/ros2_talker + $ cd ~/ros2_talker + +We'll copy the source tree from our ROS 1 package into that workspace, where we can modify it: + +.. code-block:: console + + $ mkdir src + $ cp -a ~/ros1_talker/src/talker src + +Now we'll modify the C++ code in the node. +The ROS 2 C++ library, called ``rclcpp``, provides a different API from that +provided by ``roscpp``. +The concepts are very similar between the two libraries, which makes the changes +reasonably straightforward to make. + +Included headers +~~~~~~~~~~~~~~~~ + +In place of ``ros/ros.h``, which gave us access to the ``roscpp`` library API, we +need to include ``rclcpp/rclcpp.hpp``, which gives us access to the ``rclcpp`` +library API: + +.. code-block:: cpp + + //#include "ros/ros.h" + #include "rclcpp/rclcpp.hpp" + +To get the ``std_msgs/String`` message definition, in place of +``std_msgs/String.h``, we need to include ``std_msgs/msg/string.hpp``: + +.. code-block:: cpp + + //#include "std_msgs/String.h" + #include "std_msgs/msg/string.hpp" + +Changing C++ library calls +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Instead of passing the node's name to the library initialization call, we do +the initialization, then pass the node name to the creation of the node object: + +.. code-block:: cpp + + // ros::init(argc, argv, "talker"); + // ros::NodeHandle n; + rclcpp::init(argc, argv); + auto node = rclcpp::Node::make_shared("talker"); + +The creation of the publisher and rate objects looks pretty similar, with some +changes to the names of namespace and methods. + +.. code-block:: cpp + + // ros::Publisher chatter_pub = n.advertise("chatter", 1000); + // ros::Rate loop_rate(10); + auto chatter_pub = node->create_publisher("chatter", + 1000); + rclcpp::Rate loop_rate(10); + +To further control how message delivery is handled, a quality of service +(``QoS``) profile could be passed in. +The default profile is ``rmw_qos_profile_default``. +For more details, see the +`design document `__ +and :doc:`concept overview <../../ROS-Framework/topics/About-Quality-of-Service-Settings>`. + +The creation of the outgoing message is different in the namespace: + +.. code-block:: cpp + + // std_msgs::String msg; + std_msgs::msg::String msg; + +In place of ``ros::ok()``, we call ``rclcpp::ok()``: + +.. code-block:: cpp + + // while (ros::ok()) + while (rclcpp::ok()) + +Inside the publishing loop, we access the ``data`` field as before: + +.. code-block:: cpp + + msg.data = ss.str(); + +To print a console message, instead of using ``ROS_INFO()``, we use +``RCLCPP_INFO()`` and its various cousins. +The key difference is that ``RCLCPP_INFO()`` takes a Logger object as the first +argument. + +.. code-block:: cpp + + // ROS_INFO("%s", msg.data.c_str()); + RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); + +Change the publish call to use the ``->`` operator instead of ``.``. + +.. code-block:: cpp + + // chatter_pub.publish(msg); + chatter_pub->publish(msg); + +Spinning (i.e., letting the communications system process any pending +incoming/outgoing messages until no more work is available) is different +in that the call now takes the node and timeout as arguments: + +.. code-block:: cpp + + // ros::spinOnce(); + rclcpp::spin_all(node, 0s); + +Sleeping using the rate object is unchanged. + +Putting it all together, the new ``talker.cpp`` looks like this: + +.. code-block:: cpp + + #include + #include + // #include "ros/ros.h" + #include "rclcpp/rclcpp.hpp" + // #include "std_msgs/String.h" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + + int main(int argc, char **argv) + { + // ros::init(argc, argv, "talker"); + // ros::NodeHandle n; + rclcpp::init(argc, argv); + auto node = rclcpp::Node::make_shared("talker"); + // ros::Publisher chatter_pub = n.advertise("chatter", 1000); + // ros::Rate loop_rate(10); + auto chatter_pub = node->create_publisher("chatter", 1000); + rclcpp::Rate loop_rate(10); + int count = 0; + // std_msgs::String msg; + std_msgs::msg::String msg; + // while (ros::ok()) + while (rclcpp::ok()) + { + std::stringstream ss; + ss << "hello world " << count++; + msg.data = ss.str(); + // ROS_INFO("%s", msg.data.c_str()); + RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); + // chatter_pub.publish(msg); + chatter_pub->publish(msg); + // ros::spinOnce(); + rclcpp::spin_all(node, 0s); + loop_rate.sleep(); + } + return 0; + } + +Change the ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ROS 2 packages use CMake functions and macros from ``ament_cmake_ros`` instead of ``catkin``. +Delete the dependency on ``catkin``: + +.. code-block:: + + + catkin` + +Add a new dependency on ``ament_cmake_ros``: + +.. code-block:: xml + + ament_cmake_ros + +ROS 2 C++ libraries use `rclcpp `__ instead of `roscpp `__. + +Delete the dependency on ``roscpp``: + +.. code-block:: + + + roscpp + +Add a dependency on ``rclcpp``: + +.. code-block:: xml + + rclcpp + + +Add an ```` section to tell colcon the package is an ``ament_cmake`` package instead of a ``catkin`` package. + +.. code-block:: xml + + + ament_cmake + + +Your ``package.xml`` now looks like this: + +.. code-block:: xml + + + + + talker + 0.0.0 + talker + Brian Gerkey + Apache-2.0 + ament_cmake + rclcpp + std_msgs + + ament_cmake + + + + +Changing the CMake code +~~~~~~~~~~~~~~~~~~~~~~~ + +Require a newer version of CMake so that ``ament_cmake`` functions work correctly. + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + +Use a newer C++ standard matching the version used by your target ROS distro in `REP 2000 `__. +If you are using C++20, then set that version with the following snippet after the ``project(talker)`` call. +Add extra compiler checks too because it is a good practice. + +.. code-block:: cmake + + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + +Replace the ``find_package(catkin ...)`` call with individual calls for each dependency. + +.. code-block:: cmake + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + +Delete the call to ``catkin_package()``. +Add a call to ``ament_package()`` at the bottom of the ``CMakeLists.txt``. + +.. code-block:: cmake + + ament_package() + +Make the ``target_link_libraries`` call modern CMake targets provided by ``rclcpp`` and ``std_msgs``. + +.. code-block:: cmake + + target_link_libraries(talker PUBLIC + rclcpp::rclcpp + std_msgs::std_msgs) + +Delete the call to ``include_directories()``. +Add a call to ``target_include_directories()`` below ``add_executable(talker talker.cpp)``. +Don't pass variables like ``rclcpp_INCLUDE_DIRS`` into ``target_include_directories()``. +The include directories are already handled by calling ``target_link_libraries()`` with modern CMake targets. + +.. code-block:: cmake + + target_include_directories(talker PUBLIC + "$" + "$") + +Change the call to ``install()`` so that the ``talker`` executable is installed into a project specific directory. + +.. code-block:: cmake + + install(TARGETS talker + DESTINATION lib/${PROJECT_NAME}) + +The new ``CMakeLists.txt`` looks like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(talker) + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + add_executable(talker talker.cpp) + target_include_directories(talker PUBLIC + "$" + "$") + target_link_libraries(talker PUBLIC + rclcpp::rclcpp + std_msgs::std_msgs) + install(TARGETS talker + DESTINATION lib/${PROJECT_NAME}) + ament_package() + +Building the ROS 2 code +~~~~~~~~~~~~~~~~~~~~~~~ + +We source an environment setup file (in this case the one generated by following +the ROS 2 installation tutorial, which builds in ``~/ros2_ws``, then we build our +package using ``colcon build``: + +.. code-block:: console + + $ . ~/ros2_ws/install/setup.bash + $ cd ~/ros2_talker + $ colcon build + +Running the ROS 2 node +~~~~~~~~~~~~~~~~~~~~~~ + +Because we installed the ``talker`` executable into the correct directory, after sourcing the +setup file, from our install tree, we can invoke it by running: + +.. code-block:: console + + $ . ~/ros2_ws/install/setup.bash + $ ros2 run talker talker + +Conclusion +---------- + +You have learned how to migrate an example C++ ROS 1 package to ROS 2. +Use the :doc:`Migrating C++ Packages reference page ` to help you migrate your own C++ packages from ROS 1 to ROS 2. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst index 1b842c2ea70..af5c9bd02af 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst @@ -1,477 +1,478 @@ -.. redirect-from:: - - Migration-Guide - Contributing/Migration-Guide - The-ROS2-Project/Contributing/Migration-Guide - -Migrating C++ Packages Reference -================================ - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page shows how to migrate parts of a C++ package from ROS 1 to ROS 2. -If this is your first time migrating a C++ package, then read the :doc:`C++ migration example ` first. -Afterwards, use this page as a reference while you migrate your own packages. - -Build tool ----------- - -Instead of using ``catkin_make``, ``catkin_make_isolated`` or ``catkin build`` ROS 2 uses the command line tool `colcon `__ to build and install a set of packages. -See the :doc:`beginner tutorial <../../Tutorials/Beginner-Client-Libraries/Colcon-Tutorial>` to get started with ``colcon``. - -Update your ``CMakeLists.txt`` to use *ament_cmake* ---------------------------------------------------- - -ROS 2 C++ packages use `CMake `__ with convenience functions provided by `ament_cmake `__. -Apply the following changes to use ``ament_cmake`` instead of ``catkin``. - - -Require a newer version of CMake -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 relies on newer versions of CMake than used by ROS 1. -Find the minimum version of CMake used by the ROS distribution you want to support in `REP 2000 `__, and use that version at the top of your ``CMakeLists.txt``. -For example, `3.14.4 is the minimum recommended support for ROS Humble `__. - -.. code-block:: - - cmake_minimum_required(VERSION 3.20) - -Set the build type to ament_cmake -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Remove any dependencies on ``catkin`` from your ``package.xml`` - -.. code-block:: - - # Remove this! - catkin - -Add a new dependency on ``ament_cmake_ros`` (`example `__): - -.. code-block:: xml - - ament_cmake_ros - -Add an ```` section to your ``package.xml`` if it does not have one already. -Set the ```` to ``ament_cmake`` (`example `__) - -.. code-block:: xml - - - ament_cmake - - -Add a call to ``ament_package()`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Insert a call to ``ament_package()`` at the bottom of your ``CMakeLists.txt`` (`example `__) - -.. code-block:: cmake - - # Add this to the bottom of your CMakeLists.txt - ament_package() - -Update ``find_package()`` calls -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Replace the ``find_package(catkin COMPONENTS ...)`` call with individual ``find_package()`` calls (`example `_): - -For example, change this: - -.. code-block:: - - find_package(catkin REQUIRED COMPONENTS foo bar std_msgs) - find_package(baz REQUIRED) - -To this: - -.. code-block:: cmake - - find_package(ament_cmake_ros REQUIRED) - find_package(foo REQUIRED) - find_package(bar REQUIRED) - find_package(std_msgs REQUIRED) - find_package(baz REQUIRED) - - -Use modern CMake targets -^^^^^^^^^^^^^^^^^^^^^^^^ - -Prefer to use per-target CMake functions so that your package can export modern CMake targets. - -If your ``CMakeLists.txt`` uses ``include_directories()``, then delete those calls. - -.. code-block:: - - # Delete calls to include_directories like this one! - include_directories(include ${catkin_INCLUDE_DIRS}) - -Add a call ``target_include_directories()`` for every library in your package (`example `__). - -.. code-block:: cmake - - target_include_directories(my_library PUBLIC - "$" - "$") - -Change all ``target_link_libraries()`` calls to use modern CMake targets. -For example, if your package in ROS 1 uses old-style standard CMake variables like this. - -.. code-block:: - - target_link_libraries(my_library ${catkin_LIBRARIES} ${baz_LIBRARIES}) - -Then change it to use specific modern CMake targets instead. - -.. code-block:: cmake - - target_link_libraries(my_library PUBLIC foo::foo bar::bar std_msgs::std_msgs baz::baz) - -Choose ``PUBLIC`` or ``PRIVATE`` based on how the dependency is used by your library (`example `__). - -* Use ``PUBLIC`` if the dependency is needed by downstream users, for example, your library's public API uses it. -* Use ``PRIVATE`` if the dependency is only used internally by your library. - -Replace ``catkin_package()`` with various ament_cmake calls -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Imagine your ``CMakeLists.txt`` has a call to ``catkin_package`` like this: - -.. code-block:: - - catkin_package( - INCLUDE_DIRS include - LIBRARIES my_library - CATKIN_DEPENDS foo bar std_msgs - DEPENDS baz - ) - - install(TARGETS my_library - ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION} - LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION} - RUNTIME DESTINATION ${CATKIN_GLOBAL_BIN_DESTINATION} - ) - - -Replacing ``catkin_package(INCLUDE_DIRS ...)`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you've used modern CMake targets and ``target_include_directories()``, you don't need to do anything further. -Downstream users will get the include directories by depending on your modern CMake targets. - -Replacing ``catkin_package(LIBRARIES ...)`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Use ``ament_export_targets()`` and ``install(TARGETS ... EXPORT ...)`` to replace the ``LIBRARIES`` argument. - -Use the ``EXPORT`` keyword when installing your ``my_library`` target (`example `__). - -.. code-block:: cmake - - install(TARGETS my_library EXPORT export_my_package - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - -The above is a good default for library targets. -If your package used different ``CATKIN_*_DESTINATION`` variables, convert them as follows: - -.. list-table:: - :header-rows: 1 - - * - **catkin** - - **ament_cmake** - * - CATKIN_GLOBAL_BIN_DESTINATION - - bin - * - CATKIN_GLOBAL_INCLUDE_DESTINATION - - include - * - CATKIN_GLOBAL_LIB_DESTINATION - - lib - * - CATKIN_GLOBAL_LIBEXEC_DESTINATION - - lib - * - CATKIN_GLOBAL_SHARE_DESTINATION - - share - * - CATKIN_PACKAGE_BIN_DESTINATION - - lib/${PROJECT_NAME} - * - CATKIN_PACKAGE_INCLUDE_DESTINATION - - include/${PROJECT_NAME} - * - CATKIN_PACKAGE_LIB_DESTINATION - - lib - * - CATKIN_PACKAGE_SHARE_DESTINATION - - share/${PROJECT_NAME} - -Add a call to ``ament_export_targets()`` with the same name you gave to the ``EXPORT`` keyword (`example `__). - -.. code-block:: cmake - - ament_export_targets(export_my_package) - - -Replacing ``catkin_package(CATKIN_DEPENDS .. DEPENDS ..)`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Your package's users must ``find_package()`` dependencies used by your package's public API. -In ROS 1 this was done for downstream users with the ``CATKIN_DEPENDS`` and ``DEPENDS`` arguments. -Use `ament_export_dependencies `__ to do this in ROS 2. - -.. code-block:: cmake - - ament_export_dependencies( - foo - bar - std_msgs - baz - ) - -Generate messages -^^^^^^^^^^^^^^^^^ - -If your package contains both C++ code and ROS message, service, or action definitions, then consider splitting it into two packages: - -* A package with only the ROS message, service, and/or action definitions -* A package with the C++ code - -Add the following dependencies to the ``package.xml`` of the package that contains ROS messages: - -1. Add a ```` on ``rosidl_default_generators`` (`example `__) - - .. code-block:: xml - - rosidl_default_generators - -2. Add an ```` on ``rosidl_default_runtime`` (`example `__) - - .. code-block:: xml - - rosidl_default_runtime - -3. Add a ```` tag with the group name ``rosidl_interface_packages`` (`example `__) - - .. code-block:: xml - - rosidl_interface_packages - -In your ``CMakeLists.txt``, replace the invocation of ``add_message_files``, ``add_service_files`` and ``generate_messages`` with `rosidl_generate_interfaces `__. -The first argument must be ``${PROJECT_NAME}`` due to `this bug `__. - -For example, if your ROS 1 package looks like this: - -.. code-block:: - - add_message_files(DIRECTORY msg FILES FooBar.msg Baz.msg) - add_service_files(DIRECTORY srv FILES Ping.srv) - - add_action_files(DIRECTORY action FILES DoPong.action) - generate_messages( - DEPENDENCIES actionlib_msgs std_msgs geometry_msgs - ) - -Then change it to this (`example `__) - -.. code-block:: cmake - - rosidl_generate_interfaces(${PROJECT_NAME} - "msg/FooBar.msg" - "msg/Baz.msg" - "srv/Ping.srv" - "action/DoPong.action" - DEPENDENCIES actionlib_msgs std_msgs geometry_msgs - ) - -Remove references to the devel space -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Remove any references to the *devel space* such as ``CATKIN_DEVEL_PREFIX``. -There is no equivalent to the *devel space* in ROS 2. - - -Unit tests -^^^^^^^^^^ - -If your package uses `gtest `__ then: - -* Replace ``CATKIN_ENABLE_TESTING`` with ``BUILD_TESTING``. -* Replace ``catkin_add_gtest`` with ``ament_add_gtest``. -* Add a ``find_package()`` for ``ament_cmake_gtest`` instead of ``GTest`` - -For example, if your ROS 1 package adds tests like this: - -.. code-block:: - - if (CATKIN_ENABLE_TESTING) - find_package(GTest REQUIRED) - include_directories(${GTEST_INCLUDE_DIRS}) - catkin_add_gtest(my_test src/test/some_test.cpp) - target_link_libraries(my_test - # ... - ${GTEST_LIBRARIES}) - endif() - -Then change it to this: - -.. code-block:: CMake - - if (BUILD_TESTING) - find_package(ament_cmake_gtest REQUIRED) - ament_add_gtest(my_test src/test/test_something.cpp) - target_link_libraries(my_test - #... - ) - endif() - -Add ``ament_cmake_gtest`` to your ``package.xml`` (`example `__). - -.. code-block:: xml - - ament_cmake_gtest - -Linters -^^^^^^^ - -The ROS 2 code :doc:`style guide <../../The-ROS2-Project/Contributing/Developer-Guide>` differs from ROS 1. - -If you choose to follow the ROS 2 style guide, then turn on automatic linter tests by adding these lines in a ``if(BUILD_TESTING)`` block: - -.. code-block:: cmake - - if(BUILD_TESTING) - find_package(ament_lint_auto REQUIRED) - ament_lint_auto_find_test_dependencies() - # ... - endif() - -Add the following dependencies to your ``package.xml``: - -.. code-block:: xml - - ament_lint_auto - ament_lint_common - -Update source code ------------------- - -Messages, services, and actions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The namespace of ROS 2 messages, services, and actions use a subnamespace (``msg``, ``srv``, or ``action``, respectively) after the package name. -Therefore an include looks like: ``#include ``. -The C++ type is then named: ``my_interfaces::msg::MyMessage``. - -Shared pointer types are provided as typedefs within the message structs: ``my_interfaces::msg::MyMessage::SharedPtr`` as well as ``my_interfaces::msg::MyMessage::ConstSharedPtr``. - -For more details please see the article about the `generated C++ interfaces `__. - -The migration requires includes to change by: - - -* inserting the subfolder ``msg`` between the package name and message datatype -* changing the included filename from CamelCase to underscore separation -* changing from ``*.h`` to ``*.hpp`` - -.. code-block:: cpp - - // ROS 1 style is in comments, ROS 2 follows, uncommented. - // # include - #include - - // geometry_msgs::PointStamped point_stamped; - geometry_msgs::msg::PointStamped point_stamped; - -The migration requires code to insert the ``msg`` namespace into all instances. - -Use of service objects -^^^^^^^^^^^^^^^^^^^^^^ - -Service callbacks in ROS 2 do not have boolean return values. -Instead of returning false on failures, throwing exceptions is recommended. - -.. code-block:: cpp - - // ROS 1 style is in comments, ROS 2 follows, uncommented. - // #include "nav_msgs/GetMap.h" - #include "nav_msgs/srv/get_map.hpp" - - // bool service_callback( - // nav_msgs::GetMap::Request & request, - // nav_msgs::GetMap::Response & response) - void service_callback( - const std::shared_ptr request, - std::shared_ptr response) - { - // ... - // return true; // or false for failure - } - -Usages of ros::Time -^^^^^^^^^^^^^^^^^^^ - -For usages of ``ros::Time``: - -* Replace all instances of ``ros::Time`` with ``rclcpp::Time`` - -* If your messages or code makes use of std_msgs::Time: - - * Convert all instances of std_msgs::Time to builtin_interfaces::msg::Time - - * Convert all ``#include "std_msgs/time.h`` to ``#include "builtin_interfaces/msg/time.hpp"`` - - * Convert all instances using the std_msgs::Time field ``nsec`` to the builtin_interfaces::msg::Time field ``nanosec`` - -Usages of ros::Rate -^^^^^^^^^^^^^^^^^^^ - -There is an equivalent type ``rclcpp::Rate`` object which is basically a drop in replacement for ``ros::Rate``. - - -Boost -^^^^^ - -Much of the functionality previously provided by Boost has been integrated into the C++ standard library. -As such we would like to take advantage of the new core features and avoid the dependency on boost where possible. - -Shared Pointers -~~~~~~~~~~~~~~~ - -To switch shared pointers from boost to standard C++ replace instances of: - - -* ``#include `` with ``#include `` -* ``boost::shared_ptr`` with ``std::shared_ptr`` - -There may also be variants such as ``weak_ptr`` which you want to convert as well. - -Also it is recommended practice to use ``using`` instead of ``typedef``. -``using`` has the ability to work better in templated logic. -For details `see here `__ - -Thread/Mutexes -~~~~~~~~~~~~~~ - -Another common part of boost used in ROS codebases are mutexes in ``boost::thread``. - - -* Replace ``boost::mutex::scoped_lock`` with ``std::unique_lock`` -* Replace ``boost::mutex`` with ``std::mutex`` -* Replace ``#include `` with ``#include `` - -Unordered Map -~~~~~~~~~~~~~ - -Replace: - - -* ``#include `` with ``#include `` -* ``boost::unordered_map`` with ``std::unordered_map`` - -function -~~~~~~~~ - -Replace: - - -* ``#include `` with ``#include `` -* ``boost::function`` with ``std::function`` +.. redirect-from:: + + Migration-Guide + Contributing/Migration-Guide + The-ROS2-Project/Contributing/Migration-Guide + How-To-Guides/Migrating-from-ROS1/Migrating-CPP-Packages + +Migrating C++ Packages Reference +================================ + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page shows how to migrate parts of a C++ package from ROS 1 to ROS 2. +If this is your first time migrating a C++ package, then read the :doc:`C++ migration example ` first. +Afterwards, use this page as a reference while you migrate your own packages. + +Build tool +---------- + +Instead of using ``catkin_make``, ``catkin_make_isolated`` or ``catkin build`` ROS 2 uses the command line tool `colcon `__ to build and install a set of packages. +See the :doc:`beginner tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>` to get started with ``colcon``. + +Update your ``CMakeLists.txt`` to use *ament_cmake* +--------------------------------------------------- + +ROS 2 C++ packages use `CMake `__ with convenience functions provided by `ament_cmake `__. +Apply the following changes to use ``ament_cmake`` instead of ``catkin``. + + +Require a newer version of CMake +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 relies on newer versions of CMake than used by ROS 1. +Find the minimum version of CMake used by the ROS distribution you want to support in `REP 2000 `__, and use that version at the top of your ``CMakeLists.txt``. +For example, `3.14.4 is the minimum recommended support for ROS Humble `__. + +.. code-block:: + + cmake_minimum_required(VERSION 3.20) + +Set the build type to ament_cmake +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Remove any dependencies on ``catkin`` from your ``package.xml`` + +.. code-block:: + + # Remove this! + catkin + +Add a new dependency on ``ament_cmake_ros`` (`example `__): + +.. code-block:: xml + + ament_cmake_ros + +Add an ```` section to your ``package.xml`` if it does not have one already. +Set the ```` to ``ament_cmake`` (`example `__) + +.. code-block:: xml + + + ament_cmake + + +Add a call to ``ament_package()`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Insert a call to ``ament_package()`` at the bottom of your ``CMakeLists.txt`` (`example `__) + +.. code-block:: cmake + + # Add this to the bottom of your CMakeLists.txt + ament_package() + +Update ``find_package()`` calls +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Replace the ``find_package(catkin COMPONENTS ...)`` call with individual ``find_package()`` calls (`example `_): + +For example, change this: + +.. code-block:: + + find_package(catkin REQUIRED COMPONENTS foo bar std_msgs) + find_package(baz REQUIRED) + +To this: + +.. code-block:: cmake + + find_package(ament_cmake_ros REQUIRED) + find_package(foo REQUIRED) + find_package(bar REQUIRED) + find_package(std_msgs REQUIRED) + find_package(baz REQUIRED) + + +Use modern CMake targets +^^^^^^^^^^^^^^^^^^^^^^^^ + +Prefer to use per-target CMake functions so that your package can export modern CMake targets. + +If your ``CMakeLists.txt`` uses ``include_directories()``, then delete those calls. + +.. code-block:: + + # Delete calls to include_directories like this one! + include_directories(include ${catkin_INCLUDE_DIRS}) + +Add a call ``target_include_directories()`` for every library in your package (`example `__). + +.. code-block:: cmake + + target_include_directories(my_library PUBLIC + "$" + "$") + +Change all ``target_link_libraries()`` calls to use modern CMake targets. +For example, if your package in ROS 1 uses old-style standard CMake variables like this. + +.. code-block:: + + target_link_libraries(my_library ${catkin_LIBRARIES} ${baz_LIBRARIES}) + +Then change it to use specific modern CMake targets instead. + +.. code-block:: cmake + + target_link_libraries(my_library PUBLIC foo::foo bar::bar std_msgs::std_msgs baz::baz) + +Choose ``PUBLIC`` or ``PRIVATE`` based on how the dependency is used by your library (`example `__). + +* Use ``PUBLIC`` if the dependency is needed by downstream users, for example, your library's public API uses it. +* Use ``PRIVATE`` if the dependency is only used internally by your library. + +Replace ``catkin_package()`` with various ament_cmake calls +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Imagine your ``CMakeLists.txt`` has a call to ``catkin_package`` like this: + +.. code-block:: + + catkin_package( + INCLUDE_DIRS include + LIBRARIES my_library + CATKIN_DEPENDS foo bar std_msgs + DEPENDS baz + ) + + install(TARGETS my_library + ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION} + LIBRARY DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION} + RUNTIME DESTINATION ${CATKIN_GLOBAL_BIN_DESTINATION} + ) + + +Replacing ``catkin_package(INCLUDE_DIRS ...)`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you've used modern CMake targets and ``target_include_directories()``, you don't need to do anything further. +Downstream users will get the include directories by depending on your modern CMake targets. + +Replacing ``catkin_package(LIBRARIES ...)`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Use ``ament_export_targets()`` and ``install(TARGETS ... EXPORT ...)`` to replace the ``LIBRARIES`` argument. + +Use the ``EXPORT`` keyword when installing your ``my_library`` target (`example `__). + +.. code-block:: cmake + + install(TARGETS my_library EXPORT export_my_package + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + +The above is a good default for library targets. +If your package used different ``CATKIN_*_DESTINATION`` variables, convert them as follows: + +.. list-table:: + :header-rows: 1 + + * - **catkin** + - **ament_cmake** + * - CATKIN_GLOBAL_BIN_DESTINATION + - bin + * - CATKIN_GLOBAL_INCLUDE_DESTINATION + - include + * - CATKIN_GLOBAL_LIB_DESTINATION + - lib + * - CATKIN_GLOBAL_LIBEXEC_DESTINATION + - lib + * - CATKIN_GLOBAL_SHARE_DESTINATION + - share + * - CATKIN_PACKAGE_BIN_DESTINATION + - lib/${PROJECT_NAME} + * - CATKIN_PACKAGE_INCLUDE_DESTINATION + - include/${PROJECT_NAME} + * - CATKIN_PACKAGE_LIB_DESTINATION + - lib + * - CATKIN_PACKAGE_SHARE_DESTINATION + - share/${PROJECT_NAME} + +Add a call to ``ament_export_targets()`` with the same name you gave to the ``EXPORT`` keyword (`example `__). + +.. code-block:: cmake + + ament_export_targets(export_my_package) + + +Replacing ``catkin_package(CATKIN_DEPENDS .. DEPENDS ..)`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Your package's users must ``find_package()`` dependencies used by your package's public API. +In ROS 1 this was done for downstream users with the ``CATKIN_DEPENDS`` and ``DEPENDS`` arguments. +Use `ament_export_dependencies `__ to do this in ROS 2. + +.. code-block:: cmake + + ament_export_dependencies( + foo + bar + std_msgs + baz + ) + +Generate messages +^^^^^^^^^^^^^^^^^ + +If your package contains both C++ code and ROS message, service, or action definitions, then consider splitting it into two packages: + +* A package with only the ROS message, service, and/or action definitions +* A package with the C++ code + +Add the following dependencies to the ``package.xml`` of the package that contains ROS messages: + +1. Add a ```` on ``rosidl_default_generators`` (`example `__) + + .. code-block:: xml + + rosidl_default_generators + +2. Add an ```` on ``rosidl_default_runtime`` (`example `__) + + .. code-block:: xml + + rosidl_default_runtime + +3. Add a ```` tag with the group name ``rosidl_interface_packages`` (`example `__) + + .. code-block:: xml + + rosidl_interface_packages + +In your ``CMakeLists.txt``, replace the invocation of ``add_message_files``, ``add_service_files`` and ``generate_messages`` with `rosidl_generate_interfaces `__. +The first argument must be ``${PROJECT_NAME}`` due to `this bug `__. + +For example, if your ROS 1 package looks like this: + +.. code-block:: + + add_message_files(DIRECTORY msg FILES FooBar.msg Baz.msg) + add_service_files(DIRECTORY srv FILES Ping.srv) + + add_action_files(DIRECTORY action FILES DoPong.action) + generate_messages( + DEPENDENCIES actionlib_msgs std_msgs geometry_msgs + ) + +Then change it to this (`example `__) + +.. code-block:: cmake + + rosidl_generate_interfaces(${PROJECT_NAME} + "msg/FooBar.msg" + "msg/Baz.msg" + "srv/Ping.srv" + "action/DoPong.action" + DEPENDENCIES actionlib_msgs std_msgs geometry_msgs + ) + +Remove references to the devel space +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Remove any references to the *devel space* such as ``CATKIN_DEVEL_PREFIX``. +There is no equivalent to the *devel space* in ROS 2. + + +Unit tests +^^^^^^^^^^ + +If your package uses `gtest `__ then: + +* Replace ``CATKIN_ENABLE_TESTING`` with ``BUILD_TESTING``. +* Replace ``catkin_add_gtest`` with ``ament_add_gtest``. +* Add a ``find_package()`` for ``ament_cmake_gtest`` instead of ``GTest`` + +For example, if your ROS 1 package adds tests like this: + +.. code-block:: + + if (CATKIN_ENABLE_TESTING) + find_package(GTest REQUIRED) + include_directories(${GTEST_INCLUDE_DIRS}) + catkin_add_gtest(my_test src/test/some_test.cpp) + target_link_libraries(my_test + # ... + ${GTEST_LIBRARIES}) + endif() + +Then change it to this: + +.. code-block:: CMake + + if (BUILD_TESTING) + find_package(ament_cmake_gtest REQUIRED) + ament_add_gtest(my_test src/test/test_something.cpp) + target_link_libraries(my_test + #... + ) + endif() + +Add ``ament_cmake_gtest`` to your ``package.xml`` (`example `__). + +.. code-block:: xml + + ament_cmake_gtest + +Linters +^^^^^^^ + +The ROS 2 code :doc:`style guide <../../The-ROS2-Project/Contributing/Developer-Guide>` differs from ROS 1. + +If you choose to follow the ROS 2 style guide, then turn on automatic linter tests by adding these lines in a ``if(BUILD_TESTING)`` block: + +.. code-block:: cmake + + if(BUILD_TESTING) + find_package(ament_lint_auto REQUIRED) + ament_lint_auto_find_test_dependencies() + # ... + endif() + +Add the following dependencies to your ``package.xml``: + +.. code-block:: xml + + ament_lint_auto + ament_lint_common + +Update source code +------------------ + +Messages, services, and actions +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The namespace of ROS 2 messages, services, and actions use a subnamespace (``msg``, ``srv``, or ``action``, respectively) after the package name. +Therefore an include looks like: ``#include ``. +The C++ type is then named: ``my_interfaces::msg::MyMessage``. + +Shared pointer types are provided as typedefs within the message structs: ``my_interfaces::msg::MyMessage::SharedPtr`` as well as ``my_interfaces::msg::MyMessage::ConstSharedPtr``. + +For more details please see the article about the `generated C++ interfaces `__. + +The migration requires includes to change by: + + +* inserting the subfolder ``msg`` between the package name and message datatype +* changing the included filename from CamelCase to underscore separation +* changing from ``*.h`` to ``*.hpp`` + +.. code-block:: cpp + + // ROS 1 style is in comments, ROS 2 follows, uncommented. + // # include + #include + + // geometry_msgs::PointStamped point_stamped; + geometry_msgs::msg::PointStamped point_stamped; + +The migration requires code to insert the ``msg`` namespace into all instances. + +Use of service objects +^^^^^^^^^^^^^^^^^^^^^^ + +Service callbacks in ROS 2 do not have boolean return values. +Instead of returning false on failures, throwing exceptions is recommended. + +.. code-block:: cpp + + // ROS 1 style is in comments, ROS 2 follows, uncommented. + // #include "nav_msgs/GetMap.h" + #include "nav_msgs/srv/get_map.hpp" + + // bool service_callback( + // nav_msgs::GetMap::Request & request, + // nav_msgs::GetMap::Response & response) + void service_callback( + const std::shared_ptr request, + std::shared_ptr response) + { + // ... + // return true; // or false for failure + } + +Usages of ros::Time +^^^^^^^^^^^^^^^^^^^ + +For usages of ``ros::Time``: + +* Replace all instances of ``ros::Time`` with ``rclcpp::Time`` + +* If your messages or code makes use of std_msgs::Time: + + * Convert all instances of std_msgs::Time to builtin_interfaces::msg::Time + + * Convert all ``#include "std_msgs/time.h`` to ``#include "builtin_interfaces/msg/time.hpp"`` + + * Convert all instances using the std_msgs::Time field ``nsec`` to the builtin_interfaces::msg::Time field ``nanosec`` + +Usages of ros::Rate +^^^^^^^^^^^^^^^^^^^ + +There is an equivalent type ``rclcpp::Rate`` object which is basically a drop in replacement for ``ros::Rate``. + + +Boost +^^^^^ + +Much of the functionality previously provided by Boost has been integrated into the C++ standard library. +As such we would like to take advantage of the new core features and avoid the dependency on boost where possible. + +Shared Pointers +~~~~~~~~~~~~~~~ + +To switch shared pointers from boost to standard C++ replace instances of: + + +* ``#include `` with ``#include `` +* ``boost::shared_ptr`` with ``std::shared_ptr`` + +There may also be variants such as ``weak_ptr`` which you want to convert as well. + +Also it is recommended practice to use ``using`` instead of ``typedef``. +``using`` has the ability to work better in templated logic. +For details `see here `__ + +Thread/Mutexes +~~~~~~~~~~~~~~ + +Another common part of boost used in ROS codebases are mutexes in ``boost::thread``. + + +* Replace ``boost::mutex::scoped_lock`` with ``std::unique_lock`` +* Replace ``boost::mutex`` with ``std::mutex`` +* Replace ``#include `` with ``#include `` + +Unordered Map +~~~~~~~~~~~~~ + +Replace: + + +* ``#include `` with ``#include `` +* ``boost::unordered_map`` with ``std::unordered_map`` + +function +~~~~~~~~ + +Replace: + + +* ``#include `` with ``#include `` +* ``boost::function`` with ``std::function`` \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst index 6257479857c..746b858520f 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst @@ -1,51 +1,55 @@ -Migrating Interfaces -==================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Messages, services, and actions are collectively called ``interfaces`` in ROS 2. - -Interface definitions ---------------------- - -Message files must end in ``.msg`` and must be located in the subfolder ``msg``. -Service files must end in ``.srv`` and must be located in the subfolder ``srv``. -Actions files must end in ``.action`` and must be located in the subfolder ``action``. - -These files might need to be updated to comply with the `ROS Interface definition `__. -Some primitive types have been removed and the types ``duration`` and ``time`` which were builtin types in ROS 1 have been replaced with normal message definitions and must be used from the `builtin_interfaces `__ package. -Also some naming conventions are stricter than in ROS 1. -There is additional information in the :doc:`conceptual article <../../Concepts/Basic/About-Interfaces>`. - -Building interfaces -------------------- - -The way in which interfaces are built in ROS 2 differs substantially from ROS 1. -Interfaces can only be built from packages containing a ``CMakeLists.txt``. -If you are developing a pure Python package, then the interfaces should be placed in a different package containing only the interfaces (which is best practice anyway). -See the :doc:`custom interfaces tutorial<../../Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces>` for more information. - -Migrating interface package to ROS 2 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In your ``package.xml``: - -* Add ``rosidl_default_generators``. -* Add ``rosidl_default_runtime``. -* Add ``rosidl_interface_packages`` -* For each dependent message package, add ``message_package``. - -In your ``CMakeLists.txt``: - -* Enable C++20 - -.. code-block:: cmake - - set(CMAKE_CXX_STANDARD 20) - -* Add ``find_package(rosidl_default_generators REQUIRED)`` -* For each dependent message package, add ``find_package(message_package REQUIRED)`` and replace the CMake function call to ``generate_messages`` with ``rosidl_generate_interfaces``. - -This will replace ``add_message_files`` and ``add_service_files`` listing of all the message and service files, which can be removed. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Interfaces + +Migrating Interfaces +==================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Messages, services, and actions are collectively called ``interfaces`` in ROS 2. + +Interface definitions +--------------------- + +Message files must end in ``.msg`` and must be located in the subfolder ``msg``. +Service files must end in ``.srv`` and must be located in the subfolder ``srv``. +Actions files must end in ``.action`` and must be located in the subfolder ``action``. + +These files might need to be updated to comply with the `ROS Interface definition `__. +Some primitive types have been removed and the types ``duration`` and ``time`` which were builtin types in ROS 1 have been replaced with normal message definitions and must be used from the `builtin_interfaces `__ package. +Also some naming conventions are stricter than in ROS 1. +There is additional information in the :doc:`conceptual article <../../ROS-Framework/About-Interfaces>`. + +Building interfaces +------------------- + +The way in which interfaces are built in ROS 2 differs substantially from ROS 1. +Interfaces can only be built from packages containing a ``CMakeLists.txt``. +If you are developing a pure Python package, then the interfaces should be placed in a different package containing only the interfaces (which is best practice anyway). +See the :doc:`custom interfaces tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces>` for more information. + +Migrating interface package to ROS 2 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In your ``package.xml``: + +* Add ``rosidl_default_generators``. +* Add ``rosidl_default_runtime``. +* Add ``rosidl_interface_packages`` +* For each dependent message package, add ``message_package``. + +In your ``CMakeLists.txt``: + +* Enable C++20 + +.. code-block:: cmake + + set(CMAKE_CXX_STANDARD 20) + +* Add ``find_package(rosidl_default_generators REQUIRED)`` +* For each dependent message package, add ``find_package(message_package REQUIRED)`` and replace the CMake function call to ``generate_messages`` with ``rosidl_generate_interfaces``. + +This will replace ``add_message_files`` and ``add_service_files`` listing of all the message and service files, which can be removed. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst index dc24b4f629b..d5baa0bcd9f 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst @@ -1,458 +1,459 @@ -.. redirect-from:: - - Guides/Launch-files-migration-guide - Tutorials/Launch-files-migration-guide - How-To-Guides/Launch-files-migration-guide - -.. _MigratingLaunch: - -Migrating Launch Files -====================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -While launch files in ROS 1 are always specified using `XML `__ files, ROS 2 supports both XML and YAML files. -ROS 2 also supports Python launch scripts to enable more flexibility (see `launch package `__). -However, for typical use cases, XML and YAML should be preferred over Python. - -This guide describes how to write ROS 2 XML launch files for an easy migration from ROS 1. - -Background ----------- - -A description of the ROS 2 launch system can be found in :doc:`Launch System tutorial <../../../Tutorials/Intermediate/Launch/Launch-system>`. - - -Migrating tags --------------- - -launch -^^^^^^ - -* `Available in ROS 1 `__. -* ``launch`` is the root element of any ROS 2 launch XML file. - -node -^^^^ - -* `Available in ROS 1 `__. -* Launches a new node. -* Differences from ROS 1: - - * ``type`` attribute is now ``exec``. - * ``ns`` attribute is now ``namespace``. - * ``required="true"`` is now ``on_exit="shutdown"``. - * The following attributes aren't available: ``machine``, ``respawn_delay``, ``clear_params``. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - - -param -^^^^^ - -* `Available in ROS 1 `__. -* Used for passing a parameter to a node. -* There's no global parameter concept in ROS 2. - For that reason, it can only be used nested in a ``node`` tag. - Some attributes aren't supported in ROS 2: ``type``, ``textfile``, ``binfile``, ``executable``. -* The ``command`` attribute is now ``value="$(command '...' )"``. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - - - -Type inference rules -~~~~~~~~~~~~~~~~~~~~ - -Here are some examples of how to write parameters: - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - -Parameter grouping -~~~~~~~~~~~~~~~~~~ - -In ROS 2, ``param`` tags are allowed to be nested. -For example: - -.. code-block:: xml - - - - - - - - - - -That will create two parameters: - -* A ``group1.group2.my_param`` of value ``1``, hosted by node ``/an_absolute_ns/my_node``. -* A ``group1.another_param`` of value ``2`` hosted by node ``/an_absolute_ns/my_node``. - -It's also possible to use full parameter names: - -.. code-block:: xml - - - - - - -rosparam -^^^^^^^^ - -* `Available in ROS 1 `__. -* Loads parameters from a yaml file. -* It has been replaced with a ``from`` attribute in ``param`` tags. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - -remap -^^^^^ - -* `Available in ROS 1 `__. -* Used to pass remapping rules to a node. -* It can only be used within ``node`` tags. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - - - - - - -include -^^^^^^^ - -* `Available in ROS 1 `__. -* Allows including another launch file. -* Differences from ROS 1: - - * Available in ROS 1, included content was scoped. - In ROS 2, it's not. - This means the values of ``arg`` tags are propagated into included launch files as if ``pass_all_args="true"`` were used in ROS 1. - However, this propagation only works for args that have a default value (in the inner/included launch file). - Required args have to be passed explicitly. - Nest includes in ``group`` tags to scope them (see also ``group`` attributes ``scoped`` and ``forwarding`` ). - * ``ns`` attribute is not supported. - See example of ``push_ros_namespace`` tag for a workaround. - * ``arg`` tag nested in an ``include`` tag is now ``let``. - However, ``arg`` is still supported for now. - * ``let`` tags nested in an ``include`` tag don't support conditionals (``if``, ``unless``) or the ``description`` attribute. - * There is no support for nested ``env`` tags. - ``set_env`` and ``unset_env`` can be used instead. - * Both ``clear_params`` and ``pass_all_args`` attributes aren't supported. - ROS 2 launch behaves as if ``pass_all_args`` were set to true (see above). - -Examples -~~~~~~~~ - -See `Replacing an include tag`_. - -arg -^^^ - -* `Available in ROS 1 `__. -* ``arg`` is used for declaring a launch argument, or to pass an argument when using ``include`` tags. -* Differences from ROS 1: - - * ``value`` attribute is not allowed. - Use ``let`` tag for this. - * ``doc`` is now ``description``. - * When nested within an ``include`` tag: - - * Use ``let`` instead of ``arg``. - * ``if``, ``unless``, and ``description`` attributes aren't allowed. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - - - - - - - -Passing an argument to the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the XML launch file above, the ``topic_name`` defaults to the name ``chatter``, but can be configured on the command-line. -Assuming the above launch configuration is in a file named ``mylaunch.xml``, a different topic name can be used by launching it with the following: - -.. code-block:: console - - $ ros2 launch mylaunch.xml topic_name:=custom_topic_name - -There is some additional information about passing command-line arguments in :doc:`Using Substitutions <../../../Tutorials/Intermediate/Launch/Using-Substitutions>`. - -env -^^^ - -* `Available in ROS 1 `__. -* Sets an environment variable. -* It has been replaced with ``env``, ``set_env`` and ``unset_env``: - - * ``env`` can only be used nested in a ``node`` or ``executable`` tag. - ``if`` and ``unless`` tags aren't supported. - * ``set_env`` can be nested within the root tag ``launch`` or in ``group`` tags. - It accepts the same attributes as ``env``, and also ``if`` and ``unless`` tags. - * ``unset_env`` unsets an environment variable. - It accepts a ``name`` attribute and conditionals. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - - - - - - - - - - - -group -^^^^^ - -* `Available in ROS 1 `__. -* Allows limiting the scope of launch configurations. - Usually used together with ``let``, ``include`` and ``push_ros_namespace`` tags. -* Differences from ROS 1: - - * There is no ``ns`` attribute. - See the new ``push_ros_namespace`` tag as a workaround. - * ``clear_params`` attribute isn't available. - * It doesn't accept ``remap`` nor ``param`` tags as children. - * It has two new attributes: ``scoped`` and ``forwarding`` (both are true by default). - If ``scoped`` is false, the group does not introduce a new variable scope, so actions done to variables inside the group also affect the outside variables. - If ``forwarding`` is false, no outside launch configurations ( ``arg`` ) are available inside the group. - This can be useful to isolate an included launch file and thus prevent collisions in argument names. - -.. _launch-prefix-example: - -Example -~~~~~~~ - -``launch-prefix`` configuration affects both ``executable`` and ``node`` tags' actions. -This example will use ``time`` as a prefix if ``use_time_prefix_in_talker`` argument is ``1``, only for the talker. - -.. code-block:: xml - - - - - - - - - - -machine -^^^^^^^ - -It is not supported at the moment. - -test -^^^^ - -It is not supported at the moment. - -New tags in ROS 2 ------------------ - -set_env and unset_env -^^^^^^^^^^^^^^^^^^^^^ - -See `env`_ tag description. - -push_ros_namespace -^^^^^^^^^^^^^^^^^^ - -``include`` and ``group`` tags don't accept an ``ns`` attribute. -This action can be used as a workaround: - -.. code-block:: xml - - - - - - - - - - - - - - - - - -let -^^^ - -It's a replacement of ``arg`` tag with a value attribute. - -.. code-block:: xml - - - -``let`` and ``arg`` serve two different purposes in ROS 2: - -* ``let`` sets a launch configuration value. -* ``arg`` declares a launch argument/configuration and optionally provides a default value. - The value can separately be set from the CLI or when including the given launch file. - If no value is set, the default value is used if one was provided, otherwise an error is reported. - -executable -^^^^^^^^^^ - -It allows running any executable. - -Example -~~~~~~~ - -.. code-block:: xml - - - - - -Replacing an include tag ------------------------- - -In order to include a launch file under a **namespace** as in ROS 1 then the ``include`` tags must be nested in a ``group`` tag. - -.. code-block:: xml - - - - - -Then, instead of using the ``ns`` attribute, add the ``push_ros_namespace`` action tag to specify the namespace: - -.. code-block:: xml - - - - - - -Nesting ``include`` tags under a ``group`` tag is only required when specifying a namespace - -Substitutions -------------- - -Documentation about ROS 1's substitutions can be found in `roslaunch XML wiki `__. -Substitutions syntax hasn't changed, i.e. it still follows the ``$(substitution-name arg1 arg2 ...)`` pattern. -There are, however, some changes w.r.t. ROS 1: - -* ``env`` and ``optenv`` tags have been replaced by the ``env`` tag. - ``$(env )`` will fail if the environment variable doesn't exist. - ``$(env '')`` does the same as ROS 1's ``$(optenv )``. - ``$(env )`` does the same as ROS 1's ``$(env )`` or ``$(optenv )``. -* ``find`` has been replaced with ``find-pkg-share`` (substituting the share directory of an installed package). - Alternatively ``find-pkg-prefix`` will return the root of an installed package. -* There is a new ``exec-in-pkg`` substitution. - e.g.: ``$(exec-in-pkg )``. -* There is a new ``find-exec`` substitution. -* ``arg`` has been replaced with ``var``. - It looks at configurations defined either with ``arg`` or ``let`` tag. -* ``eval`` and ``dirname`` substitutions require escape characters for string values, e.g. ``if="$(eval '\'$(var variable)\' == \'val1\'')"``. - You can also use HTML escapes like ``"`` . -* ``eval`` does not pass configurations ( ``arg`` ) as local Python variables. - They have to be accessed via ``$(var name)``. -* The argument of ``eval`` has to be a quoted string in ROS 2. - That is also the reason why quotes inside the expression have to be escaped. - -Type inference rules --------------------- - -The rules that were shown in ``Type inference rules`` subsection of ``param`` tag applies to any attribute. -For example: - -.. code-block:: xml - - - - - - - - - - - - - - -Some attributes accept more than a single type, for example ``value`` attribute of ``param`` tag. -It's usual that parameters that are of type ``int`` (or ``float``) also accept an ``str``, that will be later substituted and tried to convert to an ``int`` (or ``float``) by the action. +.. redirect-from:: + + Guides/Launch-files-migration-guide + Tutorials/Launch-files-migration-guide + How-To-Guides/Launch-files-migration-guide + How-To-Guides/Migrating-from-ROS1/Migrating-Launch-Files + +.. _MigratingLaunch: + +Migrating Launch Files +====================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +While launch files in ROS 1 are always specified using `XML `__ files, ROS 2 supports both XML and YAML files. +ROS 2 also supports Python launch scripts to enable more flexibility (see `launch package `__). +However, for typical use cases, XML and YAML should be preferred over Python. + +This guide describes how to write ROS 2 XML launch files for an easy migration from ROS 1. + +Background +---------- + +A description of the ROS 2 launch system can be found in :doc:`Launch System tutorial <../../../Tutorials/Intermediate/Launch/Launch-system>`. + + +Migrating tags +-------------- + +launch +^^^^^^ + +* `Available in ROS 1 `__. +* ``launch`` is the root element of any ROS 2 launch XML file. + +node +^^^^ + +* `Available in ROS 1 `__. +* Launches a new node. +* Differences from ROS 1: + + * ``type`` attribute is now ``exec``. + * ``ns`` attribute is now ``namespace``. + * ``required="true"`` is now ``on_exit="shutdown"``. + * The following attributes aren't available: ``machine``, ``respawn_delay``, ``clear_params``. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + + +param +^^^^^ + +* `Available in ROS 1 `__. +* Used for passing a parameter to a node. +* There's no global parameter concept in ROS 2. + For that reason, it can only be used nested in a ``node`` tag. + Some attributes aren't supported in ROS 2: ``type``, ``textfile``, ``binfile``, ``executable``. +* The ``command`` attribute is now ``value="$(command '...' )"``. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + + + +Type inference rules +~~~~~~~~~~~~~~~~~~~~ + +Here are some examples of how to write parameters: + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + +Parameter grouping +~~~~~~~~~~~~~~~~~~ + +In ROS 2, ``param`` tags are allowed to be nested. +For example: + +.. code-block:: xml + + + + + + + + + + +That will create two parameters: + +* A ``group1.group2.my_param`` of value ``1``, hosted by node ``/an_absolute_ns/my_node``. +* A ``group1.another_param`` of value ``2`` hosted by node ``/an_absolute_ns/my_node``. + +It's also possible to use full parameter names: + +.. code-block:: xml + + + + + + +rosparam +^^^^^^^^ + +* `Available in ROS 1 `__. +* Loads parameters from a yaml file. +* It has been replaced with a ``from`` attribute in ``param`` tags. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + +remap +^^^^^ + +* `Available in ROS 1 `__. +* Used to pass remapping rules to a node. +* It can only be used within ``node`` tags. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + + + + + + +include +^^^^^^^ + +* `Available in ROS 1 `__. +* Allows including another launch file. +* Differences from ROS 1: + + * Available in ROS 1, included content was scoped. + In ROS 2, it's not. + This means the values of ``arg`` tags are propagated into included launch files as if ``pass_all_args="true"`` were used in ROS 1. + However, this propagation only works for args that have a default value (in the inner/included launch file). + Required args have to be passed explicitly. + Nest includes in ``group`` tags to scope them (see also ``group`` attributes ``scoped`` and ``forwarding`` ). + * ``ns`` attribute is not supported. + See example of ``push_ros_namespace`` tag for a workaround. + * ``arg`` tag nested in an ``include`` tag is now ``let``. + However, ``arg`` is still supported for now. + * ``let`` tags nested in an ``include`` tag don't support conditionals (``if``, ``unless``) or the ``description`` attribute. + * There is no support for nested ``env`` tags. + ``set_env`` and ``unset_env`` can be used instead. + * Both ``clear_params`` and ``pass_all_args`` attributes aren't supported. + ROS 2 launch behaves as if ``pass_all_args`` were set to true (see above). + +Examples +~~~~~~~~ + +See `Replacing an include tag`_. + +arg +^^^ + +* `Available in ROS 1 `__. +* ``arg`` is used for declaring a launch argument, or to pass an argument when using ``include`` tags. +* Differences from ROS 1: + + * ``value`` attribute is not allowed. + Use ``let`` tag for this. + * ``doc`` is now ``description``. + * When nested within an ``include`` tag: + + * Use ``let`` instead of ``arg``. + * ``if``, ``unless``, and ``description`` attributes aren't allowed. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + + + + + + + +Passing an argument to the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the XML launch file above, the ``topic_name`` defaults to the name ``chatter``, but can be configured on the command-line. +Assuming the above launch configuration is in a file named ``mylaunch.xml``, a different topic name can be used by launching it with the following: + +.. code-block:: console + + $ ros2 launch mylaunch.xml topic_name:=custom_topic_name + +There is some additional information about passing command-line arguments in :doc:`Using Substitutions <../../../Tutorials/Intermediate/Launch/Using-Substitutions>`. + +env +^^^ + +* `Available in ROS 1 `__. +* Sets an environment variable. +* It has been replaced with ``env``, ``set_env`` and ``unset_env``: + + * ``env`` can only be used nested in a ``node`` or ``executable`` tag. + ``if`` and ``unless`` tags aren't supported. + * ``set_env`` can be nested within the root tag ``launch`` or in ``group`` tags. + It accepts the same attributes as ``env``, and also ``if`` and ``unless`` tags. + * ``unset_env`` unsets an environment variable. + It accepts a ``name`` attribute and conditionals. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + + + + + + + + + + + +group +^^^^^ + +* `Available in ROS 1 `__. +* Allows limiting the scope of launch configurations. + Usually used together with ``let``, ``include`` and ``push_ros_namespace`` tags. +* Differences from ROS 1: + + * There is no ``ns`` attribute. + See the new ``push_ros_namespace`` tag as a workaround. + * ``clear_params`` attribute isn't available. + * It doesn't accept ``remap`` nor ``param`` tags as children. + * It has two new attributes: ``scoped`` and ``forwarding`` (both are true by default). + If ``scoped`` is false, the group does not introduce a new variable scope, so actions done to variables inside the group also affect the outside variables. + If ``forwarding`` is false, no outside launch configurations ( ``arg`` ) are available inside the group. + This can be useful to isolate an included launch file and thus prevent collisions in argument names. + +.. _launch-prefix-example: + +Example +~~~~~~~ + +``launch-prefix`` configuration affects both ``executable`` and ``node`` tags' actions. +This example will use ``time`` as a prefix if ``use_time_prefix_in_talker`` argument is ``1``, only for the talker. + +.. code-block:: xml + + + + + + + + + + +machine +^^^^^^^ + +It is not supported at the moment. + +test +^^^^ + +It is not supported at the moment. + +New tags in ROS 2 +----------------- + +set_env and unset_env +^^^^^^^^^^^^^^^^^^^^^ + +See `env`_ tag description. + +push_ros_namespace +^^^^^^^^^^^^^^^^^^ + +``include`` and ``group`` tags don't accept an ``ns`` attribute. +This action can be used as a workaround: + +.. code-block:: xml + + + + + + + + + + + + + + + + + +let +^^^ + +It's a replacement of ``arg`` tag with a value attribute. + +.. code-block:: xml + + + +``let`` and ``arg`` serve two different purposes in ROS 2: + +* ``let`` sets a launch configuration value. +* ``arg`` declares a launch argument/configuration and optionally provides a default value. + The value can separately be set from the CLI or when including the given launch file. + If no value is set, the default value is used if one was provided, otherwise an error is reported. + +executable +^^^^^^^^^^ + +It allows running any executable. + +Example +~~~~~~~ + +.. code-block:: xml + + + + + +Replacing an include tag +------------------------ + +In order to include a launch file under a **namespace** as in ROS 1 then the ``include`` tags must be nested in a ``group`` tag. + +.. code-block:: xml + + + + + +Then, instead of using the ``ns`` attribute, add the ``push_ros_namespace`` action tag to specify the namespace: + +.. code-block:: xml + + + + + + +Nesting ``include`` tags under a ``group`` tag is only required when specifying a namespace + +Substitutions +------------- + +Documentation about ROS 1's substitutions can be found in `roslaunch XML wiki `__. +Substitutions syntax hasn't changed, i.e. it still follows the ``$(substitution-name arg1 arg2 ...)`` pattern. +There are, however, some changes w.r.t. ROS 1: + +* ``env`` and ``optenv`` tags have been replaced by the ``env`` tag. + ``$(env )`` will fail if the environment variable doesn't exist. + ``$(env '')`` does the same as ROS 1's ``$(optenv )``. + ``$(env )`` does the same as ROS 1's ``$(env )`` or ``$(optenv )``. +* ``find`` has been replaced with ``find-pkg-share`` (substituting the share directory of an installed package). + Alternatively ``find-pkg-prefix`` will return the root of an installed package. +* There is a new ``exec-in-pkg`` substitution. + e.g.: ``$(exec-in-pkg )``. +* There is a new ``find-exec`` substitution. +* ``arg`` has been replaced with ``var``. + It looks at configurations defined either with ``arg`` or ``let`` tag. +* ``eval`` and ``dirname`` substitutions require escape characters for string values, e.g. ``if="$(eval '\'$(var variable)\' == \'val1\'')"``. + You can also use HTML escapes like ``"`` . +* ``eval`` does not pass configurations ( ``arg`` ) as local Python variables. + They have to be accessed via ``$(var name)``. +* The argument of ``eval`` has to be a quoted string in ROS 2. + That is also the reason why quotes inside the expression have to be escaped. + +Type inference rules +-------------------- + +The rules that were shown in ``Type inference rules`` subsection of ``param`` tag applies to any attribute. +For example: + +.. code-block:: xml + + + + + + + + + + + + + + +Some attributes accept more than a single type, for example ``value`` attribute of ``param`` tag. +It's usual that parameters that are of type ``int`` (or ``float``) also accept an ``str``, that will be later substituted and tried to convert to an ``int`` (or ``float``) by the action. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst index 1e9a8861a59..f40b974d322 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst @@ -1,132 +1,136 @@ -Migrating your package.xml to format 2 -====================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -ROS 2 requires ``package.xml`` files to use at least `format 2 `__. -This guide shows how to migrate a ``package.xml`` from format 1 to format 2. - -If the ```` tag at the start of your ``package.xml`` looks like either of the following, then it is using format 1 and you must migrate it. - -.. code-block:: xml - - - -.. code-block:: xml - - - - -Prerequisites -------------- - -You should have a working ROS 1 installation. -This enables you to check that the converted ``package.xml`` is valid by building and testing the package, since ROS 1 supports all ``package.xml`` format versions. - -Migrate from format 1 to 2 --------------------------- - -Format 1 and format 2 differ in how they specify dependencies. -Read the `compatibility section in REP-0140 `__ for a summary of the differences. - -Add ``format`` attribute to ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Add or set the ``format`` attribute to ``2`` to indicate that the ``package.xml`` uses format 2. - -.. code:: xml - - - -Replace ```` -~~~~~~~~~~~~~~~~~~~~~~~~ - -The ```` tag is no longer allowed. -If you have a dependency specified like this: - -.. code:: xml - - foo - -then replace it with one or both of these tags: - -.. code:: xml - - foo - foo - -If the dependency is needed when something in your package is executed, then use the ```` tag. -If packages that depend on your package need the dependency when they are built, then use the ```` tag. -Use both tags if you are unsure. - -Convert some ```` to ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In format 1 ```` declares dependencies that are needed when running your package's tests. -It still does that in format 2, but it additionally declares dependencies that are needed when building your package's tests. - -Because of the limitations of this tag in format 1, your package may have a test-only dependency specified as a ```` like this: - -.. code:: xml - - testfoo - -If so, change it to a ````. - -.. code:: xml - - testfoo - -.. note:: - - If you are using CMake, then make sure your test dependencies are only referenced within a ``if(BUILD_TESTING)`` block: - - .. code:: cmake - - if (BUILD_TESTING) - find_package(testfoo REQUIRED) - endif() - -Begin using ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Use the new ```` tag to declare dependencies needed for building your package's documentation. -For example, C++ packages might have this dependency: - -.. code:: xml - - doxygen - -while Python packages might have this one: - -.. code:: xml - - python3-sphinx - -See :doc:`the guide on documenting ROS 2 packages <../Documenting-a-ROS-2-Package>` for more information. - -Simplify dependencies with ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -```` is a new tag that makes ``package.xml`` files more concise. -If your ``package.xml`` has these three tags for the same dependency: - -.. code:: - - foo - foo - foo - -then replace them with a single ```` like this: - -.. code:: xml - - foo - -Test your new ``package.xml`` ------------------------------ - -Build and test your package as you normally do using ``catkin_make``, ``cakin_make_isolated``, or the ``catkin`` build tool. -If everything succeeds, then your ``package.xml`` is valid. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Package-XML + +Migrating your package.xml to format 2 +====================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +ROS 2 requires ``package.xml`` files to use at least `format 2 `__. +This guide shows how to migrate a ``package.xml`` from format 1 to format 2. + +If the ```` tag at the start of your ``package.xml`` looks like either of the following, then it is using format 1 and you must migrate it. + +.. code-block:: xml + + + +.. code-block:: xml + + + + +Prerequisites +------------- + +You should have a working ROS 1 installation. +This enables you to check that the converted ``package.xml`` is valid by building and testing the package, since ROS 1 supports all ``package.xml`` format versions. + +Migrate from format 1 to 2 +-------------------------- + +Format 1 and format 2 differ in how they specify dependencies. +Read the `compatibility section in REP-0140 `__ for a summary of the differences. + +Add ``format`` attribute to ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Add or set the ``format`` attribute to ``2`` to indicate that the ``package.xml`` uses format 2. + +.. code:: xml + + + +Replace ```` +~~~~~~~~~~~~~~~~~~~~~~~~ + +The ```` tag is no longer allowed. +If you have a dependency specified like this: + +.. code:: xml + + foo + +then replace it with one or both of these tags: + +.. code:: xml + + foo + foo + +If the dependency is needed when something in your package is executed, then use the ```` tag. +If packages that depend on your package need the dependency when they are built, then use the ```` tag. +Use both tags if you are unsure. + +Convert some ```` to ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In format 1 ```` declares dependencies that are needed when running your package's tests. +It still does that in format 2, but it additionally declares dependencies that are needed when building your package's tests. + +Because of the limitations of this tag in format 1, your package may have a test-only dependency specified as a ```` like this: + +.. code:: xml + + testfoo + +If so, change it to a ````. + +.. code:: xml + + testfoo + +.. note:: + + If you are using CMake, then make sure your test dependencies are only referenced within a ``if(BUILD_TESTING)`` block: + + .. code:: cmake + + if (BUILD_TESTING) + find_package(testfoo REQUIRED) + endif() + +Begin using ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Use the new ```` tag to declare dependencies needed for building your package's documentation. +For example, C++ packages might have this dependency: + +.. code:: xml + + doxygen + +while Python packages might have this one: + +.. code:: xml + + python3-sphinx + +See :doc:`the guide on documenting ROS 2 packages <../../Developer-Tools/Build/Documenting-a-ROS-2-Package>` for more information. + +Simplify dependencies with ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +```` is a new tag that makes ``package.xml`` files more concise. +If your ``package.xml`` has these three tags for the same dependency: + +.. code:: + + foo + foo + foo + +then replace them with a single ```` like this: + +.. code:: xml + + foo + +Test your new ``package.xml`` +----------------------------- + +Build and test your package as you normally do using ``catkin_make``, ``cakin_make_isolated``, or the ``catkin`` build tool. +If everything succeeds, then your ``package.xml`` is valid. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst index 6c3f359732e..79fd5b70690 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst @@ -1,61 +1,65 @@ -Migrating Packages -================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -There are two different kinds of package migrations: - -* Migrating the source code of an existing package from ROS 1 to ROS 2 with the intent that a significant part of the source code will stay the same or at least similar. - An example for this is `pluginlib `_ where the source code is maintained in different branches within the same repository and common patches can be ported between those branches when necessary. -* Implementing the same or similar functionality of a ROS 1 package for ROS 2 but with the assumption that the source code will be significantly different. - An example for this is `roscpp `_ in ROS 1 and `rclcpp `_ in ROS 2 which are separate repositories and don't share any code. - -Prerequisites -------------- - -Before being able to migrate a ROS 1 package to ROS 2 all of its dependencies must be available in ROS 2. - -Package.xml format version --------------------------- - -ROS 2 only supports ``package.xml`` format versions 2 and higher. -If your package's ``package.xml`` uses format 1, then update it using the :doc:`Package.xml format 1 to 2 migration guide <./Migrating-Package-XML>`. - -Dependency names ----------------- - -Dependency names that come from :doc:`rosdep <../../Tutorials/Intermediate/Rosdep>` should not need to change, as those are shared across ROS 1 and ROS 2. - -Some packages released into ROS might have different names in ROS 2 so the dependencies might need to be updated accordingly. - -Metapackages ------------- - -ROS 2 doesn't have a special package type for metapackages. -Metapackages can still exist as regular packages that only contain runtime dependencies. -When migrating metapackages from ROS 1, simply remove the ```` tag in your package manifest. -See :doc:`Using variants <../Using-Variants>` for more information on metapackages/variants. - -Licensing ---------- - -In ROS 1 our recommended license was the `3-Clause BSD License `__. -In ROS 2 our recommended license is the `Apache 2.0 License `__. - -For any new project we recommend using the Apache 2.0 License, whether ROS 1 or ROS 2. - -However, when migrating code from ROS 1 to ROS 2 we cannot simply change the license. -The existing license must be preserved for any preexisting contributions. - -To that end if a package is being migrated we recommend keeping the existing license and continuing to contribute to that package under the existing OSI license, which we expect to be the BSD license for core elements. - -This will keep things clear and easy to understand. - -Changing the License -^^^^^^^^^^^^^^^^^^^^ - -It is possible to change the license, however you will need to contact all the contributors and get permission. -For most packages this is likely to be a significant effort and not worth considering. -If the package has a small set of contributors then this may be feasible. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Packages + +Migrating Packages +================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +There are two different kinds of package migrations: + +* Migrating the source code of an existing package from ROS 1 to ROS 2 with the intent that a significant part of the source code will stay the same or at least similar. + An example for this is `pluginlib `_ where the source code is maintained in different branches within the same repository and common patches can be ported between those branches when necessary. +* Implementing the same or similar functionality of a ROS 1 package for ROS 2 but with the assumption that the source code will be significantly different. + An example for this is `roscpp `_ in ROS 1 and `rclcpp `_ in ROS 2 which are separate repositories and don't share any code. + +Prerequisites +------------- + +Before being able to migrate a ROS 1 package to ROS 2 all of its dependencies must be available in ROS 2. + +Package.xml format version +-------------------------- + +ROS 2 only supports ``package.xml`` format versions 2 and higher. +If your package's ``package.xml`` uses format 1, then update it using the :doc:`Package.xml format 1 to 2 migration guide `. + +Dependency names +---------------- + +Dependency names that come from :doc:`rosdep <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep>` should not need to change, as those are shared across ROS 1 and ROS 2. + +Some packages released into ROS might have different names in ROS 2 so the dependencies might need to be updated accordingly. + +Metapackages +------------ + +ROS 2 doesn't have a special package type for metapackages. +Metapackages can still exist as regular packages that only contain runtime dependencies. +When migrating metapackages from ROS 1, simply remove the ```` tag in your package manifest. +See :doc:`Using variants <../../Developer-Tools/Build/Using-Variants>` for more information on metapackages/variants. + +Licensing +--------- + +In ROS 1 our recommended license was the `3-Clause BSD License `__. +In ROS 2 our recommended license is the `Apache 2.0 License `__. + +For any new project we recommend using the Apache 2.0 License, whether ROS 1 or ROS 2. + +However, when migrating code from ROS 1 to ROS 2 we cannot simply change the license. +The existing license must be preserved for any preexisting contributions. + +To that end if a package is being migrated we recommend keeping the existing license and continuing to contribute to that package under the existing OSI license, which we expect to be the BSD license for core elements. + +This will keep things clear and easy to understand. + +Changing the License +^^^^^^^^^^^^^^^^^^^^ + +It is possible to change the license, however you will need to contact all the contributors and get permission. +For most packages this is likely to be a significant effort and not worth considering. +If the package has a small set of contributors then this may be feasible. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst index a30cf19b03b..7b9984d987a 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst @@ -1,101 +1,102 @@ -.. redirect-from:: - - Guides/Parameters-YAML-files-migration-guide - Tutorials/Parameters-YAML-files-migration-guide - How-To-Guides/Parameters-YAML-files-migration-guide - -Migrating Parameters -==================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -In ROS 1, parameters are associated with a central server that allowed retrieving parameters at runtime through the use of the network APIs. -In ROS 2, parameters are associated per node and are configurable at runtime with ROS services. - -* See `ROS 2 Parameter design document `_ for more details about the system model. - -* See :doc:`ROS 2 CLI usage <../../Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` for a better understanding of how the CLI tools work and its differences with ROS 1 tooling. - -Global Parameter Server ------------------------ - -In ROS 1, the ``roscore`` acted like a global parameter blackboard where all nodes could get and set parameters. -Since there is no central ``roscore`` in ROS 2, that functionality no longer exists. -The recommended approach in ROS 2 is to use per-node parameters that are closely tied to the nodes that use them. -If a global blackboard is still needed, it is possible to create a dedicated node for this purpose. -ROS 2 ships with one in the ``ros-{DISTRO}-demo-nodes-cpp`` package called ``parameter_blackboard``; it can be run with: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp parameter_blackboard - -The code for the ``parameter_blackboard`` is `here `__. - -Migrating YAML Parameter Files ------------------------------- - -This guide describes how to adapt ROS 1 parameters files for ROS 2 and illustrates the difference in the way parameters can be accessed from the node level. - -YAML file example -^^^^^^^^^^^^^^^^^ - -YAML is used to write parameters files in both ROS 1 and ROS 2. -The main difference in ROS 2 is that node names must be used to address parameters. -In addition to the fully qualified node name, we use the key "ros__parameters" to signal the start of parameters for the node. - - -For example, here is a parameters file in ROS 1: - -.. code-block:: yaml - - lidar_name: foo - lidar_id: 10 - ports: [11312, 11311, 21311] - debug: true - -Let's assume that the first two parameters are for a node named ``/lidar_ns/lidar_node_name``, the next parameter is for a node named ``/imu``, and the last parameter we want to set on both nodes. - -We would construct our ROS 2 parameters file as follows: - -.. code-block:: yaml - - /lidar_ns: - lidar_node_name: - ros__parameters: - lidar_name: foo - id: 10 - imu: - ros__parameters: - ports: [2438, 2439, 2440] - /**: - ros__parameters: - debug: true - -Note the use of wildcards (``/**``) to indicate that the parameter ``debug`` should be set on any node in any namespace. - -Accessing parameters inside node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's say we want to use ``lidar_name`` parameter inside C++/Python node. -In ROS 1, we used slashes to separate node name and namespaces - ``"lidar_ns/lidar_node_name/lidar_name"``. -In ROS 2, we use dots instead of slashes - ``"lidar_ns.lidar_node_name.lidar_name"``. - -Feature parity -^^^^^^^^^^^^^^ - -Some features of ROS 1 parameters files do not exist in ROS 2: - -- Mixed types in a list is not supported yet (`related issue `_) -- ``deg`` and ``rad`` substitutions are not supported - - -Parameter Atomic Operation --------------------------- - -When migrating parameter groups from ROS 1 to ROS 2, there are important differences to consider. -In ROS 1, ``dynamic_reconfigure`` handles parameter groups atomically, meaning all parameters in a reconfiguration request are processed together in a single callback. -In ROS 2, the ``set_parameters`` service processes each parameter individually, which may lead to multiple callback invocations. -To maintain atomic behavior when migrating from ``dynamic_reconfigure``, use the ``set_parameters_atomically`` service, which validates and applies all parameters as a single operation. -If any parameter fails validation, no parameters will be updated. +.. redirect-from:: + + Guides/Parameters-YAML-files-migration-guide + Tutorials/Parameters-YAML-files-migration-guide + How-To-Guides/Parameters-YAML-files-migration-guide + How-To-Guides/Migrating-from-ROS1/Migrating-Parameters + +Migrating Parameters +==================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +In ROS 1, parameters are associated with a central server that allowed retrieving parameters at runtime through the use of the network APIs. +In ROS 2, parameters are associated per node and are configurable at runtime with ROS services. + +* See `ROS 2 Parameter design document `_ for more details about the system model. + +* See :doc:`ROS 2 CLI usage <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` for a better understanding of how the CLI tools work and its differences with ROS 1 tooling. + +Global Parameter Server +----------------------- + +In ROS 1, the ``roscore`` acted like a global parameter blackboard where all nodes could get and set parameters. +Since there is no central ``roscore`` in ROS 2, that functionality no longer exists. +The recommended approach in ROS 2 is to use per-node parameters that are closely tied to the nodes that use them. +If a global blackboard is still needed, it is possible to create a dedicated node for this purpose. +ROS 2 ships with one in the ``ros-{DISTRO}-demo-nodes-cpp`` package called ``parameter_blackboard``; it can be run with: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp parameter_blackboard + +The code for the ``parameter_blackboard`` is `here `__. + +Migrating YAML Parameter Files +------------------------------ + +This guide describes how to adapt ROS 1 parameters files for ROS 2 and illustrates the difference in the way parameters can be accessed from the node level. + +YAML file example +^^^^^^^^^^^^^^^^^ + +YAML is used to write parameters files in both ROS 1 and ROS 2. +The main difference in ROS 2 is that node names must be used to address parameters. +In addition to the fully qualified node name, we use the key "ros__parameters" to signal the start of parameters for the node. + + +For example, here is a parameters file in ROS 1: + +.. code-block:: yaml + + lidar_name: foo + lidar_id: 10 + ports: [11312, 11311, 21311] + debug: true + +Let's assume that the first two parameters are for a node named ``/lidar_ns/lidar_node_name``, the next parameter is for a node named ``/imu``, and the last parameter we want to set on both nodes. + +We would construct our ROS 2 parameters file as follows: + +.. code-block:: yaml + + /lidar_ns: + lidar_node_name: + ros__parameters: + lidar_name: foo + id: 10 + imu: + ros__parameters: + ports: [2438, 2439, 2440] + /**: + ros__parameters: + debug: true + +Note the use of wildcards (``/**``) to indicate that the parameter ``debug`` should be set on any node in any namespace. + +Accessing parameters inside node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's say we want to use ``lidar_name`` parameter inside C++/Python node. +In ROS 1, we used slashes to separate node name and namespaces - ``"lidar_ns/lidar_node_name/lidar_name"``. +In ROS 2, we use dots instead of slashes - ``"lidar_ns.lidar_node_name.lidar_name"``. + +Feature parity +^^^^^^^^^^^^^^ + +Some features of ROS 1 parameters files do not exist in ROS 2: + +- Mixed types in a list is not supported yet (`related issue `_) +- ``deg`` and ``rad`` substitutions are not supported + + +Parameter Atomic Operation +-------------------------- + +When migrating parameter groups from ROS 1 to ROS 2, there are important differences to consider. +In ROS 1, ``dynamic_reconfigure`` handles parameter groups atomically, meaning all parameters in a reconfiguration request are processed together in a single callback. +In ROS 2, the ``set_parameters`` service processes each parameter individually, which may lead to multiple callback invocations. +To maintain atomic behavior when migrating from ``dynamic_reconfigure``, use the ``set_parameters_atomically`` service, which validates and applies all parameters as a single operation. +If any parameter fails validation, no parameters will be updated. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst index e1abb0d353d..9b65af521e1 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst @@ -1,861 +1,865 @@ -Migrating a Python Package Example -================================== - -This guide shows how to migrate an example Python package from ROS 1 to ROS 2. - -.. contents:: Table of Contents - :depth: 2 - :local: - -Prerequisites -------------- - -You need a working ROS 2 installation, such as :doc:`ROS {DISTRO} <../../Installation>`. - -The ROS 1 code --------------- - -You won't be using `catkin `__ in this guide, so you don't need a working ROS 1 installation. -You are going to use ROS 2's build tool `Colcon `__ instead. - -This section gives you the code for a ROS 1 Python package. -The package is called ``talker_py``, and it has one node called ``talker_py_node``. -To make it easier to run Colcon later, these instructions make you create the package inside a `Colcon workspace `__, - -First, create a folder at ``~/ros2_talker_py`` to be the root of the Colcon workspace. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_talker_py/src - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_talker_py/src - - .. group-tab:: Windows - - .. code-block:: console - - $ md \ros2_talker_py\src - -Next, create the files for the ROS 1 package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_talker_py - $ mkdir -p src/talker_py/src/talker_py - $ mkdir -p src/talker_py/scripts - $ touch src/talker_py/package.xml - $ touch src/talker_py/CMakeLists.txt - $ touch src/talker_py/src/talker_py/__init__.py - $ touch src/talker_py/scripts/talker_py_node - $ touch src/talker_py/setup.py - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_talker_py - $ mkdir -p src/talker_py/src/talker_py - $ mkdir -p src/talker_py/scripts - $ touch src/talker_py/package.xml - $ touch src/talker_py/CMakeLists.txt - $ touch src/talker_py/src/talker_py/__init__.py - $ touch src/talker_py/scripts/talker_py_node - $ touch src/talker_py/setup.py - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_talker_py - $ md src\talker_py\src\talker_py - $ md src\talker_py\scripts - $ type nul > src\talker_py\package.xml - $ type nul > src\talker_py\CMakeLists.txt - $ type nul > src\talker_py\src\talker_py\__init__.py - $ type nul > src\talker_py\scripts/talker_py_node - $ type nul > src\talker_py\setup.py - -Put the following content into each file. - -``src/talker_py/package.xml``: - -.. code-block:: xml - - - - - talker_py - 1.0.0 - The talker_py package - Brian Gerkey - BSD - - catkin - - rospy - std_msgs - - -``src/talker_py/CMakeLists.txt``: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(talker_py) - - find_package(catkin REQUIRED) - - catkin_python_setup() - - catkin_package() - - catkin_install_python(PROGRAMS - scripts/talker_py_node - DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} - ) - -``src/talker/src/talker_py/__init__.py``: - -.. code-block:: Python - - import rospy - from std_msgs.msg import String - - def main(): - rospy.init_node('talker') - pub = rospy.Publisher('chatter', String, queue_size=10) - rate = rospy.Rate(10) # 10hz - while not rospy.is_shutdown(): - hello_str = "hello world %s" % rospy.get_time() - rospy.loginfo(hello_str) - pub.publish(hello_str) - rate.sleep() - -``src/talker_py/scripts/talker_py_node``: - -.. code-block:: Python - - #!/usr/bin/env python - - import talker_py - - if __name__ == '__main__': - talker_py.main() - -``src/talker_py/setup.py``: - -.. code-block:: Python - - from setuptools import setup - from catkin_pkg.python_setup import generate_distutils_setup - - setup_args = generate_distutils_setup( - packages=['talker_py'], - package_dir={'': 'src'} - ) - - setup(**setup_args) - -This is the complete ROS 1 Python package. - -Migrate the ``package.xml`` ---------------------------- - -When migrating packages to ROS 2, migrate the build system files first so that you can check your work by building and running code as you go. -Always start by migrating your ``package.xml``. - -First, ROS 2 does not use ``catkin``. -Delete the ```` on it. - -.. code-block:: - - - catkin - - -Next, ROS 2 uses ``rclpy`` instead of ``rospy``. -Delete the dependency on ``rospy``. - -.. code-block:: - - - rospy - - -Replace it with a new dependency on ``rclpy``. - -.. code-block:: xml - - rclpy - -Add an ```` section to tell ROS 2's build tool `Colcon `__ that this is an ``ament_python`` package instead of a ``catkin`` package. - -.. code-block:: xml - - - ament_python - - - -Your ``package.xml`` is fully migrated. -It should now look like this: - -.. code-block:: xml - - - - - talker_py - 1.0.0 - The talker_py package - Brian Gerkey - BSD - - rclpy - std_msgs - - - ament_python - - - -Delete the ``CMakeLists.txt`` ------------------------------ - -Python packages in ROS 2 do not use CMake, so delete the ``CMakeLists.txt``. - -Migrate the ``setup.py`` ------------------------- - -The arguments to ``setup()`` in the ``setup.py`` can no longer be automatically generated with ``catkin_pkg``. -You must pass these arguments manually, which means there will be some duplication with your ``package.xml``. - -Start by deleting the import from ``catkin_pkg``. - -.. code-block:: - - # Delete this - from catkin_pkg.python_setup import generate_distutils_setup - -Move all arguments given to ``generate_distutils_setup()`` to the call to ``setup()``, and then add the ``install_requires`` and ``zip_safe`` arguments. -Your call to ``setup()`` should look like this: - -.. code-block:: Python - - setup( - packages=['talker_py'], - package_dir={'': 'src'}, - install_requires=['setuptools'], - zip_safe=True, - ) - -Delete the call to ``generate_distutils_setup()``. - -.. code-block:: - - # Delete this - setup_args = generate_distutils_setup( - packages=['talker_py'], - package_dir={'': 'src'} - ) - -The call to ``setup()`` needs some `additional metadata `__ copied from the ``package.xml``: - -* package name via the ``name`` argument -* package version via the ``version`` argument -* maintainer via the ``maintainer`` and ``maintainer_email`` arguments -* description via the ``description`` argument -* license via the ``license`` argument - -The package name will be used multiple times. -Create a variable called ``package_name`` above the call to ``setup()``. - -.. code-block:: Python - - package_name = 'talker_py' - -Copy all of the remaining information into the arguments of ``setup()`` in ``setup.py``. -Your call to ``setup()`` should look like this: - -.. code-block:: Python - - setup( - name=package_name, - version='1.0.0', - install_requires=['setuptools'], - zip_safe=True, - packages=['talker_py'], - package_dir={'': 'src'}, - maintainer='Brian Gerkey', - maintainer_email='gerkey@example.com', - description='The talker_py package', - license='BSD', - ) - - -ROS 2 packages must install two data files: - -* a ``package.xml`` -* a package marker file - -Your package already has a ``package.xml``. -It describes your package's dependencies. -A package marker file tells tools like ``ros2 run`` where to find your package. - -Create a directory next to the ``package.xml`` called ``resource``. -Create an empty file in the ``resource`` directory with the same name as the package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir resource - $ touch resource/talker_py - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir resource - $ touch resource/talker_py - - .. group-tab:: Windows - - .. code-block:: console - - $ md resource - $ type nul > resource\talker_py - -The ``setup()`` call in ``setup.py`` must tell ``setuptools`` how to install these files. -Add the following ``data_files`` argument to the call to ``setup()``. - -.. code-block:: Python - - data_files=[ - ('share/ament_index/resource_index/packages', - ['resource/' + package_name]), - ('share/' + package_name, ['package.xml']), - ], - -Your ``setup.py`` is almost complete. - -Migrate Python scripts and create ``setup.cfg`` ------------------------------------------------ - -ROS 2 Python packages uses ``console_scripts`` `entry points `__ to install Python scripts as executables. -The `configuration file `__ ``setup.cfg`` tells ``setuptools`` to install those executables in a package specific directory so that tools like ``ros2 run`` can find them. -Create a ``setup.cfg`` file next to the ``package.xml``. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ touch setup.cfg - - .. group-tab:: macOS - - .. code-block:: console - - $ touch setup.cfg - - .. group-tab:: Windows - - .. code-block:: console - - $ type nul > touch setup.cfg - -Put the following content into it: - -.. code-block:: ini - - [develop] - script_dir=$base/lib/talker_py - [install] - install_scripts=$base/lib/talker_py - -You'll need to use the ``console_scripts`` entry point to define the executables to be installed. -Each entry has the format ``executable_name = some.module:function``. -The first part specifies the name of the executable to create. -The second part specifies the function that should be run when the executable starts. -This package needs to create an executable called ``talker_py_node``, and the executable needs to call the function ``main`` in the ``talker_py`` module. -Add the following entry point specification as another argument to ``setup()`` in your ``setup.py``. - -.. code-block:: Python - - entry_points={ - 'console_scripts': [ - 'talker_py_node = talker_py:main', - ], - }, - -The ``talker_py_node`` file is no longer necessary. -Delete the file ``talker_py_node`` and delete the ``scripts/`` directory. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rm scripts/talker_py_node - $ rmdir scripts - - .. group-tab:: macOS - - .. code-block:: console - - $ rm scripts/talker_py_node - $ rmdir scripts - - .. group-tab:: Windows - - .. code-block:: console - - $ del scripts/talker_py_node - $ rd scripts - -The addition of ``console_scripts`` is the last change to your ``setup.py``. -Your final ``setup.py`` should look like this: - -.. code-block:: Python - - from setuptools import setup - - package_name = 'talker_py' - - setup( - name=package_name, - version='1.0.0', - packages=['talker_py'], - package_dir={'': 'src'}, - install_requires=['setuptools'], - zip_safe=True, - data_files=[ - ('share/ament_index/resource_index/packages', - ['resource/' + package_name]), - ('share/' + package_name, ['package.xml']), - ], - maintainer='Brian Gerkey', - maintainer_email='gerkey@example.com', - description='The talker_py package', - license='BSD', - entry_points={ - 'console_scripts': [ - 'talker_py_node = talker_py:main', - ], - }, - ) - -Migrate Python code in ``src/talker_py/__init__.py`` ----------------------------------------------------- - -ROS 2 changed a lot of the best practices for Python code. -Start by migrating the code as-is. -It will be easier to refactor code later after you have something working. - -Use ``rclpy`` instead of ``rospy`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -ROS 2 packages use `rclpy `__ instead of ``rospy``. -You must do two things to use ``rclpy``: - - 1. Import ``rclpy`` - 2. Initialize ``rclpy`` - -Remove the statement that imports ``rospy``. - -.. code-block:: Python - - # Remove this - import rospy - -Replace it with a statement that imports ``rclpy``. - -.. code-block:: Python - - import rclpy - -Add a call to ``rclpy.init()`` as the very first statement in the ``main()`` function. - -.. code-block:: Python - - def main(): - # Add this line - rclpy.init() - -Execute callbacks in the background -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Both ROS 1 and ROS 2 use `callbacks `__. -In ROS 1, callbacks are always executed in background threads, and users are free to block the main thread with calls like ``rate.sleep()``. -In ROS 2, ``rclpy`` uses :doc:`Executors <../../Concepts/Intermediate/About-Executors>` to give users more control over where callbacks are called. -When porting code that uses blocking calls like ``rate.sleep()``, you must make sure that those calls won't interfere with the executor. -One way to do this is to create a dedicated thread for the executor. - -First, add these two import statements. - -.. code-block:: Python - - import threading - - from rclpy.executors import ExternalShutdownException - -Next, add top-level function called ``spin_in_background()``. -This function asks the default executor to execute callbacks until something shuts it down. - -.. code-block:: Python - - def spin_in_background(): - executor = rclpy.get_global_executor() - try: - executor.spin() - except ExternalShutdownException: - pass - -Add the following code in the ``main()`` function just after the call to ``rclpy.init()`` to start a thread that calls ``spin_in_background()``. - -.. code-block:: Python - - # In rospy callbacks are always called in background threads. - # Spin the executor in another thread for similar behavior in ROS 2. - t = threading.Thread(target=spin_in_background) - t.start() - - -Finally, join the thread when the program ends by putting this statement at the bottom of the ``main()`` function. - -.. code-block:: Python - - t.join() - - -Create a node -~~~~~~~~~~~~~ - -In ROS 1, Python scripts can only create a single node per process, and the API ``init_node()`` creates it. -In ROS 2, a single Python script may create multiple nodes, and the API to create a node is named ``create_node``. - -Remove the call to ``rospy.init_node()``: - -.. code-block:: - - rospy.init_node('talker') - -Add a new call to ``rclpy.create_node()`` and store the result in a variable named ``node``: - -.. code-block:: Python - - node = rclpy.create_node('talker') - -We must tell the executor about this node. -Add the following line just below the creation of the node: - -.. code-block:: Python - - rclpy.get_global_executor().add_node(node) - -Create a publisher -~~~~~~~~~~~~~~~~~~ - -In ROS 1, users create publishers by instantiating the ``Publisher`` class. -In ROS 2, users create publishers through a node's ``create_publisher()`` API. -The ``create_publisher()`` API has an unfortunate difference with ROS 1: the topic name and topic type arguments are swapped. - -Remove the creation of the ``rospy.Publisher`` instance. - -.. code-block:: - - pub = rospy.Publisher('chatter', String, queue_size=10) - -Replace it with a call to ``node.create_publisher()``. - -.. code-block:: Python - - pub = node.create_publisher(String, 'chatter', 10) - - -Create a rate -~~~~~~~~~~~~~ - -In ROS 1, users create ``Rate`` instances directly, while in ROS 2 users create them through a node's ``create_rate()`` API. - -Remove the creation of the ``rospy.Rate`` instance. - -.. code-block:: - - rate = rospy.Rate(10) # 10hz - -Replace it with a call to ``node.create_rate()``. - -.. code-block:: Python - - rate = node.create_rate(10) # 10hz - -Loop on ``rclpy.ok()`` -~~~~~~~~~~~~~~~~~~~~~~ - -In ROS 1, the ``rospy.is_shutdown()`` API indicates if the process has been asked to shutdown. -In ROS 2, the ``rclpy.ok()`` API does this. - -Remove the statement ``not rospy.is_shutdown()`` - -.. code-block:: - - while not rospy.is_shutdown(): - -Replace it with a call to ``rclpy.ok()``. - -.. code-block:: Python - - while rclpy.ok(): - - -Create a ``String`` message with the current time -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You must make a few changes to this line - -.. code-block:: - - hello_str = "hello world %s" % rospy.get_time() - -In ROS 2 you: - -* Must get the time from a ``Clock`` instance -* Should format the ``str`` data using `f-strings `__ since `% is discouraged in active Python versions `__ -* Must instantiate a ``std_msgs.msg.String`` instance - -Start with getting the time. -ROS 2 nodes have a ``Clock`` instance. -Replace the call to ``rospy.get_time()`` with ``node.get_clock().now()`` to get the current time from the node's clock. - -Next, replace the use of ``%`` with an f-string: ``f'hello world {node.get_clock().now()}'``. - -Finally, instantiate a ``std_msgs.msg.String()`` instance and assign the above to the ``data`` attribute of that instance. -Your final code should look like this: - -.. code-block:: Python - - hello_str = String() - hello_str.data = f'hello world {node.get_clock().now()}' - -Log an informational message -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In ROS 2, you must send log messages through a ``Logger`` instance, and the node has one. - -Remove the call to ``rospy.loginfo()``. - -.. code-block:: - - rospy.loginfo(hello_str) - -Replace it with a call to ``info()`` on the node's ``Logger`` instance. - -.. code-block:: Python - - node.get_logger().info(hello_str.data) - -This is the last change to ``src/talker_py/__init__.py``. -Your file should look like the following: - -.. code-block:: Python - - import threading - - import rclpy - from rclpy.executors import ExternalShutdownException - from std_msgs.msg import String - - - def spin_in_background(): - executor = rclpy.get_global_executor() - try: - executor.spin() - except ExternalShutdownException: - pass - - - def main(): - rclpy.init() - # In rospy callbacks are always called in background threads. - # Spin the executor in another thread for similar behavior in ROS 2. - t = threading.Thread(target=spin_in_background) - t.start() - - node = rclpy.create_node('talker') - rclpy.get_global_executor().add_node(node) - pub = node.create_publisher(String, 'chatter', 10) - rate = node.create_rate(10) # 10hz - - while rclpy.ok(): - hello_str = String() - hello_str.data = f'hello world {node.get_clock().now()}' - node.get_logger().info(hello_str.data) - pub.publish(hello_str) - rate.sleep() - - t.join() - - -Build and run ``talker_py_node`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Create three terminals: - -1. One to build ``talker_py`` -2. One to run ``talker_py_node`` -3. One to echo the message published by ``talker_py_node`` - -Build the workspace in the first terminal. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_talker_py - $ . /opt/ros/{DISTRO}/setup.bash - $ colcon build - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_talker_py - $ . /opt/ros/{DISTRO}/setup.bash - $ colcon build - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_talker_py - $ call C:\dev\ros2\local_setup.bat - $ colcon build - -Source your workspace in the second terminal, and run the ``talker_py_node``. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_talker_py - $ . install/setup.bash - $ ros2 run talker_py talker_py_node - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_talker_py - $ . install/setup.bash - $ ros2 run talker_py talker_py_node - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_talker_py - $ call install\setup.bat - $ ros2 run talker_py talker_py_node - -Echo the message published by the node in the third terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . /opt/ros/{DISTRO}/setup.bash - $ ros2 topic echo /chatter - - .. group-tab:: macOS - - .. code-block:: console - - $ . /opt/ros/{DISTRO}/setup.bash - $ ros2 topic echo /chatter - - .. group-tab:: Windows - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - $ ros2 topic echo /chatter - - -You should see messages with the current time being published in the second terminal, and those same messages received in the third. - -Refactor code to use ROS 2 conventions --------------------------------------- - -You have successfully migrated a ROS 1 Python package to ROS 2! -Now that you have something working, consider refactoring it to align better with ROS 2's Python APIs. -Follow these two principles. - -* Create a class that inherits from ``Node``. -* Do all work in callbacks, and never block those callbacks. - -For example, create a ``Talker`` class that inherits from ``Node``. -As for doing work in callbacks, use a ``Timer`` with a callback instead of ``rate.sleep()``. -Make the timer callback publish the message and return. -Make ``main()`` create a ``Talker`` instance rather than using ``rclpy.create_node()``, and give the executor the main thread to execute in. - -Your refactored code might look like this: - -.. code-block:: Python - - import rclpy - from rclpy.node import Node - from rclpy.executors import ExternalShutdownException - from std_msgs.msg import String - - - class Talker(Node): - - def __init__(self, **kwargs): - super().__init__('talker', **kwargs) - - self._pub = self.create_publisher(String, 'chatter', 10) - self._timer = self.create_timer(1 / 10, self.do_publish) - - def do_publish(self): - hello_str = String() - hello_str.data = f'hello world {self.get_clock().now()}' - self.get_logger().info(hello_str.data) - self._pub.publish(hello_str) - - - def main(): - try: - with rclpy.init(): - rclpy.spin(Talker()) - except (ExternalShutdownException, KeyboardInterrupt): - pass - -Conclusion ----------- - -You have learned how to migrate an example Python ROS 1 package to ROS 2. -From now on, refer to the :doc:`Migrating Python Packages reference page <./Migrating-Python-Packages>` as you migrate your own Python packages. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Python-Package-Example + +Migrating a Python Package Example +================================== + +This guide shows how to migrate an example Python package from ROS 1 to ROS 2. + +.. contents:: Table of Contents + :depth: 2 + :local: + +Prerequisites +------------- + +You need a working ROS 2 installation, such as :doc:`ROS {DISTRO} <../../Get-Started/Installation>`. + +The ROS 1 code +-------------- + +You won't be using `catkin `__ in this guide, so you don't need a working ROS 1 installation. +You are going to use ROS 2's build tool `Colcon `__ instead. + +This section gives you the code for a ROS 1 Python package. +The package is called ``talker_py``, and it has one node called ``talker_py_node``. +To make it easier to run Colcon later, these instructions make you create the package inside a `Colcon workspace `__, + +First, create a folder at ``~/ros2_talker_py`` to be the root of the Colcon workspace. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_talker_py/src + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_talker_py/src + + .. group-tab:: Windows + + .. code-block:: console + + $ md \ros2_talker_py\src + +Next, create the files for the ROS 1 package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_talker_py + $ mkdir -p src/talker_py/src/talker_py + $ mkdir -p src/talker_py/scripts + $ touch src/talker_py/package.xml + $ touch src/talker_py/CMakeLists.txt + $ touch src/talker_py/src/talker_py/__init__.py + $ touch src/talker_py/scripts/talker_py_node + $ touch src/talker_py/setup.py + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_talker_py + $ mkdir -p src/talker_py/src/talker_py + $ mkdir -p src/talker_py/scripts + $ touch src/talker_py/package.xml + $ touch src/talker_py/CMakeLists.txt + $ touch src/talker_py/src/talker_py/__init__.py + $ touch src/talker_py/scripts/talker_py_node + $ touch src/talker_py/setup.py + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_talker_py + $ md src\talker_py\src\talker_py + $ md src\talker_py\scripts + $ type nul > src\talker_py\package.xml + $ type nul > src\talker_py\CMakeLists.txt + $ type nul > src\talker_py\src\talker_py\__init__.py + $ type nul > src\talker_py\scripts/talker_py_node + $ type nul > src\talker_py\setup.py + +Put the following content into each file. + +``src/talker_py/package.xml``: + +.. code-block:: xml + + + + + talker_py + 1.0.0 + The talker_py package + Brian Gerkey + BSD + + catkin + + rospy + std_msgs + + +``src/talker_py/CMakeLists.txt``: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(talker_py) + + find_package(catkin REQUIRED) + + catkin_python_setup() + + catkin_package() + + catkin_install_python(PROGRAMS + scripts/talker_py_node + DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION} + ) + +``src/talker/src/talker_py/__init__.py``: + +.. code-block:: Python + + import rospy + from std_msgs.msg import String + + def main(): + rospy.init_node('talker') + pub = rospy.Publisher('chatter', String, queue_size=10) + rate = rospy.Rate(10) # 10hz + while not rospy.is_shutdown(): + hello_str = "hello world %s" % rospy.get_time() + rospy.loginfo(hello_str) + pub.publish(hello_str) + rate.sleep() + +``src/talker_py/scripts/talker_py_node``: + +.. code-block:: Python + + #!/usr/bin/env python + + import talker_py + + if __name__ == '__main__': + talker_py.main() + +``src/talker_py/setup.py``: + +.. code-block:: Python + + from setuptools import setup + from catkin_pkg.python_setup import generate_distutils_setup + + setup_args = generate_distutils_setup( + packages=['talker_py'], + package_dir={'': 'src'} + ) + + setup(**setup_args) + +This is the complete ROS 1 Python package. + +Migrate the ``package.xml`` +--------------------------- + +When migrating packages to ROS 2, migrate the build system files first so that you can check your work by building and running code as you go. +Always start by migrating your ``package.xml``. + +First, ROS 2 does not use ``catkin``. +Delete the ```` on it. + +.. code-block:: + + + catkin + + +Next, ROS 2 uses ``rclpy`` instead of ``rospy``. +Delete the dependency on ``rospy``. + +.. code-block:: + + + rospy + + +Replace it with a new dependency on ``rclpy``. + +.. code-block:: xml + + rclpy + +Add an ```` section to tell ROS 2's build tool `Colcon `__ that this is an ``ament_python`` package instead of a ``catkin`` package. + +.. code-block:: xml + + + ament_python + + + +Your ``package.xml`` is fully migrated. +It should now look like this: + +.. code-block:: xml + + + + + talker_py + 1.0.0 + The talker_py package + Brian Gerkey + BSD + + rclpy + std_msgs + + + ament_python + + + +Delete the ``CMakeLists.txt`` +----------------------------- + +Python packages in ROS 2 do not use CMake, so delete the ``CMakeLists.txt``. + +Migrate the ``setup.py`` +------------------------ + +The arguments to ``setup()`` in the ``setup.py`` can no longer be automatically generated with ``catkin_pkg``. +You must pass these arguments manually, which means there will be some duplication with your ``package.xml``. + +Start by deleting the import from ``catkin_pkg``. + +.. code-block:: + + # Delete this + from catkin_pkg.python_setup import generate_distutils_setup + +Move all arguments given to ``generate_distutils_setup()`` to the call to ``setup()``, and then add the ``install_requires`` and ``zip_safe`` arguments. +Your call to ``setup()`` should look like this: + +.. code-block:: Python + + setup( + packages=['talker_py'], + package_dir={'': 'src'}, + install_requires=['setuptools'], + zip_safe=True, + ) + +Delete the call to ``generate_distutils_setup()``. + +.. code-block:: + + # Delete this + setup_args = generate_distutils_setup( + packages=['talker_py'], + package_dir={'': 'src'} + ) + +The call to ``setup()`` needs some `additional metadata `__ copied from the ``package.xml``: + +* package name via the ``name`` argument +* package version via the ``version`` argument +* maintainer via the ``maintainer`` and ``maintainer_email`` arguments +* description via the ``description`` argument +* license via the ``license`` argument + +The package name will be used multiple times. +Create a variable called ``package_name`` above the call to ``setup()``. + +.. code-block:: Python + + package_name = 'talker_py' + +Copy all of the remaining information into the arguments of ``setup()`` in ``setup.py``. +Your call to ``setup()`` should look like this: + +.. code-block:: Python + + setup( + name=package_name, + version='1.0.0', + install_requires=['setuptools'], + zip_safe=True, + packages=['talker_py'], + package_dir={'': 'src'}, + maintainer='Brian Gerkey', + maintainer_email='gerkey@example.com', + description='The talker_py package', + license='BSD', + ) + + +ROS 2 packages must install two data files: + +* a ``package.xml`` +* a package marker file + +Your package already has a ``package.xml``. +It describes your package's dependencies. +A package marker file tells tools like ``ros2 run`` where to find your package. + +Create a directory next to the ``package.xml`` called ``resource``. +Create an empty file in the ``resource`` directory with the same name as the package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir resource + $ touch resource/talker_py + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir resource + $ touch resource/talker_py + + .. group-tab:: Windows + + .. code-block:: console + + $ md resource + $ type nul > resource\talker_py + +The ``setup()`` call in ``setup.py`` must tell ``setuptools`` how to install these files. +Add the following ``data_files`` argument to the call to ``setup()``. + +.. code-block:: Python + + data_files=[ + ('share/ament_index/resource_index/packages', + ['resource/' + package_name]), + ('share/' + package_name, ['package.xml']), + ], + +Your ``setup.py`` is almost complete. + +Migrate Python scripts and create ``setup.cfg`` +----------------------------------------------- + +ROS 2 Python packages uses ``console_scripts`` `entry points `__ to install Python scripts as executables. +The `configuration file `__ ``setup.cfg`` tells ``setuptools`` to install those executables in a package specific directory so that tools like ``ros2 run`` can find them. +Create a ``setup.cfg`` file next to the ``package.xml``. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ touch setup.cfg + + .. group-tab:: macOS + + .. code-block:: console + + $ touch setup.cfg + + .. group-tab:: Windows + + .. code-block:: console + + $ type nul > touch setup.cfg + +Put the following content into it: + +.. code-block:: ini + + [develop] + script_dir=$base/lib/talker_py + [install] + install_scripts=$base/lib/talker_py + +You'll need to use the ``console_scripts`` entry point to define the executables to be installed. +Each entry has the format ``executable_name = some.module:function``. +The first part specifies the name of the executable to create. +The second part specifies the function that should be run when the executable starts. +This package needs to create an executable called ``talker_py_node``, and the executable needs to call the function ``main`` in the ``talker_py`` module. +Add the following entry point specification as another argument to ``setup()`` in your ``setup.py``. + +.. code-block:: Python + + entry_points={ + 'console_scripts': [ + 'talker_py_node = talker_py:main', + ], + }, + +The ``talker_py_node`` file is no longer necessary. +Delete the file ``talker_py_node`` and delete the ``scripts/`` directory. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rm scripts/talker_py_node + $ rmdir scripts + + .. group-tab:: macOS + + .. code-block:: console + + $ rm scripts/talker_py_node + $ rmdir scripts + + .. group-tab:: Windows + + .. code-block:: console + + $ del scripts/talker_py_node + $ rd scripts + +The addition of ``console_scripts`` is the last change to your ``setup.py``. +Your final ``setup.py`` should look like this: + +.. code-block:: Python + + from setuptools import setup + + package_name = 'talker_py' + + setup( + name=package_name, + version='1.0.0', + packages=['talker_py'], + package_dir={'': 'src'}, + install_requires=['setuptools'], + zip_safe=True, + data_files=[ + ('share/ament_index/resource_index/packages', + ['resource/' + package_name]), + ('share/' + package_name, ['package.xml']), + ], + maintainer='Brian Gerkey', + maintainer_email='gerkey@example.com', + description='The talker_py package', + license='BSD', + entry_points={ + 'console_scripts': [ + 'talker_py_node = talker_py:main', + ], + }, + ) + +Migrate Python code in ``src/talker_py/__init__.py`` +---------------------------------------------------- + +ROS 2 changed a lot of the best practices for Python code. +Start by migrating the code as-is. +It will be easier to refactor code later after you have something working. + +Use ``rclpy`` instead of ``rospy`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ROS 2 packages use `rclpy `__ instead of ``rospy``. +You must do two things to use ``rclpy``: + + 1. Import ``rclpy`` + 2. Initialize ``rclpy`` + +Remove the statement that imports ``rospy``. + +.. code-block:: Python + + # Remove this + import rospy + +Replace it with a statement that imports ``rclpy``. + +.. code-block:: Python + + import rclpy + +Add a call to ``rclpy.init()`` as the very first statement in the ``main()`` function. + +.. code-block:: Python + + def main(): + # Add this line + rclpy.init() + +Execute callbacks in the background +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Both ROS 1 and ROS 2 use `callbacks `__. +In ROS 1, callbacks are always executed in background threads, and users are free to block the main thread with calls like ``rate.sleep()``. +In ROS 2, ``rclpy`` uses :doc:`Executors <../../ROS-Framework/client-libraries/About-Executors/About-Executors>` to give users more control over where callbacks are called. +When porting code that uses blocking calls like ``rate.sleep()``, you must make sure that those calls won't interfere with the executor. +One way to do this is to create a dedicated thread for the executor. + +First, add these two import statements. + +.. code-block:: Python + + import threading + + from rclpy.executors import ExternalShutdownException + +Next, add top-level function called ``spin_in_background()``. +This function asks the default executor to execute callbacks until something shuts it down. + +.. code-block:: Python + + def spin_in_background(): + executor = rclpy.get_global_executor() + try: + executor.spin() + except ExternalShutdownException: + pass + +Add the following code in the ``main()`` function just after the call to ``rclpy.init()`` to start a thread that calls ``spin_in_background()``. + +.. code-block:: Python + + # In rospy callbacks are always called in background threads. + # Spin the executor in another thread for similar behavior in ROS 2. + t = threading.Thread(target=spin_in_background) + t.start() + + +Finally, join the thread when the program ends by putting this statement at the bottom of the ``main()`` function. + +.. code-block:: Python + + t.join() + + +Create a node +~~~~~~~~~~~~~ + +In ROS 1, Python scripts can only create a single node per process, and the API ``init_node()`` creates it. +In ROS 2, a single Python script may create multiple nodes, and the API to create a node is named ``create_node``. + +Remove the call to ``rospy.init_node()``: + +.. code-block:: + + rospy.init_node('talker') + +Add a new call to ``rclpy.create_node()`` and store the result in a variable named ``node``: + +.. code-block:: Python + + node = rclpy.create_node('talker') + +We must tell the executor about this node. +Add the following line just below the creation of the node: + +.. code-block:: Python + + rclpy.get_global_executor().add_node(node) + +Create a publisher +~~~~~~~~~~~~~~~~~~ + +In ROS 1, users create publishers by instantiating the ``Publisher`` class. +In ROS 2, users create publishers through a node's ``create_publisher()`` API. +The ``create_publisher()`` API has an unfortunate difference with ROS 1: the topic name and topic type arguments are swapped. + +Remove the creation of the ``rospy.Publisher`` instance. + +.. code-block:: + + pub = rospy.Publisher('chatter', String, queue_size=10) + +Replace it with a call to ``node.create_publisher()``. + +.. code-block:: Python + + pub = node.create_publisher(String, 'chatter', 10) + + +Create a rate +~~~~~~~~~~~~~ + +In ROS 1, users create ``Rate`` instances directly, while in ROS 2 users create them through a node's ``create_rate()`` API. + +Remove the creation of the ``rospy.Rate`` instance. + +.. code-block:: + + rate = rospy.Rate(10) # 10hz + +Replace it with a call to ``node.create_rate()``. + +.. code-block:: Python + + rate = node.create_rate(10) # 10hz + +Loop on ``rclpy.ok()`` +~~~~~~~~~~~~~~~~~~~~~~ + +In ROS 1, the ``rospy.is_shutdown()`` API indicates if the process has been asked to shutdown. +In ROS 2, the ``rclpy.ok()`` API does this. + +Remove the statement ``not rospy.is_shutdown()`` + +.. code-block:: + + while not rospy.is_shutdown(): + +Replace it with a call to ``rclpy.ok()``. + +.. code-block:: Python + + while rclpy.ok(): + + +Create a ``String`` message with the current time +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You must make a few changes to this line + +.. code-block:: + + hello_str = "hello world %s" % rospy.get_time() + +In ROS 2 you: + +* Must get the time from a ``Clock`` instance +* Should format the ``str`` data using `f-strings `__ since `% is discouraged in active Python versions `__ +* Must instantiate a ``std_msgs.msg.String`` instance + +Start with getting the time. +ROS 2 nodes have a ``Clock`` instance. +Replace the call to ``rospy.get_time()`` with ``node.get_clock().now()`` to get the current time from the node's clock. + +Next, replace the use of ``%`` with an f-string: ``f'hello world {node.get_clock().now()}'``. + +Finally, instantiate a ``std_msgs.msg.String()`` instance and assign the above to the ``data`` attribute of that instance. +Your final code should look like this: + +.. code-block:: Python + + hello_str = String() + hello_str.data = f'hello world {node.get_clock().now()}' + +Log an informational message +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In ROS 2, you must send log messages through a ``Logger`` instance, and the node has one. + +Remove the call to ``rospy.loginfo()``. + +.. code-block:: + + rospy.loginfo(hello_str) + +Replace it with a call to ``info()`` on the node's ``Logger`` instance. + +.. code-block:: Python + + node.get_logger().info(hello_str.data) + +This is the last change to ``src/talker_py/__init__.py``. +Your file should look like the following: + +.. code-block:: Python + + import threading + + import rclpy + from rclpy.executors import ExternalShutdownException + from std_msgs.msg import String + + + def spin_in_background(): + executor = rclpy.get_global_executor() + try: + executor.spin() + except ExternalShutdownException: + pass + + + def main(): + rclpy.init() + # In rospy callbacks are always called in background threads. + # Spin the executor in another thread for similar behavior in ROS 2. + t = threading.Thread(target=spin_in_background) + t.start() + + node = rclpy.create_node('talker') + rclpy.get_global_executor().add_node(node) + pub = node.create_publisher(String, 'chatter', 10) + rate = node.create_rate(10) # 10hz + + while rclpy.ok(): + hello_str = String() + hello_str.data = f'hello world {node.get_clock().now()}' + node.get_logger().info(hello_str.data) + pub.publish(hello_str) + rate.sleep() + + t.join() + + +Build and run ``talker_py_node`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Create three terminals: + +1. One to build ``talker_py`` +2. One to run ``talker_py_node`` +3. One to echo the message published by ``talker_py_node`` + +Build the workspace in the first terminal. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_talker_py + $ . /opt/ros/{DISTRO}/setup.bash + $ colcon build + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_talker_py + $ . /opt/ros/{DISTRO}/setup.bash + $ colcon build + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_talker_py + $ call C:\dev\ros2\local_setup.bat + $ colcon build + +Source your workspace in the second terminal, and run the ``talker_py_node``. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_talker_py + $ . install/setup.bash + $ ros2 run talker_py talker_py_node + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_talker_py + $ . install/setup.bash + $ ros2 run talker_py talker_py_node + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_talker_py + $ call install\setup.bat + $ ros2 run talker_py talker_py_node + +Echo the message published by the node in the third terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . /opt/ros/{DISTRO}/setup.bash + $ ros2 topic echo /chatter + + .. group-tab:: macOS + + .. code-block:: console + + $ . /opt/ros/{DISTRO}/setup.bash + $ ros2 topic echo /chatter + + .. group-tab:: Windows + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + $ ros2 topic echo /chatter + + +You should see messages with the current time being published in the second terminal, and those same messages received in the third. + +Refactor code to use ROS 2 conventions +-------------------------------------- + +You have successfully migrated a ROS 1 Python package to ROS 2! +Now that you have something working, consider refactoring it to align better with ROS 2's Python APIs. +Follow these two principles. + +* Create a class that inherits from ``Node``. +* Do all work in callbacks, and never block those callbacks. + +For example, create a ``Talker`` class that inherits from ``Node``. +As for doing work in callbacks, use a ``Timer`` with a callback instead of ``rate.sleep()``. +Make the timer callback publish the message and return. +Make ``main()`` create a ``Talker`` instance rather than using ``rclpy.create_node()``, and give the executor the main thread to execute in. + +Your refactored code might look like this: + +.. code-block:: Python + + import rclpy + from rclpy.node import Node + from rclpy.executors import ExternalShutdownException + from std_msgs.msg import String + + + class Talker(Node): + + def __init__(self, **kwargs): + super().__init__('talker', **kwargs) + + self._pub = self.create_publisher(String, 'chatter', 10) + self._timer = self.create_timer(1 / 10, self.do_publish) + + def do_publish(self): + hello_str = String() + hello_str.data = f'hello world {self.get_clock().now()}' + self.get_logger().info(hello_str.data) + self._pub.publish(hello_str) + + + def main(): + try: + with rclpy.init(): + rclpy.spin(Talker()) + except (ExternalShutdownException, KeyboardInterrupt): + pass + +Conclusion +---------- + +You have learned how to migrate an example Python ROS 1 package to ROS 2. +From now on, refer to the :doc:`Migrating Python Packages reference page ` as you migrate your own Python packages. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst index 72fc3b4fd26..029a365b91a 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst @@ -1,177 +1,178 @@ -.. redirect-from:: - - Migration-Guide-Python - The-ROS2-Project/Contributing/Migration-Guide-Python - -Migrating Python Packages Reference -=================================== - -This page is a reference on how to migrate Python packages from ROS 1 to ROS 2. -If this is your first time migrating a Python package, then follow :doc:`this guide to migrate an example Python package <./Migrating-Python-Package-Example>` first. - -.. contents:: Table of Contents - :depth: 2 - :local: - -Build tool ----------- - -Instead of using ``catkin_make``, ``catkin_make_isolated`` or ``catkin build`` ROS 2 uses the command line tool `colcon `__ to build and install a set of packages. -See the :doc:`beginner tutorial <../../Tutorials/Beginner-Client-Libraries/Colcon-Tutorial>` to get started with ``colcon``. - -Build system ------------- - -For pure Python packages, ROS 2 uses the standard ``setup.py`` installation mechanism familiar to Python developers. - -Update the files to use *setup.py* -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If the ROS 1 package uses CMake only to invoke the ``setup.py`` file and does not contain anything beside Python code (e.g. no messages, services, etc.) it should be converted into a pure Python package in ROS 2: - -* - Update or add the build type in the ``package.xml`` file: - - .. code-block:: xml - - - ament_python - - -* - Remove the ``CMakeLists.txt`` file - -* - Update the ``setup.py`` file to be a standard Python setup script - -ROS 2 supports Python 3 only. -While each package can choose to also support Python 2 it must invoke executables with Python 3 if it uses any API provided by other ROS 2 packages. - -Update source code ------------------- - -Node Initialization -^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - rospy.init_node('asdf') - - rospy.loginfo('Created node') - -In ROS 2: - -.. code-block:: python - - with rclpy.init(args=sys.argv): - node = rclpy.create_node('asdf') - - node.get_logger().info('Created node') - -ROS Parameters -^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - port = rospy.get_param('port', '/dev/ttyUSB0') - assert isinstance(port, str), 'port parameter must be a str' - - baudrate = rospy.get_param('baudrate', 115200) - assert isinstance(baudrate, int), 'baudrate parameter must be an integer' - - rospy.logwarn('port: ' + port) - -In ROS 2: - -.. code-block:: python - - port = node.declare_parameter('port', '/dev/ttyUSB0').value - assert isinstance(port, str), 'port parameter must be a str' - - baudrate = node.declare_parameter('baudrate', 115200).value - assert isinstance(baudrate, int), 'baudrate parameter must be an integer' - - node.get_logger().warn('port: ' + port) - -Creating a Publisher -^^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - pub = rospy.Publisher('chatter', String) - # or - pub = rospy.Publisher('chatter', String, queue_size=10) - -In ROS 2: - -.. code-block:: python - - pub = node.create_publisher(String, 'chatter', rclpy.qos.QoSProfile()) - # or - pub = node.create_publisher(String, 'chatter', 10) - -Creating a Subscriber -^^^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - sub = rospy.Subscriber('chatter', String, callback) - # or - sub = rospy.Subscriber('chatter', String, callback, queue_size=10) - -In ROS 2: - -.. code-block:: python - - sub = node.create_subscription(String, 'chatter', callback, rclpy.qos.QoSProfile()) - # or - sub = node.create_subscription(String, 'chatter', callback, 10) - -Creating a Service -^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - srv = rospy.Service('add_two_ints', AddTwoInts, add_two_ints_callback) - -In ROS 2: - -.. code-block:: python - - srv = node.create_service(AddTwoInts, 'add_two_ints', add_two_ints_callback) - -Creating a Service Client -^^^^^^^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - rospy.wait_for_service('add_two_ints') - add_two_ints = rospy.ServiceProxy('add_two_ints', AddTwoInts) - resp = add_two_ints(req) - -In ROS 2: - -.. code-block:: python - - add_two_ints = node.create_client(AddTwoInts, 'add_two_ints') - while not add_two_ints.wait_for_service(timeout_sec=1.0): - node.get_logger().info('service not available, waiting again...') - resp = add_two_ints.call_async(req) - rclpy.spin_until_future_complete(node, resp) - -.. warning:: - - Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. - For more details see the :doc:`sync deadlock article <../Sync-Vs-Async>`. +.. redirect-from:: + + Migration-Guide-Python + The-ROS2-Project/Contributing/Migration-Guide-Python + How-To-Guides/Migrating-from-ROS1/Migrating-Python-Packages + +Migrating Python Packages Reference +=================================== + +This page is a reference on how to migrate Python packages from ROS 1 to ROS 2. +If this is your first time migrating a Python package, then follow :doc:`this guide to migrate an example Python package ` first. + +.. contents:: Table of Contents + :depth: 2 + :local: + +Build tool +---------- + +Instead of using ``catkin_make``, ``catkin_make_isolated`` or ``catkin build`` ROS 2 uses the command line tool `colcon `__ to build and install a set of packages. +See the :doc:`beginner tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>` to get started with ``colcon``. + +Build system +------------ + +For pure Python packages, ROS 2 uses the standard ``setup.py`` installation mechanism familiar to Python developers. + +Update the files to use *setup.py* +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If the ROS 1 package uses CMake only to invoke the ``setup.py`` file and does not contain anything beside Python code (e.g. no messages, services, etc.) it should be converted into a pure Python package in ROS 2: + +* + Update or add the build type in the ``package.xml`` file: + + .. code-block:: xml + + + ament_python + + +* + Remove the ``CMakeLists.txt`` file + +* + Update the ``setup.py`` file to be a standard Python setup script + +ROS 2 supports Python 3 only. +While each package can choose to also support Python 2 it must invoke executables with Python 3 if it uses any API provided by other ROS 2 packages. + +Update source code +------------------ + +Node Initialization +^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + rospy.init_node('asdf') + + rospy.loginfo('Created node') + +In ROS 2: + +.. code-block:: python + + with rclpy.init(args=sys.argv): + node = rclpy.create_node('asdf') + + node.get_logger().info('Created node') + +ROS Parameters +^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + port = rospy.get_param('port', '/dev/ttyUSB0') + assert isinstance(port, str), 'port parameter must be a str' + + baudrate = rospy.get_param('baudrate', 115200) + assert isinstance(baudrate, int), 'baudrate parameter must be an integer' + + rospy.logwarn('port: ' + port) + +In ROS 2: + +.. code-block:: python + + port = node.declare_parameter('port', '/dev/ttyUSB0').value + assert isinstance(port, str), 'port parameter must be a str' + + baudrate = node.declare_parameter('baudrate', 115200).value + assert isinstance(baudrate, int), 'baudrate parameter must be an integer' + + node.get_logger().warn('port: ' + port) + +Creating a Publisher +^^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + pub = rospy.Publisher('chatter', String) + # or + pub = rospy.Publisher('chatter', String, queue_size=10) + +In ROS 2: + +.. code-block:: python + + pub = node.create_publisher(String, 'chatter', rclpy.qos.QoSProfile()) + # or + pub = node.create_publisher(String, 'chatter', 10) + +Creating a Subscriber +^^^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + sub = rospy.Subscriber('chatter', String, callback) + # or + sub = rospy.Subscriber('chatter', String, callback, queue_size=10) + +In ROS 2: + +.. code-block:: python + + sub = node.create_subscription(String, 'chatter', callback, rclpy.qos.QoSProfile()) + # or + sub = node.create_subscription(String, 'chatter', callback, 10) + +Creating a Service +^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + srv = rospy.Service('add_two_ints', AddTwoInts, add_two_ints_callback) + +In ROS 2: + +.. code-block:: python + + srv = node.create_service(AddTwoInts, 'add_two_ints', add_two_ints_callback) + +Creating a Service Client +^^^^^^^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + rospy.wait_for_service('add_two_ints') + add_two_ints = rospy.ServiceProxy('add_two_ints', AddTwoInts) + resp = add_two_ints(req) + +In ROS 2: + +.. code-block:: python + + add_two_ints = node.create_client(AddTwoInts, 'add_two_ints') + while not add_two_ints.wait_for_service(timeout_sec=1.0): + node.get_logger().info('service not available, waiting again...') + resp = add_two_ints.call_async(req) + rclpy.spin_until_future_complete(node, resp) + +.. warning:: + + Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. + For more details see the :doc:`sync deadlock article <../../ROS-Framework/services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst index a0b4d1686f7..3591d84d007 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst @@ -1,68 +1,72 @@ -Migrating Scripts -================= - -ROS CLI -------- - -In ROS 1 there were individual commands for performing various actions, like ``rosrun``, ``rosparam``, etc. - -In ROS 2, there is a single top-level commands called ``ros2``, and all of the actions are sub-commands of that, like ``ros2 run``, ``ros2 param``, etc. - -ROS CLI arguments ------------------ - -In ROS 1, arguments to nodes were provided directly on the command-line. - -ROS 2 arguments should be scoped with ``--ros-args`` and a trailing ``--`` (the trailing double dash may be elided if no arguments follow it). - -Remapping names is similar to ROS 1, taking on the form ``from:=to``, except that it must be preceded by a ``--remap`` (or ``-r``) flag. -For example: - -.. code-block:: console - - $ ros2 run some_package some_ros_executable --ros-args -r foo:=bar - -We use a similar syntax for parameters, using the ``--param`` (or ``-p``) flag: - -.. code-block:: console - - $ ros2 run some_package some_ros_executable --ros-args -p my_param:=value - -Note, this is different than using a leading underscore in ROS 1. - -To change a node name use ``__node`` (the ROS 1 equivalent is ``__name``): - -.. code-block:: console - - $ ros2 run some_package some_ros_executable --ros-args -r __node:=new_node_name - -Note the use of the ``-r`` flag. -The same remap flag is needed for changing the namespace ``__ns``: - -.. code-block:: console - - $ ros2 run some_package some_ros_executable --ros-args -r __ns:=/new/namespace - -There is no equivalent in ROS 2 for the following ROS 1 keys: - -- ``__log`` (but ``--log-config-file`` can be used to provide a logger configuration file) -- ``__ip`` -- ``__hostname`` -- ``__master`` - -For more information, see the `design document `_. - -Quick reference -~~~~~~~~~~~~~~~ - -+------------+-------------+----------------+ -| Feature | ROS 1 | ROS 2 | -+============+=============+================+ -| remapping | foo:=bar | -r foo:=bar | -+------------+-------------+----------------+ -| parameters | _foo:=bar | -p foo:=bar | -+------------+-------------+----------------+ -| node name | __name:=foo | -r __node:=foo | -+------------+-------------+----------------+ -| namespace | __ns:=foo | -r __ns:=foo | -+------------+-------------+----------------+ +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Scripts + +Migrating Scripts +================= + +ROS CLI +------- + +In ROS 1 there were individual commands for performing various actions, like ``rosrun``, ``rosparam``, etc. + +In ROS 2, there is a single top-level commands called ``ros2``, and all of the actions are sub-commands of that, like ``ros2 run``, ``ros2 param``, etc. + +ROS CLI arguments +----------------- + +In ROS 1, arguments to nodes were provided directly on the command-line. + +ROS 2 arguments should be scoped with ``--ros-args`` and a trailing ``--`` (the trailing double dash may be elided if no arguments follow it). + +Remapping names is similar to ROS 1, taking on the form ``from:=to``, except that it must be preceded by a ``--remap`` (or ``-r``) flag. +For example: + +.. code-block:: console + + $ ros2 run some_package some_ros_executable --ros-args -r foo:=bar + +We use a similar syntax for parameters, using the ``--param`` (or ``-p``) flag: + +.. code-block:: console + + $ ros2 run some_package some_ros_executable --ros-args -p my_param:=value + +Note, this is different than using a leading underscore in ROS 1. + +To change a node name use ``__node`` (the ROS 1 equivalent is ``__name``): + +.. code-block:: console + + $ ros2 run some_package some_ros_executable --ros-args -r __node:=new_node_name + +Note the use of the ``-r`` flag. +The same remap flag is needed for changing the namespace ``__ns``: + +.. code-block:: console + + $ ros2 run some_package some_ros_executable --ros-args -r __ns:=/new/namespace + +There is no equivalent in ROS 2 for the following ROS 1 keys: + +- ``__log`` (but ``--log-config-file`` can be used to provide a logger configuration file) +- ``__ip`` +- ``__hostname`` +- ``__master`` + +For more information, see the `design document `_. + +Quick reference +~~~~~~~~~~~~~~~ + ++------------+-------------+----------------+ +| Feature | ROS 1 | ROS 2 | ++============+=============+================+ +| remapping | foo:=bar | -r foo:=bar | ++------------+-------------+----------------+ +| parameters | _foo:=bar | -p foo:=bar | ++------------+-------------+----------------+ +| node name | __name:=foo | -r __node:=foo | ++------------+-------------+----------------+ +| namespace | __ns:=foo | -r __ns:=foo | ++------------+-------------+----------------+ \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst b/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst index 575ca1b04d4..1d0e950c9cf 100644 --- a/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst +++ b/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst @@ -1,67 +1,71 @@ -Using Custom Rosdistro Version -============================== - - -.. contents:: Contents - :depth: 2 - :local: - - -Overview --------- - -`rosdistro `_ contains the central index of ROS packages for all distributions and ``rosdep`` keys for packaged binary dependencies for installation. -When you invoke ``rosdep install ...``, it is checking a local cached index from rosdistro (populated during ``rosdep update``) to correlate keys in a ``package.xml`` to the ROS package, python module, or binary to install. -Thus, this index is an important element of the ROS ecosystem. - -However, there are occasions where a user would like the assert further control over this index to add in their own proprietary keys or use a previous state of rosdistro. -This guide walks through how to set a version of rosdistro to use on your system. - -The motivating example that this guide will use is a desire to use a previous version of Rolling due to a breakage on your development computer or Continuous Integration. -It is possible that during transition periods from one operating system to another, Rolling on the older operating system may become unusable due to support shifting to a new OS (i.e. moving from Ubuntu 22.04 to 24.04). -Thus, we wish to set a prior version of rosdistro that aligns with a working Rolling distribution on a given operating system to keep our systems functioning before upgrading to the new operating system. - -Important Preliminaries ------------------------ - -Rosdep populates its cache from the locations set in its ``/etc/ros/rosdep/sources.list.d/20-default.list`` by default. -When setting up rosdep with ``rosdep init``, it populates ``20-default.list`` with the main rosdistro URLs (`from this file `_). -The cache generated by ``rosdep update`` is located in ``~/.ros/rosdep/sources.cache`` and should not be modified by hand. - -When no ``ROSDISTRO_INDEX_URL`` environment variable value is set during a rosdep update, it uses the main public rosdistro index. -However, when this value is set, you may use a custom rosdisto index which could be a snapshot from the public index or a completely separate index populated with your proprietary packages. - -If you'd like to learn more about this, checkout the `documentation in ros_buildfarm package `_. - -How to Use a Custom Rosdistro Version -------------------------------------- - -To use a custom version in your CI, docker build, local environment, robot, or other application, we need to first identify the rosdistro version of interest. - -For our motivating example, we wish to use the last index state before the first sync of ``rolling`` on the new operating system. -In this case, that last sync for our operating system was performed on February 28, 2024. -Conveniently, the syncs are tagged so we can obtain that information on the ``rolling/2024-02-28`` tagged branch. - -Thus, we need to update the ``20-default.list`` with our tagged branch values rather than using the main repository's current state. -This can be accomplished using the script as follows. -If running on a local host, you may need to include ``sudo``. -This will update list to use our tagged branch rather than the master branch. - -.. code-block:: console - - $ sed -i "s|ros\/rosdistro\/master|ros\/rosdistro\/rolling\/2024-02-28|" /etc/ros/rosdep/sources.list.d/20-default.list - -After, we must now update the environment variable ``ROSDISTRO_INDEX_URL`` to point to our new rosdistro index. - -.. code-block:: console - - $ export ROSDISTRO_INDEX_URL=https://raw.githubusercontent.com/ros/rosdistro/rolling/2024-02-28/index-v4.yaml - -If you plan to use this on a local host for a long time, it may be wise to include this in your ``~/.bashrc`` so that all new terminals do this automatically. -The ``v4`` in our index points to a new version of the index format. -A previous index also exists without the ``v4`` which is still present for historical reasons and legacy systems, but you should not use it. - -Afterward, you can ``rosdep update``, which will now use the changes to update the index in accordance to the Rolling distribution's state on February 28, 2024 before the breakages began. -You can see this in action in `Nav2's CircleCI `_ and `ros_gz's GitHub Actions `_ in order to bypass a temporary Rolling outage in their CI systems. - -.. Note:: If you are using a custom rosdistro version, you can substitute the final URLs in the default list and index URL with your fork or index location. +.. redirect-from:: + + How-To-Guides/Using-Custom-Rosdistro + +Using Custom Rosdistro Version +============================== + + +.. contents:: Contents + :depth: 2 + :local: + + +Overview +-------- + +`rosdistro `_ contains the central index of ROS packages for all distributions and ``rosdep`` keys for packaged binary dependencies for installation. +When you invoke ``rosdep install ...``, it is checking a local cached index from rosdistro (populated during ``rosdep update``) to correlate keys in a ``package.xml`` to the ROS package, python module, or binary to install. +Thus, this index is an important element of the ROS ecosystem. + +However, there are occasions where a user would like the assert further control over this index to add in their own proprietary keys or use a previous state of rosdistro. +This guide walks through how to set a version of rosdistro to use on your system. + +The motivating example that this guide will use is a desire to use a previous version of Rolling due to a breakage on your development computer or Continuous Integration. +It is possible that during transition periods from one operating system to another, Rolling on the older operating system may become unusable due to support shifting to a new OS (i.e. moving from Ubuntu 22.04 to 24.04). +Thus, we wish to set a prior version of rosdistro that aligns with a working Rolling distribution on a given operating system to keep our systems functioning before upgrading to the new operating system. + +Important Preliminaries +----------------------- + +Rosdep populates its cache from the locations set in its ``/etc/ros/rosdep/sources.list.d/20-default.list`` by default. +When setting up rosdep with ``rosdep init``, it populates ``20-default.list`` with the main rosdistro URLs (`from this file `_). +The cache generated by ``rosdep update`` is located in ``~/.ros/rosdep/sources.cache`` and should not be modified by hand. + +When no ``ROSDISTRO_INDEX_URL`` environment variable value is set during a rosdep update, it uses the main public rosdistro index. +However, when this value is set, you may use a custom rosdisto index which could be a snapshot from the public index or a completely separate index populated with your proprietary packages. + +If you'd like to learn more about this, checkout the `documentation in ros_buildfarm package `_. + +How to Use a Custom Rosdistro Version +------------------------------------- + +To use a custom version in your CI, docker build, local environment, robot, or other application, we need to first identify the rosdistro version of interest. + +For our motivating example, we wish to use the last index state before the first sync of ``rolling`` on the new operating system. +In this case, that last sync for our operating system was performed on February 28, 2024. +Conveniently, the syncs are tagged so we can obtain that information on the ``rolling/2024-02-28`` tagged branch. + +Thus, we need to update the ``20-default.list`` with our tagged branch values rather than using the main repository's current state. +This can be accomplished using the script as follows. +If running on a local host, you may need to include ``sudo``. +This will update list to use our tagged branch rather than the master branch. + +.. code-block:: console + + $ sed -i "s|ros\/rosdistro\/master|ros\/rosdistro\/rolling\/2024-02-28|" /etc/ros/rosdep/sources.list.d/20-default.list + +After, we must now update the environment variable ``ROSDISTRO_INDEX_URL`` to point to our new rosdistro index. + +.. code-block:: console + + $ export ROSDISTRO_INDEX_URL=https://raw.githubusercontent.com/ros/rosdistro/rolling/2024-02-28/index-v4.yaml + +If you plan to use this on a local host for a long time, it may be wise to include this in your ``~/.bashrc`` so that all new terminals do this automatically. +The ``v4`` in our index points to a new version of the index format. +A previous index also exists without the ``v4`` which is still present for historical reasons and legacy systems, but you should not use it. + +Afterward, you can ``rosdep update``, which will now use the changes to update the index in accordance to the Rolling distribution's state on February 28, 2024 before the breakages began. +You can see this in action in `Nav2's CircleCI `_ and `ros_gz's GitHub Actions `_ in order to bypass a temporary Rolling outage in their CI systems. + +.. Note:: If you are using a custom rosdistro version, you can substitute the final URLs in the default list and index URL with your fork or index location. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst b/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst index 86a9cba5458..2acc70cf4ce 100644 --- a/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst +++ b/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst @@ -1,107 +1,111 @@ -Using ``ros1_bridge`` with upstream ROS on Ubuntu 22.04 -======================================================= - -.. contents:: Table of Contents - :depth: 1 - :local: - -The release of ROS 2 Humble (and Rolling) on Ubuntu 22.04 Jammy Jellyfish marks the first ROS 2 release on a platform with no official ROS 1 release. -While ROS 1 Noetic will continue to be supported through the duration of its `long term support window `__, it will only target Ubuntu 20.04. -Alternatively, there are `upstream variants of ROS 1 packages `__ in Debian and Ubuntu that are not maintained as an official distribution by the ROS maintainers. - -This guide outlines the current mechanism for bridging ROS 2 releases with these upstream packages on Ubuntu 22.04 Jammy Jellyfish. -This provides a migration path for users who still depend on ROS 1, but desire moving to newer ROS 2 and Ubuntu releases. - -ROS 2 via deb packages ----------------------- - -Installing :doc:`ROS 2 from deb packages <../Installation/Ubuntu-Install-Debs>` currently does not work for ROS 2 on Ubuntu Jammy. -The version of ``catkin-pkg-modules`` available in the Ubuntu repository conflicts with that in the ROS 2 package repository. - -If the ROS 2 apt repository is in the available apt repositories (``/etc/apt/sources.list.d``), no ROS 1 packages will be installable. -The error will be: - -.. code-block:: console - - $ apt install ros-core-dev - Reading package lists... Done - Building dependency tree... Done - Reading state information... Done - Some packages could not be installed. This may mean that you have - requested an impossible situation or if you are using the unstable - distribution that some required packages have not yet been created - or been moved out of Incoming. - The following information may help to resolve the situation: - - The following packages have unmet dependencies: - ros-core-dev : Depends: catkin but it is not installable - E: Unable to correct problems, you have held broken packages. - -To correct this, remove packages.ros.org from your ``sources.list``. -If you were following the ROS 2 installation guide, simply remove ``/etc/apt/sources.list.d/ros2.list`` - -For now, to support ``ros1_bridge``, follow the instructions below for building ROS 2 from source. - -ROS 2 from source ------------------ - -Installing :doc:`ROS 2 from Source <../Installation/Alternatives/Ubuntu-Development-Setup>` is the only configuration that works for ROS 2 on Ubuntu Jammy. - -Below is a summary of the necessary instructions from the source build instructions. -The substantial deviation is that we skip using the ROS 2 apt repositories because of conflicting packages. - -Install development tools and ROS tools -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Since we aren't using the ROS 2 apt repositories, ``colcon`` must be installed via ``pip``. - -.. code-block:: console - - $ sudo apt update && sudo apt install -y \ - build-essential \ - cmake \ - git \ - python3-flake8 \ - python3-flake8-blind-except \ - python3-flake8-builtins \ - python3-flake8-class-newline \ - python3-flake8-comprehensions \ - python3-flake8-deprecated \ - python3-flake8-docstrings \ - python3-flake8-import-order \ - python3-flake8-quotes \ - python3-pip \ - python3-pytest \ - python3-pytest-cov \ - python3-pytest-repeat \ - python3-pytest-rerunfailures \ - python3-rosdep \ - python3-setuptools \ - wget - - # Install colcon from PyPI, rather than apt packages - python3 -m pip install -U colcon-common-extensions vcstool - -From here, continue with the :doc:`source install guide <../Installation/Alternatives/Ubuntu-Development-Setup>` to build ROS 2. - -Install ROS 1 from Ubuntu packages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ sudo apt update && sudo apt install -y ros-core-dev - - -Build ``ros1_bridge`` -^^^^^^^^^^^^^^^^^^^^^ - -.. code-block:: console - - $ mkdir -p ~/ros1_bridge/src # Create a workspace for the ros1_bridge - $ cd ~/ros1_bridge/src - $ git clone https://github.com/ros2/ros1_bridge - $ cd ~/ros1_bridge - $. ~/ros2_humble/install/local_setup.bash # Source the ROS 2 workspace - $ colcon build # Build - -After building all of ``ros1_bridge``, the remainder of the `ros1_bridge examples `__ should work with your new installation +.. redirect-from:: + + How-To-Guides/Using-ros1_bridge-Jammy-upstream + +Using ``ros1_bridge`` with upstream ROS on Ubuntu 22.04 +======================================================= + +.. contents:: Table of Contents + :depth: 1 + :local: + +The release of ROS 2 Humble (and Rolling) on Ubuntu 22.04 Jammy Jellyfish marks the first ROS 2 release on a platform with no official ROS 1 release. +While ROS 1 Noetic will continue to be supported through the duration of its `long term support window `__, it will only target Ubuntu 20.04. +Alternatively, there are `upstream variants of ROS 1 packages `__ in Debian and Ubuntu that are not maintained as an official distribution by the ROS maintainers. + +This guide outlines the current mechanism for bridging ROS 2 releases with these upstream packages on Ubuntu 22.04 Jammy Jellyfish. +This provides a migration path for users who still depend on ROS 1, but desire moving to newer ROS 2 and Ubuntu releases. + +ROS 2 via deb packages +---------------------- + +Installing :doc:`ROS 2 from deb packages <../Get-Started/Installation/Ubuntu-Install-Debs>` currently does not work for ROS 2 on Ubuntu Jammy. +The version of ``catkin-pkg-modules`` available in the Ubuntu repository conflicts with that in the ROS 2 package repository. + +If the ROS 2 apt repository is in the available apt repositories (``/etc/apt/sources.list.d``), no ROS 1 packages will be installable. +The error will be: + +.. code-block:: console + + $ apt install ros-core-dev + Reading package lists... Done + Building dependency tree... Done + Reading state information... Done + Some packages could not be installed. This may mean that you have + requested an impossible situation or if you are using the unstable + distribution that some required packages have not yet been created + or been moved out of Incoming. + The following information may help to resolve the situation: + + The following packages have unmet dependencies: + ros-core-dev : Depends: catkin but it is not installable + E: Unable to correct problems, you have held broken packages. + +To correct this, remove packages.ros.org from your ``sources.list``. +If you were following the ROS 2 installation guide, simply remove ``/etc/apt/sources.list.d/ros2.list`` + +For now, to support ``ros1_bridge``, follow the instructions below for building ROS 2 from source. + +ROS 2 from source +----------------- + +Installing :doc:`ROS 2 from Source <../Get-Started/Installation/Alternatives/Ubuntu-Development-Setup>` is the only configuration that works for ROS 2 on Ubuntu Jammy. + +Below is a summary of the necessary instructions from the source build instructions. +The substantial deviation is that we skip using the ROS 2 apt repositories because of conflicting packages. + +Install development tools and ROS tools +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Since we aren't using the ROS 2 apt repositories, ``colcon`` must be installed via ``pip``. + +.. code-block:: console + + $ sudo apt update && sudo apt install -y \ + build-essential \ + cmake \ + git \ + python3-flake8 \ + python3-flake8-blind-except \ + python3-flake8-builtins \ + python3-flake8-class-newline \ + python3-flake8-comprehensions \ + python3-flake8-deprecated \ + python3-flake8-docstrings \ + python3-flake8-import-order \ + python3-flake8-quotes \ + python3-pip \ + python3-pytest \ + python3-pytest-cov \ + python3-pytest-repeat \ + python3-pytest-rerunfailures \ + python3-rosdep \ + python3-setuptools \ + wget + + # Install colcon from PyPI, rather than apt packages + python3 -m pip install -U colcon-common-extensions vcstool + +From here, continue with the :doc:`source install guide <../Get-Started/Installation/Alternatives/Ubuntu-Development-Setup>` to build ROS 2. + +Install ROS 1 from Ubuntu packages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ sudo apt update && sudo apt install -y ros-core-dev + + +Build ``ros1_bridge`` +^^^^^^^^^^^^^^^^^^^^^ + +.. code-block:: console + + $ mkdir -p ~/ros1_bridge/src # Create a workspace for the ros1_bridge + $ cd ~/ros1_bridge/src + $ git clone https://github.com/ros2/ros1_bridge + $ cd ~/ros1_bridge + $. ~/ros2_humble/install/local_setup.bash # Source the ROS 2 workspace + $ colcon build # Build + +After building all of ``ros1_bridge``, the remainder of the `ros1_bridge examples `__ should work with your new installation \ No newline at end of file diff --git a/source/ROS-Framework/About-Actions.rst b/source/ROS-Framework/About-Actions.rst index adc10507f86..ae9546f759a 100644 --- a/source/ROS-Framework/About-Actions.rst +++ b/source/ROS-Framework/About-Actions.rst @@ -1,63 +1,66 @@ -Actions -======= - -.. toctree:: - :maxdepth: 1 - :hidden: - - actions/Working-with-actions - -.. contents:: Table of Contents - :local: - -In ROS 2, an action refers to a long-running remote procedure call with feedback and the ability to cancel or preempt the goal. -For instance, the high-level state machine running a robot may call an action to tell the navigation subsystem to travel to a waypoint, which may take several seconds (or minutes) to do. -Along the way, the navigation subsystem can provide feedback on how far along it is, and the high-level state machine has the option to cancel or preempt the travel to that waypoint. - -This structure is reflected in how an action message definition looks: - -.. code:: - - int32 request - --- - int32 response - --- - int32 feedback - -In ROS 2, actions are expected to be long running procedures, as there is overhead in setting up and monitoring the connection. -If you need a short running remote procedure call, consider using a :doc:`service ` instead. - -Actions are identified by an action name, which looks much like a topic name (but is in a different namespace). - -An action consists of two parts: the action server and the action client. - -Action server -------------- - -The action server is the entity that will accept the remote procedure request and perform some procedure on it. -It is also responsible for sending out feedback as the action progresses and should react to cancellation/preemption requests. -For instance, consider an action to calculate the Fibonacci sequence with the following interface: - -.. code:: - - int32 order - --- - int32[] sequence - --- - int32[] sequence - -The action server is the entity that receives this message, starts calculating the sequence up to ``order`` (providing feedback along the way), and finally returns a full result in ``sequence``. - -.. note:: - - There should only ever be one action server per action name. - It is undefined which action server will receive client requests in the case of multiple action servers on the same action name. - -Action client -------------- - -An action client is an entity that will request a remote action server to perform a procedure on its behalf. -Following the example above, the action client is the entity that creates the initial message containing the ``order``, and waits for the action server to compute the sequence and return it (with feedback along the way). - -Unlike the action server, there can be arbitrary numbers of action clients using the same action name. - +.. redirect-from:: + + Concepts/Basic/About-Actions + +Actions +======= + +.. toctree:: + :maxdepth: 1 + :hidden: + + actions/Working-with-actions + +.. contents:: Table of Contents + :local: + +In ROS 2, an action refers to a long-running remote procedure call with feedback and the ability to cancel or preempt the goal. +For instance, the high-level state machine running a robot may call an action to tell the navigation subsystem to travel to a waypoint, which may take several seconds (or minutes) to do. +Along the way, the navigation subsystem can provide feedback on how far along it is, and the high-level state machine has the option to cancel or preempt the travel to that waypoint. + +This structure is reflected in how an action message definition looks: + +.. code:: + + int32 request + --- + int32 response + --- + int32 feedback + +In ROS 2, actions are expected to be long running procedures, as there is overhead in setting up and monitoring the connection. +If you need a short running remote procedure call, consider using a :doc:`service ` instead. + +Actions are identified by an action name, which looks much like a topic name (but is in a different namespace). + +An action consists of two parts: the action server and the action client. + +Action server +------------- + +The action server is the entity that will accept the remote procedure request and perform some procedure on it. +It is also responsible for sending out feedback as the action progresses and should react to cancellation/preemption requests. +For instance, consider an action to calculate the Fibonacci sequence with the following interface: + +.. code:: + + int32 order + --- + int32[] sequence + --- + int32[] sequence + +The action server is the entity that receives this message, starts calculating the sequence up to ``order`` (providing feedback along the way), and finally returns a full result in ``sequence``. + +.. note:: + + There should only ever be one action server per action name. + It is undefined which action server will receive client requests in the case of multiple action servers on the same action name. + +Action client +------------- + +An action client is an entity that will request a remote action server to perform a procedure on its behalf. +Following the example above, the action client is the entity that creates the initial message containing the ``order``, and waits for the action server to compute the sequence and return it (with feedback along the way). + +Unlike the action server, there can be arbitrary numbers of action clients using the same action name. diff --git a/source/ROS-Framework/About-Client-Libraries.rst b/source/ROS-Framework/About-Client-Libraries.rst index 45cb39ff14d..bddbd764dee 100644 --- a/source/ROS-Framework/About-Client-Libraries.rst +++ b/source/ROS-Framework/About-Client-Libraries.rst @@ -1,135 +1,136 @@ -.. redirect-from:: - - Concepts/About-Client-Interfaces - Concepts/About-ROS-2-Client-Libraries - -.. include:: ../../../global_substitutions.txt - -Client libraries -================ - -.. toctree:: - :maxdepth: 1 - :hidden: - - client-libraries/About-Different-Middleware-Vendors - client-libraries/About-Executors/About-Executors - client-libraries/About-Client-Interfaces - client-libraries/About-Middleware-Implementations - client-libraries/Working-with-Client-Libraries - - -.. contents:: Table of Contents - :local: - -Overview --------- - -Client libraries are the APIs that allow users to implement their ROS 2 code. -Using client libraries, users gain access to ROS 2 concepts such as nodes, topics, services, etc. -Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their application. -For example, you might prefer to write visualization tools in Python because it makes prototyping iterations faster, while for parts of your system that are concerned with efficiency, the nodes might be better implemented in C++. - -Nodes written using different client libraries are able to share messages with each other because all client libraries implement code generators that provide users with the capability to interact with ROS 2 interface files in the respective language. - -In addition to the language-specific communication tools, client libraries expose to users the core functionality that makes ROS "ROS". -For example, here is a list of functionality that can typically be accessed through a client library: - -* Names and namespaces -* Time (real or simulated) -* Parameters -* Console logging -* Threading model -* Intra-process communication - -Supported client libraries --------------------------- - -The C++ client library (``rclcpp``) and the Python client library (``rclpy``) are both client libraries which utilize common functionality in ``rcl``. - -The ``rclcpp`` package -~~~~~~~~~~~~~~~~~~~~~~ - -The ROS Client Library for C++ (``rclcpp``) is the user facing, C++ idiomatic interface which provides all of the ROS client functionality like creating nodes, publishers, and subscriptions. -``rclcpp`` builds on top of ``rcl`` and the ``rosidl`` |API|, and it is designed to be used with the C++ messages generated by ``rosidl_generator_cpp``. - -``rclcpp`` makes use of all the features of C++ and C++20 to make the interface as easy to use as possible, but since it reuses the implementation in ``rcl`` it is able maintain a consistent behavior with the other client libraries that use the ``rcl`` |API|. - -The ``rclcpp`` repository is located on GitHub at `ros2/rclcpp `_ and contains the |package| ``rclcpp``. -The generated |API| documentation is at {package_link(rclcpp)}. - -The ``rclpy`` package -~~~~~~~~~~~~~~~~~~~~~ - -The ROS Client Library for Python (``rclpy``) is the Python counterpart to the C++ client library. -Like the C++ client library, ``rclpy`` also builds on top of the ``rcl`` C API for its implementation. -The interface provides an idiomatic Python experience that uses native Python types and patterns like lists and context objects. -By using the ``rcl`` |API| in the implementation, it stays consistent with the other client libraries in terms of feature parity and behavior. -In addition to providing Python idiomatic bindings around the ``rcl`` |API| and Python classes for each message, the Python client library takes care of the execution model, using ``threading.Thread`` or similar to run the functions in the ``rcl`` |API|. - -Like C++ it generates custom Python code for each ROS message that the user interacts with, but unlike C++ it eventually converts the native Python message object into the C version of the message. -All operations happen on the Python version of the messages until they need to be passed into the ``rcl`` layer, at which point they are converted into the plain C version of the message so it can be passed into the ``rcl`` C |API|. -This is avoided if possible when communicating between publishers and subscriptions in the same process to cut down on the conversion into and out of Python. - -The ``rclpy`` repository is located on GitHub at `ros2/rclpy `_ and contains the |package| ``rclpy``. -The generated |API| documentation is at {package_link(rclpy)}. - -Community-maintained -~~~~~~~~~~~~~~~~~~~~ - -While the C++ and Python client libraries are maintained by the core ROS 2 team, members of the ROS 2 community maintain additional client libraries: - -* `Ada `__ This is a set of packages (binding to ``rcl``, message generator, binding to ``tf2``, examples and tutorials) that allows the writing of Ada applications for ROS 2. -* `C `__ ``rclc`` does not put a layer on top of rcl but complements rcl to make rcl+rclc a feature-complete client library in C. See `micro.ros.org `__ for tutorials. -* `JVM and Android `__ Java and Android bindings for ROS 2. -* `.NET Core, UWP and C# `__ This is a collection of projects (bindings, code generator, examples and more) for writing ROS 2 applications for .NET Core and .NET Standard. -* `Node.js `__ rclnodejs is a Node.js client for ROS 2. - It provides a simple and easy JavaScript API for ROS 2 programming. -* `Rust `__ This is a set of projects (the rclrs client library, code generator, examples and more) that enables developers to write ROS 2 applications in Rust. -* `Flutter and Dart `__ Flutter and Dart bindings for ROS 2. - -Older, unmaintained client libraries are: - -* `C# `__ -* `Objective C and iOS `__ -* `Zig `__ - - -Common functionality: ``rcl`` ------------------------------ - -Most of the functionality found in a client library is not specific to the programming language of the client library. -For example, the behavior of parameters and the logic of namespaces should ideally be the same across all programming languages. -Because of this, rather than implementing the common functionality from scratch, client libraries make use of a common core ROS Client Library (RCL) interface that implements logic and behavior of ROS concepts that is not language-specific. -As a result, client libraries only need to wrap the common functionality in the RCL with foreign function interfaces. -This keeps client libraries thinner and easier to develop. -For this reason the common RCL functionality is exposed with C interfaces as the C language is typically the easiest language for client libraries to wrap. - -In addition to making the client libraries light-weight, an advantage of having the common core is that the behavior between languages is more consistent. -If any changes are made to the logic/behavior of the functionality in the core RCL -- namespaces, for example -- all client libraries that use the RCL will have these changes reflected. -Furthermore, having the common core means that maintaining multiple client libraries becomes less work when it comes to bug fixes. - -The API documentation for ``rcl`` can be found `here <{package_link(rcl)}>`__. - -Language-specific functionality -------------------------------- - -Client library concepts that require language-specific features/properties are not implemented in the RCL but instead are implemented in each client library. -For example, threading models used by "spin" functions will have implementations that are specific to the language of the client library. - -Demo ----- - -For a walkthrough of the message exchange between a publisher using ``rclpy`` and a subscription using ``rclcpp``\ , we encourage you to watch `this ROSCon talk `__ starting at 17:25 (`see the slides here `__). - -Comparison to ROS 1 -------------------- - -In ROS 1, all client libraries are developed "from the ground up". -This allows for the ROS 1 Python client library to be implemented purely in Python, for example, which brings benefits of such as not needing to compile code. -However, naming conventions and behaviors are not always consistent between client libraries, bug fixes have to be done in multiple places, and there is a lot of functionality that has only ever been implemented in one client library (e.g. UDPROS). - -Summary -------- - -By utilizing the common core ROS client library, client libraries written in a variety of programming languages are easier to write and have more consistent behavior. +.. redirect-from:: + + Concepts/About-Client-Interfaces + Concepts/About-ROS-2-Client-Libraries + Concepts/Basic/About-Client-Libraries + +.. include:: ../../../global_substitutions.txt + +Client libraries +================ + +.. toctree:: + :maxdepth: 1 + :hidden: + + client-libraries/About-Different-Middleware-Vendors + client-libraries/About-Executors/About-Executors + client-libraries/About-Client-Interfaces + client-libraries/About-Middleware-Implementations + client-libraries/Working-with-Client-Libraries + + +.. contents:: Table of Contents + :local: + +Overview +-------- + +Client libraries are the APIs that allow users to implement their ROS 2 code. +Using client libraries, users gain access to ROS 2 concepts such as nodes, topics, services, etc. +Client libraries come in a variety of programming languages so that users may write ROS 2 code in the language that is best-suited for their application. +For example, you might prefer to write visualization tools in Python because it makes prototyping iterations faster, while for parts of your system that are concerned with efficiency, the nodes might be better implemented in C++. + +Nodes written using different client libraries are able to share messages with each other because all client libraries implement code generators that provide users with the capability to interact with ROS 2 interface files in the respective language. + +In addition to the language-specific communication tools, client libraries expose to users the core functionality that makes ROS "ROS". +For example, here is a list of functionality that can typically be accessed through a client library: + +* Names and namespaces +* Time (real or simulated) +* Parameters +* Console logging +* Threading model +* Intra-process communication + +Supported client libraries +-------------------------- + +The C++ client library (``rclcpp``) and the Python client library (``rclpy``) are both client libraries which utilize common functionality in ``rcl``. + +The ``rclcpp`` package +~~~~~~~~~~~~~~~~~~~~~~ + +The ROS Client Library for C++ (``rclcpp``) is the user facing, C++ idiomatic interface which provides all of the ROS client functionality like creating nodes, publishers, and subscriptions. +``rclcpp`` builds on top of ``rcl`` and the ``rosidl`` |API|, and it is designed to be used with the C++ messages generated by ``rosidl_generator_cpp``. + +``rclcpp`` makes use of all the features of C++ and C++20 to make the interface as easy to use as possible, but since it reuses the implementation in ``rcl`` it is able maintain a consistent behavior with the other client libraries that use the ``rcl`` |API|. + +The ``rclcpp`` repository is located on GitHub at `ros2/rclcpp `_ and contains the |package| ``rclcpp``. +The generated |API| documentation is at {package_link(rclcpp)}. + +The ``rclpy`` package +~~~~~~~~~~~~~~~~~~~~~ + +The ROS Client Library for Python (``rclpy``) is the Python counterpart to the C++ client library. +Like the C++ client library, ``rclpy`` also builds on top of the ``rcl`` C API for its implementation. +The interface provides an idiomatic Python experience that uses native Python types and patterns like lists and context objects. +By using the ``rcl`` |API| in the implementation, it stays consistent with the other client libraries in terms of feature parity and behavior. +In addition to providing Python idiomatic bindings around the ``rcl`` |API| and Python classes for each message, the Python client library takes care of the execution model, using ``threading.Thread`` or similar to run the functions in the ``rcl`` |API|. + +Like C++ it generates custom Python code for each ROS message that the user interacts with, but unlike C++ it eventually converts the native Python message object into the C version of the message. +All operations happen on the Python version of the messages until they need to be passed into the ``rcl`` layer, at which point they are converted into the plain C version of the message so it can be passed into the ``rcl`` C |API|. +This is avoided if possible when communicating between publishers and subscriptions in the same process to cut down on the conversion into and out of Python. + +The ``rclpy`` repository is located on GitHub at `ros2/rclpy `_ and contains the |package| ``rclpy``. +The generated |API| documentation is at {package_link(rclpy)}. + +Community-maintained +~~~~~~~~~~~~~~~~~~~~ + +While the C++ and Python client libraries are maintained by the core ROS 2 team, members of the ROS 2 community maintain additional client libraries: + +* `Ada `__ This is a set of packages (binding to ``rcl``, message generator, binding to ``tf2``, examples and tutorials) that allows the writing of Ada applications for ROS 2. +* `C `__ ``rclc`` does not put a layer on top of rcl but complements rcl to make rcl+rclc a feature-complete client library in C. See `micro.ros.org `__ for tutorials. +* `JVM and Android `__ Java and Android bindings for ROS 2. +* `.NET Core, UWP and C# `__ This is a collection of projects (bindings, code generator, examples and more) for writing ROS 2 applications for .NET Core and .NET Standard. +* `Node.js `__ rclnodejs is a Node.js client for ROS 2. + It provides a simple and easy JavaScript API for ROS 2 programming. +* `Rust `__ This is a set of projects (the rclrs client library, code generator, examples and more) that enables developers to write ROS 2 applications in Rust. +* `Flutter and Dart `__ Flutter and Dart bindings for ROS 2. + +Older, unmaintained client libraries are: + +* `C# `__ +* `Objective C and iOS `__ +* `Zig `__ + + +Common functionality: ``rcl`` +----------------------------- + +Most of the functionality found in a client library is not specific to the programming language of the client library. +For example, the behavior of parameters and the logic of namespaces should ideally be the same across all programming languages. +Because of this, rather than implementing the common functionality from scratch, client libraries make use of a common core ROS Client Library (RCL) interface that implements logic and behavior of ROS concepts that is not language-specific. +As a result, client libraries only need to wrap the common functionality in the RCL with foreign function interfaces. +This keeps client libraries thinner and easier to develop. +For this reason the common RCL functionality is exposed with C interfaces as the C language is typically the easiest language for client libraries to wrap. + +In addition to making the client libraries light-weight, an advantage of having the common core is that the behavior between languages is more consistent. +If any changes are made to the logic/behavior of the functionality in the core RCL -- namespaces, for example -- all client libraries that use the RCL will have these changes reflected. +Furthermore, having the common core means that maintaining multiple client libraries becomes less work when it comes to bug fixes. + +The API documentation for ``rcl`` can be found `here <{package_link(rcl)}>`__. + +Language-specific functionality +------------------------------- + +Client library concepts that require language-specific features/properties are not implemented in the RCL but instead are implemented in each client library. +For example, threading models used by "spin" functions will have implementations that are specific to the language of the client library. + +Demo +---- + +For a walkthrough of the message exchange between a publisher using ``rclpy`` and a subscription using ``rclcpp``\ , we encourage you to watch `this ROSCon talk `__ starting at 17:25 (`see the slides here `__). + +Comparison to ROS 1 +------------------- + +In ROS 1, all client libraries are developed "from the ground up". +This allows for the ROS 1 Python client library to be implemented purely in Python, for example, which brings benefits of such as not needing to compile code. +However, naming conventions and behaviors are not always consistent between client libraries, bug fixes have to be done in multiple places, and there is a lot of functionality that has only ever been implemented in one client library (e.g. UDPROS). + +Summary +------- + +By utilizing the common core ROS client library, client libraries written in a variety of programming languages are easier to write and have more consistent behavior. \ No newline at end of file diff --git a/source/ROS-Framework/About-Interfaces.rst b/source/ROS-Framework/About-Interfaces.rst index 578c9d049b5..1c3f1bd9e2a 100644 --- a/source/ROS-Framework/About-Interfaces.rst +++ b/source/ROS-Framework/About-Interfaces.rst @@ -1,316 +1,317 @@ -.. redirect-from:: - - About-ROS-Interfaces - Concepts/About-ROS-Interfaces - -Interfaces -========== - -.. toctree:: - :maxdepth: 1 - :hidden: - - interfaces/Interfaces-Topics-Services-Actions - interfaces/Topics-Services-Actions - interfaces/About-Tf2/About-Tf2 - interfaces/Working-with-interfaces - -.. contents:: Table of Contents - :local: - -Background ----------- - -ROS applications typically communicate through interfaces of one of three types: :doc:`topics `, :doc:`services `, or :doc:`actions `. -ROS 2 uses a simplified description language, the interface definition language (IDL), to describe these interfaces. -This description makes it easy for ROS tools to automatically generate source code for the interface type in several target languages. - -In this document we will describe the supported types: - -* msg: ``.msg`` files are simple text files that describe the fields of a ROS message. - They are used to generate source code for messages in different languages. -* srv: ``.srv`` files describe a service. - They are composed of two parts: a request and a response. - The request and response are message declarations. -* action: ``.action`` files describe actions. - They are composed of three parts: a goal, a result, and feedback. - Each part is a message declaration itself. - -Messages --------- - -Messages are a way for a ROS 2 node to send data on the network to other ROS nodes, with no response expected. -For instance, if a ROS 2 node reads temperature data from a sensor, it can then publish that data on the ROS 2 network using a ``Temperature`` message. -Other nodes on the ROS 2 network can subscribe to that data and receive the ``Temperature`` message. - -Messages are described and defined in ``.msg`` files in the ``msg/`` directory of a ROS package. -``.msg`` files are composed of two parts: fields and constants. - -Fields -^^^^^^ - -Each field consists of a type and a name, separated by a space, i.e: - -.. code-block:: bash - - fieldtype1 fieldname1 - fieldtype2 fieldname2 - fieldtype3 fieldname3 - -For example: - -.. code-block:: bash - - int32 my_int - string my_string - -Field types -~~~~~~~~~~~ - -Field types can be: - -* a built-in-type -* names of Message descriptions defined on their own, such as "geometry_msgs/PoseStamped" - -*Built-in-types currently supported:* - -.. list-table:: - :header-rows: 1 - - * - Type name - - `C++ `__ - - `Python `__ - - `DDS type `__ - * - bool - - bool - - builtins.bool - - boolean - * - byte - - uint8_t - - builtins.bytes* - - octet - * - char - - char - - builtins.int* - - char - * - float32 - - float - - builtins.float* - - float - * - float64 - - double - - builtins.float* - - double - * - int8 - - int8_t - - builtins.int* - - octet - * - uint8 - - uint8_t - - builtins.int* - - octet - * - int16 - - int16_t - - builtins.int* - - short - * - uint16 - - uint16_t - - builtins.int* - - unsigned short - * - int32 - - int32_t - - builtins.int* - - long - * - uint32 - - uint32_t - - builtins.int* - - unsigned long - * - int64 - - int64_t - - builtins.int* - - long long - * - uint64 - - uint64_t - - builtins.int* - - unsigned long long - * - string - - std::string - - builtins.str - - string - * - wstring - - std::u16string - - builtins.str - - wstring - -*Every built-in-type can be used to define arrays:* - -.. list-table:: - :header-rows: 1 - - * - Type name - - `C++ `__ - - `Python `__ - - `DDS type `__ - * - static array - - std::array - - builtins.list* - - T[N] - * - unbounded dynamic array - - std::vector - - builtins.list - - sequence - * - bounded dynamic array - - custom_class - - builtins.list* - - sequence - * - bounded string - - std::string - - builtins.str* - - string - -(*) All types that are more permissive than their ROS definition enforce the ROS constraints in range and length by software. - -*Example of message definition using arrays and bounded types:* - -.. code-block:: bash - - int32[] unbounded_integer_array - int32[5] five_integers_array - int32[<=5] up_to_five_integers_array - - string string_of_unbounded_size - string<=10 up_to_ten_characters_string - - string[<=5] up_to_five_unbounded_strings - string<=10[] unbounded_array_of_strings_up_to_ten_characters_each - string<=10[<=5] up_to_five_strings_up_to_ten_characters_each - -Field names -~~~~~~~~~~~ - -Field names must be lowercase alphanumeric characters with underscores for separating words. -They must start with an alphabetic character, and they must not end with an underscore or have two consecutive underscores. - -Field default value -~~~~~~~~~~~~~~~~~~~ - -Default values can be set to any field in the message type. -Currently default values are not supported for string arrays and complex types (i.e. types not present in the built-in-types table above; that applies to all nested messages). - -Defining a default value is done by adding a third element to the field definition line, i.e: - -.. code-block:: bash - - fieldtype fieldname fielddefaultvalue - -For example: - -.. code-block:: bash - - uint8 x 42 - int16 y -2000 - string full_name "John Doe" - int32[] samples [-200, -100, 0, 100, 200] - -.. note:: - - * string values must be defined in single ``'`` or double ``"`` quotes - * currently string values are not escaped - -Constants -^^^^^^^^^ - -Each constant definition is like a field description with a default value, except that this value can never be changed programmatically. -This value assignment is indicated by use of an equal '=' sign, e.g. - -.. code-block:: bash - - constanttype CONSTANTNAME=constantvalue - -For example: - -.. code-block:: bash - - int32 X=123 - int32 Y=-123 - string FOO="foo" - string EXAMPLE='bar' - -.. note:: - - Constants names have to be UPPERCASE - -Services --------- - -Services are a request/response communication, where the client (requester) is waiting for the server (responder) to make a short computation and return a result. - -Services are described and defined in ``.srv`` files in the ``srv/`` directory of a ROS package. - -A service description file consists of a request and a response msg type, separated by ``---``. -Any two ``.msg`` files concatenated with a ``---`` are a legal service description. - -Here is a very simple example of a service that takes in a string and returns a string: - -.. code-block:: bash - - string str - --- - string str - -We can of course get much more complicated (if you want to refer to a message from the same package you must not mention the package name): - -.. code-block:: bash - - # request constants - int8 FOO=1 - int8 BAR=2 - # request fields - int8 foobar - another_pkg/AnotherMessage msg - --- - # response constants - uint32 SECRET=123456 - # response fields - another_pkg/YetAnotherMessage val - CustomMessageDefinedInThisPackage value - uint32 an_integer - -You cannot embed another service inside of a service. - -Actions -------- - -Actions are a long-running request/response communication, where the action client (requester) is waiting for the action server (the responder) to take some action and return a result. -In contrast to services, actions can be long-running (many seconds or minutes), provide feedback while they are happening, and can be interrupted. - -Action definitions have the following form: - -.. code:: - - - --- - - --- - - -Like services, the request fields are before and the response fields are after the first triple-dash (``---``), respectively. -There is also a third set of fields after the second triple-dash, which is the fields to be sent when sending feedback. - -There can be arbitrary numbers of request fields (including zero), arbitrary numbers of response fields (including zero), and arbitrary numbers of feedback fields (including zero). - -The ````, ````, and ```` follow all of the same rules as the ```` for a message. -The ````, ````, and ```` follow all of the same rules as the ```` for a message. - -For instance, the ``Fibonacci`` action definition contains the following: - -.. code:: - - int32 order - --- - int32[] sequence - --- - int32[] sequence - -This is an action definition where the action client is sending a single ``int32`` field representing the number of Fibonacci steps to take, and expecting the action server to produce an array of ``int32`` containing the complete steps. -Along the way, the action server may also provide an intermediate array of ``int32`` containing the steps accomplished up until a certain point. +.. redirect-from:: + + About-ROS-Interfaces + Concepts/About-ROS-Interfaces + Concepts/Basic/About-Interfaces + +Interfaces +========== + +.. toctree:: + :maxdepth: 1 + :hidden: + + interfaces/Interfaces-Topics-Services-Actions + interfaces/Topics-Services-Actions + interfaces/About-Tf2/About-Tf2 + interfaces/Working-with-interfaces + +.. contents:: Table of Contents + :local: + +Background +---------- + +ROS applications typically communicate through interfaces of one of three types: :doc:`topics `, :doc:`services `, or :doc:`actions `. +ROS 2 uses a simplified description language, the interface definition language (IDL), to describe these interfaces. +This description makes it easy for ROS tools to automatically generate source code for the interface type in several target languages. + +In this document we will describe the supported types: + +* msg: ``.msg`` files are simple text files that describe the fields of a ROS message. + They are used to generate source code for messages in different languages. +* srv: ``.srv`` files describe a service. + They are composed of two parts: a request and a response. + The request and response are message declarations. +* action: ``.action`` files describe actions. + They are composed of three parts: a goal, a result, and feedback. + Each part is a message declaration itself. + +Messages +-------- + +Messages are a way for a ROS 2 node to send data on the network to other ROS nodes, with no response expected. +For instance, if a ROS 2 node reads temperature data from a sensor, it can then publish that data on the ROS 2 network using a ``Temperature`` message. +Other nodes on the ROS 2 network can subscribe to that data and receive the ``Temperature`` message. + +Messages are described and defined in ``.msg`` files in the ``msg/`` directory of a ROS package. +``.msg`` files are composed of two parts: fields and constants. + +Fields +^^^^^^ + +Each field consists of a type and a name, separated by a space, i.e: + +.. code-block:: bash + + fieldtype1 fieldname1 + fieldtype2 fieldname2 + fieldtype3 fieldname3 + +For example: + +.. code-block:: bash + + int32 my_int + string my_string + +Field types +~~~~~~~~~~~ + +Field types can be: + +* a built-in-type +* names of Message descriptions defined on their own, such as "geometry_msgs/PoseStamped" + +*Built-in-types currently supported:* + +.. list-table:: + :header-rows: 1 + + * - Type name + - `C++ `__ + - `Python `__ + - `DDS type `__ + * - bool + - bool + - builtins.bool + - boolean + * - byte + - uint8_t + - builtins.bytes* + - octet + * - char + - char + - builtins.int* + - char + * - float32 + - float + - builtins.float* + - float + * - float64 + - double + - builtins.float* + - double + * - int8 + - int8_t + - builtins.int* + - octet + * - uint8 + - uint8_t + - builtins.int* + - octet + * - int16 + - int16_t + - builtins.int* + - short + * - uint16 + - uint16_t + - builtins.int* + - unsigned short + * - int32 + - int32_t + - builtins.int* + - long + * - uint32 + - uint32_t + - builtins.int* + - unsigned long + * - int64 + - int64_t + - builtins.int* + - long long + * - uint64 + - uint64_t + - builtins.int* + - unsigned long long + * - string + - std::string + - builtins.str + - string + * - wstring + - std::u16string + - builtins.str + - wstring + +*Every built-in-type can be used to define arrays:* + +.. list-table:: + :header-rows: 1 + + * - Type name + - `C++ `__ + - `Python `__ + - `DDS type `__ + * - static array + - std::array + - builtins.list* + - T[N] + * - unbounded dynamic array + - std::vector + - builtins.list + - sequence + * - bounded dynamic array + - custom_class + - builtins.list* + - sequence + * - bounded string + - std::string + - builtins.str* + - string + +(*) All types that are more permissive than their ROS definition enforce the ROS constraints in range and length by software. + +*Example of message definition using arrays and bounded types:* + +.. code-block:: bash + + int32[] unbounded_integer_array + int32[5] five_integers_array + int32[<=5] up_to_five_integers_array + + string string_of_unbounded_size + string<=10 up_to_ten_characters_string + + string[<=5] up_to_five_unbounded_strings + string<=10[] unbounded_array_of_strings_up_to_ten_characters_each + string<=10[<=5] up_to_five_strings_up_to_ten_characters_each + +Field names +~~~~~~~~~~~ + +Field names must be lowercase alphanumeric characters with underscores for separating words. +They must start with an alphabetic character, and they must not end with an underscore or have two consecutive underscores. + +Field default value +~~~~~~~~~~~~~~~~~~~ + +Default values can be set to any field in the message type. +Currently default values are not supported for string arrays and complex types (i.e. types not present in the built-in-types table above; that applies to all nested messages). + +Defining a default value is done by adding a third element to the field definition line, i.e: + +.. code-block:: bash + + fieldtype fieldname fielddefaultvalue + +For example: + +.. code-block:: bash + + uint8 x 42 + int16 y -2000 + string full_name "John Doe" + int32[] samples [-200, -100, 0, 100, 200] + +.. note:: + + * string values must be defined in single ``'`` or double ``"`` quotes + * currently string values are not escaped + +Constants +^^^^^^^^^ + +Each constant definition is like a field description with a default value, except that this value can never be changed programmatically. +This value assignment is indicated by use of an equal '=' sign, e.g. + +.. code-block:: bash + + constanttype CONSTANTNAME=constantvalue + +For example: + +.. code-block:: bash + + int32 X=123 + int32 Y=-123 + string FOO="foo" + string EXAMPLE='bar' + +.. note:: + + Constants names have to be UPPERCASE + +Services +-------- + +Services are a request/response communication, where the client (requester) is waiting for the server (responder) to make a short computation and return a result. + +Services are described and defined in ``.srv`` files in the ``srv/`` directory of a ROS package. + +A service description file consists of a request and a response msg type, separated by ``---``. +Any two ``.msg`` files concatenated with a ``---`` are a legal service description. + +Here is a very simple example of a service that takes in a string and returns a string: + +.. code-block:: bash + + string str + --- + string str + +We can of course get much more complicated (if you want to refer to a message from the same package you must not mention the package name): + +.. code-block:: bash + + # request constants + int8 FOO=1 + int8 BAR=2 + # request fields + int8 foobar + another_pkg/AnotherMessage msg + --- + # response constants + uint32 SECRET=123456 + # response fields + another_pkg/YetAnotherMessage val + CustomMessageDefinedInThisPackage value + uint32 an_integer + +You cannot embed another service inside of a service. + +Actions +------- + +Actions are a long-running request/response communication, where the action client (requester) is waiting for the action server (the responder) to take some action and return a result. +In contrast to services, actions can be long-running (many seconds or minutes), provide feedback while they are happening, and can be interrupted. + +Action definitions have the following form: + +.. code:: + + + --- + + --- + + +Like services, the request fields are before and the response fields are after the first triple-dash (``---``), respectively. +There is also a third set of fields after the second triple-dash, which is the fields to be sent when sending feedback. + +There can be arbitrary numbers of request fields (including zero), arbitrary numbers of response fields (including zero), and arbitrary numbers of feedback fields (including zero). + +The ````, ````, and ```` follow all of the same rules as the ```` for a message. +The ````, ````, and ```` follow all of the same rules as the ```` for a message. + +For instance, the ``Fibonacci`` action definition contains the following: + +.. code:: + + int32 order + --- + int32[] sequence + --- + int32[] sequence + +This is an action definition where the action client is sending a single ``int32`` field representing the number of Fibonacci steps to take, and expecting the action server to produce an array of ``int32`` containing the complete steps. +Along the way, the action server may also provide an intermediate array of ``int32`` containing the steps accomplished up until a certain point. \ No newline at end of file diff --git a/source/ROS-Framework/About-Nodes.rst b/source/ROS-Framework/About-Nodes.rst index ba8739fb0b9..35dd3f47c09 100644 --- a/source/ROS-Framework/About-Nodes.rst +++ b/source/ROS-Framework/About-Nodes.rst @@ -1,29 +1,32 @@ -Nodes -===== - -.. toctree:: - :maxdepth: 1 - :hidden: - - nodes/About-Discovery - nodes/About-Domain-ID - nodes/About-Logging/About-Logging - nodes/About-Composition - nodes/Working-with-nodes - -.. contents:: Table of Contents - :local: - -A node is a participant in the ROS 2 graph, which uses a :doc:`client library ` to communicate with other nodes. -Nodes can communicate with other nodes within the same process, in a different process, or on a different machine. -Nodes are typically the unit of computation in a ROS graph; each node should do one logical thing. - -Nodes can :doc:`publish ` to named topics to deliver data to other nodes, or :doc:`subscribe ` to named topics to get data from other nodes. -They can also act as a :doc:`service client ` to have another node perform a computation on their behalf, or as a :doc:`service server ` to provide functionality to other nodes. -For long-running computations, a node can act as an :doc:`action client ` to have another node perform it on their behalf, or as an :doc:`action server ` to provide functionality to other nodes. -Nodes can provide configurable :doc:`parameters ` to change behavior during run-time. - -Nodes are often a complex combination of publishers, subscribers, service servers, service clients, action servers, and action clients, all at the same time. - -Connections between nodes are established through a distributed :doc:`discovery ` process. - +.. redirect-from:: + + Concepts/Basic/About-Nodes + +Nodes +===== + +.. toctree:: + :maxdepth: 1 + :hidden: + + nodes/About-Discovery + nodes/About-Domain-ID + nodes/About-Logging/About-Logging + nodes/About-Composition + nodes/Working-with-nodes + +.. contents:: Table of Contents + :local: + +A node is a participant in the ROS 2 graph, which uses a :doc:`client library ` to communicate with other nodes. +Nodes can communicate with other nodes within the same process, in a different process, or on a different machine. +Nodes are typically the unit of computation in a ROS graph; each node should do one logical thing. + +Nodes can :doc:`publish ` to named topics to deliver data to other nodes, or :doc:`subscribe ` to named topics to get data from other nodes. +They can also act as a :doc:`service client ` to have another node perform a computation on their behalf, or as a :doc:`service server ` to provide functionality to other nodes. +For long-running computations, a node can act as an :doc:`action client ` to have another node perform it on their behalf, or as an :doc:`action server ` to provide functionality to other nodes. +Nodes can provide configurable :doc:`parameters ` to change behavior during run-time. + +Nodes are often a complex combination of publishers, subscribers, service servers, service clients, action servers, and action clients, all at the same time. + +Connections between nodes are established through a distributed :doc:`discovery ` process. diff --git a/source/ROS-Framework/About-Parameters.rst b/source/ROS-Framework/About-Parameters.rst index 151d29322c0..c1e8e62559d 100644 --- a/source/ROS-Framework/About-Parameters.rst +++ b/source/ROS-Framework/About-Parameters.rst @@ -1,138 +1,139 @@ -.. redirect-from:: - - About-ROS-2-Parameters - Concepts/About-ROS-2-Parameters - -Parameters -========== - -.. toctree:: - :maxdepth: 1 - :hidden: - - parameters/Working-with-parameters - -.. contents:: Table of Contents - :local: - -Overview --------- - -Parameters in ROS 2 are associated with individual nodes. -Parameters are used to configure nodes at startup (and during runtime), without changing the code. -The lifetime of a parameter is tied to the lifetime of the node (though the node could implement some sort of persistence to reload values after restart). - -Parameters are addressed by node name, node namespace, parameter name, and parameter namespace. -Providing a parameter namespace is optional. - -Each parameter consists of a key, a value, and a descriptor. -The key is a string and the value is one of the following types: ``bool``, ``int64``, ``float64``, ``string``, ``byte[]``, ``bool[]``, ``int64[]``, ``float64[]`` or ``string[]``. -By default all descriptors are empty, but can contain parameter descriptions, value ranges, type information, and additional constraints. - -For a hands-on tutorial with ROS parameters see :doc:`../../Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters`. - -Parameters background ---------------------- - -Declaring parameters -^^^^^^^^^^^^^^^^^^^^ - -By default, a node needs to *declare* all of the parameters that it will accept during its lifetime. -This is so that the type and name of the parameters are well-defined at node startup time, which reduces the chances of misconfiguration later on. -See :doc:`../../Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-CPP` or :doc:`../../Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-Python` for tutorials on declaring and using parameters from a node. - -For some types of nodes, not all of the parameters will be known ahead of time. -In these cases, the node can be instantiated with ``allow_undeclared_parameters`` set to ``true``, which will allow parameters to be get and set on the node even if they haven't been declared. - -Parameter types -^^^^^^^^^^^^^^^ - -Each parameter on a ROS 2 node has one of the pre-defined parameter types as mentioned in the Overview. -By default, attempts to change the type of a declared parameter at runtime will fail. -This prevents common mistakes, such as putting a boolean value into an integer parameter. - -If a parameter needs to be multiple different types, and the code using the parameter can handle it, this default behavior can be changed. -When the parameter is declared, it should be declared using a ``ParameterDescriptor`` with the ``dynamic_typing`` member variable set to ``true``. - -Parameter callbacks -^^^^^^^^^^^^^^^^^^^ - -A ROS 2 node can register three different types of callbacks to be informed when changes are happening to parameters. -All three of the callbacks are optional. - -The first is known as a "pre set parameter" callback, and can be set by calling ``add_pre_set_parameters_callback`` from the node API. -This callback is passed a list of the ``Parameter`` objects that are being changed, and returns nothing. -When it is called, it can modify the ``Parameter`` list to change, add, or remove entries. -As an example, if ``parameter2`` should change anytime that ``parameter1`` changes, that can be implemented with this callback. - -The second is known as a "set parameter" callback, and can be set by calling ``add_on_set_parameters_callback`` from the node API. -The callback is passed a list of immutable ``Parameter`` objects, and returns an ``rcl_interfaces/msg/SetParametersResult``. -The main purpose of this callback is to give the user the ability to inspect the upcoming change to the parameter and explicitly reject the change. - -.. note:: - It is important that "set parameter" callbacks have no side-effects. - Since multiple "set parameter" callbacks can be chained, there is no way for an individual callback to know if a later callback will reject the update. - If the individual callback were to make changes to the class it is in, for instance, it may get out-of-sync with the actual parameter. - To get a callback *after* a parameter has been successfully changed, see the next type of callback below. - -The third type of callback is known as an "post set parameter" callback, and can be set by calling ``add_post_set_parameters_callback`` from the node API. -The callback is passed a list of immutable ``Parameter`` objects, and returns nothing. -The main purpose of this callback is to give the user the ability to react to changes from parameters that have successfully been accepted. - -The ROS 2 demos have an `example `__ of all of these callbacks in use. - -Interacting with parameters ---------------------------- - -ROS 2 nodes can perform parameter operations through node APIs as described in :doc:`../../Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-CPP` or :doc:`../../Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-Python`. -External processes can perform parameter operations via parameter services that are created by default when a node is instantiated. -The services that are created by default are: - -* ``/node_name/describe_parameters``: Uses a service type of ``rcl_interfaces/srv/DescribeParameters``. - Given a list of parameter names, returns a list of descriptors associated with the parameters. -* ``/node_name/get_parameter_types``: Uses a service type of ``rcl_interfaces/srv/GetParameterTypes``. - Given a list of parameter names, returns a list of parameter types associated with the parameters. -* ``/node_name/get_parameters``: Uses a service type of ``rcl_interfaces/srv/GetParameters``. - Given a list of parameter names, returns a list of parameter values associated with the parameters. -* ``/node_name/list_parameters``: Uses a service type of ``rcl_interfaces/srv/ListParameters``. - Given an optional list of parameter prefixes, returns a list of the available parameters with that prefix. - If the prefixes are empty, returns all parameters. -* ``/node_name/set_parameters``: Uses a service type of ``rcl_interfaces/srv/SetParameters``. - Given a list of parameter names and values, attempts to set the parameters on the node. - Returns a list of results from trying to set each parameter; some of them may have succeeded and some may have failed. -* ``/node_name/set_parameters_atomically``: Uses a service type of ``rcl_interfaces/srv/SetParametersAtomically``. - Given a list of parameter names and values, attempts to set the parameters on the node. - Returns a single result from trying to set all parameters, so if one failed, all of them failed. - -Setting initial parameter values when running a node ----------------------------------------------------- - -Initial parameter values can be set when running the node either through individual command-line arguments, or through YAML files. -See :ref:`NodeArgsParameters` for examples on how to set initial parameter values. - -Setting initial parameter values when launching nodes ------------------------------------------------------ - -Initial parameter values can also be set when running the node through the ROS 2 launch facility. -See :doc:`this document <../../Tutorials/Intermediate/Launch/Using-ROS2-Launch-For-Large-Projects>` for information on how to specify parameters via launch. - -Manipulating parameter values at runtime ----------------------------------------- - -The ``ros2 param`` command is the general way to interact with parameters for nodes that are already running. -``ros2 param`` uses the parameter service API as described above to perform the various operations. -See :doc:`this how-to guide <../../How-To-Guides/Using-ros2-param>` for details on how to use ``ros2 param``. - -In addition to the command-line interface, parameters can also be manipulated programmatically at runtime using the ROS 2 client libraries. -All client libraries provide APIs to get, set, and react to parameter changes while a node is running. - -Client library support includes: - * **C++ (rclcpp)**: see :doc:`../../Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-CPP` and :doc:`../../Tutorials/Intermediate/Monitoring-For-Parameter-Changes-CPP`. - * **Python (rclpy)**: see :doc:`../../Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-Python` and :doc:`../../Tutorials/Intermediate/Monitoring-For-Parameter-Changes-Python`. - -Migrating from ROS 1 --------------------- - -The :doc:`Launch file migration guide <../../How-To-Guides/Migrating-from-ROS1/Migrating-Launch-Files>` explains how to migrate ``param`` and ``rosparam`` launch tags from ROS 1 to ROS 2. - -The :doc:`Migration guide <../../How-To-Guides/Migrating-from-ROS1/Migrating-Parameters>` explains how to migrate parameter from ROS 1 to ROS 2. +.. redirect-from:: + + About-ROS-2-Parameters + Concepts/About-ROS-2-Parameters + Concepts/Basic/About-Parameters + +Parameters +========== + +.. toctree:: + :maxdepth: 1 + :hidden: + + parameters/Working-with-parameters + +.. contents:: Table of Contents + :local: + +Overview +-------- + +Parameters in ROS 2 are associated with individual nodes. +Parameters are used to configure nodes at startup (and during runtime), without changing the code. +The lifetime of a parameter is tied to the lifetime of the node (though the node could implement some sort of persistence to reload values after restart). + +Parameters are addressed by node name, node namespace, parameter name, and parameter namespace. +Providing a parameter namespace is optional. + +Each parameter consists of a key, a value, and a descriptor. +The key is a string and the value is one of the following types: ``bool``, ``int64``, ``float64``, ``string``, ``byte[]``, ``bool[]``, ``int64[]``, ``float64[]`` or ``string[]``. +By default all descriptors are empty, but can contain parameter descriptions, value ranges, type information, and additional constraints. + +For a hands-on tutorial with ROS parameters see :doc:`parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters`. + +Parameters background +--------------------- + +Declaring parameters +^^^^^^^^^^^^^^^^^^^^ + +By default, a node needs to *declare* all of the parameters that it will accept during its lifetime. +This is so that the type and name of the parameters are well-defined at node startup time, which reduces the chances of misconfiguration later on. +See :doc:`client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP` or :doc:`client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python` for tutorials on declaring and using parameters from a node. + +For some types of nodes, not all of the parameters will be known ahead of time. +In these cases, the node can be instantiated with ``allow_undeclared_parameters`` set to ``true``, which will allow parameters to be get and set on the node even if they haven't been declared. + +Parameter types +^^^^^^^^^^^^^^^ + +Each parameter on a ROS 2 node has one of the pre-defined parameter types as mentioned in the Overview. +By default, attempts to change the type of a declared parameter at runtime will fail. +This prevents common mistakes, such as putting a boolean value into an integer parameter. + +If a parameter needs to be multiple different types, and the code using the parameter can handle it, this default behavior can be changed. +When the parameter is declared, it should be declared using a ``ParameterDescriptor`` with the ``dynamic_typing`` member variable set to ``true``. + +Parameter callbacks +^^^^^^^^^^^^^^^^^^^ + +A ROS 2 node can register three different types of callbacks to be informed when changes are happening to parameters. +All three of the callbacks are optional. + +The first is known as a "pre set parameter" callback, and can be set by calling ``add_pre_set_parameters_callback`` from the node API. +This callback is passed a list of the ``Parameter`` objects that are being changed, and returns nothing. +When it is called, it can modify the ``Parameter`` list to change, add, or remove entries. +As an example, if ``parameter2`` should change anytime that ``parameter1`` changes, that can be implemented with this callback. + +The second is known as a "set parameter" callback, and can be set by calling ``add_on_set_parameters_callback`` from the node API. +The callback is passed a list of immutable ``Parameter`` objects, and returns an ``rcl_interfaces/msg/SetParametersResult``. +The main purpose of this callback is to give the user the ability to inspect the upcoming change to the parameter and explicitly reject the change. + +.. note:: + It is important that "set parameter" callbacks have no side-effects. + Since multiple "set parameter" callbacks can be chained, there is no way for an individual callback to know if a later callback will reject the update. + If the individual callback were to make changes to the class it is in, for instance, it may get out-of-sync with the actual parameter. + To get a callback *after* a parameter has been successfully changed, see the next type of callback below. + +The third type of callback is known as an "post set parameter" callback, and can be set by calling ``add_post_set_parameters_callback`` from the node API. +The callback is passed a list of immutable ``Parameter`` objects, and returns nothing. +The main purpose of this callback is to give the user the ability to react to changes from parameters that have successfully been accepted. + +The ROS 2 demos have an `example `__ of all of these callbacks in use. + +Interacting with parameters +--------------------------- + +ROS 2 nodes can perform parameter operations through node APIs as described in :doc:`client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP` or :doc:`client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python`. +External processes can perform parameter operations via parameter services that are created by default when a node is instantiated. +The services that are created by default are: + +* ``/node_name/describe_parameters``: Uses a service type of ``rcl_interfaces/srv/DescribeParameters``. + Given a list of parameter names, returns a list of descriptors associated with the parameters. +* ``/node_name/get_parameter_types``: Uses a service type of ``rcl_interfaces/srv/GetParameterTypes``. + Given a list of parameter names, returns a list of parameter types associated with the parameters. +* ``/node_name/get_parameters``: Uses a service type of ``rcl_interfaces/srv/GetParameters``. + Given a list of parameter names, returns a list of parameter values associated with the parameters. +* ``/node_name/list_parameters``: Uses a service type of ``rcl_interfaces/srv/ListParameters``. + Given an optional list of parameter prefixes, returns a list of the available parameters with that prefix. + If the prefixes are empty, returns all parameters. +* ``/node_name/set_parameters``: Uses a service type of ``rcl_interfaces/srv/SetParameters``. + Given a list of parameter names and values, attempts to set the parameters on the node. + Returns a list of results from trying to set each parameter; some of them may have succeeded and some may have failed. +* ``/node_name/set_parameters_atomically``: Uses a service type of ``rcl_interfaces/srv/SetParametersAtomically``. + Given a list of parameter names and values, attempts to set the parameters on the node. + Returns a single result from trying to set all parameters, so if one failed, all of them failed. + +Setting initial parameter values when running a node +---------------------------------------------------- + +Initial parameter values can be set when running the node either through individual command-line arguments, or through YAML files. +See :ref:`NodeArgsParameters` for examples on how to set initial parameter values. + +Setting initial parameter values when launching nodes +----------------------------------------------------- + +Initial parameter values can also be set when running the node through the ROS 2 launch facility. +See :doc:`this document <../Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects>` for information on how to specify parameters via launch. + +Manipulating parameter values at runtime +---------------------------------------- + +The ``ros2 param`` command is the general way to interact with parameters for nodes that are already running. +``ros2 param`` uses the parameter service API as described above to perform the various operations. +See :doc:`this how-to guide ` for details on how to use ``ros2 param``. + +In addition to the command-line interface, parameters can also be manipulated programmatically at runtime using the ROS 2 client libraries. +All client libraries provide APIs to get, set, and react to parameter changes while a node is running. + +Client library support includes: + * **C++ (rclcpp)**: see :doc:`client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP` and :doc:`parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP`. + * **Python (rclpy)**: see :doc:`client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python` and :doc:`parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python`. + +Migrating from ROS 1 +-------------------- + +The :doc:`Launch file migration guide <../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files>` explains how to migrate ``param`` and ``rosparam`` launch tags from ROS 1 to ROS 2. + +The :doc:`Migration guide <../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` explains how to migrate parameter from ROS 1 to ROS 2. \ No newline at end of file diff --git a/source/ROS-Framework/About-Services.rst b/source/ROS-Framework/About-Services.rst index 140d5446826..6c6685cf68b 100644 --- a/source/ROS-Framework/About-Services.rst +++ b/source/ROS-Framework/About-Services.rst @@ -1,57 +1,61 @@ -Services -======== -.. toctree:: - :maxdepth: 1 - :hidden: - - services/Working-with-services - -.. contents:: Table of Contents - :local: - -In ROS 2, a service refers to a remote procedure call. -In other words, a node can make a remote procedure call to another node which will do a computation and return a result. - -This structure is reflected in how a service message definition looks: - -.. code:: - - uint32 request - --- - uint32 response - -In ROS 2, services are expected to return quickly, as the client is generally waiting on the result. -Services should never be used for longer running processes, in particular processes that might need to be preempted for exceptional situations. -If you have a service that will be doing a long-running computation, consider using an :doc:`action ` instead. - -Services are identified by a service name, which looks much like a topic name (but is in a different namespace). - -A service consists of two parts: the service server and the service client. - -Service server --------------- - -A service server is the entity that will accept a remote procedure request, and perform some computation on it. -For instance, suppose the ROS 2 message contains the following: - -.. code:: - - uint32 a - uint32 b - --- - uint32 sum - -The service server would be the entity that receives this message, adds ``a`` and ``b`` together, and returns the ``sum``. - -.. note:: - - There should only ever be one service server per service name. - It is undefined which service server will receive client requests in the case of multiple service servers on the same service name. - -Service client --------------- - -A service client is an entity that will request a remote service server to perform a computation on its behalf. -Following from the example above, the service client is the entity that creates the initial message containing ``a`` and ``b``, and waits for the service server to compute the sum and return the result. - -Unlike the service server, there can be arbitrary numbers of service clients using the same service name. +.. redirect-from:: + + Concepts/Basic/About-Services + +Services +======== +.. toctree:: + :maxdepth: 1 + :hidden: + + services/Working-with-services + +.. contents:: Table of Contents + :local: + +In ROS 2, a service refers to a remote procedure call. +In other words, a node can make a remote procedure call to another node which will do a computation and return a result. + +This structure is reflected in how a service message definition looks: + +.. code:: + + uint32 request + --- + uint32 response + +In ROS 2, services are expected to return quickly, as the client is generally waiting on the result. +Services should never be used for longer running processes, in particular processes that might need to be preempted for exceptional situations. +If you have a service that will be doing a long-running computation, consider using an :doc:`action ` instead. + +Services are identified by a service name, which looks much like a topic name (but is in a different namespace). + +A service consists of two parts: the service server and the service client. + +Service server +-------------- + +A service server is the entity that will accept a remote procedure request, and perform some computation on it. +For instance, suppose the ROS 2 message contains the following: + +.. code:: + + uint32 a + uint32 b + --- + uint32 sum + +The service server would be the entity that receives this message, adds ``a`` and ``b`` together, and returns the ``sum``. + +.. note:: + + There should only ever be one service server per service name. + It is undefined which service server will receive client requests in the case of multiple service servers on the same service name. + +Service client +-------------- + +A service client is an entity that will request a remote service server to perform a computation on its behalf. +Following from the example above, the service client is the entity that creates the initial message containing ``a`` and ``b``, and waits for the service server to compute the sum and return the result. + +Unlike the service server, there can be arbitrary numbers of service clients using the same service name. \ No newline at end of file diff --git a/source/ROS-Framework/About-Topics.rst b/source/ROS-Framework/About-Topics.rst index 9c8a8382bff..4778e679574 100644 --- a/source/ROS-Framework/About-Topics.rst +++ b/source/ROS-Framework/About-Topics.rst @@ -1,63 +1,66 @@ -Topics -====== -.. toctree:: - :maxdepth: 1 - :hidden: - - topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics - topics/About-Quality-of-Service-Settings - topics/About-Topic-Statistics - topics/Working-with-topics - -.. contents:: Table of Contents - :local: - -Topics are one of the three primary styles of interfaces provided by ROS 2. -Topics should be used for continuous data streams, like sensor data, robot state, etc. - -As stated earlier, ROS 2 is a strongly-typed, anonymous publish/subscribe system. -Let's break down that sentence and explain it a bit more. - -Publish/Subscribe ------------------ - -A publish/subscribe system is one in which there are producers of data (publishers) and consumers of data (subscribers). -The publishers and subscribers know how to contact each other through the concept of a "topic", which is a common name so that the entities can find each other. -For instance, when you create a publisher, you must also give it a string that is the name of the topic; the same goes for the subscriber. -Any publishers and subscribers that are on the same topic name can directly communicate with each other. -There may be zero or more publishers and zero or more subscribers on any particular topic. -When data is published to the topic by any of the publishers, all subscribers in the system will receive the data. -This system is also known as a "bus", since it somewhat resembles a device bus from electrical engineering. -This concept of a bus is part of what makes ROS 2 a powerful and flexible system. -Publishers and subscribers can come and go as needed, meaning that debugging and introspection are natural extensions to the system. -For instance, if you want to record data, you can use the ``ros2 bag record`` command. -Under the hood, ``ros2 bag record`` creates a new subscriber to whatever topic you tell it, without interrupting the flow of data to the other parts of the system. - -Anonymous ---------- - -Another fact mentioned in the introduction is that ROS 2 is "anonymous". -This means that when a subscriber gets a piece of data, it doesn't generally know or care which publisher originally sent it (though it can find out if it wants). -The benefit to this architecture is that publishers and subscribers can be swapped out at will without affecting the rest of the system. - -Strongly-typed --------------- - -Finally, the introduction also mentioned that the publish/subscribe system is "strongly-typed". -That has two meanings in this context: - -1. The types of each field in a ROS message are typed, and that type is enforced at various levels. - For instance, if the ROS message contains: - - .. code:: - - uint32 field1 - string field2 - - Then the code will ensure that ``field1`` is always an unsigned integer and that ``field2`` is always a string. - -2. The semantics of each field are well-defined. - There is no automated mechanism to ensure this, but all of the core ROS types have strong semantics associated with them. - For instance, the IMU message contains a 3-dimensional vector for the measured angular velocity, and each of the dimensions is specified to be in radians/second. - Other interpretations should not be placed into the message. - +.. redirect-from:: + + Concepts/Basic/About-Topics + +Topics +====== +.. toctree:: + :maxdepth: 1 + :hidden: + + topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics + topics/About-Quality-of-Service-Settings + topics/About-Topic-Statistics + topics/Working-with-topics + +.. contents:: Table of Contents + :local: + +Topics are one of the three primary styles of interfaces provided by ROS 2. +Topics should be used for continuous data streams, like sensor data, robot state, etc. + +As stated earlier, ROS 2 is a strongly-typed, anonymous publish/subscribe system. +Let's break down that sentence and explain it a bit more. + +Publish/Subscribe +----------------- + +A publish/subscribe system is one in which there are producers of data (publishers) and consumers of data (subscribers). +The publishers and subscribers know how to contact each other through the concept of a "topic", which is a common name so that the entities can find each other. +For instance, when you create a publisher, you must also give it a string that is the name of the topic; the same goes for the subscriber. +Any publishers and subscribers that are on the same topic name can directly communicate with each other. +There may be zero or more publishers and zero or more subscribers on any particular topic. +When data is published to the topic by any of the publishers, all subscribers in the system will receive the data. +This system is also known as a "bus", since it somewhat resembles a device bus from electrical engineering. +This concept of a bus is part of what makes ROS 2 a powerful and flexible system. +Publishers and subscribers can come and go as needed, meaning that debugging and introspection are natural extensions to the system. +For instance, if you want to record data, you can use the ``ros2 bag record`` command. +Under the hood, ``ros2 bag record`` creates a new subscriber to whatever topic you tell it, without interrupting the flow of data to the other parts of the system. + +Anonymous +--------- + +Another fact mentioned in the introduction is that ROS 2 is "anonymous". +This means that when a subscriber gets a piece of data, it doesn't generally know or care which publisher originally sent it (though it can find out if it wants). +The benefit to this architecture is that publishers and subscribers can be swapped out at will without affecting the rest of the system. + +Strongly-typed +-------------- + +Finally, the introduction also mentioned that the publish/subscribe system is "strongly-typed". +That has two meanings in this context: + +1. The types of each field in a ROS message are typed, and that type is enforced at various levels. + For instance, if the ROS message contains: + + .. code:: + + uint32 field1 + string field2 + + Then the code will ensure that ``field1`` is always an unsigned integer and that ``field2`` is always a string. + +2. The semantics of each field are well-defined. + There is no automated mechanism to ensure this, but all of the core ROS types have strong semantics associated with them. + For instance, the IMU message contains a 3-dimensional vector for the measured angular velocity, and each of the dimensions is specified to be in radians/second. + Other interpretations should not be placed into the message. diff --git a/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst b/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst index 6d2210ed720..03a5d03b5f6 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst +++ b/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst @@ -1,342 +1,346 @@ -Configure action introspection -============================== - -**Goal:** Configure action introspection for an action client and an action server. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Overview --------- - -ROS 2 applications usually consist of actions to execute specific long-running procedures or work in remote nodes. -It is possible to introspect action data communication with action introspection. - -ROS 2 actions are built on topics and services, so action introspection is based on :doc:`Service Introspection `. - -In this demo, we'll be highlighting how to configure action introspection state for an action client and an action server and monitor action communication with ``ros2 action echo``. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 binary packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` and ``ros-{DISTRO}-demo-nodes-py`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Introspection Configuration State ---------------------------------- - -There are three configuration states for action introspection that are the same states as service introspection. - -.. list-table:: Action Introspection Configuration State - :widths: 25 25 - - * - RCL_SERVICE_INTROSPECTION_OFF - - Disabled - * - RCL_SERVICE_INTROSPECTION_METADATA - - Only metadata without any user data contents - * - RCL_SERVICE_INTROSPECTION_CONTENTS - - User data contents with metadata - -Introspection demo ------------------- - -This demo shows how to manage action introspection and monitor the action data communication with using ``ros2 action echo``. - -Action server -^^^^^^^^^^^^^ - -You can find the source code here: `fibonacci_action_server.py `__. -``FibonacciActionServer`` has a parameter named ``action_server_configure_introspection`` to configure the action introspection state. - -.. code-block:: python - - class FibonacciActionServer(Node): - ... - def on_post_set_parameters_callback(self, parameter_list): - for param in parameter_list: - if param.name != 'action_server_configure_introspection': - continue - - introspection_state = ServiceIntrospectionState.OFF - if param.value == 'disabled': - introspection_state = ServiceIntrospectionState.OFF - elif param.value == 'metadata': - introspection_state = ServiceIntrospectionState.METADATA - elif param.value == 'contents': - introspection_state = ServiceIntrospectionState.CONTENTS - - self._action_server.configure_introspection(self.get_clock(), - qos_profile_system_default, - introspection_state) - break - ... - -If you want to try the C++ version, you can find the source code here: `fibonacci_action_server.cpp `__. - -Action introspection is disabled by default, so users need to enable it with ``action_server_configure_introspection`` parameter when the server starts up. -In this demo, ``FibonacciActionServer`` enables action introspection when the value of the ``action_server_configure_introspection`` parameter is ``contents``. - -.. code-block:: console - - $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents - -To change action introspection state, we need to set the ``action_server_configure_introspection`` parameter as follows. - -To change it to user data contents with metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_server action_server_configure_introspection contents - -To change it to only metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_server action_server_configure_introspection metadata - -To disable: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_server action_server_configure_introspection disabled - -Action client -^^^^^^^^^^^^^ - -You can find the source code here: `fibonacci_action_client.cpp `__. -``FibonacciActionClient`` has a parameter named ``action_client_configure_introspection`` to configure the action introspection state. - -.. code-block:: c++ - - namespace action_tutorials_cpp - { - class FibonacciActionClient : public rclcpp::Node - ... - auto post_set_parameter_callback = - [this](const std::vector & parameters) { - for (const rclcpp::Parameter & param : parameters) { - if (param.get_name() != "action_client_configure_introspection") { - continue; - } - - rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - - if (param.as_string() == "disabled") { - introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - } else if (param.as_string() == "metadata") { - introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; - } else if (param.as_string() == "contents") { - introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; - } - - this->client_ptr_->configure_introspection( - this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); - break; - } - }; - ... - -If you want to try the Python version, you can find the source code here: `fibonacci_action_client.py `__. - -And then, we start and configure ``FibonacciActionClient`` in the same way. - -.. code-block:: console - - $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents - -To change action introspection state, we need to set the ``action_client_configure_introspection`` parameter as follows. -Note that ``FibonacciActionClient`` only runs in short time, so it is recommended to set the parameter before running the client as above. - -To change it to user data contents with metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_client action_client_configure_introspection contents - -To change it to only metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_client action_client_configure_introspection metadata - -To disable: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_client action_client_configure_introspection disabled - -Introspect -^^^^^^^^^^ - -In this tutorial, the following is an example output with action introspection state ``contents`` on both ``FibonacciActionServer`` and ``FibonacciActionClient``. -To monitor action communication between ``FibonacciActionServer`` and ``FibonacciActionClient``, let's run it: - -.. code-block:: console - - $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style - interface: GOAL_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 400435819 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1742070798 - nanosec: 400706446 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: RESULT_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 401486678 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] - response: [] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] - --- - interface: GOAL_SERVICE - info: - event_type: RESPONSE_SENT - stamp: - sec: 1742070798 - nanosec: 401109161 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [] - response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] - --- - interface: RESULT_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1742070798 - nanosec: 401579875 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1742070798 - nanosec: 401234269 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [] - response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55] - --- - interface: RESULT_SERVICE - info: - event_type: RESPONSE_SENT - stamp: - sec: 1742070807 - nanosec: 402339670 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [] - response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] - --- - interface: RESULT_SERVICE - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1742070807 - nanosec: 402698784 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [] - response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 4}] - --- - ... - -You can see the ``interface: GOAL_SERVICE`` and ``interface: RESULT_SERVICE``, those introspection service events take place in both ``FibonacciActionServer`` and ``FibonacciActionClient``. -And you can also see ``interface: FEEDBACK_TOPIC`` and ``interface: STATUS_TOPIC`` data, those topics are published by ``FibonacciActionServer`` and subscribed by ``FibonacciActionClient``. - -Now you can see the action communication between ``FibonacciActionServer`` and ``FibonacciActionClient`` with ``ros2 action echo``. - -Related content ---------------- - -- `Action Introspection REP-2018 `__. +.. redirect-from:: + + Tutorials/Demos/Action-Introspection + +Configure action introspection +============================== + +**Goal:** Configure action introspection for an action client and an action server. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Overview +-------- + +ROS 2 applications usually consist of actions to execute specific long-running procedures or work in remote nodes. +It is possible to introspect action data communication with action introspection. + +ROS 2 actions are built on topics and services, so action introspection is based on :doc:`Service Introspection `. + +In this demo, we'll be highlighting how to configure action introspection state for an action client and an action server and monitor action communication with ``ros2 action echo``. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 binary packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` and ``ros-{DISTRO}-demo-nodes-py`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Introspection Configuration State +--------------------------------- + +There are three configuration states for action introspection that are the same states as service introspection. + +.. list-table:: Action Introspection Configuration State + :widths: 25 25 + + * - RCL_SERVICE_INTROSPECTION_OFF + - Disabled + * - RCL_SERVICE_INTROSPECTION_METADATA + - Only metadata without any user data contents + * - RCL_SERVICE_INTROSPECTION_CONTENTS + - User data contents with metadata + +Introspection demo +------------------ + +This demo shows how to manage action introspection and monitor the action data communication with using ``ros2 action echo``. + +Action server +^^^^^^^^^^^^^ + +You can find the source code here: `fibonacci_action_server.py `__. +``FibonacciActionServer`` has a parameter named ``action_server_configure_introspection`` to configure the action introspection state. + +.. code-block:: python + + class FibonacciActionServer(Node): + ... + def on_post_set_parameters_callback(self, parameter_list): + for param in parameter_list: + if param.name != 'action_server_configure_introspection': + continue + + introspection_state = ServiceIntrospectionState.OFF + if param.value == 'disabled': + introspection_state = ServiceIntrospectionState.OFF + elif param.value == 'metadata': + introspection_state = ServiceIntrospectionState.METADATA + elif param.value == 'contents': + introspection_state = ServiceIntrospectionState.CONTENTS + + self._action_server.configure_introspection(self.get_clock(), + qos_profile_system_default, + introspection_state) + break + ... + +If you want to try the C++ version, you can find the source code here: `fibonacci_action_server.cpp `__. + +Action introspection is disabled by default, so users need to enable it with ``action_server_configure_introspection`` parameter when the server starts up. +In this demo, ``FibonacciActionServer`` enables action introspection when the value of the ``action_server_configure_introspection`` parameter is ``contents``. + +.. code-block:: console + + $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents + +To change action introspection state, we need to set the ``action_server_configure_introspection`` parameter as follows. + +To change it to user data contents with metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_server action_server_configure_introspection contents + +To change it to only metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_server action_server_configure_introspection metadata + +To disable: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_server action_server_configure_introspection disabled + +Action client +^^^^^^^^^^^^^ + +You can find the source code here: `fibonacci_action_client.cpp `__. +``FibonacciActionClient`` has a parameter named ``action_client_configure_introspection`` to configure the action introspection state. + +.. code-block:: c++ + + namespace action_tutorials_cpp + { + class FibonacciActionClient : public rclcpp::Node + ... + auto post_set_parameter_callback = + [this](const std::vector & parameters) { + for (const rclcpp::Parameter & param : parameters) { + if (param.get_name() != "action_client_configure_introspection") { + continue; + } + + rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + + if (param.as_string() == "disabled") { + introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + } else if (param.as_string() == "metadata") { + introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; + } else if (param.as_string() == "contents") { + introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; + } + + this->client_ptr_->configure_introspection( + this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); + break; + } + }; + ... + +If you want to try the Python version, you can find the source code here: `fibonacci_action_client.py `__. + +And then, we start and configure ``FibonacciActionClient`` in the same way. + +.. code-block:: console + + $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents + +To change action introspection state, we need to set the ``action_client_configure_introspection`` parameter as follows. +Note that ``FibonacciActionClient`` only runs in short time, so it is recommended to set the parameter before running the client as above. + +To change it to user data contents with metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_client action_client_configure_introspection contents + +To change it to only metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_client action_client_configure_introspection metadata + +To disable: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_client action_client_configure_introspection disabled + +Introspect +^^^^^^^^^^ + +In this tutorial, the following is an example output with action introspection state ``contents`` on both ``FibonacciActionServer`` and ``FibonacciActionClient``. +To monitor action communication between ``FibonacciActionServer`` and ``FibonacciActionClient``, let's run it: + +.. code-block:: console + + $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style + interface: GOAL_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 400435819 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1742070798 + nanosec: 400706446 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: RESULT_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 401486678 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] + response: [] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] + --- + interface: GOAL_SERVICE + info: + event_type: RESPONSE_SENT + stamp: + sec: 1742070798 + nanosec: 401109161 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [] + response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] + --- + interface: RESULT_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1742070798 + nanosec: 401579875 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1742070798 + nanosec: 401234269 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [] + response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55] + --- + interface: RESULT_SERVICE + info: + event_type: RESPONSE_SENT + stamp: + sec: 1742070807 + nanosec: 402339670 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [] + response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] + --- + interface: RESULT_SERVICE + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1742070807 + nanosec: 402698784 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [] + response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 4}] + --- + ... + +You can see the ``interface: GOAL_SERVICE`` and ``interface: RESULT_SERVICE``, those introspection service events take place in both ``FibonacciActionServer`` and ``FibonacciActionClient``. +And you can also see ``interface: FEEDBACK_TOPIC`` and ``interface: STATUS_TOPIC`` data, those topics are published by ``FibonacciActionServer`` and subscribed by ``FibonacciActionClient``. + +Now you can see the action communication between ``FibonacciActionServer`` and ``FibonacciActionClient`` with ``ros2 action echo``. + +Related content +--------------- + +- `Action Introspection REP-2018 `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst b/source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst index 86a68a46913..97e10035a5a 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst +++ b/source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst @@ -1,222 +1,223 @@ -.. redirect-from:: - - Tutorials/Actions/Creating-an-Action - -.. _ActionCreate: - -Creating an action -================== - -**Goal:** Define an action in a ROS 2 package. - -**Tutorial level:** Intermediate - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -You learned about actions previously in the :doc:`../Beginner-CLI-Tools/Understanding-ROS2-Actions/Understanding-ROS2-Actions` tutorial. -Like the other communication types and their respective interfaces (topics/msg and services/srv), -you can also custom-define actions in your packages. -This tutorial shows you how to define and build an action that you can use -with the action server and action client you will write in the next tutorial. - -Prerequisites -------------- - -You should have :doc:`ROS 2 <../../Installation>` and `colcon `__ installed. - -You should know how to set up a :doc:`workspace <../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and create packages. - -Remember to :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` first. - -Tasks ------ - -1 Creating an interface package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src # you can reuse an existing workspace with this naming convention - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces - - .. group-tab:: Windows - - .. code-block:: console - - $ md \ros2_ws\src - $ cd \ros2_ws\src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces - -``custom_action_interfaces`` is the name of the new package. -Note that it is, and can only be, a CMake package, but this doesn't restrict in which type of packages you can use your actions. -The ``--build-type ament_cmake`` flag is largely optional when creating a new ROS 2 package but we are including it here for completeness. -You can create your own custom interfaces in a CMake package, and then use it in a C++ or Python node. - -.. note:: - - It is good practice to keep ``.msg``, ``.srv``, and ``.action`` files in separate packages from the nodes that use them. - This makes it easier to reuse the interface definitions across different packages. - - -2 Defining an action -^^^^^^^^^^^^^^^^^^^^ - -Actions are defined in ``.action`` files of the form: - -.. code-block:: bash - - # Request - --- - # Result - --- - # Feedback - -An action definition is made up of three message definitions separated by ``---``. - -- A *request* message is sent from an action client to an action server initiating a new goal. -- A *result* message is sent from an action server to an action client when a goal is done. -- *Feedback* messages are periodically sent from an action server to an action client with updates about a goal. - -An instance of an action is typically referred to as a *goal*. - -Say we want to define a new action "Fibonacci" for computing the `Fibonacci sequence `__. - -Create an ``action`` directory in our ROS 2 package ``custom_action_interfaces``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd custom_action_interfaces - $ mkdir action - - .. group-tab:: macOS - - .. code-block:: console - - $ cd custom_action_interfaces - $ mkdir action - - .. group-tab:: Windows - - .. code-block:: console - - $ cd custom_action_interfaces - $ md action - -Within the ``action`` directory, create a file called ``Fibonacci.action`` with the following contents: - -.. code-block:: bash - - int32 order - --- - int32[] sequence - --- - int32[] sequence - -The goal request is the ``order`` of the Fibonacci sequence we want to compute, the result is the final ``sequence``, and the feedback is the ``sequence`` computed so far. - -3 Building an action -^^^^^^^^^^^^^^^^^^^^ - -Before we can use the new Fibonacci action type in our code, we must pass the definition to the rosidl code generation pipeline. - -This is accomplished by adding the following lines to our ``CMakeLists.txt`` before the ``ament_package()`` line: - -.. code-block:: cmake - - find_package(rosidl_default_generators REQUIRED) - - rosidl_generate_interfaces(${PROJECT_NAME} - "action/Fibonacci.action" - ) - -We should also add the required dependencies to our ``package.xml``: - -.. code-block:: xml - - rosidl_default_generators - - rosidl_interface_packages - -We should now be able to build the package containing the ``Fibonacci`` action definition: - -.. code-block:: console - - $ cd ~/ros2_ws # Change to the root of the workspace - $ colcon build # Build - -We're done! - -By convention, action types will be prefixed by their package name and the word ``action``. -So when we want to refer to our new action, it will have the full name ``custom_action_interfaces/action/Fibonacci``. - -We can check that our action built successfully with the command line tool. -First source our workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/local_setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/local_setup.console - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\local_setup.bat - -Now check that our action definition exists: - -.. code-block:: console - - $ ros2 interface show custom_action_interfaces/action/Fibonacci - -You should see the Fibonacci action definition printed to the screen. - -Summary -------- - -In this tutorial, you learned the structure of an action definition. -You also learned how to correctly build a new action interface using ``CMakeLists.txt`` and ``package.xml``, -and how to verify a successful build. - -Next steps ----------- - -Next, let's utilize your newly defined action interface by creating an action service and client (in :doc:`Python ` or :doc:`C++ `). - -Related content ---------------- - -For more detailed information about ROS actions, please refer to the `design article `__. +.. redirect-from:: + + Tutorials/Actions/Creating-an-Action + Tutorials/Intermediate/Creating-an-Action + +.. _ActionCreate: + +Creating an action +================== + +**Goal:** Define an action in a ROS 2 package. + +**Tutorial level:** Intermediate + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +You learned about actions previously in the :doc:`Understanding-ROS2-Actions/Understanding-ROS2-Actions` tutorial. +Like the other communication types and their respective interfaces (topics/msg and services/srv), +you can also custom-define actions in your packages. +This tutorial shows you how to define and build an action that you can use +with the action server and action client you will write in the next tutorial. + +Prerequisites +------------- + +You should have :doc:`ROS 2 <../../../Get-Started/Installation>` and `colcon `__ installed. + +You should know how to set up a :doc:`workspace <../../client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and create packages. + +Remember to :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` first. + +Tasks +----- + +1 Creating an interface package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src # you can reuse an existing workspace with this naming convention + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces + + .. group-tab:: Windows + + .. code-block:: console + + $ md \ros2_ws\src + $ cd \ros2_ws\src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces + +``custom_action_interfaces`` is the name of the new package. +Note that it is, and can only be, a CMake package, but this doesn't restrict in which type of packages you can use your actions. +The ``--build-type ament_cmake`` flag is largely optional when creating a new ROS 2 package but we are including it here for completeness. +You can create your own custom interfaces in a CMake package, and then use it in a C++ or Python node. + +.. note:: + + It is good practice to keep ``.msg``, ``.srv``, and ``.action`` files in separate packages from the nodes that use them. + This makes it easier to reuse the interface definitions across different packages. + + +2 Defining an action +^^^^^^^^^^^^^^^^^^^^ + +Actions are defined in ``.action`` files of the form: + +.. code-block:: bash + + # Request + --- + # Result + --- + # Feedback + +An action definition is made up of three message definitions separated by ``---``. + +- A *request* message is sent from an action client to an action server initiating a new goal. +- A *result* message is sent from an action server to an action client when a goal is done. +- *Feedback* messages are periodically sent from an action server to an action client with updates about a goal. + +An instance of an action is typically referred to as a *goal*. + +Say we want to define a new action "Fibonacci" for computing the `Fibonacci sequence `__. + +Create an ``action`` directory in our ROS 2 package ``custom_action_interfaces``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd custom_action_interfaces + $ mkdir action + + .. group-tab:: macOS + + .. code-block:: console + + $ cd custom_action_interfaces + $ mkdir action + + .. group-tab:: Windows + + .. code-block:: console + + $ cd custom_action_interfaces + $ md action + +Within the ``action`` directory, create a file called ``Fibonacci.action`` with the following contents: + +.. code-block:: bash + + int32 order + --- + int32[] sequence + --- + int32[] sequence + +The goal request is the ``order`` of the Fibonacci sequence we want to compute, the result is the final ``sequence``, and the feedback is the ``sequence`` computed so far. + +3 Building an action +^^^^^^^^^^^^^^^^^^^^ + +Before we can use the new Fibonacci action type in our code, we must pass the definition to the rosidl code generation pipeline. + +This is accomplished by adding the following lines to our ``CMakeLists.txt`` before the ``ament_package()`` line: + +.. code-block:: cmake + + find_package(rosidl_default_generators REQUIRED) + + rosidl_generate_interfaces(${PROJECT_NAME} + "action/Fibonacci.action" + ) + +We should also add the required dependencies to our ``package.xml``: + +.. code-block:: xml + + rosidl_default_generators + + rosidl_interface_packages + +We should now be able to build the package containing the ``Fibonacci`` action definition: + +.. code-block:: console + + $ cd ~/ros2_ws # Change to the root of the workspace + $ colcon build # Build + +We're done! + +By convention, action types will be prefixed by their package name and the word ``action``. +So when we want to refer to our new action, it will have the full name ``custom_action_interfaces/action/Fibonacci``. + +We can check that our action built successfully with the command line tool. +First source our workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/local_setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/local_setup.console + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\local_setup.bat + +Now check that our action definition exists: + +.. code-block:: console + + $ ros2 interface show custom_action_interfaces/action/Fibonacci + +You should see the Fibonacci action definition printed to the screen. + +Summary +------- + +In this tutorial, you learned the structure of an action definition. +You also learned how to correctly build a new action interface using ``CMakeLists.txt`` and ``package.xml``, +and how to verify a successful build. + +Next steps +---------- + +Next, let's utilize your newly defined action interface by creating an action service and client (in :doc:`Python ` or :doc:`C++ `). + +Related content +--------------- + +For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst b/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst index b00f2290a38..553aba7b72a 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst +++ b/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst @@ -1,424 +1,425 @@ -.. redirect-from:: - - Tutorials/Understanding-ROS2-Actions - -.. _ROS2Actions: - -Understanding actions -===================== - -**Goal:** Introspect actions in ROS 2. - -**Tutorial level:** Beginner - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Actions are one of the communication types in ROS 2 and are intended for long running tasks. -They consist of three parts: a goal, feedback, and a result. - -Actions are built on topics and services. -Their functionality is similar to services, except actions can be canceled. -They also provide steady feedback, as opposed to services which return a single response. - -Actions use a client-server model, similar to the publisher-subscriber model (described in the :doc:`topics tutorial <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). -An "action client" node sends a goal to an "action server" node that acknowledges the goal and returns a stream of feedback and a result. - -.. image:: images/Action-SingleActionClient.gif - -Prerequisites -------------- - -This tutorial builds off concepts, like :doc:`nodes <../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`topics <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, covered in previous tutorials. - -This tutorial uses the :doc:`turtlesim package <../Introducing-Turtlesim/Introducing-Turtlesim>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ - -Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - - -2 Use actions -^^^^^^^^^^^^^ - -When you launch the ``/teleop_turtle`` node, you will see the following message in your terminal: - -.. code-block:: console - - Use arrow keys to move the turtle. - Use G|B|V|C|D|E|R|T keys to rotate to absolute orientations. 'F' to cancel a rotation. - -Let's focus on the second line, which corresponds to an action. -(The first instruction corresponds to the "cmd_vel" topic, discussed previously in the :doc:`topics tutorial <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`.) - -Notice that the letter keys ``G|B|V|C|D|E|R|T`` form a "box" around the ``F`` key on a US QWERTY keyboard (if you are not using a QWERTY keyboard, see `this link `__ to follow along). -Each key's position around ``F`` corresponds to that orientation in turtlesim. -For example, the ``E`` will rotate the turtle's orientation to the upper left corner. - -Pay attention to the terminal where the ``/turtlesim`` node is running. -Each time you press one of these keys, you are sending a goal to an action server that is part of the ``/turtlesim`` node. -The goal is to rotate the turtle to face a particular direction. -A message relaying the result of the goal should display once the turtle completes its rotation: - -.. code-block:: console - - [INFO] [turtlesim]: Rotation goal completed successfully - -The ``F`` key will cancel a goal mid-execution. - -Try pressing the ``C`` key, and then pressing the ``F`` key before the turtle can complete its rotation. -In the terminal where the ``/turtlesim`` node is running, you will see the message: - -.. code-block:: console - - [INFO] [turtlesim]: Rotation goal canceled - -Not only can the client-side (your input in the teleop) stop a goal, but the server-side (the ``/turtlesim`` node) can as well. -When the server-side chooses to stop processing a goal, it is said to "abort" the goal. - -Try hitting the ``D`` key, then the ``G`` key before the first rotation can complete. -In the terminal where the ``/turtlesim`` node is running, you will see the message: - -.. code-block:: console - - [WARN] [turtlesim]: Rotation goal received before a previous goal finished. Aborting previous goal - -This action server chose to abort the first goal because it got a new one. -It could have chosen something else, like reject the new goal or execute the second goal after the first one finished. -Don't assume every action server will choose to abort the current goal when it gets a new one. - -3 ros2 node info -^^^^^^^^^^^^^^^^ - -To see the list of actions a node provides, ``/turtlesim`` in this case, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 node info /turtlesim - /turtlesim - Subscribers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /turtle1/cmd_vel: geometry_msgs/msg/Twist - Publishers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /rosout: rcl_interfaces/msg/Log - /turtle1/color_sensor: turtlesim_msgs/msg/Color - /turtle1/pose: turtlesim_msgs/msg/Pose - Service Servers: - /clear: std_srvs/srv/Empty - /kill: turtlesim_msgs/srv/Kill - /reset: std_srvs/srv/Empty - /spawn: turtlesim_msgs/srv/Spawn - /turtle1/set_pen: turtlesim_msgs/srv/SetPen - /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute - /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative - /turtlesim/describe_parameters: rcl_interfaces/srv/DescribeParameters - /turtlesim/get_parameter_types: rcl_interfaces/srv/GetParameterTypes - /turtlesim/get_parameters: rcl_interfaces/srv/GetParameters - /turtlesim/list_parameters: rcl_interfaces/srv/ListParameters - /turtlesim/set_parameters: rcl_interfaces/srv/SetParameters - /turtlesim/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically - Service Clients: - - Action Servers: - /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute - Action Clients: - -The command returns a list of ``/turtlesim``'s subscribers, publishers, services, action servers and action clients. - -Notice that the ``/turtle1/rotate_absolute`` action for ``/turtlesim`` is under ``Action Servers``. -This means ``/turtlesim`` responds to and provides feedback for the ``/turtle1/rotate_absolute`` action. - -The ``/teleop_turtle`` node has the name ``/turtle1/rotate_absolute`` under ``Action Clients`` meaning that it sends goals for that action name. -To see that, run: - -.. code-block:: console - - $ ros2 node info /teleop_turtle - /teleop_turtle - Subscribers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - Publishers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /rosout: rcl_interfaces/msg/Log - /turtle1/cmd_vel: geometry_msgs/msg/Twist - Service Servers: - /teleop_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters - /teleop_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes - /teleop_turtle/get_parameters: rcl_interfaces/srv/GetParameters - /teleop_turtle/list_parameters: rcl_interfaces/srv/ListParameters - /teleop_turtle/set_parameters: rcl_interfaces/srv/SetParameters - /teleop_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically - Service Clients: - - Action Servers: - - Action Clients: - /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute - -4 ros2 action list -^^^^^^^^^^^^^^^^^^ - -To identify all the actions in the ROS graph, run the command: - -.. code-block:: console - - $ ros2 action list - /turtle1/rotate_absolute - -This is the only action in the ROS graph right now. -It controls the turtle's rotation, as you saw earlier. -You also already know that there is one action client (part of ``/teleop_turtle``) and one action server (part of ``/turtlesim``) for this action from using the ``ros2 node info `` command. - -4.1 ros2 action list -t -~~~~~~~~~~~~~~~~~~~~~~~ - -Actions have types, similar to topics and services. -To find ``/turtle1/rotate_absolute``'s type, run the command: - -.. code-block:: console - - $ ros2 action list -t - /turtle1/rotate_absolute [turtlesim_msgs/action/RotateAbsolute] - -In brackets to the right of each action name (in this case only ``/turtle1/rotate_absolute``) is the action type, ``turtlesim_msgs/action/RotateAbsolute``. -You will need this when you want to execute an action from the command line or from code. - -5 ros2 action type -^^^^^^^^^^^^^^^^^^ - -If you want to check the action type for the action, run the command: - -.. code-block:: console - - $ ros2 action type /turtle1/rotate_absolute - turtlesim_msgs/action/RotateAbsolute - -6 ros2 action info -^^^^^^^^^^^^^^^^^^ - -You can further introspect the ``/turtle1/rotate_absolute`` action with the command: - -.. code-block:: console - - $ ros2 action info /turtle1/rotate_absolute - Action: /turtle1/rotate_absolute - Action clients: 1 - /teleop_turtle - Action servers: 1 - /turtlesim - -This tells us what we learned earlier from running ``ros2 node info`` on each node: -The ``/teleop_turtle`` node has an action client and the ``/turtlesim`` node has an action server for the ``/turtle1/rotate_absolute`` action. - -7 ros2 interface show -^^^^^^^^^^^^^^^^^^^^^ - -One more piece of information you will need before sending or executing an action goal yourself is the structure of the action type. - -Recall that you identified ``/turtle1/rotate_absolute``'s type when running the command ``ros2 action list -t``. -Enter the following command with the action type in your terminal: - -.. code-block:: console - - $ ros2 interface show turtlesim_msgs/action/RotateAbsolute - -Which will return: - -.. code-block:: text - - # The desired heading in radians - float32 theta - --- - # The angular displacement in radians to the starting position - float32 delta - --- - # The remaining rotation in radians - float32 remaining - -The section of this message above the first ``---`` is the structure (data type and name) of the goal request. -The next section is the structure of the result. -The last section is the structure of the feedback. - -8 ros2 action send_goal -^^^^^^^^^^^^^^^^^^^^^^^ - -Now let's send an action goal from the command line with the following syntax: - -.. code-block:: console - - $ ros2 action send_goal - -```` need to be in YAML format. - -Keep an eye on the turtlesim window, and enter the following command into your terminal: - -.. code-block:: console - - $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: 1.57}" - Waiting for an action server to become available... - Sending goal: - theta: 1.57 - - Goal accepted with ID: f8db8f44410849eaa93d3feb747dd444 - - Result: - delta: -1.568000316619873 - - Goal finished with status: SUCCEEDED - - -You should see the turtle rotating. - - -All goals have a unique ID, shown in the return message. -You can also see the result, a field with the name ``delta``, which is the displacement to the starting position. - -To see the feedback of this goal, add ``--feedback`` to the ``ros2 action send_goal`` command: - -.. code-block:: console - - $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: -1.57}" --feedback - Sending goal: - theta: -1.57 - - Goal accepted with ID: e6092c831f994afda92f0086f220da27 - - Feedback: - remaining: -3.1268222332000732 - - Feedback: - remaining: -3.1108222007751465 - - … - - Result: - delta: 3.1200008392333984 - - Goal finished with status: SUCCEEDED - -You will continue to receive feedback, the remaining radians, until the goal is complete. - -.. _understanding-actions-ros2-action-echo: - -9 ros2 action echo -^^^^^^^^^^^^^^^^^^ - -To see the data communication between an action client and an action server you can ``echo`` the action data using: - -.. code-block:: console - - $ ros2 action echo - -``ros2 action echo`` depends on action introspection of an action client and server, that is disabled by default. -To enable it, users must call ``configure_introspection`` after creating an action client or server. - -Start up the ``fibonacci_action_server`` and ``fibonacci_action_client``, enabling ``action_server_configure_introspection`` parameter for demonstration. - -.. code-block:: console - - $ ros2 run action_tutorials_cpp fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents - -.. code-block:: console - - $ ros2 run action_tutorials_py fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents - -Now we are able to see the action communication between ``fibonacci_action_server`` and ``fibonacci_action_client`` via ``ros2 action echo``. - -.. code-block:: console - - $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style - interface: GOAL_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 400435819 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1742070798 - nanosec: 400706446 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: RESULT_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 401486678 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] - response: [] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] - --- - ... - -.. note:: - - This feature is available on ``Kilted Kaiju`` or later. - -Summary -------- - -Actions are like services that allow you to execute long running tasks, provide regular feedback, and are cancelable. - -A robot system would likely use actions for navigation. -An action goal could tell a robot to travel to a position. -While the robot navigates to the position, it can send updates along the way (i.e. feedback), and then a final result message once it's reached its destination. - -Turtlesim has an action server that action clients can send goals to for rotating turtles. -In this tutorial, you introspected that action, ``/turtle1/rotate_absolute``, to get a better idea of what actions are and how they work. - -Next steps ----------- - -Now you've covered all of the core ROS 2 concepts. -The last few tutorials in this set will introduce you to some tools and techniques that will make using ROS 2 easier, starting with :doc:`../Using-Rqt-Console/Using-Rqt-Console`. - -Related content ---------------- - -You can read more about the design decisions behind actions in ROS 2 `here `__. +.. redirect-from:: + + Tutorials/Understanding-ROS2-Actions + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Actions/Understanding-ROS2-Actions + +.. _ROS2Actions: + +Understanding actions +===================== + +**Goal:** Introspect actions in ROS 2. + +**Tutorial level:** Beginner + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Actions are one of the communication types in ROS 2 and are intended for long running tasks. +They consist of three parts: a goal, feedback, and a result. + +Actions are built on topics and services. +Their functionality is similar to services, except actions can be canceled. +They also provide steady feedback, as opposed to services which return a single response. + +Actions use a client-server model, similar to the publisher-subscriber model (described in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). +An "action client" node sends a goal to an "action server" node that acknowledges the goal and returns a stream of feedback and a result. + +.. image:: images/Action-SingleActionClient.gif + +Prerequisites +------------- + +This tutorial builds off concepts, like :doc:`nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, covered in previous tutorials. + +This tutorial uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ + +Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + + +2 Use actions +^^^^^^^^^^^^^ + +When you launch the ``/teleop_turtle`` node, you will see the following message in your terminal: + +.. code-block:: console + + Use arrow keys to move the turtle. + Use G|B|V|C|D|E|R|T keys to rotate to absolute orientations. 'F' to cancel a rotation. + +Let's focus on the second line, which corresponds to an action. +(The first instruction corresponds to the "cmd_vel" topic, discussed previously in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`.) + +Notice that the letter keys ``G|B|V|C|D|E|R|T`` form a "box" around the ``F`` key on a US QWERTY keyboard (if you are not using a QWERTY keyboard, see `this link `__ to follow along). +Each key's position around ``F`` corresponds to that orientation in turtlesim. +For example, the ``E`` will rotate the turtle's orientation to the upper left corner. + +Pay attention to the terminal where the ``/turtlesim`` node is running. +Each time you press one of these keys, you are sending a goal to an action server that is part of the ``/turtlesim`` node. +The goal is to rotate the turtle to face a particular direction. +A message relaying the result of the goal should display once the turtle completes its rotation: + +.. code-block:: console + + [INFO] [turtlesim]: Rotation goal completed successfully + +The ``F`` key will cancel a goal mid-execution. + +Try pressing the ``C`` key, and then pressing the ``F`` key before the turtle can complete its rotation. +In the terminal where the ``/turtlesim`` node is running, you will see the message: + +.. code-block:: console + + [INFO] [turtlesim]: Rotation goal canceled + +Not only can the client-side (your input in the teleop) stop a goal, but the server-side (the ``/turtlesim`` node) can as well. +When the server-side chooses to stop processing a goal, it is said to "abort" the goal. + +Try hitting the ``D`` key, then the ``G`` key before the first rotation can complete. +In the terminal where the ``/turtlesim`` node is running, you will see the message: + +.. code-block:: console + + [WARN] [turtlesim]: Rotation goal received before a previous goal finished. Aborting previous goal + +This action server chose to abort the first goal because it got a new one. +It could have chosen something else, like reject the new goal or execute the second goal after the first one finished. +Don't assume every action server will choose to abort the current goal when it gets a new one. + +3 ros2 node info +^^^^^^^^^^^^^^^^ + +To see the list of actions a node provides, ``/turtlesim`` in this case, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 node info /turtlesim + /turtlesim + Subscribers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /turtle1/cmd_vel: geometry_msgs/msg/Twist + Publishers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /rosout: rcl_interfaces/msg/Log + /turtle1/color_sensor: turtlesim_msgs/msg/Color + /turtle1/pose: turtlesim_msgs/msg/Pose + Service Servers: + /clear: std_srvs/srv/Empty + /kill: turtlesim_msgs/srv/Kill + /reset: std_srvs/srv/Empty + /spawn: turtlesim_msgs/srv/Spawn + /turtle1/set_pen: turtlesim_msgs/srv/SetPen + /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute + /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative + /turtlesim/describe_parameters: rcl_interfaces/srv/DescribeParameters + /turtlesim/get_parameter_types: rcl_interfaces/srv/GetParameterTypes + /turtlesim/get_parameters: rcl_interfaces/srv/GetParameters + /turtlesim/list_parameters: rcl_interfaces/srv/ListParameters + /turtlesim/set_parameters: rcl_interfaces/srv/SetParameters + /turtlesim/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically + Service Clients: + + Action Servers: + /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute + Action Clients: + +The command returns a list of ``/turtlesim``'s subscribers, publishers, services, action servers and action clients. + +Notice that the ``/turtle1/rotate_absolute`` action for ``/turtlesim`` is under ``Action Servers``. +This means ``/turtlesim`` responds to and provides feedback for the ``/turtle1/rotate_absolute`` action. + +The ``/teleop_turtle`` node has the name ``/turtle1/rotate_absolute`` under ``Action Clients`` meaning that it sends goals for that action name. +To see that, run: + +.. code-block:: console + + $ ros2 node info /teleop_turtle + /teleop_turtle + Subscribers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + Publishers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /rosout: rcl_interfaces/msg/Log + /turtle1/cmd_vel: geometry_msgs/msg/Twist + Service Servers: + /teleop_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters + /teleop_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes + /teleop_turtle/get_parameters: rcl_interfaces/srv/GetParameters + /teleop_turtle/list_parameters: rcl_interfaces/srv/ListParameters + /teleop_turtle/set_parameters: rcl_interfaces/srv/SetParameters + /teleop_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically + Service Clients: + + Action Servers: + + Action Clients: + /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute + +4 ros2 action list +^^^^^^^^^^^^^^^^^^ + +To identify all the actions in the ROS graph, run the command: + +.. code-block:: console + + $ ros2 action list + /turtle1/rotate_absolute + +This is the only action in the ROS graph right now. +It controls the turtle's rotation, as you saw earlier. +You also already know that there is one action client (part of ``/teleop_turtle``) and one action server (part of ``/turtlesim``) for this action from using the ``ros2 node info `` command. + +4.1 ros2 action list -t +~~~~~~~~~~~~~~~~~~~~~~~ + +Actions have types, similar to topics and services. +To find ``/turtle1/rotate_absolute``'s type, run the command: + +.. code-block:: console + + $ ros2 action list -t + /turtle1/rotate_absolute [turtlesim_msgs/action/RotateAbsolute] + +In brackets to the right of each action name (in this case only ``/turtle1/rotate_absolute``) is the action type, ``turtlesim_msgs/action/RotateAbsolute``. +You will need this when you want to execute an action from the command line or from code. + +5 ros2 action type +^^^^^^^^^^^^^^^^^^ + +If you want to check the action type for the action, run the command: + +.. code-block:: console + + $ ros2 action type /turtle1/rotate_absolute + turtlesim_msgs/action/RotateAbsolute + +6 ros2 action info +^^^^^^^^^^^^^^^^^^ + +You can further introspect the ``/turtle1/rotate_absolute`` action with the command: + +.. code-block:: console + + $ ros2 action info /turtle1/rotate_absolute + Action: /turtle1/rotate_absolute + Action clients: 1 + /teleop_turtle + Action servers: 1 + /turtlesim + +This tells us what we learned earlier from running ``ros2 node info`` on each node: +The ``/teleop_turtle`` node has an action client and the ``/turtlesim`` node has an action server for the ``/turtle1/rotate_absolute`` action. + +7 ros2 interface show +^^^^^^^^^^^^^^^^^^^^^ + +One more piece of information you will need before sending or executing an action goal yourself is the structure of the action type. + +Recall that you identified ``/turtle1/rotate_absolute``'s type when running the command ``ros2 action list -t``. +Enter the following command with the action type in your terminal: + +.. code-block:: console + + $ ros2 interface show turtlesim_msgs/action/RotateAbsolute + +Which will return: + +.. code-block:: text + + # The desired heading in radians + float32 theta + --- + # The angular displacement in radians to the starting position + float32 delta + --- + # The remaining rotation in radians + float32 remaining + +The section of this message above the first ``---`` is the structure (data type and name) of the goal request. +The next section is the structure of the result. +The last section is the structure of the feedback. + +8 ros2 action send_goal +^^^^^^^^^^^^^^^^^^^^^^^ + +Now let's send an action goal from the command line with the following syntax: + +.. code-block:: console + + $ ros2 action send_goal + +```` need to be in YAML format. + +Keep an eye on the turtlesim window, and enter the following command into your terminal: + +.. code-block:: console + + $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: 1.57}" + Waiting for an action server to become available... + Sending goal: + theta: 1.57 + + Goal accepted with ID: f8db8f44410849eaa93d3feb747dd444 + + Result: + delta: -1.568000316619873 + + Goal finished with status: SUCCEEDED + + +You should see the turtle rotating. + + +All goals have a unique ID, shown in the return message. +You can also see the result, a field with the name ``delta``, which is the displacement to the starting position. + +To see the feedback of this goal, add ``--feedback`` to the ``ros2 action send_goal`` command: + +.. code-block:: console + + $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: -1.57}" --feedback + Sending goal: + theta: -1.57 + + Goal accepted with ID: e6092c831f994afda92f0086f220da27 + + Feedback: + remaining: -3.1268222332000732 + + Feedback: + remaining: -3.1108222007751465 + + … + + Result: + delta: 3.1200008392333984 + + Goal finished with status: SUCCEEDED + +You will continue to receive feedback, the remaining radians, until the goal is complete. + +.. _understanding-actions-ros2-action-echo: + +9 ros2 action echo +^^^^^^^^^^^^^^^^^^ + +To see the data communication between an action client and an action server you can ``echo`` the action data using: + +.. code-block:: console + + $ ros2 action echo + +``ros2 action echo`` depends on action introspection of an action client and server, that is disabled by default. +To enable it, users must call ``configure_introspection`` after creating an action client or server. + +Start up the ``fibonacci_action_server`` and ``fibonacci_action_client``, enabling ``action_server_configure_introspection`` parameter for demonstration. + +.. code-block:: console + + $ ros2 run action_tutorials_cpp fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents + +.. code-block:: console + + $ ros2 run action_tutorials_py fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents + +Now we are able to see the action communication between ``fibonacci_action_server`` and ``fibonacci_action_client`` via ``ros2 action echo``. + +.. code-block:: console + + $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style + interface: GOAL_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 400435819 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1742070798 + nanosec: 400706446 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: RESULT_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 401486678 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] + response: [] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] + --- + ... + +.. note:: + + This feature is available on ``Kilted Kaiju`` or later. + +Summary +------- + +Actions are like services that allow you to execute long running tasks, provide regular feedback, and are cancelable. + +A robot system would likely use actions for navigation. +An action goal could tell a robot to travel to a position. +While the robot navigates to the position, it can send updates along the way (i.e. feedback), and then a final result message once it's reached its destination. + +Turtlesim has an action server that action clients can send goals to for rotating turtles. +In this tutorial, you introspected that action, ``/turtle1/rotate_absolute``, to get a better idea of what actions are and how they work. + +Next steps +---------- + +Now you've covered all of the core ROS 2 concepts. +The last few tutorials in this set will introduce you to some tools and techniques that will make using ROS 2 easier, starting with :doc:`../../../nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console`. + +Related content +--------------- + +You can read more about the design decisions behind actions in ROS 2 `here `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst b/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst index 603b0a73db0..15e1e613fc7 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst +++ b/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst @@ -1,398 +1,399 @@ -.. redirect-from:: - - Tutorials/Actions/Writing-a-Cpp-Action-Server-Client - -.. _ActionsCpp: - -Writing an action server and client (C++) -========================================= - -**Goal:** Implement an action server and client in C++. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Actions are a form of asynchronous communication in ROS. -*Action clients* send goal requests to *action servers*. -*Action servers* send goal feedback and results to *action clients*. - -Prerequisites -------------- - -You will need the ``custom_action_interfaces`` package and the ``Fibonacci.action`` -interface defined in the previous tutorial, :doc:`../Creating-an-Action`. - -Tasks ------ - -1 Creating the custom_action_cpp package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As we saw in the :doc:`../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package` tutorial, we need to create a new package to hold our C++ and supporting code. - -1.1 Creating the custom_action_cpp package -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Go into the action workspace you created in the :doc:`previous tutorial <../Creating-an-Action>` (remember to source the workspace), and create a new package for the C++ action server: - - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws/src - $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws/src - $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_ws\src - $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp - -1.2 Adding in visibility control -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to make the package compile and work on Windows, we need to add in some "visibility control". -For more details, see :ref:`Windows Symbol Visibility in the Windows Tips and Tricks document `. - -Open up ``custom_action_cpp/include/custom_action_cpp/visibility_control.h``, and put the following code in: - -.. code-block:: c++ - - #ifndef CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ - #define CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ - - #ifdef __cplusplus - extern "C" - { - #endif - - // This logic was borrowed (then namespaced) from the examples on the gcc wiki: - // https://gcc.gnu.org/wiki/Visibility - - #if defined _WIN32 || defined __CYGWIN__ - #ifdef __GNUC__ - #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((dllexport)) - #define CUSTOM_ACTION_CPP_IMPORT __attribute__ ((dllimport)) - #else - #define CUSTOM_ACTION_CPP_EXPORT __declspec(dllexport) - #define CUSTOM_ACTION_CPP_IMPORT __declspec(dllimport) - #endif - #ifdef CUSTOM_ACTION_CPP_BUILDING_DLL - #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_EXPORT - #else - #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_IMPORT - #endif - #define CUSTOM_ACTION_CPP_PUBLIC_TYPE CUSTOM_ACTION_CPP_PUBLIC - #define CUSTOM_ACTION_CPP_LOCAL - #else - #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((visibility("default"))) - #define CUSTOM_ACTION_CPP_IMPORT - #if __GNUC__ >= 4 - #define CUSTOM_ACTION_CPP_PUBLIC __attribute__ ((visibility("default"))) - #define CUSTOM_ACTION_CPP_LOCAL __attribute__ ((visibility("hidden"))) - #else - #define CUSTOM_ACTION_CPP_PUBLIC - #define CUSTOM_ACTION_CPP_LOCAL - #endif - #define CUSTOM_ACTION_CPP_PUBLIC_TYPE - #endif - - #ifdef __cplusplus - } - #endif - - #endif // CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ - -2 Writing an action server -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's focus on writing an action server that computes the Fibonacci sequence using the action we created in the :doc:`../Creating-an-Action` tutorial. - -2.1 Writing the action server code -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Open up ``custom_action_cpp/src/fibonacci_action_server.cpp``, and put the following code in: - -.. literalinclude:: scripts/server.cpp - :language: c++ - -The first few lines include all of the headers we need to compile. - -Next we create a class that is a derived class of ``rclcpp::Node``: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 14 - -The constructor for the ``FibonacciActionServer`` class initializes the node name as ``fibonacci_action_server``: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 21-22 - -The constructor also instantiates a new action server: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 52-57 - -An action server requires 6 things: - -1. The templated action type name: ``Fibonacci``. -2. A ROS 2 node to add the action to: ``this``. -3. The action name: ``'fibonacci'``. -4. A callback function for handling goals: ``handle_goal`` -5. A callback function for handling cancellation: ``handle_cancel``. -6. A callback function for handling goal accept: ``handle_accept``. - -The implementation of the various callbacks is done with `lambda expressions `_ within the constructor. -Note that all of the callbacks need to return quickly, otherwise we risk starving the executor. - -We start with the callback for handling new goals: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 26-33 - -This implementation just accepts all goals. - -Next up is the callback for dealing with cancellation: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 35-41 - -This implementation just tells the client that it accepted the cancellation. - -The last of the callbacks accepts a new goal and starts processing it: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 43-50 - -Since the execution is a long-running operation, we spawn off a thread to do the actual work and return from ``handle_accepted`` quickly. - -All further processing and updates are done in the ``execute`` method in the new thread: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 63-96 - -This work thread processes one sequence number of the Fibonacci sequence every second, publishing a feedback update for each step. -When it has finished processing, it marks the ``goal_handle`` as succeeded, and quits. - -We now have a fully functioning action server. -Let's get it built and running. - -2.2 Compiling the action server -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the previous section we put the action server code into place. -To get it to compile and run, we need to do a couple of additional things. - -First we need to setup the CMakeLists.txt so that the action server is compiled. -Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: - -.. code-block:: cmake - - add_library(action_server SHARED - src/fibonacci_action_server.cpp) - target_include_directories(action_server PRIVATE - $ - $) - target_compile_definitions(action_server - PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") - target_link_libraries(action_server PUBLIC - custom_action_interfaces::custom_action_interfaces - rclcpp::rclcpp - rclcpp_action::rclcpp_action - rclcpp_components::component) - rclcpp_components_register_node(action_server PLUGIN "custom_action_cpp::FibonacciActionServer" EXECUTABLE fibonacci_action_server) - install(TARGETS - action_server - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin) - -And now we can compile the package. -Go to the top-level of the ``ros2_ws``, and run: - -.. code-block:: console - - $ colcon build - -This should compile the entire workspace, including the ``fibonacci_action_server`` in the ``custom_action_cpp`` package. - -2.3 Running the action server -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now that we have the action server built, we can run it. -Source the workspace we just built (``ros2_ws``), and try to run the action server: - -.. code-block:: console - - $ ros2 run custom_action_cpp fibonacci_action_server - -3 Writing an action client -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -3.1 Writing the action client code -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Open up ``custom_action_cpp/src/fibonacci_action_client.cpp``, and put the following code in: - -.. literalinclude:: scripts/client.cpp - :language: c++ - -The first few lines include all of the headers we need to compile. - -Next we create a class that is a derived class of ``rclcpp::Node``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 15 - -The constructor for the ``FibonacciActionClient`` class initializes the node name as ``fibonacci_action_client``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 20-22 - -The constructor also instantiates a new action client: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 24-26 - -An action client requires 3 things: - -1. The templated action type name: ``Fibonacci``. -2. A ROS 2 node to add the action client to: ``this``. -3. The action name: ``'fibonacci'``. - -We also instantiate a ROS timer that will kick off the one and only call to ``send_goal``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 28-31 - -When the timer expires, it will call ``send_goal``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 34-96 - -This function does the following: - -1. Cancels the timer (so it is only called once). -2. Waits for the action server to come up. -3. Instantiates a new ``Fibonacci::Goal``. -4. Sets the response, feedback, and result callbacks. -5. Sends the goal to the server. - -When the server receives and accepts the goal, it will send a response to the client. -That response is handled by ``goal_response_callback``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 51-58 - -Assuming the goal was accepted by the server, it will start processing. -Any feedback to the client will be handled by the ``feedback_callback``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 60-70 - -When the server is finished processing, it will return a result to the client. -The result is handled by the ``result_callback``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 72-94 - -We now have a fully functioning action client. -Let's get it built and running. - -3.2 Compiling the action client -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the previous section we put the action client code into place. -To get it to compile and run, we need to do a couple of additional things. - -First we need to setup the CMakeLists.txt so that the action client is compiled. -Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: - -.. code-block:: cmake - - add_library(action_client SHARED - src/fibonacci_action_client.cpp) - target_include_directories(action_client PRIVATE - $ - $) - target_compile_definitions(action_client - PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") - target_link_libraries(action_client PUBLIC - custom_action_interfaces::custom_action_interfaces - rclcpp::rclcpp - rclcpp_action::rclcpp_action - rclcpp_components::component) - rclcpp_components_register_node(action_client PLUGIN "custom_action_cpp::FibonacciActionClient" EXECUTABLE fibonacci_action_client) - install(TARGETS - action_client - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin) - -And now we can compile the package. -Go to the top-level of the ``ros2_ws``, and run: - -.. code-block:: console - - $ colcon build - -This should compile the entire workspace, including the ``fibonacci_action_client`` in the ``custom_action_cpp`` package. - -3.3 Running the action client -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now that we have the action client built, we can run it. -First make sure that an action server is running in a separate terminal. -Now source the workspace we just built (``ros2_ws``), and try to run the action client: - -.. code-block:: console - - $ ros2 run custom_action_cpp fibonacci_action_client - -You should see logged messages for the goal being accepted, feedback being printed, and the final result. - -Summary -------- - -In this tutorial, you put together a C++ action server and action client line by line, and configured them to exchange goals, feedback, and results. - -Related content ---------------- - -* There are several ways you could write an action server and client in C++; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. - -* For more detailed information about ROS actions, please refer to the `design article `__. +.. redirect-from:: + + Tutorials/Actions/Writing-a-Cpp-Action-Server-Client + Tutorials/Intermediate/Writing-an-Action-Server-Client/Cpp + +.. _ActionsCpp: + +Writing an action server and client (C++) +========================================= + +**Goal:** Implement an action server and client in C++. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Actions are a form of asynchronous communication in ROS. +*Action clients* send goal requests to *action servers*. +*Action servers* send goal feedback and results to *action clients*. + +Prerequisites +------------- + +You will need the ``custom_action_interfaces`` package and the ``Fibonacci.action`` +interface defined in the previous tutorial, :doc:`../Creating-an-Action`. + +Tasks +----- + +1 Creating the custom_action_cpp package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As we saw in the :doc:`../../../client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` tutorial, we need to create a new package to hold our C++ and supporting code. + +1.1 Creating the custom_action_cpp package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Go into the action workspace you created in the :doc:`previous tutorial <../Creating-an-Action>` (remember to source the workspace), and create a new package for the C++ action server: + + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws/src + $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws/src + $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_ws\src + $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp + +1.2 Adding in visibility control +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to make the package compile and work on Windows, we need to add in some "visibility control". +For more details, see :ref:`Windows Symbol Visibility in the Windows Tips and Tricks document `. + +Open up ``custom_action_cpp/include/custom_action_cpp/visibility_control.h``, and put the following code in: + +.. code-block:: c++ + + #ifndef CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ + #define CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ + + #ifdef __cplusplus + extern "C" + { + #endif + + // This logic was borrowed (then namespaced) from the examples on the gcc wiki: + // https://gcc.gnu.org/wiki/Visibility + + #if defined _WIN32 || defined __CYGWIN__ + #ifdef __GNUC__ + #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((dllexport)) + #define CUSTOM_ACTION_CPP_IMPORT __attribute__ ((dllimport)) + #else + #define CUSTOM_ACTION_CPP_EXPORT __declspec(dllexport) + #define CUSTOM_ACTION_CPP_IMPORT __declspec(dllimport) + #endif + #ifdef CUSTOM_ACTION_CPP_BUILDING_DLL + #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_EXPORT + #else + #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_IMPORT + #endif + #define CUSTOM_ACTION_CPP_PUBLIC_TYPE CUSTOM_ACTION_CPP_PUBLIC + #define CUSTOM_ACTION_CPP_LOCAL + #else + #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((visibility("default"))) + #define CUSTOM_ACTION_CPP_IMPORT + #if __GNUC__ >= 4 + #define CUSTOM_ACTION_CPP_PUBLIC __attribute__ ((visibility("default"))) + #define CUSTOM_ACTION_CPP_LOCAL __attribute__ ((visibility("hidden"))) + #else + #define CUSTOM_ACTION_CPP_PUBLIC + #define CUSTOM_ACTION_CPP_LOCAL + #endif + #define CUSTOM_ACTION_CPP_PUBLIC_TYPE + #endif + + #ifdef __cplusplus + } + #endif + + #endif // CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ + +2 Writing an action server +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's focus on writing an action server that computes the Fibonacci sequence using the action we created in the :doc:`../Creating-an-Action` tutorial. + +2.1 Writing the action server code +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Open up ``custom_action_cpp/src/fibonacci_action_server.cpp``, and put the following code in: + +.. literalinclude:: scripts/server.cpp + :language: c++ + +The first few lines include all of the headers we need to compile. + +Next we create a class that is a derived class of ``rclcpp::Node``: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 14 + +The constructor for the ``FibonacciActionServer`` class initializes the node name as ``fibonacci_action_server``: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 21-22 + +The constructor also instantiates a new action server: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 52-57 + +An action server requires 6 things: + +1. The templated action type name: ``Fibonacci``. +2. A ROS 2 node to add the action to: ``this``. +3. The action name: ``'fibonacci'``. +4. A callback function for handling goals: ``handle_goal`` +5. A callback function for handling cancellation: ``handle_cancel``. +6. A callback function for handling goal accept: ``handle_accept``. + +The implementation of the various callbacks is done with `lambda expressions `_ within the constructor. +Note that all of the callbacks need to return quickly, otherwise we risk starving the executor. + +We start with the callback for handling new goals: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 26-33 + +This implementation just accepts all goals. + +Next up is the callback for dealing with cancellation: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 35-41 + +This implementation just tells the client that it accepted the cancellation. + +The last of the callbacks accepts a new goal and starts processing it: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 43-50 + +Since the execution is a long-running operation, we spawn off a thread to do the actual work and return from ``handle_accepted`` quickly. + +All further processing and updates are done in the ``execute`` method in the new thread: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 63-96 + +This work thread processes one sequence number of the Fibonacci sequence every second, publishing a feedback update for each step. +When it has finished processing, it marks the ``goal_handle`` as succeeded, and quits. + +We now have a fully functioning action server. +Let's get it built and running. + +2.2 Compiling the action server +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the previous section we put the action server code into place. +To get it to compile and run, we need to do a couple of additional things. + +First we need to setup the CMakeLists.txt so that the action server is compiled. +Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: + +.. code-block:: cmake + + add_library(action_server SHARED + src/fibonacci_action_server.cpp) + target_include_directories(action_server PRIVATE + $ + $) + target_compile_definitions(action_server + PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") + target_link_libraries(action_server PUBLIC + custom_action_interfaces::custom_action_interfaces + rclcpp::rclcpp + rclcpp_action::rclcpp_action + rclcpp_components::component) + rclcpp_components_register_node(action_server PLUGIN "custom_action_cpp::FibonacciActionServer" EXECUTABLE fibonacci_action_server) + install(TARGETS + action_server + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin) + +And now we can compile the package. +Go to the top-level of the ``ros2_ws``, and run: + +.. code-block:: console + + $ colcon build + +This should compile the entire workspace, including the ``fibonacci_action_server`` in the ``custom_action_cpp`` package. + +2.3 Running the action server +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now that we have the action server built, we can run it. +Source the workspace we just built (``ros2_ws``), and try to run the action server: + +.. code-block:: console + + $ ros2 run custom_action_cpp fibonacci_action_server + +3 Writing an action client +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +3.1 Writing the action client code +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Open up ``custom_action_cpp/src/fibonacci_action_client.cpp``, and put the following code in: + +.. literalinclude:: scripts/client.cpp + :language: c++ + +The first few lines include all of the headers we need to compile. + +Next we create a class that is a derived class of ``rclcpp::Node``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 15 + +The constructor for the ``FibonacciActionClient`` class initializes the node name as ``fibonacci_action_client``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 20-22 + +The constructor also instantiates a new action client: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 24-26 + +An action client requires 3 things: + +1. The templated action type name: ``Fibonacci``. +2. A ROS 2 node to add the action client to: ``this``. +3. The action name: ``'fibonacci'``. + +We also instantiate a ROS timer that will kick off the one and only call to ``send_goal``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 28-31 + +When the timer expires, it will call ``send_goal``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 34-96 + +This function does the following: + +1. Cancels the timer (so it is only called once). +2. Waits for the action server to come up. +3. Instantiates a new ``Fibonacci::Goal``. +4. Sets the response, feedback, and result callbacks. +5. Sends the goal to the server. + +When the server receives and accepts the goal, it will send a response to the client. +That response is handled by ``goal_response_callback``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 51-58 + +Assuming the goal was accepted by the server, it will start processing. +Any feedback to the client will be handled by the ``feedback_callback``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 60-70 + +When the server is finished processing, it will return a result to the client. +The result is handled by the ``result_callback``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 72-94 + +We now have a fully functioning action client. +Let's get it built and running. + +3.2 Compiling the action client +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the previous section we put the action client code into place. +To get it to compile and run, we need to do a couple of additional things. + +First we need to setup the CMakeLists.txt so that the action client is compiled. +Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: + +.. code-block:: cmake + + add_library(action_client SHARED + src/fibonacci_action_client.cpp) + target_include_directories(action_client PRIVATE + $ + $) + target_compile_definitions(action_client + PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") + target_link_libraries(action_client PUBLIC + custom_action_interfaces::custom_action_interfaces + rclcpp::rclcpp + rclcpp_action::rclcpp_action + rclcpp_components::component) + rclcpp_components_register_node(action_client PLUGIN "custom_action_cpp::FibonacciActionClient" EXECUTABLE fibonacci_action_client) + install(TARGETS + action_client + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin) + +And now we can compile the package. +Go to the top-level of the ``ros2_ws``, and run: + +.. code-block:: console + + $ colcon build + +This should compile the entire workspace, including the ``fibonacci_action_client`` in the ``custom_action_cpp`` package. + +3.3 Running the action client +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now that we have the action client built, we can run it. +First make sure that an action server is running in a separate terminal. +Now source the workspace we just built (``ros2_ws``), and try to run the action client: + +.. code-block:: console + + $ ros2 run custom_action_cpp fibonacci_action_client + +You should see logged messages for the goal being accepted, feedback being printed, and the final result. + +Summary +------- + +In this tutorial, you put together a C++ action server and action client line by line, and configured them to exchange goals, feedback, and results. + +Related content +--------------- + +* There are several ways you could write an action server and client in C++; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. + +* For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst b/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst index 0660fec441d..d9262e20e94 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst +++ b/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst @@ -1,364 +1,365 @@ -.. redirect-from:: - - Tutorials/Actions/Writing-a-Py-Action-Server-Client - -.. _ActionsPy: - -Writing an action server and client (Python) -============================================ - -**Goal:** Implement an action server and client in Python. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Actions are a form of asynchronous communication in ROS 2. -*Action clients* send goal requests to *action servers*. -*Action servers* send goal feedback and results to *action clients*. - -Prerequisites -------------- - -You will need the ``custom_action_interfaces`` package and the ``Fibonacci.action`` -interface defined in the previous tutorial, :doc:`../Creating-an-Action`. - -Tasks ------ - -1 Writing an action server -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's focus on writing an action server that computes the Fibonacci sequence -using the action we created in the :doc:`../Creating-an-Action` tutorial. - -Until now, you've created packages and used ``ros2 run`` to run your nodes. -To keep things simple in this tutorial, however, we'll scope the action server to a single file. -If you'd like to see what a complete package for the actions tutorials looks like, check out -`action_tutorials `__. - -Open a new file in your home directory, let's call it ``fibonacci_action_server.py``, -and add the following code: - -.. literalinclude:: scripts/server_0.py - :language: python - -Line 8 defines a class ``FibonacciActionServer`` that is a subclass of ``Node``. -The class is initialized by calling the ``Node`` constructor, naming our node ``fibonacci_action_server``: - -.. literalinclude:: scripts/server_0.py - :language: python - :lines: 12 - -In the constructor we also instantiate a new action server: - -.. literalinclude:: scripts/server_0.py - :language: python - :lines: 13-17 - -An action server requires four arguments: - -1. A ROS 2 node to add the action server to: ``self``. -2. The type of the action: ``Fibonacci`` (imported in line 5). -3. The action name: ``'fibonacci'``. -4. A callback function for executing accepted goals: ``self.execute_callback``. - This callback **must** return a result message for the action type. - -We also define an ``execute_callback`` method in our class: - -.. literalinclude:: scripts/server_0.py - :language: python - :lines: 19-22 - -This is the method that will be called to execute a goal once it is accepted. - -Let's try running our action server: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ python3 fibonacci_action_server.py - - .. group-tab:: macOS - - .. code-block:: console - - $ python3 fibonacci_action_server.py - - .. group-tab:: Windows - - .. code-block:: console - - $ python fibonacci_action_server.py - -In another terminal, we can use the command line interface to send a goal: - -.. code-block:: console - - $ ros2 action send_goal fibonacci custom_action_interfaces/action/Fibonacci "{order: 5}" - -In the terminal that is running the action server, you should see a logged message "Executing goal..." followed by a warning that the goal state was not set. -By default, if the goal handle state is not set in the execute callback it assumes the *aborted* state. - -We can call ``succeed()`` on the goal handle to indicate that the goal was successful: - -.. literalinclude:: scripts/server_1.py - :language: python - :lines: 19-23 - :emphasize-lines: 3 - -Now if you restart the action server and send another goal, you should see the goal finished with the status ``SUCCEEDED``. - -Now let's make our goal execution actually compute and return the requested Fibonacci sequence: - -.. literalinclude:: scripts/server_2.py - :language: python - :lines: 19-31 - :emphasize-lines: 4-7,12 - -After computing the sequence, we assign it to the result message field before returning. - -Again, restart the action server and send another goal. -You should see the goal finish with the proper result sequence. - -1.2 Publishing feedback -~~~~~~~~~~~~~~~~~~~~~~~ - -One of the nice things about actions is the ability to provide feedback to an action client during goal execution. -We can make our action server publish feedback for action clients by calling the goal handle's ``publish_feedback()`` method. - -We'll replace the ``sequence`` variable, and use a feedback message to store the sequence instead. -After every update of the feedback message in the for-loop, we publish the feedback message and sleep for dramatic effect: - -.. literalinclude:: scripts/server_3.py - :language: python - :emphasize-lines: 1,24,25,28-32,37 - -After restarting the action server, we can confirm that feedback is now published by using the command line tool with the ``--feedback`` option: - -.. code-block:: console - - $ ros2 action send_goal --feedback fibonacci custom_action_interfaces/action/Fibonacci "{order: 5}" - -2 Writing an action client -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -We'll also scope the action client to a single file. -Open a new file, let's call it ``fibonacci_action_client.py``, and add the following boilerplate code: - -.. literalinclude:: scripts/client_0.py - :language: python - -We've defined a class ``FibonacciActionClient`` that is a subclass of ``Node``. -The class is initialized by calling the ``Node`` constructor, naming our node ``fibonacci_action_client``: - -.. literalinclude:: scripts/client_0.py - :language: python - :lines: 12 - -Also in the class constructor, we create an action client using the custom action definition from the previous tutorial on :doc:`../Creating-an-Action`: - -.. literalinclude:: scripts/client_0.py - :language: python - :lines: 13 - -We create an ``ActionClient`` by passing it three arguments: - -1. A ROS 2 node to add the action client to: ``self`` -2. The type of the action: ``Fibonacci`` -3. The action name: ``'fibonacci'`` - -Our action client will be able to communicate with action servers of the same action name and type. - -We also define a method ``send_goal`` in the ``FibonacciActionClient`` class: - -.. literalinclude:: scripts/client_0.py - :language: python - :lines: 15-21 - -This method waits for the action server to be available, then sends a goal to the server. -It returns a future that we can later wait on. - -After the class definition, we define a function ``main()`` that initializes ROS 2 -and creates an instance of our ``FibonacciActionClient`` node. -It then sends a goal and waits until that goal has been completed. - -Finally, we call ``main()`` in the entry point of our Python program. - -Let's test our action client by first running the action server built earlier: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ python3 fibonacci_action_server.py - - .. group-tab:: macOS - - .. code-block:: console - - $ python3 fibonacci_action_server.py - - .. group-tab:: Windows - - .. code-block:: console - - $ python fibonacci_action_server.py - -In another terminal, run the action client. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ python3 fibonacci_action_client.py - - - .. group-tab:: macOS - - .. code-block:: console - - $ python3 fibonacci_action_client.py - - - .. group-tab:: Windows - - .. code-block:: console - - $ python fibonacci_action_client.py - -You should see messages printed by the action server as it successfully executes the goal: - -.. code-block:: console - - [INFO] [fibonacci_action_server]: Executing goal... - [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1]) - [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2]) - [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3]) - [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5]) - ~ etc. - -The action client should start up, and then quickly finish. -At this point, we have a functioning action client, but we don't see any results or get any feedback. - -2.1 Getting a result -~~~~~~~~~~~~~~~~~~~~ - -So we can send a goal, but how do we know when it is completed? -We can get the result information with a couple steps. -First, we need to get a goal handle for the goal we sent. -Then, we can use the goal handle to request the result. - -Here's the complete code for this example: - -.. literalinclude:: scripts/client_1.py - :language: python - -The ``ActionClient.send_goal_async()`` method returns a future to a goal handle. -First we register a callback for when the future is complete: - -.. literalinclude:: scripts/client_1.py - :language: python - :lines: 23 - -Note that the future is completed when an action server accepts or rejects the goal request. -Let's look at the ``goal_response_callback`` in more detail. -We can check to see if the goal was rejected and return early since we know there will be no result: - -.. literalinclude:: scripts/client_1.py - :language: python - :lines: 25-31 - -Now that we've got a goal handle, we can use it to request the result with the method ``get_result_async()``. -Similar to sending the goal, we will get a future that will complete when the result is ready. -Let's register a callback just like we did for the goal response: - -.. literalinclude:: scripts/client_1.py - :language: python - :lines: 33-34 - -In the callback, we log the result sequence and shutdown ROS 2 for a clean exit: - -.. literalinclude:: scripts/client_1.py - :language: python - :lines: 36-39 - -With an action server running in a separate terminal, go ahead and try running our Fibonacci action client! - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ python3 fibonacci_action_client.py - - .. group-tab:: macOS - - .. code-block:: console - - $ python3 fibonacci_action_client.py - - .. group-tab:: Windows - - .. code-block:: console - - $ python fibonacci_action_client.py - -You should see logged messages for the goal being accepted and the final result. - -2.2 Getting feedback -~~~~~~~~~~~~~~~~~~~~ - -Our action client can send goals. -Nice! -But it would be great if we could get some feedback about the goals we send from the action server. - -Here's the complete code for this example: - -.. literalinclude:: scripts/client_2.py - :language: python - -Here's the callback function for feedback messages: - -.. literalinclude:: scripts/client_2.py - :language: python - :lines: 41-43 - -In the callback we get the feedback portion of the message and print the ``sequence`` field to the screen. - -We need to register the callback with the action client. -This is achieved by additionally passing the callback to the action client when we send a goal: - -.. literalinclude:: scripts/client_2.py - :language: python - :lines: 21 - -We're all set. -If we run our action client, you should see feedback being printed to the screen. - -Summary -------- - -In this tutorial, you put together a Python action server and action client line by line, and configured them to exchange goals, feedback, and results. - -Related content ---------------- - -* There are several ways you could write an action server and client in Python; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. - -* For more detailed information about ROS actions, please refer to the `design article `__. +.. redirect-from:: + + Tutorials/Actions/Writing-a-Py-Action-Server-Client + Tutorials/Intermediate/Writing-an-Action-Server-Client/Py + +.. _ActionsPy: + +Writing an action server and client (Python) +============================================ + +**Goal:** Implement an action server and client in Python. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Actions are a form of asynchronous communication in ROS 2. +*Action clients* send goal requests to *action servers*. +*Action servers* send goal feedback and results to *action clients*. + +Prerequisites +------------- + +You will need the ``custom_action_interfaces`` package and the ``Fibonacci.action`` +interface defined in the previous tutorial, :doc:`../Creating-an-Action`. + +Tasks +----- + +1 Writing an action server +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's focus on writing an action server that computes the Fibonacci sequence +using the action we created in the :doc:`../Creating-an-Action` tutorial. + +Until now, you've created packages and used ``ros2 run`` to run your nodes. +To keep things simple in this tutorial, however, we'll scope the action server to a single file. +If you'd like to see what a complete package for the actions tutorials looks like, check out +`action_tutorials `__. + +Open a new file in your home directory, let's call it ``fibonacci_action_server.py``, +and add the following code: + +.. literalinclude:: scripts/server_0.py + :language: python + +Line 8 defines a class ``FibonacciActionServer`` that is a subclass of ``Node``. +The class is initialized by calling the ``Node`` constructor, naming our node ``fibonacci_action_server``: + +.. literalinclude:: scripts/server_0.py + :language: python + :lines: 12 + +In the constructor we also instantiate a new action server: + +.. literalinclude:: scripts/server_0.py + :language: python + :lines: 13-17 + +An action server requires four arguments: + +1. A ROS 2 node to add the action server to: ``self``. +2. The type of the action: ``Fibonacci`` (imported in line 5). +3. The action name: ``'fibonacci'``. +4. A callback function for executing accepted goals: ``self.execute_callback``. + This callback **must** return a result message for the action type. + +We also define an ``execute_callback`` method in our class: + +.. literalinclude:: scripts/server_0.py + :language: python + :lines: 19-22 + +This is the method that will be called to execute a goal once it is accepted. + +Let's try running our action server: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ python3 fibonacci_action_server.py + + .. group-tab:: macOS + + .. code-block:: console + + $ python3 fibonacci_action_server.py + + .. group-tab:: Windows + + .. code-block:: console + + $ python fibonacci_action_server.py + +In another terminal, we can use the command line interface to send a goal: + +.. code-block:: console + + $ ros2 action send_goal fibonacci custom_action_interfaces/action/Fibonacci "{order: 5}" + +In the terminal that is running the action server, you should see a logged message "Executing goal..." followed by a warning that the goal state was not set. +By default, if the goal handle state is not set in the execute callback it assumes the *aborted* state. + +We can call ``succeed()`` on the goal handle to indicate that the goal was successful: + +.. literalinclude:: scripts/server_1.py + :language: python + :lines: 19-23 + :emphasize-lines: 3 + +Now if you restart the action server and send another goal, you should see the goal finished with the status ``SUCCEEDED``. + +Now let's make our goal execution actually compute and return the requested Fibonacci sequence: + +.. literalinclude:: scripts/server_2.py + :language: python + :lines: 19-31 + :emphasize-lines: 4-7,12 + +After computing the sequence, we assign it to the result message field before returning. + +Again, restart the action server and send another goal. +You should see the goal finish with the proper result sequence. + +1.2 Publishing feedback +~~~~~~~~~~~~~~~~~~~~~~~ + +One of the nice things about actions is the ability to provide feedback to an action client during goal execution. +We can make our action server publish feedback for action clients by calling the goal handle's ``publish_feedback()`` method. + +We'll replace the ``sequence`` variable, and use a feedback message to store the sequence instead. +After every update of the feedback message in the for-loop, we publish the feedback message and sleep for dramatic effect: + +.. literalinclude:: scripts/server_3.py + :language: python + :emphasize-lines: 1,24,25,28-32,37 + +After restarting the action server, we can confirm that feedback is now published by using the command line tool with the ``--feedback`` option: + +.. code-block:: console + + $ ros2 action send_goal --feedback fibonacci custom_action_interfaces/action/Fibonacci "{order: 5}" + +2 Writing an action client +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +We'll also scope the action client to a single file. +Open a new file, let's call it ``fibonacci_action_client.py``, and add the following boilerplate code: + +.. literalinclude:: scripts/client_0.py + :language: python + +We've defined a class ``FibonacciActionClient`` that is a subclass of ``Node``. +The class is initialized by calling the ``Node`` constructor, naming our node ``fibonacci_action_client``: + +.. literalinclude:: scripts/client_0.py + :language: python + :lines: 12 + +Also in the class constructor, we create an action client using the custom action definition from the previous tutorial on :doc:`../Creating-an-Action`: + +.. literalinclude:: scripts/client_0.py + :language: python + :lines: 13 + +We create an ``ActionClient`` by passing it three arguments: + +1. A ROS 2 node to add the action client to: ``self`` +2. The type of the action: ``Fibonacci`` +3. The action name: ``'fibonacci'`` + +Our action client will be able to communicate with action servers of the same action name and type. + +We also define a method ``send_goal`` in the ``FibonacciActionClient`` class: + +.. literalinclude:: scripts/client_0.py + :language: python + :lines: 15-21 + +This method waits for the action server to be available, then sends a goal to the server. +It returns a future that we can later wait on. + +After the class definition, we define a function ``main()`` that initializes ROS 2 +and creates an instance of our ``FibonacciActionClient`` node. +It then sends a goal and waits until that goal has been completed. + +Finally, we call ``main()`` in the entry point of our Python program. + +Let's test our action client by first running the action server built earlier: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ python3 fibonacci_action_server.py + + .. group-tab:: macOS + + .. code-block:: console + + $ python3 fibonacci_action_server.py + + .. group-tab:: Windows + + .. code-block:: console + + $ python fibonacci_action_server.py + +In another terminal, run the action client. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ python3 fibonacci_action_client.py + + + .. group-tab:: macOS + + .. code-block:: console + + $ python3 fibonacci_action_client.py + + + .. group-tab:: Windows + + .. code-block:: console + + $ python fibonacci_action_client.py + +You should see messages printed by the action server as it successfully executes the goal: + +.. code-block:: console + + [INFO] [fibonacci_action_server]: Executing goal... + [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1]) + [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2]) + [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3]) + [INFO] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5]) + ~ etc. + +The action client should start up, and then quickly finish. +At this point, we have a functioning action client, but we don't see any results or get any feedback. + +2.1 Getting a result +~~~~~~~~~~~~~~~~~~~~ + +So we can send a goal, but how do we know when it is completed? +We can get the result information with a couple steps. +First, we need to get a goal handle for the goal we sent. +Then, we can use the goal handle to request the result. + +Here's the complete code for this example: + +.. literalinclude:: scripts/client_1.py + :language: python + +The ``ActionClient.send_goal_async()`` method returns a future to a goal handle. +First we register a callback for when the future is complete: + +.. literalinclude:: scripts/client_1.py + :language: python + :lines: 23 + +Note that the future is completed when an action server accepts or rejects the goal request. +Let's look at the ``goal_response_callback`` in more detail. +We can check to see if the goal was rejected and return early since we know there will be no result: + +.. literalinclude:: scripts/client_1.py + :language: python + :lines: 25-31 + +Now that we've got a goal handle, we can use it to request the result with the method ``get_result_async()``. +Similar to sending the goal, we will get a future that will complete when the result is ready. +Let's register a callback just like we did for the goal response: + +.. literalinclude:: scripts/client_1.py + :language: python + :lines: 33-34 + +In the callback, we log the result sequence and shutdown ROS 2 for a clean exit: + +.. literalinclude:: scripts/client_1.py + :language: python + :lines: 36-39 + +With an action server running in a separate terminal, go ahead and try running our Fibonacci action client! + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ python3 fibonacci_action_client.py + + .. group-tab:: macOS + + .. code-block:: console + + $ python3 fibonacci_action_client.py + + .. group-tab:: Windows + + .. code-block:: console + + $ python fibonacci_action_client.py + +You should see logged messages for the goal being accepted and the final result. + +2.2 Getting feedback +~~~~~~~~~~~~~~~~~~~~ + +Our action client can send goals. +Nice! +But it would be great if we could get some feedback about the goals we send from the action server. + +Here's the complete code for this example: + +.. literalinclude:: scripts/client_2.py + :language: python + +Here's the callback function for feedback messages: + +.. literalinclude:: scripts/client_2.py + :language: python + :lines: 41-43 + +In the callback we get the feedback portion of the message and print the ``sequence`` field to the screen. + +We need to register the callback with the action client. +This is achieved by additionally passing the callback to the action client when we send a goal: + +.. literalinclude:: scripts/client_2.py + :language: python + :lines: 21 + +We're all set. +If we run our action client, you should see feedback being printed to the screen. + +Summary +------- + +In this tutorial, you put together a Python action server and action client line by line, and configured them to exchange goals, feedback, and results. + +Related content +--------------- + +* There are several ways you could write an action server and client in Python; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. + +* For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst b/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst index 556f31051cb..a7972aaed9c 100644 --- a/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst +++ b/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst @@ -1,115 +1,116 @@ -.. redirect-from:: - - DDS-and-ROS-middleware-implementations - Concepts/About-Different-Middleware-Vendors - -Different ROS 2 middleware vendors -================================== - -.. contents:: Table of Contents - :local: - -ROS 2 supports multiple middleware implementations which provide discovery, serialisation, and transportation communications. -This flexibility exists because it is not necessarily "one size fits all" when it comes to choosing a middleware vendor/implementation. -While primarily built on top of DDS/RTPS as its initial middleware foundation, the ROS 2 ecosystem has expanded to include other middleware architectures such as Zenoh. - -DDS middleware --------------- - -`DDS `__ is an industry standard which is implemented by a range of vendors, such as RTI's `Connext DDS `__, eProsima's `Fast DDS `__, Eclipse's `Cyclone DDS `__, or GurumNetworks's `GurumDDS `__. -RTPS (a.k.a. `DDSI-RTPS `__\ ) is the wire protocol used by DDS to communicate over the network. - -`This article `__ explains the motivation behind using DDS implementations, and/or the RTPS wire protocol of DDS, in detail. -In summary, DDS is an end-to-end middleware that provides features which are relevant to ROS systems, such as distributed discovery (not centralized like in ROS 1) and control over different "Quality of Service" (a.k.a. QoS) options for the transportation. - -Zenoh middleware ----------------- - -`Zenoh `_ is a protocol that integrates internet-scale publish/subscribe with distributed querying. -It is designed for efficient communication in a wide range of deployments that vary from server-grade hardware and networks to resource-constrained edge devices. -Zenoh extends the privilege of location transparency to storage data, allowing queries to be addressed with no concerns about where the data is stored. - -As an RMW implementation for ROS 2, Zenoh offers a more lightweight alternative to DDS and maintains Quality of Service features (in Zenoh, there are essentially no "incompatible" QoS settings). -Its minimal wire overhead and flexible routing make Zenoh well-suited for challenging network conditions. - -Supported RMW implementations ------------------------------ - -.. list-table:: - :header-rows: 1 - - * - Product name - - License - - RMW implementation - - Status - * - eProsima *Fast DDS* - - Apache 2 - - ``rmw_fastrtps_cpp`` - - Full support. - Default RMW. - Packaged with binary releases. - * - Eclipse *Cyclone DDS* - - Eclipse Public License v2.0 - - ``rmw_cyclonedds_cpp`` - - Full support. - Packaged with binary releases. - * - RTI *Connext DDS* - - Commercial, research - - ``rmw_connextdds`` - - Full support. - Support included in binaries, but Connext installed separately. - * - GurumNetworks *GurumDDS* - - Commercial - - ``rmw_gurumdds_cpp`` - - Community support. - Support included in binaries, but GurumDDS installed separately. - * - Eclipse *Zenoh* - - Eclipse Public License v2.0 - - ``rmw_zenoh_cpp`` - - Full support. - Packaged with binary releases starting with Kilted Kaiju. - -For practical information on working with multiple RMW implementations, see the :doc:`"Working with multiple RMW implementations" <../../How-To-Guides/Working-with-multiple-RMW-implementations>` tutorial. - -Choosing a middleware implementation ------------------------------------- - -There are many factors you might consider while choosing a middleware implementation: logistical considerations like the license, or technical considerations like platform availability, resource utilisation, or computation footprint. -Vendors may provide more than one middleware implementation targeted at meeting different needs. - -For example, RTI has a few variations of their Connext implementation that vary in purpose, like one that specifically targets microcontrollers and another which targets applications requiring special safety certifications (we only support their standard desktop version at this time). -Eclipse offers both Cyclone DDS and Zenoh. -Cyclone DDS is one of the lighter DDS implementations, optimised for real-time deterministic communication, while Zenoh is designed for IoT and edge computing scenarios where high throughput, low latency, and interoperability across heterogeneous environments are primary concerns. - -In order to use a middleware implementation with ROS 2, a "\ **R**\ OS **M**\ iddle\ **w**\ are interface" (a.k.a. ``rmw`` interface or just ``rmw``\ ) package needs to be created that implements the abstract ROS middleware interface using that specific implementation's API and tools. -It's a lot of work to implement and maintain RMW packages for supporting various middleware implementations, but this diversity is important for ensuring that the ROS 2 codebase is not tied to any one particular implementation, as users may wish to switch out implementations depending on their project's needs. - -Multiple RMW implementations ----------------------------- - -The ROS 2 binary releases for currently active distros have built-in support for several RMW implementations out of the box (Fast DDS, RTI Connext Pro, Eclipse Cyclone DDS, GurumNetworks GurumDDS). -Beginning with ROS 2 Kilted Kaiju, this also includes Eclipse Zenoh. -The default is Fast DDS, which works without any additional installation steps because we distribute it with our binary packages. - -RMWs other than Fast DDS, like Cyclone DDS, Connext or GurumDDS can be enabled by :doc:`installing additional packages <../../Installation/RMW-Implementations>`, and without having to rebuild anything or replace any existing packages. - -A ROS 2 workspace that has been built from source may build and install multiple RMW implementations simultaneously. -While the core ROS 2 code is being compiled, any RMW implementation that is found will be built if the relevant middleware implementation has been installed properly and the relevant environment variables have been configured. -For example, if the code for the `RMW package for RTI Connext DDS `__ is in the workspace, it will be built if an installation of RTI's Connext Pro can also be found. - -If a ROS 2 workspace has multiple RMW implementations, Fast DDS is selected as the default RMW implementation if it is available. -If Fast DDS is not installed, the default middleware will be selected based on alphabetical order of the package identifiers. -The implementation identifier is the name of the ROS package that provides the RMW implementation, e.g. ``rmw_cyclonedds_cpp``. -For example, if both ``rmw_cyclonedds_cpp`` and ``rmw_connextdds`` ROS packages are installed, ``rmw_connextdds`` would be the default. -If ``rmw_fastrtps_cpp`` is ever installed, it would be the default. - -See the :doc:`guide <../../How-To-Guides/Working-with-multiple-RMW-implementations>` for how to specify which RMW implementation is to be used when running the ROS 2 examples. - -.. _different-middleware-vendors-cross-vendor-communication: - -Cross-Vendor Communication among DDS middleware ------------------------------------------------ - -For many cases you will find that nodes using different DDS middleware implementations are able to communicate, however this is not true under all circumstances. -While the different DDS implementations may be compatible in limited circumstances, this is not guaranteed. -Thus it is suggested that users ensure that all parts of a distributed system are using the same ROS version and the same RMW implementation. +.. redirect-from:: + + DDS-and-ROS-middleware-implementations + Concepts/About-Different-Middleware-Vendors + Concepts/Intermediate/About-Different-Middleware-Vendors + +Different ROS 2 middleware vendors +================================== + +.. contents:: Table of Contents + :local: + +ROS 2 supports multiple middleware implementations which provide discovery, serialisation, and transportation communications. +This flexibility exists because it is not necessarily "one size fits all" when it comes to choosing a middleware vendor/implementation. +While primarily built on top of DDS/RTPS as its initial middleware foundation, the ROS 2 ecosystem has expanded to include other middleware architectures such as Zenoh. + +DDS middleware +-------------- + +`DDS `__ is an industry standard which is implemented by a range of vendors, such as RTI's `Connext DDS `__, eProsima's `Fast DDS `__, Eclipse's `Cyclone DDS `__, or GurumNetworks's `GurumDDS `__. +RTPS (a.k.a. `DDSI-RTPS `__\ ) is the wire protocol used by DDS to communicate over the network. + +`This article `__ explains the motivation behind using DDS implementations, and/or the RTPS wire protocol of DDS, in detail. +In summary, DDS is an end-to-end middleware that provides features which are relevant to ROS systems, such as distributed discovery (not centralized like in ROS 1) and control over different "Quality of Service" (a.k.a. QoS) options for the transportation. + +Zenoh middleware +---------------- + +`Zenoh `_ is a protocol that integrates internet-scale publish/subscribe with distributed querying. +It is designed for efficient communication in a wide range of deployments that vary from server-grade hardware and networks to resource-constrained edge devices. +Zenoh extends the privilege of location transparency to storage data, allowing queries to be addressed with no concerns about where the data is stored. + +As an RMW implementation for ROS 2, Zenoh offers a more lightweight alternative to DDS and maintains Quality of Service features (in Zenoh, there are essentially no "incompatible" QoS settings). +Its minimal wire overhead and flexible routing make Zenoh well-suited for challenging network conditions. + +Supported RMW implementations +----------------------------- + +.. list-table:: + :header-rows: 1 + + * - Product name + - License + - RMW implementation + - Status + * - eProsima *Fast DDS* + - Apache 2 + - ``rmw_fastrtps_cpp`` + - Full support. + Default RMW. + Packaged with binary releases. + * - Eclipse *Cyclone DDS* + - Eclipse Public License v2.0 + - ``rmw_cyclonedds_cpp`` + - Full support. + Packaged with binary releases. + * - RTI *Connext DDS* + - Commercial, research + - ``rmw_connextdds`` + - Full support. + Support included in binaries, but Connext installed separately. + * - GurumNetworks *GurumDDS* + - Commercial + - ``rmw_gurumdds_cpp`` + - Community support. + Support included in binaries, but GurumDDS installed separately. + * - Eclipse *Zenoh* + - Eclipse Public License v2.0 + - ``rmw_zenoh_cpp`` + - Full support. + Packaged with binary releases starting with Kilted Kaiju. + +For practical information on working with multiple RMW implementations, see the :doc:`"Working with multiple RMW implementations" <../../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` tutorial. + +Choosing a middleware implementation +------------------------------------ + +There are many factors you might consider while choosing a middleware implementation: logistical considerations like the license, or technical considerations like platform availability, resource utilisation, or computation footprint. +Vendors may provide more than one middleware implementation targeted at meeting different needs. + +For example, RTI has a few variations of their Connext implementation that vary in purpose, like one that specifically targets microcontrollers and another which targets applications requiring special safety certifications (we only support their standard desktop version at this time). +Eclipse offers both Cyclone DDS and Zenoh. +Cyclone DDS is one of the lighter DDS implementations, optimised for real-time deterministic communication, while Zenoh is designed for IoT and edge computing scenarios where high throughput, low latency, and interoperability across heterogeneous environments are primary concerns. + +In order to use a middleware implementation with ROS 2, a "\ **R**\ OS **M**\ iddle\ **w**\ are interface" (a.k.a. ``rmw`` interface or just ``rmw``\ ) package needs to be created that implements the abstract ROS middleware interface using that specific implementation's API and tools. +It's a lot of work to implement and maintain RMW packages for supporting various middleware implementations, but this diversity is important for ensuring that the ROS 2 codebase is not tied to any one particular implementation, as users may wish to switch out implementations depending on their project's needs. + +Multiple RMW implementations +---------------------------- + +The ROS 2 binary releases for currently active distros have built-in support for several RMW implementations out of the box (Fast DDS, RTI Connext Pro, Eclipse Cyclone DDS, GurumNetworks GurumDDS). +Beginning with ROS 2 Kilted Kaiju, this also includes Eclipse Zenoh. +The default is Fast DDS, which works without any additional installation steps because we distribute it with our binary packages. + +RMWs other than Fast DDS, like Cyclone DDS, Connext or GurumDDS can be enabled by :doc:`installing additional packages <../../Get-Started/Installation/RMW-Implementations>`, and without having to rebuild anything or replace any existing packages. + +A ROS 2 workspace that has been built from source may build and install multiple RMW implementations simultaneously. +While the core ROS 2 code is being compiled, any RMW implementation that is found will be built if the relevant middleware implementation has been installed properly and the relevant environment variables have been configured. +For example, if the code for the `RMW package for RTI Connext DDS `__ is in the workspace, it will be built if an installation of RTI's Connext Pro can also be found. + +If a ROS 2 workspace has multiple RMW implementations, Fast DDS is selected as the default RMW implementation if it is available. +If Fast DDS is not installed, the default middleware will be selected based on alphabetical order of the package identifiers. +The implementation identifier is the name of the ROS package that provides the RMW implementation, e.g. ``rmw_cyclonedds_cpp``. +For example, if both ``rmw_cyclonedds_cpp`` and ``rmw_connextdds`` ROS packages are installed, ``rmw_connextdds`` would be the default. +If ``rmw_fastrtps_cpp`` is ever installed, it would be the default. + +See the :doc:`guide <../../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` for how to specify which RMW implementation is to be used when running the ROS 2 examples. + +.. _different-middleware-vendors-cross-vendor-communication: + +Cross-Vendor Communication among DDS middleware +----------------------------------------------- + +For many cases you will find that nodes using different DDS middleware implementations are able to communicate, however this is not true under all circumstances. +While the different DDS implementations may be compatible in limited circumstances, this is not guaranteed. +Thus it is suggested that users ensure that all parts of a distributed system are using the same ROS version and the same RMW implementation. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst b/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst index 19ff6c1b58f..bd3e150d6cc 100644 --- a/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst +++ b/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst @@ -1,240 +1,241 @@ -.. redirect-from:: - - Concepts/About-Executors - -Executors -========= - -.. contents:: Table of Contents - :local: - -Overview --------- - -Execution management in ROS 2 is handled by Executors. -An Executor uses one or more threads of the underlying operating system to invoke the callbacks of subscriptions, timers, service servers, action servers, etc. on incoming messages and events. -The explicit Executor class (in `executor.hpp `_ in rclcpp, in `executors.py `_ in rclpy, or in `executor.h `_ in rclc) provides more control over execution management than the spin mechanism in ROS 1, although the basic API is very similar. - -In the following, we focus on the C++ Client Library *rclcpp*. - -Basic use ---------- - -In the simplest case, the main thread is used for processing the incoming messages and events of a Node by calling ``rclcpp::spin(..)`` as follows: - -.. code-block:: cpp - - int main(int argc, char* argv[]) - { - // Some initialization. - rclcpp::init(argc, argv); - ... - - // Instantiate a node. - rclcpp::Node::SharedPtr node = ... - - // Run the executor. - rclcpp::spin(node); - - // Shutdown and exit. - ... - return 0; - } - -The call to ``spin(node)`` basically expands to an instantiation and invocation of the Single-Threaded Executor, which is the simplest Executor: - -.. code-block:: cpp - - rclcpp::executors::SingleThreadedExecutor executor; - executor.add_node(node); - executor.spin(); - -By invoking ``spin()`` of the Executor instance, the current thread starts querying the rcl and middleware layers for incoming messages and other events and calls the corresponding callback functions until the node shuts down. -In order not to counteract the QoS settings of the middleware, an incoming message is not stored in a queue on the Client Library layer but kept in the middleware until it is taken for processing by a callback function. -(This is a crucial difference to ROS 1.) -A *wait set* is used to inform the Executor about available messages on the middleware layer, with one binary flag per queue. -The *wait set* is also used to detect when timers expire. - -.. image:: ../images/executors_basic_principle.png - -The Single-Threaded Executor is also used by the container process for :doc:`components <./About-Composition>`, i.e. in all cases where nodes are created and executed without an explicit main function. - -.. _TypesOfExecutors: - -Types of Executors ------------------- - -Currently, rclcpp provides three Executor types, derived from a shared parent class: - -.. graphviz:: - - digraph Flatland { - - Executor -> SingleThreadedExecutor [dir = back, arrowtail = empty]; - Executor -> MultiThreadedExecutor [dir = back, arrowtail = empty]; - Executor -> EventsCBGExecutor [dir = back, arrowtail = empty]; - Executor [shape=polygon,sides=4]; - SingleThreadedExecutor [shape=polygon,sides=4]; - MultiThreadedExecutor [shape=polygon,sides=4]; - EventsCBGExecutor [shape=polygon,sides=4]; - - } - -The *Multi-Threaded Executor* creates a configurable number of threads to allow for processing multiple messages or events in parallel. - -All executors can be used with multiple nodes by calling ``add_node(..)`` for each node. - -.. code-block:: cpp - - rclcpp::Node::SharedPtr node1 = ... - rclcpp::Node::SharedPtr node2 = ... - rclcpp::Node::SharedPtr node3 = ... - - rclcpp::executors::SingleThreadedExecutor executor; - executor.add_node(node1); - executor.add_node(node2); - executor.add_node(node3); - executor.spin(); - -In the above example, the one thread of a Single-Threaded Executor is used to serve three nodes together. -In case of a Multi-Threaded Executor, the actual parallelism depends on the callback groups. - -.. _TheCallbackGroupEventsExecutor: - -The Callback Group Events Executor ----------------------------------- - -Historically, both the Single and Multi-threaded executors, while simple enough in their implementation and how to reason about their execution, `were a significant performance bottleneck. `_ - -Available in Lyrical Luth onward, the `EventsCBGExecutor `_ is the result of years of work towards reducing the CPU overhead compared to existing executors. -Instead of the wait sets, it utilizes a *first-in first-out events queue* to process ready events. -It builds off the core idea that you don't pay for what you're not using, because rather than polling for changes on entities, an entity will enqueue an event to be processed *only when it becomes ready*. - -This new executor improves on its predecessor, the ``rclcpp::experimental::EventsExecutor``, by adding support for multiple sources of ROS time (including sim time), addressing `issues with slow running timers leading to a burst of timer events `_, and multithreading support. -Therefore, the new executor can also act as a drop-in replacement for the ``MultiThreadedExecutor``, as it will also create a configurable number of worker threads to process ready events. -In single-threaded mode, the ``EventsCBGExecutor`` results in less context switching and `exhibits similar performance characteristics to its predecessor `_. - -Note: Currently, there is no limit to the number of events that can be added to the queue. -This means that if the process is overloaded and starts slowing down, the number of ready entities inside the queue can grow unbounded. - -.. code-block:: cpp - - rclcpp::Node::SharedPtr node1 = ... - rclcpp::Node::SharedPtr node2 = ... - rclcpp::Node::SharedPtr node3 = ... - rclcpp::Node::SharedPtr node4 = ... - - rclcpp::executors::EventsCBGExecutor st_cbg_exec(rclcpp::ExecutorOptions(), 1); - st_cbg_exec.add_node(node1); - st_cbg_exec.add_node(node2); - st_cbg_exec.spin(); - - rclcpp::executors::EventsCBGExecutor mt_cbg_exec; - mt_cbg_exec.add_node(node3); - mt_cbg_exec.add_node(node4); - mt_cbg_exec.spin(); - -In the above example, ``st_cbg_exec`` will use one thread for processing all of ``node1`` and ``node2``'s ready events, while ``mt_cbg_exec`` will use the maximum threads available on the system to process ``node3`` and ``node4``'s ready events. -Like the Multi-Threaded Executor, the actual parallelism depends on the callback groups when using the CBG Executor with more than one thread. - -Callback groups ---------------- - -ROS 2 allows organizing the callbacks of a node in groups. -In rclcpp, such a *callback group* can be created by the ``create_callback_group`` function of the Node class. -In rclpy, the same is done by calling the constructor of the specific callback group type. -The callback group must be stored throughout execution of the node (e.g. as a class member), or otherwise the executor won't be able to trigger the callbacks. -Then, this callback group can be specified when creating a subscription, timer, etc. - for example by the subscription options: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: cpp - - my_callback_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - - rclcpp::SubscriptionOptions options; - options.callback_group = my_callback_group; - - my_subscription = create_subscription("/topic", rclcpp::SensorDataQoS(), - callback, options); - .. group-tab:: Python - - .. code-block:: python - - my_callback_group = MutuallyExclusiveCallbackGroup() - my_subscription = self.create_subscription(Int32, "/topic", self.callback, qos_profile=1, - callback_group=my_callback_group) - -All subscriptions, timers, etc. that are created without the indication of a callback group are assigned to the *default callback group*. -The default callback group can be queried via ``NodeBaseInterface::get_default_callback_group()`` in rclcpp -and by ``Node.default_callback_group`` in rclpy. - -There are two types of callback groups, where the type has to be specified at instantiation time: - -* *Mutually exclusive:* Callbacks of this group must not be executed in parallel. -* *Reentrant:* Callbacks of this group may be executed in parallel. - -Callbacks of different callback groups may always be executed in parallel. -The Multi-Threaded Executor uses its threads as a pool to process as many callbacks as possible in parallel according to these conditions. -For tips on how to use callback groups efficiently, see :doc:`Using Callback Groups <../../How-To-Guides/Using-callback-groups>`. - -The Executor base class in rclcpp also has the function ``add_callback_group(..)``, which allows distributing callback groups to different Executors. -By configuring the underlying threads using the operating system scheduler, specific callbacks can be prioritized over other callbacks. -For example, the subscriptions and timers of a control loop can be prioritized over all other subscriptions and standard services of a node. -The `examples_rclcpp_cbg_executor package `_ provides a demo of this mechanism. - -Scheduling semantics --------------------- - -If the processing time of the callbacks is shorter than the period with which messages and events occur, the Executor basically processes them in FIFO order. -However, if the processing time of some callbacks is longer, messages and events will be queued on the lower layers of the stack. -The wait set mechanism reports only very little information about these queues to the Executor. -In detail, it only reports whether there are any messages for a certain topic or not. -The Executor uses this information to process the messages (including services and actions) in a round-robin fashion - but not in FIFO order. -The following flow diagram visualizes this scheduling semantics. - -.. image:: ../images/executors_scheduling_semantics.png - -This semantics was first described in a `paper by Casini et al. at ECRTS 2019 `_. -(Note: The paper also explains that timer events are prioritized over all other messages. -`This prioritization was removed in Eloquent. `_) - - -Outlook -------- - -While the Single and Multi-threaded Executors of rclcpp work well for most applications, there are some issues that make them not suitable for real-time applications, which require well-defined execution times, determinism, and custom control over the execution order. -Here is a summary of some of these issues: - -1. Complex and mixed scheduling semantics. - Ideally you want well defined scheduling semantics to perform a formal timing analysis. -2. Callbacks may suffer from priority inversion. - Higher priority callbacks may be blocked by lower priority callbacks. -3. No explicit control over the callbacks execution order. -4. No built-in control over triggering for specific topics. - -Additionally, the overhead of the Single and Multi-threaded Executors in terms of CPU and memory usage is considerable. - -These issues have been partially addressed by the following developments: - -* `rclcpp WaitSet `_: The ``WaitSet`` class of rclcpp allows waiting directly on subscriptions, timers, service servers, action servers, etc. instead of using an Executor. - It can be used to implement deterministic, user-defined processing sequences, possibly processing multiple messages from different subscriptions together. - The `examples_rclcpp_wait_set package `_ provides several examples for the use of this user-level wait set mechanism. -* `rclc Executor `_: This Executor from the C Client Library *rclc*, developed for micro-ROS, gives the user fine-grained control over the execution order of callbacks and allows for custom trigger conditions to activate callbacks. - Furthermore, it implements ideas of the Logical Execution Time (LET) semantics. -* :ref:`The Callback Group Events Executor ` utilizes between 10 and 15% less CPU compared to the single and multi-threaded executors, and makes use of a FIFO queue to handle events. - -Further information -------------------- - -* Michael Pöhnl et al.: `"ROS 2 Executor: How to make it efficient, real-time and deterministic?" `_. - Workshop at ROS World 2021. - Virtual event. - 19 October 2021. -* Ralph Lange: `"Advanced Execution Management with ROS 2" `_. - ROS Industrial Conference. - Virtual event. - 16 December 2020. -* Daniel Casini, Tobias Blass, Ingo Lütkebohle, and Björn Brandenburg: `"Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling" `_, Proceedings of 31st ECRTS 2019, Stuttgart, Germany, July 2019. +.. redirect-from:: + + Concepts/About-Executors + Concepts/Intermediate/About-Executors + +Executors +========= + +.. contents:: Table of Contents + :local: + +Overview +-------- + +Execution management in ROS 2 is handled by Executors. +An Executor uses one or more threads of the underlying operating system to invoke the callbacks of subscriptions, timers, service servers, action servers, etc. on incoming messages and events. +The explicit Executor class (in `executor.hpp `_ in rclcpp, in `executors.py `_ in rclpy, or in `executor.h `_ in rclc) provides more control over execution management than the spin mechanism in ROS 1, although the basic API is very similar. + +In the following, we focus on the C++ Client Library *rclcpp*. + +Basic use +--------- + +In the simplest case, the main thread is used for processing the incoming messages and events of a Node by calling ``rclcpp::spin(..)`` as follows: + +.. code-block:: cpp + + int main(int argc, char* argv[]) + { + // Some initialization. + rclcpp::init(argc, argv); + ... + + // Instantiate a node. + rclcpp::Node::SharedPtr node = ... + + // Run the executor. + rclcpp::spin(node); + + // Shutdown and exit. + ... + return 0; + } + +The call to ``spin(node)`` basically expands to an instantiation and invocation of the Single-Threaded Executor, which is the simplest Executor: + +.. code-block:: cpp + + rclcpp::executors::SingleThreadedExecutor executor; + executor.add_node(node); + executor.spin(); + +By invoking ``spin()`` of the Executor instance, the current thread starts querying the rcl and middleware layers for incoming messages and other events and calls the corresponding callback functions until the node shuts down. +In order not to counteract the QoS settings of the middleware, an incoming message is not stored in a queue on the Client Library layer but kept in the middleware until it is taken for processing by a callback function. +(This is a crucial difference to ROS 1.) +A *wait set* is used to inform the Executor about available messages on the middleware layer, with one binary flag per queue. +The *wait set* is also used to detect when timers expire. + +.. image:: ../images/executors_basic_principle.png + +The Single-Threaded Executor is also used by the container process for :doc:`components <../../nodes/About-Composition>`, i.e. in all cases where nodes are created and executed without an explicit main function. + +.. _TypesOfExecutors: + +Types of Executors +------------------ + +Currently, rclcpp provides three Executor types, derived from a shared parent class: + +.. graphviz:: + + digraph Flatland { + + Executor -> SingleThreadedExecutor [dir = back, arrowtail = empty]; + Executor -> MultiThreadedExecutor [dir = back, arrowtail = empty]; + Executor -> EventsCBGExecutor [dir = back, arrowtail = empty]; + Executor [shape=polygon,sides=4]; + SingleThreadedExecutor [shape=polygon,sides=4]; + MultiThreadedExecutor [shape=polygon,sides=4]; + EventsCBGExecutor [shape=polygon,sides=4]; + + } + +The *Multi-Threaded Executor* creates a configurable number of threads to allow for processing multiple messages or events in parallel. + +All executors can be used with multiple nodes by calling ``add_node(..)`` for each node. + +.. code-block:: cpp + + rclcpp::Node::SharedPtr node1 = ... + rclcpp::Node::SharedPtr node2 = ... + rclcpp::Node::SharedPtr node3 = ... + + rclcpp::executors::SingleThreadedExecutor executor; + executor.add_node(node1); + executor.add_node(node2); + executor.add_node(node3); + executor.spin(); + +In the above example, the one thread of a Single-Threaded Executor is used to serve three nodes together. +In case of a Multi-Threaded Executor, the actual parallelism depends on the callback groups. + +.. _TheCallbackGroupEventsExecutor: + +The Callback Group Events Executor +---------------------------------- + +Historically, both the Single and Multi-threaded executors, while simple enough in their implementation and how to reason about their execution, `were a significant performance bottleneck. `_ + +Available in Lyrical Luth onward, the `EventsCBGExecutor `_ is the result of years of work towards reducing the CPU overhead compared to existing executors. +Instead of the wait sets, it utilizes a *first-in first-out events queue* to process ready events. +It builds off the core idea that you don't pay for what you're not using, because rather than polling for changes on entities, an entity will enqueue an event to be processed *only when it becomes ready*. + +This new executor improves on its predecessor, the ``rclcpp::experimental::EventsExecutor``, by adding support for multiple sources of ROS time (including sim time), addressing `issues with slow running timers leading to a burst of timer events `_, and multithreading support. +Therefore, the new executor can also act as a drop-in replacement for the ``MultiThreadedExecutor``, as it will also create a configurable number of worker threads to process ready events. +In single-threaded mode, the ``EventsCBGExecutor`` results in less context switching and `exhibits similar performance characteristics to its predecessor `_. + +Note: Currently, there is no limit to the number of events that can be added to the queue. +This means that if the process is overloaded and starts slowing down, the number of ready entities inside the queue can grow unbounded. + +.. code-block:: cpp + + rclcpp::Node::SharedPtr node1 = ... + rclcpp::Node::SharedPtr node2 = ... + rclcpp::Node::SharedPtr node3 = ... + rclcpp::Node::SharedPtr node4 = ... + + rclcpp::executors::EventsCBGExecutor st_cbg_exec(rclcpp::ExecutorOptions(), 1); + st_cbg_exec.add_node(node1); + st_cbg_exec.add_node(node2); + st_cbg_exec.spin(); + + rclcpp::executors::EventsCBGExecutor mt_cbg_exec; + mt_cbg_exec.add_node(node3); + mt_cbg_exec.add_node(node4); + mt_cbg_exec.spin(); + +In the above example, ``st_cbg_exec`` will use one thread for processing all of ``node1`` and ``node2``'s ready events, while ``mt_cbg_exec`` will use the maximum threads available on the system to process ``node3`` and ``node4``'s ready events. +Like the Multi-Threaded Executor, the actual parallelism depends on the callback groups when using the CBG Executor with more than one thread. + +Callback groups +--------------- + +ROS 2 allows organizing the callbacks of a node in groups. +In rclcpp, such a *callback group* can be created by the ``create_callback_group`` function of the Node class. +In rclpy, the same is done by calling the constructor of the specific callback group type. +The callback group must be stored throughout execution of the node (e.g. as a class member), or otherwise the executor won't be able to trigger the callbacks. +Then, this callback group can be specified when creating a subscription, timer, etc. - for example by the subscription options: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: cpp + + my_callback_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + + rclcpp::SubscriptionOptions options; + options.callback_group = my_callback_group; + + my_subscription = create_subscription("/topic", rclcpp::SensorDataQoS(), + callback, options); + .. group-tab:: Python + + .. code-block:: python + + my_callback_group = MutuallyExclusiveCallbackGroup() + my_subscription = self.create_subscription(Int32, "/topic", self.callback, qos_profile=1, + callback_group=my_callback_group) + +All subscriptions, timers, etc. that are created without the indication of a callback group are assigned to the *default callback group*. +The default callback group can be queried via ``NodeBaseInterface::get_default_callback_group()`` in rclcpp +and by ``Node.default_callback_group`` in rclpy. + +There are two types of callback groups, where the type has to be specified at instantiation time: + +* *Mutually exclusive:* Callbacks of this group must not be executed in parallel. +* *Reentrant:* Callbacks of this group may be executed in parallel. + +Callbacks of different callback groups may always be executed in parallel. +The Multi-Threaded Executor uses its threads as a pool to process as many callbacks as possible in parallel according to these conditions. +For tips on how to use callback groups efficiently, see :doc:`Using Callback Groups <../../nodes/Working-with-nodes/Using-callback-groups>`. + +The Executor base class in rclcpp also has the function ``add_callback_group(..)``, which allows distributing callback groups to different Executors. +By configuring the underlying threads using the operating system scheduler, specific callbacks can be prioritized over other callbacks. +For example, the subscriptions and timers of a control loop can be prioritized over all other subscriptions and standard services of a node. +The `examples_rclcpp_cbg_executor package `_ provides a demo of this mechanism. + +Scheduling semantics +-------------------- + +If the processing time of the callbacks is shorter than the period with which messages and events occur, the Executor basically processes them in FIFO order. +However, if the processing time of some callbacks is longer, messages and events will be queued on the lower layers of the stack. +The wait set mechanism reports only very little information about these queues to the Executor. +In detail, it only reports whether there are any messages for a certain topic or not. +The Executor uses this information to process the messages (including services and actions) in a round-robin fashion - but not in FIFO order. +The following flow diagram visualizes this scheduling semantics. + +.. image:: ../images/executors_scheduling_semantics.png + +This semantics was first described in a `paper by Casini et al. at ECRTS 2019 `_. +(Note: The paper also explains that timer events are prioritized over all other messages. +`This prioritization was removed in Eloquent. `_) + + +Outlook +------- + +While the Single and Multi-threaded Executors of rclcpp work well for most applications, there are some issues that make them not suitable for real-time applications, which require well-defined execution times, determinism, and custom control over the execution order. +Here is a summary of some of these issues: + +1. Complex and mixed scheduling semantics. + Ideally you want well defined scheduling semantics to perform a formal timing analysis. +2. Callbacks may suffer from priority inversion. + Higher priority callbacks may be blocked by lower priority callbacks. +3. No explicit control over the callbacks execution order. +4. No built-in control over triggering for specific topics. + +Additionally, the overhead of the Single and Multi-threaded Executors in terms of CPU and memory usage is considerable. + +These issues have been partially addressed by the following developments: + +* `rclcpp WaitSet `_: The ``WaitSet`` class of rclcpp allows waiting directly on subscriptions, timers, service servers, action servers, etc. instead of using an Executor. + It can be used to implement deterministic, user-defined processing sequences, possibly processing multiple messages from different subscriptions together. + The `examples_rclcpp_wait_set package `_ provides several examples for the use of this user-level wait set mechanism. +* `rclc Executor `_: This Executor from the C Client Library *rclc*, developed for micro-ROS, gives the user fine-grained control over the execution order of callbacks and allows for custom trigger conditions to activate callbacks. + Furthermore, it implements ideas of the Logical Execution Time (LET) semantics. +* :ref:`The Callback Group Events Executor ` utilizes between 10 and 15% less CPU compared to the single and multi-threaded executors, and makes use of a FIFO queue to handle events. + +Further information +------------------- + +* Michael Pöhnl et al.: `"ROS 2 Executor: How to make it efficient, real-time and deterministic?" `_. + Workshop at ROS World 2021. + Virtual event. + 19 October 2021. +* Ralph Lange: `"Advanced Execution Management with ROS 2" `_. + ROS Industrial Conference. + Virtual event. + 16 December 2020. +* Daniel Casini, Tobias Blass, Ingo Lütkebohle, and Björn Brandenburg: `"Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling" `_, Proceedings of 31st ECRTS 2019, Stuttgart, Germany, July 2019. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/About-Middleware-Implementations.rst b/source/ROS-Framework/client-libraries/About-Middleware-Implementations.rst index cba11527e2a..795f94721e5 100644 --- a/source/ROS-Framework/client-libraries/About-Middleware-Implementations.rst +++ b/source/ROS-Framework/client-libraries/About-Middleware-Implementations.rst @@ -1,110 +1,110 @@ -.. redirect-from:: - - Concepts/About-Middleware-Implementations - -ROS 2 middleware implementations -================================ - -.. contents:: Table of Contents - :local: - -.. include:: ../../../global_substitutions.txt - -ROS middleware implementations are sets of |packages| that provide the underlying communication framework for ROS 2. -These packages interact with core ROS 2 interfaces such as the ``rmw``, ``rcl``, and ``rosidl`` |APIs| to integrate with external protocols like Zenoh, DDS, or others. -For example, ``rmw_fastrtps_cpp`` adapts eProsima's Fast DDS implementation to ROS 2's middleware |API|, while ``rmw_zenoh_cpp`` provides similar integration for the Zenoh protocol. - -For a more practical in-depth overview of how ROS 2 integrates with different middleware implementations, see :doc:`the middleware implementation tutorial <../../Tutorials/Advanced/Creating-An-RMW-Implementation>`. - -Common Packages for DDS Middleware Implementations --------------------------------------------------- - -Many of the ROS 2 middleware solutions are based on full or partial DDS implementations. -For example, there are middleware implementations that use RTI's Connext DDS, eProsima's Fast DDS and GurumNetworks' GurumDDS. -These DDS-based implementations share some common |packages| and patterns. - -In the `ros2/rosidl_dds `_ repository on |GitHub|_, there is the following |package|: - -- ``rosidl_generator_dds_idl``: provides tools to generate DDS ``.idl`` files from ``rosidl`` files, e.g. ``.msg`` files, ``.srv`` files, etc. - -The ``rosidl_generator_dds_idl`` |package| generates a DDS ``.idl`` file for each ROS interface definition file (``.msg``, ``.srv``, ``.action``, etc.) found in ROS packages. -These interface definition files specify the data structures used for topics, services, and actions in ROS 2. -DDS-based ROS middleware implementations then use these generated ``.idl`` files to create vendor-specific pre-compiled type support. - -.. _about-middleware-impls_struct_dds: - -Structure of DDS Middleware Implementations -------------------------------------------- - -A DDS-based ROS middleware implementation typically includes, but is not limited to, these |packages| in a single repository: - -- ``_cmake_module``: contains CMake Module for discovering and exposing required dependencies -- ``rmw__``: contains the implementation of the RMW |API| in a particular language, typically C++ -- ``rosidl_typesupport__``: contains tools to generate static type support code for ``rosidl`` files, tailored to the implementation in a particular language, typically C or C++ - -The ``_cmake_module`` |package| contains any CMake Modules and functions needed to find the supporting dependencies for the middleware implementation. -For example, ``rti_connext_dds_cmake_module`` provides wrapper logic around the CMake Module shipped with RTI Connext DDS to make sure that all packages that depend on it will select the same installation of RTI Connext DDS. -Similarly, ``fastrtps_cmake_module`` includes a CMake Module to find eProsima's Fast DDS and ``gurumdds_cmake_module`` includes a CMake Module to find GurumNetworks GurumDDS. -Not all implementations will have a package like this: for example, Eclipe's Cyclone DDS already provides a CMake Module which is used directly by its RMW implementation without the need of additional wrappers. - -The ``rmw__`` |package| implements the ``rmw`` C |API| in a particular language. -The implementation itself can be C++, it just must expose the header's symbols as ``extern "C"`` so that C applications can link against it. - -The ``rosidl_typesupport__`` |package| provides a generator which generates DDS code in a particular language. -This is done using the ``.idl`` files generated by the ``rosidl_generator_dds_idl`` |package| and the DDS IDL code generator provided by the DDS vendor. -It also generates code for converting ROS message structures to and from DDS message structures. -This generator is also responsible for creating a shared library for the message package it is being used in, which is specific to the messages in the message package and to the DDS vendor being used. - -As mentioned above, the ``rosidl_typesupport_introspection_`` may be used instead of a vendor specific type support package if an RMW implementation supports runtime interpretation of messages. -This ability to programmatically send and receive types over topics without generating code beforehand is achieved by supporting the `DDS X-Types Dynamic Data standard `_. -As such, RMW implementations may provide support for the X-Types standard, and/or provide a package for type support generated at compile time specific to their DDS implementation. - -For examples of example of DDS RMW implementation repositories, - -| The ``Eclipse Cyclone DDS`` ROS middleware implementation is on |GitHub|_ at `ros2/rmw_cyclonedds `_. -| The RMW implementation for ``Fast DDS`` is on |GitHub|_ at `ros2/rmw_fastrtps_cpp `_. -| The RMW implementation for ``Connext DDS`` is on |GitHub|_ at `ros2/rmw_connextdds `_. -| The RMW implementation for ``GurumDDS`` is on |GitHub|_ at `ros/rmw_gurumdds `_. - -.. _about-middleware-impls_struct_zenoh: - -Structure of the Zenoh Middleware Implementation ------------------------------------------------- - -For data to be sent and received over Zenoh using ROS 2, the middleware package, ``rmw_zenoh_cpp``, maps the ROS 2 middleware |API| to Zenoh's |APIs| using `zenoh-c `_. -Unlike DDS-based implementations, this middleware relies on a Zenoh router to discover peers and pass discovery information along via Zenoh's 'gossip scouting'. -Therefore, ``rmw_zenoh_cpp`` requires the Zenoh router (``zenohd``) to be active on the local system or reachable over the network. - -In ROS 2's Zenoh integration, each `context `_ is mapped to a single Zenoh session. -This session is shared across all publishers, subscriptions, services, and clients within that context. -The context maintains a local graph cache that tracks the network topology of ROS 2 entities and the presence of each entity is managed through unique liveliness tokens issued on creation and revoked during destruction. - -Here is an inexhaustive list of how the Zenoh middleware |API| adapts ROS 2 entities over its communication protocol: - -**Nodes:** Nodes in ROS 2 have been referred to as "units of computation" in a ROS 2 graph, whereby each node should be responsible for a single, modular purpose. -Zenoh has no direct counterpart to the node, so ``rmw_zenoh_cpp`` creates no Zenoh entities for them. -However, when a node is created through the RMW |API|, a liveliness token of type ``NN`` is declared. - -**Publishers:** A ROS 2 publisher sends data to a specific topic. -Because Zenoh publishers function very similarly with Keys, ``rmw_zenoh_cpp`` maps these entities directly. -When a publisher is created through the RMW |API|, a liveliness token of type ``MP`` is declared. - -**Subscribers:** Subscribers in ROS 2 listen on topics for new data. -They are conceptually equivalent to subscribers in Zenoh so ``rmw_zenoh_cpp`` maps these entities directly. -When new data arrives, Zenoh's middleware |package| invokes an internal callback that takes ownership of the data and signals availability to ``rmw_wait``. -When a subscriber is created through the RMW |API|, a liveliness token of type ``MS`` is declared. - -**Service clients:** ``rmw_zenoh_cpp`` uses Zenoh queryables to implement ROS 2 services. -Clients use ``rmw_send_request`` to make requests in ROS 2. -A request will carry metadata that will be used to correlate a response, like its sequence number and the GUID of the client that sent it. -Zenoh's middleware |package| can then use ``z_get`` to send a query out into the network. -When a client is created through the RMW |API|, a liveliness token of type ``SC`` is declared. - -**Service server:** ``rmw_zenoh_cpp`` uses Zenoh queryables to implement ROS 2 services. -ROS 2 nodes use ``rmw_create_service`` to advertise services to the network and the Zenoh |API|, ``z_declare_queryable``, is used to create the server-side representation of a ROS 2 service. -``rmw_take_request`` delivers the query to the use callback to be processed and after the computation is complete, ``rmw_send_reponse`` returns the result to the requester. -When a server is created, a liveliness token of type ``SS`` is declared. - -The RMW implementation for ``Zenoh`` is on |GitHub|_ at `ros2/rmw_zenoh `_. - - +.. redirect-from:: + + Concepts/About-Middleware-Implementations + Concepts/Advanced/About-Middleware-Implementations + +ROS 2 middleware implementations +================================ + +.. contents:: Table of Contents + :local: + +.. include:: ../../../global_substitutions.txt + +ROS middleware implementations are sets of |packages| that provide the underlying communication framework for ROS 2. +These packages interact with core ROS 2 interfaces such as the ``rmw``, ``rcl``, and ``rosidl`` |APIs| to integrate with external protocols like Zenoh, DDS, or others. +For example, ``rmw_fastrtps_cpp`` adapts eProsima's Fast DDS implementation to ROS 2's middleware |API|, while ``rmw_zenoh_cpp`` provides similar integration for the Zenoh protocol. + +For a more practical in-depth overview of how ROS 2 integrates with different middleware implementations, see :doc:`the middleware implementation tutorial `. + +Common Packages for DDS Middleware Implementations +-------------------------------------------------- + +Many of the ROS 2 middleware solutions are based on full or partial DDS implementations. +For example, there are middleware implementations that use RTI's Connext DDS, eProsima's Fast DDS and GurumNetworks' GurumDDS. +These DDS-based implementations share some common |packages| and patterns. + +In the `ros2/rosidl_dds `_ repository on |GitHub|_, there is the following |package|: + +- ``rosidl_generator_dds_idl``: provides tools to generate DDS ``.idl`` files from ``rosidl`` files, e.g. ``.msg`` files, ``.srv`` files, etc. + +The ``rosidl_generator_dds_idl`` |package| generates a DDS ``.idl`` file for each ROS interface definition file (``.msg``, ``.srv``, ``.action``, etc.) found in ROS packages. +These interface definition files specify the data structures used for topics, services, and actions in ROS 2. +DDS-based ROS middleware implementations then use these generated ``.idl`` files to create vendor-specific pre-compiled type support. + +.. _about-middleware-impls_struct_dds: + +Structure of DDS Middleware Implementations +------------------------------------------- + +A DDS-based ROS middleware implementation typically includes, but is not limited to, these |packages| in a single repository: + +- ``_cmake_module``: contains CMake Module for discovering and exposing required dependencies +- ``rmw__``: contains the implementation of the RMW |API| in a particular language, typically C++ +- ``rosidl_typesupport__``: contains tools to generate static type support code for ``rosidl`` files, tailored to the implementation in a particular language, typically C or C++ + +The ``_cmake_module`` |package| contains any CMake Modules and functions needed to find the supporting dependencies for the middleware implementation. +For example, ``rti_connext_dds_cmake_module`` provides wrapper logic around the CMake Module shipped with RTI Connext DDS to make sure that all packages that depend on it will select the same installation of RTI Connext DDS. +Similarly, ``fastrtps_cmake_module`` includes a CMake Module to find eProsima's Fast DDS and ``gurumdds_cmake_module`` includes a CMake Module to find GurumNetworks GurumDDS. +Not all implementations will have a package like this: for example, Eclipe's Cyclone DDS already provides a CMake Module which is used directly by its RMW implementation without the need of additional wrappers. + +The ``rmw__`` |package| implements the ``rmw`` C |API| in a particular language. +The implementation itself can be C++, it just must expose the header's symbols as ``extern "C"`` so that C applications can link against it. + +The ``rosidl_typesupport__`` |package| provides a generator which generates DDS code in a particular language. +This is done using the ``.idl`` files generated by the ``rosidl_generator_dds_idl`` |package| and the DDS IDL code generator provided by the DDS vendor. +It also generates code for converting ROS message structures to and from DDS message structures. +This generator is also responsible for creating a shared library for the message package it is being used in, which is specific to the messages in the message package and to the DDS vendor being used. + +As mentioned above, the ``rosidl_typesupport_introspection_`` may be used instead of a vendor specific type support package if an RMW implementation supports runtime interpretation of messages. +This ability to programmatically send and receive types over topics without generating code beforehand is achieved by supporting the `DDS X-Types Dynamic Data standard `_. +As such, RMW implementations may provide support for the X-Types standard, and/or provide a package for type support generated at compile time specific to their DDS implementation. + +For examples of example of DDS RMW implementation repositories, + +| The ``Eclipse Cyclone DDS`` ROS middleware implementation is on |GitHub|_ at `ros2/rmw_cyclonedds `_. +| The RMW implementation for ``Fast DDS`` is on |GitHub|_ at `ros2/rmw_fastrtps_cpp `_. +| The RMW implementation for ``Connext DDS`` is on |GitHub|_ at `ros2/rmw_connextdds `_. +| The RMW implementation for ``GurumDDS`` is on |GitHub|_ at `ros/rmw_gurumdds `_. + +.. _about-middleware-impls_struct_zenoh: + +Structure of the Zenoh Middleware Implementation +------------------------------------------------ + +For data to be sent and received over Zenoh using ROS 2, the middleware package, ``rmw_zenoh_cpp``, maps the ROS 2 middleware |API| to Zenoh's |APIs| using `zenoh-c `_. +Unlike DDS-based implementations, this middleware relies on a Zenoh router to discover peers and pass discovery information along via Zenoh's 'gossip scouting'. +Therefore, ``rmw_zenoh_cpp`` requires the Zenoh router (``zenohd``) to be active on the local system or reachable over the network. + +In ROS 2's Zenoh integration, each `context `_ is mapped to a single Zenoh session. +This session is shared across all publishers, subscriptions, services, and clients within that context. +The context maintains a local graph cache that tracks the network topology of ROS 2 entities and the presence of each entity is managed through unique liveliness tokens issued on creation and revoked during destruction. + +Here is an inexhaustive list of how the Zenoh middleware |API| adapts ROS 2 entities over its communication protocol: + +**Nodes:** Nodes in ROS 2 have been referred to as "units of computation" in a ROS 2 graph, whereby each node should be responsible for a single, modular purpose. +Zenoh has no direct counterpart to the node, so ``rmw_zenoh_cpp`` creates no Zenoh entities for them. +However, when a node is created through the RMW |API|, a liveliness token of type ``NN`` is declared. + +**Publishers:** A ROS 2 publisher sends data to a specific topic. +Because Zenoh publishers function very similarly with Keys, ``rmw_zenoh_cpp`` maps these entities directly. +When a publisher is created through the RMW |API|, a liveliness token of type ``MP`` is declared. + +**Subscribers:** Subscribers in ROS 2 listen on topics for new data. +They are conceptually equivalent to subscribers in Zenoh so ``rmw_zenoh_cpp`` maps these entities directly. +When new data arrives, Zenoh's middleware |package| invokes an internal callback that takes ownership of the data and signals availability to ``rmw_wait``. +When a subscriber is created through the RMW |API|, a liveliness token of type ``MS`` is declared. + +**Service clients:** ``rmw_zenoh_cpp`` uses Zenoh queryables to implement ROS 2 services. +Clients use ``rmw_send_request`` to make requests in ROS 2. +A request will carry metadata that will be used to correlate a response, like its sequence number and the GUID of the client that sent it. +Zenoh's middleware |package| can then use ``z_get`` to send a query out into the network. +When a client is created through the RMW |API|, a liveliness token of type ``SC`` is declared. + +**Service server:** ``rmw_zenoh_cpp`` uses Zenoh queryables to implement ROS 2 services. +ROS 2 nodes use ``rmw_create_service`` to advertise services to the network and the Zenoh |API|, ``z_declare_queryable``, is used to create the server-side representation of a ROS 2 service. +``rmw_take_request`` delivers the query to the use callback to be processed and after the computation is complete, ``rmw_send_reponse`` returns the result to the requester. +When a server is created, a liveliness token of type ``SS`` is declared. + +The RMW implementation for ``Zenoh`` is on |GitHub|_ at `ros2/rmw_zenoh `_. + diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst index 47fa171536a..c8dfec3beca 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst @@ -1,240 +1,241 @@ -.. redirect-from:: - - Concepts/About-Internal-Interfaces - -Internal ROS 2 interfaces -========================= - -.. contents:: Table of Contents - :local: - -.. include:: ../../../global_substitutions.txt - -The internal ROS interfaces are public C |APIs| that are intended for use by developers who are creating |client libraries| or adding a new underlying middleware, but are not intended for use by typical ROS users. -The ROS |client libraries| provide the user facing |APIs| that most ROS users are familiar with, and may come in a variety of programming languages. - -Internal API Architecture Overview ----------------------------------- - -There are two main internal interfaces: - -- the ROS middleware interface (``rmw`` |API|) -- the ROS client library interface (``rcl`` |API|) - -The ``rmw`` |API| is the interface between the ROS 2 software stack and the underlying middleware implementation. -The underlying middleware used for ROS 2 is either a DDS or RTPS implementation, and is responsible for discovery, publish and subscribe mechanics, request-reply mechanics for services, and serialization of message types. - -The ``rcl`` |API| is a slightly higher level |API| which is used to implement the |client libraries| and does not touch the middleware implementation directly, but rather does so through the ROS middleware interface (``rmw`` |API|) abstraction. - -.. figure:: ../images/ros_client_library_api_stack.png - :alt: ros2 software stack - -As the diagram shows, these |APIs| are stacked such that the typical ROS user will use the |client library| |API|, e.g. ``rclcpp``, to implement their code (executable or library). -The implementation of the |client libraries|, e.g. ``rclcpp``, use the ``rcl`` interface which provides access to the ROS graph and graph events. -The ``rcl`` implementation in turn uses the ``rmw`` |API| to access the ROS graph. -The purpose of the ``rcl`` implementation is to provide a common implementation for more complex ROS concepts and utilities that may be used by various |client libraries|, while remaining agnostic to the underlying middleware being used. -The purpose of the ``rmw`` interface is to capture the absolute minimum middleware functionality needed to support ROS's client libraries. -Finally, the implementation of the ``rmw`` |API| is provided by a middleware implementation specific |package|, e.g. ``rmw_fastrtps_cpp``, the library of which is compiled against vendor specific DDS interfaces and types. - -In the diagram above there is also a box labeled ``ros_to_dds``, and the purpose of this box is to represent a category of possible packages which allow the user to access DDS vendor specific objects and settings using the ROS equivalents. -One of the goals of this abstraction interface is to completely insulate the ROS user space code from the middleware being used, so that changing DDS vendors or even middleware technology has a minimal impact on the users code. -However, we recognize that on occasion it is useful to reach into the implementation and manually adjust settings despite the consequences that might have. -By requiring the use of one of these packages in order to access the underlying DDS vendor's objects, we can avoid exposing vendor specific symbols and headers in the normal interface. -It also makes it easy to see what code is potentially violating the vendor portability by inspecting the package's dependencies to see if one of these ``ros_to_dds`` packages are being used. - -.. _Type Specific Interfaces: - -Type Specific Interfaces ------------------------- - -All along the way there are some parts of the |APIs| that are necessarily specific to the message types being exchanged, e.g. publishing a message or subscribing to a topic, and therefore require generated code for each message type. -The following diagram layouts the path from user defined ``rosidl`` files, e.g. ``.msg`` files, to the type specific code used by the user and system to perform type specific functions: - -.. figure:: ../images/ros_idl_api_stack_static.png - :alt: ros2 idl static type support stack - - Figure: flow chart of "static" type support generation, from ``rosidl`` files to user facing code. - -The right hand side of the diagram shows how the ``.msg`` files are passed directly to language specific code generators, e.g. ``rosidl_generator_cpp`` or ``rosidl_generator_py``. -These generators are responsible for creating the code that the user will include (or import) and use as the in-memory representation of the messages that were defined in the ``.msg`` files. -For example, consider the message ``std_msgs/String``, a user might use this file in C++ with the statement ``#include ``, or they might use the statement ``from std_msgs.msg import String`` in Python. -These statements work because of the files generated by these language specific (but middleware agnostic) generator packages. - -Separately, the ``.msg`` files are used to generate type support code for each type. -In this context, type support means: meta data or functions that are specific to a given type and that are used by the system to perform particular tasks for the given type. -The type support for a given message might include things like a list of the names and types for each field in the message. -It might also contain a reference to code that can perform particular tasks for that type, e.g. publish a message. - -.. _internal-interfaces_static-type-support: - -Static Type Support -^^^^^^^^^^^^^^^^^^^ - -When the type support references code to do particular functions for a specific message type, that code sometimes needs to do middleware specific work. -For example, consider the type specific publish function, when using "vendor A" the function will need to call some of "vendor A"'s |API|, but when using "vendor B" it will need to call "vendor B"'s |API|. -To allow for middleware vendor specific code, the user defined ``.msg`` files may result in the generation of vendor specific code. -This vendor specific code is still hidden from the user through the type support abstraction, which is similar to how the "Private Implementation" (or Pimpl) pattern works. - -Static Type Support with DDS -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For middleware vendors based on DDS, and specifically those which generate code based on the OMG IDL files (``.idl`` files), the user defined ``rosidl`` files (``.msg`` files) are converted into equivalent OMG IDL files (``.idl`` files). -From these OMG IDL files, vendor specific code is created and then used within the type specific functions which are referenced by the type support for a given type. -The above diagram shows this on the left hand side, where the ``.msg`` files are consumed by the ``rosidl_dds`` package to produce ``.idl`` files, and then those ``.idl`` files are given to language specific and DDS vendor specific type support generation packages. - -For example, consider the Fast DDS implementation, which has a package called ``rosidl_typesupport_fastrtps_cpp``. -This package is responsible for generating code to handle things like converting a C++ message object into a serialized octet buffer to be written over the network. -This code, while specific to Fast DDS, is still not exposed to the user because of the abstraction in the type support code. - -.. _internal-interfaces_dynamic-type-support: - -Dynamic Type Support -^^^^^^^^^^^^^^^^^^^^ - -Another way to implement type support is to have generic functions for things like publishing to a topic, rather than generating a version of the function for each message type. -In order to accomplish this, this generic function needs some meta information about the message type being published, things like a list of field names and types in the order in which they appear in the message type. -Then to publish a message, you call a generic publish function and pass a message to be published along with a structure which contains the necessary meta data about the message type. -This is referred to as "dynamic" type support, as opposed to "static" type support which requires generated versions of a function for each type. - -.. figure:: ../images/ros_idl_api_stack_dynamic.png - :alt: ros2 idl dynamic type support stack - - Figure: flow chart of "dynamic" type support generation, from ``rosidl`` files to user facing code. - -The above diagram shows the flow from user defined ``rosidl`` files to generated user facing code. -It is very similar to the diagram for static type support, and differs only in how the type support is generated which is represented by the left hand side of the diagram. -In dynamic type support the ``.msg`` files are converted directly into user facing code. - -This code is also middleware agnostic, because it only contains meta information about the messages. -The function to actually do the work, e.g. publishing to a topic, is generic to the message type and will make any necessary calls to the middleware specific |APIs|. -Note that rather than dds vendor specific packages providing the type support code, which is the case in static type support, this method has middleware agnostic package for each language, e.g. ``rosidl_typesupport_introspection_c`` and ``rosidl_typesupport_introspection_cpp``. -The ``introspection`` part of the package name refers to the ability to introspect any message instance with the generated meta data for the message type. -This is the fundamental capability that allows for generic implementations of functions like "publish to a topic". - -This approach has the advantage that all generated code is middleware agnostic, which means it can be reused for different middleware implementations, so long as they allow for dynamic type support. -It also results in less generated code, which reduces compile time and code size. - -However, dynamic type support requires that the underlying middleware support a similar form of dynamic type support. -In the case of DDS the DDS-XTypes standard allows for publishing of messages using meta information rather than generated code. -DDS-XTypes, or something like it, is required in the underlying middleware in order to support dynamic type support. -Also, this approach to type support is normally slower than the static type support alternative. -The type specific generated code in static type support can be written to be more efficient as it does not need to iterate over the message type's meta data to perform things like serialization. - -The ``rcl`` repository ----------------------- - -The ROS Client Library interface (``rcl`` |API|) can be used by |client libraries| (e.g. ``rclc``, ``rclcpp``, ``rclpy``, etc.) in order to avoid duplicating logic and features. -By reusing the ``rcl`` |API|, client libraries can be smaller and more consistent with each other. -Some parts of the client library are intentionally left out of the ``rcl`` |API| because the language idiomatic method should be used to implement those parts of the system. -A good example of this is the execution model, which ``rcl`` does not address at all. -Instead the client library should provide a language idiomatic solution like ``pthreads`` in C, ``std::thread`` in C++11, and ``threading.Thread`` in Python. -Generally the ``rcl`` interface provides functions that are not specific to a language pattern and are not specific to a particular message type. - -The ``rcl`` |API| is located in the `ros2/rcl `_ repository on |GitHub|_ and contains the interface as C headers. -The ``rcl`` C implementation is provided by the ``rcl`` |package| in the same repository. -This implementation avoids direct contact with the middleware by instead using the ``rmw`` and ``rosidl`` |APIs|. - -For a complete definition of the ``rcl`` |API|, see `the rcl docs `_. - -The ``rmw`` repository ----------------------- - -The ROS middleware interface (``rmw`` |API|) is the minimal set of primitive middleware capabilities needed to build ROS on top. -Providers of different middleware implementations must implement this interface in order to support the entire ROS stack on top. -Currently most of the middleware implementations are for different DDS vendors. - -The ``rmw`` |API| is located in the `ros2/rmw `_ repository. -The ``rmw`` |package| contains the C headers which define the interface, the implementation of which is provided by the various |packages| of rmw implementations for different DDS vendors. - -For a definition of the ``rmw`` |API|, see `the rmw docs `_. - -For a more practical in-depth overview of how ROS 2 integrates with different middleware implementations, see :doc:`the middleware implementation tutorial <../../Tutorials/Advanced/Creating-An-RMW-Implementation>`. - -The ``rosidl`` repository -------------------------- - -The ``rosidl`` |API| consists of a few message related static functions and types along with a definition of what code should be generated by messages in different languages. -The generated message code specified in the |API| will be language specific, but may or may not reuse generated code for other languages. -The generated message code specified in the |API| contains things like the message data structure, functions for construction, destruction, etc. -The |API| will also implement a way to get the type support structure for the message type, which is used when publishing or subscribing to a topic of that message type. - -There are several repositories that play a role in the ``rosidl`` |API| and implementation. - -The ``rosidl`` repository, located on |GitHub|_ at `ros2/rosidl `_, defines the message IDL syntax, i.e. syntax of ``.msg`` files, ``.srv`` files, etc., and contains |packages| for parsing the files, for providing CMake infrastructure to generate code from the messages, for generating implementation agnostic code (headers and source files), and for establishing the default set of generators. -The repository contains these |packages|: - -- ``rosidl_cmake``: provides CMake functions and modules for generating code from ``rosidl`` files, e.g. ``.msg`` files, ``.srv`` files, etc. -- ``rosidl_default_generators``: defines the list of default generators which ensures that they are installed as dependencies, but other injected generators can also be used. -- ``rosidl_generator_c``: provides tools to generate C header files (``.h``) for ``rosidl`` files. -- ``rosidl_generator_cpp``: provides tools to generate C++ header files (``.hpp``) for ``rosidl`` files. -- ``rosidl_generator_py``: provides tools to generate Python modules for ``rosidl`` files. -- ``rosidl_parser``: provides Python |API| for parsing ``rosidl`` files. - -Generators for other languages, e.g. ``rosidl_generator_java``, are hosted externally (in different repositories) but would use the same mechanism that the above generators use to "register" themselves as a ``rosidl`` generator. - -In addition to the aforementioned |packages| for parsing and generating headers for the ``rosidl`` files, the ``rosidl`` repository also contains |packages| concerned with "type support" for the message types defined in the files. -Type support refers to the ability to interpret and manipulate the information represented by ROS message instances of particular types (publishing the messages, for example). -Type support can either be provided by code that is generated at compile time or it can be done programmatically based on the contents of the ``rosidl`` file, e.g. the ``.msg`` or ``.srv`` file, and the data received, by introspecting the data. -In the case of the latter, where type support is done through runtime interpretation of the messages, the message code generated by ROS 2 can be agnostic to the rmw implementation. -The packages that provide this type support through introspection of the data are: - -- ``rosidl_typesupport_introspection_c``: provides tools for generating C code for supporting ``rosidl`` message data types. -- ``rosidl_typesupport_introspection_cpp``: provides tools for generating C++ code for supporting ``rosidl`` message data types. - -In the case where type support is to be generated at compile time instead of being generated programmatically, a package specific to the rmw implementation will need to be used. -This is because typically a particular rmw implementation will require data to be stored and manipulated in a manner that is specific to the DDS vendor in order for the DDS implementation to make use of it. -See the :ref:`Type Specific Interfaces` section above for more details. - -The ``rosidl_generator_cpp`` package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This package is responsible for generating the C++ structures representing the IDL. -It also generates utilities for user-convenience and to facilitate interoperability with the C++ language. - -Message member names -"""""""""""""""""""" -The names of the members in a message can be retrieved at compile-time using ``rosidl_generator_traits::MessageTraits``. - -.. code-block:: cpp - - #include - - // ... - - using MessageTraitsTime = rosidl_generator_traits::MessageTraits; - std::array member_names = MessageTraitsTime::member_names; // Returns {"sec", "nanosec"} - -Message member metaprogramming -"""""""""""""""""""""""""""""" -To facilitate metaprogramming techniques ahead of C++26 reflection, an ``as_tuple_ref`` utility has been added to the code generation. -It returns references to each member of the structure as a tuple. -This makes it possible to both read and write message contents without accessing it through the member name. - -.. code-block:: cpp - - #include - #include - - // ... - - // Increment both members using ``std::apply`` and a fold-expression - builtin_interfaces::msg::Time time; - std::apply([](auto & ... member) { - ((member += 1), ...); - }, as_tuple_ref(msg)); - -.. warning:: - - Members of the same type can be swapped without detection using this technique. - Use with care if the interfaces can change. - The ``as_tuple_ref`` function does not extend the lifetime of the message passed to is. - It is the responsibility of the programmer to ensure that the lifetime of the message object exceeds the use of the references. - -The ``rcutils`` repository --------------------------- - -ROS 2 C Utilities (``rcutils``) is a C |API| composed of macros, functions, and data structures used throughout the ROS 2 codebase. -These are mainly used for error handling, commandline argument parsing, and logging which are not specific to the client or middleware layers and can be shared by both. - -The ``rcutils`` |API| and implementation are located in the `ros2/rcutils `_ repository on |GitHub|_ which contains the interface as C headers. - -For a complete definition of the ``rcutils`` |API|, see `the rcutils docs `_. +.. redirect-from:: + + Concepts/About-Internal-Interfaces + Concepts/Advanced/About-Internal-Interfaces + +Internal ROS 2 interfaces +========================= + +.. contents:: Table of Contents + :local: + +.. include:: ../../../global_substitutions.txt + +The internal ROS interfaces are public C |APIs| that are intended for use by developers who are creating |client libraries| or adding a new underlying middleware, but are not intended for use by typical ROS users. +The ROS |client libraries| provide the user facing |APIs| that most ROS users are familiar with, and may come in a variety of programming languages. + +Internal API Architecture Overview +---------------------------------- + +There are two main internal interfaces: + +- the ROS middleware interface (``rmw`` |API|) +- the ROS client library interface (``rcl`` |API|) + +The ``rmw`` |API| is the interface between the ROS 2 software stack and the underlying middleware implementation. +The underlying middleware used for ROS 2 is either a DDS or RTPS implementation, and is responsible for discovery, publish and subscribe mechanics, request-reply mechanics for services, and serialization of message types. + +The ``rcl`` |API| is a slightly higher level |API| which is used to implement the |client libraries| and does not touch the middleware implementation directly, but rather does so through the ROS middleware interface (``rmw`` |API|) abstraction. + +.. figure:: ../images/ros_client_library_api_stack.png + :alt: ros2 software stack + +As the diagram shows, these |APIs| are stacked such that the typical ROS user will use the |client library| |API|, e.g. ``rclcpp``, to implement their code (executable or library). +The implementation of the |client libraries|, e.g. ``rclcpp``, use the ``rcl`` interface which provides access to the ROS graph and graph events. +The ``rcl`` implementation in turn uses the ``rmw`` |API| to access the ROS graph. +The purpose of the ``rcl`` implementation is to provide a common implementation for more complex ROS concepts and utilities that may be used by various |client libraries|, while remaining agnostic to the underlying middleware being used. +The purpose of the ``rmw`` interface is to capture the absolute minimum middleware functionality needed to support ROS's client libraries. +Finally, the implementation of the ``rmw`` |API| is provided by a middleware implementation specific |package|, e.g. ``rmw_fastrtps_cpp``, the library of which is compiled against vendor specific DDS interfaces and types. + +In the diagram above there is also a box labeled ``ros_to_dds``, and the purpose of this box is to represent a category of possible packages which allow the user to access DDS vendor specific objects and settings using the ROS equivalents. +One of the goals of this abstraction interface is to completely insulate the ROS user space code from the middleware being used, so that changing DDS vendors or even middleware technology has a minimal impact on the users code. +However, we recognize that on occasion it is useful to reach into the implementation and manually adjust settings despite the consequences that might have. +By requiring the use of one of these packages in order to access the underlying DDS vendor's objects, we can avoid exposing vendor specific symbols and headers in the normal interface. +It also makes it easy to see what code is potentially violating the vendor portability by inspecting the package's dependencies to see if one of these ``ros_to_dds`` packages are being used. + +.. _Type Specific Interfaces: + +Type Specific Interfaces +------------------------ + +All along the way there are some parts of the |APIs| that are necessarily specific to the message types being exchanged, e.g. publishing a message or subscribing to a topic, and therefore require generated code for each message type. +The following diagram layouts the path from user defined ``rosidl`` files, e.g. ``.msg`` files, to the type specific code used by the user and system to perform type specific functions: + +.. figure:: ../images/ros_idl_api_stack_static.png + :alt: ros2 idl static type support stack + + Figure: flow chart of "static" type support generation, from ``rosidl`` files to user facing code. + +The right hand side of the diagram shows how the ``.msg`` files are passed directly to language specific code generators, e.g. ``rosidl_generator_cpp`` or ``rosidl_generator_py``. +These generators are responsible for creating the code that the user will include (or import) and use as the in-memory representation of the messages that were defined in the ``.msg`` files. +For example, consider the message ``std_msgs/String``, a user might use this file in C++ with the statement ``#include ``, or they might use the statement ``from std_msgs.msg import String`` in Python. +These statements work because of the files generated by these language specific (but middleware agnostic) generator packages. + +Separately, the ``.msg`` files are used to generate type support code for each type. +In this context, type support means: meta data or functions that are specific to a given type and that are used by the system to perform particular tasks for the given type. +The type support for a given message might include things like a list of the names and types for each field in the message. +It might also contain a reference to code that can perform particular tasks for that type, e.g. publish a message. + +.. _internal-interfaces_static-type-support: + +Static Type Support +^^^^^^^^^^^^^^^^^^^ + +When the type support references code to do particular functions for a specific message type, that code sometimes needs to do middleware specific work. +For example, consider the type specific publish function, when using "vendor A" the function will need to call some of "vendor A"'s |API|, but when using "vendor B" it will need to call "vendor B"'s |API|. +To allow for middleware vendor specific code, the user defined ``.msg`` files may result in the generation of vendor specific code. +This vendor specific code is still hidden from the user through the type support abstraction, which is similar to how the "Private Implementation" (or Pimpl) pattern works. + +Static Type Support with DDS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For middleware vendors based on DDS, and specifically those which generate code based on the OMG IDL files (``.idl`` files), the user defined ``rosidl`` files (``.msg`` files) are converted into equivalent OMG IDL files (``.idl`` files). +From these OMG IDL files, vendor specific code is created and then used within the type specific functions which are referenced by the type support for a given type. +The above diagram shows this on the left hand side, where the ``.msg`` files are consumed by the ``rosidl_dds`` package to produce ``.idl`` files, and then those ``.idl`` files are given to language specific and DDS vendor specific type support generation packages. + +For example, consider the Fast DDS implementation, which has a package called ``rosidl_typesupport_fastrtps_cpp``. +This package is responsible for generating code to handle things like converting a C++ message object into a serialized octet buffer to be written over the network. +This code, while specific to Fast DDS, is still not exposed to the user because of the abstraction in the type support code. + +.. _internal-interfaces_dynamic-type-support: + +Dynamic Type Support +^^^^^^^^^^^^^^^^^^^^ + +Another way to implement type support is to have generic functions for things like publishing to a topic, rather than generating a version of the function for each message type. +In order to accomplish this, this generic function needs some meta information about the message type being published, things like a list of field names and types in the order in which they appear in the message type. +Then to publish a message, you call a generic publish function and pass a message to be published along with a structure which contains the necessary meta data about the message type. +This is referred to as "dynamic" type support, as opposed to "static" type support which requires generated versions of a function for each type. + +.. figure:: ../images/ros_idl_api_stack_dynamic.png + :alt: ros2 idl dynamic type support stack + + Figure: flow chart of "dynamic" type support generation, from ``rosidl`` files to user facing code. + +The above diagram shows the flow from user defined ``rosidl`` files to generated user facing code. +It is very similar to the diagram for static type support, and differs only in how the type support is generated which is represented by the left hand side of the diagram. +In dynamic type support the ``.msg`` files are converted directly into user facing code. + +This code is also middleware agnostic, because it only contains meta information about the messages. +The function to actually do the work, e.g. publishing to a topic, is generic to the message type and will make any necessary calls to the middleware specific |APIs|. +Note that rather than dds vendor specific packages providing the type support code, which is the case in static type support, this method has middleware agnostic package for each language, e.g. ``rosidl_typesupport_introspection_c`` and ``rosidl_typesupport_introspection_cpp``. +The ``introspection`` part of the package name refers to the ability to introspect any message instance with the generated meta data for the message type. +This is the fundamental capability that allows for generic implementations of functions like "publish to a topic". + +This approach has the advantage that all generated code is middleware agnostic, which means it can be reused for different middleware implementations, so long as they allow for dynamic type support. +It also results in less generated code, which reduces compile time and code size. + +However, dynamic type support requires that the underlying middleware support a similar form of dynamic type support. +In the case of DDS the DDS-XTypes standard allows for publishing of messages using meta information rather than generated code. +DDS-XTypes, or something like it, is required in the underlying middleware in order to support dynamic type support. +Also, this approach to type support is normally slower than the static type support alternative. +The type specific generated code in static type support can be written to be more efficient as it does not need to iterate over the message type's meta data to perform things like serialization. + +The ``rcl`` repository +---------------------- + +The ROS Client Library interface (``rcl`` |API|) can be used by |client libraries| (e.g. ``rclc``, ``rclcpp``, ``rclpy``, etc.) in order to avoid duplicating logic and features. +By reusing the ``rcl`` |API|, client libraries can be smaller and more consistent with each other. +Some parts of the client library are intentionally left out of the ``rcl`` |API| because the language idiomatic method should be used to implement those parts of the system. +A good example of this is the execution model, which ``rcl`` does not address at all. +Instead the client library should provide a language idiomatic solution like ``pthreads`` in C, ``std::thread`` in C++11, and ``threading.Thread`` in Python. +Generally the ``rcl`` interface provides functions that are not specific to a language pattern and are not specific to a particular message type. + +The ``rcl`` |API| is located in the `ros2/rcl `_ repository on |GitHub|_ and contains the interface as C headers. +The ``rcl`` C implementation is provided by the ``rcl`` |package| in the same repository. +This implementation avoids direct contact with the middleware by instead using the ``rmw`` and ``rosidl`` |APIs|. + +For a complete definition of the ``rcl`` |API|, see `the rcl docs `_. + +The ``rmw`` repository +---------------------- + +The ROS middleware interface (``rmw`` |API|) is the minimal set of primitive middleware capabilities needed to build ROS on top. +Providers of different middleware implementations must implement this interface in order to support the entire ROS stack on top. +Currently most of the middleware implementations are for different DDS vendors. + +The ``rmw`` |API| is located in the `ros2/rmw `_ repository. +The ``rmw`` |package| contains the C headers which define the interface, the implementation of which is provided by the various |packages| of rmw implementations for different DDS vendors. + +For a definition of the ``rmw`` |API|, see `the rmw docs `_. + +For a more practical in-depth overview of how ROS 2 integrates with different middleware implementations, see :doc:`the middleware implementation tutorial <../Creating-An-RMW-Implementation>`. + +The ``rosidl`` repository +------------------------- + +The ``rosidl`` |API| consists of a few message related static functions and types along with a definition of what code should be generated by messages in different languages. +The generated message code specified in the |API| will be language specific, but may or may not reuse generated code for other languages. +The generated message code specified in the |API| contains things like the message data structure, functions for construction, destruction, etc. +The |API| will also implement a way to get the type support structure for the message type, which is used when publishing or subscribing to a topic of that message type. + +There are several repositories that play a role in the ``rosidl`` |API| and implementation. + +The ``rosidl`` repository, located on |GitHub|_ at `ros2/rosidl `_, defines the message IDL syntax, i.e. syntax of ``.msg`` files, ``.srv`` files, etc., and contains |packages| for parsing the files, for providing CMake infrastructure to generate code from the messages, for generating implementation agnostic code (headers and source files), and for establishing the default set of generators. +The repository contains these |packages|: + +- ``rosidl_cmake``: provides CMake functions and modules for generating code from ``rosidl`` files, e.g. ``.msg`` files, ``.srv`` files, etc. +- ``rosidl_default_generators``: defines the list of default generators which ensures that they are installed as dependencies, but other injected generators can also be used. +- ``rosidl_generator_c``: provides tools to generate C header files (``.h``) for ``rosidl`` files. +- ``rosidl_generator_cpp``: provides tools to generate C++ header files (``.hpp``) for ``rosidl`` files. +- ``rosidl_generator_py``: provides tools to generate Python modules for ``rosidl`` files. +- ``rosidl_parser``: provides Python |API| for parsing ``rosidl`` files. + +Generators for other languages, e.g. ``rosidl_generator_java``, are hosted externally (in different repositories) but would use the same mechanism that the above generators use to "register" themselves as a ``rosidl`` generator. + +In addition to the aforementioned |packages| for parsing and generating headers for the ``rosidl`` files, the ``rosidl`` repository also contains |packages| concerned with "type support" for the message types defined in the files. +Type support refers to the ability to interpret and manipulate the information represented by ROS message instances of particular types (publishing the messages, for example). +Type support can either be provided by code that is generated at compile time or it can be done programmatically based on the contents of the ``rosidl`` file, e.g. the ``.msg`` or ``.srv`` file, and the data received, by introspecting the data. +In the case of the latter, where type support is done through runtime interpretation of the messages, the message code generated by ROS 2 can be agnostic to the rmw implementation. +The packages that provide this type support through introspection of the data are: + +- ``rosidl_typesupport_introspection_c``: provides tools for generating C code for supporting ``rosidl`` message data types. +- ``rosidl_typesupport_introspection_cpp``: provides tools for generating C++ code for supporting ``rosidl`` message data types. + +In the case where type support is to be generated at compile time instead of being generated programmatically, a package specific to the rmw implementation will need to be used. +This is because typically a particular rmw implementation will require data to be stored and manipulated in a manner that is specific to the DDS vendor in order for the DDS implementation to make use of it. +See the :ref:`Type Specific Interfaces` section above for more details. + +The ``rosidl_generator_cpp`` package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +This package is responsible for generating the C++ structures representing the IDL. +It also generates utilities for user-convenience and to facilitate interoperability with the C++ language. + +Message member names +"""""""""""""""""""" +The names of the members in a message can be retrieved at compile-time using ``rosidl_generator_traits::MessageTraits``. + +.. code-block:: cpp + + #include + + // ... + + using MessageTraitsTime = rosidl_generator_traits::MessageTraits; + std::array member_names = MessageTraitsTime::member_names; // Returns {"sec", "nanosec"} + +Message member metaprogramming +"""""""""""""""""""""""""""""" +To facilitate metaprogramming techniques ahead of C++26 reflection, an ``as_tuple_ref`` utility has been added to the code generation. +It returns references to each member of the structure as a tuple. +This makes it possible to both read and write message contents without accessing it through the member name. + +.. code-block:: cpp + + #include + #include + + // ... + + // Increment both members using ``std::apply`` and a fold-expression + builtin_interfaces::msg::Time time; + std::apply([](auto & ... member) { + ((member += 1), ...); + }, as_tuple_ref(msg)); + +.. warning:: + + Members of the same type can be swapped without detection using this technique. + Use with care if the interfaces can change. + The ``as_tuple_ref`` function does not extend the lifetime of the message passed to is. + It is the responsibility of the programmer to ensure that the lifetime of the message object exceeds the use of the references. + +The ``rcutils`` repository +-------------------------- + +ROS 2 C Utilities (``rcutils``) is a C |API| composed of macros, functions, and data structures used throughout the ROS 2 codebase. +These are mainly used for error handling, commandline argument parsing, and logging which are not specific to the client or middleware layers and can be shared by both. + +The ``rcutils`` |API| and implementation are located in the `ros2/rcutils `_ repository on |GitHub|_ which contains the interface as C headers. + +For a complete definition of the ``rcutils`` |API|, see `the rcutils docs `_. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst index bb37ec78cdf..da2a6093cc0 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst @@ -1,244 +1,245 @@ -.. redirect-from:: - - Allocator-Template-Tutorial - Tutorials/Allocator-Template-Tutorial - -Implementing a custom memory allocator -====================================== - -**Goal:** This tutorial will show how to use a custom memory allocator when writing ROS 2 C++ code. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -This tutorial will teach you how to integrate a custom allocator for publishers and subscribers so that the default heap allocator is never called while your ROS nodes are executing. -The code for this tutorial is available `here `__. - -Background ----------- - -Suppose you want to write real-time safe code, and you've heard about the many dangers of calling ``new`` during the real-time critical section, because the default heap allocator on most platforms is nondeterministic. - -By default, many C++ standard library structures will implicitly allocate memory as they grow, such as ``std::vector``. -However, these data structures also accept an "Allocator" template argument. -If you specify a custom allocator to one of these data structures, it will use that allocator instead of the system allocator to grow or shrink the data structure. -Your custom allocator could have a pool of memory preallocated on the stack, which might be better suited to real-time applications. - -In the ROS 2 C++ client library (rclcpp), we are following a similar philosophy to the C++ standard library. -Publishers, subscribers, and the Executor accept an Allocator template parameter that controls allocations made by that entity during execution. - -Writing an allocator --------------------- - -To write an allocator compatible with ROS 2's allocator interface, your allocator must be compatible with the C++ standard library allocator interface. - -Since C++17, the standard library provides something called ``std::pmr::memory_resource``. -This is a class that can be derived from to create a custom allocator that fulfills a minimum set of requirements. - -For example, the following declaration for a custom memory resource fulfills the requirements (of course, you would still need to implement the declared functions in this class): - -.. code-block:: c++ - - class CustomMemoryResource : public std::pmr::memory_resource - { - private: - void * do_allocate(std::size_t bytes, std::size_t alignment) override; - - void do_deallocate( - void * p, std::size_t bytes, - std::size_t alignment) override; - - bool do_is_equal( - const std::pmr::memory_resource & other) const noexcept override; - }; - -To learn about the full capabilities of ``std::pmr::memory_resource``, see https://en.cppreference.com/w/cpp/memory/memory_resource. - -The full implementation of the custom allocator for this tutorial is in https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/allocator_tutorial_pmr.cpp. - -Writing an example main ------------------------ - -Once you have written a valid C++ allocator, you must pass it as a shared pointer to your publisher, subscriber, and executor. -But first, we'll declare a few aliases to shorten the names. - -.. code-block:: c++ - - using Alloc = std::pmr::polymorphic_allocator; - using MessageAllocTraits = - rclcpp::allocator::AllocRebind; - using MessageAlloc = MessageAllocTraits::allocator_type; - using MessageDeleter = rclcpp::allocator::Deleter; - using MessageUniquePtr = std::unique_ptr; - -Now we can create our resources with the custom allocator: - -.. code-block:: c++ - - CustomMemoryResource mem_resource{}; - auto alloc = std::make_shared(&mem_resource); - rclcpp::PublisherOptionsWithAllocator publisher_options; - publisher_options.allocator = alloc; - auto publisher = node->create_publisher( - "allocator_tutorial", 10, publisher_options); - - rclcpp::SubscriptionOptionsWithAllocator subscription_options; - subscription_options.allocator = alloc; - auto msg_mem_strat = std::make_shared< - rclcpp::message_memory_strategy::MessageMemoryStrategy< - std_msgs::msg::UInt32, Alloc>>(alloc); - auto subscriber = node->create_subscription( - "allocator_tutorial", 10, callback, subscription_options, msg_mem_strat); - - rclcpp::ExecutorOptions options; - rclcpp::executors::SingleThreadedExecutor executor(options); - -You must also instantiate a custom deleter and allocator for use when allocating messages: - -.. code-block:: c++ - - MessageDeleter message_deleter; - MessageAlloc message_alloc = *alloc; - rclcpp::allocator::set_allocator_for_deleter(&message_deleter, &message_alloc); - -Once you've add the node to the executor, it is time to spin. -We'll use the custom allocator to allocate each message: - -.. code-block:: c++ - - uint32_t i = 0; - while (rclcpp::ok()) { - auto ptr = MessageAllocTraits::allocate(message_alloc, 1); - MessageAllocTraits::construct(message_alloc, ptr); - MessageUniquePtr msg(ptr, message_deleter); - msg->data = i; - ++i; - publisher->publish(std::move(msg)); - rclcpp::sleep_for(10ms); - executor.spin_some(); - } - -Passing an allocator to the intra-process pipeline --------------------------------------------------- - -Even though we instantiated a publisher and subscriber in the same process, we aren't using the intra-process pipeline yet. - -The IntraProcessManager is a class that is usually hidden from the user, but in order to pass a custom allocator to it we need to expose it by getting it from the rclcpp Context. -The IntraProcessManager makes use of several standard library structures, so without a custom allocator it will call the default ``new``. - -.. code-block:: c++ - - auto context = rclcpp::contexts::get_global_default_context(); - auto options = rclcpp::NodeOptions() - .context(context) - .use_intra_process_comms(true); - auto node = rclcpp::Node::make_shared("allocator_example", options); - -Make sure to instantiate publishers and subscribers AFTER constructing the node in this way. - -Testing and verifying the code ------------------------------- - -How do you know that your custom allocator is actually getting called? - -The obvious thing to do would be to count the calls made to your custom allocator's ``allocate`` and ``deallocate`` functions and compare that to the calls to ``new`` and ``delete``. - -Adding counting to the custom allocator is easy: - -.. code-block:: c++ - - void * do_allocate(std::size_t size, std::size_t alignment) override - { - // ... - num_allocs++; - // ... - } - - void do_deallocate( - void * p, std::size_t bytes, - std::size_t alignment) override - { - // ... - num_deallocs++; - // ... - } - -You can also override the global ``new`` and ``delete`` operators: - -.. code-block:: c++ - - void * operator new(std::size_t size) - { - if (is_running) { - global_runtime_allocs++; - } - return std::malloc(size); - } - - void operator delete(void * ptr, size_t) noexcept - { - if (ptr != nullptr) { - if (is_running) { - global_runtime_deallocs++; - } - std::free(ptr); - } - } - - void operator delete(void * ptr) noexcept - { - if (ptr != nullptr) { - if (is_running) { - global_runtime_deallocs++; - } - std::free(ptr); - } - } - -where the variables we are incrementing are just global static integers, and ``is_running`` is a global static boolean that gets toggled right before the call to ``spin``. - -The `example executable `__ prints the value of the variables. -To run the example executable, use: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp allocator_tutorial - -or, to run the example with the intra-process pipeline on: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp allocator_tutorial intra - Global new was called 15590 times during spin - Global delete was called 15590 times during spin - Allocator new was called 27284 times during spin - Allocator delete was called 27281 times during spin - -We've caught about 2/3 of the allocations/deallocations that happen on the execution path, but where do the remaining 1/3 come from? - -As a matter of fact, these allocations/deallocations originate in the underlying DDS implementation used in this example. - -Proving this is out of the scope of this tutorial, but you can check out the test for the allocation path that gets run as part of the ROS 2 continuous integration testing, which backtraces through the code and figures out whether certain function calls originate in the rmw implementation or in a DDS implementation: - -https://github.com/ros2/realtime_support/blob/{REPOS_FILE_BRANCH}/tlsf_cpp/test/test_tlsf.cpp#L41 - -Note that this test is not using the custom allocator we just created, but the TLSF allocator (see below). - -The TLSF allocator ------------------- - -ROS 2 offers support for the TLSF (Two Level Segregate Fit) allocator, which was designed to meet real-time requirements: - -https://github.com/ros2/realtime_support/tree/{REPOS_FILE_BRANCH}/tlsf_cpp - -For more information about TLSF, see `this page via Universitat Politècnica de València `_. - -Note that the TLSF allocator is licensed under a dual-GPL/LGPL license. - -A full working example using the TLSF allocator is here: -https://github.com/ros2/realtime_support/blob/{REPOS_FILE_BRANCH}/tlsf_cpp/example/allocator_example.cpp +.. redirect-from:: + + Allocator-Template-Tutorial + Tutorials/Allocator-Template-Tutorial + Tutorials/Advanced/Allocator-Template-Tutorial + +Implementing a custom memory allocator +====================================== + +**Goal:** This tutorial will show how to use a custom memory allocator when writing ROS 2 C++ code. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +This tutorial will teach you how to integrate a custom allocator for publishers and subscribers so that the default heap allocator is never called while your ROS nodes are executing. +The code for this tutorial is available `here `__. + +Background +---------- + +Suppose you want to write real-time safe code, and you've heard about the many dangers of calling ``new`` during the real-time critical section, because the default heap allocator on most platforms is nondeterministic. + +By default, many C++ standard library structures will implicitly allocate memory as they grow, such as ``std::vector``. +However, these data structures also accept an "Allocator" template argument. +If you specify a custom allocator to one of these data structures, it will use that allocator instead of the system allocator to grow or shrink the data structure. +Your custom allocator could have a pool of memory preallocated on the stack, which might be better suited to real-time applications. + +In the ROS 2 C++ client library (rclcpp), we are following a similar philosophy to the C++ standard library. +Publishers, subscribers, and the Executor accept an Allocator template parameter that controls allocations made by that entity during execution. + +Writing an allocator +-------------------- + +To write an allocator compatible with ROS 2's allocator interface, your allocator must be compatible with the C++ standard library allocator interface. + +Since C++17, the standard library provides something called ``std::pmr::memory_resource``. +This is a class that can be derived from to create a custom allocator that fulfills a minimum set of requirements. + +For example, the following declaration for a custom memory resource fulfills the requirements (of course, you would still need to implement the declared functions in this class): + +.. code-block:: c++ + + class CustomMemoryResource : public std::pmr::memory_resource + { + private: + void * do_allocate(std::size_t bytes, std::size_t alignment) override; + + void do_deallocate( + void * p, std::size_t bytes, + std::size_t alignment) override; + + bool do_is_equal( + const std::pmr::memory_resource & other) const noexcept override; + }; + +To learn about the full capabilities of ``std::pmr::memory_resource``, see https://en.cppreference.com/w/cpp/memory/memory_resource. + +The full implementation of the custom allocator for this tutorial is in https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/allocator_tutorial_pmr.cpp. + +Writing an example main +----------------------- + +Once you have written a valid C++ allocator, you must pass it as a shared pointer to your publisher, subscriber, and executor. +But first, we'll declare a few aliases to shorten the names. + +.. code-block:: c++ + + using Alloc = std::pmr::polymorphic_allocator; + using MessageAllocTraits = + rclcpp::allocator::AllocRebind; + using MessageAlloc = MessageAllocTraits::allocator_type; + using MessageDeleter = rclcpp::allocator::Deleter; + using MessageUniquePtr = std::unique_ptr; + +Now we can create our resources with the custom allocator: + +.. code-block:: c++ + + CustomMemoryResource mem_resource{}; + auto alloc = std::make_shared(&mem_resource); + rclcpp::PublisherOptionsWithAllocator publisher_options; + publisher_options.allocator = alloc; + auto publisher = node->create_publisher( + "allocator_tutorial", 10, publisher_options); + + rclcpp::SubscriptionOptionsWithAllocator subscription_options; + subscription_options.allocator = alloc; + auto msg_mem_strat = std::make_shared< + rclcpp::message_memory_strategy::MessageMemoryStrategy< + std_msgs::msg::UInt32, Alloc>>(alloc); + auto subscriber = node->create_subscription( + "allocator_tutorial", 10, callback, subscription_options, msg_mem_strat); + + rclcpp::ExecutorOptions options; + rclcpp::executors::SingleThreadedExecutor executor(options); + +You must also instantiate a custom deleter and allocator for use when allocating messages: + +.. code-block:: c++ + + MessageDeleter message_deleter; + MessageAlloc message_alloc = *alloc; + rclcpp::allocator::set_allocator_for_deleter(&message_deleter, &message_alloc); + +Once you've add the node to the executor, it is time to spin. +We'll use the custom allocator to allocate each message: + +.. code-block:: c++ + + uint32_t i = 0; + while (rclcpp::ok()) { + auto ptr = MessageAllocTraits::allocate(message_alloc, 1); + MessageAllocTraits::construct(message_alloc, ptr); + MessageUniquePtr msg(ptr, message_deleter); + msg->data = i; + ++i; + publisher->publish(std::move(msg)); + rclcpp::sleep_for(10ms); + executor.spin_some(); + } + +Passing an allocator to the intra-process pipeline +-------------------------------------------------- + +Even though we instantiated a publisher and subscriber in the same process, we aren't using the intra-process pipeline yet. + +The IntraProcessManager is a class that is usually hidden from the user, but in order to pass a custom allocator to it we need to expose it by getting it from the rclcpp Context. +The IntraProcessManager makes use of several standard library structures, so without a custom allocator it will call the default ``new``. + +.. code-block:: c++ + + auto context = rclcpp::contexts::get_global_default_context(); + auto options = rclcpp::NodeOptions() + .context(context) + .use_intra_process_comms(true); + auto node = rclcpp::Node::make_shared("allocator_example", options); + +Make sure to instantiate publishers and subscribers AFTER constructing the node in this way. + +Testing and verifying the code +------------------------------ + +How do you know that your custom allocator is actually getting called? + +The obvious thing to do would be to count the calls made to your custom allocator's ``allocate`` and ``deallocate`` functions and compare that to the calls to ``new`` and ``delete``. + +Adding counting to the custom allocator is easy: + +.. code-block:: c++ + + void * do_allocate(std::size_t size, std::size_t alignment) override + { + // ... + num_allocs++; + // ... + } + + void do_deallocate( + void * p, std::size_t bytes, + std::size_t alignment) override + { + // ... + num_deallocs++; + // ... + } + +You can also override the global ``new`` and ``delete`` operators: + +.. code-block:: c++ + + void * operator new(std::size_t size) + { + if (is_running) { + global_runtime_allocs++; + } + return std::malloc(size); + } + + void operator delete(void * ptr, size_t) noexcept + { + if (ptr != nullptr) { + if (is_running) { + global_runtime_deallocs++; + } + std::free(ptr); + } + } + + void operator delete(void * ptr) noexcept + { + if (ptr != nullptr) { + if (is_running) { + global_runtime_deallocs++; + } + std::free(ptr); + } + } + +where the variables we are incrementing are just global static integers, and ``is_running`` is a global static boolean that gets toggled right before the call to ``spin``. + +The `example executable `__ prints the value of the variables. +To run the example executable, use: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp allocator_tutorial + +or, to run the example with the intra-process pipeline on: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp allocator_tutorial intra + Global new was called 15590 times during spin + Global delete was called 15590 times during spin + Allocator new was called 27284 times during spin + Allocator delete was called 27281 times during spin + +We've caught about 2/3 of the allocations/deallocations that happen on the execution path, but where do the remaining 1/3 come from? + +As a matter of fact, these allocations/deallocations originate in the underlying DDS implementation used in this example. + +Proving this is out of the scope of this tutorial, but you can check out the test for the allocation path that gets run as part of the ROS 2 continuous integration testing, which backtraces through the code and figures out whether certain function calls originate in the rmw implementation or in a DDS implementation: + +https://github.com/ros2/realtime_support/blob/{REPOS_FILE_BRANCH}/tlsf_cpp/test/test_tlsf.cpp#L41 + +Note that this test is not using the custom allocator we just created, but the TLSF allocator (see below). + +The TLSF allocator +------------------ + +ROS 2 offers support for the TLSF (Two Level Segregate Fit) allocator, which was designed to meet real-time requirements: + +https://github.com/ros2/realtime_support/tree/{REPOS_FILE_BRANCH}/tlsf_cpp + +For more information about TLSF, see `this page via Universitat Politècnica de València `_. + +Note that the TLSF allocator is licensed under a dual-GPL/LGPL license. + +A full working example using the TLSF allocator is here: +https://github.com/ros2/realtime_support/blob/{REPOS_FILE_BRANCH}/tlsf_cpp/example/allocator_example.cpp \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst index 26c4e61ad69..558609fe765 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst @@ -1,390 +1,391 @@ -.. _Colcon: - -.. redirect-from:: - - Colcon-Tutorial - Tutorials/Colcon-Tutorial - -Using ``colcon`` to build packages -================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -**Goal:** Build a ROS 2 workspace with ``colcon``. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -This is a brief tutorial on how to create and build a ROS 2 workspace with ``colcon``. -It is a practical tutorial and not designed to replace the core documentation. - -Background ----------- - -``colcon`` is an iteration on the ROS build tools ``catkin_make``, ``catkin_make_isolated``, ``catkin_tools`` and ``ament_tools``. -For more information on the design of colcon see `this document `__. - -The source code can be found in the `colcon GitHub organization `__. - -Prerequisites -------------- - -Install colcon -^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ sudo apt install python3-colcon-common-extensions - - .. group-tab:: macOS - - .. code-block:: console - - $ python3 -m pip install colcon-common-extensions - - .. group-tab:: Windows - - .. code-block:: console - - $ pip install -U colcon-common-extensions - - -Install ROS 2 -^^^^^^^^^^^^^ - -To build the samples, you will need to install ROS 2. - -Follow the :doc:`installation instructions <../../Installation>`. - -.. attention:: If installing from deb packages, this tutorial requires the :ref:`desktop installation `. - -Basics ------- - -A ROS workspace is a directory with a particular structure. -Commonly there is a ``src`` subdirectory. -Inside that subdirectory is where the source code of ROS packages will be located. -Typically the directory starts otherwise empty. - -colcon performs out-of-source builds. -By default it will create the following directories as peers of the ``src`` directory: - -* The ``build`` directory will be where intermediate files are stored. - For each package a subfolder will be created in which e.g. CMake is being invoked. -* The ``install`` directory is where each package will be installed to. - By default each package will be installed into a separate subdirectory. -* The ``log`` directory contains various logging information about each colcon invocation. - -.. note:: Compared to catkin there is no ``devel`` directory. - -Create a workspace -^^^^^^^^^^^^^^^^^^ - -First, create a directory (``ros2_ws``) to contain our workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws - - .. group-tab:: Windows - - .. code-block:: console - - $ md \dev\ros2_ws\src - $ cd \dev\ros2_ws - -At this point the workspace contains a single empty directory ``src``: - -.. code-block:: bash - - . - └── src - - 1 directory, 0 files - -Add some sources -^^^^^^^^^^^^^^^^ - -Let's clone the `examples `__ repository into the ``src`` directory of the workspace: - -.. code-block:: console - - $ git clone https://github.com/ros2/examples src/examples -b {REPOS_FILE_BRANCH} - -Now the workspace should have the source code to the ROS 2 examples: - -.. code-block:: bash - - . - └── src - └── examples - ├── CONTRIBUTING.md - ├── LICENSE - ├── rclcpp - ├── rclpy - └── README.md - - 4 directories, 3 files - -Source an underlay -^^^^^^^^^^^^^^^^^^ - -It is important that we have sourced the environment for an existing ROS 2 installation that will provide our workspace with the necessary build dependencies for the example packages. -This is achieved by sourcing the setup script provided by a binary installation or a source installation, i.e. another colcon workspace (see :doc:`Installation <../../Installation>`). -We call this environment an **underlay**. - -Our workspace, ``ros2_ws``, will be an **overlay** on top of the existing ROS 2 installation. -In general, it is recommended to use an overlay when you plan to iterate on a small number of packages, rather than putting all of your packages into the same workspace. - -Build the workspace -^^^^^^^^^^^^^^^^^^^ - -.. attention:: - - To build packages on Windows you need to be in a Visual Studio environment, see :ref:`Building the ROS 2 Code ` for more details. - -In the root of the workspace, run ``colcon build``. -Since build types such as ``ament_cmake`` do not support the concept of the ``devel`` space and require the package to be installed, colcon supports the option ``--symlink-install``. -This allows the installed files to be changed by changing the files in the ``source`` space (e.g. Python files or other non-compiled resources) for faster iteration. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --symlink-install - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --symlink-install - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install - - Windows doesn't allow long paths, so ``merge-install`` will combine all the paths into the ``install`` directory. - On Windows, you need special permissions to create symbolic links, so ``--symlink-install`` is not used by default. - To use it, you need to run the command as administrator or enable developer mode in system settings. - -.. tip:: - - Running ``colcon build`` may freeze the screen and mouse of systems that are CPU-, RAM- and I/O-limited (e.g., Raspberry Pi), so it might be useful to use the ``--executor sequential`` argument to build the packages one by one instead of using parallelism. - See the `colcon documentation `_ for more arguments as needed. - -After the build is finished, we should see the ``build``, ``install``, and ``log`` directories: - -.. code-block:: bash - - . - ├── build - ├── install - ├── log - └── src - - 4 directories, 0 files - -.. _colcon-run-the-tests: - -Run tests -^^^^^^^^^ - -To run tests for the packages we just built, run the following: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon test - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon test - - .. group-tab:: Windows - - Remember to use a ``x64 Native Tools Command Prompt for VS 2019`` for executing the following command, as we are going to build a workspace. - - .. code-block:: console - - $ colcon test --merge-install - - You also need to specify ``--merge-install`` here since we used it for building above. - -.. _colcon-tutorial-source-the-environment: - -Source the environment -^^^^^^^^^^^^^^^^^^^^^^ - -When colcon has completed building successfully, the output will be in the ``install`` directory. -Before you can use any of the installed executables or libraries, you will need to add them to your path and library paths. -colcon will have generated bash/bat files in the ``install`` directory to help set up the environment. -These files will add all of the required elements to your path and library paths as well as provide any bash or shell commands exported by packages. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line interface: - - .. code-block:: console - - $ call install\setup.bat - - Or with Powershell: - - .. code-block:: console - - $ install\setup.ps1 - -Try a demo -^^^^^^^^^^ - -With the environment sourced, we can run executables built by colcon. -Let's run a subscriber node from the examples: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function - -In another terminal, let's run a publisher node (don't forget to source the setup script): - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_publisher publisher_member_function - -You should see messages from the publisher and subscriber with numbers incrementing. - -Create your own package ------------------------ - -colcon uses the ``package.xml`` specification defined in `REP 149 `__ (`format 2 `__ is also supported). - -colcon supports multiple build types. -The recommended build types are ``ament_cmake`` and ``ament_python``. -Also supported are pure ``cmake`` packages. - -An example of an ``ament_python`` build is the `ament_index_python package `__ , where the setup.py is the primary entry point for building. - -A package such as `demo_nodes_cpp `__ uses the ``ament_cmake`` build type, and uses CMake as the build tool. - -For convenience, you can use the tool ``ros2 pkg create`` to create a new package based on a template. -A full description of creating a package and how to use ``ros2 pkg create`` is in the upcoming tutorial :doc:`create a package <./Creating-Your-First-ROS2-Package>`. - -.. note:: For ``catkin`` users, this is the equivalent of ``catkin_create_package``. - -Setup ``colcon_cd`` -------------------- - -The command ``colcon_cd`` allows you to quickly change the current working directory of your shell to the directory of a package. -As an example ``colcon_cd some_ros_package`` would quickly bring you to the directory ``~/ros2_ws/src/some_ros_package``. -To set up ``colcon_cd`` you need to run the following commands to modify your shell startup script: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc - $ echo "export _colcon_cd_root=/opt/ros/{DISTRO}/" >> ~/.bashrc - - .. group-tab:: macOS - - .. code-block:: console - - $ echo "source /usr/local/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc - $ echo "export _colcon_cd_root=~/ros2_install" >> ~/.bashrc - - .. group-tab:: Windows - - Not yet available - -Depending on the way you installed ``colcon_cd`` and where your workspace is, the instructions above may vary, please refer to `the documentation `__ for more details. -To undo this in Linux and macOS, locate your system's shell startup script and remove the appended source and export commands. - -Setup ``colcon`` tab completion -------------------------------- - -The ``colcon`` command supports command completion for bash and bash-like shells. -The ``colcon-argcomplete`` package must be installed, and `some setup may be required `__ to make it work. - -Tips ----- - -* If you do not want to build a specific package, then place an empty file named ``COLCON_IGNORE`` in the directory and it will not be indexed. - -* If you want to avoid configuring and building tests in CMake packages you can pass: ``--cmake-args -DBUILD_TESTING=0``. - -* If you want to run a single particular test from a package: - - .. code-block:: console - - $ colcon test --packages-select YOUR_PKG_NAME --ctest-args -R YOUR_TEST_IN_PKG - -Setup ``colcon`` mixins ------------------------ - -Various command line options are tedious to write and/or difficult to remember. - -For example, to change the CMake build type to debug, you normally use: - -.. code-block:: console - - $ colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug - -To make common command line options easier to invoke this repository makes these "shortcuts" available. - -To install the default colcon mixins, run the following: - -.. code-block:: console - - $ colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml - $ colcon mixin update default - -Then, try out using the ``debug`` mixin: - -.. code-block:: console - - $ colcon build --mixin debug - -For more details, see the `colcon mixin repository `__. +.. _Colcon: + +.. redirect-from:: + + Colcon-Tutorial + Tutorials/Colcon-Tutorial + Tutorials/Beginner-Client-Libraries/Colcon-Tutorial + +Using ``colcon`` to build packages +================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +**Goal:** Build a ROS 2 workspace with ``colcon``. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +This is a brief tutorial on how to create and build a ROS 2 workspace with ``colcon``. +It is a practical tutorial and not designed to replace the core documentation. + +Background +---------- + +``colcon`` is an iteration on the ROS build tools ``catkin_make``, ``catkin_make_isolated``, ``catkin_tools`` and ``ament_tools``. +For more information on the design of colcon see `this document `__. + +The source code can be found in the `colcon GitHub organization `__. + +Prerequisites +------------- + +Install colcon +^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ sudo apt install python3-colcon-common-extensions + + .. group-tab:: macOS + + .. code-block:: console + + $ python3 -m pip install colcon-common-extensions + + .. group-tab:: Windows + + .. code-block:: console + + $ pip install -U colcon-common-extensions + + +Install ROS 2 +^^^^^^^^^^^^^ + +To build the samples, you will need to install ROS 2. + +Follow the :doc:`installation instructions <../../../Get-Started/Installation>`. + +.. attention:: If installing from deb packages, this tutorial requires the :ref:`desktop installation `. + +Basics +------ + +A ROS workspace is a directory with a particular structure. +Commonly there is a ``src`` subdirectory. +Inside that subdirectory is where the source code of ROS packages will be located. +Typically the directory starts otherwise empty. + +colcon performs out-of-source builds. +By default it will create the following directories as peers of the ``src`` directory: + +* The ``build`` directory will be where intermediate files are stored. + For each package a subfolder will be created in which e.g. CMake is being invoked. +* The ``install`` directory is where each package will be installed to. + By default each package will be installed into a separate subdirectory. +* The ``log`` directory contains various logging information about each colcon invocation. + +.. note:: Compared to catkin there is no ``devel`` directory. + +Create a workspace +^^^^^^^^^^^^^^^^^^ + +First, create a directory (``ros2_ws``) to contain our workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws + + .. group-tab:: Windows + + .. code-block:: console + + $ md \dev\ros2_ws\src + $ cd \dev\ros2_ws + +At this point the workspace contains a single empty directory ``src``: + +.. code-block:: bash + + . + └── src + + 1 directory, 0 files + +Add some sources +^^^^^^^^^^^^^^^^ + +Let's clone the `examples `__ repository into the ``src`` directory of the workspace: + +.. code-block:: console + + $ git clone https://github.com/ros2/examples src/examples -b {REPOS_FILE_BRANCH} + +Now the workspace should have the source code to the ROS 2 examples: + +.. code-block:: bash + + . + └── src + └── examples + ├── CONTRIBUTING.md + ├── LICENSE + ├── rclcpp + ├── rclpy + └── README.md + + 4 directories, 3 files + +Source an underlay +^^^^^^^^^^^^^^^^^^ + +It is important that we have sourced the environment for an existing ROS 2 installation that will provide our workspace with the necessary build dependencies for the example packages. +This is achieved by sourcing the setup script provided by a binary installation or a source installation, i.e. another colcon workspace (see :doc:`Installation <../../../Get-Started/Installation>`). +We call this environment an **underlay**. + +Our workspace, ``ros2_ws``, will be an **overlay** on top of the existing ROS 2 installation. +In general, it is recommended to use an overlay when you plan to iterate on a small number of packages, rather than putting all of your packages into the same workspace. + +Build the workspace +^^^^^^^^^^^^^^^^^^^ + +.. attention:: + + To build packages on Windows you need to be in a Visual Studio environment, see :ref:`Building the ROS 2 Code ` for more details. + +In the root of the workspace, run ``colcon build``. +Since build types such as ``ament_cmake`` do not support the concept of the ``devel`` space and require the package to be installed, colcon supports the option ``--symlink-install``. +This allows the installed files to be changed by changing the files in the ``source`` space (e.g. Python files or other non-compiled resources) for faster iteration. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --symlink-install + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --symlink-install + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install + + Windows doesn't allow long paths, so ``merge-install`` will combine all the paths into the ``install`` directory. + On Windows, you need special permissions to create symbolic links, so ``--symlink-install`` is not used by default. + To use it, you need to run the command as administrator or enable developer mode in system settings. + +.. tip:: + + Running ``colcon build`` may freeze the screen and mouse of systems that are CPU-, RAM- and I/O-limited (e.g., Raspberry Pi), so it might be useful to use the ``--executor sequential`` argument to build the packages one by one instead of using parallelism. + See the `colcon documentation `_ for more arguments as needed. + +After the build is finished, we should see the ``build``, ``install``, and ``log`` directories: + +.. code-block:: bash + + . + ├── build + ├── install + ├── log + └── src + + 4 directories, 0 files + +.. _colcon-run-the-tests: + +Run tests +^^^^^^^^^ + +To run tests for the packages we just built, run the following: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon test + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon test + + .. group-tab:: Windows + + Remember to use a ``x64 Native Tools Command Prompt for VS 2019`` for executing the following command, as we are going to build a workspace. + + .. code-block:: console + + $ colcon test --merge-install + + You also need to specify ``--merge-install`` here since we used it for building above. + +.. _colcon-tutorial-source-the-environment: + +Source the environment +^^^^^^^^^^^^^^^^^^^^^^ + +When colcon has completed building successfully, the output will be in the ``install`` directory. +Before you can use any of the installed executables or libraries, you will need to add them to your path and library paths. +colcon will have generated bash/bat files in the ``install`` directory to help set up the environment. +These files will add all of the required elements to your path and library paths as well as provide any bash or shell commands exported by packages. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line interface: + + .. code-block:: console + + $ call install\setup.bat + + Or with Powershell: + + .. code-block:: console + + $ install\setup.ps1 + +Try a demo +^^^^^^^^^^ + +With the environment sourced, we can run executables built by colcon. +Let's run a subscriber node from the examples: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function + +In another terminal, let's run a publisher node (don't forget to source the setup script): + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_publisher publisher_member_function + +You should see messages from the publisher and subscriber with numbers incrementing. + +Create your own package +----------------------- + +colcon uses the ``package.xml`` specification defined in `REP 149 `__ (`format 2 `__ is also supported). + +colcon supports multiple build types. +The recommended build types are ``ament_cmake`` and ``ament_python``. +Also supported are pure ``cmake`` packages. + +An example of an ``ament_python`` build is the `ament_index_python package `__ , where the setup.py is the primary entry point for building. + +A package such as `demo_nodes_cpp `__ uses the ``ament_cmake`` build type, and uses CMake as the build tool. + +For convenience, you can use the tool ``ros2 pkg create`` to create a new package based on a template. +A full description of creating a package and how to use ``ros2 pkg create`` is in the upcoming tutorial :doc:`create a package `. + +.. note:: For ``catkin`` users, this is the equivalent of ``catkin_create_package``. + +Setup ``colcon_cd`` +------------------- + +The command ``colcon_cd`` allows you to quickly change the current working directory of your shell to the directory of a package. +As an example ``colcon_cd some_ros_package`` would quickly bring you to the directory ``~/ros2_ws/src/some_ros_package``. +To set up ``colcon_cd`` you need to run the following commands to modify your shell startup script: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc + $ echo "export _colcon_cd_root=/opt/ros/{DISTRO}/" >> ~/.bashrc + + .. group-tab:: macOS + + .. code-block:: console + + $ echo "source /usr/local/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc + $ echo "export _colcon_cd_root=~/ros2_install" >> ~/.bashrc + + .. group-tab:: Windows + + Not yet available + +Depending on the way you installed ``colcon_cd`` and where your workspace is, the instructions above may vary, please refer to `the documentation `__ for more details. +To undo this in Linux and macOS, locate your system's shell startup script and remove the appended source and export commands. + +Setup ``colcon`` tab completion +------------------------------- + +The ``colcon`` command supports command completion for bash and bash-like shells. +The ``colcon-argcomplete`` package must be installed, and `some setup may be required `__ to make it work. + +Tips +---- + +* If you do not want to build a specific package, then place an empty file named ``COLCON_IGNORE`` in the directory and it will not be indexed. + +* If you want to avoid configuring and building tests in CMake packages you can pass: ``--cmake-args -DBUILD_TESTING=0``. + +* If you want to run a single particular test from a package: + + .. code-block:: console + + $ colcon test --packages-select YOUR_PKG_NAME --ctest-args -R YOUR_TEST_IN_PKG + +Setup ``colcon`` mixins +----------------------- + +Various command line options are tedious to write and/or difficult to remember. + +For example, to change the CMake build type to debug, you normally use: + +.. code-block:: console + + $ colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug + +To make common command line options easier to invoke this repository makes these "shortcuts" available. + +To install the default colcon mixins, run the following: + +.. code-block:: console + + $ colcon mixin add default https://raw.githubusercontent.com/colcon/colcon-mixin-repository/master/index.yaml + $ colcon mixin update default + +Then, try out using the ``debug`` mixin: + +.. code-block:: console + + $ colcon build --mixin debug + +For more details, see the `colcon mixin repository `__. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst index a3c924f35c3..925a819732a 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst @@ -1,277 +1,278 @@ -.. redirect-from:: - - How-To-Guides/Disabling-ZeroCopy-loaned-messages - -Configure Zero Copy Loaned Messages -=================================== - -.. contents:: Contents - :depth: 2 - :local: - -Overview --------- - -ROS 2 loaned messages and zero copy data sharing are mechanisms designed to improve performance by minimizing data copying. -When using loaned messages, the RMW middleware can allocate and manage message memory, allowing publishers and subscribers to share data buffers directly. -This reduces the overhead associated with memory allocation and data copying, leading to lower latency and higher throughput. -Zero copy data sharing is particularly beneficial in high-performance applications where large amounts of data need to be transmitted efficiently. - -See more details for `Loaned Messages `__ article for details on how loaned messages work. - -RMW Support ------------ - -Loaned messages require RMW implementation support. - -.. list-table:: Loaned Messages Support Status - :widths: 25 25 25 - - * - RMW Implementation - - Support Status - - Documentation - * - rmw_fastrtps - - supported - - `Enable Zero Copy Data Sharing `__ - * - rmw_connextdds - - not supported - - N.A - * - rmw_cyclonedds - - not supported - - N.A - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Using Loaned Messages ---------------------- - -Loaned messages on the publisher are used by default when the underlying RMW implementation supports them. -If the RMW implementation does not support loaned messages, the messages will be allocated with the allocator instance provided by the publisher. -The `talker_loaned_message example `__ demonstrates how to create a ROS 2 publisher that uses loaned messages to publish data efficiently without copying the message data. - -.. code-block:: c++ - - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp_components/register_node_macro.hpp" - - #include "std_msgs/msg/float64.hpp" - #include "std_msgs/msg/string.hpp" - - #include "demo_nodes_cpp/visibility_control.h" - - using namespace std::chrono_literals; - - namespace demo_nodes_cpp - { - // Create a Talker class that subclasses the generic rclcpp::Node base class. - // The main function below will instantiate the class as a ROS node. - class LoanedMessageTalker : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit LoanedMessageTalker(const rclcpp::NodeOptions & options) - : Node("loaned_message_talker", options) - { - // Create a function for when messages are to be sent. - setvbuf(stdout, NULL, _IONBF, BUFSIZ); - - // We differentiate in this demo between two fundamental message types - POD and non-POD - // PODs are plain old data types, meaning all the data of its type is encapsulated within - // the structure and does not require any heap allocation or dynamic resizing. - // non-PODs are essentially the opposite where the data size changes during runtime. - // All containers (including Strings) are such non-PODs. - // Most middlewares won't be able to loan non-POD datatypes. - // We thus feature two publishers in this demo where both, a POD and non-POD message - // will be used to publish data. - // The take-away for this is that the rclcpp API for message loaning can cope with - // either POD and non-POD transparently. - auto publish_message = - [this]() -> void - { - // We loan a message here and don't allocate the memory on the stack. - // For middlewares which support message loaning, this means the middleware - // completely owns the memory for this message. - // This enables a zero-copy message transport for middlewares with shared memory - // capabilities. - // If the middleware doesn't support this, the loaned message will be allocated - // with the allocator instance provided by the publisher. - auto pod_loaned_msg = pod_pub_->borrow_loaned_message(); - auto pod_msg_data = static_cast(count_); - pod_loaned_msg.get().data = pod_msg_data; - RCLCPP_INFO(this->get_logger(), "Publishing: '%f'", pod_msg_data); - // As the middleware might own the memory allocated for this message, - // a call to publish explicitly transfers ownership back to the middleware. - // The loaned message instance is thus no longer valid after a call to publish. - pod_pub_->publish(std::move(pod_loaned_msg)); - - // Similar as in the above case, we ask the middleware to loan a message. - // As most likely the middleware won't be able to loan a message for a non-POD - // data type, the memory for the message will be allocated on the heap within - // the scope of the `LoanedMessage` instance. - // After the call to `publish()`, the message will be correctly allocated. - auto non_pod_loaned_msg = non_pod_pub_->borrow_loaned_message(); - auto non_pod_msg_data = "Hello World: " + std::to_string(count_); - non_pod_loaned_msg.get().data = non_pod_msg_data; - RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", non_pod_msg_data.c_str()); - non_pod_pub_->publish(std::move(non_pod_loaned_msg)); - count_++; - }; - - // Create a publisher with a custom Quality of Service profile. - rclcpp::QoS qos(rclcpp::KeepLast(7)); - pod_pub_ = this->create_publisher("chatter_pod", qos); - non_pod_pub_ = this->create_publisher("chatter", qos); - - // Use a timer to schedule periodic message publishing. - timer_ = this->create_wall_timer(1s, publish_message); - } - - private: - size_t count_ = 1; - rclcpp::Publisher::SharedPtr pod_pub_; - rclcpp::Publisher::SharedPtr non_pod_pub_; - rclcpp::TimerBase::SharedPtr timer_; - }; - - } // namespace demo_nodes_cpp - -This example tries to loan two types of messages from the RMW implementation with calling ``borrow_loaned_message()``. -The one is a Plain Old Data (POD) message type, ``std_msgs::msg::Float64``, and the other is a non-Plain Old Data (POD) message type, ``std_msgs::msg::String``. -The requirements for loaned messages are that the message type is a Plain Old Data (POD) type for `rmw_fastrtps `__ as shown below. - -We can run the demo by running the ``ros2 run demo_nodes_cpp talker_loaned_message`` executable (don't forget to source the setup file first): - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker_loaned_message - [INFO] [1741063656.446278828] [loaned_message_talker]: Publishing: '1.000000' - [INFO] [1741063656.446705580] [rclcpp]: Currently used middleware cannot loan messages. Local allocator will be used. - [INFO] [1741063656.446754794] [loaned_message_talker]: Publishing: 'Hello World: 1' - [INFO] [1741063657.446232119] [loaned_message_talker]: Publishing: '2.000000' - [INFO] [1741063657.446401820] [loaned_message_talker]: Publishing: 'Hello World: 2' - [INFO] [1741063658.446217220] [loaned_message_talker]: Publishing: '3.000000' - [INFO] [1741063658.446383011] [loaned_message_talker]: Publishing: 'Hello World: 3' - [...] - -If the RMW implementation does not support loaned messages, all the messages will be allocated with the allocator instance provided by the publisher. -We can try that by executing ``RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp talker_loaned_message``. - -.. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp talker_loaned_message - [INFO] [1741064109.676860153] [rclcpp]: Currently used middleware cannot loan messages. Local allocator will be used. - [INFO] [1741064109.677043250] [loaned_message_talker]: Publishing: '1.000000' - [INFO] [1741064109.677185724] [rclcpp]: Currently used middleware cannot loan messages. Local allocator will be used. - [INFO] [1741064109.677224058] [loaned_message_talker]: Publishing: 'Hello World: 1' - [INFO] [1741064110.676842111] [loaned_message_talker]: Publishing: '2.000000' - [INFO] [1741064110.677008774] [loaned_message_talker]: Publishing: 'Hello World: 2' - [INFO] [1741064111.676779850] [loaned_message_talker]: Publishing: '3.000000' - [INFO] [1741064111.676937613] [loaned_message_talker]: Publishing: 'Hello World: 3' - [...] - -As we can see, both messages are published successfully, but the messages are allocated with the local allocator instance provided by the publisher because the RMW implementation does not support loaned messages. - -How to disable Loaned Messages ------------------------------- - -Publishers -~~~~~~~~~~ - -By default, *Loaned Messages* will try to borrow the memory from underlying middleware if it supports *Loaned Messages*. -The ``ROS_DISABLE_LOANED_MESSAGES`` environment variable can be used to disable *Loaned Messages*, and fallback to normal publisher behavior, without any code changes or middleware configuration. -You can set the environment variable with the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISABLE_LOANED_MESSAGES=1 - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_DISABLE_LOANED_MESSAGES=1" >> ~/.bashrc - - .. group-tab:: macOS - - .. code-block:: console - - $ export ROS_DISABLE_LOANED_MESSAGES=1 - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_DISABLE_LOANED_MESSAGES=1" >> ~/.bash_profile - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISABLE_LOANED_MESSAGES=1 - - If you want to make this permanent between shell sessions, also run: - - .. code-block:: console - - $ setx ROS_DISABLE_LOANED_MESSAGES 1 - - -Subscriptions -~~~~~~~~~~~~~ - -Currently using *Loaned Messages* is not safe on subscription, see more details in `rmw issue `_ and `rclcpp issue `_. -Because of this, by default *Loaned Messages* is ``disabled`` on subscription with `Set disable loan to on by default `_ even though underlying middleware supports that. -To enable *Loaned Messages* on subscription, you need to set the environment variable ``ROS_DISABLE_LOANED_MESSAGES`` to ``0`` explicitly. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export ROS_DISABLE_LOANED_MESSAGES=0 - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_DISABLE_LOANED_MESSAGES=0" >> ~/.bashrc - - .. group-tab:: macOS - - .. code-block:: console - - $ export ROS_DISABLE_LOANED_MESSAGES=0 - - To maintain this setting between shell sessions, you can add the command to your shell startup script: - - .. code-block:: console - - $ echo "export ROS_DISABLE_LOANED_MESSAGES=0" >> ~/.bash_profile - - .. group-tab:: Windows - - .. code-block:: console - - $ set ROS_DISABLE_LOANED_MESSAGES=0 - - If you want to make this permanent between shell sessions, also run: - - .. code-block:: console - - $ setx ROS_DISABLE_LOANED_MESSAGES 0 +.. redirect-from:: + + How-To-Guides/Disabling-ZeroCopy-loaned-messages + How-To-Guides/Configure-ZeroCopy-loaned-messages + +Configure Zero Copy Loaned Messages +=================================== + +.. contents:: Contents + :depth: 2 + :local: + +Overview +-------- + +ROS 2 loaned messages and zero copy data sharing are mechanisms designed to improve performance by minimizing data copying. +When using loaned messages, the RMW middleware can allocate and manage message memory, allowing publishers and subscribers to share data buffers directly. +This reduces the overhead associated with memory allocation and data copying, leading to lower latency and higher throughput. +Zero copy data sharing is particularly beneficial in high-performance applications where large amounts of data need to be transmitted efficiently. + +See more details for `Loaned Messages `__ article for details on how loaned messages work. + +RMW Support +----------- + +Loaned messages require RMW implementation support. + +.. list-table:: Loaned Messages Support Status + :widths: 25 25 25 + + * - RMW Implementation + - Support Status + - Documentation + * - rmw_fastrtps + - supported + - `Enable Zero Copy Data Sharing `__ + * - rmw_connextdds + - not supported + - N.A + * - rmw_cyclonedds + - not supported + - N.A + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Using Loaned Messages +--------------------- + +Loaned messages on the publisher are used by default when the underlying RMW implementation supports them. +If the RMW implementation does not support loaned messages, the messages will be allocated with the allocator instance provided by the publisher. +The `talker_loaned_message example `__ demonstrates how to create a ROS 2 publisher that uses loaned messages to publish data efficiently without copying the message data. + +.. code-block:: c++ + + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp_components/register_node_macro.hpp" + + #include "std_msgs/msg/float64.hpp" + #include "std_msgs/msg/string.hpp" + + #include "demo_nodes_cpp/visibility_control.h" + + using namespace std::chrono_literals; + + namespace demo_nodes_cpp + { + // Create a Talker class that subclasses the generic rclcpp::Node base class. + // The main function below will instantiate the class as a ROS node. + class LoanedMessageTalker : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit LoanedMessageTalker(const rclcpp::NodeOptions & options) + : Node("loaned_message_talker", options) + { + // Create a function for when messages are to be sent. + setvbuf(stdout, NULL, _IONBF, BUFSIZ); + + // We differentiate in this demo between two fundamental message types - POD and non-POD + // PODs are plain old data types, meaning all the data of its type is encapsulated within + // the structure and does not require any heap allocation or dynamic resizing. + // non-PODs are essentially the opposite where the data size changes during runtime. + // All containers (including Strings) are such non-PODs. + // Most middlewares won't be able to loan non-POD datatypes. + // We thus feature two publishers in this demo where both, a POD and non-POD message + // will be used to publish data. + // The take-away for this is that the rclcpp API for message loaning can cope with + // either POD and non-POD transparently. + auto publish_message = + [this]() -> void + { + // We loan a message here and don't allocate the memory on the stack. + // For middlewares which support message loaning, this means the middleware + // completely owns the memory for this message. + // This enables a zero-copy message transport for middlewares with shared memory + // capabilities. + // If the middleware doesn't support this, the loaned message will be allocated + // with the allocator instance provided by the publisher. + auto pod_loaned_msg = pod_pub_->borrow_loaned_message(); + auto pod_msg_data = static_cast(count_); + pod_loaned_msg.get().data = pod_msg_data; + RCLCPP_INFO(this->get_logger(), "Publishing: '%f'", pod_msg_data); + // As the middleware might own the memory allocated for this message, + // a call to publish explicitly transfers ownership back to the middleware. + // The loaned message instance is thus no longer valid after a call to publish. + pod_pub_->publish(std::move(pod_loaned_msg)); + + // Similar as in the above case, we ask the middleware to loan a message. + // As most likely the middleware won't be able to loan a message for a non-POD + // data type, the memory for the message will be allocated on the heap within + // the scope of the `LoanedMessage` instance. + // After the call to `publish()`, the message will be correctly allocated. + auto non_pod_loaned_msg = non_pod_pub_->borrow_loaned_message(); + auto non_pod_msg_data = "Hello World: " + std::to_string(count_); + non_pod_loaned_msg.get().data = non_pod_msg_data; + RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", non_pod_msg_data.c_str()); + non_pod_pub_->publish(std::move(non_pod_loaned_msg)); + count_++; + }; + + // Create a publisher with a custom Quality of Service profile. + rclcpp::QoS qos(rclcpp::KeepLast(7)); + pod_pub_ = this->create_publisher("chatter_pod", qos); + non_pod_pub_ = this->create_publisher("chatter", qos); + + // Use a timer to schedule periodic message publishing. + timer_ = this->create_wall_timer(1s, publish_message); + } + + private: + size_t count_ = 1; + rclcpp::Publisher::SharedPtr pod_pub_; + rclcpp::Publisher::SharedPtr non_pod_pub_; + rclcpp::TimerBase::SharedPtr timer_; + }; + + } // namespace demo_nodes_cpp + +This example tries to loan two types of messages from the RMW implementation with calling ``borrow_loaned_message()``. +The one is a Plain Old Data (POD) message type, ``std_msgs::msg::Float64``, and the other is a non-Plain Old Data (POD) message type, ``std_msgs::msg::String``. +The requirements for loaned messages are that the message type is a Plain Old Data (POD) type for `rmw_fastrtps `__ as shown below. + +We can run the demo by running the ``ros2 run demo_nodes_cpp talker_loaned_message`` executable (don't forget to source the setup file first): + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker_loaned_message + [INFO] [1741063656.446278828] [loaned_message_talker]: Publishing: '1.000000' + [INFO] [1741063656.446705580] [rclcpp]: Currently used middleware cannot loan messages. Local allocator will be used. + [INFO] [1741063656.446754794] [loaned_message_talker]: Publishing: 'Hello World: 1' + [INFO] [1741063657.446232119] [loaned_message_talker]: Publishing: '2.000000' + [INFO] [1741063657.446401820] [loaned_message_talker]: Publishing: 'Hello World: 2' + [INFO] [1741063658.446217220] [loaned_message_talker]: Publishing: '3.000000' + [INFO] [1741063658.446383011] [loaned_message_talker]: Publishing: 'Hello World: 3' + [...] + +If the RMW implementation does not support loaned messages, all the messages will be allocated with the allocator instance provided by the publisher. +We can try that by executing ``RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp talker_loaned_message``. + +.. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp talker_loaned_message + [INFO] [1741064109.676860153] [rclcpp]: Currently used middleware cannot loan messages. Local allocator will be used. + [INFO] [1741064109.677043250] [loaned_message_talker]: Publishing: '1.000000' + [INFO] [1741064109.677185724] [rclcpp]: Currently used middleware cannot loan messages. Local allocator will be used. + [INFO] [1741064109.677224058] [loaned_message_talker]: Publishing: 'Hello World: 1' + [INFO] [1741064110.676842111] [loaned_message_talker]: Publishing: '2.000000' + [INFO] [1741064110.677008774] [loaned_message_talker]: Publishing: 'Hello World: 2' + [INFO] [1741064111.676779850] [loaned_message_talker]: Publishing: '3.000000' + [INFO] [1741064111.676937613] [loaned_message_talker]: Publishing: 'Hello World: 3' + [...] + +As we can see, both messages are published successfully, but the messages are allocated with the local allocator instance provided by the publisher because the RMW implementation does not support loaned messages. + +How to disable Loaned Messages +------------------------------ + +Publishers +~~~~~~~~~~ + +By default, *Loaned Messages* will try to borrow the memory from underlying middleware if it supports *Loaned Messages*. +The ``ROS_DISABLE_LOANED_MESSAGES`` environment variable can be used to disable *Loaned Messages*, and fallback to normal publisher behavior, without any code changes or middleware configuration. +You can set the environment variable with the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISABLE_LOANED_MESSAGES=1 + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_DISABLE_LOANED_MESSAGES=1" >> ~/.bashrc + + .. group-tab:: macOS + + .. code-block:: console + + $ export ROS_DISABLE_LOANED_MESSAGES=1 + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_DISABLE_LOANED_MESSAGES=1" >> ~/.bash_profile + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISABLE_LOANED_MESSAGES=1 + + If you want to make this permanent between shell sessions, also run: + + .. code-block:: console + + $ setx ROS_DISABLE_LOANED_MESSAGES 1 + + +Subscriptions +~~~~~~~~~~~~~ + +Currently using *Loaned Messages* is not safe on subscription, see more details in `rmw issue `_ and `rclcpp issue `_. +Because of this, by default *Loaned Messages* is ``disabled`` on subscription with `Set disable loan to on by default `_ even though underlying middleware supports that. +To enable *Loaned Messages* on subscription, you need to set the environment variable ``ROS_DISABLE_LOANED_MESSAGES`` to ``0`` explicitly. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export ROS_DISABLE_LOANED_MESSAGES=0 + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_DISABLE_LOANED_MESSAGES=0" >> ~/.bashrc + + .. group-tab:: macOS + + .. code-block:: console + + $ export ROS_DISABLE_LOANED_MESSAGES=0 + + To maintain this setting between shell sessions, you can add the command to your shell startup script: + + .. code-block:: console + + $ echo "export ROS_DISABLE_LOANED_MESSAGES=0" >> ~/.bash_profile + + .. group-tab:: Windows + + .. code-block:: console + + $ set ROS_DISABLE_LOANED_MESSAGES=0 + + If you want to make this permanent between shell sessions, also run: + + .. code-block:: console + + $ setx ROS_DISABLE_LOANED_MESSAGES 0 \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst index 2ade50673cc..010a0d69080 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst @@ -1,404 +1,405 @@ -.. redirect-from:: - - Tutorials/Workspace/Creating-A-Workspace - -.. _ROS2Workspace: - -Creating a workspace -==================== - -**Goal:** Create a workspace and learn how to set up an overlay for development and testing. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -A workspace is a directory containing ROS 2 packages. -Before using ROS 2, it's necessary to source your ROS 2 installation workspace in the terminal you plan to work in. -This makes ROS 2's packages available for you to use in that terminal. - -You also have the option of sourcing an "overlay" - a secondary workspace where you can add new packages without interfering with the existing ROS 2 workspace that you're extending, or "underlay". -Your underlay must contain the dependencies of all the packages in your overlay. -Packages in your overlay will override packages in the underlay. -It's also possible to have several layers of underlays and overlays, with each successive overlay using the packages of its parent underlays. - - -Prerequisites -------------- - -* :doc:`ROS 2 installation <../../../Installation>` -* :doc:`colcon installation <../Colcon-Tutorial>` -* `git installation `__ -* :doc:`turtlesim installation <../../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>` -* Have :doc:`rosdep installed <../../Intermediate/Rosdep>` -* Understanding of basic terminal commands (`here's a guide for Linux `__) -* Text editor of your choice - -Tasks ------ - -1 Source ROS 2 environment -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Your main ROS 2 installation will be your underlay for this tutorial. -(Keep in mind that an underlay does not necessarily have to be the main ROS 2 installation.) - -Depending on how you installed ROS 2 (from source or binaries), and which platform you're on, your exact source command will vary: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - Remember to use a ``x64 Native Tools Command Prompt for VS 2019`` for executing the following commands, as we are going to build a workspace. - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - -Consult the :doc:`installation guide <../../../Installation>` you followed if these commands don't work for you. - -.. _new-directory: - -2 Create a new directory -^^^^^^^^^^^^^^^^^^^^^^^^ - -Best practice is to create a new directory for every new workspace. -The name doesn't matter, but it is helpful to have it indicate the purpose of the workspace. -Let's choose the directory name ``ros2_ws``, for "development workspace": - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - - .. group-tab:: Windows - - .. code-block:: console - - $ md \ros2_ws\src - $ cd \ros2_ws\src - - -Another best practice is to put any packages in your workspace into the ``src`` directory. -The above code creates a ``src`` directory inside ``ros2_ws`` and then navigates into it. - - -3 Clone a sample repo -^^^^^^^^^^^^^^^^^^^^^ - -Ensure you're still in the ``ros2_ws/src`` directory before you clone. - -In the rest of the beginner developer tutorials, you will create your own packages, but for now you will practice putting a workspace together using existing packages. - -If you went through the :doc:`Beginner: CLI Tools <../../Beginner-CLI-Tools>` tutorials, you'll be familiar with ``turtlesim``, one of the packages in `ros_tutorials `__. - -A repo can have multiple branches. -You need to check out the one that targets your installed ROS 2 distro. -When you clone this repo, add the ``-b`` argument followed by that branch. - -In the ``ros2_ws/src`` directory, run the following command: - -.. code-block:: console - - $ git clone https://github.com/ros/ros_tutorials.git -b {DISTRO} - -Now ``ros_tutorials`` is cloned in your workspace. -The ``ros_tutorials`` repository contains the ``turtlesim`` package, which we'll use in the rest of this tutorial. -The other packages in this repository are not built because they contain a ``COLCON_IGNORE`` file. - -So far you have populated your workspace with a sample package, but it isn't a fully-functional workspace yet. -You need to resolve the dependencies first and then build the workspace. - - -4 Resolve dependencies -^^^^^^^^^^^^^^^^^^^^^^ - -Before building the workspace, you need to resolve the package dependencies. -You may have all the dependencies already, but best practice is to check for dependencies every time you clone. -You wouldn't want a build to fail after a long wait only to realize that you have missing dependencies. - -From the root of your workspace (``ros2_ws``), run the following command: - -.. tabs:: - - .. group-tab:: Linux - - If you're still in the ``src`` directory with the ``ros_tutorials`` clone, make sure to run ``cd ..`` to move back up to the workspace (``ros2_ws``). - - .. code-block:: console - - $ cd .. - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to section "5 Build the workspace with colcon". - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to section "5 Build the workspace with colcon". - -If you installed ROS 2 on Linux from source or the binary archive, you will need to use the rosdep command from their installation instructions. -Here are the :ref:`from-source rosdep section ` and the :ref:`binary archive rosdep section `. - -If you already have all your dependencies, the console will return: - -.. code-block:: text - - #All required rosdeps installed successfully - -Packages declare their dependencies in the package.xml file (you will learn more about packages in the next tutorial). -This command walks through those declarations and installs the ones that are missing. -You can learn more about ``rosdep`` in another tutorial (coming soon). - -5 Build the workspace with colcon -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -From the root of your workspace (``ros2_ws``), you can now build your packages using the command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build - Starting >>> turtlesim - Finished <<< turtlesim [5.49s] - - Summary: 1 package finished [5.58s] - - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build - Starting >>> turtlesim - Finished <<< turtlesim [5.49s] - - Summary: 1 package finished [5.58s] - - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install - Starting >>> turtlesim - Finished <<< turtlesim [5.49s] - - Summary: 1 package finished [5.58s] - - Windows doesn't allow long paths, so ``merge-install`` will combine all the paths into the ``install`` directory. - -.. note:: - - Other useful arguments for ``colcon build``: - - * ``--packages-up-to`` builds the package you want, plus all its dependencies, but not the whole workspace (saves time) - * ``--symlink-install`` saves you from having to rebuild every time you tweak python scripts - * ``--event-handlers console_direct+`` shows console output while building (can otherwise be found in the ``log`` directory) - * ``--executor sequential`` processes the packages one by one instead of using parallelism - -Once the build is finished, enter the command in the workspace root (``~/ros2_ws``). -You will see that colcon has created new directories: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ ls - build install log src - - .. group-tab:: macOS - - .. code-block:: console - - $ ls - build install log src - - .. group-tab:: Windows - - .. code-block:: console - - $ dir - build install log src - -The ``install`` directory is where your workspace's setup files are, which you can use to source your overlay. - - -6 Source the overlay -^^^^^^^^^^^^^^^^^^^^ - -Before sourcing the overlay, it is very important that you open a new terminal, separate from the one where you built the workspace. -Sourcing an overlay in the same terminal where you built, or likewise building where an overlay is sourced, may create complex issues. - -In the new terminal, source your main ROS 2 environment as the "underlay", so you can build the overlay "on top of" it: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - In this case you can use a normal command prompt, as we are not going to build any workspace in this terminal. - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - -Go into the root of your workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_ws - -In the root, source your overlay: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/local_setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/local_setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\setup.bat - -.. note:: - - Sourcing the ``local_setup`` of the overlay will only add the packages available in the overlay to your environment. - ``setup`` sources the overlay as well as the underlay it was created in, allowing you to utilize both workspaces. - - So, sourcing your main ROS 2 installation's ``setup`` and then the ``ros2_ws`` overlay's ``local_setup``, like you just did, - is the same as just sourcing ``ros2_ws``'s ``setup``, because that includes the environment of its underlay. - -Now you can run the ``turtlesim`` package from the overlay: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -But how can you tell that this is the overlay turtlesim running, and not your main installation's turtlesim? - -Let's modify turtlesim in the overlay so you can see the effects: - -* You can modify and rebuild packages in the overlay separately from the underlay. -* The overlay takes precedence over the underlay. - - -7 Modify the overlay -^^^^^^^^^^^^^^^^^^^^ - -You can modify ``turtlesim`` in your overlay by editing the title bar on the turtlesim window. -To do this, locate the ``turtle_frame.cpp`` file in ``~/ros2_ws/src/ros_tutorials/turtlesim/src``. -Open ``turtle_frame.cpp`` with your preferred text editor. - -Find the function ``setWindowTitle("TurtleSim");``, change the value ``"TurtleSim"`` to ``"MyTurtleSim"``, and save the file. - -Return to the first terminal where you ran ``colcon build`` earlier and run it again. - -Return to the second terminal (where the overlay is sourced) and run turtlesim again: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -You will see the title bar on the turtlesim window now says "MyTurtleSim". - -.. image:: images/overlay.png - -Even though your main ROS 2 environment was sourced in this terminal earlier, the overlay of your ``ros2_ws`` environment takes precedence over the contents of the underlay. - -To see that your underlay is still intact, open a brand new terminal and source only your ROS 2 installation. -Run turtlesim again: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -.. image:: images/underlay.png - -You can see that modifications in the overlay did not actually affect anything in the underlay. - - -Summary -------- -In this tutorial, you sourced your main ROS 2 distro install as your underlay, and created an overlay by cloning and building packages in a new workspace. -The overlay gets prepended to the path, and takes precedence over the underlay, as you saw with your modified turtlesim. - -Using overlays is recommended for working on a small number of packages, so you don't have to put everything in the same workspace and rebuild a huge workspace on every iteration. - -Next steps ----------- - -Now that you understand the details behind creating, building and sourcing your own workspace, you can learn how to :doc:`create your own packages <../Creating-Your-First-ROS2-Package>`. +.. redirect-from:: + + Tutorials/Workspace/Creating-A-Workspace + Tutorials/Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace + +.. _ROS2Workspace: + +Creating a workspace +==================== + +**Goal:** Create a workspace and learn how to set up an overlay for development and testing. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +A workspace is a directory containing ROS 2 packages. +Before using ROS 2, it's necessary to source your ROS 2 installation workspace in the terminal you plan to work in. +This makes ROS 2's packages available for you to use in that terminal. + +You also have the option of sourcing an "overlay" - a secondary workspace where you can add new packages without interfering with the existing ROS 2 workspace that you're extending, or "underlay". +Your underlay must contain the dependencies of all the packages in your overlay. +Packages in your overlay will override packages in the underlay. +It's also possible to have several layers of underlays and overlays, with each successive overlay using the packages of its parent underlays. + + +Prerequisites +------------- + +* :doc:`ROS 2 installation <../../../../Get-Started/Installation>` +* :doc:`colcon installation <../Colcon-Tutorial>` +* `git installation `__ +* :doc:`turtlesim installation <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` +* Have :doc:`rosdep installed <../Rosdep>` +* Understanding of basic terminal commands (`here's a guide for Linux `__) +* Text editor of your choice + +Tasks +----- + +1 Source ROS 2 environment +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Your main ROS 2 installation will be your underlay for this tutorial. +(Keep in mind that an underlay does not necessarily have to be the main ROS 2 installation.) + +Depending on how you installed ROS 2 (from source or binaries), and which platform you're on, your exact source command will vary: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + Remember to use a ``x64 Native Tools Command Prompt for VS 2019`` for executing the following commands, as we are going to build a workspace. + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + +Consult the :doc:`installation guide <../../../../Get-Started/Installation>` you followed if these commands don't work for you. + +.. _new-directory: + +2 Create a new directory +^^^^^^^^^^^^^^^^^^^^^^^^ + +Best practice is to create a new directory for every new workspace. +The name doesn't matter, but it is helpful to have it indicate the purpose of the workspace. +Let's choose the directory name ``ros2_ws``, for "development workspace": + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + + .. group-tab:: Windows + + .. code-block:: console + + $ md \ros2_ws\src + $ cd \ros2_ws\src + + +Another best practice is to put any packages in your workspace into the ``src`` directory. +The above code creates a ``src`` directory inside ``ros2_ws`` and then navigates into it. + + +3 Clone a sample repo +^^^^^^^^^^^^^^^^^^^^^ + +Ensure you're still in the ``ros2_ws/src`` directory before you clone. + +In the rest of the beginner developer tutorials, you will create your own packages, but for now you will practice putting a workspace together using existing packages. + +If you went through the :doc:`Beginner: CLI Tools <../../../../Tutorials/Beginner-CLI-Tools>` tutorials, you'll be familiar with ``turtlesim``, one of the packages in `ros_tutorials `__. + +A repo can have multiple branches. +You need to check out the one that targets your installed ROS 2 distro. +When you clone this repo, add the ``-b`` argument followed by that branch. + +In the ``ros2_ws/src`` directory, run the following command: + +.. code-block:: console + + $ git clone https://github.com/ros/ros_tutorials.git -b {DISTRO} + +Now ``ros_tutorials`` is cloned in your workspace. +The ``ros_tutorials`` repository contains the ``turtlesim`` package, which we'll use in the rest of this tutorial. +The other packages in this repository are not built because they contain a ``COLCON_IGNORE`` file. + +So far you have populated your workspace with a sample package, but it isn't a fully-functional workspace yet. +You need to resolve the dependencies first and then build the workspace. + + +4 Resolve dependencies +^^^^^^^^^^^^^^^^^^^^^^ + +Before building the workspace, you need to resolve the package dependencies. +You may have all the dependencies already, but best practice is to check for dependencies every time you clone. +You wouldn't want a build to fail after a long wait only to realize that you have missing dependencies. + +From the root of your workspace (``ros2_ws``), run the following command: + +.. tabs:: + + .. group-tab:: Linux + + If you're still in the ``src`` directory with the ``ros_tutorials`` clone, make sure to run ``cd ..`` to move back up to the workspace (``ros2_ws``). + + .. code-block:: console + + $ cd .. + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to section "5 Build the workspace with colcon". + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to section "5 Build the workspace with colcon". + +If you installed ROS 2 on Linux from source or the binary archive, you will need to use the rosdep command from their installation instructions. +Here are the :ref:`from-source rosdep section ` and the :ref:`binary archive rosdep section `. + +If you already have all your dependencies, the console will return: + +.. code-block:: text + + #All required rosdeps installed successfully + +Packages declare their dependencies in the package.xml file (you will learn more about packages in the next tutorial). +This command walks through those declarations and installs the ones that are missing. +You can learn more about ``rosdep`` in another tutorial (coming soon). + +5 Build the workspace with colcon +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +From the root of your workspace (``ros2_ws``), you can now build your packages using the command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build + Starting >>> turtlesim + Finished <<< turtlesim [5.49s] + + Summary: 1 package finished [5.58s] + + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build + Starting >>> turtlesim + Finished <<< turtlesim [5.49s] + + Summary: 1 package finished [5.58s] + + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install + Starting >>> turtlesim + Finished <<< turtlesim [5.49s] + + Summary: 1 package finished [5.58s] + + Windows doesn't allow long paths, so ``merge-install`` will combine all the paths into the ``install`` directory. + +.. note:: + + Other useful arguments for ``colcon build``: + + * ``--packages-up-to`` builds the package you want, plus all its dependencies, but not the whole workspace (saves time) + * ``--symlink-install`` saves you from having to rebuild every time you tweak python scripts + * ``--event-handlers console_direct+`` shows console output while building (can otherwise be found in the ``log`` directory) + * ``--executor sequential`` processes the packages one by one instead of using parallelism + +Once the build is finished, enter the command in the workspace root (``~/ros2_ws``). +You will see that colcon has created new directories: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ ls + build install log src + + .. group-tab:: macOS + + .. code-block:: console + + $ ls + build install log src + + .. group-tab:: Windows + + .. code-block:: console + + $ dir + build install log src + +The ``install`` directory is where your workspace's setup files are, which you can use to source your overlay. + + +6 Source the overlay +^^^^^^^^^^^^^^^^^^^^ + +Before sourcing the overlay, it is very important that you open a new terminal, separate from the one where you built the workspace. +Sourcing an overlay in the same terminal where you built, or likewise building where an overlay is sourced, may create complex issues. + +In the new terminal, source your main ROS 2 environment as the "underlay", so you can build the overlay "on top of" it: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + In this case you can use a normal command prompt, as we are not going to build any workspace in this terminal. + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + +Go into the root of your workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_ws + +In the root, source your overlay: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/local_setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/local_setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\setup.bat + +.. note:: + + Sourcing the ``local_setup`` of the overlay will only add the packages available in the overlay to your environment. + ``setup`` sources the overlay as well as the underlay it was created in, allowing you to utilize both workspaces. + + So, sourcing your main ROS 2 installation's ``setup`` and then the ``ros2_ws`` overlay's ``local_setup``, like you just did, + is the same as just sourcing ``ros2_ws``'s ``setup``, because that includes the environment of its underlay. + +Now you can run the ``turtlesim`` package from the overlay: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +But how can you tell that this is the overlay turtlesim running, and not your main installation's turtlesim? + +Let's modify turtlesim in the overlay so you can see the effects: + +* You can modify and rebuild packages in the overlay separately from the underlay. +* The overlay takes precedence over the underlay. + + +7 Modify the overlay +^^^^^^^^^^^^^^^^^^^^ + +You can modify ``turtlesim`` in your overlay by editing the title bar on the turtlesim window. +To do this, locate the ``turtle_frame.cpp`` file in ``~/ros2_ws/src/ros_tutorials/turtlesim/src``. +Open ``turtle_frame.cpp`` with your preferred text editor. + +Find the function ``setWindowTitle("TurtleSim");``, change the value ``"TurtleSim"`` to ``"MyTurtleSim"``, and save the file. + +Return to the first terminal where you ran ``colcon build`` earlier and run it again. + +Return to the second terminal (where the overlay is sourced) and run turtlesim again: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +You will see the title bar on the turtlesim window now says "MyTurtleSim". + +.. image:: images/overlay.png + +Even though your main ROS 2 environment was sourced in this terminal earlier, the overlay of your ``ros2_ws`` environment takes precedence over the contents of the underlay. + +To see that your underlay is still intact, open a brand new terminal and source only your ROS 2 installation. +Run turtlesim again: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +.. image:: images/underlay.png + +You can see that modifications in the overlay did not actually affect anything in the underlay. + + +Summary +------- +In this tutorial, you sourced your main ROS 2 distro install as your underlay, and created an overlay by cloning and building packages in a new workspace. +The overlay gets prepended to the path, and takes precedence over the underlay, as you saw with your modified turtlesim. + +Using overlays is recommended for working on a small number of packages, so you don't have to put everything in the same workspace and rebuild a huge workspace on every iteration. + +Next steps +---------- + +Now that you understand the details behind creating, building and sourcing your own workspace, you can learn how to :doc:`create your own packages <../Creating-Your-First-ROS2-Package>`. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst index 454f5a84c02..741f19e629e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst @@ -1,481 +1,485 @@ -Creating an ``rmw`` implementation -================================== - -**Goal:** Learn how to create a new ``rmw`` implementation, from the features required from the underlying middleware to the ``rmw`` implementation details. - -**Tutorial level:** Advanced - -**Time:** 30+ minutes - -.. contents:: Table of Contents - :local: - -Introduction ------------- - -ROS 2's architecture has two main :doc:`abstraction layers <../../Concepts/Advanced/About-Internal-Interfaces>`. -From top to bottom: - -#. The client library interface, ``rcl``, which supports the user-facing :doc:`client libraries <../../Concepts/Basic/About-Client-Libraries>`, such as ``rclcpp`` and ``rclpy`` -#. The middleware interface, ``rmw``, which abstracts away the :doc:`underlying middleware implementation <../../Concepts/Intermediate/About-Different-Middleware-Vendors>`, such as a specific DDS implementation, Zenoh, etc. - -The ``rmw`` `API includes function-level documentation `_, but there is no higher-level documentation on the features of the interface and what it expects from the underlying middleware. - -This guide is for developers who want to implement the ``rmw`` interface for a specific middleware. -It will first go over the ``rmw`` interface and how it works. -Then it will cover the main concepts or features that a middleware implementation must support. -Finally, it will go over some implementation details, including how to create an implementation skeleton and some tips to implement the interface functions. - -This guide is intended to be an entry point to kickstart the development of a new ``rmw`` implementation. -It will link to other pages and source code for more details where appropriate. - -.. note:: - - ROS 2 design articles on `design.ros2.org `_ are historical documents and may not reflect the current state of ROS 2. - However, in some cases, they provide useful context and information, so they may still be referenced by this guide or by pages that this guide links to. - -The ``rmw`` interface ---------------------- - -The ``rmw`` interface is declared by the ``rmw`` package through `C header files `_. -Implementations of the C functions declared in these headers are provided by ``rmw`` implementations, which are separate packages. -For example, the ``rmw_fastrtps_cpp`` package implements the interface for eProsima Fast DDS. - -Example implementations -^^^^^^^^^^^^^^^^^^^^^^^ - -The following ``rmw`` :doc:`implementations <../../Concepts/Advanced/About-Middleware-Implementations>` can be used as references. -Note that there are different `support tiers, which are defined by REP 2000 `_. - -#. DDS: - - #. ``rmw_fastrtps_cpp``, ``rmw_fastrtps_dynamic_cpp``: `ros2/rmw_fastrtps `_ - #. ``rmw_cyclonedds_cpp``: `ros2/rmw_cyclonedds `_ - #. ``rmw_connextdds``: `ros2/rmw_connextdds `_ - #. ``rmw_gurumdds_cpp``: `ros2/rmw_gurumdds `_ - - * See :ref:`this overview ` - -#. ``rmw_zenoh_cpp``: `ros2/rmw_zenoh `_ - - * See :ref:`this overview ` and the `design document `_ - -#. ``rmw_email_cpp``, an email-based implementation: `christophebedard/rmw_email `_ - - * See the `design document for the underlying email middleware `_ and the `blog post for some context `_ - -.. _rmw-impl-guide_selection-mechanism: - -Build-time and runtime ``rmw`` implementation selection mechanism -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The dependency on the actual ``rmw`` implementation is done through the ``rmw_implementation`` `package `_. -Users of ``rmw``, such as ``rcl``, depend on the ``rmw`` package for the interface (headers) and some utility functions. -They also depend on the ``rmw_implementation`` package to get the actual implementation. - -By default, ROS 2 allows you to choose which ``rmw`` implementation to use at runtime. -This is convenient for comparing two implementations on the same machine, and it lets ROS 2 distribute a single set of binaries that is compatible with multiple ``rmw`` implementations. -The :doc:`implementation is selected at runtime <../../How-To-Guides/Working-with-multiple-RMW-implementations>` through the ``RMW_IMPLEMENTATION`` environment variable, or, if that variable is unset, a default ``rmw`` implementation is loaded. - -This is accomplished by the ``rmw_implementation`` package, which acts as a proxy for an actual ``rmw`` implementation. -It works by creating placeholder ``rmw`` functions. -When they are called, it will ``dlopen()`` the appropriate library for the selected ``rmw`` implementation and then look up the corresponding symbols in the loaded shared library using the ``dlsym()`` function before calling them. - -The ``rmw_implementation`` package can be configured at build-time to change the default option or disable runtime selection. -The default implementation can be selected at build-time with the ``RMW_IMPLEMENTATION`` CMake variable (e.g., ``-DRMW_IMPLEMENTATION=rmw_other``) or the ``RMW_IMPLEMENTATION`` environment variable. -If only one implementation is available at build-time, or if runtime selection is disabled (``-DRMW_IMPLEMENTATION_DISABLE_RUNTIME_SELECTION=ON``), the ``rmw_implementation`` target will be a simple ``INTERFACE`` library for the single implementation. - -Because of the proxy mechanism and the CMake logic described above, an ``rmw`` implementation that does not implement all of the functions in the interface will only fail at runtime, when the symbol lookup fails, as opposed to failing at build-time (specifically at link-time) if runtime selection is disabled. - -Features --------- - -This section goes over the main features of the ``rmw`` interface, which the underlying middleware must support or deal with. -Depending on the middleware -- and how similar it is to the features expected by the interface -- the ``rmw`` implementation may be more or less trivial, i.e., it might have to do more "glue" work. -For some non-critical features or configuration options, the implementation can indicate that they are not supported through ``rmw_feature_supported()`` or by returning ``RMW_RET_UNSUPPORTED``. -In any case, any special behavior of the ``rmw`` implementation should ideally be documented. - -Topics, pub/sub, services -^^^^^^^^^^^^^^^^^^^^^^^^^ - -:doc:`Topics <../../Concepts/Basic/About-Topics>` are a common concept in publish/subscribe middleware. -However, ROS 2 has its own topic name conventions, which is validated using ``rmw_validate_full_topic_name()``. -The ``rmw`` implementation simply has to use the given (resolved) topic name. -This might involve adapting or mangling the ROS topic name to fit the underlying middleware's topic name conventions or constraints, or encode useful information. -For example, a pub/sub topic called ``/chatter`` is usually mangled into ``rt/chatter`` for DDS-based implementations, making ROS topics on DDS easily distinguishable from normal DDS topics. -See the `"Mapping of ROS 2 Topic and Service Names to DDS Concepts" section in this design document `_. -For Zenoh, the domain ID, resolved topic name, topic type name, and topic type hash are `encoded in the underlying Zenoh key `_ to avoid communications between different ROS topic names & types. - -As for :doc:`services <../../Concepts/Basic/About-Services>`, they are not always natively supported by the underlying middleware. -For DDS-based implementations, they are simply built on top of pub/sub: 1 request topic and 1 response topic. -[#fn_dds_rpc]_ -On the other hand, Zenoh natively supports services through `queryables `_, so they are used to implement services in ``rmw_zenoh_cpp``. - -Note that, while services are a part of the ``rmw`` interface, :doc:`actions <../../Concepts/Basic/About-Actions>` are not. -They are an ``rcl`` concept implemented in the ``rcl_action`` package on top of services and pub/sub. - -Nodes -^^^^^ - -:doc:`Nodes <../../Concepts/Basic/About-Nodes>` are mostly a ROS concept. -Neither DDS nor Zenoh has a corresponding concept, so they are mostly a logical concept in the ``rmw`` implementation. -Topic names get resolved with the node namespace/name, if needed, by ``rcl`` before they are passed to ``rmw`` when creating a pub/sub object. -Implementations just have to make sure to include nodes in :ref:`introspection data `. - -.. _rmw-impl-guide_waitsets: - -Wait sets and waiting -^^^^^^^^^^^^^^^^^^^^^ - -:doc:`Executors <../../Concepts/Intermediate/About-Executors>` are responsible for triggering user-provided callbacks when a new message is received, for example. -Executors are implemented at the client library level (``rclcpp``, ``rclpy``), but they rely on the underlying middleware to wait for new messages using a polling mechanism. -This is done using wait sets, which allow waiting on different entities at the same time in a standard way, e.g., subscriptions, service clients, and service servers. -The ``rmw_wait()`` `function `_ is called with lists of entities to wait on, as well as an implementation-specific wait set object. -It adds all entities to the wait set and asks it to wait until at least one entity has new data available or until it times out. -Then the executor checks the lists of entities to see which ones have new data available and triggers the corresponding callbacks. - -The key mechanism here is the ability to check if a given entity is ready, e.g., check if a subscription has a new message. -Then waiting simply involves continuously checking entities one at a time until one is ready or until the wait times out. - -Take a look at how ``rmw_email_cpp`` `implements wait sets and waiting `_ and dig down to the middleware, ``email``, since it's fairly simple. - -Taking data -^^^^^^^^^^^ - -Once an :ref:`executor is done waiting ` and there is a new message, request, or response, it takes it from the middleware and triggers the corresponding callback. -For instance, ``rmw_take()`` is called with a subscription and a type-erased pointer to an instance of the corresponding message type to write to. - -``rmw_email_cpp`` takes the new message (YAML string) from the underlying email middleware subscription object, and converts it into a ROS message by writing into the provided message. - -Metadata: GIDs, timestamps, sequence numbers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Aside from actual user-specified data, message publications, service requests, service responses, and so on also have metadata associated with them: - -* GID: globally-unique ID that identifies an entity (e.g., pub, sub, client, server) - - * The GID for an entity should be unique within a ROS domain and should be the same when reported both locally and remotely. - For example, the publisher GID for a message being published should be the same publisher GID reported on the other side, when that message is received by a subscription. - [#fn_gid_remote_matching]_ - -* Source & received timestamps: publication & subscription reception timestamps, respectively - -* Publication & reception sequence numbers - -This means that service request metadata includes the GID of the client that made the request and the request sequence number. -Service response metadata also includes the client GID & sequence number of the request it is responding to. - -This metadata is available as structs through ``rmw_take_with_info()`` for subscription messages and ``rmw_take_{request,response}()`` for service requests/responses, which are wrapped & provided to user callbacks by the client libraries. - -Part of this metadata might be natively supported and provided by the underlying middleware, while another part might have to be included and transmitted alongside the application data by the ``rmw`` implementation. -For instance, DDS natively supports all of it for pub/sub through DDS sample info, but the client request metadata needs to be wrapped alongside the service response data by the ``rmw`` implementation. -``email`` natively supports all of this metadata, which is included in standard email headers (i.e., not in the email body). - -.. _rmw-impl-guide_typesupport: - -Type support -^^^^^^^^^^^^ - -To bridge the gap between ROS 2 :doc:`interfaces <../../Concepts/Basic/About-Interfaces>` (specifically :doc:`custom interfaces <../Beginner-Client-Libraries/Custom-ROS2-Interfaces>`) and the underlying middleware, some glue code is needed. -This is referred to as :ref:`type support `. -When publishing a message of type {interface(std_msgs/msg/String)}, ``rmw_publish()`` only gets a ``void *`` to the message, which could point to a C++ instance, or a C instance, and so on. -The pointer will be interpreted based on the type support information provided when the publisher was created. - -First, code is generated for each combination of interface type and user-facing language, independent of the underlying middleware. -For example, for the {interface(std_msgs/msg/String)} message type, data structures are generated: - -#. C++: ``std_msgs/msg/string.hpp`` header with ``std_msgs::msg::String`` class generated by the ``rosidl_generator_cpp`` package -#. C: ``std_msgs/msg/string.h`` header with ``std_msgs__msg__String`` struct generated by the ``rosidl_generator_c`` package -#. Python: ``std_msgs`` module with ``std_msgs.msg.String`` class (which is just a wrapper around the C struct) generated by the ``rosidl_generator_py`` package -#. (and so on, e.g., for Rust) - -Second, for the underlying middleware to be able to send and receive messages, it needs to know how to interpret the user-facing data structure. -This is one of the most critical parts of an ``rmw`` implementation. -There are two options: :ref:`static type support ` and :ref:`dynamic type support `. -Static type support involves generating middleware-specific code for each interface. -For example, ``rosidl_typesupport_fastrtps_cpp`` generates code to serialize/deserialize C++ classes of each interface type into CDR using `Fast CDR `_ for ``rmw_fastrtps_cpp`` to pass on to Fast DDS. -[#fn_ts_fastrtps]_ -``rmw_connextdds`` and even ``rmw_zenoh_cpp`` use CDR for serialization, so they use this type support package as well. -On the other hand, dynamic type support involves generating a bit of middleware-independent code that provides generic information about each interface type. -[#fn_ts_dynamic]_ - -This information can be used at runtime by any ``rmw`` implementation to interpret a type-erased pointer to data: names & types of fields, functions to read from/write to fields depending on their type, functions to get the size of an array field, etc. -For C++, this is ``rosidl_typesupport_introspection_cpp``, which is used by ``rmw_fastrtps_dynamic_cpp`` (hence the "dynamic" part), for example. - -Dynamic type support is generally slower than static type support at runtime because it has to iterate over each message field, figure out what type it is, and then process it, e.g., serialize it. -Static type support knows exactly how to process the message thanks to the code it generated for each interface type. -This is why most ``rmw`` implementations use static type support. -However, dynamic type support does not require generating middleware-specific code. -Choosing between static and dynamic type support is an orthogonal decision to the ``rmw`` implementation itself. - -``rmw_email_cpp`` uses dynamic type support to convert messages to and from YAML string to be sent over email. -It gets the type support introspection information, and passes it and the message to an external/experimental package, `dynmsg `_, which converts the message to/from YAML. -The YAML object is then sent as a YAML-formatted string via email using the underlying middleware. -When a new message is received by the middleware, the YAML string is converted into a message. - -Domain ID -^^^^^^^^^ - -:doc:`Domain IDs <../../Concepts/Intermediate/About-Domain-ID>` are a way to have separate logical networks on the same physical network. -It is a native feature of DDS, but not Zenoh. -DDS achieves this by using the domain ID as a network port offset, while Zenoh implements it by making the domain ID the first component of the internal Zenoh key corresponding to each ROS 2 topic. - -Quality of service (QoS) -^^^^^^^^^^^^^^^^^^^^^^^^ - -:doc:`Quality of service settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>` in ROS 2 are largely derived from DDS. -Basic QoS policies like history, depth, and durability are the same as ROS 1's, but more advanced policies simply come from DDS. -Implementations may simply ignore some settings. -For instance, ``rmw_zenoh_cpp`` doesn't implement the deadline and lifespan QoS policies. - -One important aspect of QoS is that two profiles, e.g., a publisher's profile and a subscription's profile, may be incompatible, meaning they cannot communicate. -It is up to the implementation to decide if two QoS profiles are compatible: ``rmw_qos_profile_check_compatible()``. -DDS-based implementations rely on ``rmw_dds_common::qos_profile_check_compatible()``, since :ref:`QoS profile compatibility ` is standard in DDS. -In Zenoh, `QoS settings are essentially never incompatible `_. - -To support a universal "default" behavior, QoS policies include a ``*_SYSTEM_DEFAULT`` setting (e.g., ``rmw_qos_reliability_policy_t``'s ``RMW_QOS_POLICY_RELIABILITY_SYSTEM_DEFAULT``), which leaves the value up to the middleware implementation. -Then the ``rmw_*_get_actual_qos()`` functions retrieve the actual QoS profile used by the implementation. - -.. _rmw-impl-guide_introspection: - -ROS graph introspection -^^^^^^^^^^^^^^^^^^^^^^^ - -Nodes are able to get a list of other nodes, topics, etc. -This also allows publishers to know if any subscriptions exist for their topic, for example. -This same mechanism is used to :doc:`list nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, and so on with the ROS 2 CLI: ``ros2 node list``, ``ros2 topic list``, etc. - -This is supported by a number of ``rmw`` functions: ``rmw_get_node_names()``, ``rmw_get_topic_names_and_types()``, ``rmw_publisher_count_matched_subscriptions()``, and many more. -While the implementation is not specified by the interface, ``rmw`` implementations usually maintain a cache of the ROS graph. -When they create a new entity (e.g., node, publisher, subscription, service, client), they note it in their internal graph cache and notify other participants through a middleware-specific mechanism so that they can add it to their cache. -The graph cache belongs to the ``rmw`` context, so it is initialized when ``rmw_init()`` is called. -This context indirectly belongs to the ``rclcpp`` context (e.g., initialized by ``rclcpp::init()``), so there is usually only one graph cache per process. - -Since DDS-based ``rmw`` implementations are very similar in this regard, they share a common graph cache implementation in the ``rmw_dds_common`` `package `__. -It uses an internal topic (usually ``ros_discovery_info``) to share information about new entities. -``rmw_zenoh_cpp`` `creates a Zenoh liveliness token `_ with the entity type & info and shares it with other participants. - -Events -^^^^^^ - -Users can provide callbacks for publishers & subscriptions to be triggered by the middleware (but executed by the client library) on certain events (``rmw_event_type_t``), such as :ref:`quality of service-related events ` and :ref:`pub-sub match events `. -Some of these events could be triggered on relevant changes to the graph cache. - -Security -^^^^^^^^ - -:doc:`Security <../../Concepts/Intermediate/About-Security>` is not well-specified by the ``rmw`` interface; most of it is specified by :doc:`SROS2 <../Advanced/Security/Introducing-ros2-security>`. -The interface only defines a few security options as part of the context initialization options, ``rmw_init_options_t``: - -#. ``rmw_security_options_t``, which includes a security policy (enforce/permissive) and a path to a directory containing security artifacts, i.e., a keystore. - These are set by ``rcl`` based on environment variables: ``ROS_SECURITY_ENABLE`` & ``ROS_SECURITY_STRATEGY`` and ``ROS_SECURITY_KEYSTORE``. -#. The name of a security enclave from the keystore to use for the given process. - This is set, for example, through the ``--enclave`` option when running a node with ``ros2 run``. - -However, in practice, the structure of the :doc:`keystore <./Security/The-Keystore>` directory and its security enclaves is based on the DDS Security specification. -Therefore, :doc:`security artifacts generated <./Security/Introducing-ros2-security>` with the ``sros2`` package can only be directly used by DDS-based ``rmw`` implementations. -For ``rmw_zenoh_cpp``, `Zenoh-specific security configuration files can be generated `_ from ``sros2``-generated artifacts using the ``zenoh_security_tools`` package and provided through the ``ZENOH_SESSION_CONFIG_URI`` environment variable, bypassing the ``ROS_SECURITY_*`` environment variables. - -Implementation --------------- - -Implementation skeleton -^^^^^^^^^^^^^^^^^^^^^^^ - -This section covers concrete steps to create the base files and directories for the new implementation package, including special handling in ``package.xml`` and ``CMakeLists.txt``. - -Start with the :doc:`package creation tutorial <../../Tutorials/Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>` to create an empty package. -Then make the following changes: - -#. ``package.xml`` - - #. Define a package/implementation name - - The package name is also the name of the ``rmw`` implementation. - It will be used to :ref:`select the implementation ` through the ``RMW_IMPLEMENTATION`` environment variable or CMake option, for example. - The name usually starts with ``rmw_`` and is followed by the name of the underlying middleware. - Most :doc:`implementations in the ROS 2 ecosystem <../../Concepts/Intermediate/About-Different-Middleware-Vendors>` then append a suffix such as ``_cpp`` to indicate that the implementation is written in C++. - However, that is not required. - Examples: ``rmw_fastrtps_cpp``, ``rmw_cyclonedds_cpp``, ``rmw_connextdds``, ``rmw_zenoh_cpp``, and ``rmw_email_cpp``. - - .. code-block:: xml - - - rmw_IMPLEMENTATION_NAME_cpp - - #. Declare a dependency on ``rmw`` - - Since the package will implement the interface declared in the ``rmw`` package and will depend on some utility functions. - - .. code-block:: xml - - rmw - - #. Declare a dependency on the required type support packages - - See the :ref:`type support section ` for details. - - .. code-block:: xml - - - rosidl_typesupport_fastrtps_c - rosidl_typesupport_fastrtps_cpp - rosidl_typesupport_introspection_c - rosidl_typesupport_introspection_cpp - - #. Declare membership of the ``rmw_implementation_packages`` group - - This allows the ``rmw_implementation`` package to `depend on the implementation `_ so that it gets built alongside other implementations, since no package otherwise explicitly depends on any ``rmw`` implementations. - This way it can be found and used if selected. - - .. code-block:: xml - - rmw_implementation_packages - -#. ``CMakeLists.txt`` - - #. Create the library target - - The library has to be a shared library. - It should depend on ``rmw`` for headers and utility functions as well as the required type support packages. - It will also depend on the underlying middleware. - - .. code-block:: cmake - - add_library(${PROJECT_NAME} SHARED - src/file.cpp - # ... - ) - target_link_libraries(${PROJECT_NAME} PUBLIC - rmw::rmw - ) - target_link_libraries(${PROJECT_NAME} PRIVATE - rosidl_typesupport_fastrtps_c::rosidl_typesupport_fastrtps_c - rosidl_typesupport_fastrtps_cpp::rosidl_typesupport_fastrtps_cpp - rosidl_typesupport_introspection_c::rosidl_typesupport_introspection_c - rosidl_typesupport_introspection_cpp::rosidl_typesupport_introspection_cpp - # TODO add any implementation-specific dependencies, e.g., underlying middleware - ) - - #. Configure the implementation library target - - In practice, this simply makes symbols hidden by default to hide internal symbols, i.e., non-``rmw`` interface symbols. - If the implementation is written in C (not common), specify ``LANGUAGE "C"``. - - .. code-block:: cmake - - configure_rmw_library(${PROJECT_NAME}) - - #. Register the ``rmw`` implementation - - This registers the implementation in the :ref:`ament index ` so that it can be found at build-time (``get_available_rmw_implementations()``, ``get_rmw_typesupport()``) or at runtime (``ament_index_cpp::get_resources("rmw_typesupport")``). - It also registers the languages that the implementation supports and the list of type support packages. - For example, if the implementation only uses type support introspection (i.e., dynamic and not static) for C and C++ messages: - - .. code-block:: cmake - - register_rmw_implementation( - "c:rosidl_typesupport_introspection_c" - "cpp:rosidl_typesupport_introspection_cpp" - ) - - .. For example, the Python client library, ``rclpy``, uses C typesupport, and checks if C typesupport is available using ``get_rmw_typesupport()``, so the ``rmw`` implementation must support it. - - #. Install and export target - - .. code-block:: cmake - - install( - TARGETS ${PROJECT_NAME} - EXPORT ${PROJECT_NAME} - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - - ament_export_targets(${PROJECT_NAME}) - # ament_export_libraries(${PROJECT_NAME}) # Old-style CMake - - # ... - -Interface functions implementation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The first step is to define the C interface functions declared in the ``rmw`` headers. -Start with empty functions that simply return ``RMW_RET_OK``, and then implement them one by one in the order in which they are likely to be called at runtime. -For example: ``rmw_init()``, ``rmw_create_node()``, ``rmw_create_publisher()``, ``rmw_create_subscription()``, and so on. -This will allow building and running/testing the implementation incrementally. - -Most ``rmw`` functions have to perform input validation, as defined by the function's documentation. -There are various utility macros to simplify this, such as ``RMW_CHECK_ARGUMENT_FOR_NULL()`` and ``RMW_CHECK_TYPE_IDENTIFIERS_MATCH()``. - -``rmw`` structs usually include a type-erased pointer (or sometimes an opaque pointer) for ``rmw`` implementation-specific data. -For instance, ``rmw_publisher_t`` has a ``void * data``. -The implementation can place whatever it wants there, e.g., a pointer to an internal object that wraps the underlying middleware's publisher object and any relevant information, like type support. -This data/object can be fetched and used later when ``rmw_publish()`` is called with the corresponding ``rmw_publisher_t``. -To make sure that a different ``rmw`` implementation doesn't try to interpret this data, ``rmw_publisher_t`` includes the name of the implementation in its ``implementation_identifier`` field. - -Type support -^^^^^^^^^^^^ - -Type support structs can be confusing. -Here is an example for message type support for publishers/subscriptions. - -A publisher is created through ``rmw_create_publisher()``, which takes in a handle for the type support information: ``const rosidl_message_type_support_t *``. -This is the base language-dependent type support: ``rosidl_typesupport_c`` / ``rosidl_typesupport_cpp``. -From this, we can get the concrete type support handle, depending on the available type supports, e.g., ``rosidl_typesupport_fastrtps_c`` / ``rosidl_typesupport_fastrtps_cpp`` and ``rosidl_typesupport_introspection_c`` / ``rosidl_typesupport_introspection_cpp``. -The confusing part is that these are also of type ``const rosidl_message_type_support_t *``! -However, the concrete type support handles are the ones that contain actual useful information. -See `this example function `__, which extracts the concrete C or C++ dynamic message type support handle (``rosidl_typesupport_introspection_{c,cpp}``) given a base type support handle (``rosidl_typesupport_{c,cpp}``). -Publishers created by ``rclcpp`` will use C++ type support, while publishers created by ``rclpy`` will use C type support, since Python messages get converted into C messages. -The ``/rosout`` publisher is managed by ``rcl``, which is written in C, so it uses C type support. - -Then, using the concrete type support handle's type-erased pointer, ``const void * data``, we get type support-specific information. -For example, for C++ dynamic type support, this will be a ``const rosidl_typesupport_introspection_cpp::MessageMembers *``, which contains information about each field of the message. -See `this example function `__, which extracts language-dependent type support information from the concrete type support handle. -The information is used to read the type-erased message pointer and convert the message to a YAML object and then convert that to a string for the underlying middleware to publish. - -Service type support is similar, but ``rosidl_service_type_support_t`` points to separate type support information for the request and response message types. - -Tests ------ - -The ``rmw`` package contains some tests, but they are mostly for utilities (e.g., getting zero-initialized structs) and non-implementation-specific functions such as topic/node name/namespace validation. - -As for testing the new ``rmw`` implementation, the ``test_rmw_implementation`` package `contains tests for the interface `_. -Test executables are defined first and then a CMake function creates test targets for a given ``rmw`` implementation by setting the ``RMW_IMPLEMENTATION`` environment variable. -``rmw_implementation_cmake``'s ``call_for_each_rmw_implementation()`` is called and is provided with this CMake function, which is called with each available implementation. -See the `CMakeLists.txt file `__. -Many other packages, including the ``test_rclcpp`` test-only package, also `use this mechanism `__ to run tests against all available ``rmw`` implementations, otherwise tests are simply run with the default implementation. -Packages can also use ``get_available_rmw_implementations()`` to get the actual list of available implementations. - -Some tests have implementation-specific code, which is done for various reasons, such as unsupported interface subsets. -These tests can use ``rmw``'s ``rmw_get_implementation_identifier()`` `function `__ for this. - -Middleware- and ``rmw`` implementation-specific configuration -------------------------------------------------------------- - -The ``rmw`` interface allows providing arbitrary implementation-specific configuration payloads for publishers and subscriptions through the type-erased ``rmw_specific_publisher_payload`` / ``rmw_specific_subscription_payload`` fields in ``rmw_publisher_options_t`` / ``rmw_subscription_options_t``. -This is set by users through ``RMWImplementationSpecificPublisherPayload`` / ``RMWImplementationSpecificSubscriptionPayload`` in ``rclcpp``, for example. -This is an advanced, non-portable feature that is not currently used by any (tier 1) implementations. - -For a bit more flexibility, some implementations use environment variables: ``RMW_FASTRTPS_*``, ``RMW_CONNEXT_*``, etc. -The underlying middleware may also be configurable through environment variables: ``FASTDDS_*``, ``ZENOH_*``, ``CYCLONEDDS_*``, ``EMAIL_*``, etc. -For example, the ``CYCLONEDDS_URI``, ``FASTDDS_DEFAULT_PROFILES_FILE``, and ``ZENOH_SESSION_CONFIG_URI`` environment variables can be used to provide a path to a full configuration file if the relevant middleware is used. - -Footnotes ---------- - -.. [#fn_dds_rpc] - There now is a DDS RPC specification, but `it was not finalized and wasn't implemented by DDS vendors back when ROS 2 was initially designed `_. - Since the ``rmw`` interface is also officially DDS-agnostic, services are up to the ``rmw`` implementation, which explains why :ref:`cross-DDS vendor communications are not guaranteed `, even if pub/sub generally works. - -.. [#fn_gid_remote_matching] - In practice, this is not always the case, so this requirement is somewhat relaxed. - See `ros2/rmw_cyclonedds#377 `_. - -.. [#fn_ts_fastrtps] - For example, the C++ message Fast CDR serialization/deserialization code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_fastrtps_cpp/std_msgs/msg/detail/dds_fastrtps/header__type_support.cpp`` under the ``build/`` directory. - -.. [#fn_ts_dynamic] - For example, the C++ message introspection code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_introspection_cpp/std_msgs/msg/detail/header__type_support.cpp`` under the ``build/`` directory. +.. redirect-from:: + + Tutorials/Advanced/Creating-An-RMW-Implementation + +Creating an ``rmw`` implementation +================================== + +**Goal:** Learn how to create a new ``rmw`` implementation, from the features required from the underlying middleware to the ``rmw`` implementation details. + +**Tutorial level:** Advanced + +**Time:** 30+ minutes + +.. contents:: Table of Contents + :local: + +Introduction +------------ + +ROS 2's architecture has two main :doc:`abstraction layers `. +From top to bottom: + +#. The client library interface, ``rcl``, which supports the user-facing :doc:`client libraries <../../About-Client-Libraries>`, such as ``rclcpp`` and ``rclpy`` +#. The middleware interface, ``rmw``, which abstracts away the :doc:`underlying middleware implementation <../About-Different-Middleware-Vendors>`, such as a specific DDS implementation, Zenoh, etc. + +The ``rmw`` `API includes function-level documentation `_, but there is no higher-level documentation on the features of the interface and what it expects from the underlying middleware. + +This guide is for developers who want to implement the ``rmw`` interface for a specific middleware. +It will first go over the ``rmw`` interface and how it works. +Then it will cover the main concepts or features that a middleware implementation must support. +Finally, it will go over some implementation details, including how to create an implementation skeleton and some tips to implement the interface functions. + +This guide is intended to be an entry point to kickstart the development of a new ``rmw`` implementation. +It will link to other pages and source code for more details where appropriate. + +.. note:: + + ROS 2 design articles on `design.ros2.org `_ are historical documents and may not reflect the current state of ROS 2. + However, in some cases, they provide useful context and information, so they may still be referenced by this guide or by pages that this guide links to. + +The ``rmw`` interface +--------------------- + +The ``rmw`` interface is declared by the ``rmw`` package through `C header files `_. +Implementations of the C functions declared in these headers are provided by ``rmw`` implementations, which are separate packages. +For example, the ``rmw_fastrtps_cpp`` package implements the interface for eProsima Fast DDS. + +Example implementations +^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``rmw`` :doc:`implementations <../About-Middleware-Implementations>` can be used as references. +Note that there are different `support tiers, which are defined by REP 2000 `_. + +#. DDS: + + #. ``rmw_fastrtps_cpp``, ``rmw_fastrtps_dynamic_cpp``: `ros2/rmw_fastrtps `_ + #. ``rmw_cyclonedds_cpp``: `ros2/rmw_cyclonedds `_ + #. ``rmw_connextdds``: `ros2/rmw_connextdds `_ + #. ``rmw_gurumdds_cpp``: `ros2/rmw_gurumdds `_ + + * See :ref:`this overview ` + +#. ``rmw_zenoh_cpp``: `ros2/rmw_zenoh `_ + + * See :ref:`this overview ` and the `design document `_ + +#. ``rmw_email_cpp``, an email-based implementation: `christophebedard/rmw_email `_ + + * See the `design document for the underlying email middleware `_ and the `blog post for some context `_ + +.. _rmw-impl-guide_selection-mechanism: + +Build-time and runtime ``rmw`` implementation selection mechanism +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The dependency on the actual ``rmw`` implementation is done through the ``rmw_implementation`` `package `_. +Users of ``rmw``, such as ``rcl``, depend on the ``rmw`` package for the interface (headers) and some utility functions. +They also depend on the ``rmw_implementation`` package to get the actual implementation. + +By default, ROS 2 allows you to choose which ``rmw`` implementation to use at runtime. +This is convenient for comparing two implementations on the same machine, and it lets ROS 2 distribute a single set of binaries that is compatible with multiple ``rmw`` implementations. +The :doc:`implementation is selected at runtime <../../../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` through the ``RMW_IMPLEMENTATION`` environment variable, or, if that variable is unset, a default ``rmw`` implementation is loaded. + +This is accomplished by the ``rmw_implementation`` package, which acts as a proxy for an actual ``rmw`` implementation. +It works by creating placeholder ``rmw`` functions. +When they are called, it will ``dlopen()`` the appropriate library for the selected ``rmw`` implementation and then look up the corresponding symbols in the loaded shared library using the ``dlsym()`` function before calling them. + +The ``rmw_implementation`` package can be configured at build-time to change the default option or disable runtime selection. +The default implementation can be selected at build-time with the ``RMW_IMPLEMENTATION`` CMake variable (e.g., ``-DRMW_IMPLEMENTATION=rmw_other``) or the ``RMW_IMPLEMENTATION`` environment variable. +If only one implementation is available at build-time, or if runtime selection is disabled (``-DRMW_IMPLEMENTATION_DISABLE_RUNTIME_SELECTION=ON``), the ``rmw_implementation`` target will be a simple ``INTERFACE`` library for the single implementation. + +Because of the proxy mechanism and the CMake logic described above, an ``rmw`` implementation that does not implement all of the functions in the interface will only fail at runtime, when the symbol lookup fails, as opposed to failing at build-time (specifically at link-time) if runtime selection is disabled. + +Features +-------- + +This section goes over the main features of the ``rmw`` interface, which the underlying middleware must support or deal with. +Depending on the middleware -- and how similar it is to the features expected by the interface -- the ``rmw`` implementation may be more or less trivial, i.e., it might have to do more "glue" work. +For some non-critical features or configuration options, the implementation can indicate that they are not supported through ``rmw_feature_supported()`` or by returning ``RMW_RET_UNSUPPORTED``. +In any case, any special behavior of the ``rmw`` implementation should ideally be documented. + +Topics, pub/sub, services +^^^^^^^^^^^^^^^^^^^^^^^^^ + +:doc:`Topics <../../About-Topics>` are a common concept in publish/subscribe middleware. +However, ROS 2 has its own topic name conventions, which is validated using ``rmw_validate_full_topic_name()``. +The ``rmw`` implementation simply has to use the given (resolved) topic name. +This might involve adapting or mangling the ROS topic name to fit the underlying middleware's topic name conventions or constraints, or encode useful information. +For example, a pub/sub topic called ``/chatter`` is usually mangled into ``rt/chatter`` for DDS-based implementations, making ROS topics on DDS easily distinguishable from normal DDS topics. +See the `"Mapping of ROS 2 Topic and Service Names to DDS Concepts" section in this design document `_. +For Zenoh, the domain ID, resolved topic name, topic type name, and topic type hash are `encoded in the underlying Zenoh key `_ to avoid communications between different ROS topic names & types. + +As for :doc:`services <../../About-Services>`, they are not always natively supported by the underlying middleware. +For DDS-based implementations, they are simply built on top of pub/sub: 1 request topic and 1 response topic. +[#fn_dds_rpc]_ +On the other hand, Zenoh natively supports services through `queryables `_, so they are used to implement services in ``rmw_zenoh_cpp``. + +Note that, while services are a part of the ``rmw`` interface, :doc:`actions <../../About-Actions>` are not. +They are an ``rcl`` concept implemented in the ``rcl_action`` package on top of services and pub/sub. + +Nodes +^^^^^ + +:doc:`Nodes <../../About-Nodes>` are mostly a ROS concept. +Neither DDS nor Zenoh has a corresponding concept, so they are mostly a logical concept in the ``rmw`` implementation. +Topic names get resolved with the node namespace/name, if needed, by ``rcl`` before they are passed to ``rmw`` when creating a pub/sub object. +Implementations just have to make sure to include nodes in :ref:`introspection data `. + +.. _rmw-impl-guide_waitsets: + +Wait sets and waiting +^^^^^^^^^^^^^^^^^^^^^ + +:doc:`Executors <../About-Executors/About-Executors>` are responsible for triggering user-provided callbacks when a new message is received, for example. +Executors are implemented at the client library level (``rclcpp``, ``rclpy``), but they rely on the underlying middleware to wait for new messages using a polling mechanism. +This is done using wait sets, which allow waiting on different entities at the same time in a standard way, e.g., subscriptions, service clients, and service servers. +The ``rmw_wait()`` `function `_ is called with lists of entities to wait on, as well as an implementation-specific wait set object. +It adds all entities to the wait set and asks it to wait until at least one entity has new data available or until it times out. +Then the executor checks the lists of entities to see which ones have new data available and triggers the corresponding callbacks. + +The key mechanism here is the ability to check if a given entity is ready, e.g., check if a subscription has a new message. +Then waiting simply involves continuously checking entities one at a time until one is ready or until the wait times out. + +Take a look at how ``rmw_email_cpp`` `implements wait sets and waiting `_ and dig down to the middleware, ``email``, since it's fairly simple. + +Taking data +^^^^^^^^^^^ + +Once an :ref:`executor is done waiting ` and there is a new message, request, or response, it takes it from the middleware and triggers the corresponding callback. +For instance, ``rmw_take()`` is called with a subscription and a type-erased pointer to an instance of the corresponding message type to write to. + +``rmw_email_cpp`` takes the new message (YAML string) from the underlying email middleware subscription object, and converts it into a ROS message by writing into the provided message. + +Metadata: GIDs, timestamps, sequence numbers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Aside from actual user-specified data, message publications, service requests, service responses, and so on also have metadata associated with them: + +* GID: globally-unique ID that identifies an entity (e.g., pub, sub, client, server) + + * The GID for an entity should be unique within a ROS domain and should be the same when reported both locally and remotely. + For example, the publisher GID for a message being published should be the same publisher GID reported on the other side, when that message is received by a subscription. + [#fn_gid_remote_matching]_ + +* Source & received timestamps: publication & subscription reception timestamps, respectively + +* Publication & reception sequence numbers + +This means that service request metadata includes the GID of the client that made the request and the request sequence number. +Service response metadata also includes the client GID & sequence number of the request it is responding to. + +This metadata is available as structs through ``rmw_take_with_info()`` for subscription messages and ``rmw_take_{request,response}()`` for service requests/responses, which are wrapped & provided to user callbacks by the client libraries. + +Part of this metadata might be natively supported and provided by the underlying middleware, while another part might have to be included and transmitted alongside the application data by the ``rmw`` implementation. +For instance, DDS natively supports all of it for pub/sub through DDS sample info, but the client request metadata needs to be wrapped alongside the service response data by the ``rmw`` implementation. +``email`` natively supports all of this metadata, which is included in standard email headers (i.e., not in the email body). + +.. _rmw-impl-guide_typesupport: + +Type support +^^^^^^^^^^^^ + +To bridge the gap between ROS 2 :doc:`interfaces <../../About-Interfaces>` (specifically :doc:`custom interfaces `) and the underlying middleware, some glue code is needed. +This is referred to as :ref:`type support `. +When publishing a message of type {interface(std_msgs/msg/String)}, ``rmw_publish()`` only gets a ``void *`` to the message, which could point to a C++ instance, or a C instance, and so on. +The pointer will be interpreted based on the type support information provided when the publisher was created. + +First, code is generated for each combination of interface type and user-facing language, independent of the underlying middleware. +For example, for the {interface(std_msgs/msg/String)} message type, data structures are generated: + +#. C++: ``std_msgs/msg/string.hpp`` header with ``std_msgs::msg::String`` class generated by the ``rosidl_generator_cpp`` package +#. C: ``std_msgs/msg/string.h`` header with ``std_msgs__msg__String`` struct generated by the ``rosidl_generator_c`` package +#. Python: ``std_msgs`` module with ``std_msgs.msg.String`` class (which is just a wrapper around the C struct) generated by the ``rosidl_generator_py`` package +#. (and so on, e.g., for Rust) + +Second, for the underlying middleware to be able to send and receive messages, it needs to know how to interpret the user-facing data structure. +This is one of the most critical parts of an ``rmw`` implementation. +There are two options: :ref:`static type support ` and :ref:`dynamic type support `. +Static type support involves generating middleware-specific code for each interface. +For example, ``rosidl_typesupport_fastrtps_cpp`` generates code to serialize/deserialize C++ classes of each interface type into CDR using `Fast CDR `_ for ``rmw_fastrtps_cpp`` to pass on to Fast DDS. +[#fn_ts_fastrtps]_ +``rmw_connextdds`` and even ``rmw_zenoh_cpp`` use CDR for serialization, so they use this type support package as well. +On the other hand, dynamic type support involves generating a bit of middleware-independent code that provides generic information about each interface type. +[#fn_ts_dynamic]_ + +This information can be used at runtime by any ``rmw`` implementation to interpret a type-erased pointer to data: names & types of fields, functions to read from/write to fields depending on their type, functions to get the size of an array field, etc. +For C++, this is ``rosidl_typesupport_introspection_cpp``, which is used by ``rmw_fastrtps_dynamic_cpp`` (hence the "dynamic" part), for example. + +Dynamic type support is generally slower than static type support at runtime because it has to iterate over each message field, figure out what type it is, and then process it, e.g., serialize it. +Static type support knows exactly how to process the message thanks to the code it generated for each interface type. +This is why most ``rmw`` implementations use static type support. +However, dynamic type support does not require generating middleware-specific code. +Choosing between static and dynamic type support is an orthogonal decision to the ``rmw`` implementation itself. + +``rmw_email_cpp`` uses dynamic type support to convert messages to and from YAML string to be sent over email. +It gets the type support introspection information, and passes it and the message to an external/experimental package, `dynmsg `_, which converts the message to/from YAML. +The YAML object is then sent as a YAML-formatted string via email using the underlying middleware. +When a new message is received by the middleware, the YAML string is converted into a message. + +Domain ID +^^^^^^^^^ + +:doc:`Domain IDs <../../nodes/About-Domain-ID>` are a way to have separate logical networks on the same physical network. +It is a native feature of DDS, but not Zenoh. +DDS achieves this by using the domain ID as a network port offset, while Zenoh implements it by making the domain ID the first component of the internal Zenoh key corresponding to each ROS 2 topic. + +Quality of service (QoS) +^^^^^^^^^^^^^^^^^^^^^^^^ + +:doc:`Quality of service settings <../../topics/About-Quality-of-Service-Settings>` in ROS 2 are largely derived from DDS. +Basic QoS policies like history, depth, and durability are the same as ROS 1's, but more advanced policies simply come from DDS. +Implementations may simply ignore some settings. +For instance, ``rmw_zenoh_cpp`` doesn't implement the deadline and lifespan QoS policies. + +One important aspect of QoS is that two profiles, e.g., a publisher's profile and a subscription's profile, may be incompatible, meaning they cannot communicate. +It is up to the implementation to decide if two QoS profiles are compatible: ``rmw_qos_profile_check_compatible()``. +DDS-based implementations rely on ``rmw_dds_common::qos_profile_check_compatible()``, since :ref:`QoS profile compatibility ` is standard in DDS. +In Zenoh, `QoS settings are essentially never incompatible `_. + +To support a universal "default" behavior, QoS policies include a ``*_SYSTEM_DEFAULT`` setting (e.g., ``rmw_qos_reliability_policy_t``'s ``RMW_QOS_POLICY_RELIABILITY_SYSTEM_DEFAULT``), which leaves the value up to the middleware implementation. +Then the ``rmw_*_get_actual_qos()`` functions retrieve the actual QoS profile used by the implementation. + +.. _rmw-impl-guide_introspection: + +ROS graph introspection +^^^^^^^^^^^^^^^^^^^^^^^ + +Nodes are able to get a list of other nodes, topics, etc. +This also allows publishers to know if any subscriptions exist for their topic, for example. +This same mechanism is used to :doc:`list nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, and so on with the ROS 2 CLI: ``ros2 node list``, ``ros2 topic list``, etc. + +This is supported by a number of ``rmw`` functions: ``rmw_get_node_names()``, ``rmw_get_topic_names_and_types()``, ``rmw_publisher_count_matched_subscriptions()``, and many more. +While the implementation is not specified by the interface, ``rmw`` implementations usually maintain a cache of the ROS graph. +When they create a new entity (e.g., node, publisher, subscription, service, client), they note it in their internal graph cache and notify other participants through a middleware-specific mechanism so that they can add it to their cache. +The graph cache belongs to the ``rmw`` context, so it is initialized when ``rmw_init()`` is called. +This context indirectly belongs to the ``rclcpp`` context (e.g., initialized by ``rclcpp::init()``), so there is usually only one graph cache per process. + +Since DDS-based ``rmw`` implementations are very similar in this regard, they share a common graph cache implementation in the ``rmw_dds_common`` `package `__. +It uses an internal topic (usually ``ros_discovery_info``) to share information about new entities. +``rmw_zenoh_cpp`` `creates a Zenoh liveliness token `_ with the entity type & info and shares it with other participants. + +Events +^^^^^^ + +Users can provide callbacks for publishers & subscriptions to be triggered by the middleware (but executed by the client library) on certain events (``rmw_event_type_t``), such as :ref:`quality of service-related events ` and :ref:`pub-sub match events `. +Some of these events could be triggered on relevant changes to the graph cache. + +Security +^^^^^^^^ + +:doc:`Security <../../../Developer-Tools/Introspection-and-analysis/About-Security>` is not well-specified by the ``rmw`` interface; most of it is specified by :doc:`SROS2 <../../../Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security>`. +The interface only defines a few security options as part of the context initialization options, ``rmw_init_options_t``: + +#. ``rmw_security_options_t``, which includes a security policy (enforce/permissive) and a path to a directory containing security artifacts, i.e., a keystore. + These are set by ``rcl`` based on environment variables: ``ROS_SECURITY_ENABLE`` & ``ROS_SECURITY_STRATEGY`` and ``ROS_SECURITY_KEYSTORE``. +#. The name of a security enclave from the keystore to use for the given process. + This is set, for example, through the ``--enclave`` option when running a node with ``ros2 run``. + +However, in practice, the structure of the :doc:`keystore <../../../Developer-Tools/Build/The-Keystore>` directory and its security enclaves is based on the DDS Security specification. +Therefore, :doc:`security artifacts generated <../../../Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security>` with the ``sros2`` package can only be directly used by DDS-based ``rmw`` implementations. +For ``rmw_zenoh_cpp``, `Zenoh-specific security configuration files can be generated `_ from ``sros2``-generated artifacts using the ``zenoh_security_tools`` package and provided through the ``ZENOH_SESSION_CONFIG_URI`` environment variable, bypassing the ``ROS_SECURITY_*`` environment variables. + +Implementation +-------------- + +Implementation skeleton +^^^^^^^^^^^^^^^^^^^^^^^ + +This section covers concrete steps to create the base files and directories for the new implementation package, including special handling in ``package.xml`` and ``CMakeLists.txt``. + +Start with the :doc:`package creation tutorial ` to create an empty package. +Then make the following changes: + +#. ``package.xml`` + + #. Define a package/implementation name + + The package name is also the name of the ``rmw`` implementation. + It will be used to :ref:`select the implementation ` through the ``RMW_IMPLEMENTATION`` environment variable or CMake option, for example. + The name usually starts with ``rmw_`` and is followed by the name of the underlying middleware. + Most :doc:`implementations in the ROS 2 ecosystem <../About-Different-Middleware-Vendors>` then append a suffix such as ``_cpp`` to indicate that the implementation is written in C++. + However, that is not required. + Examples: ``rmw_fastrtps_cpp``, ``rmw_cyclonedds_cpp``, ``rmw_connextdds``, ``rmw_zenoh_cpp``, and ``rmw_email_cpp``. + + .. code-block:: xml + + + rmw_IMPLEMENTATION_NAME_cpp + + #. Declare a dependency on ``rmw`` + + Since the package will implement the interface declared in the ``rmw`` package and will depend on some utility functions. + + .. code-block:: xml + + rmw + + #. Declare a dependency on the required type support packages + + See the :ref:`type support section ` for details. + + .. code-block:: xml + + + rosidl_typesupport_fastrtps_c + rosidl_typesupport_fastrtps_cpp + rosidl_typesupport_introspection_c + rosidl_typesupport_introspection_cpp + + #. Declare membership of the ``rmw_implementation_packages`` group + + This allows the ``rmw_implementation`` package to `depend on the implementation `_ so that it gets built alongside other implementations, since no package otherwise explicitly depends on any ``rmw`` implementations. + This way it can be found and used if selected. + + .. code-block:: xml + + rmw_implementation_packages + +#. ``CMakeLists.txt`` + + #. Create the library target + + The library has to be a shared library. + It should depend on ``rmw`` for headers and utility functions as well as the required type support packages. + It will also depend on the underlying middleware. + + .. code-block:: cmake + + add_library(${PROJECT_NAME} SHARED + src/file.cpp + # ... + ) + target_link_libraries(${PROJECT_NAME} PUBLIC + rmw::rmw + ) + target_link_libraries(${PROJECT_NAME} PRIVATE + rosidl_typesupport_fastrtps_c::rosidl_typesupport_fastrtps_c + rosidl_typesupport_fastrtps_cpp::rosidl_typesupport_fastrtps_cpp + rosidl_typesupport_introspection_c::rosidl_typesupport_introspection_c + rosidl_typesupport_introspection_cpp::rosidl_typesupport_introspection_cpp + # TODO add any implementation-specific dependencies, e.g., underlying middleware + ) + + #. Configure the implementation library target + + In practice, this simply makes symbols hidden by default to hide internal symbols, i.e., non-``rmw`` interface symbols. + If the implementation is written in C (not common), specify ``LANGUAGE "C"``. + + .. code-block:: cmake + + configure_rmw_library(${PROJECT_NAME}) + + #. Register the ``rmw`` implementation + + This registers the implementation in the :ref:`ament index ` so that it can be found at build-time (``get_available_rmw_implementations()``, ``get_rmw_typesupport()``) or at runtime (``ament_index_cpp::get_resources("rmw_typesupport")``). + It also registers the languages that the implementation supports and the list of type support packages. + For example, if the implementation only uses type support introspection (i.e., dynamic and not static) for C and C++ messages: + + .. code-block:: cmake + + register_rmw_implementation( + "c:rosidl_typesupport_introspection_c" + "cpp:rosidl_typesupport_introspection_cpp" + ) + + .. For example, the Python client library, ``rclpy``, uses C typesupport, and checks if C typesupport is available using ``get_rmw_typesupport()``, so the ``rmw`` implementation must support it. + + #. Install and export target + + .. code-block:: cmake + + install( + TARGETS ${PROJECT_NAME} + EXPORT ${PROJECT_NAME} + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + + ament_export_targets(${PROJECT_NAME}) + # ament_export_libraries(${PROJECT_NAME}) # Old-style CMake + + # ... + +Interface functions implementation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The first step is to define the C interface functions declared in the ``rmw`` headers. +Start with empty functions that simply return ``RMW_RET_OK``, and then implement them one by one in the order in which they are likely to be called at runtime. +For example: ``rmw_init()``, ``rmw_create_node()``, ``rmw_create_publisher()``, ``rmw_create_subscription()``, and so on. +This will allow building and running/testing the implementation incrementally. + +Most ``rmw`` functions have to perform input validation, as defined by the function's documentation. +There are various utility macros to simplify this, such as ``RMW_CHECK_ARGUMENT_FOR_NULL()`` and ``RMW_CHECK_TYPE_IDENTIFIERS_MATCH()``. + +``rmw`` structs usually include a type-erased pointer (or sometimes an opaque pointer) for ``rmw`` implementation-specific data. +For instance, ``rmw_publisher_t`` has a ``void * data``. +The implementation can place whatever it wants there, e.g., a pointer to an internal object that wraps the underlying middleware's publisher object and any relevant information, like type support. +This data/object can be fetched and used later when ``rmw_publish()`` is called with the corresponding ``rmw_publisher_t``. +To make sure that a different ``rmw`` implementation doesn't try to interpret this data, ``rmw_publisher_t`` includes the name of the implementation in its ``implementation_identifier`` field. + +Type support +^^^^^^^^^^^^ + +Type support structs can be confusing. +Here is an example for message type support for publishers/subscriptions. + +A publisher is created through ``rmw_create_publisher()``, which takes in a handle for the type support information: ``const rosidl_message_type_support_t *``. +This is the base language-dependent type support: ``rosidl_typesupport_c`` / ``rosidl_typesupport_cpp``. +From this, we can get the concrete type support handle, depending on the available type supports, e.g., ``rosidl_typesupport_fastrtps_c`` / ``rosidl_typesupport_fastrtps_cpp`` and ``rosidl_typesupport_introspection_c`` / ``rosidl_typesupport_introspection_cpp``. +The confusing part is that these are also of type ``const rosidl_message_type_support_t *``! +However, the concrete type support handles are the ones that contain actual useful information. +See `this example function `__, which extracts the concrete C or C++ dynamic message type support handle (``rosidl_typesupport_introspection_{c,cpp}``) given a base type support handle (``rosidl_typesupport_{c,cpp}``). +Publishers created by ``rclcpp`` will use C++ type support, while publishers created by ``rclpy`` will use C type support, since Python messages get converted into C messages. +The ``/rosout`` publisher is managed by ``rcl``, which is written in C, so it uses C type support. + +Then, using the concrete type support handle's type-erased pointer, ``const void * data``, we get type support-specific information. +For example, for C++ dynamic type support, this will be a ``const rosidl_typesupport_introspection_cpp::MessageMembers *``, which contains information about each field of the message. +See `this example function `__, which extracts language-dependent type support information from the concrete type support handle. +The information is used to read the type-erased message pointer and convert the message to a YAML object and then convert that to a string for the underlying middleware to publish. + +Service type support is similar, but ``rosidl_service_type_support_t`` points to separate type support information for the request and response message types. + +Tests +----- + +The ``rmw`` package contains some tests, but they are mostly for utilities (e.g., getting zero-initialized structs) and non-implementation-specific functions such as topic/node name/namespace validation. + +As for testing the new ``rmw`` implementation, the ``test_rmw_implementation`` package `contains tests for the interface `_. +Test executables are defined first and then a CMake function creates test targets for a given ``rmw`` implementation by setting the ``RMW_IMPLEMENTATION`` environment variable. +``rmw_implementation_cmake``'s ``call_for_each_rmw_implementation()`` is called and is provided with this CMake function, which is called with each available implementation. +See the `CMakeLists.txt file `__. +Many other packages, including the ``test_rclcpp`` test-only package, also `use this mechanism `__ to run tests against all available ``rmw`` implementations, otherwise tests are simply run with the default implementation. +Packages can also use ``get_available_rmw_implementations()`` to get the actual list of available implementations. + +Some tests have implementation-specific code, which is done for various reasons, such as unsupported interface subsets. +These tests can use ``rmw``'s ``rmw_get_implementation_identifier()`` `function `__ for this. + +Middleware- and ``rmw`` implementation-specific configuration +------------------------------------------------------------- + +The ``rmw`` interface allows providing arbitrary implementation-specific configuration payloads for publishers and subscriptions through the type-erased ``rmw_specific_publisher_payload`` / ``rmw_specific_subscription_payload`` fields in ``rmw_publisher_options_t`` / ``rmw_subscription_options_t``. +This is set by users through ``RMWImplementationSpecificPublisherPayload`` / ``RMWImplementationSpecificSubscriptionPayload`` in ``rclcpp``, for example. +This is an advanced, non-portable feature that is not currently used by any (tier 1) implementations. + +For a bit more flexibility, some implementations use environment variables: ``RMW_FASTRTPS_*``, ``RMW_CONNEXT_*``, etc. +The underlying middleware may also be configurable through environment variables: ``FASTDDS_*``, ``ZENOH_*``, ``CYCLONEDDS_*``, ``EMAIL_*``, etc. +For example, the ``CYCLONEDDS_URI``, ``FASTDDS_DEFAULT_PROFILES_FILE``, and ``ZENOH_SESSION_CONFIG_URI`` environment variables can be used to provide a path to a full configuration file if the relevant middleware is used. + +Footnotes +--------- + +.. [#fn_dds_rpc] + There now is a DDS RPC specification, but `it was not finalized and wasn't implemented by DDS vendors back when ROS 2 was initially designed `_. + Since the ``rmw`` interface is also officially DDS-agnostic, services are up to the ``rmw`` implementation, which explains why :ref:`cross-DDS vendor communications are not guaranteed `, even if pub/sub generally works. + +.. [#fn_gid_remote_matching] + In practice, this is not always the case, so this requirement is somewhat relaxed. + See `ros2/rmw_cyclonedds#377 `_. + +.. [#fn_ts_fastrtps] + For example, the C++ message Fast CDR serialization/deserialization code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_fastrtps_cpp/std_msgs/msg/detail/dds_fastrtps/header__type_support.cpp`` under the ``build/`` directory. + +.. [#fn_ts_dynamic] + For example, the C++ message introspection code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_introspection_cpp/std_msgs/msg/detail/header__type_support.cpp`` under the ``build/`` directory. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst index 82e31a09eb1..ec136d3c4b7 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst @@ -1,537 +1,538 @@ -.. redirect-from:: - - Tutorials/Creating-Your-First-ROS2-Package - -.. _CreatePkg: - -Creating a package -================== - -**Goal:** Create a new package using either CMake or Python, and run its executable. - -**Tutorial level:** Beginner - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -1 What is a ROS 2 package? -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A package is an organizational unit for your ROS 2 code. -If you want to be able to install your code or share it with others, then you'll need it organized in a package. -With packages, you can release your ROS 2 work and allow others to build and use it easily. - -Package creation in ROS 2 uses ament as its build system and colcon as its build tool. -You can create a package using either CMake or Python, which are officially supported, though other build types do exist. - -2 What makes up a ROS 2 package? -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 Python and CMake packages each have their own minimum required contents: - -.. tabs:: - - .. group-tab:: CMake - - * ``CMakeLists.txt`` file that describes how to build the code within the package - * ``include/`` directory containing the public headers for the package - * ``package.xml`` file containing meta information about the package - * ``src`` directory containing the source code for the package - - .. group-tab:: Python - - * ``package.xml`` file containing meta information about the package - * ``resource/`` marker file for the package - * ``setup.cfg`` is required when a package has executables, so ``ros2 run`` can find them - * ``setup.py`` containing instructions for how to install the package - * ```` - a directory with the same name as your package, used by ROS 2 tools to find your package, contains ``__init__.py`` - -The simplest possible package may have a file structure that looks like: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: console - - my_package/ - CMakeLists.txt - include/my_package/ - package.xml - src/ - - .. group-tab:: Python - - .. code-block:: console - - my_package/ - package.xml - resource/my_package - setup.cfg - setup.py - my_package/ - - -3 Packages in a workspace -^^^^^^^^^^^^^^^^^^^^^^^^^ - -A single workspace can contain as many packages as you want, each in their own folder. -You can also have packages of different build types in one workspace (CMake, Python, etc.). -You cannot have nested packages. - -Best practice is to have a ``src`` folder within your workspace, and to create your packages in there. -This keeps the top level of the workspace "clean". - -A trivial workspace might look like: - -.. code-block:: console - - workspace_folder/ - src/ - cpp_package_1/ - CMakeLists.txt - include/cpp_package_1/ - package.xml - src/ - - py_package_1/ - package.xml - resource/py_package_1 - setup.cfg - setup.py - py_package_1/ - ... - cpp_package_n/ - CMakeLists.txt - include/cpp_package_n/ - package.xml - src/ - - -Prerequisites -------------- - -You should have a ROS 2 workspace after following the instructions in the :doc:`previous tutorial <./Creating-A-Workspace/Creating-A-Workspace>`. -You will create your package in this workspace. - - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First, :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>`. - -Let's use the workspace you created in the :ref:`previous tutorial `, ``ros2_ws``, for your new package. - -Make sure you are in the ``src`` folder before running the package creation command. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws/src - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws/src - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_ws\src - -The command syntax for creating a new package in ROS 2 is: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 - -For this tutorial, you will use the optional arguments ``--node-name`` and ``--license``. -``--node-name`` option creates a simple Hello World type executable in the package, and ``--license`` declares the license information for the package. - -Enter the following command in your terminal: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --node-name my_node my_package - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 --node-name my_node my_package - -You will now have a new folder within your workspace's ``src`` directory called ``my_package``. - -After running the command, your terminal will return the message: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: console - - going to create a new package - package name: my_package - destination directory: /home/user/ros2_ws/src - package format: 3 - version: 0.0.0 - description: TODO: Package description - maintainer: [' '] - licenses: ['Apache-2.0'] - build type: ament_cmake - dependencies: [] - node_name: my_node - creating folder ./my_package - creating ./my_package/package.xml - creating source and include folder - creating folder ./my_package/src - creating folder ./my_package/include/my_package - creating ./my_package/CMakeLists.txt - creating ./my_package/src/my_node.cpp - - .. group-tab:: Python - - .. code-block:: console - - going to create a new package - package name: my_package - destination directory: /home/user/ros2_ws/src - package format: 3 - version: 0.0.0 - description: TODO: Package description - maintainer: [' '] - licenses: ['Apache-2.0'] - build type: ament_python - dependencies: [] - node_name: my_node - creating folder ./my_package - creating ./my_package/package.xml - creating source folder - creating folder ./my_package/my_package - creating ./my_package/setup.py - creating ./my_package/setup.cfg - creating folder ./my_package/resource - creating ./my_package/resource/my_package - creating ./my_package/my_package/__init__.py - creating folder ./my_package/test - creating ./my_package/test/test_copyright.py - creating ./my_package/test/test_flake8.py - creating ./my_package/test/test_pep257.py - creating ./my_package/my_package/my_node.py - -You can see the automatically generated files for the new package. - -2 Build a package -^^^^^^^^^^^^^^^^^ - -Putting packages in a workspace is especially valuable because you can build many packages at once by running ``colcon build`` in the workspace root. -Otherwise, you would have to build each package individually. - -Return to the root of your workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_ws - -Now you can build your packages: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install - - Windows doesn't allow long paths, so ``merge-install`` will combine all the paths into the ``install`` directory. - -Recall from the last tutorial that you also have the ``ros_tutorials`` packages in your ``ros2_ws``. -You might have noticed that running ``colcon build`` also built the ``turtlesim`` package. -That's fine when you only have a few packages in your workspace, but when there are many packages, ``colcon build`` can take a long time. - -To build only the ``my_package`` package next time, you can run: - -.. code-block:: console - - $ colcon build --packages-select my_package - -3 Source the setup file -^^^^^^^^^^^^^^^^^^^^^^^ - -To use your new package and executable, first open a new terminal and source your main ROS 2 installation. - -Then, from inside the ``ros2_ws`` directory, run the following command to source your workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/local_setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/local_setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/local_setup.bat - -Now that your workspace has been added to your path, you will be able to use your new package's executables. - -4 Use the package -^^^^^^^^^^^^^^^^^ - -To run the executable you created using the ``--node-name`` argument during package creation, enter the command: - -.. code-block:: console - - $ ros2 run my_package my_node - -Which will return a message to your terminal: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: console - - hello world my_package package - - .. group-tab:: Python - - .. code-block:: console - - Hi from my_package. - -5 Examine package contents -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Inside ``ros2_ws/src/my_package``, you will see the files and folders that ``ros2 pkg create`` automatically generated: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: console - - CMakeLists.txt include package.xml src - - ``my_node.cpp`` is inside the ``src`` directory. - This is where all your custom C++ nodes will go in the future. - - .. group-tab:: Python - - .. code-block:: console - - my_package package.xml resource setup.cfg setup.py test - - ``my_node.py`` is inside the ``my_package`` directory. - This is where all your custom Python nodes will go in the future. - -6 Customize package.xml -^^^^^^^^^^^^^^^^^^^^^^^ - -You may have noticed in the return message after creating your package that the fields ``description`` and ``license`` contain ``TODO`` notes. -That's because the package description and license declaration are not automatically set, but are required if you ever want to release your package. -The ``maintainer`` field may also need to be filled in. - -From ``ros2_ws/src/my_package``, open ``package.xml`` using your preferred text editor: - -.. tabs:: - - .. group-tab:: CMake - - .. code-block:: xml - - - - - my_package - 0.0.0 - TODO: Package description - user - TODO: License declaration - - ament_cmake - - ament_lint_auto - ament_lint_common - - - ament_cmake - - - - .. group-tab:: Python - - .. code-block:: xml - - - - - my_package - 0.0.0 - TODO: Package description - user - TODO: License declaration - - ament_copyright - ament_flake8 - ament_pep257 - python3-pytest - - - ament_python - - - -Input your name and email on the ``maintainer`` line if it hasn't been automatically populated for you. -Then, edit the ``description`` line to summarize the package: - -.. code-block:: xml - - Beginner client libraries tutorials practice package - -Then, update the ``license`` line. -You can read more about open source licenses `here `__. -Since this package is only for practice, it's safe to use any license. -We'll use ``Apache-2.0``: - -.. code-block:: xml - - Apache-2.0 - -Don't forget to save once you're done editing. - -Below the license tag, you will see some tag names ending with ``_depend``. -This is where your ``package.xml`` would list its dependencies on other packages, for colcon to search for. -``my_package`` is simple and doesn't have any dependencies, but you will see this space being utilized in upcoming tutorials. - -.. tabs:: - - .. group-tab:: CMake - - You're all done for now! - - .. group-tab:: Python - - The ``setup.py`` file contains the same description, maintainer and license fields as ``package.xml``, so you need to set those as well. - They need to match exactly in both files. - The version and name (``package_name``) also need to match exactly, and should be automatically populated in both files. - - Open ``setup.py`` with your preferred text editor. - - .. code-block:: python - - from setuptools import find_packages, setup - - package_name = 'my_py_pkg' - - setup( - name=package_name, - version='0.0.0', - packages=find_packages(exclude=['test']), - data_files=[ - ('share/ament_index/resource_index/packages', - ['resource/' + package_name]), - ('share/' + package_name, ['package.xml']), - ], - install_requires=['setuptools'], - zip_safe=True, - maintainer='TODO', - maintainer_email='TODO', - description='TODO: Package description', - license='TODO: License declaration', - extras_require={ - 'test': ['pytest'], - }, - entry_points={ - 'console_scripts': [ - 'my_node = my_py_pkg.my_node:main' - ], - }, - ) - - Edit the ``maintainer``, ``maintainer_email``, and ``description`` lines to match ``package.xml``. - - Don't forget to save the file. - - -Summary -------- - -You've created a package to organize your code and make it easy to use for others. - -Your package was automatically populated with the necessary files, and then you used colcon to build it so you can use its executables in your local environment. - -Next steps ----------- - -Next, let's add something meaningful to a package. -You'll start with a simple publisher/subscriber system, which you can choose to write in either :doc:`C++ <./Writing-A-Simple-Cpp-Publisher-And-Subscriber>` or :doc:`Python <./Writing-A-Simple-Py-Publisher-And-Subscriber>`. +.. redirect-from:: + + Tutorials/Creating-Your-First-ROS2-Package + Tutorials/Beginner-Client-Libraries/Creating-Your-First-ROS2-Package + +.. _CreatePkg: + +Creating a package +================== + +**Goal:** Create a new package using either CMake or Python, and run its executable. + +**Tutorial level:** Beginner + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +1 What is a ROS 2 package? +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A package is an organizational unit for your ROS 2 code. +If you want to be able to install your code or share it with others, then you'll need it organized in a package. +With packages, you can release your ROS 2 work and allow others to build and use it easily. + +Package creation in ROS 2 uses ament as its build system and colcon as its build tool. +You can create a package using either CMake or Python, which are officially supported, though other build types do exist. + +2 What makes up a ROS 2 package? +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 Python and CMake packages each have their own minimum required contents: + +.. tabs:: + + .. group-tab:: CMake + + * ``CMakeLists.txt`` file that describes how to build the code within the package + * ``include/`` directory containing the public headers for the package + * ``package.xml`` file containing meta information about the package + * ``src`` directory containing the source code for the package + + .. group-tab:: Python + + * ``package.xml`` file containing meta information about the package + * ``resource/`` marker file for the package + * ``setup.cfg`` is required when a package has executables, so ``ros2 run`` can find them + * ``setup.py`` containing instructions for how to install the package + * ```` - a directory with the same name as your package, used by ROS 2 tools to find your package, contains ``__init__.py`` + +The simplest possible package may have a file structure that looks like: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: console + + my_package/ + CMakeLists.txt + include/my_package/ + package.xml + src/ + + .. group-tab:: Python + + .. code-block:: console + + my_package/ + package.xml + resource/my_package + setup.cfg + setup.py + my_package/ + + +3 Packages in a workspace +^^^^^^^^^^^^^^^^^^^^^^^^^ + +A single workspace can contain as many packages as you want, each in their own folder. +You can also have packages of different build types in one workspace (CMake, Python, etc.). +You cannot have nested packages. + +Best practice is to have a ``src`` folder within your workspace, and to create your packages in there. +This keeps the top level of the workspace "clean". + +A trivial workspace might look like: + +.. code-block:: console + + workspace_folder/ + src/ + cpp_package_1/ + CMakeLists.txt + include/cpp_package_1/ + package.xml + src/ + + py_package_1/ + package.xml + resource/py_package_1 + setup.cfg + setup.py + py_package_1/ + ... + cpp_package_n/ + CMakeLists.txt + include/cpp_package_n/ + package.xml + src/ + + +Prerequisites +------------- + +You should have a ROS 2 workspace after following the instructions in the :doc:`previous tutorial `. +You will create your package in this workspace. + + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First, :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>`. + +Let's use the workspace you created in the :ref:`previous tutorial `, ``ros2_ws``, for your new package. + +Make sure you are in the ``src`` folder before running the package creation command. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws/src + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws/src + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_ws\src + +The command syntax for creating a new package in ROS 2 is: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 + +For this tutorial, you will use the optional arguments ``--node-name`` and ``--license``. +``--node-name`` option creates a simple Hello World type executable in the package, and ``--license`` declares the license information for the package. + +Enter the following command in your terminal: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --node-name my_node my_package + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 --node-name my_node my_package + +You will now have a new folder within your workspace's ``src`` directory called ``my_package``. + +After running the command, your terminal will return the message: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: console + + going to create a new package + package name: my_package + destination directory: /home/user/ros2_ws/src + package format: 3 + version: 0.0.0 + description: TODO: Package description + maintainer: [' '] + licenses: ['Apache-2.0'] + build type: ament_cmake + dependencies: [] + node_name: my_node + creating folder ./my_package + creating ./my_package/package.xml + creating source and include folder + creating folder ./my_package/src + creating folder ./my_package/include/my_package + creating ./my_package/CMakeLists.txt + creating ./my_package/src/my_node.cpp + + .. group-tab:: Python + + .. code-block:: console + + going to create a new package + package name: my_package + destination directory: /home/user/ros2_ws/src + package format: 3 + version: 0.0.0 + description: TODO: Package description + maintainer: [' '] + licenses: ['Apache-2.0'] + build type: ament_python + dependencies: [] + node_name: my_node + creating folder ./my_package + creating ./my_package/package.xml + creating source folder + creating folder ./my_package/my_package + creating ./my_package/setup.py + creating ./my_package/setup.cfg + creating folder ./my_package/resource + creating ./my_package/resource/my_package + creating ./my_package/my_package/__init__.py + creating folder ./my_package/test + creating ./my_package/test/test_copyright.py + creating ./my_package/test/test_flake8.py + creating ./my_package/test/test_pep257.py + creating ./my_package/my_package/my_node.py + +You can see the automatically generated files for the new package. + +2 Build a package +^^^^^^^^^^^^^^^^^ + +Putting packages in a workspace is especially valuable because you can build many packages at once by running ``colcon build`` in the workspace root. +Otherwise, you would have to build each package individually. + +Return to the root of your workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_ws + +Now you can build your packages: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install + + Windows doesn't allow long paths, so ``merge-install`` will combine all the paths into the ``install`` directory. + +Recall from the last tutorial that you also have the ``ros_tutorials`` packages in your ``ros2_ws``. +You might have noticed that running ``colcon build`` also built the ``turtlesim`` package. +That's fine when you only have a few packages in your workspace, but when there are many packages, ``colcon build`` can take a long time. + +To build only the ``my_package`` package next time, you can run: + +.. code-block:: console + + $ colcon build --packages-select my_package + +3 Source the setup file +^^^^^^^^^^^^^^^^^^^^^^^ + +To use your new package and executable, first open a new terminal and source your main ROS 2 installation. + +Then, from inside the ``ros2_ws`` directory, run the following command to source your workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/local_setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/local_setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/local_setup.bat + +Now that your workspace has been added to your path, you will be able to use your new package's executables. + +4 Use the package +^^^^^^^^^^^^^^^^^ + +To run the executable you created using the ``--node-name`` argument during package creation, enter the command: + +.. code-block:: console + + $ ros2 run my_package my_node + +Which will return a message to your terminal: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: console + + hello world my_package package + + .. group-tab:: Python + + .. code-block:: console + + Hi from my_package. + +5 Examine package contents +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Inside ``ros2_ws/src/my_package``, you will see the files and folders that ``ros2 pkg create`` automatically generated: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: console + + CMakeLists.txt include package.xml src + + ``my_node.cpp`` is inside the ``src`` directory. + This is where all your custom C++ nodes will go in the future. + + .. group-tab:: Python + + .. code-block:: console + + my_package package.xml resource setup.cfg setup.py test + + ``my_node.py`` is inside the ``my_package`` directory. + This is where all your custom Python nodes will go in the future. + +6 Customize package.xml +^^^^^^^^^^^^^^^^^^^^^^^ + +You may have noticed in the return message after creating your package that the fields ``description`` and ``license`` contain ``TODO`` notes. +That's because the package description and license declaration are not automatically set, but are required if you ever want to release your package. +The ``maintainer`` field may also need to be filled in. + +From ``ros2_ws/src/my_package``, open ``package.xml`` using your preferred text editor: + +.. tabs:: + + .. group-tab:: CMake + + .. code-block:: xml + + + + + my_package + 0.0.0 + TODO: Package description + user + TODO: License declaration + + ament_cmake + + ament_lint_auto + ament_lint_common + + + ament_cmake + + + + .. group-tab:: Python + + .. code-block:: xml + + + + + my_package + 0.0.0 + TODO: Package description + user + TODO: License declaration + + ament_copyright + ament_flake8 + ament_pep257 + python3-pytest + + + ament_python + + + +Input your name and email on the ``maintainer`` line if it hasn't been automatically populated for you. +Then, edit the ``description`` line to summarize the package: + +.. code-block:: xml + + Beginner client libraries tutorials practice package + +Then, update the ``license`` line. +You can read more about open source licenses `here `__. +Since this package is only for practice, it's safe to use any license. +We'll use ``Apache-2.0``: + +.. code-block:: xml + + Apache-2.0 + +Don't forget to save once you're done editing. + +Below the license tag, you will see some tag names ending with ``_depend``. +This is where your ``package.xml`` would list its dependencies on other packages, for colcon to search for. +``my_package`` is simple and doesn't have any dependencies, but you will see this space being utilized in upcoming tutorials. + +.. tabs:: + + .. group-tab:: CMake + + You're all done for now! + + .. group-tab:: Python + + The ``setup.py`` file contains the same description, maintainer and license fields as ``package.xml``, so you need to set those as well. + They need to match exactly in both files. + The version and name (``package_name``) also need to match exactly, and should be automatically populated in both files. + + Open ``setup.py`` with your preferred text editor. + + .. code-block:: python + + from setuptools import find_packages, setup + + package_name = 'my_py_pkg' + + setup( + name=package_name, + version='0.0.0', + packages=find_packages(exclude=['test']), + data_files=[ + ('share/ament_index/resource_index/packages', + ['resource/' + package_name]), + ('share/' + package_name, ['package.xml']), + ], + install_requires=['setuptools'], + zip_safe=True, + maintainer='TODO', + maintainer_email='TODO', + description='TODO: Package description', + license='TODO: License declaration', + extras_require={ + 'test': ['pytest'], + }, + entry_points={ + 'console_scripts': [ + 'my_node = my_py_pkg.my_node:main' + ], + }, + ) + + Edit the ``maintainer``, ``maintainer_email``, and ``description`` lines to match ``package.xml``. + + Don't forget to save the file. + + +Summary +------- + +You've created a package to organize your code and make it easy to use for others. + +Your package was automatically populated with the necessary files, and then you used colcon to build it so you can use its executables in your local environment. + +Next steps +---------- + +Next, let's add something meaningful to a package. +You'll start with a simple publisher/subscriber system, which you can choose to write in either :doc:`C++ ` or :doc:`Python `. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst index 2069f08d9ba..44ee8411f7a 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst @@ -1,799 +1,800 @@ -.. redirect-from:: - - Tutorials/Custom-ROS2-Interfaces - -.. _CustomInterfaces: - -Creating custom msg and srv files -================================= - -**Goal:** Define custom interface files (``.msg`` and ``.srv``) and use them with Python and C++ nodes. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials you utilized message and service interfaces to learn about :doc:`topics <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services>`, and simple publisher/subscriber (:doc:`C++ <./Writing-A-Simple-Cpp-Publisher-And-Subscriber>`/:doc:`Python<./Writing-A-Simple-Py-Publisher-And-Subscriber>`) and service/client (:doc:`C++ <./Writing-A-Simple-Cpp-Service-And-Client>`/:doc:`Python<./Writing-A-Simple-Py-Service-And-Client>`) nodes. -The interfaces you used were predefined in those cases. - -While it's good practice to use predefined interface definitions, you will probably need to define your own messages and services sometimes as well. -This tutorial will introduce you to the simplest method of creating custom interface definitions. - -Prerequisites -------------- - -You should have a :doc:`ROS 2 workspace <./Creating-A-Workspace/Creating-A-Workspace>`. - -This tutorial also uses the packages created in the publisher/subscriber (:doc:`C++ <./Writing-A-Simple-Cpp-Publisher-And-Subscriber>` and :doc:`Python<./Writing-A-Simple-Py-Publisher-And-Subscriber>`) and service/client (:doc:`C++ <./Writing-A-Simple-Cpp-Service-And-Client>` and :doc:`Python<./Writing-A-Simple-Py-Service-And-Client>`) tutorials to try out the new custom messages. - -Tasks ------ - -1 Create a new package -^^^^^^^^^^^^^^^^^^^^^^^ - -For this tutorial you will be creating custom ``.msg`` and ``.srv`` files in their own package, and then utilizing them in a separate package. -Both packages should be in the same workspace. - -Since we will use the pub/sub and service/client packages created in earlier tutorials, make sure you are in the same workspace as those packages (``ros2_ws/src``), and then run the following command to create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 tutorial_interfaces - -``tutorial_interfaces`` is the name of the new package. -Note that it is, and can only be, an ament_cmake package, but this doesn't restrict in which type of packages you can use your messages and services. -You can create your own custom interfaces in an ament_cmake package, and then use it in a C++ or Python node, which will be covered in the last section. - -The ``.msg`` and ``.srv`` files are required to be placed in directories called ``msg`` and ``srv`` respectively. -Create the directories in ``ros2_ws/src/tutorial_interfaces``: - -.. code-block:: console - - $ mkdir msg srv - -2 Create custom definitions -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -2.1 msg definition -~~~~~~~~~~~~~~~~~~ - -In the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Num.msg`` with one line of code declaring its data structure: - -.. code-block:: bash - - int64 num - -This is a custom message that transfers a single 64-bit integer called ``num``. - -Also in the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Sphere.msg`` with the following content: - -.. code-block:: bash - - geometry_msgs/Point center - float64 radius - -This custom message uses a message from another message package (``geometry_msgs/Point`` in this case). - -2.2 srv definition -~~~~~~~~~~~~~~~~~~ - -Back in the ``tutorial_interfaces/srv`` directory you just created, make a new file called ``AddThreeInts.srv`` with the following request and response structure: - -.. code-block:: bash - - int64 a - int64 b - int64 c - --- - int64 sum - -This is your custom service that requests three integers named ``a``, ``b``, and ``c``, and responds with an integer called ``sum``. - -3 ``CMakeLists.txt`` -^^^^^^^^^^^^^^^^^^^^ - -To convert the interfaces you defined into language-specific code (like C++ and Python) so that they can be used in those languages, add the following lines to ``CMakeLists.txt``: - -.. code-block:: cmake - - find_package(geometry_msgs REQUIRED) - find_package(rosidl_default_generators REQUIRED) - - rosidl_generate_interfaces(${PROJECT_NAME} - "msg/Num.msg" - "msg/Sphere.msg" - "srv/AddThreeInts.srv" - DEPENDENCIES geometry_msgs # Add packages that above messages depend on, in this case geometry_msgs for Sphere.msg - ) - -.. note:: - - The first argument (library name) in the ``rosidl_generate_interfaces`` must start with the name of the package, e.g., simply ``${PROJECT_NAME}`` or ``${PROJECT_NAME}_suffix``. - See https://github.com/ros2/rosidl/issues/441#issuecomment-591025515. - -4 ``package.xml`` -^^^^^^^^^^^^^^^^^ - -Because the interfaces rely on ``rosidl_default_generators`` for generating language-specific code, you need to declare a build tool dependency on it. -``rosidl_default_runtime`` is a runtime or execution-stage dependency, needed to be able to use the interfaces later. -The ``rosidl_interface_packages`` is the name of the dependency group that your package, ``tutorial_interfaces``, should be associated with, declared using the ```` tag. - -Add the following lines within the ```` element of ``package.xml``: - -.. code-block:: xml - - geometry_msgs - rosidl_default_generators - rosidl_default_runtime - rosidl_interface_packages - -5 Build the ``tutorial_interfaces`` package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now that all the parts of your custom interfaces package are in place, you can build the package. -In the root of your workspace (``~/ros2_ws``), run the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select tutorial_interfaces - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select tutorial_interfaces - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select tutorial_interfaces - -Now the interfaces will be discoverable by other ROS 2 packages. - -6 Confirm msg and srv creation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In a new terminal, run the following command from within your workspace (``ros2_ws``) to source it: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now you can confirm that your interface creation worked by using the ``ros2 interface show`` command. -The output you see in your terminal should look similar to the following: - -.. code-block:: console - - $ ros2 interface show tutorial_interfaces/msg/Num - int64 num - -.. code-block:: console - - $ ros2 interface show tutorial_interfaces/msg/Sphere - geometry_msgs/Point center - float64 x - float64 y - float64 z - float64 radius - -.. code-block:: console - - $ ros2 interface show tutorial_interfaces/srv/AddThreeInts - int64 a - int64 b - int64 c - --- - int64 sum - -7 Test the new interfaces -^^^^^^^^^^^^^^^^^^^^^^^^^ - -For this step you can use the packages you created in previous tutorials. -A few simple modifications to the nodes, ``CMakeLists.txt`` and ``package.xml`` files will allow you to use your new interfaces. - -7.1 Testing ``Num.msg`` with pub/sub -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -With a few modifications to the publisher/subscriber package created in a previous tutorial (:doc:`C++ <./Writing-A-Simple-Cpp-Publisher-And-Subscriber>` or :doc:`Python <./Writing-A-Simple-Py-Publisher-And-Subscriber>`), you can see ``Num.msg`` in action. -Since you'll be changing the standard string msg to a numerical one, the output will be slightly different. - -**Publisher** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/msg/num.hpp" // CHANGE - - using namespace std::chrono_literals; - - class MinimalPublisher : public rclcpp::Node - { - public: - MinimalPublisher() - : Node("minimal_publisher"), count_(0) - { - publisher_ = this->create_publisher("topic", 10); // CHANGE - - auto timer_callback = [this](){ - auto message = tutorial_interfaces::msg::Num(); // CHANGE - message.num = this->count_++; // CHANGE - RCLCPP_INFO_STREAM(this->get_logger(), "Publishing: '" << message.num << "'"); // CHANGE - publisher_->publish(message); - }; - timer_ = this->create_wall_timer(500ms, timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; // CHANGE - size_t count_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tutorial_interfaces.msg import Num # CHANGE - - - class MinimalPublisher(Node): - - def __init__(self): - super().__init__('minimal_publisher') - self.publisher_ = self.create_publisher(Num, 'topic', 10) # CHANGE - timer_period = 0.5 # seconds - self.timer = self.create_timer(timer_period, self.timer_callback) - self.i = 0 - - def timer_callback(self): - msg = Num() # CHANGE - msg.num = self.i # CHANGE - self.publisher_.publish(msg) - self.get_logger().info('Publishing: "%d"' % msg.num) # CHANGE - self.i += 1 - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_publisher = MinimalPublisher() - - rclpy.spin(minimal_publisher) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -**Subscriber** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/msg/num.hpp" // CHANGE - - using std::placeholders::_1; - - class MinimalSubscriber : public rclcpp::Node - { - public: - MinimalSubscriber() - : Node("minimal_subscriber") - { - auto topic_callback = [this](const tutorial_interfaces::msg::Num & msg){ // CHANGE - RCLCPP_INFO_STREAM(this->get_logger(), "I heard: '" << msg.num << "'"); // CHANGE - }; - subscription_ = this->create_subscription( // CHANGE - "topic", 10, topic_callback); - } - - private: - rclcpp::Subscription::SharedPtr subscription_; // CHANGE - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tutorial_interfaces.msg import Num # CHANGE - - - class MinimalSubscriber(Node): - - def __init__(self): - super().__init__('minimal_subscriber') - self.subscription = self.create_subscription( - Num, # CHANGE - 'topic', - self.listener_callback, - 10) - self.subscription # prevent unused variable warning - - def listener_callback(self, msg): - self.get_logger().info('I heard: "%d"' % msg.num) # CHANGE - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_subscriber = MinimalSubscriber() - - rclpy.spin(minimal_subscriber) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -**CMakeLists.txt** - -Add the following lines (C++ only): - -.. code-block:: cmake - - #... - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(tutorial_interfaces REQUIRED) # CHANGE - - add_executable(talker src/publisher_lambda_function.cpp) - target_link_libraries(talker PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - add_executable(listener src/subscriber_lambda_function.cpp) - target_link_libraries(listener PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - install(TARGETS - talker - listener - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - - -**package.xml** - -Add the following line: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - tutorial_interfaces - - .. group-tab:: Python - - .. code-block:: python - - tutorial_interfaces - - -After making the above edits and saving all the changes, build the package: - -.. tabs:: - - .. group-tab:: C++ - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select cpp_pubsub - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_pubsub - - .. group-tab:: Python - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select py_pubsub - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select py_pubsub - -Then open two new terminals, source ``ros2_ws`` in each, and run: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: console - - $ ros2 run cpp_pubsub talker - - .. code-block:: console - - $ ros2 run cpp_pubsub listener - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 run py_pubsub talker - - .. code-block:: console - - $ ros2 run py_pubsub listener - -Since ``Num.msg`` relays only an integer, the talker should only be publishing integer values, as opposed to the string it published previously: - -.. code-block:: console - - [INFO] [minimal_publisher]: Publishing: '0' - [INFO] [minimal_publisher]: Publishing: '1' - [INFO] [minimal_publisher]: Publishing: '2' - - -7.2 Testing ``AddThreeInts.srv`` with service/client -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -With a few modifications to the service/client package created in a previous tutorial (:doc:`C++ <./Writing-A-Simple-Cpp-Service-And-Client>` or :doc:`Python <./Writing-A-Simple-Py-Service-And-Client>`), you can see ``AddThreeInts.srv`` in action. -Since you'll be changing the original two integer request srv to a three integer request srv, the output will be slightly different. - -**Service** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE - - #include - - void add(const std::shared_ptr request, // CHANGE - std::shared_ptr response) // CHANGE - { - response->sum = request->a + request->b + request->c; // CHANGE - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Incoming request\na: %ld" " b: %ld" " c: %ld", // CHANGE - request->a, request->b, request->c); // CHANGE - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "sending back response: [%ld]", (long int)response->sum); - } - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_server"); // CHANGE - - rclcpp::Service::SharedPtr service = // CHANGE - node->create_service("add_three_ints", &add); // CHANGE - - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Ready to add three ints."); // CHANGE - - rclcpp::spin(node); - rclcpp::shutdown(); - } - - .. group-tab:: Python - - .. code-block:: python - - from tutorial_interfaces.srv import AddThreeInts # CHANGE - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalService(Node): - - def __init__(self): - super().__init__('minimal_service') - self.srv = self.create_service(AddThreeInts, 'add_three_ints', self.add_three_ints_callback) # CHANGE - - def add_three_ints_callback(self, request, response): - response.sum = request.a + request.b + request.c # CHANGE - self.get_logger().info('Incoming request\na: %d b: %d c: %d' % (request.a, request.b, request.c)) # CHANGE - - return response - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_service = MinimalService() - - rclpy.spin(minimal_service) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -**Client** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE - - #include - #include - #include - - using namespace std::chrono_literals; - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_client"); // CHANGE - rclcpp::Client::SharedPtr client = // CHANGE - node->create_client("add_three_ints"); // CHANGE - - auto request = std::make_shared(); // CHANGE - request->a = 41; - request->b = 1; - request->c = 1; // CHANGE - - while (!client->wait_for_service(1s)) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Interrupted while waiting for the service. Exiting."); - return 0; - } - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "service not available, waiting again..."); - } - - auto result = client->async_send_request(request); - // Wait for the result. - if (rclcpp::spin_until_future_complete(node, result) == - rclcpp::FutureReturnCode::SUCCESS) - { - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Sum: %ld", result.get()->sum); - } else { - RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Failed to call service add_three_ints"); // CHANGE - } - - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - from tutorial_interfaces.srv import AddThreeInts # CHANGE - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalClientAsync(Node): - - def __init__(self): - super().__init__('minimal_client_async') - self.cli = self.create_client(AddThreeInts, 'add_three_ints') # CHANGE - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddThreeInts.Request() # CHANGE - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - self.req.c = 1 # CHANGE - return self.cli.call_async(self.req) - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_client = MinimalClientAsync() - future = minimal_client.send_request() - rclpy.spin_until_future_complete(minimal_client, future) - response = future.result() - minimal_client.get_logger().info( - 'Result of add_three_ints: for %d + %d + %d = %d' % # CHANGE - (minimal_client.req.a, minimal_client.req.b, minimal_client.req.c, response.sum)) # CHANGE - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -**CMakeLists.txt** - -Add the following lines (C++ only): - -.. code-block:: cmake - - #... - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(tutorial_interfaces REQUIRED) # CHANGE - - add_executable(server src/add_two_ints_server.cpp) - target_link_libraries(server PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - add_executable(client src/add_two_ints_client.cpp) - target_link_libraries(client PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - install(TARGETS - server - client - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - - -**package.xml** - -Add the following line: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - tutorial_interfaces - - .. group-tab:: Python - - .. code-block:: python - - tutorial_interfaces - - -After making the above edits and saving all the changes, build the package: - -.. tabs:: - - .. group-tab:: C++ - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select cpp_srvcli - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_srvcli - - - .. group-tab:: Python - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select py_srvcli - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select py_srvcli - -Then open two new terminals, source ``ros2_ws`` in each, and run: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: console - - $ ros2 run cpp_srvcli server - - .. code-block:: console - - $ ros2 run cpp_srvcli client - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 run py_srvcli service - - .. code-block:: console - - $ ros2 run py_srvcli client - - -Summary -------- - -In this tutorial, you learned how to create custom interfaces in their own package and how to utilize those interfaces in other packages. - -This tutorial only scratches the surface about defining custom interfaces. -You can learn more about it in :doc:`About ROS 2 interfaces <../../Concepts/Basic/About-Interfaces>`. - -Next steps ----------- - -The :doc:`next tutorial <./Single-Package-Define-And-Use-Interface>` covers more ways to use interfaces in ROS 2. +.. redirect-from:: + + Tutorials/Custom-ROS2-Interfaces + Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces + +.. _CustomInterfaces: + +Creating custom msg and srv files +================================= + +**Goal:** Define custom interface files (``.msg`` and ``.srv``) and use them with Python and C++ nodes. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials you utilized message and service interfaces to learn about :doc:`topics <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, and simple publisher/subscriber (:doc:`C++ `/:doc:`Python `) and service/client (:doc:`C++ `/:doc:`Python `) nodes. +The interfaces you used were predefined in those cases. + +While it's good practice to use predefined interface definitions, you will probably need to define your own messages and services sometimes as well. +This tutorial will introduce you to the simplest method of creating custom interface definitions. + +Prerequisites +------------- + +You should have a :doc:`ROS 2 workspace `. + +This tutorial also uses the packages created in the publisher/subscriber (:doc:`C++ ` and :doc:`Python `) and service/client (:doc:`C++ ` and :doc:`Python `) tutorials to try out the new custom messages. + +Tasks +----- + +1 Create a new package +^^^^^^^^^^^^^^^^^^^^^^^ + +For this tutorial you will be creating custom ``.msg`` and ``.srv`` files in their own package, and then utilizing them in a separate package. +Both packages should be in the same workspace. + +Since we will use the pub/sub and service/client packages created in earlier tutorials, make sure you are in the same workspace as those packages (``ros2_ws/src``), and then run the following command to create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 tutorial_interfaces + +``tutorial_interfaces`` is the name of the new package. +Note that it is, and can only be, an ament_cmake package, but this doesn't restrict in which type of packages you can use your messages and services. +You can create your own custom interfaces in an ament_cmake package, and then use it in a C++ or Python node, which will be covered in the last section. + +The ``.msg`` and ``.srv`` files are required to be placed in directories called ``msg`` and ``srv`` respectively. +Create the directories in ``ros2_ws/src/tutorial_interfaces``: + +.. code-block:: console + + $ mkdir msg srv + +2 Create custom definitions +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +2.1 msg definition +~~~~~~~~~~~~~~~~~~ + +In the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Num.msg`` with one line of code declaring its data structure: + +.. code-block:: bash + + int64 num + +This is a custom message that transfers a single 64-bit integer called ``num``. + +Also in the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Sphere.msg`` with the following content: + +.. code-block:: bash + + geometry_msgs/Point center + float64 radius + +This custom message uses a message from another message package (``geometry_msgs/Point`` in this case). + +2.2 srv definition +~~~~~~~~~~~~~~~~~~ + +Back in the ``tutorial_interfaces/srv`` directory you just created, make a new file called ``AddThreeInts.srv`` with the following request and response structure: + +.. code-block:: bash + + int64 a + int64 b + int64 c + --- + int64 sum + +This is your custom service that requests three integers named ``a``, ``b``, and ``c``, and responds with an integer called ``sum``. + +3 ``CMakeLists.txt`` +^^^^^^^^^^^^^^^^^^^^ + +To convert the interfaces you defined into language-specific code (like C++ and Python) so that they can be used in those languages, add the following lines to ``CMakeLists.txt``: + +.. code-block:: cmake + + find_package(geometry_msgs REQUIRED) + find_package(rosidl_default_generators REQUIRED) + + rosidl_generate_interfaces(${PROJECT_NAME} + "msg/Num.msg" + "msg/Sphere.msg" + "srv/AddThreeInts.srv" + DEPENDENCIES geometry_msgs # Add packages that above messages depend on, in this case geometry_msgs for Sphere.msg + ) + +.. note:: + + The first argument (library name) in the ``rosidl_generate_interfaces`` must start with the name of the package, e.g., simply ``${PROJECT_NAME}`` or ``${PROJECT_NAME}_suffix``. + See https://github.com/ros2/rosidl/issues/441#issuecomment-591025515. + +4 ``package.xml`` +^^^^^^^^^^^^^^^^^ + +Because the interfaces rely on ``rosidl_default_generators`` for generating language-specific code, you need to declare a build tool dependency on it. +``rosidl_default_runtime`` is a runtime or execution-stage dependency, needed to be able to use the interfaces later. +The ``rosidl_interface_packages`` is the name of the dependency group that your package, ``tutorial_interfaces``, should be associated with, declared using the ```` tag. + +Add the following lines within the ```` element of ``package.xml``: + +.. code-block:: xml + + geometry_msgs + rosidl_default_generators + rosidl_default_runtime + rosidl_interface_packages + +5 Build the ``tutorial_interfaces`` package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now that all the parts of your custom interfaces package are in place, you can build the package. +In the root of your workspace (``~/ros2_ws``), run the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select tutorial_interfaces + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select tutorial_interfaces + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select tutorial_interfaces + +Now the interfaces will be discoverable by other ROS 2 packages. + +6 Confirm msg and srv creation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In a new terminal, run the following command from within your workspace (``ros2_ws``) to source it: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now you can confirm that your interface creation worked by using the ``ros2 interface show`` command. +The output you see in your terminal should look similar to the following: + +.. code-block:: console + + $ ros2 interface show tutorial_interfaces/msg/Num + int64 num + +.. code-block:: console + + $ ros2 interface show tutorial_interfaces/msg/Sphere + geometry_msgs/Point center + float64 x + float64 y + float64 z + float64 radius + +.. code-block:: console + + $ ros2 interface show tutorial_interfaces/srv/AddThreeInts + int64 a + int64 b + int64 c + --- + int64 sum + +7 Test the new interfaces +^^^^^^^^^^^^^^^^^^^^^^^^^ + +For this step you can use the packages you created in previous tutorials. +A few simple modifications to the nodes, ``CMakeLists.txt`` and ``package.xml`` files will allow you to use your new interfaces. + +7.1 Testing ``Num.msg`` with pub/sub +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With a few modifications to the publisher/subscriber package created in a previous tutorial (:doc:`C++ ` or :doc:`Python `), you can see ``Num.msg`` in action. +Since you'll be changing the standard string msg to a numerical one, the output will be slightly different. + +**Publisher** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/msg/num.hpp" // CHANGE + + using namespace std::chrono_literals; + + class MinimalPublisher : public rclcpp::Node + { + public: + MinimalPublisher() + : Node("minimal_publisher"), count_(0) + { + publisher_ = this->create_publisher("topic", 10); // CHANGE + + auto timer_callback = [this](){ + auto message = tutorial_interfaces::msg::Num(); // CHANGE + message.num = this->count_++; // CHANGE + RCLCPP_INFO_STREAM(this->get_logger(), "Publishing: '" << message.num << "'"); // CHANGE + publisher_->publish(message); + }; + timer_ = this->create_wall_timer(500ms, timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; // CHANGE + size_t count_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tutorial_interfaces.msg import Num # CHANGE + + + class MinimalPublisher(Node): + + def __init__(self): + super().__init__('minimal_publisher') + self.publisher_ = self.create_publisher(Num, 'topic', 10) # CHANGE + timer_period = 0.5 # seconds + self.timer = self.create_timer(timer_period, self.timer_callback) + self.i = 0 + + def timer_callback(self): + msg = Num() # CHANGE + msg.num = self.i # CHANGE + self.publisher_.publish(msg) + self.get_logger().info('Publishing: "%d"' % msg.num) # CHANGE + self.i += 1 + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_publisher = MinimalPublisher() + + rclpy.spin(minimal_publisher) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +**Subscriber** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/msg/num.hpp" // CHANGE + + using std::placeholders::_1; + + class MinimalSubscriber : public rclcpp::Node + { + public: + MinimalSubscriber() + : Node("minimal_subscriber") + { + auto topic_callback = [this](const tutorial_interfaces::msg::Num & msg){ // CHANGE + RCLCPP_INFO_STREAM(this->get_logger(), "I heard: '" << msg.num << "'"); // CHANGE + }; + subscription_ = this->create_subscription( // CHANGE + "topic", 10, topic_callback); + } + + private: + rclcpp::Subscription::SharedPtr subscription_; // CHANGE + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tutorial_interfaces.msg import Num # CHANGE + + + class MinimalSubscriber(Node): + + def __init__(self): + super().__init__('minimal_subscriber') + self.subscription = self.create_subscription( + Num, # CHANGE + 'topic', + self.listener_callback, + 10) + self.subscription # prevent unused variable warning + + def listener_callback(self, msg): + self.get_logger().info('I heard: "%d"' % msg.num) # CHANGE + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_subscriber = MinimalSubscriber() + + rclpy.spin(minimal_subscriber) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +**CMakeLists.txt** + +Add the following lines (C++ only): + +.. code-block:: cmake + + #... + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(tutorial_interfaces REQUIRED) # CHANGE + + add_executable(talker src/publisher_lambda_function.cpp) + target_link_libraries(talker PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + add_executable(listener src/subscriber_lambda_function.cpp) + target_link_libraries(listener PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + install(TARGETS + talker + listener + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + + +**package.xml** + +Add the following line: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + tutorial_interfaces + + .. group-tab:: Python + + .. code-block:: python + + tutorial_interfaces + + +After making the above edits and saving all the changes, build the package: + +.. tabs:: + + .. group-tab:: C++ + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select cpp_pubsub + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_pubsub + + .. group-tab:: Python + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select py_pubsub + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select py_pubsub + +Then open two new terminals, source ``ros2_ws`` in each, and run: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: console + + $ ros2 run cpp_pubsub talker + + .. code-block:: console + + $ ros2 run cpp_pubsub listener + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 run py_pubsub talker + + .. code-block:: console + + $ ros2 run py_pubsub listener + +Since ``Num.msg`` relays only an integer, the talker should only be publishing integer values, as opposed to the string it published previously: + +.. code-block:: console + + [INFO] [minimal_publisher]: Publishing: '0' + [INFO] [minimal_publisher]: Publishing: '1' + [INFO] [minimal_publisher]: Publishing: '2' + + +7.2 Testing ``AddThreeInts.srv`` with service/client +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With a few modifications to the service/client package created in a previous tutorial (:doc:`C++ ` or :doc:`Python `), you can see ``AddThreeInts.srv`` in action. +Since you'll be changing the original two integer request srv to a three integer request srv, the output will be slightly different. + +**Service** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE + + #include + + void add(const std::shared_ptr request, // CHANGE + std::shared_ptr response) // CHANGE + { + response->sum = request->a + request->b + request->c; // CHANGE + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Incoming request\na: %ld" " b: %ld" " c: %ld", // CHANGE + request->a, request->b, request->c); // CHANGE + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "sending back response: [%ld]", (long int)response->sum); + } + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_server"); // CHANGE + + rclcpp::Service::SharedPtr service = // CHANGE + node->create_service("add_three_ints", &add); // CHANGE + + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Ready to add three ints."); // CHANGE + + rclcpp::spin(node); + rclcpp::shutdown(); + } + + .. group-tab:: Python + + .. code-block:: python + + from tutorial_interfaces.srv import AddThreeInts # CHANGE + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalService(Node): + + def __init__(self): + super().__init__('minimal_service') + self.srv = self.create_service(AddThreeInts, 'add_three_ints', self.add_three_ints_callback) # CHANGE + + def add_three_ints_callback(self, request, response): + response.sum = request.a + request.b + request.c # CHANGE + self.get_logger().info('Incoming request\na: %d b: %d c: %d' % (request.a, request.b, request.c)) # CHANGE + + return response + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_service = MinimalService() + + rclpy.spin(minimal_service) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +**Client** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE + + #include + #include + #include + + using namespace std::chrono_literals; + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_client"); // CHANGE + rclcpp::Client::SharedPtr client = // CHANGE + node->create_client("add_three_ints"); // CHANGE + + auto request = std::make_shared(); // CHANGE + request->a = 41; + request->b = 1; + request->c = 1; // CHANGE + + while (!client->wait_for_service(1s)) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Interrupted while waiting for the service. Exiting."); + return 0; + } + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "service not available, waiting again..."); + } + + auto result = client->async_send_request(request); + // Wait for the result. + if (rclcpp::spin_until_future_complete(node, result) == + rclcpp::FutureReturnCode::SUCCESS) + { + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Sum: %ld", result.get()->sum); + } else { + RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Failed to call service add_three_ints"); // CHANGE + } + + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + from tutorial_interfaces.srv import AddThreeInts # CHANGE + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalClientAsync(Node): + + def __init__(self): + super().__init__('minimal_client_async') + self.cli = self.create_client(AddThreeInts, 'add_three_ints') # CHANGE + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddThreeInts.Request() # CHANGE + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + self.req.c = 1 # CHANGE + return self.cli.call_async(self.req) + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_client = MinimalClientAsync() + future = minimal_client.send_request() + rclpy.spin_until_future_complete(minimal_client, future) + response = future.result() + minimal_client.get_logger().info( + 'Result of add_three_ints: for %d + %d + %d = %d' % # CHANGE + (minimal_client.req.a, minimal_client.req.b, minimal_client.req.c, response.sum)) # CHANGE + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +**CMakeLists.txt** + +Add the following lines (C++ only): + +.. code-block:: cmake + + #... + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(tutorial_interfaces REQUIRED) # CHANGE + + add_executable(server src/add_two_ints_server.cpp) + target_link_libraries(server PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + add_executable(client src/add_two_ints_client.cpp) + target_link_libraries(client PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + install(TARGETS + server + client + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + + +**package.xml** + +Add the following line: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + tutorial_interfaces + + .. group-tab:: Python + + .. code-block:: python + + tutorial_interfaces + + +After making the above edits and saving all the changes, build the package: + +.. tabs:: + + .. group-tab:: C++ + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select cpp_srvcli + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_srvcli + + + .. group-tab:: Python + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select py_srvcli + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select py_srvcli + +Then open two new terminals, source ``ros2_ws`` in each, and run: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: console + + $ ros2 run cpp_srvcli server + + .. code-block:: console + + $ ros2 run cpp_srvcli client + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 run py_srvcli service + + .. code-block:: console + + $ ros2 run py_srvcli client + + +Summary +------- + +In this tutorial, you learned how to create custom interfaces in their own package and how to utilize those interfaces in other packages. + +This tutorial only scratches the surface about defining custom interfaces. +You can learn more about it in :doc:`About ROS 2 interfaces <../../About-Interfaces>`. + +Next steps +---------- + +The :doc:`next tutorial ` covers more ways to use interfaces in ROS 2. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst index 498548d3538..e8e6ed1ddd9 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst @@ -1,217 +1,218 @@ -.. redirect-from:: - - Tutorials/Getting-Started-With-Ros2doctor - -.. _Ros2Doctor: - -Using ``ros2doctor`` to identify issues -======================================= - -**Goal:** Identify issues in your ROS 2 setup using the ``ros2doctor`` tool. - -**Tutorial level:** Beginner - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When your ROS 2 setup is not running as expected, you can check its settings with the ``ros2doctor`` tool. - -``ros2doctor`` checks all aspects of ROS 2, including platform, version, network, environment, running systems and more, and warns you about possible errors and reasons for issues. - -Prerequisites -------------- - -``ros2doctor`` is part of the ``ros2cli`` package. -As long as you have ``ros2cli`` installed (which any normal install should have), you will be able to use ``ros2doctor``. - -This tutorial uses :doc:`turtlesim <../Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim>` to illustrate some of the examples. - -Tasks ------ - -1 Check your setup -^^^^^^^^^^^^^^^^^^ - -Let's examine your general ROS 2 setup as a whole with ``ros2doctor``. -First, source ROS 2 in a new terminal, then enter the command: - - -.. code-block:: console - - $ ros2 doctor - All checks passed - -This will conduct checks over all your setup modules and return warnings and errors. -If your ROS 2 setup is in perfect shape, you'll see a message similar to the one above. - -However, it's not unusual to have a few warnings returned. -A ``UserWarning`` doesn't mean your setup is unusable; it's more likely just an indication that something is configured in a way that's not ideal. - -If you do receive a warning, it will look something like this: - -.. code-block:: console - - : : UserWarning: - -For example, ``ros2doctor`` will find this warning if you're using an unstable ROS 2 distribution: - -.. code-block:: console - - UserWarning: Distribution is not fully supported or tested. To get more consistent features, download a stable version at https://index.ros.org/doc/ros2/Installation/ - -If ``ros2doctor`` only finds warnings in your system, you will still receive the ``All checks passed`` message. - -Most checks are categorized as warnings as opposed to errors. -It's mostly up to you, the user, to determine the importance of the feedback ``ros2doctor`` returns. -If it does find a rare error in your setup, indicated by ``UserWarning: ERROR:``, the check is considered failed. - -You will see a message similar to the following list of issue feedback: - -.. code-block:: console - - 1/3 checks failed - - Failed modules: network - -An error indicates the system is missing important settings or functions that are crucial to ROS 2. -Errors should be addressed to ensure the system functions properly. - -2 Check a system -^^^^^^^^^^^^^^^^ - -You can also examine a running ROS 2 system to identify possible causes for issues. -To see ``ros2doctor`` working on a running system, let's run turtlesim, which has nodes actively communicating with each other. - -Start up the system by opening a new terminal, sourcing ROS 2, and entering the command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and source ROS 2 to run the teleop controls: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Now run ``ros2doctor`` again in its own terminal. -You will see the warnings and errors you had the last time you ran ``ros2doctor`` on your setup if you had any. -Following those will be a couple new warnings relating to the system itself: - -.. code-block:: console - - $ ros2 doctor - UserWarning: Publisher without subscriber detected on /turtle1/color_sensor. - UserWarning: Publisher without subscriber detected on /turtle1/pose. - -It seems that the ``/turtlesim`` node publishes data to two topics that aren't being subscribed to, and ``ros2doctor`` thinks this could possibly lead to issues. - -If you run commands to echo the ``/color_sensor`` and ``/pose`` topics, those warnings will disappear because the publishers will have subscribers. - -You can try this by opening two new terminals while turtlesim is still running, sourcing ROS 2 in each, and running each of the following commands in their own terminal: - -.. code-block:: console - - $ ros2 topic echo /turtle1/color_sensor - -.. code-block:: console - - $ ros2 topic echo /turtle1/pose - -Then run ``ros2doctor`` in its terminal again. -The ``publisher without subscriber`` warnings will be gone. -(Make sure to enter ``Ctrl+C`` in the terminals where you ran ``echo``). - -Now try exiting either the turtlesim window or quitting the teleop and running ``ros2doctor`` again. -You'll see more warnings indicating ``publisher without subscriber`` or ``subscriber without publisher`` for different topics, now that one node in the system isn't available. - -In a complex system with many nodes, ``ros2doctor`` would be invaluable for identifying possible reasons for communication issues. - -3 Get a full report -^^^^^^^^^^^^^^^^^^^ - -While ``ros2doctor`` will let you know warnings about your network, system, etc., running it with the ``--report`` argument will give you much more detail to help you analyze issues. - -You might want to use ``--report`` if you get a warning about your network setup and want to find out exactly what part of your configuration is causing the warning. - -It's also very helpful when you need to open a support ticket to get help with ROS 2. -You can copy and paste the relevant parts of your report into the ticket so the people helping you can better understand your environment and provide better assistance. - -To get a full report, enter the following command in the terminal: - -.. code-block:: console - - $ ros2 doctor --report - -Which will return a list of information categorized into the following groups: - -.. code-block:: console - - ACTION LIST - ... - - ROS ENVIRONMENT - ... - - NETWORK CONFIGURATION - ... - - PACKAGE VERSIONS - ... - - PLATFORM INFORMATION - ... - - QOS COMPATIBILITY LIST - ... - - RMW MIDDLEWARE - ... - - ROS 2 INFORMATION - ... - - SERVICE LIST - ... - - TOPIC LIST - ... - -You can crosscheck the information here against the warnings you get when running ``ros2 doctor``. -For example, if ``ros2doctor`` returned the warning (mentioned earlier) that your distribution is "not fully supported or tested", you might take a look at the ``ROS 2 INFORMATION`` section of the report: - -.. code-block:: console - - distribution name : - distribution type : ros2 - distribution status : prerelease - release platforms : {'': ['']} - -Here you can see the ``distribution status`` is ``prerelease``, which explains why it's not fully supported. - - -Summary -------- - -``ros2doctor`` will inform you of problems in your ROS 2 setup and running systems. -You can get a deeper look at information behind those warnings by using the ``--report`` argument. - -Keep in mind, ``ros2doctor`` is not a debug tool; it won't help with errors in your code or on the implementation side of your system. - - -Related content ---------------- - -`ros2doctor's README `__ will tell you more about different arguments. -You might want to take a look around the ``ros2doctor`` repo as well, since it's fairly beginner friendly and a great place to get started with contributing. - -Next steps ----------------- - -You've completed the beginner level tutorials! +.. redirect-from:: + + Tutorials/Getting-Started-With-Ros2doctor + Tutorials/Beginner-Client-Libraries/Getting-Started-With-Ros2doctor + +.. _Ros2Doctor: + +Using ``ros2doctor`` to identify issues +======================================= + +**Goal:** Identify issues in your ROS 2 setup using the ``ros2doctor`` tool. + +**Tutorial level:** Beginner + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When your ROS 2 setup is not running as expected, you can check its settings with the ``ros2doctor`` tool. + +``ros2doctor`` checks all aspects of ROS 2, including platform, version, network, environment, running systems and more, and warns you about possible errors and reasons for issues. + +Prerequisites +------------- + +``ros2doctor`` is part of the ``ros2cli`` package. +As long as you have ``ros2cli`` installed (which any normal install should have), you will be able to use ``ros2doctor``. + +This tutorial uses :doc:`turtlesim <../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` to illustrate some of the examples. + +Tasks +----- + +1 Check your setup +^^^^^^^^^^^^^^^^^^ + +Let's examine your general ROS 2 setup as a whole with ``ros2doctor``. +First, source ROS 2 in a new terminal, then enter the command: + + +.. code-block:: console + + $ ros2 doctor + All checks passed + +This will conduct checks over all your setup modules and return warnings and errors. +If your ROS 2 setup is in perfect shape, you'll see a message similar to the one above. + +However, it's not unusual to have a few warnings returned. +A ``UserWarning`` doesn't mean your setup is unusable; it's more likely just an indication that something is configured in a way that's not ideal. + +If you do receive a warning, it will look something like this: + +.. code-block:: console + + : : UserWarning: + +For example, ``ros2doctor`` will find this warning if you're using an unstable ROS 2 distribution: + +.. code-block:: console + + UserWarning: Distribution is not fully supported or tested. To get more consistent features, download a stable version at https://index.ros.org/doc/ros2/Installation/ + +If ``ros2doctor`` only finds warnings in your system, you will still receive the ``All checks passed`` message. + +Most checks are categorized as warnings as opposed to errors. +It's mostly up to you, the user, to determine the importance of the feedback ``ros2doctor`` returns. +If it does find a rare error in your setup, indicated by ``UserWarning: ERROR:``, the check is considered failed. + +You will see a message similar to the following list of issue feedback: + +.. code-block:: console + + 1/3 checks failed + + Failed modules: network + +An error indicates the system is missing important settings or functions that are crucial to ROS 2. +Errors should be addressed to ensure the system functions properly. + +2 Check a system +^^^^^^^^^^^^^^^^ + +You can also examine a running ROS 2 system to identify possible causes for issues. +To see ``ros2doctor`` working on a running system, let's run turtlesim, which has nodes actively communicating with each other. + +Start up the system by opening a new terminal, sourcing ROS 2, and entering the command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and source ROS 2 to run the teleop controls: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Now run ``ros2doctor`` again in its own terminal. +You will see the warnings and errors you had the last time you ran ``ros2doctor`` on your setup if you had any. +Following those will be a couple new warnings relating to the system itself: + +.. code-block:: console + + $ ros2 doctor + UserWarning: Publisher without subscriber detected on /turtle1/color_sensor. + UserWarning: Publisher without subscriber detected on /turtle1/pose. + +It seems that the ``/turtlesim`` node publishes data to two topics that aren't being subscribed to, and ``ros2doctor`` thinks this could possibly lead to issues. + +If you run commands to echo the ``/color_sensor`` and ``/pose`` topics, those warnings will disappear because the publishers will have subscribers. + +You can try this by opening two new terminals while turtlesim is still running, sourcing ROS 2 in each, and running each of the following commands in their own terminal: + +.. code-block:: console + + $ ros2 topic echo /turtle1/color_sensor + +.. code-block:: console + + $ ros2 topic echo /turtle1/pose + +Then run ``ros2doctor`` in its terminal again. +The ``publisher without subscriber`` warnings will be gone. +(Make sure to enter ``Ctrl+C`` in the terminals where you ran ``echo``). + +Now try exiting either the turtlesim window or quitting the teleop and running ``ros2doctor`` again. +You'll see more warnings indicating ``publisher without subscriber`` or ``subscriber without publisher`` for different topics, now that one node in the system isn't available. + +In a complex system with many nodes, ``ros2doctor`` would be invaluable for identifying possible reasons for communication issues. + +3 Get a full report +^^^^^^^^^^^^^^^^^^^ + +While ``ros2doctor`` will let you know warnings about your network, system, etc., running it with the ``--report`` argument will give you much more detail to help you analyze issues. + +You might want to use ``--report`` if you get a warning about your network setup and want to find out exactly what part of your configuration is causing the warning. + +It's also very helpful when you need to open a support ticket to get help with ROS 2. +You can copy and paste the relevant parts of your report into the ticket so the people helping you can better understand your environment and provide better assistance. + +To get a full report, enter the following command in the terminal: + +.. code-block:: console + + $ ros2 doctor --report + +Which will return a list of information categorized into the following groups: + +.. code-block:: console + + ACTION LIST + ... + + ROS ENVIRONMENT + ... + + NETWORK CONFIGURATION + ... + + PACKAGE VERSIONS + ... + + PLATFORM INFORMATION + ... + + QOS COMPATIBILITY LIST + ... + + RMW MIDDLEWARE + ... + + ROS 2 INFORMATION + ... + + SERVICE LIST + ... + + TOPIC LIST + ... + +You can crosscheck the information here against the warnings you get when running ``ros2 doctor``. +For example, if ``ros2doctor`` returned the warning (mentioned earlier) that your distribution is "not fully supported or tested", you might take a look at the ``ROS 2 INFORMATION`` section of the report: + +.. code-block:: console + + distribution name : + distribution type : ros2 + distribution status : prerelease + release platforms : {'': ['']} + +Here you can see the ``distribution status`` is ``prerelease``, which explains why it's not fully supported. + + +Summary +------- + +``ros2doctor`` will inform you of problems in your ROS 2 setup and running systems. +You can get a deeper look at information behind those warnings by using the ``--report`` argument. + +Keep in mind, ``ros2doctor`` is not a debug tool; it won't help with errors in your code or on the implementation side of your system. + + +Related content +--------------- + +`ros2doctor's README `__ will tell you more about different arguments. +You might want to take a look around the ``ros2doctor`` repo as well, since it's fairly beginner friendly and a great place to get started with contributing. + +Next steps +---------------- + +You've completed the beginner level tutorials! \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst index 2d8347643c0..ea1ac557f90 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst @@ -1,370 +1,371 @@ -.. redirect-from:: - - Tutorials/Pluginlib - -Creating and using plugins (C++) -================================ - -**Goal:** Learn to create and load a simple plugin using ``pluginlib``. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 3 - :local: - -Background ----------- - -This tutorial is derived from ``_ and `Writing and Using a Simple Plugin Tutorial `_. - -``pluginlib`` is a C++ library for loading and unloading plugins from within a ROS package. -Plugins are dynamically loadable classes that are loaded from a runtime library (i.e. shared object, dynamically linked library). -With pluginlib, you do not have to explicitly link your application against the library containing the classes -- instead ``pluginlib`` can open a library containing exported classes at any point without the application having any prior awareness of the library or the header file containing the class definition. -Plugins are useful for extending/modifying application behavior without needing the application source code. - -Prerequisites -------------- - -This tutorial assumes basic C++ knowledge and that you have successfully :doc:`installed ROS 2 <../../Installation>`. - -Tasks ------ - -In this tutorial, you will create two new packages, one that defines the base class, and another that provides the plugins. -The base class will define a generic polygon class, and then our plugins will define specific shapes. - -1 Create the Base Class Package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Create a new empty package in your ``~/ros2_ws/src`` folder with the following command: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies pluginlib --node-name area_node polygon_base - - -Open your favorite editor, edit ``~/ros2_ws/src/polygon_base/include/polygon_base/regular_polygon.hpp``, and paste the following inside of it: - -.. code-block:: C++ - - #ifndef POLYGON_BASE_REGULAR_POLYGON_HPP - #define POLYGON_BASE_REGULAR_POLYGON_HPP - - #include - - namespace polygon_base - { - class RegularPolygon - { - public: - virtual double area() = 0; - virtual ~RegularPolygon() = default; - - protected: - RegularPolygon() = default; - }; - } // namespace polygon_base - - // Interface traits specialized for our interface `polygon_base::RegularPolygon` - // to define constructor parameters. - template<> - struct class_loader::InterfaceTraits - { - // The constructor of the plugins will take a `double`. - // You can use constructor with more arguments by listing them inside the - // angle brackets. - // Eg.: class_loader::ConstructorParameters> - using constructor_parameters = class_loader::ConstructorParameters; - }; - - #endif // POLYGON_BASE_REGULAR_POLYGON_HPP - -The code above creates an abstract class called ``RegularPolygon``. -One thing to notice is the presence of the ``class_loader::InterfaceTraits`` struct specialization. -To allow passing arguments to constructor, we need to tell ``pluginlib`` (and the underlying ``class_loader``), what type of arguments will be expected. -This is done by creating the specialization as shown in the example above. -If we do not create this specialization, the plugins must be constructible without any arguments. - -.. note:: Parameters of the base class constructor can be different from what is declared for the plugins using the ``InterfaceTraits``. - -We need to make this header available to other classes by exporting it as an interface library. -To do so, open ``~/ros2_ws/src/polygon_base/CMakeLists.txt`` for editing -and add the following lines after the ``find_package(pluginlib REQUIRED)`` command: - -.. code-block:: cmake - - # Library (this will be used as the base class for plugins) - add_library(${PROJECT_NAME} INTERFACE) - add_library(${PROJECT_NAME}::${PROJECT_NAME} ALIAS ${PROJECT_NAME}) - target_compile_features(${PROJECT_NAME} INTERFACE c_std_17 cxx_std_20) - target_include_directories(${PROJECT_NAME} INTERFACE - $ - $ - ) - target_link_libraries(${PROJECT_NAME} INTERFACE pluginlib::pluginlib) - - # Install headers - install(DIRECTORY include/ - DESTINATION include/${PROJECT_NAME} - ) - - # Install library and export targets - install(TARGETS ${PROJECT_NAME} - EXPORT export_${PROJECT_NAME} - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - install(EXPORT export_${PROJECT_NAME} - NAMESPACE ${PROJECT_NAME}:: - DESTINATION share/${PROJECT_NAME}/cmake - ) - -And add this commands before the ``ament_package`` command: - -.. code-block:: cmake - - # Export old-style CMake variables - ament_export_include_directories( - include - ) - - # Export modern CMake targets - ament_export_targets( - export_${PROJECT_NAME} - ) - -We will return to this package later to write our test node. - -2 Create the Plugin Package -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now we're going to write two non-virtual implementations of our abstract class. -Create a second empty package in your ``~/ros2_ws/src`` folder with the following command: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies polygon_base pluginlib --library-name polygon_plugins polygon_plugins - -2.1 Source code for the plugins -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Open ``~/ros2_ws/src/polygon_plugins/src/polygon_plugins.cpp`` for editing, and paste the following inside of it: - -.. code-block:: C++ - - #include - #include - - namespace polygon_plugins - { - class Square : public polygon_base::RegularPolygon - { - public: - Square(double side_length) - : side_length_(side_length) - { - } - - double area() override - { - return side_length_ * side_length_; - } - - protected: - double side_length_; - }; - - class Triangle : public polygon_base::RegularPolygon - { - public: - Triangle(double side_length) - : side_length_(side_length) - { - } - - double area() override - { - return 0.5 * side_length_ * getHeight(); - } - - double getHeight() - { - return sqrt((side_length_ * side_length_) - ((side_length_ / 2) * (side_length_ / 2))); - } - - protected: - double side_length_; - }; - } - - #include - - PLUGINLIB_EXPORT_CLASS(polygon_plugins::Square, polygon_base::RegularPolygon) - PLUGINLIB_EXPORT_CLASS(polygon_plugins::Triangle, polygon_base::RegularPolygon) - -The implementation of the Square and Triangle classes is fairly straightforward: save the side length, and use it to calculate the area. -The only piece that is pluginlib specific is the last three lines, which invokes some magical macros that register the classes as actual plugins. -Let's go through the arguments to the ``PLUGINLIB_EXPORT_CLASS`` macro: - -1. The fully-qualified type of the plugin class, in this case, ``polygon_plugins::Square``. -2. The fully-qualified type of the base class, in this case, ``polygon_base::RegularPolygon``. - -2.2 Plugin Declaration XML -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The steps above enable plugin instances to be created when the containing library is loaded, but the plugin loader still needs a way to find that library and to know what to reference within that library. -To this end, we'll also create an XML file that, along with a special export line in the package manifest, makes all the necessary information about our plugins available to the ROS toolchain. - -Create ``~/ros2_ws/src/polygon_plugins/plugins.xml`` with the following code: - -.. code-block:: XML - - - - This is a square plugin. - - - This is a triangle plugin. - - - -A couple things to note: - -1. The ``library`` tag gives the relative path to a library that contains the plugins that we want to export. - In ROS 2, that is just the name of the library. - In ROS 1, it contained the prefix ``lib`` or sometimes ``lib/lib`` (i.e. ``lib/libpolygon_plugins``), but here it is simpler. -2. The ``class`` tag declares a plugin that we want to export from our library. - Let's go through its parameters: - - * ``type``: The fully qualified type of the plugin. - For us, that's ``polygon_plugins::Square``. - * ``base_class``: The fully qualified base class type for the plugin. - For us, that's ``polygon_base::RegularPolygon``. - * ``description``: A description of the plugin and what it does. - * ``name`` (optional): A lookup name (i.e. magic name) used by the class loader. - -2.3 CMake Plugin Declaration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The last step is to export your plugins via ``CMakeLists.txt``. -This is a change from ROS 1, where the exporting was done via ``package.xml``. -Add the following line to your ``~/ros2_ws/src/polygon_plugins/CMakeLists.txt`` after the line reading ``find_package(pluginlib REQUIRED)``: - -.. code-block:: cmake - - pluginlib_export_plugin_description_file(polygon_base plugins.xml) - -The arguments to the ``pluginlib_export_plugin_description_file`` command are: - -1. The package with the base class, i.e. ``polygon_base``. -2. The relative path to the Plugin Declaration xml, i.e. ``plugins.xml``. - -3 Use the Plugins -^^^^^^^^^^^^^^^^^ - -Now it's time to use the plugins. -This can be done in any package, but here we're going to do it in the base package. -Edit ``~/ros2_ws/src/polygon_base/src/area_node.cpp`` to contain the following: - -.. code-block:: C++ - - #include - #include - - int main(int argc, char** argv) - { - // To avoid unused parameter warnings - (void) argc; - (void) argv; - - pluginlib::ClassLoader poly_loader("polygon_base", "polygon_base::RegularPolygon"); - - try - { - std::shared_ptr triangle = poly_loader.createSharedInstance("awesome_triangle", 10.0); - - std::shared_ptr square = poly_loader.createSharedInstance("polygon_plugins::Square", 10.0); - - printf("Triangle area: %.2f\n", triangle->area()); - printf("Square area: %.2f\n", square->area()); - } - catch(pluginlib::PluginlibException& ex) - { - printf("The plugin failed to load for some reason. Error: %s\n", ex.what()); - } - - return 0; - } - -The ``ClassLoader`` is the key class to understand, defined in the ``class_loader.hpp`` `header file `_: - - * It is templated with the base class, i.e. ``polygon_base::RegularPolygon``. - * The first argument is a string for the package name of the base class, i.e. ``polygon_base``. - * The second argument is a string with the fully qualified base class type for the plugin, i.e. ``polygon_base::RegularPolygon``. - -There are a number of ways to instantiate an instance of the class. -In this example, we're using shared pointers. -We just need to call ``createSharedInstance`` with a reference to the plugin: This can be either the fully-qualified type of the plugin class (the ``type`` attribute of the declaration XML file, e.g. ``polygon_plugins::Square``), or the optional magic name (the ``name`` attribute of the declaration XML file, e.g., ``awesome_triangle``). -The rest of the parameters in the call must match the types defined in the ``InterfaceTraits`` and are passed to the constructor of the plugin. - -Important note: the ``polygon_base`` package in which this node is defined does NOT depend on the ``polygon_plugins`` class. -The plugins will be loaded dynamically without any dependency needing to be declared. -Furthermore, we're instantiating the classes with hardcoded plugin names, but you can also do so dynamically with parameters, etc. - -4 Build and run -^^^^^^^^^^^^^^^ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new packages: - -.. code-block:: console - - $ colcon build --packages-select polygon_base polygon_plugins - -From ``ros2_ws``, be sure to source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -You can verify that your plugins were successfully registered by listing them: - -.. code-block:: console - - $ ros2 plugin list - polygon_plugins: - Plugin(name='polygon_plugins::Square', type='polygon_plugins::Square', base='polygon_base::RegularPolygon') - Plugin(name='polygon_plugins::Triangle', type='polygon_plugins::Triangle', base='polygon_base::RegularPolygon') - -Now run the node: - -.. code-block:: console - - $ ros2 run polygon_base area_node - Triangle area: 43.30 - Square area: 100.00 - -Summary -------- - -Congratulations! -You've just written and used your first plugins. +.. redirect-from:: + + Tutorials/Pluginlib + Tutorials/Beginner-Client-Libraries/Pluginlib + +Creating and using plugins (C++) +================================ + +**Goal:** Learn to create and load a simple plugin using ``pluginlib``. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 3 + :local: + +Background +---------- + +This tutorial is derived from ``_ and `Writing and Using a Simple Plugin Tutorial `_. + +``pluginlib`` is a C++ library for loading and unloading plugins from within a ROS package. +Plugins are dynamically loadable classes that are loaded from a runtime library (i.e. shared object, dynamically linked library). +With pluginlib, you do not have to explicitly link your application against the library containing the classes -- instead ``pluginlib`` can open a library containing exported classes at any point without the application having any prior awareness of the library or the header file containing the class definition. +Plugins are useful for extending/modifying application behavior without needing the application source code. + +Prerequisites +------------- + +This tutorial assumes basic C++ knowledge and that you have successfully :doc:`installed ROS 2 <../../../Get-Started/Installation>`. + +Tasks +----- + +In this tutorial, you will create two new packages, one that defines the base class, and another that provides the plugins. +The base class will define a generic polygon class, and then our plugins will define specific shapes. + +1 Create the Base Class Package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Create a new empty package in your ``~/ros2_ws/src`` folder with the following command: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies pluginlib --node-name area_node polygon_base + + +Open your favorite editor, edit ``~/ros2_ws/src/polygon_base/include/polygon_base/regular_polygon.hpp``, and paste the following inside of it: + +.. code-block:: C++ + + #ifndef POLYGON_BASE_REGULAR_POLYGON_HPP + #define POLYGON_BASE_REGULAR_POLYGON_HPP + + #include + + namespace polygon_base + { + class RegularPolygon + { + public: + virtual double area() = 0; + virtual ~RegularPolygon() = default; + + protected: + RegularPolygon() = default; + }; + } // namespace polygon_base + + // Interface traits specialized for our interface `polygon_base::RegularPolygon` + // to define constructor parameters. + template<> + struct class_loader::InterfaceTraits + { + // The constructor of the plugins will take a `double`. + // You can use constructor with more arguments by listing them inside the + // angle brackets. + // Eg.: class_loader::ConstructorParameters> + using constructor_parameters = class_loader::ConstructorParameters; + }; + + #endif // POLYGON_BASE_REGULAR_POLYGON_HPP + +The code above creates an abstract class called ``RegularPolygon``. +One thing to notice is the presence of the ``class_loader::InterfaceTraits`` struct specialization. +To allow passing arguments to constructor, we need to tell ``pluginlib`` (and the underlying ``class_loader``), what type of arguments will be expected. +This is done by creating the specialization as shown in the example above. +If we do not create this specialization, the plugins must be constructible without any arguments. + +.. note:: Parameters of the base class constructor can be different from what is declared for the plugins using the ``InterfaceTraits``. + +We need to make this header available to other classes by exporting it as an interface library. +To do so, open ``~/ros2_ws/src/polygon_base/CMakeLists.txt`` for editing +and add the following lines after the ``find_package(pluginlib REQUIRED)`` command: + +.. code-block:: cmake + + # Library (this will be used as the base class for plugins) + add_library(${PROJECT_NAME} INTERFACE) + add_library(${PROJECT_NAME}::${PROJECT_NAME} ALIAS ${PROJECT_NAME}) + target_compile_features(${PROJECT_NAME} INTERFACE c_std_17 cxx_std_20) + target_include_directories(${PROJECT_NAME} INTERFACE + $ + $ + ) + target_link_libraries(${PROJECT_NAME} INTERFACE pluginlib::pluginlib) + + # Install headers + install(DIRECTORY include/ + DESTINATION include/${PROJECT_NAME} + ) + + # Install library and export targets + install(TARGETS ${PROJECT_NAME} + EXPORT export_${PROJECT_NAME} + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + install(EXPORT export_${PROJECT_NAME} + NAMESPACE ${PROJECT_NAME}:: + DESTINATION share/${PROJECT_NAME}/cmake + ) + +And add this commands before the ``ament_package`` command: + +.. code-block:: cmake + + # Export old-style CMake variables + ament_export_include_directories( + include + ) + + # Export modern CMake targets + ament_export_targets( + export_${PROJECT_NAME} + ) + +We will return to this package later to write our test node. + +2 Create the Plugin Package +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now we're going to write two non-virtual implementations of our abstract class. +Create a second empty package in your ``~/ros2_ws/src`` folder with the following command: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies polygon_base pluginlib --library-name polygon_plugins polygon_plugins + +2.1 Source code for the plugins +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Open ``~/ros2_ws/src/polygon_plugins/src/polygon_plugins.cpp`` for editing, and paste the following inside of it: + +.. code-block:: C++ + + #include + #include + + namespace polygon_plugins + { + class Square : public polygon_base::RegularPolygon + { + public: + Square(double side_length) + : side_length_(side_length) + { + } + + double area() override + { + return side_length_ * side_length_; + } + + protected: + double side_length_; + }; + + class Triangle : public polygon_base::RegularPolygon + { + public: + Triangle(double side_length) + : side_length_(side_length) + { + } + + double area() override + { + return 0.5 * side_length_ * getHeight(); + } + + double getHeight() + { + return sqrt((side_length_ * side_length_) - ((side_length_ / 2) * (side_length_ / 2))); + } + + protected: + double side_length_; + }; + } + + #include + + PLUGINLIB_EXPORT_CLASS(polygon_plugins::Square, polygon_base::RegularPolygon) + PLUGINLIB_EXPORT_CLASS(polygon_plugins::Triangle, polygon_base::RegularPolygon) + +The implementation of the Square and Triangle classes is fairly straightforward: save the side length, and use it to calculate the area. +The only piece that is pluginlib specific is the last three lines, which invokes some magical macros that register the classes as actual plugins. +Let's go through the arguments to the ``PLUGINLIB_EXPORT_CLASS`` macro: + +1. The fully-qualified type of the plugin class, in this case, ``polygon_plugins::Square``. +2. The fully-qualified type of the base class, in this case, ``polygon_base::RegularPolygon``. + +2.2 Plugin Declaration XML +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The steps above enable plugin instances to be created when the containing library is loaded, but the plugin loader still needs a way to find that library and to know what to reference within that library. +To this end, we'll also create an XML file that, along with a special export line in the package manifest, makes all the necessary information about our plugins available to the ROS toolchain. + +Create ``~/ros2_ws/src/polygon_plugins/plugins.xml`` with the following code: + +.. code-block:: XML + + + + This is a square plugin. + + + This is a triangle plugin. + + + +A couple things to note: + +1. The ``library`` tag gives the relative path to a library that contains the plugins that we want to export. + In ROS 2, that is just the name of the library. + In ROS 1, it contained the prefix ``lib`` or sometimes ``lib/lib`` (i.e. ``lib/libpolygon_plugins``), but here it is simpler. +2. The ``class`` tag declares a plugin that we want to export from our library. + Let's go through its parameters: + + * ``type``: The fully qualified type of the plugin. + For us, that's ``polygon_plugins::Square``. + * ``base_class``: The fully qualified base class type for the plugin. + For us, that's ``polygon_base::RegularPolygon``. + * ``description``: A description of the plugin and what it does. + * ``name`` (optional): A lookup name (i.e. magic name) used by the class loader. + +2.3 CMake Plugin Declaration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The last step is to export your plugins via ``CMakeLists.txt``. +This is a change from ROS 1, where the exporting was done via ``package.xml``. +Add the following line to your ``~/ros2_ws/src/polygon_plugins/CMakeLists.txt`` after the line reading ``find_package(pluginlib REQUIRED)``: + +.. code-block:: cmake + + pluginlib_export_plugin_description_file(polygon_base plugins.xml) + +The arguments to the ``pluginlib_export_plugin_description_file`` command are: + +1. The package with the base class, i.e. ``polygon_base``. +2. The relative path to the Plugin Declaration xml, i.e. ``plugins.xml``. + +3 Use the Plugins +^^^^^^^^^^^^^^^^^ + +Now it's time to use the plugins. +This can be done in any package, but here we're going to do it in the base package. +Edit ``~/ros2_ws/src/polygon_base/src/area_node.cpp`` to contain the following: + +.. code-block:: C++ + + #include + #include + + int main(int argc, char** argv) + { + // To avoid unused parameter warnings + (void) argc; + (void) argv; + + pluginlib::ClassLoader poly_loader("polygon_base", "polygon_base::RegularPolygon"); + + try + { + std::shared_ptr triangle = poly_loader.createSharedInstance("awesome_triangle", 10.0); + + std::shared_ptr square = poly_loader.createSharedInstance("polygon_plugins::Square", 10.0); + + printf("Triangle area: %.2f\n", triangle->area()); + printf("Square area: %.2f\n", square->area()); + } + catch(pluginlib::PluginlibException& ex) + { + printf("The plugin failed to load for some reason. Error: %s\n", ex.what()); + } + + return 0; + } + +The ``ClassLoader`` is the key class to understand, defined in the ``class_loader.hpp`` `header file `_: + + * It is templated with the base class, i.e. ``polygon_base::RegularPolygon``. + * The first argument is a string for the package name of the base class, i.e. ``polygon_base``. + * The second argument is a string with the fully qualified base class type for the plugin, i.e. ``polygon_base::RegularPolygon``. + +There are a number of ways to instantiate an instance of the class. +In this example, we're using shared pointers. +We just need to call ``createSharedInstance`` with a reference to the plugin: This can be either the fully-qualified type of the plugin class (the ``type`` attribute of the declaration XML file, e.g. ``polygon_plugins::Square``), or the optional magic name (the ``name`` attribute of the declaration XML file, e.g., ``awesome_triangle``). +The rest of the parameters in the call must match the types defined in the ``InterfaceTraits`` and are passed to the constructor of the plugin. + +Important note: the ``polygon_base`` package in which this node is defined does NOT depend on the ``polygon_plugins`` class. +The plugins will be loaded dynamically without any dependency needing to be declared. +Furthermore, we're instantiating the classes with hardcoded plugin names, but you can also do so dynamically with parameters, etc. + +4 Build and run +^^^^^^^^^^^^^^^ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new packages: + +.. code-block:: console + + $ colcon build --packages-select polygon_base polygon_plugins + +From ``ros2_ws``, be sure to source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +You can verify that your plugins were successfully registered by listing them: + +.. code-block:: console + + $ ros2 plugin list + polygon_plugins: + Plugin(name='polygon_plugins::Square', type='polygon_plugins::Square', base='polygon_base::RegularPolygon') + Plugin(name='polygon_plugins::Triangle', type='polygon_plugins::Triangle', base='polygon_base::RegularPolygon') + +Now run the node: + +.. code-block:: console + + $ ros2 run polygon_base area_node + Triangle area: 43.30 + Square area: 100.00 + +Summary +------- + +Congratulations! +You've just written and used your first plugins. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst index d93287403c6..c5c475c5c37 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst @@ -1,323 +1,327 @@ -Reading from a bag file (C++) -============================= - -**Goal:** Read data from a bag file to your own C++ node. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. -It also provides a C++ API for reading from and writing to a bag from your own source code. -This allows you to read the contents from a bag without having to play the bag, which can sometimes be useful. - -Prerequisites -------------- - -You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. - -If you need to install ROS 2, see the :doc:`Installation instructions <../../Installation>`. - -You should have already completed the :doc:`basic ROS 2 bag tutorial <../Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`, and we will be using the ``subset`` bag you created there. - -Tasks ------ - -1 Create a Package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -In a new or existing :ref:`workspace `, navigate to the ``src`` directory and create -a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 bag_reading_cpp --dependencies rclcpp rosbag2_transport turtlesim_msgs - -Your terminal will return a message verifying the creation of your package ``bag_reading_cpp`` and all its necessary files and folders. -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. -In this case, the package will use the ``rosbag2_transport`` package as well as the ``rclcpp`` package. -A dependency on the ``turtlesim_msgs`` package is also required for working with the custom turtlesim messages. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - C++ bag reading tutorial - Your Name - Apache-2.0 - -2 Write the C++ Reader -^^^^^^^^^^^^^^^^^^^^^^ - -Inside your package's ``src`` directory, create a new file called ``simple_bag_reader.cpp`` and paste the following code into it. - -.. code-block:: C++ - - #include - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp/serialization.hpp" - #include "rosbag2_transport/reader_writer_factory.hpp" - #include "turtlesim_msgs/msg/pose.hpp" - - using namespace std::chrono_literals; - - class PlaybackNode : public rclcpp::Node - { - public: - PlaybackNode(const std::string & bag_filename) - : Node("playback_node") - { - publisher_ = this->create_publisher("/turtle1/pose", 10); - - timer_ = this->create_wall_timer(100ms, - [this](){return this->timer_callback();} - ); - - rosbag2_storage::StorageOptions storage_options; - storage_options.uri = bag_filename; - reader_ = rosbag2_transport::ReaderWriterFactory::make_reader(storage_options); - reader_->open(storage_options); - } - - private: - void timer_callback() - { - while (reader_->has_next()) { - rosbag2_storage::SerializedBagMessageSharedPtr msg = reader_->read_next(); - - if (msg->topic_name != "/turtle1/pose") { - continue; - } - - rclcpp::SerializedMessage serialized_msg(*msg->serialized_data); - turtlesim_msgs::msg::Pose::SharedPtr ros_msg = std::make_shared(); - - serialization_.deserialize_message(&serialized_msg, ros_msg.get()); - - publisher_->publish(*ros_msg); - std::cout << '(' << ros_msg->x << ", " << ros_msg->y << ")\n"; - - break; - } - } - - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; - - rclcpp::Serialization serialization_; - std::unique_ptr reader_; - }; - - int main(int argc, char ** argv) - { - if (argc != 2) { - std::cerr << "Usage: " << argv[0] << " " << std::endl; - return 1; - } - - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared(argv[1])); - rclcpp::shutdown(); - - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The ``#include`` statements at the top are the package dependencies. -Note the inclusion of headers from the ``rosbag2_transport`` package for the functions and structures necessary to work with bag files. - -The next line creates the node which will read from the bag file and play back the data. - -.. code-block:: C++ - - class PlaybackNode : public rclcpp::Node - -Now, we can create a timer callback which will run at 10 hz. -Our goal is to replay one message to the ``/turtle1/pose`` topic each time the callback is run. -Note the constructor takes a path to the bag file as a parameter. - -.. code-block:: C++ - - public: - PlaybackNode(const std::string & bag_filename) - : Node("playback_node") - { - publisher_ = this->create_publisher("/turtle1/pose", 10); - - timer_ = this->create_wall_timer(100ms, - [this](){return this->timer_callback();} - ); - -We also open the bag in the constructor. -The ``rosbag2_transport::ReaderWriterFactory`` is a class that can construct a compressed or uncompressed reader or writer based on the storage options. - -.. code-block:: C++ - - rosbag2_storage::StorageOptions storage_options; - storage_options.uri = bag_filename; - reader_ = rosbag2_transport::ReaderWriterFactory::make_reader(storage_options); - reader_->open(storage_options); - -Now, inside our timer callback, we loop through messages in the bag until we read a message recorded from our desired topic. -Note that the serialized message has timestamp metadata in addition to the topic name. - -.. code-block:: C++ - - void timer_callback() - { - while (reader_->has_next()) { - rosbag2_storage::SerializedBagMessageSharedPtr msg = reader_->read_next(); - - if (msg->topic_name != "/turtle1/pose") { - continue; - } - -We then construct an ``rclcpp::SerializedMessage`` object from the serialized data we just read. -Additionally, we need to create a ROS 2 deserialized message which will hold the result of our deserialization. -Then, we can pass both these objects to the ``rclcpp::Serialization::deserialize_message`` method. - -.. code-block:: C++ - - rclcpp::SerializedMessage serialized_msg(*msg->serialized_data); - turtlesim_msgs::msg::Pose::SharedPtr ros_msg = std::make_shared(); - - serialization_.deserialize_message(&serialized_msg, ros_msg.get()); - -Finally, we publish the deserialized message and print out the xy coordinate to the terminal. -We also break out of the loop so that we publish the next message during the next timer callback. - -.. code-block:: C++ - - publisher_->publish(*ros_msg); - std::cout << '(' << ros_msg->x << ", " << ros_msg->y << ")\n"; - - break; - } - -We must also declare the private variables used throughout the node. - -.. code-block:: C++ - - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; - - rclcpp::Serialization serialization_; - std::unique_ptr reader_; - }; - -Lastly, we create the main function which will check that the user passes an argument for the bag file path and spins our node. - -.. code-block:: C++ - - int main(int argc, char ** argv) - { - if (argc != 2) { - std::cerr << "Usage: " << argv[0] << " " << std::endl; - return 1; - } - - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared(argv[1])); - rclcpp::shutdown(); - - return 0; - } - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. - -Below the dependencies block, which contains ``find_package(rosbag2_transport REQUIRED)``, add the following lines of code. - -.. code-block:: console - - add_executable(simple_bag_reader src/simple_bag_reader.cpp) - target_link_libraries(simple_bag_reader PUBLIC rclcpp::rclcpp rosbag2_transport::rosbag2_transport turtlesim_msgs::turtlesim_msgs) - - install(TARGETS - simple_bag_reader - DESTINATION lib/${PROJECT_NAME} - ) - -3 Build and run -^^^^^^^^^^^^^^^ - -Navigate back to the root of your workspace and build your new package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_reading_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_reading_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_reading_cpp - -Next, source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now, run the script. -Make sure to replace ``/path/to/subset`` with the path to your ``subset`` bag. - -.. code-block:: console - - $ ros2 run bag_reading_cpp simple_bag_reader /path/to/subset - -You should see the (x, y) coordinates of the turtle printed to the console. - -Summary -------- - -You created a C++ executable that reads data from a bag. -You then compiled and ran the executable which printed some information from the bag to the console. +.. redirect-from:: + + Tutorials/Advanced/Reading-From-A-Bag-File-CPP + +Reading from a bag file (C++) +============================= + +**Goal:** Read data from a bag file to your own C++ node. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. +It also provides a C++ API for reading from and writing to a bag from your own source code. +This allows you to read the contents from a bag without having to play the bag, which can sometimes be useful. + +Prerequisites +------------- + +You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. + +If you need to install ROS 2, see the :doc:`Installation instructions <../../../Get-Started/Installation>`. + +You should have already completed the :doc:`basic ROS 2 bag tutorial <../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`, and we will be using the ``subset`` bag you created there. + +Tasks +----- + +1 Create a Package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +In a new or existing :ref:`workspace `, navigate to the ``src`` directory and create +a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 bag_reading_cpp --dependencies rclcpp rosbag2_transport turtlesim_msgs + +Your terminal will return a message verifying the creation of your package ``bag_reading_cpp`` and all its necessary files and folders. +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. +In this case, the package will use the ``rosbag2_transport`` package as well as the ``rclcpp`` package. +A dependency on the ``turtlesim_msgs`` package is also required for working with the custom turtlesim messages. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + C++ bag reading tutorial + Your Name + Apache-2.0 + +2 Write the C++ Reader +^^^^^^^^^^^^^^^^^^^^^^ + +Inside your package's ``src`` directory, create a new file called ``simple_bag_reader.cpp`` and paste the following code into it. + +.. code-block:: C++ + + #include + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp/serialization.hpp" + #include "rosbag2_transport/reader_writer_factory.hpp" + #include "turtlesim_msgs/msg/pose.hpp" + + using namespace std::chrono_literals; + + class PlaybackNode : public rclcpp::Node + { + public: + PlaybackNode(const std::string & bag_filename) + : Node("playback_node") + { + publisher_ = this->create_publisher("/turtle1/pose", 10); + + timer_ = this->create_wall_timer(100ms, + [this](){return this->timer_callback();} + ); + + rosbag2_storage::StorageOptions storage_options; + storage_options.uri = bag_filename; + reader_ = rosbag2_transport::ReaderWriterFactory::make_reader(storage_options); + reader_->open(storage_options); + } + + private: + void timer_callback() + { + while (reader_->has_next()) { + rosbag2_storage::SerializedBagMessageSharedPtr msg = reader_->read_next(); + + if (msg->topic_name != "/turtle1/pose") { + continue; + } + + rclcpp::SerializedMessage serialized_msg(*msg->serialized_data); + turtlesim_msgs::msg::Pose::SharedPtr ros_msg = std::make_shared(); + + serialization_.deserialize_message(&serialized_msg, ros_msg.get()); + + publisher_->publish(*ros_msg); + std::cout << '(' << ros_msg->x << ", " << ros_msg->y << ")\n"; + + break; + } + } + + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; + + rclcpp::Serialization serialization_; + std::unique_ptr reader_; + }; + + int main(int argc, char ** argv) + { + if (argc != 2) { + std::cerr << "Usage: " << argv[0] << " " << std::endl; + return 1; + } + + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared(argv[1])); + rclcpp::shutdown(); + + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The ``#include`` statements at the top are the package dependencies. +Note the inclusion of headers from the ``rosbag2_transport`` package for the functions and structures necessary to work with bag files. + +The next line creates the node which will read from the bag file and play back the data. + +.. code-block:: C++ + + class PlaybackNode : public rclcpp::Node + +Now, we can create a timer callback which will run at 10 hz. +Our goal is to replay one message to the ``/turtle1/pose`` topic each time the callback is run. +Note the constructor takes a path to the bag file as a parameter. + +.. code-block:: C++ + + public: + PlaybackNode(const std::string & bag_filename) + : Node("playback_node") + { + publisher_ = this->create_publisher("/turtle1/pose", 10); + + timer_ = this->create_wall_timer(100ms, + [this](){return this->timer_callback();} + ); + +We also open the bag in the constructor. +The ``rosbag2_transport::ReaderWriterFactory`` is a class that can construct a compressed or uncompressed reader or writer based on the storage options. + +.. code-block:: C++ + + rosbag2_storage::StorageOptions storage_options; + storage_options.uri = bag_filename; + reader_ = rosbag2_transport::ReaderWriterFactory::make_reader(storage_options); + reader_->open(storage_options); + +Now, inside our timer callback, we loop through messages in the bag until we read a message recorded from our desired topic. +Note that the serialized message has timestamp metadata in addition to the topic name. + +.. code-block:: C++ + + void timer_callback() + { + while (reader_->has_next()) { + rosbag2_storage::SerializedBagMessageSharedPtr msg = reader_->read_next(); + + if (msg->topic_name != "/turtle1/pose") { + continue; + } + +We then construct an ``rclcpp::SerializedMessage`` object from the serialized data we just read. +Additionally, we need to create a ROS 2 deserialized message which will hold the result of our deserialization. +Then, we can pass both these objects to the ``rclcpp::Serialization::deserialize_message`` method. + +.. code-block:: C++ + + rclcpp::SerializedMessage serialized_msg(*msg->serialized_data); + turtlesim_msgs::msg::Pose::SharedPtr ros_msg = std::make_shared(); + + serialization_.deserialize_message(&serialized_msg, ros_msg.get()); + +Finally, we publish the deserialized message and print out the xy coordinate to the terminal. +We also break out of the loop so that we publish the next message during the next timer callback. + +.. code-block:: C++ + + publisher_->publish(*ros_msg); + std::cout << '(' << ros_msg->x << ", " << ros_msg->y << ")\n"; + + break; + } + +We must also declare the private variables used throughout the node. + +.. code-block:: C++ + + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; + + rclcpp::Serialization serialization_; + std::unique_ptr reader_; + }; + +Lastly, we create the main function which will check that the user passes an argument for the bag file path and spins our node. + +.. code-block:: C++ + + int main(int argc, char ** argv) + { + if (argc != 2) { + std::cerr << "Usage: " << argv[0] << " " << std::endl; + return 1; + } + + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared(argv[1])); + rclcpp::shutdown(); + + return 0; + } + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. + +Below the dependencies block, which contains ``find_package(rosbag2_transport REQUIRED)``, add the following lines of code. + +.. code-block:: console + + add_executable(simple_bag_reader src/simple_bag_reader.cpp) + target_link_libraries(simple_bag_reader PUBLIC rclcpp::rclcpp rosbag2_transport::rosbag2_transport turtlesim_msgs::turtlesim_msgs) + + install(TARGETS + simple_bag_reader + DESTINATION lib/${PROJECT_NAME} + ) + +3 Build and run +^^^^^^^^^^^^^^^ + +Navigate back to the root of your workspace and build your new package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_reading_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_reading_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_reading_cpp + +Next, source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now, run the script. +Make sure to replace ``/path/to/subset`` with the path to your ``subset`` bag. + +.. code-block:: console + + $ ros2 run bag_reading_cpp simple_bag_reader /path/to/subset + +You should see the (x, y) coordinates of the turtle printed to the console. + +Summary +------- + +You created a C++ executable that reads data from a bag. +You then compiled and ran the executable which printed some information from the bag to the console. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst index a0a9ecc4e45..e236774c6fa 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst @@ -1,260 +1,264 @@ -Reading from a bag file (Python) -================================ - -**Goal:** Read data from a bag file to your own Python node. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. -It also provides a Python API for reading from and writing to a bag from your own source code. -This allows you to read the contents from a bag without having to play the bag, which can sometimes be useful. - -Prerequisites -------------- - -You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. - -If you need to install ROS 2, see the :doc:`Installation instructions <../../Installation>`. - -You should have already completed the :doc:`basic ROS 2 bag tutorial <../Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`, and we will be using the ``subset`` bag you created there. - -Tasks ------ - -1 Create a Package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -In a new or existing :ref:`workspace `, navigate to the ``src`` directory and create -a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 bag_reader_node_py --dependencies rclpy rosbag2_py std_msgs - -Your terminal will return a message verifying the creation of your package ``bag_reader_node_py`` and all its necessary files and folders. -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. -In this case, the package will use the ``rosbag2_py`` package as well as the ``rclpy`` package. -A dependency on the ``std_msgs`` package is also required for message definitions. - -1.1 Update ``package.xml`` and ``setup.py`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - Python bag reading tutorial - Your Name - Apache-2.0 - -Also be sure to add this information to the ``setup.py`` file as well. - -.. code-block:: Python - - maintainer='Your Name', - maintainer_email='you@email.com', - description='Python bag reading tutorial', - license='Apache-2.0', - -2 Write the Python Reader -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/bag_reader_node_py/bag_reader_node_py`` directory, create a new file called ``simple_bag_reader.py`` and paste the following code into it. - -.. code-block:: Python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - import rosbag2_py - from std_msgs.msg import String - - - class SimpleBagReader(Node): - - def __init__(self): - super().__init__('simple_bag_reader') - self.reader = rosbag2_py.SequentialReader() - storage_options = rosbag2_py.StorageOptions( - uri='my_bag', - storage_id='mcap') - converter_options = rosbag2_py.ConverterOptions('', '') - self.reader.open(storage_options, converter_options) - - self.publisher = self.create_publisher(String, 'chatter', 10) - self.timer = self.create_timer(0.1, self.timer_callback) - - def timer_callback(self): - while self.reader.has_next(): - msg = self.reader.read_next() - if msg[0] != 'chatter': - continue - self.publisher.publish(msg[1]) - self.get_logger().info('Publish serialized data to ' + msg[0]) - break - - - def main(args=None): - try: - with rclpy.init(args=args): - sbr = SimpleBagReader() - rclpy.spin(sbr) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The ``import`` statements at the top are the package dependencies. -Note the importation of the ``rosbag2_py`` package for the functions and structures necessary to work with bag files. - -In the class constructor, we begin by creating the bag reader object that we will use to read from the bag. -We are creating a ``SequentialReader``, which reads messages from the bag in the order they are stored. -Other readers with different behaviors may be available in `rosbag2_py reader `__. - -.. code-block:: Python - - self.reader = rosbag2_py.SequentialReader() - -Now that we have a bag reader object, we can open the bag using it. -We specify the URI of the bag and the format (``mcap``), leaving other options at their defaults. -The default conversion options are used, which will perform no conversion and store the messages in the serialization format they are received in. - -.. code-block:: Python - - storage_options = rosbag2_py.StorageOptions( - uri='my_bag', - storage_id='mcap') - converter_options = rosbag2_py.ConverterOptions('', '') - self.reader.open(storage_options, converter_options) - -Next, we create a publisher and a timer to publish the data that reader object reads from the bag file. - -.. code-block:: Python - - self.publisher = self.create_publisher(String, 'chatter', 10) - self.timer = self.create_timer(0.1, self.timer_callback) - -The timer callback publishes all messages from the bag file only to the ``chatter`` topic as long as it can read out the data. - -.. code-block:: Python - - def timer_callback(self): - while self.reader.has_next(): - msg = self.reader.read_next() - if msg[0] != 'chatter': - continue - self.publisher.publish(msg[1]) - self.get_logger().info('Publish serialized data to ' + msg[0]) - -Finally, it finishes with the ``main`` function used to create an instance of the node and start ROS processing it. - -.. code-block:: Python - - def main(args=None): - try: - with rclpy.init(args=args): - sbr = SimpleBagReader() - rclpy.spin(sbr) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file in the ``bag_reader_node_py`` package and add an entry point for your node. - -.. code-block:: Python - - entry_points={ - 'console_scripts': [ - 'simple_bag_reader = bag_reader_node_py.simple_bag_reader:main', - ], - }, - -3 Build and run -^^^^^^^^^^^^^^^ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_reader_node_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_reader_node_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_reader_node_py - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node: - -.. code-block:: console - - $ ros2 run bag_reader_node_py simple_bag_reader - -This will start publishing data on the ``chatter`` topic from the ``my_bag`` bag file. -If the ``my_bag`` directory does not exists, ``simple_bag_reader`` will return failure since it can not open the bag file. - -Open a second terminal and run the ``listener`` example node. - -.. code-block:: console - - $ ros2 run demo_nodes_py listener - -This will start receiving data on the ``chatter`` topic, published by ``simple_bag_reader`` from the bag file. - -Summary -------- - -You created a Python node that reads data from a bag. -You tested reading a bag using the node, and publishing the data by playing back the bag. -This approach can be used to read and publish the data with additional data from the bag file, for example modifying the original data stored in the bag file. +.. redirect-from:: + + Tutorials/Advanced/Reading-From-A-Bag-File-Python + +Reading from a bag file (Python) +================================ + +**Goal:** Read data from a bag file to your own Python node. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. +It also provides a Python API for reading from and writing to a bag from your own source code. +This allows you to read the contents from a bag without having to play the bag, which can sometimes be useful. + +Prerequisites +------------- + +You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. + +If you need to install ROS 2, see the :doc:`Installation instructions <../../../Get-Started/Installation>`. + +You should have already completed the :doc:`basic ROS 2 bag tutorial <../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`, and we will be using the ``subset`` bag you created there. + +Tasks +----- + +1 Create a Package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +In a new or existing :ref:`workspace `, navigate to the ``src`` directory and create +a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 bag_reader_node_py --dependencies rclpy rosbag2_py std_msgs + +Your terminal will return a message verifying the creation of your package ``bag_reader_node_py`` and all its necessary files and folders. +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. +In this case, the package will use the ``rosbag2_py`` package as well as the ``rclpy`` package. +A dependency on the ``std_msgs`` package is also required for message definitions. + +1.1 Update ``package.xml`` and ``setup.py`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + Python bag reading tutorial + Your Name + Apache-2.0 + +Also be sure to add this information to the ``setup.py`` file as well. + +.. code-block:: Python + + maintainer='Your Name', + maintainer_email='you@email.com', + description='Python bag reading tutorial', + license='Apache-2.0', + +2 Write the Python Reader +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/bag_reader_node_py/bag_reader_node_py`` directory, create a new file called ``simple_bag_reader.py`` and paste the following code into it. + +.. code-block:: Python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + import rosbag2_py + from std_msgs.msg import String + + + class SimpleBagReader(Node): + + def __init__(self): + super().__init__('simple_bag_reader') + self.reader = rosbag2_py.SequentialReader() + storage_options = rosbag2_py.StorageOptions( + uri='my_bag', + storage_id='mcap') + converter_options = rosbag2_py.ConverterOptions('', '') + self.reader.open(storage_options, converter_options) + + self.publisher = self.create_publisher(String, 'chatter', 10) + self.timer = self.create_timer(0.1, self.timer_callback) + + def timer_callback(self): + while self.reader.has_next(): + msg = self.reader.read_next() + if msg[0] != 'chatter': + continue + self.publisher.publish(msg[1]) + self.get_logger().info('Publish serialized data to ' + msg[0]) + break + + + def main(args=None): + try: + with rclpy.init(args=args): + sbr = SimpleBagReader() + rclpy.spin(sbr) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The ``import`` statements at the top are the package dependencies. +Note the importation of the ``rosbag2_py`` package for the functions and structures necessary to work with bag files. + +In the class constructor, we begin by creating the bag reader object that we will use to read from the bag. +We are creating a ``SequentialReader``, which reads messages from the bag in the order they are stored. +Other readers with different behaviors may be available in `rosbag2_py reader `__. + +.. code-block:: Python + + self.reader = rosbag2_py.SequentialReader() + +Now that we have a bag reader object, we can open the bag using it. +We specify the URI of the bag and the format (``mcap``), leaving other options at their defaults. +The default conversion options are used, which will perform no conversion and store the messages in the serialization format they are received in. + +.. code-block:: Python + + storage_options = rosbag2_py.StorageOptions( + uri='my_bag', + storage_id='mcap') + converter_options = rosbag2_py.ConverterOptions('', '') + self.reader.open(storage_options, converter_options) + +Next, we create a publisher and a timer to publish the data that reader object reads from the bag file. + +.. code-block:: Python + + self.publisher = self.create_publisher(String, 'chatter', 10) + self.timer = self.create_timer(0.1, self.timer_callback) + +The timer callback publishes all messages from the bag file only to the ``chatter`` topic as long as it can read out the data. + +.. code-block:: Python + + def timer_callback(self): + while self.reader.has_next(): + msg = self.reader.read_next() + if msg[0] != 'chatter': + continue + self.publisher.publish(msg[1]) + self.get_logger().info('Publish serialized data to ' + msg[0]) + +Finally, it finishes with the ``main`` function used to create an instance of the node and start ROS processing it. + +.. code-block:: Python + + def main(args=None): + try: + with rclpy.init(args=args): + sbr = SimpleBagReader() + rclpy.spin(sbr) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file in the ``bag_reader_node_py`` package and add an entry point for your node. + +.. code-block:: Python + + entry_points={ + 'console_scripts': [ + 'simple_bag_reader = bag_reader_node_py.simple_bag_reader:main', + ], + }, + +3 Build and run +^^^^^^^^^^^^^^^ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_reader_node_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_reader_node_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_reader_node_py + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node: + +.. code-block:: console + + $ ros2 run bag_reader_node_py simple_bag_reader + +This will start publishing data on the ``chatter`` topic from the ``my_bag`` bag file. +If the ``my_bag`` directory does not exists, ``simple_bag_reader`` will return failure since it can not open the bag file. + +Open a second terminal and run the ``listener`` example node. + +.. code-block:: console + + $ ros2 run demo_nodes_py listener + +This will start receiving data on the ``chatter`` topic, published by ``simple_bag_reader`` from the bag file. + +Summary +------- + +You created a Python node that reads data from a bag. +You tested reading a bag using the node, and publishing the data by playing back the bag. +This approach can be used to read and publish the data with additional data from the bag file, for example modifying the original data stored in the bag file. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst index 9cdef01db3b..11dd5eb053e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst @@ -1,680 +1,681 @@ -.. redirect-from:: - - Tutorials/Ros2bag/Recording-A-Bag-From-Your-Own-Node-Cpp - -.. _ROS2BagOwnNode: - -Recording a bag from a node (C++) -================================= - -**Goal:** Record data from your own C++ node to a bag. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. -It also provides a C++ API for reading from and writing to a bag from your own source code. -This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choice on that data. - -Prerequisites -------------- - -You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. - -If you've installed from deb packages on Linux, it may be installed by default. -If it is not, you can install it using this command. - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-rosbag2 - -This tutorial discusses using ROS 2 bags, including from the terminal. -You should have already completed the :doc:`basic ROS 2 bag tutorial <../Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. -Navigate into the ``ros2_ws/src`` directory and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 bag_recorder_nodes --dependencies example_interfaces rclcpp rosbag2_cpp std_msgs - -Your terminal will return a message verifying the creation of your package ``bag_recorder_nodes`` and all its necessary files and folders. -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. -In this case, the package will use the ``rosbag2_cpp`` package as well as the ``rclcpp`` package. -A dependency on the ``example_interfaces`` package is also required for later parts of this tutorial. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - C++ bag writing tutorial - Your Name - Apache-2.0 - -2 Write the C++ node -^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/bag_recorder_nodes/src`` directory, create a new file called ``simple_bag_recorder.cpp`` and paste the following code into it. - -.. code-block:: C++ - - - #include - #include - - #include - - class SimpleBagRecorder : public rclcpp::Node - { - public: - SimpleBagRecorder() - : Node("simple_bag_recorder") - { - writer_ = std::make_unique(); - - writer_->open("my_bag"); - - auto subscription_callback_lambda = [this](std::shared_ptr msg){ - rclcpp::Time time_stamp = this->now(); - - writer_->write(msg, "chatter", "std_msgs/msg/String", time_stamp); - }; - - subscription_ = create_subscription( - "chatter", 10, subscription_callback_lambda); - } - - private: - - rclcpp::Subscription::SharedPtr subscription_; - std::unique_ptr writer_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The ``#include`` statements at the top are the package dependencies. -Note the inclusion of headers from the ``rosbag2_cpp`` package for the functions and structures necessary to work with bag files. - -In the class constructor we begin by creating the writer object we will use to write to the bag. - -.. code-block:: C++ - - writer_ = std::make_unique(); - -Now that we have a writer object, we can open the bag using it. -We specify just the URI of the bag to create, leaving other options at their defaults. -The default storage options are used, which means that an ``mcap``-format bag will be created. -The default conversion options are used, too, which will perform no conversion, instead storing messages in the serialisation format they are received in. - -.. code-block:: C++ - - writer_->open("my_bag"); - -With the writer now set up to record data we pass to it, we create a subscription and specify a callback for it. -We will write data to the bag in the callback. - -.. code-block:: C++ - - auto subscription_callback_lambda = [this](std::shared_ptr msg){ - rclcpp::Time time_stamp = this->now(); - - writer_->write(msg, "chatter", "std_msgs/msg/String", time_stamp); - }; - - subscription_ = create_subscription( - "chatter", 10, subscription_callback_lambda); - -The callback itself is different from a typical callback. -Rather than receiving an instance of the data type of the topic, we instead receive a ``rclcpp::SerializedMessage``. -We do this for two reasons. - -1. The message data will need to be serialized by ``rosbag2`` before being written to the bag, so rather than unserializing it when receiving the data and then re-serializing it, we ask ROS to just give us the serialized message as-is. -2. The writer API can accept a serialized message. - -.. code-block:: C++ - - auto subscription_callback_lambda = [this](std::shared_ptr msg){ - -Within the subscription callback, the first thing to do is determine the time stamp to use for the stored message. -This can be anything appropriate to your data, but two common values are the time at which the data was produced, if known, and the time it is received. -The second option, the time of reception, is used here. - -.. code-block:: C++ - - rclcpp::Time time_stamp = this->now(); - -We can then write the message into the bag. -Because we have not yet registered any topics with the bag, we must specify the full topic information with the message. -This is why we pass in the topic name and the topic type. - -.. code-block:: C++ - - writer_->write(msg, "chatter", "std_msgs/msg/String", time_stamp); - -The class contains two member variables. - -1. The subscription object. -2. A managed pointer to the writer object used to write to the bag. - Note the type of writer used here is the ``rosbag2_cpp::Writer``, the generic writer interface. - Other writers may be available with different behaviours. - -.. code-block:: C++ - - rclcpp::Subscription::SharedPtr subscription_; - std::unique_ptr writer_; - -The file finishes with the ``main`` function used to create an instance of the node and start ROS processing it. - -.. code-block:: C++ - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. - -Near the top of the file, add the following lines to set the C++ standard to C++20. - -.. code-block:: cmake - - # Default to C++20 - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - -Below the dependencies block, which contains ``find_package(rosbag2_cpp REQUIRED)``, add the following lines of code. - -.. code-block:: cmake - - add_executable(simple_bag_recorder src/simple_bag_recorder.cpp) - target_link_libraries(simple_bag_recorder rclcpp::rclcpp rosbag2_cpp::rosbag2_cpp std_msgs::std_msgs) - - install(TARGETS - simple_bag_recorder - DESTINATION lib/${PROJECT_NAME} - ) - -3 Build and run -^^^^^^^^^^^^^^^ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_recorder_nodes - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node: - -.. code-block:: console - - $ ros2 run bag_recorder_nodes simple_bag_recorder - -Open a second terminal and run the ``talker`` example node. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp talker - -This will start publishing data on the ``chatter`` topic. -As the bag-writing node receives this data, it will write it to the ``my_bag`` bag. - -Terminate both nodes. -Then, in one terminal start the ``listener`` example node. - -.. code-block:: console - - $ ros2 run demo_nodes_cpp listener - -In the other terminal, use ``ros2 bag`` to play the bag recorded by your node. - -.. code-block:: console - - $ ros2 bag play my_bag - -You will see the messages from the bag being received by the ``listener`` node. - -If you wish to run the bag-writing node again, you will first need to delete the ``my_bag`` directory. - -4 Record synthetic data from a node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Any data can be recorded into a bag, not just data received over a topic. -A common use case for writing to a bag from your own node is to generate and store synthetic data. -In this section you will learn how to write a node that generates some data and stores it in a bag. -We will demonstrate two approaches for doing this. -The first uses a node with a timer; this is the approach that you would use if your data generation is external to the node, such as reading data directly from hardware (e.g. a camera). -The second approach does not use a node; this is the approach you can use when you do not need to use any functionality from the ROS infrastructure. - -4.1 Write a C++ node -~~~~~~~~~~~~~~~~~~~~ - -Inside the ``ros2_ws/src/bag_recorder_nodes/src`` directory, create a new file called ``data_generator_node.cpp`` and paste the following code into it. - -.. code-block:: C++ - - #include - - #include - #include - - #include - - using namespace std::chrono_literals; - - class DataGenerator : public rclcpp::Node - { - public: - DataGenerator() - : Node("data_generator") - { - data_.data = 0; - writer_ = std::make_unique(); - - writer_->open("timed_synthetic_bag"); - - writer_->create_topic( - { - 0u, - "synthetic", - "example_interfaces/msg/Int32", - rmw_get_serialization_format(), - {}, - "", - }); - - auto timer_callback_lambda = [this](){return this->timer_callback();}; - timer_ = create_wall_timer(1s, timer_callback_lambda); - } - - private: - void timer_callback() - { - writer_->write(data_, "synthetic", now()); - - ++data_.data; - } - - rclcpp::TimerBase::SharedPtr timer_; - std::unique_ptr writer_; - example_interfaces::msg::Int32 data_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -4.2 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Much of this code is the same as the first example. -The important differences are described here. - -First, the name of the bag is changed. - -.. code-block:: C++ - - writer_->open("timed_synthetic_bag"); - -In this example we are registering the topic with the bag in advance. -This is optional in most cases, but it must be done when passing in a serialized message without topic information. - -.. code-block:: C++ - - writer_->create_topic( - { - 0u, - "synthetic", - "example_interfaces/msg/Int32", - rmw_get_serialization_format(), - {}, - "", - }); - -Rather than a subscription to a topic, this node has a timer. -The timer fires with a one-second period, and calls the given member function when it does. - -.. code-block:: C++ - - auto timer_callback_lambda = [this](){return this->timer_callback();}; - timer_ = create_wall_timer(1s, timer_callback_lambda); - -Within the timer callback, we generate (or otherwise obtain, e.g. read from a serial port connected to some hardware) the data we wish to store in the bag. -The important difference between this and the previous sample is that the data is not yet serialized. -Instead we are passing a ROS message data type to the writer object, in this case an instance of ``example_interfaces/msg/Int32``. -The writer will serialize the data for us before writing it into the bag. - -.. code-block:: C++ - - writer_->write(data_, "synthetic", now()); - -4.3 Add executable -~~~~~~~~~~~~~~~~~~ - -Open the ``CMakeLists.txt`` file and add the following lines after the previously-added lines (specifically, after the ``install(TARGETS ...)`` macro call). - -.. code-block:: cmake - - add_executable(data_generator_node src/data_generator_node.cpp) - target_link_libraries(data_generator_node PUBLIC rclcpp::rclcpp rosbag2_cpp::rosbag2_cpp example_interfaces::example_interfaces) - - install(TARGETS - data_generator_node - DESTINATION lib/${PROJECT_NAME} - ) - -4.4 Build and run -~~~~~~~~~~~~~~~~~ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_recorder_nodes - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -(If the ``timed_synthetic_bag`` directory already exists, you must first delete it before running the node.) - -Now run the node: - -.. code-block:: console - - $ ros2 run bag_recorder_nodes data_generator_node - -Wait for 30 seconds or so, then terminate the node with :kbd:`ctrl-c`. -Next, play back the created bag. - -.. code-block:: console - - $ ros2 bag play timed_synthetic_bag - -Open a second terminal and echo the ``/synthetic`` topic. - -.. code-block:: console - - $ ros2 topic echo /synthetic - -You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. - -5 Record synthetic data from an executable -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now that you can create a bag that stores data from a source other than a topic, you will learn how to generate and record synthetic data from a non-node executable. -The advantage of this approach is simpler code and rapid creation of a large quantity of data. - -5.1 Write a C++ executable -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Inside the ``ros2_ws/src/bag_recorder_nodes/src`` directory, create a new file called ``data_generator_executable.cpp`` and paste the following code into it. - -.. code-block:: C++ - - #include - - #include // For rclcpp::Clock, rclcpp::Duration and rclcpp::Time - #include - - #include - #include - #include - - using namespace std::chrono_literals; - - int main(int, char**) - { - example_interfaces::msg::Int32 data; - data.data = 0; - std::unique_ptr writer_ = std::make_unique(); - - writer_->open("big_synthetic_bag"); - - writer_->create_topic( - { - 0u, - "synthetic", - "example_interfaces/msg/Int32", - rmw_get_serialization_format(), - {}, - "", - }); - - rclcpp::Clock clock; - rclcpp::Time time_stamp = clock.now(); - for (int32_t ii = 0; ii < 100; ++ii) { - writer_->write(data, "synthetic", time_stamp); - ++data.data; - time_stamp += rclcpp::Duration(1s); - } - - return 0; - } - -5.2 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -A comparison of this sample and the previous sample will reveal that they are not that different. -The only significant difference is the use of a for loop to drive the data generation rather than a timer. - -Notice that we are also now generating time stamps for the data rather than relying on the current system time for each sample. -The time stamp can be any value you need it to be. -The data will be played back at the rate given by these time stamps, so this is a useful way to control the default playback speed of the samples. -Notice also that while the gap between each sample is a full second in time, this executable does not need to wait a second between each sample. -This allows us to generate a lot of data covering a wide span of time in much less time than playback will take. - -.. code-block:: C++ - - rclcpp::Clock clock; - rclcpp::Time time_stamp = clock.now(); - for (int32_t ii = 0; ii < 100; ++ii) { - writer_->write(data, "synthetic", time_stamp); - ++data.data; - time_stamp += rclcpp::Duration(1s); - } - -5.3 Add executable -~~~~~~~~~~~~~~~~~~ - -Open the ``CMakeLists.txt`` file and add the following lines after the previously-added lines. - -.. code-block:: cmake - - add_executable(data_generator_executable src/data_generator_executable.cpp) - target_link_libraries(data_generator_executable PUBLIC rclcpp::rclcpp rosbag2_cpp::rosbag2_cpp example_interfaces::example_interfaces) - - install(TARGETS - data_generator_executable - DESTINATION lib/${PROJECT_NAME} - ) - -5.4 Build and run -~~~~~~~~~~~~~~~~~ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_recorder_nodes - -Open a terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -(If the ``big_synthetic_bag`` directory already exists, you must first delete it before running the executable.) - -Now run the executable: - -.. code-block:: console - - $ ros2 run bag_recorder_nodes data_generator_executable - -Note that the executable runs and finishes very quickly. - -Now play back the created bag. - -.. code-block:: console - - $ ros2 bag play big_synthetic_bag - -Open a second terminal and echo the ``/synthetic`` topic. - -.. code-block:: console - - $ ros2 topic echo /synthetic - -You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. -Even though the bag was generated rapidly it is still played back at the rate the time stamps indicate. - -Summary -------- - -You created a node that records data it receives on a topic into a bag. -You tested recording a bag using the node, and verified the data was recorded by playing back the bag. -You then went on to create a node and an executable to generate synthetic data and store it in a bag. +.. redirect-from:: + + Tutorials/Ros2bag/Recording-A-Bag-From-Your-Own-Node-Cpp + Tutorials/Advanced/Recording-A-Bag-From-Your-Own-Node-CPP + +.. _ROS2BagOwnNode: + +Recording a bag from a node (C++) +================================= + +**Goal:** Record data from your own C++ node to a bag. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. +It also provides a C++ API for reading from and writing to a bag from your own source code. +This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choice on that data. + +Prerequisites +------------- + +You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. + +If you've installed from deb packages on Linux, it may be installed by default. +If it is not, you can install it using this command. + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-rosbag2 + +This tutorial discusses using ROS 2 bags, including from the terminal. +You should have already completed the :doc:`basic ROS 2 bag tutorial <../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. +Navigate into the ``ros2_ws/src`` directory and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 bag_recorder_nodes --dependencies example_interfaces rclcpp rosbag2_cpp std_msgs + +Your terminal will return a message verifying the creation of your package ``bag_recorder_nodes`` and all its necessary files and folders. +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. +In this case, the package will use the ``rosbag2_cpp`` package as well as the ``rclcpp`` package. +A dependency on the ``example_interfaces`` package is also required for later parts of this tutorial. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + C++ bag writing tutorial + Your Name + Apache-2.0 + +2 Write the C++ node +^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/bag_recorder_nodes/src`` directory, create a new file called ``simple_bag_recorder.cpp`` and paste the following code into it. + +.. code-block:: C++ + + + #include + #include + + #include + + class SimpleBagRecorder : public rclcpp::Node + { + public: + SimpleBagRecorder() + : Node("simple_bag_recorder") + { + writer_ = std::make_unique(); + + writer_->open("my_bag"); + + auto subscription_callback_lambda = [this](std::shared_ptr msg){ + rclcpp::Time time_stamp = this->now(); + + writer_->write(msg, "chatter", "std_msgs/msg/String", time_stamp); + }; + + subscription_ = create_subscription( + "chatter", 10, subscription_callback_lambda); + } + + private: + + rclcpp::Subscription::SharedPtr subscription_; + std::unique_ptr writer_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The ``#include`` statements at the top are the package dependencies. +Note the inclusion of headers from the ``rosbag2_cpp`` package for the functions and structures necessary to work with bag files. + +In the class constructor we begin by creating the writer object we will use to write to the bag. + +.. code-block:: C++ + + writer_ = std::make_unique(); + +Now that we have a writer object, we can open the bag using it. +We specify just the URI of the bag to create, leaving other options at their defaults. +The default storage options are used, which means that an ``mcap``-format bag will be created. +The default conversion options are used, too, which will perform no conversion, instead storing messages in the serialisation format they are received in. + +.. code-block:: C++ + + writer_->open("my_bag"); + +With the writer now set up to record data we pass to it, we create a subscription and specify a callback for it. +We will write data to the bag in the callback. + +.. code-block:: C++ + + auto subscription_callback_lambda = [this](std::shared_ptr msg){ + rclcpp::Time time_stamp = this->now(); + + writer_->write(msg, "chatter", "std_msgs/msg/String", time_stamp); + }; + + subscription_ = create_subscription( + "chatter", 10, subscription_callback_lambda); + +The callback itself is different from a typical callback. +Rather than receiving an instance of the data type of the topic, we instead receive a ``rclcpp::SerializedMessage``. +We do this for two reasons. + +1. The message data will need to be serialized by ``rosbag2`` before being written to the bag, so rather than unserializing it when receiving the data and then re-serializing it, we ask ROS to just give us the serialized message as-is. +2. The writer API can accept a serialized message. + +.. code-block:: C++ + + auto subscription_callback_lambda = [this](std::shared_ptr msg){ + +Within the subscription callback, the first thing to do is determine the time stamp to use for the stored message. +This can be anything appropriate to your data, but two common values are the time at which the data was produced, if known, and the time it is received. +The second option, the time of reception, is used here. + +.. code-block:: C++ + + rclcpp::Time time_stamp = this->now(); + +We can then write the message into the bag. +Because we have not yet registered any topics with the bag, we must specify the full topic information with the message. +This is why we pass in the topic name and the topic type. + +.. code-block:: C++ + + writer_->write(msg, "chatter", "std_msgs/msg/String", time_stamp); + +The class contains two member variables. + +1. The subscription object. +2. A managed pointer to the writer object used to write to the bag. + Note the type of writer used here is the ``rosbag2_cpp::Writer``, the generic writer interface. + Other writers may be available with different behaviours. + +.. code-block:: C++ + + rclcpp::Subscription::SharedPtr subscription_; + std::unique_ptr writer_; + +The file finishes with the ``main`` function used to create an instance of the node and start ROS processing it. + +.. code-block:: C++ + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. + +Near the top of the file, add the following lines to set the C++ standard to C++20. + +.. code-block:: cmake + + # Default to C++20 + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + +Below the dependencies block, which contains ``find_package(rosbag2_cpp REQUIRED)``, add the following lines of code. + +.. code-block:: cmake + + add_executable(simple_bag_recorder src/simple_bag_recorder.cpp) + target_link_libraries(simple_bag_recorder rclcpp::rclcpp rosbag2_cpp::rosbag2_cpp std_msgs::std_msgs) + + install(TARGETS + simple_bag_recorder + DESTINATION lib/${PROJECT_NAME} + ) + +3 Build and run +^^^^^^^^^^^^^^^ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_recorder_nodes + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node: + +.. code-block:: console + + $ ros2 run bag_recorder_nodes simple_bag_recorder + +Open a second terminal and run the ``talker`` example node. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp talker + +This will start publishing data on the ``chatter`` topic. +As the bag-writing node receives this data, it will write it to the ``my_bag`` bag. + +Terminate both nodes. +Then, in one terminal start the ``listener`` example node. + +.. code-block:: console + + $ ros2 run demo_nodes_cpp listener + +In the other terminal, use ``ros2 bag`` to play the bag recorded by your node. + +.. code-block:: console + + $ ros2 bag play my_bag + +You will see the messages from the bag being received by the ``listener`` node. + +If you wish to run the bag-writing node again, you will first need to delete the ``my_bag`` directory. + +4 Record synthetic data from a node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Any data can be recorded into a bag, not just data received over a topic. +A common use case for writing to a bag from your own node is to generate and store synthetic data. +In this section you will learn how to write a node that generates some data and stores it in a bag. +We will demonstrate two approaches for doing this. +The first uses a node with a timer; this is the approach that you would use if your data generation is external to the node, such as reading data directly from hardware (e.g. a camera). +The second approach does not use a node; this is the approach you can use when you do not need to use any functionality from the ROS infrastructure. + +4.1 Write a C++ node +~~~~~~~~~~~~~~~~~~~~ + +Inside the ``ros2_ws/src/bag_recorder_nodes/src`` directory, create a new file called ``data_generator_node.cpp`` and paste the following code into it. + +.. code-block:: C++ + + #include + + #include + #include + + #include + + using namespace std::chrono_literals; + + class DataGenerator : public rclcpp::Node + { + public: + DataGenerator() + : Node("data_generator") + { + data_.data = 0; + writer_ = std::make_unique(); + + writer_->open("timed_synthetic_bag"); + + writer_->create_topic( + { + 0u, + "synthetic", + "example_interfaces/msg/Int32", + rmw_get_serialization_format(), + {}, + "", + }); + + auto timer_callback_lambda = [this](){return this->timer_callback();}; + timer_ = create_wall_timer(1s, timer_callback_lambda); + } + + private: + void timer_callback() + { + writer_->write(data_, "synthetic", now()); + + ++data_.data; + } + + rclcpp::TimerBase::SharedPtr timer_; + std::unique_ptr writer_; + example_interfaces::msg::Int32 data_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +4.2 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Much of this code is the same as the first example. +The important differences are described here. + +First, the name of the bag is changed. + +.. code-block:: C++ + + writer_->open("timed_synthetic_bag"); + +In this example we are registering the topic with the bag in advance. +This is optional in most cases, but it must be done when passing in a serialized message without topic information. + +.. code-block:: C++ + + writer_->create_topic( + { + 0u, + "synthetic", + "example_interfaces/msg/Int32", + rmw_get_serialization_format(), + {}, + "", + }); + +Rather than a subscription to a topic, this node has a timer. +The timer fires with a one-second period, and calls the given member function when it does. + +.. code-block:: C++ + + auto timer_callback_lambda = [this](){return this->timer_callback();}; + timer_ = create_wall_timer(1s, timer_callback_lambda); + +Within the timer callback, we generate (or otherwise obtain, e.g. read from a serial port connected to some hardware) the data we wish to store in the bag. +The important difference between this and the previous sample is that the data is not yet serialized. +Instead we are passing a ROS message data type to the writer object, in this case an instance of ``example_interfaces/msg/Int32``. +The writer will serialize the data for us before writing it into the bag. + +.. code-block:: C++ + + writer_->write(data_, "synthetic", now()); + +4.3 Add executable +~~~~~~~~~~~~~~~~~~ + +Open the ``CMakeLists.txt`` file and add the following lines after the previously-added lines (specifically, after the ``install(TARGETS ...)`` macro call). + +.. code-block:: cmake + + add_executable(data_generator_node src/data_generator_node.cpp) + target_link_libraries(data_generator_node PUBLIC rclcpp::rclcpp rosbag2_cpp::rosbag2_cpp example_interfaces::example_interfaces) + + install(TARGETS + data_generator_node + DESTINATION lib/${PROJECT_NAME} + ) + +4.4 Build and run +~~~~~~~~~~~~~~~~~ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_recorder_nodes + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +(If the ``timed_synthetic_bag`` directory already exists, you must first delete it before running the node.) + +Now run the node: + +.. code-block:: console + + $ ros2 run bag_recorder_nodes data_generator_node + +Wait for 30 seconds or so, then terminate the node with :kbd:`ctrl-c`. +Next, play back the created bag. + +.. code-block:: console + + $ ros2 bag play timed_synthetic_bag + +Open a second terminal and echo the ``/synthetic`` topic. + +.. code-block:: console + + $ ros2 topic echo /synthetic + +You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. + +5 Record synthetic data from an executable +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now that you can create a bag that stores data from a source other than a topic, you will learn how to generate and record synthetic data from a non-node executable. +The advantage of this approach is simpler code and rapid creation of a large quantity of data. + +5.1 Write a C++ executable +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Inside the ``ros2_ws/src/bag_recorder_nodes/src`` directory, create a new file called ``data_generator_executable.cpp`` and paste the following code into it. + +.. code-block:: C++ + + #include + + #include // For rclcpp::Clock, rclcpp::Duration and rclcpp::Time + #include + + #include + #include + #include + + using namespace std::chrono_literals; + + int main(int, char**) + { + example_interfaces::msg::Int32 data; + data.data = 0; + std::unique_ptr writer_ = std::make_unique(); + + writer_->open("big_synthetic_bag"); + + writer_->create_topic( + { + 0u, + "synthetic", + "example_interfaces/msg/Int32", + rmw_get_serialization_format(), + {}, + "", + }); + + rclcpp::Clock clock; + rclcpp::Time time_stamp = clock.now(); + for (int32_t ii = 0; ii < 100; ++ii) { + writer_->write(data, "synthetic", time_stamp); + ++data.data; + time_stamp += rclcpp::Duration(1s); + } + + return 0; + } + +5.2 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +A comparison of this sample and the previous sample will reveal that they are not that different. +The only significant difference is the use of a for loop to drive the data generation rather than a timer. + +Notice that we are also now generating time stamps for the data rather than relying on the current system time for each sample. +The time stamp can be any value you need it to be. +The data will be played back at the rate given by these time stamps, so this is a useful way to control the default playback speed of the samples. +Notice also that while the gap between each sample is a full second in time, this executable does not need to wait a second between each sample. +This allows us to generate a lot of data covering a wide span of time in much less time than playback will take. + +.. code-block:: C++ + + rclcpp::Clock clock; + rclcpp::Time time_stamp = clock.now(); + for (int32_t ii = 0; ii < 100; ++ii) { + writer_->write(data, "synthetic", time_stamp); + ++data.data; + time_stamp += rclcpp::Duration(1s); + } + +5.3 Add executable +~~~~~~~~~~~~~~~~~~ + +Open the ``CMakeLists.txt`` file and add the following lines after the previously-added lines. + +.. code-block:: cmake + + add_executable(data_generator_executable src/data_generator_executable.cpp) + target_link_libraries(data_generator_executable PUBLIC rclcpp::rclcpp rosbag2_cpp::rosbag2_cpp example_interfaces::example_interfaces) + + install(TARGETS + data_generator_executable + DESTINATION lib/${PROJECT_NAME} + ) + +5.4 Build and run +~~~~~~~~~~~~~~~~~ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_recorder_nodes + +Open a terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +(If the ``big_synthetic_bag`` directory already exists, you must first delete it before running the executable.) + +Now run the executable: + +.. code-block:: console + + $ ros2 run bag_recorder_nodes data_generator_executable + +Note that the executable runs and finishes very quickly. + +Now play back the created bag. + +.. code-block:: console + + $ ros2 bag play big_synthetic_bag + +Open a second terminal and echo the ``/synthetic`` topic. + +.. code-block:: console + + $ ros2 topic echo /synthetic + +You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. +Even though the bag was generated rapidly it is still played back at the rate the time stamps indicate. + +Summary +------- + +You created a node that records data it receives on a topic into a bag. +You tested recording a bag using the node, and verified the data was recorded by playing back the bag. +You then went on to create a node and an executable to generate synthetic data and store it in a bag. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst index fd98913f295..057b6ab6a4b 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst @@ -1,678 +1,679 @@ -.. redirect-from:: - - Tutorials/Ros2bag/Recording-A-Bag-From-Your-Own-Node-Python - -.. _ROS2BagOwnNodePython: - -Recording a bag from a node (Python) -==================================== - -**Goal:** Record data from your own Python node to a bag. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. -It also provides a Python API for reading from and writing to a bag from your own source code. -This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choice on that data. -You may do this, for example, to save data from a topic and the result of processing that data without needing to send the processed data over a topic just to record it. -Because any data can be recorded in a bag, it is also possible to save data generated by another source than a topic, such as synthetic data for training sets. -This is useful, for example, for quickly generating a bag that contains a large number of samples spread over a long playback time. - -Prerequisites -------------- - -You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. - -If you've installed from deb packages on Linux, it may be installed by default. -If it is not, you can install it using this command. - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-rosbag2 - -This tutorial discusses using ROS 2 bags, including from the terminal. -You should have already completed the :doc:`basic ROS 2 bag tutorial <../Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. - -Navigate into the ``ros2_ws/src`` directory and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 bag_recorder_nodes_py --dependencies rclpy rosbag2_py example_interfaces std_msgs - -Your terminal will return a message verifying the creation of your package ``bag_recorder_nodes_py`` and all its necessary files and folders. -The ``--dependencies`` argument will automatically add the necessary dependency lines to the ``package.xml``. -In this case, the package will use the ``rosbag2_py`` package as well as the ``rclpy`` package. -A dependency on the ``std_msgs`` and ``example_interfaces`` packages are also required for message definitions. - -1.1 Update ``package.xml`` and ``setup.py`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - Python bag writing tutorial - Your Name - Apache-2.0 - -Also be sure to add this information to the ``setup.py`` file as well. - -.. code-block:: Python - - maintainer='Your Name', - maintainer_email='you@email.com', - description='Python bag writing tutorial', - license='Apache-2.0', - -2 Write the Python node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/bag_recorder_nodes_py/bag_recorder_nodes_py`` directory, create a new file called ``simple_bag_recorder.py`` and paste the following code into it. - -.. code-block:: Python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - from rclpy.serialization import serialize_message - from std_msgs.msg import String - - import rosbag2_py - - class SimpleBagRecorder(Node): - def __init__(self): - super().__init__('simple_bag_recorder') - self.writer = rosbag2_py.SequentialWriter() - - storage_options = rosbag2_py.StorageOptions( - uri='my_bag', - storage_id='mcap') - converter_options = rosbag2_py.ConverterOptions('', '') - self.writer.open(storage_options, converter_options) - - topic_info = rosbag2_py.TopicMetadata( - id=0, - name='chatter', - type='std_msgs/msg/String', - serialization_format='cdr') - self.writer.create_topic(topic_info) - - self.subscription = self.create_subscription( - String, - 'chatter', - self.topic_callback, - 10) - self.subscription - - def topic_callback(self, msg): - self.writer.write( - 'chatter', - serialize_message(msg), - self.get_clock().now().nanoseconds) - - - def main(args=None): - try: - with rclpy.init(args=args): - sbr = SimpleBagRecorder() - rclpy.spin(sbr) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The ``import`` statements at the top are the package dependencies. -Note the importation of the ``rosbag2_py`` package for the functions and structures necessary to work with bag files. - -In the class constructor, we begin by creating the writer object that we will use to write to the bag. -We are creating a ``SequentialWriter``, which writes messages into the bag in the order they are received. -Other writers with different behaviors may be available in `rosbag2 writer `__. - -.. code-block:: Python - - self.writer = rosbag2_py.SequentialWriter() - -Now that we have a writer object, we can open the bag using it. -We specify the URI of the bag to create and the format (``mcap``), leaving other options at their defaults. -The default conversion options are used, which will perform no conversion and store the messages in the serialization format they are received in. - -.. code-block:: Python - - storage_options = rosbag2_py.StorageOptions( - uri='my_bag', - storage_id='mcap') - converter_options = rosbag2_py.ConverterOptions('', '') - self.writer.open(storage_options, converter_options) - -Next, we need to tell the writer about the topics we wish to store. -This is done by creating a ``TopicMetadata`` object and registering it with the writer. -This object specifies the topic name, topic data type, and serialization format used. - -.. code-block:: Python - - topic_info = rosbag2_py.TopicMetadata( - id=0, - name='chatter', - type='std_msgs/msg/String', - serialization_format='cdr') - self.writer.create_topic(topic_info) - -With the writer now set up to record data we pass to it, we create a subscription and specify a callback for it. -We will write data to the bag in the callback. - -.. code-block:: Python - - self.subscription = self.create_subscription( - String, - 'chatter', - self.topic_callback, - 10) - self.subscription - -The callback receives the message in unserialized form (as is standard for the ``rclpy`` API) and passes the message to the writer, specifying the topic that the data is for and the timestamp to record with the message. -However, the writer requires serialized messages to store in the bag. -This means that we need to serialize the data before passing it to the writer. -For this reason, we call ``serialize_message()`` and pass the result of that to the writer, rather than passing in the message directly. - -.. code-block:: Python - - def topic_callback(self, msg): - self.writer.write( - 'chatter', - serialize_message(msg), - self.get_clock().now().nanoseconds) - -The file finishes with the ``main`` function used to create an instance of the node and start ROS processing it. - -.. code-block:: Python - - def main(args=None): - try: - with rclpy.init(args=args): - sbr = SimpleBagRecorder() - rclpy.spin(sbr) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -2.2 Add entry point -~~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file in the ``bag_recorder_nodes_py`` package and add an entry point for your node. - -.. code-block:: Python - - entry_points={ - 'console_scripts': [ - 'simple_bag_recorder = bag_recorder_nodes_py.simple_bag_recorder:main', - ], - }, - - -3 Build and run -^^^^^^^^^^^^^^^ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_recorder_nodes_py - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node: - -.. code-block:: console - - $ ros2 run bag_recorder_nodes_py simple_bag_recorder - -Open a second terminal and run the ``talker`` example node. - -.. code-block:: console - - $ ros2 run demo_nodes_py talker - -This will start publishing data on the ``chatter`` topic. -As the bag-writing node receives this data, it will write it to the ``my_bag`` bag. -If the ``my_bag`` directory already exists, you must first delete it before running the ``simple_bag_recorder`` node. -This is because ``rosbag2`` will not overwrite existing bags by default, and so the destination directory cannot exist. - -Terminate both nodes. -Then, in one terminal start the ``listener`` example node. - -.. code-block:: console - - $ ros2 run demo_nodes_py listener - -In the other terminal, use ``ros2 bag`` to play the bag recorded by your node. - -.. code-block:: console - - $ ros2 bag play my_bag - -You will see the messages from the bag being received by the ``listener`` node. - -If you wish to run the bag-writing node again, you will first need to delete the ``my_bag`` directory. - -4 Record synthetic data from a node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Any data can be recorded into a bag, not just data received over a topic. -A common use case for writing to a bag from your own node is to generate and store synthetic data. -In this section you will learn how to write a node that generates some data and stores it in a bag. -We will demonstrate two approaches for doing this. -The first uses a node with a timer; this is the approach that you would use if your data generation is external to the node, such as reading data directly from hardware (e.g. a camera). -The second approach does not use a node; this is the approach you can use when you do not need to use any functionality from the ROS infrastructure. - -4.1 Write a Python node -~~~~~~~~~~~~~~~~~~~~~~~ - -Inside the ``ros2_ws/src/bag_recorder_nodes_py/bag_recorder_nodes_py`` directory, create a new file called ``data_generator_node.py`` and paste the following code into it. - -.. code-block:: Python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - from rclpy.serialization import serialize_message - from example_interfaces.msg import Int32 - - import rosbag2_py - - class DataGeneratorNode(Node): - def __init__(self): - super().__init__('data_generator_node') - self.data = Int32() - self.data.data = 0 - self.writer = rosbag2_py.SequentialWriter() - - storage_options = rosbag2_py.StorageOptions( - uri='timed_synthetic_bag', - storage_id='mcap') - converter_options = rosbag2_py.ConverterOptions('', '') - self.writer.open(storage_options, converter_options) - - topic_info = rosbag2_py.TopicMetadata( - id=0, - name='synthetic', - type='example_interfaces/msg/Int32', - serialization_format='cdr') - self.writer.create_topic(topic_info) - - self.timer = self.create_timer(1, self.timer_callback) - - def timer_callback(self): - self.writer.write( - 'synthetic', - serialize_message(self.data), - self.get_clock().now().nanoseconds) - self.data.data += 1 - - - def main(args=None): - try: - with rclpy.init(args=args): - dgn = DataGeneratorNode() - rclpy.spin(dgn) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -4.2 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Much of this code is the same as the first example. -The important differences are described here. - -First, the name of the bag is changed. - -.. code-block:: Python - - storage_options = rosbag2_py.StorageOptions( - uri='timed_synthetic_bag', - storage_id='mcap') - -The name of the topic is also changed, as is the data type stored. - -.. code-block:: Python - - topic_info = rosbag2_py.TopicMetadata( - id=0, - name='synthetic', - type='example_interfaces/msg/Int32', - serialization_format='cdr') - self.writer.create_topic(topic_info) - -Rather than a subscription to a topic, this node has a timer. -The timer fires with a one-second period, and calls the given member function when it does. - -.. code-block:: Python - - self.timer = self.create_timer(1, self.timer_callback) - -Within the timer callback, we generate (or otherwise obtain, e.g. read from a serial port connected to some hardware) the data we wish to store in the bag. -As with the previous example, the data is not yet serialized, so we must serialize it before passing it to the writer. - -.. code-block:: Python - - self.writer.write( - 'synthetic', - serialize_message(self.data), - self.get_clock().now().nanoseconds) - -4.3 Add executable -~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file in the ``bag_recorder_nodes_py`` package and add an entry point for your node. - -.. code-block:: Python - - entry_points={ - 'console_scripts': [ - 'simple_bag_recorder = bag_recorder_nodes_py.simple_bag_recorder:main', - 'data_generator_node = bag_recorder_nodes_py.data_generator_node:main', - ], - }, - -4.4 Build and run -~~~~~~~~~~~~~~~~~ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_recorder_nodes_py - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -If the ``timed_synthetic_bag`` directory already exists, you must first delete it before running the node. - -Now run the node: - -.. code-block:: console - - $ ros2 run bag_recorder_nodes_py data_generator_node - -Wait for 30 seconds or so, then terminate the node with :kbd:`ctrl-c`. -Next, play back the created bag. - -.. code-block:: console - - $ ros2 bag play timed_synthetic_bag - -Open a second terminal and echo the ``/synthetic`` topic. - -.. code-block:: console - - $ ros2 topic echo /synthetic - -You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. - -5 Record synthetic data from an executable -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now that you can create a bag that stores data from a source other than a topic, you will learn how to generate and record synthetic data from a non-node executable. -The advantage of this approach is simpler code and rapid creation of a large quantity of data. - -5.1 Write a Python executable -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Inside the ``ros2_ws/src/bag_recorder_nodes_py/bag_recorder_nodes_py`` directory, create a new file called ``data_generator_executable.py`` and paste the following code into it. - -.. code-block:: Python - - from rclpy.clock import Clock - from rclpy.duration import Duration - from rclpy.serialization import serialize_message - from example_interfaces.msg import Int32 - - import rosbag2_py - - - def main(args=None): - writer = rosbag2_py.SequentialWriter() - - storage_options = rosbag2_py.StorageOptions( - uri='big_synthetic_bag', - storage_id='mcap') - converter_options = rosbag2_py.ConverterOptions('', '') - writer.open(storage_options, converter_options) - - topic_info = rosbag2_py.TopicMetadata( - id=0, - name='synthetic', - type='example_interfaces/msg/Int32', - serialization_format='cdr') - writer.create_topic(topic_info) - - time_stamp = Clock().now() - for ii in range(0, 100): - data = Int32() - data.data = ii - writer.write( - 'synthetic', - serialize_message(data), - time_stamp.nanoseconds) - time_stamp += Duration(seconds=1) - - if __name__ == '__main__': - main() - -5.2 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -A comparison of this sample and the previous sample will reveal that they are not that different. -The only significant difference is the use of a for loop to drive the data generation rather than a timer. - -Notice that we are also now generating time stamps for the data rather than relying on the current system time for each sample. -The time stamp can be any value you need it to be. -The data will be played back at the rate given by these time stamps, so this is a useful way to control the default playback speed of the samples. -Notice also that while the gap between each sample is a full second in time, this executable does not need to wait a second between each sample. -This allows us to generate a lot of data covering a wide span of time in much less time than playback will take. - -.. code-block:: Python - - time_stamp = Clock().now() - for ii in range(0, 100): - data = Int32() - data.data = ii - writer.write( - 'synthetic', - serialize_message(data), - time_stamp.nanoseconds) - time_stamp += Duration(seconds=1) - -5.3 Add executable -~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file in the ``bag_recorder_nodes_py`` package and add an entry point for your node. - -.. code-block:: Python - - entry_points={ - 'console_scripts': [ - 'simple_bag_recorder = bag_recorder_nodes_py.simple_bag_recorder:main', - 'data_generator_node = bag_recorder_nodes_py.data_generator_node:main', - 'data_generator_executable = bag_recorder_nodes_py.data_generator_executable:main', - ], - }, - -5.4 Build and run -~~~~~~~~~~~~~~~~~ - -Navigate back to the root of your workspace, ``ros2_ws``, and build your package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select bag_recorder_nodes_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select bag_recorder_nodes_py - -Open a terminal, navigate to ``ros2_ws``, and source the setup files. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -If the ``big_synthetic_bag`` directory already exists, you must first delete it before running the executable. - -Now run the executable: - -.. code-block:: console - - $ ros2 run bag_recorder_nodes_py data_generator_executable - -Note that the executable runs and finishes very quickly. - -Now play back the created bag. - -.. code-block:: console - - $ ros2 bag play big_synthetic_bag - -Open a second terminal and echo the ``/synthetic`` topic. - -.. code-block:: console - - $ ros2 topic echo /synthetic - -You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. -Even though the bag was generated rapidly it is still played back at the rate the time stamps indicate. - -Summary -------- - -You created a node that records data it receives on a topic into a bag. -You tested recording a bag using the node, and verified the data was recorded by playing back the bag. -This approach can be used to record a bag with additional data than it received over a topic, for example with results obtained from processing the received data. -You then went on to create a node and an executable to generate synthetic data and store it in a bag. -The latter approaches are useful especially for generating synthetic data that can be used, for example, as training sets. +.. redirect-from:: + + Tutorials/Ros2bag/Recording-A-Bag-From-Your-Own-Node-Python + Tutorials/Advanced/Recording-A-Bag-From-Your-Own-Node-Py + +.. _ROS2BagOwnNodePython: + +Recording a bag from a node (Python) +==================================== + +**Goal:** Record data from your own Python node to a bag. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``rosbag2`` doesn't just provide the ``ros2 bag`` command line tool. +It also provides a Python API for reading from and writing to a bag from your own source code. +This allows you to subscribe to a topic and save the received data to a bag at the same time as performing any other processing of your choice on that data. +You may do this, for example, to save data from a topic and the result of processing that data without needing to send the processed data over a topic just to record it. +Because any data can be recorded in a bag, it is also possible to save data generated by another source than a topic, such as synthetic data for training sets. +This is useful, for example, for quickly generating a bag that contains a large number of samples spread over a long playback time. + +Prerequisites +------------- + +You should have the ``rosbag2`` packages installed as part of your regular ROS 2 setup. + +If you've installed from deb packages on Linux, it may be installed by default. +If it is not, you can install it using this command. + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-rosbag2 + +This tutorial discusses using ROS 2 bags, including from the terminal. +You should have already completed the :doc:`basic ROS 2 bag tutorial <../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>`. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. + +Navigate into the ``ros2_ws/src`` directory and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 bag_recorder_nodes_py --dependencies rclpy rosbag2_py example_interfaces std_msgs + +Your terminal will return a message verifying the creation of your package ``bag_recorder_nodes_py`` and all its necessary files and folders. +The ``--dependencies`` argument will automatically add the necessary dependency lines to the ``package.xml``. +In this case, the package will use the ``rosbag2_py`` package as well as the ``rclpy`` package. +A dependency on the ``std_msgs`` and ``example_interfaces`` packages are also required for message definitions. + +1.1 Update ``package.xml`` and ``setup.py`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + Python bag writing tutorial + Your Name + Apache-2.0 + +Also be sure to add this information to the ``setup.py`` file as well. + +.. code-block:: Python + + maintainer='Your Name', + maintainer_email='you@email.com', + description='Python bag writing tutorial', + license='Apache-2.0', + +2 Write the Python node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/bag_recorder_nodes_py/bag_recorder_nodes_py`` directory, create a new file called ``simple_bag_recorder.py`` and paste the following code into it. + +.. code-block:: Python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + from rclpy.serialization import serialize_message + from std_msgs.msg import String + + import rosbag2_py + + class SimpleBagRecorder(Node): + def __init__(self): + super().__init__('simple_bag_recorder') + self.writer = rosbag2_py.SequentialWriter() + + storage_options = rosbag2_py.StorageOptions( + uri='my_bag', + storage_id='mcap') + converter_options = rosbag2_py.ConverterOptions('', '') + self.writer.open(storage_options, converter_options) + + topic_info = rosbag2_py.TopicMetadata( + id=0, + name='chatter', + type='std_msgs/msg/String', + serialization_format='cdr') + self.writer.create_topic(topic_info) + + self.subscription = self.create_subscription( + String, + 'chatter', + self.topic_callback, + 10) + self.subscription + + def topic_callback(self, msg): + self.writer.write( + 'chatter', + serialize_message(msg), + self.get_clock().now().nanoseconds) + + + def main(args=None): + try: + with rclpy.init(args=args): + sbr = SimpleBagRecorder() + rclpy.spin(sbr) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The ``import`` statements at the top are the package dependencies. +Note the importation of the ``rosbag2_py`` package for the functions and structures necessary to work with bag files. + +In the class constructor, we begin by creating the writer object that we will use to write to the bag. +We are creating a ``SequentialWriter``, which writes messages into the bag in the order they are received. +Other writers with different behaviors may be available in `rosbag2 writer `__. + +.. code-block:: Python + + self.writer = rosbag2_py.SequentialWriter() + +Now that we have a writer object, we can open the bag using it. +We specify the URI of the bag to create and the format (``mcap``), leaving other options at their defaults. +The default conversion options are used, which will perform no conversion and store the messages in the serialization format they are received in. + +.. code-block:: Python + + storage_options = rosbag2_py.StorageOptions( + uri='my_bag', + storage_id='mcap') + converter_options = rosbag2_py.ConverterOptions('', '') + self.writer.open(storage_options, converter_options) + +Next, we need to tell the writer about the topics we wish to store. +This is done by creating a ``TopicMetadata`` object and registering it with the writer. +This object specifies the topic name, topic data type, and serialization format used. + +.. code-block:: Python + + topic_info = rosbag2_py.TopicMetadata( + id=0, + name='chatter', + type='std_msgs/msg/String', + serialization_format='cdr') + self.writer.create_topic(topic_info) + +With the writer now set up to record data we pass to it, we create a subscription and specify a callback for it. +We will write data to the bag in the callback. + +.. code-block:: Python + + self.subscription = self.create_subscription( + String, + 'chatter', + self.topic_callback, + 10) + self.subscription + +The callback receives the message in unserialized form (as is standard for the ``rclpy`` API) and passes the message to the writer, specifying the topic that the data is for and the timestamp to record with the message. +However, the writer requires serialized messages to store in the bag. +This means that we need to serialize the data before passing it to the writer. +For this reason, we call ``serialize_message()`` and pass the result of that to the writer, rather than passing in the message directly. + +.. code-block:: Python + + def topic_callback(self, msg): + self.writer.write( + 'chatter', + serialize_message(msg), + self.get_clock().now().nanoseconds) + +The file finishes with the ``main`` function used to create an instance of the node and start ROS processing it. + +.. code-block:: Python + + def main(args=None): + try: + with rclpy.init(args=args): + sbr = SimpleBagRecorder() + rclpy.spin(sbr) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +2.2 Add entry point +~~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file in the ``bag_recorder_nodes_py`` package and add an entry point for your node. + +.. code-block:: Python + + entry_points={ + 'console_scripts': [ + 'simple_bag_recorder = bag_recorder_nodes_py.simple_bag_recorder:main', + ], + }, + + +3 Build and run +^^^^^^^^^^^^^^^ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_recorder_nodes_py + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node: + +.. code-block:: console + + $ ros2 run bag_recorder_nodes_py simple_bag_recorder + +Open a second terminal and run the ``talker`` example node. + +.. code-block:: console + + $ ros2 run demo_nodes_py talker + +This will start publishing data on the ``chatter`` topic. +As the bag-writing node receives this data, it will write it to the ``my_bag`` bag. +If the ``my_bag`` directory already exists, you must first delete it before running the ``simple_bag_recorder`` node. +This is because ``rosbag2`` will not overwrite existing bags by default, and so the destination directory cannot exist. + +Terminate both nodes. +Then, in one terminal start the ``listener`` example node. + +.. code-block:: console + + $ ros2 run demo_nodes_py listener + +In the other terminal, use ``ros2 bag`` to play the bag recorded by your node. + +.. code-block:: console + + $ ros2 bag play my_bag + +You will see the messages from the bag being received by the ``listener`` node. + +If you wish to run the bag-writing node again, you will first need to delete the ``my_bag`` directory. + +4 Record synthetic data from a node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Any data can be recorded into a bag, not just data received over a topic. +A common use case for writing to a bag from your own node is to generate and store synthetic data. +In this section you will learn how to write a node that generates some data and stores it in a bag. +We will demonstrate two approaches for doing this. +The first uses a node with a timer; this is the approach that you would use if your data generation is external to the node, such as reading data directly from hardware (e.g. a camera). +The second approach does not use a node; this is the approach you can use when you do not need to use any functionality from the ROS infrastructure. + +4.1 Write a Python node +~~~~~~~~~~~~~~~~~~~~~~~ + +Inside the ``ros2_ws/src/bag_recorder_nodes_py/bag_recorder_nodes_py`` directory, create a new file called ``data_generator_node.py`` and paste the following code into it. + +.. code-block:: Python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + from rclpy.serialization import serialize_message + from example_interfaces.msg import Int32 + + import rosbag2_py + + class DataGeneratorNode(Node): + def __init__(self): + super().__init__('data_generator_node') + self.data = Int32() + self.data.data = 0 + self.writer = rosbag2_py.SequentialWriter() + + storage_options = rosbag2_py.StorageOptions( + uri='timed_synthetic_bag', + storage_id='mcap') + converter_options = rosbag2_py.ConverterOptions('', '') + self.writer.open(storage_options, converter_options) + + topic_info = rosbag2_py.TopicMetadata( + id=0, + name='synthetic', + type='example_interfaces/msg/Int32', + serialization_format='cdr') + self.writer.create_topic(topic_info) + + self.timer = self.create_timer(1, self.timer_callback) + + def timer_callback(self): + self.writer.write( + 'synthetic', + serialize_message(self.data), + self.get_clock().now().nanoseconds) + self.data.data += 1 + + + def main(args=None): + try: + with rclpy.init(args=args): + dgn = DataGeneratorNode() + rclpy.spin(dgn) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +4.2 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Much of this code is the same as the first example. +The important differences are described here. + +First, the name of the bag is changed. + +.. code-block:: Python + + storage_options = rosbag2_py.StorageOptions( + uri='timed_synthetic_bag', + storage_id='mcap') + +The name of the topic is also changed, as is the data type stored. + +.. code-block:: Python + + topic_info = rosbag2_py.TopicMetadata( + id=0, + name='synthetic', + type='example_interfaces/msg/Int32', + serialization_format='cdr') + self.writer.create_topic(topic_info) + +Rather than a subscription to a topic, this node has a timer. +The timer fires with a one-second period, and calls the given member function when it does. + +.. code-block:: Python + + self.timer = self.create_timer(1, self.timer_callback) + +Within the timer callback, we generate (or otherwise obtain, e.g. read from a serial port connected to some hardware) the data we wish to store in the bag. +As with the previous example, the data is not yet serialized, so we must serialize it before passing it to the writer. + +.. code-block:: Python + + self.writer.write( + 'synthetic', + serialize_message(self.data), + self.get_clock().now().nanoseconds) + +4.3 Add executable +~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file in the ``bag_recorder_nodes_py`` package and add an entry point for your node. + +.. code-block:: Python + + entry_points={ + 'console_scripts': [ + 'simple_bag_recorder = bag_recorder_nodes_py.simple_bag_recorder:main', + 'data_generator_node = bag_recorder_nodes_py.data_generator_node:main', + ], + }, + +4.4 Build and run +~~~~~~~~~~~~~~~~~ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_recorder_nodes_py + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +If the ``timed_synthetic_bag`` directory already exists, you must first delete it before running the node. + +Now run the node: + +.. code-block:: console + + $ ros2 run bag_recorder_nodes_py data_generator_node + +Wait for 30 seconds or so, then terminate the node with :kbd:`ctrl-c`. +Next, play back the created bag. + +.. code-block:: console + + $ ros2 bag play timed_synthetic_bag + +Open a second terminal and echo the ``/synthetic`` topic. + +.. code-block:: console + + $ ros2 topic echo /synthetic + +You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. + +5 Record synthetic data from an executable +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now that you can create a bag that stores data from a source other than a topic, you will learn how to generate and record synthetic data from a non-node executable. +The advantage of this approach is simpler code and rapid creation of a large quantity of data. + +5.1 Write a Python executable +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Inside the ``ros2_ws/src/bag_recorder_nodes_py/bag_recorder_nodes_py`` directory, create a new file called ``data_generator_executable.py`` and paste the following code into it. + +.. code-block:: Python + + from rclpy.clock import Clock + from rclpy.duration import Duration + from rclpy.serialization import serialize_message + from example_interfaces.msg import Int32 + + import rosbag2_py + + + def main(args=None): + writer = rosbag2_py.SequentialWriter() + + storage_options = rosbag2_py.StorageOptions( + uri='big_synthetic_bag', + storage_id='mcap') + converter_options = rosbag2_py.ConverterOptions('', '') + writer.open(storage_options, converter_options) + + topic_info = rosbag2_py.TopicMetadata( + id=0, + name='synthetic', + type='example_interfaces/msg/Int32', + serialization_format='cdr') + writer.create_topic(topic_info) + + time_stamp = Clock().now() + for ii in range(0, 100): + data = Int32() + data.data = ii + writer.write( + 'synthetic', + serialize_message(data), + time_stamp.nanoseconds) + time_stamp += Duration(seconds=1) + + if __name__ == '__main__': + main() + +5.2 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +A comparison of this sample and the previous sample will reveal that they are not that different. +The only significant difference is the use of a for loop to drive the data generation rather than a timer. + +Notice that we are also now generating time stamps for the data rather than relying on the current system time for each sample. +The time stamp can be any value you need it to be. +The data will be played back at the rate given by these time stamps, so this is a useful way to control the default playback speed of the samples. +Notice also that while the gap between each sample is a full second in time, this executable does not need to wait a second between each sample. +This allows us to generate a lot of data covering a wide span of time in much less time than playback will take. + +.. code-block:: Python + + time_stamp = Clock().now() + for ii in range(0, 100): + data = Int32() + data.data = ii + writer.write( + 'synthetic', + serialize_message(data), + time_stamp.nanoseconds) + time_stamp += Duration(seconds=1) + +5.3 Add executable +~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file in the ``bag_recorder_nodes_py`` package and add an entry point for your node. + +.. code-block:: Python + + entry_points={ + 'console_scripts': [ + 'simple_bag_recorder = bag_recorder_nodes_py.simple_bag_recorder:main', + 'data_generator_node = bag_recorder_nodes_py.data_generator_node:main', + 'data_generator_executable = bag_recorder_nodes_py.data_generator_executable:main', + ], + }, + +5.4 Build and run +~~~~~~~~~~~~~~~~~ + +Navigate back to the root of your workspace, ``ros2_ws``, and build your package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select bag_recorder_nodes_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select bag_recorder_nodes_py + +Open a terminal, navigate to ``ros2_ws``, and source the setup files. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +If the ``big_synthetic_bag`` directory already exists, you must first delete it before running the executable. + +Now run the executable: + +.. code-block:: console + + $ ros2 run bag_recorder_nodes_py data_generator_executable + +Note that the executable runs and finishes very quickly. + +Now play back the created bag. + +.. code-block:: console + + $ ros2 bag play big_synthetic_bag + +Open a second terminal and echo the ``/synthetic`` topic. + +.. code-block:: console + + $ ros2 topic echo /synthetic + +You will see the data that was generated and stored in the bag printed to the console at a rate of one message per second. +Even though the bag was generated rapidly it is still played back at the rate the time stamps indicate. + +Summary +------- + +You created a node that records data it receives on a topic into a bag. +You tested recording a bag using the node, and verified the data was recorded by playing back the bag. +This approach can be used to record a bag with additional data than it received over a topic, for example with results obtained from processing the received data. +You then went on to create a node and an executable to generate synthetic data and store it in a bag. +The latter approaches are useful especially for generating synthetic data that can be used, for example, as training sets. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst index b3fb4bcceef..addea48c263 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst @@ -1,207 +1,208 @@ -.. redirect-from:: - - Tutorials/Rosdep - -Managing Dependencies with rosdep -================================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -**Goal:** Manage external dependencies using ``rosdep``. - -**Tutorial level:** Intermediate - -**Time:** 5 minutes - -This tutorial will explain how to manage external dependencies using ``rosdep``. - -.. warning:: - - Currently rosdep only works on Linux and macOS; Windows is not supported. - There are long-term plans to add support for Windows to https://github.com/ros-infrastructure/rosdep. - -What is rosdep? ---------------- - -``rosdep`` is a dependency management utility that can work with packages and external libraries. -It is a command-line utility for identifying and installing dependencies to build or install a package. -``rosdep`` is *not* a package manager in its own right; it is a meta-package manager that uses its own knowledge of the system and the dependencies to find the appropriate package to install on a particular platform. -The actual installation is done using the system package manager (e.g. ``apt`` on Debian/Ubuntu, ``dnf`` on Fedora/RHEL, etc). - -It is most often invoked before building a workspace, where it is used to install the dependencies of the packages within that workspace. - -It has the ability to work over a single package or over a directory of packages (e.g. workspace). - -.. note:: - - While the name suggests it is for ROS, ``rosdep`` is semi-agnostic to ROS. - You can utilize this powerful tool in non-ROS software projects by installing it as a standalone Python package. - Successfully running ``rosdep`` relies on ``rosdep keys`` to be available, which can be downloaded from a public git repository with a few simple commands. - -A little about package.xml files --------------------------------- - -The ``package.xml`` is the file in your software where ``rosdep`` finds the set of dependencies. -It is important that the list of dependencies in the ``package.xml`` is complete and correct, which allows all of the tooling to determine the packages dependencies. -Missing or incorrect dependencies can lead to users not being able to use your package, to packages in a workspace being built out-of-order, and to packages not being able to be released. - -The dependencies in the ``package.xml`` file are generally referred to as "rosdep keys". -These dependencies are manually populated in the ``package.xml`` file by the package's creators and should be an exhaustive list of any non-builtin libraries and packages it requires. - -These are represented in the following tags (see `REP-149 `__ for the full specification): - -```` -^^^^^^^^^^^^ - -These are dependencies that should be provided at both build time and run time for your package. -For C++ packages, if in doubt, use this tag. -Pure Python packages generally don't have a build phase, so should never use this and should use ```` instead. - -```` -^^^^^^^^^^^^^^^^^^ - -If you only use a particular dependency for building your package, and not at execution time, you can use the ```` tag. - -With this type of dependency, an installed binary of your package does not require that particular package to be installed. - -However, that can create a problem if your package exports a header that includes a header from this dependency. -In that case you also need a ````. - -```` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you export a header that includes a header from a dependency, it will be needed by other packages that ```` on yours. -This mainly applies to headers and CMake configuration files. -Library packages referenced by libraries you export should normally specify ````, because they are also needed at execution time. - -```` -^^^^^^^^^^^^^^^^^ - -This tag declares dependencies for shared libraries, executables, Python modules, launch scripts and other files required when running your package. - -```` -^^^^^^^^^^^^^^^^^ - -This tag declares dependencies needed only by tests. -Dependencies here should *not* be duplicated with keys specified by ````, ````, or ````. - -How does rosdep work? ---------------------- - -``rosdep`` will check for ``package.xml`` files in its path or for a specific package and find the rosdep keys stored within. -These keys are then cross-referenced against a central index to find the appropriate ROS package or software library in various package managers. -Finally, once the packages are found, they are installed and ready to go! - -``rosdep`` works by retrieving the central index on to your local machine so that it doesn't have to access the network every time it runs (on Debian/Ubuntu the configuration for it is stored in ``/etc/ros/rosdep/sources.list.d/20-default.list``). - -The central index is known as ``rosdistro``, which `may be found online `_. -We'll explore that more in the next section. - -How do I know what keys to put in my package.xml? -------------------------------------------------- - -Great question, I'm glad you asked! - -* If the package you want to depend in your package is ROS-based, AND has been released into the ROS ecosystem [1]_, e.g. ``nav2_bt_navigator``, you may simply use the name of the package. - You can find a list of all released ROS packages in https://github.com/ros/rosdistro at ``/distribution.yaml`` (e.g. ``humble/distribution.yaml``) for your given ROS distribution. -* If you want to depend on a non-ROS package, something often called "system dependencies", you will need to find the keys for a particular library. - In general, there are two files of interest: - - * `rosdep/base.yaml `_ contains the ``apt`` system dependencies - * `rosdep/python.yaml `_ contains the Python dependencies - -To find a key, search for your library in these files and find the name. -This is the key to put in a ``package.xml`` file. - -For example, imagine a package had a dependency on ``doxygen`` because it is a great piece of software that cares about quality documentation (hint hint). -We would search ``rosdep/base.yaml`` for ``doxygen`` and come across: - -.. code-block:: yaml - - doxygen: - arch: [doxygen] - debian: [doxygen] - fedora: [doxygen] - freebsd: [doxygen] - gentoo: [app-doc/doxygen] - macports: [doxygen] - nixos: [doxygen] - openembedded: [doxygen@meta-oe] - opensuse: [doxygen] - rhel: [doxygen] - ubuntu: [doxygen] - -That means our rosdep key is ``doxygen``, which would resolve to those various names in different operating system's package managers for installation. - -What if my library isn't in rosdistro? --------------------------------------- - -If your library isn't in ``rosdistro``, you can experience the greatness that is open-source software development: you can add it yourself! -Pull requests for rosdistro are typically merged well within a week. - -`Detailed instructions may be found here `_ for how to contribute new rosdep keys. -If for some reason these may not be contributed openly, other options exist: - -1. Forking rosdistro and maintaining a alternate index containing the extra keys (:doc:`../../How-To-Guides/Using-Custom-Rosdistro`) -2. Creating a new file containing custom keys and instructing ``rosdep`` to check it when populating the local index (:doc:`../Advanced/Supplementing-Custom-Rosdep-Keys`) - -How do I use the rosdep tool? ------------------------------ - -rosdep installation -^^^^^^^^^^^^^^^^^^^ - -If you are using ``rosdep`` with ROS, it is conveniently packaged along with the ROS distribution. -This is the recommended way to get ``rosdep``. -You can install it with: - -.. code-block:: console - - $ apt-get install python3-rosdep - -.. note:: - - On Debian and Ubuntu, there is another, similarly named package called ``python3-rosdep2``. - If that package is installed, make sure to remove it before installing ``python3-rosdep``. - -If you are using ``rosdep`` outside of ROS, the system package may not be available. -In that case, you can install it directly from https://pypi.org: - -.. code-block:: console - - $ pip install rosdep - -rosdep operation -^^^^^^^^^^^^^^^^ - -Now that we have some understanding of ``rosdep``, ``package.xml``, and ``rosdistro``, we're ready to use the utility itself! -Firstly, if this is the first time using ``rosdep``, it must be initialized via: - -.. code-block:: console - - $ sudo rosdep init - $ rosdep update - -This will initialize rosdep and ``update`` will update the locally cached rosdistro index. -It is a good idea to ``update`` rosdep on occasion to get the latest index. - -Finally, we can run ``rosdep install`` to install dependencies. -Typically, this is run over a workspace with many packages in a single call to install all dependencies. -A call for that would appear as the following, if in the root of the workspace with directory ``src`` containing source code. - -.. code-block:: console - - $ rosdep install --from-paths src -y --ignore-src - -Breaking that down: - -- ``--from-paths src`` specifies the path to check for ``package.xml`` files to resolve keys for -- ``-y`` means to default yes to all prompts from the package manager to install without prompts -- ``--ignore-src`` means to ignore installing dependencies, even if a rosdep key exists, if the package itself is also in the workspace. - -There are additional arguments and options available. -Use ``rosdep -h`` to see them, or look at the more complete documentation for rosdep at http://docs.ros.org/en/independent/api/rosdep/html/ . - -.. [1] "released into the ROS ecosystem" means the package is listed in one or more of the ``/distribution.yaml`` directories in the `rosdistro database `_. +.. redirect-from:: + + Tutorials/Rosdep + Tutorials/Intermediate/Rosdep + +Managing Dependencies with rosdep +================================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +**Goal:** Manage external dependencies using ``rosdep``. + +**Tutorial level:** Intermediate + +**Time:** 5 minutes + +This tutorial will explain how to manage external dependencies using ``rosdep``. + +.. warning:: + + Currently rosdep only works on Linux and macOS; Windows is not supported. + There are long-term plans to add support for Windows to https://github.com/ros-infrastructure/rosdep. + +What is rosdep? +--------------- + +``rosdep`` is a dependency management utility that can work with packages and external libraries. +It is a command-line utility for identifying and installing dependencies to build or install a package. +``rosdep`` is *not* a package manager in its own right; it is a meta-package manager that uses its own knowledge of the system and the dependencies to find the appropriate package to install on a particular platform. +The actual installation is done using the system package manager (e.g. ``apt`` on Debian/Ubuntu, ``dnf`` on Fedora/RHEL, etc). + +It is most often invoked before building a workspace, where it is used to install the dependencies of the packages within that workspace. + +It has the ability to work over a single package or over a directory of packages (e.g. workspace). + +.. note:: + + While the name suggests it is for ROS, ``rosdep`` is semi-agnostic to ROS. + You can utilize this powerful tool in non-ROS software projects by installing it as a standalone Python package. + Successfully running ``rosdep`` relies on ``rosdep keys`` to be available, which can be downloaded from a public git repository with a few simple commands. + +A little about package.xml files +-------------------------------- + +The ``package.xml`` is the file in your software where ``rosdep`` finds the set of dependencies. +It is important that the list of dependencies in the ``package.xml`` is complete and correct, which allows all of the tooling to determine the packages dependencies. +Missing or incorrect dependencies can lead to users not being able to use your package, to packages in a workspace being built out-of-order, and to packages not being able to be released. + +The dependencies in the ``package.xml`` file are generally referred to as "rosdep keys". +These dependencies are manually populated in the ``package.xml`` file by the package's creators and should be an exhaustive list of any non-builtin libraries and packages it requires. + +These are represented in the following tags (see `REP-149 `__ for the full specification): + +```` +^^^^^^^^^^^^ + +These are dependencies that should be provided at both build time and run time for your package. +For C++ packages, if in doubt, use this tag. +Pure Python packages generally don't have a build phase, so should never use this and should use ```` instead. + +```` +^^^^^^^^^^^^^^^^^^ + +If you only use a particular dependency for building your package, and not at execution time, you can use the ```` tag. + +With this type of dependency, an installed binary of your package does not require that particular package to be installed. + +However, that can create a problem if your package exports a header that includes a header from this dependency. +In that case you also need a ````. + +```` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you export a header that includes a header from a dependency, it will be needed by other packages that ```` on yours. +This mainly applies to headers and CMake configuration files. +Library packages referenced by libraries you export should normally specify ````, because they are also needed at execution time. + +```` +^^^^^^^^^^^^^^^^^ + +This tag declares dependencies for shared libraries, executables, Python modules, launch scripts and other files required when running your package. + +```` +^^^^^^^^^^^^^^^^^ + +This tag declares dependencies needed only by tests. +Dependencies here should *not* be duplicated with keys specified by ````, ````, or ````. + +How does rosdep work? +--------------------- + +``rosdep`` will check for ``package.xml`` files in its path or for a specific package and find the rosdep keys stored within. +These keys are then cross-referenced against a central index to find the appropriate ROS package or software library in various package managers. +Finally, once the packages are found, they are installed and ready to go! + +``rosdep`` works by retrieving the central index on to your local machine so that it doesn't have to access the network every time it runs (on Debian/Ubuntu the configuration for it is stored in ``/etc/ros/rosdep/sources.list.d/20-default.list``). + +The central index is known as ``rosdistro``, which `may be found online `_. +We'll explore that more in the next section. + +How do I know what keys to put in my package.xml? +------------------------------------------------- + +Great question, I'm glad you asked! + +* If the package you want to depend in your package is ROS-based, AND has been released into the ROS ecosystem [1]_, e.g. ``nav2_bt_navigator``, you may simply use the name of the package. + You can find a list of all released ROS packages in https://github.com/ros/rosdistro at ``/distribution.yaml`` (e.g. ``humble/distribution.yaml``) for your given ROS distribution. +* If you want to depend on a non-ROS package, something often called "system dependencies", you will need to find the keys for a particular library. + In general, there are two files of interest: + + * `rosdep/base.yaml `_ contains the ``apt`` system dependencies + * `rosdep/python.yaml `_ contains the Python dependencies + +To find a key, search for your library in these files and find the name. +This is the key to put in a ``package.xml`` file. + +For example, imagine a package had a dependency on ``doxygen`` because it is a great piece of software that cares about quality documentation (hint hint). +We would search ``rosdep/base.yaml`` for ``doxygen`` and come across: + +.. code-block:: yaml + + doxygen: + arch: [doxygen] + debian: [doxygen] + fedora: [doxygen] + freebsd: [doxygen] + gentoo: [app-doc/doxygen] + macports: [doxygen] + nixos: [doxygen] + openembedded: [doxygen@meta-oe] + opensuse: [doxygen] + rhel: [doxygen] + ubuntu: [doxygen] + +That means our rosdep key is ``doxygen``, which would resolve to those various names in different operating system's package managers for installation. + +What if my library isn't in rosdistro? +-------------------------------------- + +If your library isn't in ``rosdistro``, you can experience the greatness that is open-source software development: you can add it yourself! +Pull requests for rosdistro are typically merged well within a week. + +`Detailed instructions may be found here `_ for how to contribute new rosdep keys. +If for some reason these may not be contributed openly, other options exist: + +1. Forking rosdistro and maintaining a alternate index containing the extra keys (:doc:`../../../Migration-and-Upgrades/Using-Custom-Rosdistro`) +2. Creating a new file containing custom keys and instructing ``rosdep`` to check it when populating the local index (:doc:`../../../Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys`) + +How do I use the rosdep tool? +----------------------------- + +rosdep installation +^^^^^^^^^^^^^^^^^^^ + +If you are using ``rosdep`` with ROS, it is conveniently packaged along with the ROS distribution. +This is the recommended way to get ``rosdep``. +You can install it with: + +.. code-block:: console + + $ apt-get install python3-rosdep + +.. note:: + + On Debian and Ubuntu, there is another, similarly named package called ``python3-rosdep2``. + If that package is installed, make sure to remove it before installing ``python3-rosdep``. + +If you are using ``rosdep`` outside of ROS, the system package may not be available. +In that case, you can install it directly from https://pypi.org: + +.. code-block:: console + + $ pip install rosdep + +rosdep operation +^^^^^^^^^^^^^^^^ + +Now that we have some understanding of ``rosdep``, ``package.xml``, and ``rosdistro``, we're ready to use the utility itself! +Firstly, if this is the first time using ``rosdep``, it must be initialized via: + +.. code-block:: console + + $ sudo rosdep init + $ rosdep update + +This will initialize rosdep and ``update`` will update the locally cached rosdistro index. +It is a good idea to ``update`` rosdep on occasion to get the latest index. + +Finally, we can run ``rosdep install`` to install dependencies. +Typically, this is run over a workspace with many packages in a single call to install all dependencies. +A call for that would appear as the following, if in the root of the workspace with directory ``src`` containing source code. + +.. code-block:: console + + $ rosdep install --from-paths src -y --ignore-src + +Breaking that down: + +- ``--from-paths src`` specifies the path to check for ``package.xml`` files to resolve keys for +- ``-y`` means to default yes to all prompts from the package manager to install without prompts +- ``--ignore-src`` means to ignore installing dependencies, even if a rosdep key exists, if the package itself is also in the workspace. + +There are additional arguments and options available. +Use ``rosdep -h`` to see them, or look at the more complete documentation for rosdep at http://docs.ros.org/en/independent/api/rosdep/html/ . + +.. [1] "released into the ROS ecosystem" means the package is listed in one or more of the ``/distribution.yaml`` directories in the `rosdistro database `_. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst index e3e406d6378..187cf8043e5 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst @@ -1,471 +1,472 @@ -.. _SinglePkgInterface: - -.. redirect-from:: - - Rosidl-Tutorial - Tutorials/Single-Package-Define-And-Use-Interface - -Implementing custom interfaces -============================== - -**Goal:** Learn more ways to implement custom interfaces in ROS 2. - -**Tutorial level:** Beginner - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In a :doc:`previous tutorial <./Custom-ROS2-Interfaces>`, you learned how to create custom msg and srv interfaces. - -While best practice is to declare interfaces in dedicated interface packages, sometimes it can be convenient to declare, create and use an interface all in one package. - -Recall that interfaces can currently only be defined in CMake packages. -It is possible, however, to have Python libraries and nodes in CMake packages (using `ament_cmake_python `_), so you could define interfaces and Python nodes together in one package. -We'll use a CMake package and C++ nodes here for the sake of simplicity. - -This tutorial will focus on the msg interface type, but the steps here are applicable to all interface types. - -Prerequisites -------------- - -We assume you've reviewed the basics in the :doc:`./Custom-ROS2-Interfaces` tutorial before working through this one. - -You should have :doc:`ROS 2 installed <../../Installation>`, a :doc:`workspace <./Creating-A-Workspace/Creating-A-Workspace>`, and an understanding of :doc:`creating packages <./Creating-Your-First-ROS2-Package>`. - -As always, don't forget to :doc:`source ROS 2 <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` in every new terminal you open. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -In your workspace ``src`` directory, create a package ``more_interfaces`` and make a directory within it for msg files: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 more_interfaces - $ mkdir more_interfaces/msg - -2 Create a msg file -^^^^^^^^^^^^^^^^^^^ - -Inside ``more_interfaces/msg``, create a new file ``AddressBook.msg``, and paste the following code to create a message meant to carry information about an individual: - -:: - - uint8 PHONE_TYPE_HOME=0 - uint8 PHONE_TYPE_WORK=1 - uint8 PHONE_TYPE_MOBILE=2 - - string first_name - string last_name - string phone_number - uint8 phone_type - -This message is composed of these fields: - -* first_name: of type string -* last_name: of type string -* phone_number: of type string -* phone_type: of type uint8, with several named constant values defined - -Note that it's possible to set default values for fields within a message definition. -See :doc:`../../Concepts/Basic/About-Interfaces` for more ways you can customize interfaces. - -Next, we need to make sure that the msg file is turned into source code for C++, Python, and other languages. - -2.1 Build a msg file -~~~~~~~~~~~~~~~~~~~~ - -Open ``package.xml`` and add the following lines: - -.. code-block:: xml - - rosidl_default_generators - - rosidl_default_runtime - - rosidl_interface_packages - -Note that at build time, we need ``rosidl_default_generators``, while at runtime, we only need ``rosidl_default_runtime``. - -Open ``CMakeLists.txt`` and add the following lines: - -Find the package that generates message code from msg/srv files: - -.. code-block:: cmake - - find_package(rosidl_default_generators REQUIRED) - -Declare the list of messages you want to generate: - -.. code-block:: cmake - - set(msg_files - "msg/AddressBook.msg" - ) - -By adding the .msg files manually, we make sure that CMake knows when it has to reconfigure the project after you add other .msg files. - -Generate the messages: - -.. code-block:: cmake - - rosidl_generate_interfaces(${PROJECT_NAME} - ${msg_files} - ) - -Also make sure you export the message runtime dependency: - -.. code-block:: cmake - - ament_export_dependencies(rosidl_default_runtime) - -Now you're ready to generate source files from your msg definition. -We'll skip the compile step for now as we'll do it all together below in step 4. - -3 Use an interface from the same package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now we can start writing code that uses this message. - -In ``more_interfaces/src`` create a file called ``publish_address_book.cpp`` and paste the following code: - -.. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "more_interfaces/msg/address_book.hpp" - - using namespace std::chrono_literals; - - class AddressBookPublisher : public rclcpp::Node - { - public: - AddressBookPublisher() - : Node("address_book_publisher") - { - address_book_publisher_ = - this->create_publisher("address_book", 10); - - auto publish_msg = [this]() -> void { - auto message = more_interfaces::msg::AddressBook(); - - message.first_name = "John"; - message.last_name = "Doe"; - message.phone_number = "1234567890"; - message.phone_type = message.PHONE_TYPE_MOBILE; - - std::cout << "Publishing Contact\nFirst:" << message.first_name << - " Last:" << message.last_name << std::endl; - - this->address_book_publisher_->publish(message); - }; - timer_ = this->create_wall_timer(1s, publish_msg); - } - - private: - rclcpp::Publisher::SharedPtr address_book_publisher_; - rclcpp::TimerBase::SharedPtr timer_; - }; - - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - - return 0; - } - -3.1 The code explained -~~~~~~~~~~~~~~~~~~~~~~ - -Include the header of our newly created ``AddressBook.msg``. - -.. code-block:: c++ - - #include "more_interfaces/msg/address_book.hpp" - -Create a node and an ``AddressBook`` publisher. - -.. code-block:: c++ - - using namespace std::chrono_literals; - - class AddressBookPublisher : public rclcpp::Node - { - public: - AddressBookPublisher() - : Node("address_book_publisher") - { - address_book_publisher_ = - this->create_publisher("address_book"); - -Create a callback to publish the messages periodically. - -.. code-block:: c++ - - auto publish_msg = [this]() -> void { - -Create an ``AddressBook`` message instance that we will later publish. - -.. code-block:: c++ - - auto message = more_interfaces::msg::AddressBook(); - -Populate ``AddressBook`` fields. - -.. code-block:: c++ - - message.first_name = "John"; - message.last_name = "Doe"; - message.phone_number = "1234567890"; - message.phone_type = message.PHONE_TYPE_MOBILE; - -Finally send the message periodically. - -.. code-block:: c++ - - std::cout << "Publishing Contact\nFirst:" << message.first_name << - " Last:" << message.last_name << std::endl; - - this->address_book_publisher_->publish(message); - -Create a 1 second timer to call our ``publish_msg`` function every second. - -.. code-block:: c++ - - timer_ = this->create_wall_timer(1s, publish_msg); - -3.2 Build the publisher -~~~~~~~~~~~~~~~~~~~~~~~ - -We need to create a new target for this node in the ``CMakeLists.txt``: - -.. code-block:: cmake - - find_package(rclcpp REQUIRED) - - add_executable(publish_address_book src/publish_address_book.cpp) - target_link_libraries(publish_address_book rclcpp::rclcpp) - - install(TARGETS - publish_address_book - DESTINATION lib/${PROJECT_NAME}) - -3.3 Link against the interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to use the messages generated in the same package we need to use the following CMake code: - -.. code-block:: cmake - - rosidl_get_typesupport_target(cpp_typesupport_target - ${PROJECT_NAME} rosidl_typesupport_cpp) - - target_link_libraries(publish_address_book "${cpp_typesupport_target}") - -This finds the relevant generated C++ code from ``AddressBook.msg`` and allows your target to link against it. - -You may have noticed that this step was not necessary when the interfaces being used were from a different package that was built independently. -This CMake code is only required when you want to use interfaces in the same package as the one in which they are defined. - -4 Try it out -^^^^^^^^^^^^ - -Return to the root of the workspace to build the package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws - $ colcon build --packages-up-to more_interfaces - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws - $ colcon build --packages-up-to more_interfaces - - .. group-tab:: Windows - - .. code-block:: console - - $ cd /ros2_ws - $ colcon build --merge-install --packages-up-to more_interfaces - -Then source the workspace and run the publisher: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/local_setup.bash - $ ros2 run more_interfaces publish_address_book - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/local_setup.bash - $ ros2 run more_interfaces publish_address_book - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/local_setup.bat - $ ros2 run more_interfaces publish_address_book - - Or using Powershell: - - .. code-block:: console - - $ install/local_setup.ps1 - $ ros2 run more_interfaces publish_address_book - -You should see the publisher relaying the msg you defined, including the values you set in ``publish_address_book.cpp``. - -To confirm the message is being published on the ``address_book`` topic, open another terminal, source the workspace, and call ``topic echo``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - $ ros2 topic echo /address_book - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - $ ros2 topic echo /address_book - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - $ ros2 topic echo /address_book - - Or using Powershell: - - .. code-block:: console - - $ install/setup.ps1 - $ ros2 topic echo /address_book - -We won't create a subscriber in this tutorial, but you can try to write one yourself for practice (use :doc:`./Writing-A-Simple-Cpp-Publisher-And-Subscriber` to help). - -5 (Extra) Use an existing interface definition -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. note:: - - You can use an existing interface definition in a new interface definition. - For example, let's say there is a message named ``Contact.msg`` that belongs to an existing ROS 2 package named ``rosidl_tutorials_msgs``. - Assume that its definition is identical to our custom-made ``AddressBook.msg`` interface from earlier. - - In that case you could have defined ``AddressBook.msg`` (an interface in the package *with* your nodes) as type ``Contact`` (an interface in a *separate* package). - You could even define ``AddressBook.msg`` as an *array* of type ``Contact``, like so: - - :: - - rosidl_tutorials_msgs/Contact[] address_book - - To generate this message you would need to declare a dependency on ``Contact.msg's`` package, ``rosidl_tutorials_msgs``, in ``package.xml``: - - .. code-block:: xml - - rosidl_tutorials_msgs - - rosidl_tutorials_msgs - - And in ``CMakeLists.txt``: - - .. code-block:: cmake - - find_package(rosidl_tutorials_msgs REQUIRED) - - rosidl_generate_interfaces(${PROJECT_NAME} - ${msg_files} - DEPENDENCIES rosidl_tutorials_msgs - ) - - You would also need to include the header of ``Contact.msg`` in your publisher node in order to be able to add ``contacts`` to your ``address_book``. - - .. code-block:: c++ - - #include "rosidl_tutorials_msgs/msg/contact.hpp" - - You could change the callback to something like this: - - .. code-block:: c++ - - auto publish_msg = [this]() -> void { - auto msg = std::make_shared(); - { - rosidl_tutorials_msgs::msg::Contact contact; - contact.first_name = "John"; - contact.last_name = "Doe"; - contact.phone_number = "1234567890"; - contact.phone_type = contact.PHONE_TYPE_MOBILE; - msg->address_book.push_back(contact); - } - { - rosidl_tutorials_msgs::msg::Contact contact; - contact.first_name = "Jane"; - contact.last_name = "Doe"; - contact.phone_number = "4254242424"; - contact.phone_type = contact.PHONE_TYPE_HOME; - msg->address_book.push_back(contact); - } - - std::cout << "Publishing address book:" << std::endl; - for (auto contact : msg->address_book) { - std::cout << "First:" << contact.first_name << " Last:" << contact.last_name << - std::endl; - } - - address_book_publisher_->publish(*msg); - }; - - Building and running these changes would show the msg defined as expected, as well as the array of msgs defined above. - -Summary -------- - -In this tutorial, you tried out different field types for defining interfaces, then built an interface in the same package where it's being used. - -You also learned how to use another interface as a field type, as well as the ``package.xml``, ``CMakeLists.txt``, and ``#include`` statements necessary for utilizing that feature. - -Next steps ----------- - -Next you will create a simple ROS 2 package with a custom parameter that you will learn to set from a launch file. -Again, you can choose to write it in either :doc:`C++ <./Using-Parameters-In-A-Class-CPP>` or :doc:`Python <./Using-Parameters-In-A-Class-Python>`. - -Related content ---------------- - -There are `several design articles `_ on ROS 2 interfaces and the IDL (interface definition language). +.. _SinglePkgInterface: + +.. redirect-from:: + + Rosidl-Tutorial + Tutorials/Single-Package-Define-And-Use-Interface + Tutorials/Beginner-Client-Libraries/Single-Package-Define-And-Use-Interface + +Implementing custom interfaces +============================== + +**Goal:** Learn more ways to implement custom interfaces in ROS 2. + +**Tutorial level:** Beginner + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In a :doc:`previous tutorial `, you learned how to create custom msg and srv interfaces. + +While best practice is to declare interfaces in dedicated interface packages, sometimes it can be convenient to declare, create and use an interface all in one package. + +Recall that interfaces can currently only be defined in CMake packages. +It is possible, however, to have Python libraries and nodes in CMake packages (using `ament_cmake_python `_), so you could define interfaces and Python nodes together in one package. +We'll use a CMake package and C++ nodes here for the sake of simplicity. + +This tutorial will focus on the msg interface type, but the steps here are applicable to all interface types. + +Prerequisites +------------- + +We assume you've reviewed the basics in the :doc:`Custom-ROS2-Interfaces` tutorial before working through this one. + +You should have :doc:`ROS 2 installed <../../../Get-Started/Installation>`, a :doc:`workspace `, and an understanding of :doc:`creating packages `. + +As always, don't forget to :doc:`source ROS 2 <../../../Get-Started/Configuring-ROS2-Environment>` in every new terminal you open. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +In your workspace ``src`` directory, create a package ``more_interfaces`` and make a directory within it for msg files: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 more_interfaces + $ mkdir more_interfaces/msg + +2 Create a msg file +^^^^^^^^^^^^^^^^^^^ + +Inside ``more_interfaces/msg``, create a new file ``AddressBook.msg``, and paste the following code to create a message meant to carry information about an individual: + +:: + + uint8 PHONE_TYPE_HOME=0 + uint8 PHONE_TYPE_WORK=1 + uint8 PHONE_TYPE_MOBILE=2 + + string first_name + string last_name + string phone_number + uint8 phone_type + +This message is composed of these fields: + +* first_name: of type string +* last_name: of type string +* phone_number: of type string +* phone_type: of type uint8, with several named constant values defined + +Note that it's possible to set default values for fields within a message definition. +See :doc:`../../About-Interfaces` for more ways you can customize interfaces. + +Next, we need to make sure that the msg file is turned into source code for C++, Python, and other languages. + +2.1 Build a msg file +~~~~~~~~~~~~~~~~~~~~ + +Open ``package.xml`` and add the following lines: + +.. code-block:: xml + + rosidl_default_generators + + rosidl_default_runtime + + rosidl_interface_packages + +Note that at build time, we need ``rosidl_default_generators``, while at runtime, we only need ``rosidl_default_runtime``. + +Open ``CMakeLists.txt`` and add the following lines: + +Find the package that generates message code from msg/srv files: + +.. code-block:: cmake + + find_package(rosidl_default_generators REQUIRED) + +Declare the list of messages you want to generate: + +.. code-block:: cmake + + set(msg_files + "msg/AddressBook.msg" + ) + +By adding the .msg files manually, we make sure that CMake knows when it has to reconfigure the project after you add other .msg files. + +Generate the messages: + +.. code-block:: cmake + + rosidl_generate_interfaces(${PROJECT_NAME} + ${msg_files} + ) + +Also make sure you export the message runtime dependency: + +.. code-block:: cmake + + ament_export_dependencies(rosidl_default_runtime) + +Now you're ready to generate source files from your msg definition. +We'll skip the compile step for now as we'll do it all together below in step 4. + +3 Use an interface from the same package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now we can start writing code that uses this message. + +In ``more_interfaces/src`` create a file called ``publish_address_book.cpp`` and paste the following code: + +.. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "more_interfaces/msg/address_book.hpp" + + using namespace std::chrono_literals; + + class AddressBookPublisher : public rclcpp::Node + { + public: + AddressBookPublisher() + : Node("address_book_publisher") + { + address_book_publisher_ = + this->create_publisher("address_book", 10); + + auto publish_msg = [this]() -> void { + auto message = more_interfaces::msg::AddressBook(); + + message.first_name = "John"; + message.last_name = "Doe"; + message.phone_number = "1234567890"; + message.phone_type = message.PHONE_TYPE_MOBILE; + + std::cout << "Publishing Contact\nFirst:" << message.first_name << + " Last:" << message.last_name << std::endl; + + this->address_book_publisher_->publish(message); + }; + timer_ = this->create_wall_timer(1s, publish_msg); + } + + private: + rclcpp::Publisher::SharedPtr address_book_publisher_; + rclcpp::TimerBase::SharedPtr timer_; + }; + + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + + return 0; + } + +3.1 The code explained +~~~~~~~~~~~~~~~~~~~~~~ + +Include the header of our newly created ``AddressBook.msg``. + +.. code-block:: c++ + + #include "more_interfaces/msg/address_book.hpp" + +Create a node and an ``AddressBook`` publisher. + +.. code-block:: c++ + + using namespace std::chrono_literals; + + class AddressBookPublisher : public rclcpp::Node + { + public: + AddressBookPublisher() + : Node("address_book_publisher") + { + address_book_publisher_ = + this->create_publisher("address_book"); + +Create a callback to publish the messages periodically. + +.. code-block:: c++ + + auto publish_msg = [this]() -> void { + +Create an ``AddressBook`` message instance that we will later publish. + +.. code-block:: c++ + + auto message = more_interfaces::msg::AddressBook(); + +Populate ``AddressBook`` fields. + +.. code-block:: c++ + + message.first_name = "John"; + message.last_name = "Doe"; + message.phone_number = "1234567890"; + message.phone_type = message.PHONE_TYPE_MOBILE; + +Finally send the message periodically. + +.. code-block:: c++ + + std::cout << "Publishing Contact\nFirst:" << message.first_name << + " Last:" << message.last_name << std::endl; + + this->address_book_publisher_->publish(message); + +Create a 1 second timer to call our ``publish_msg`` function every second. + +.. code-block:: c++ + + timer_ = this->create_wall_timer(1s, publish_msg); + +3.2 Build the publisher +~~~~~~~~~~~~~~~~~~~~~~~ + +We need to create a new target for this node in the ``CMakeLists.txt``: + +.. code-block:: cmake + + find_package(rclcpp REQUIRED) + + add_executable(publish_address_book src/publish_address_book.cpp) + target_link_libraries(publish_address_book rclcpp::rclcpp) + + install(TARGETS + publish_address_book + DESTINATION lib/${PROJECT_NAME}) + +3.3 Link against the interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to use the messages generated in the same package we need to use the following CMake code: + +.. code-block:: cmake + + rosidl_get_typesupport_target(cpp_typesupport_target + ${PROJECT_NAME} rosidl_typesupport_cpp) + + target_link_libraries(publish_address_book "${cpp_typesupport_target}") + +This finds the relevant generated C++ code from ``AddressBook.msg`` and allows your target to link against it. + +You may have noticed that this step was not necessary when the interfaces being used were from a different package that was built independently. +This CMake code is only required when you want to use interfaces in the same package as the one in which they are defined. + +4 Try it out +^^^^^^^^^^^^ + +Return to the root of the workspace to build the package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws + $ colcon build --packages-up-to more_interfaces + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws + $ colcon build --packages-up-to more_interfaces + + .. group-tab:: Windows + + .. code-block:: console + + $ cd /ros2_ws + $ colcon build --merge-install --packages-up-to more_interfaces + +Then source the workspace and run the publisher: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/local_setup.bash + $ ros2 run more_interfaces publish_address_book + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/local_setup.bash + $ ros2 run more_interfaces publish_address_book + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/local_setup.bat + $ ros2 run more_interfaces publish_address_book + + Or using Powershell: + + .. code-block:: console + + $ install/local_setup.ps1 + $ ros2 run more_interfaces publish_address_book + +You should see the publisher relaying the msg you defined, including the values you set in ``publish_address_book.cpp``. + +To confirm the message is being published on the ``address_book`` topic, open another terminal, source the workspace, and call ``topic echo``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + $ ros2 topic echo /address_book + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + $ ros2 topic echo /address_book + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + $ ros2 topic echo /address_book + + Or using Powershell: + + .. code-block:: console + + $ install/setup.ps1 + $ ros2 topic echo /address_book + +We won't create a subscriber in this tutorial, but you can try to write one yourself for practice (use :doc:`Writing-A-Simple-Cpp-Publisher-And-Subscriber` to help). + +5 (Extra) Use an existing interface definition +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. note:: + + You can use an existing interface definition in a new interface definition. + For example, let's say there is a message named ``Contact.msg`` that belongs to an existing ROS 2 package named ``rosidl_tutorials_msgs``. + Assume that its definition is identical to our custom-made ``AddressBook.msg`` interface from earlier. + + In that case you could have defined ``AddressBook.msg`` (an interface in the package *with* your nodes) as type ``Contact`` (an interface in a *separate* package). + You could even define ``AddressBook.msg`` as an *array* of type ``Contact``, like so: + + :: + + rosidl_tutorials_msgs/Contact[] address_book + + To generate this message you would need to declare a dependency on ``Contact.msg's`` package, ``rosidl_tutorials_msgs``, in ``package.xml``: + + .. code-block:: xml + + rosidl_tutorials_msgs + + rosidl_tutorials_msgs + + And in ``CMakeLists.txt``: + + .. code-block:: cmake + + find_package(rosidl_tutorials_msgs REQUIRED) + + rosidl_generate_interfaces(${PROJECT_NAME} + ${msg_files} + DEPENDENCIES rosidl_tutorials_msgs + ) + + You would also need to include the header of ``Contact.msg`` in your publisher node in order to be able to add ``contacts`` to your ``address_book``. + + .. code-block:: c++ + + #include "rosidl_tutorials_msgs/msg/contact.hpp" + + You could change the callback to something like this: + + .. code-block:: c++ + + auto publish_msg = [this]() -> void { + auto msg = std::make_shared(); + { + rosidl_tutorials_msgs::msg::Contact contact; + contact.first_name = "John"; + contact.last_name = "Doe"; + contact.phone_number = "1234567890"; + contact.phone_type = contact.PHONE_TYPE_MOBILE; + msg->address_book.push_back(contact); + } + { + rosidl_tutorials_msgs::msg::Contact contact; + contact.first_name = "Jane"; + contact.last_name = "Doe"; + contact.phone_number = "4254242424"; + contact.phone_type = contact.PHONE_TYPE_HOME; + msg->address_book.push_back(contact); + } + + std::cout << "Publishing address book:" << std::endl; + for (auto contact : msg->address_book) { + std::cout << "First:" << contact.first_name << " Last:" << contact.last_name << + std::endl; + } + + address_book_publisher_->publish(*msg); + }; + + Building and running these changes would show the msg defined as expected, as well as the array of msgs defined above. + +Summary +------- + +In this tutorial, you tried out different field types for defining interfaces, then built an interface in the same package where it's being used. + +You also learned how to use another interface as a field type, as well as the ``package.xml``, ``CMakeLists.txt``, and ``#include`` statements necessary for utilizing that feature. + +Next steps +---------- + +Next you will create a simple ROS 2 package with a custom parameter that you will learn to set from a launch file. +Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. + +Related content +--------------- + +There are `several design articles `_ on ROS 2 interfaces and the IDL (interface definition language). \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst index a2d79fb765d..40a7997b16e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst @@ -1,586 +1,587 @@ -.. redirect-from:: - - Tutorials/Tf2/Adding-A-Frame-Cpp - -Adding a frame (C++) -==================== - -**Goal:** Learn how to to add an extra frame to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 3 - :local: - -Background ----------- - -In previous tutorials, we recreated the turtle demo by writing a :doc:`tf2 broadcaster <./Writing-A-Tf2-Broadcaster-Cpp>` and a :doc:`tf2 listener `. -This tutorial will teach you how to add extra fixed and dynamic frames to the transformation tree. -In fact, adding a frame in tf2 is very similar to creating the tf2 broadcaster, but this example will show you some additional features of tf2. - -For many tasks related to transformations, it is easier to think inside a local frame. -For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. -tf2 allows you to define a local frame for each sensor, link, or joint in your system. -When transforming from one frame to another, tf2 will take care of all the hidden intermediate frame transformations that are introduced. - -tf2 tree --------- - -tf2 builds up a tree structure of frames and, thus, does not allow a closed loop in the frame structure. -This means that a frame only has one single parent, but it can have multiple children. -Currently, our tf2 tree contains three frames: ``world``, ``turtle1`` and ``turtle2``. -The two turtle frames are children of the ``world`` frame. -If we want to add a new frame to tf2, one of the three existing frames needs to be the parent frame, and the new one will become its child frame. - -.. image:: images/turtlesim_frames.png - -Tasks ------ - -1 Write the fixed frame broadcaster -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In our turtle example, we'll add a new frame ``carrot1``, which will be the child of the ``turtle1``. -This frame will serve as the goal for the second turtle. - -Let's first create the source files. -Go to the ``learning_tf2_cpp`` package we created in the previous tutorials. -Inside the ``src`` directory download the fixed frame broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp -o fixed_frame_tf2_broadcaster.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp -o fixed_frame_tf2_broadcaster.cpp - -Now open the file called ``fixed_frame_tf2_broadcaster.cpp``. - -.. code-block:: C++ - - #include - #include - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2_ros/transform_broadcaster.h" - - using namespace std::chrono_literals; - - class FixedFrameBroadcaster : public rclcpp::Node - { - public: - FixedFrameBroadcaster() - : Node("fixed_frame_tf2_broadcaster") - { - tf_broadcaster_ = std::make_shared(this); - - auto broadcast_timer_callback = [this](){ - geometry_msgs::msg::TransformStamped t; - - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "turtle1"; - t.child_frame_id = "carrot1"; - t.transform.translation.x = 0.0; - t.transform.translation.y = 2.0; - t.transform.translation.z = 0.0; - t.transform.rotation.x = 0.0; - t.transform.rotation.y = 0.0; - t.transform.rotation.z = 0.0; - t.transform.rotation.w = 1.0; - - tf_broadcaster_->sendTransform(t); - }; - timer_ = this->create_wall_timer(100ms, broadcast_timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - std::shared_ptr tf_broadcaster_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -The code is very similar to the tf2 broadcaster tutorial example and the only difference is that the transform here does not change over time. - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Let's take a look at the key lines in this piece of code. -Here we create a new transform, from the parent ``turtle1`` to the new child ``carrot1``. -The ``carrot1`` frame is 2 meters offset in y axis in terms of the ``turtle1`` frame. - -.. code-block:: C++ - - geometry_msgs::msg::TransformStamped t; - - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "turtle1"; - t.child_frame_id = "carrot1"; - t.transform.translation.x = 0.0; - t.transform.translation.y = 2.0; - t.transform.translation.z = 0.0; - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Now open the ``CMakeLists.txt`` add the executable and name it ``fixed_frame_tf2_broadcaster``. - -.. code-block:: console - - add_executable(fixed_frame_tf2_broadcaster src/fixed_frame_tf2_broadcaster.cpp) - target_link_libraries( - fixed_frame_tf2_broadcaster PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2_ros::tf2_ros - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - fixed_frame_tf2_broadcaster - DESTINATION lib/${PROJECT_NAME}) - -1.3 Write the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now let's create a launch file for this example. -With your text editor, create a new file called ``turtle_tf2_fixed_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory, check the type (``.py``, ``.xml``, or ``.yaml``) of previous tutorial's launch file and add the following lines: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.yaml - :language: yaml - -This launch file imports the required packages and then creates a ``demo_nodes`` variable that will store nodes that we created in the previous tutorial's launch file. - -The last part of the code will add our fixed ``carrot1`` frame to the turtlesim world using our ``fixed_frame_tf2_broadcaster`` node. - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.py - :language: python - :lines: 14-18 - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.xml - :language: xml - :lines: 3-4 - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.yaml - :language: yaml - :lines: 6-9 - -1.4 Build -~~~~~~~~~ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -1.5 Run -~~~~~~~ - -Now you can start the turtle broadcaster demo: - -.. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml # .py or .yaml are also acceptable - -You should notice that the new ``carrot1`` frame appeared in the transformation tree. - -.. image:: images/turtlesim_frames_carrot.png - -If you drive the first turtle around, you should notice that the behavior didn't change from the previous tutorial, even though we added a new frame. -That's because adding an extra frame does not affect the other frames and our listener is still using the previously defined frames. - -Therefore if we want our second turtle to follow the carrot instead of the first turtle, we need to change value of the ``target_frame``. -This can be done two ways. -One way is to pass the ``target_frame`` argument to the launch file directly from the console: - -.. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml target_frame:=carrot1 # .py or .yaml are also acceptable - -The second way is to update the launch file. -To do so, open the ``turtle_tf2_fixed_frame_demo_launch.py`` file, and add the ``'target_frame': 'carrot1'`` parameter via ``launch_arguments`` argument. - -.. code-block:: python - - def generate_launch_description(): - demo_nodes = IncludeLaunchDescription( - ..., - launch_arguments={'target_frame': 'carrot1'}.items(), - ) - -Now rebuild the package, restart the ``turtle_tf2_fixed_frame_demo_launch.py``, and you'll see the second turtle following the carrot instead of the first turtle! - -.. image:: images/carrot_static.png - -2 Write the dynamic frame broadcaster -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The extra frame we published in this tutorial is a fixed frame that doesn't change over time in relation to the parent frame. -However, if you want to publish a moving frame you can code the broadcaster to change the frame over time. -Let's change our ``carrot1`` frame so that it changes relative to ``turtle1`` frame over time. -Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. -Inside the ``src`` directory download the dynamic frame broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp -o dynamic_frame_tf2_broadcaster.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp -o dynamic_frame_tf2_broadcaster.cpp - -Now open the file called ``dynamic_frame_tf2_broadcaster.cpp``: - -.. code-block:: C++ - - #include - #include - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2_ros/transform_broadcaster.h" - - using namespace std::chrono_literals; - - const double PI = 3.141592653589793238463; - - class DynamicFrameBroadcaster : public rclcpp::Node - { - public: - DynamicFrameBroadcaster() - : Node("dynamic_frame_tf2_broadcaster") - { - tf_broadcaster_ = std::make_shared(this); - - auto broadcast_timer_callback = [this](){ - rclcpp::Time now = this->get_clock()->now(); - double x = now.seconds() * PI; - - geometry_msgs::msg::TransformStamped t; - t.header.stamp = now; - t.header.frame_id = "turtle1"; - t.child_frame_id = "carrot1"; - t.transform.translation.x = 10 * sin(x); - t.transform.translation.y = 10 * cos(x); - t.transform.translation.z = 0.0; - t.transform.rotation.x = 0.0; - t.transform.rotation.y = 0.0; - t.transform.rotation.z = 0.0; - t.transform.rotation.w = 1.0; - - tf_broadcaster_->sendTransform(t); - }; - timer_ = this->create_wall_timer(100ms, broadcast_timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - std::shared_ptr tf_broadcaster_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Instead of a fixed definition of our x and y offsets, we are using the ``sin()`` and ``cos()`` functions on the current time so that the offset of ``carrot1`` is constantly changing. - -.. code-block:: C++ - - double x = now.seconds() * PI; - ... - t.transform.translation.x = 10 * sin(x); - t.transform.translation.y = 10 * cos(x); - -2.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Now open the ``CMakeLists.txt`` add the executable and name it ``dynamic_frame_tf2_broadcaster``. - -.. code-block:: console - - add_executable(dynamic_frame_tf2_broadcaster src/dynamic_frame_tf2_broadcaster.cpp) - target_link_libraries( - dynamic_frame_tf2_broadcaster PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2_ros::tf2_ros - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - dynamic_frame_tf2_broadcaster - DESTINATION lib/${PROJECT_NAME}) - -2.3 Write the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~ - -To test this code, create a new launch file ``turtle_tf2_dynamic_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory and check the type (``.py``, ``.xml``, or ``.yaml``) of previous tutorial's launch file and paste the following code: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_dynamic_frame_demo_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_dynamic_frame_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_dynamic_frame_demo_launch.yaml - :language: yaml - - -2.4 Build -~~~~~~~~~ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -2.5 Run -~~~~~~~ - -Now you can start the dynamic frame demo: - -.. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_dynamic_frame_demo_launch.xml # .py or .yaml are also acceptable - -You should see that the second turtle is following the carrot's position that is constantly changing. - -.. image:: images/carrot_dynamic.png - - -Summary -------- - -In this tutorial, you learned about the tf2 transformation tree, its structure, and its features. -You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. +.. redirect-from:: + + Tutorials/Tf2/Adding-A-Frame-Cpp + Tutorials/Intermediate/Tf2/Adding-A-Frame-Cpp + +Adding a frame (C++) +==================== + +**Goal:** Learn how to to add an extra frame to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 3 + :local: + +Background +---------- + +In previous tutorials, we recreated the turtle demo by writing a :doc:`tf2 broadcaster ` and a :doc:`tf2 listener `. +This tutorial will teach you how to add extra fixed and dynamic frames to the transformation tree. +In fact, adding a frame in tf2 is very similar to creating the tf2 broadcaster, but this example will show you some additional features of tf2. + +For many tasks related to transformations, it is easier to think inside a local frame. +For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. +tf2 allows you to define a local frame for each sensor, link, or joint in your system. +When transforming from one frame to another, tf2 will take care of all the hidden intermediate frame transformations that are introduced. + +tf2 tree +-------- + +tf2 builds up a tree structure of frames and, thus, does not allow a closed loop in the frame structure. +This means that a frame only has one single parent, but it can have multiple children. +Currently, our tf2 tree contains three frames: ``world``, ``turtle1`` and ``turtle2``. +The two turtle frames are children of the ``world`` frame. +If we want to add a new frame to tf2, one of the three existing frames needs to be the parent frame, and the new one will become its child frame. + +.. image:: images/turtlesim_frames.png + +Tasks +----- + +1 Write the fixed frame broadcaster +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In our turtle example, we'll add a new frame ``carrot1``, which will be the child of the ``turtle1``. +This frame will serve as the goal for the second turtle. + +Let's first create the source files. +Go to the ``learning_tf2_cpp`` package we created in the previous tutorials. +Inside the ``src`` directory download the fixed frame broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp -o fixed_frame_tf2_broadcaster.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/fixed_frame_tf2_broadcaster.cpp -o fixed_frame_tf2_broadcaster.cpp + +Now open the file called ``fixed_frame_tf2_broadcaster.cpp``. + +.. code-block:: C++ + + #include + #include + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2_ros/transform_broadcaster.h" + + using namespace std::chrono_literals; + + class FixedFrameBroadcaster : public rclcpp::Node + { + public: + FixedFrameBroadcaster() + : Node("fixed_frame_tf2_broadcaster") + { + tf_broadcaster_ = std::make_shared(this); + + auto broadcast_timer_callback = [this](){ + geometry_msgs::msg::TransformStamped t; + + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "turtle1"; + t.child_frame_id = "carrot1"; + t.transform.translation.x = 0.0; + t.transform.translation.y = 2.0; + t.transform.translation.z = 0.0; + t.transform.rotation.x = 0.0; + t.transform.rotation.y = 0.0; + t.transform.rotation.z = 0.0; + t.transform.rotation.w = 1.0; + + tf_broadcaster_->sendTransform(t); + }; + timer_ = this->create_wall_timer(100ms, broadcast_timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + std::shared_ptr tf_broadcaster_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +The code is very similar to the tf2 broadcaster tutorial example and the only difference is that the transform here does not change over time. + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Let's take a look at the key lines in this piece of code. +Here we create a new transform, from the parent ``turtle1`` to the new child ``carrot1``. +The ``carrot1`` frame is 2 meters offset in y axis in terms of the ``turtle1`` frame. + +.. code-block:: C++ + + geometry_msgs::msg::TransformStamped t; + + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "turtle1"; + t.child_frame_id = "carrot1"; + t.transform.translation.x = 0.0; + t.transform.translation.y = 2.0; + t.transform.translation.z = 0.0; + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Now open the ``CMakeLists.txt`` add the executable and name it ``fixed_frame_tf2_broadcaster``. + +.. code-block:: console + + add_executable(fixed_frame_tf2_broadcaster src/fixed_frame_tf2_broadcaster.cpp) + target_link_libraries( + fixed_frame_tf2_broadcaster PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2_ros::tf2_ros + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + fixed_frame_tf2_broadcaster + DESTINATION lib/${PROJECT_NAME}) + +1.3 Write the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now let's create a launch file for this example. +With your text editor, create a new file called ``turtle_tf2_fixed_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory, check the type (``.py``, ``.xml``, or ``.yaml``) of previous tutorial's launch file and add the following lines: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.yaml + :language: yaml + +This launch file imports the required packages and then creates a ``demo_nodes`` variable that will store nodes that we created in the previous tutorial's launch file. + +The last part of the code will add our fixed ``carrot1`` frame to the turtlesim world using our ``fixed_frame_tf2_broadcaster`` node. + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.py + :language: python + :lines: 14-18 + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.xml + :language: xml + :lines: 3-4 + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_fixed_frame_demo_launch.yaml + :language: yaml + :lines: 6-9 + +1.4 Build +~~~~~~~~~ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +1.5 Run +~~~~~~~ + +Now you can start the turtle broadcaster demo: + +.. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml # .py or .yaml are also acceptable + +You should notice that the new ``carrot1`` frame appeared in the transformation tree. + +.. image:: images/turtlesim_frames_carrot.png + +If you drive the first turtle around, you should notice that the behavior didn't change from the previous tutorial, even though we added a new frame. +That's because adding an extra frame does not affect the other frames and our listener is still using the previously defined frames. + +Therefore if we want our second turtle to follow the carrot instead of the first turtle, we need to change value of the ``target_frame``. +This can be done two ways. +One way is to pass the ``target_frame`` argument to the launch file directly from the console: + +.. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml target_frame:=carrot1 # .py or .yaml are also acceptable + +The second way is to update the launch file. +To do so, open the ``turtle_tf2_fixed_frame_demo_launch.py`` file, and add the ``'target_frame': 'carrot1'`` parameter via ``launch_arguments`` argument. + +.. code-block:: python + + def generate_launch_description(): + demo_nodes = IncludeLaunchDescription( + ..., + launch_arguments={'target_frame': 'carrot1'}.items(), + ) + +Now rebuild the package, restart the ``turtle_tf2_fixed_frame_demo_launch.py``, and you'll see the second turtle following the carrot instead of the first turtle! + +.. image:: images/carrot_static.png + +2 Write the dynamic frame broadcaster +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The extra frame we published in this tutorial is a fixed frame that doesn't change over time in relation to the parent frame. +However, if you want to publish a moving frame you can code the broadcaster to change the frame over time. +Let's change our ``carrot1`` frame so that it changes relative to ``turtle1`` frame over time. +Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. +Inside the ``src`` directory download the dynamic frame broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp -o dynamic_frame_tf2_broadcaster.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/dynamic_frame_tf2_broadcaster.cpp -o dynamic_frame_tf2_broadcaster.cpp + +Now open the file called ``dynamic_frame_tf2_broadcaster.cpp``: + +.. code-block:: C++ + + #include + #include + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2_ros/transform_broadcaster.h" + + using namespace std::chrono_literals; + + const double PI = 3.141592653589793238463; + + class DynamicFrameBroadcaster : public rclcpp::Node + { + public: + DynamicFrameBroadcaster() + : Node("dynamic_frame_tf2_broadcaster") + { + tf_broadcaster_ = std::make_shared(this); + + auto broadcast_timer_callback = [this](){ + rclcpp::Time now = this->get_clock()->now(); + double x = now.seconds() * PI; + + geometry_msgs::msg::TransformStamped t; + t.header.stamp = now; + t.header.frame_id = "turtle1"; + t.child_frame_id = "carrot1"; + t.transform.translation.x = 10 * sin(x); + t.transform.translation.y = 10 * cos(x); + t.transform.translation.z = 0.0; + t.transform.rotation.x = 0.0; + t.transform.rotation.y = 0.0; + t.transform.rotation.z = 0.0; + t.transform.rotation.w = 1.0; + + tf_broadcaster_->sendTransform(t); + }; + timer_ = this->create_wall_timer(100ms, broadcast_timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + std::shared_ptr tf_broadcaster_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Instead of a fixed definition of our x and y offsets, we are using the ``sin()`` and ``cos()`` functions on the current time so that the offset of ``carrot1`` is constantly changing. + +.. code-block:: C++ + + double x = now.seconds() * PI; + ... + t.transform.translation.x = 10 * sin(x); + t.transform.translation.y = 10 * cos(x); + +2.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Now open the ``CMakeLists.txt`` add the executable and name it ``dynamic_frame_tf2_broadcaster``. + +.. code-block:: console + + add_executable(dynamic_frame_tf2_broadcaster src/dynamic_frame_tf2_broadcaster.cpp) + target_link_libraries( + dynamic_frame_tf2_broadcaster PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2_ros::tf2_ros + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + dynamic_frame_tf2_broadcaster + DESTINATION lib/${PROJECT_NAME}) + +2.3 Write the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~ + +To test this code, create a new launch file ``turtle_tf2_dynamic_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory and check the type (``.py``, ``.xml``, or ``.yaml``) of previous tutorial's launch file and paste the following code: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_dynamic_frame_demo_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_dynamic_frame_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_dynamic_frame_demo_launch.yaml + :language: yaml + + +2.4 Build +~~~~~~~~~ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +2.5 Run +~~~~~~~ + +Now you can start the dynamic frame demo: + +.. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_dynamic_frame_demo_launch.xml # .py or .yaml are also acceptable + +You should see that the second turtle is following the carrot's position that is constantly changing. + +.. image:: images/carrot_dynamic.png + + +Summary +------- + +In this tutorial, you learned about the tf2 transformation tree, its structure, and its features. +You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst index ce504a67024..48a764eb240 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst @@ -1,542 +1,543 @@ -.. redirect-from:: - - Tutorials/Tf2/Adding-A-Frame-Py - -Adding a frame (Python) -======================= - -**Goal:** Learn how to to add an extra frame to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 3 - :local: - -Background ----------- - -In previous tutorials, we recreated the turtle demo by writing a :doc:`tf2 broadcaster <./Writing-A-Tf2-Broadcaster-Py>` and a :doc:`tf2 listener <./Writing-A-Tf2-Listener-Py>`. -This tutorial will teach you how to add extra fixed and dynamic frames to the transformation tree. -In fact, adding a frame in tf2 is very similar to creating the tf2 broadcaster, but this example will show you some additional features of tf2. - -For many tasks related to transformations, it is easier to think inside a local frame. -For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. -tf2 allows you to define a local frame for each sensor, link, or joint in your system. -When transforming from one frame to another, tf2 will take care of all the hidden intermediate frame transformations that are introduced. - -tf2 tree --------- - -tf2 builds up a tree structure of frames and, thus, does not allow a closed loop in the frame structure. -This means that a frame only has one single parent, but it can have multiple children. -Currently, our tf2 tree contains three frames: ``world``, ``turtle1`` and ``turtle2``. -The two turtle frames are children of the ``world`` frame. -If we want to add a new frame to tf2, one of the three existing frames needs to be the parent frame, and the new one will become its child frame. - -.. image:: images/turtlesim_frames.png - -Tasks ------ - -1 Write the fixed frame broadcaster -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In our turtle example, we'll add a new frame ``carrot1``, which will be the child of the ``turtle1``. -This frame will serve as the goal for the second turtle. - -Let's first create the source files. -Go to the ``learning_tf2_py`` package we created in the previous tutorials. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the fixed frame broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py -o fixed_frame_tf2_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py -o fixed_frame_tf2_broadcaster.py - -Now open the file called ``fixed_frame_tf2_broadcaster.py``. - -.. code-block:: python - - from geometry_msgs.msg import TransformStamped - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros import TransformBroadcaster - - - class FixedFrameBroadcaster(Node): - - def __init__(self): - super().__init__('fixed_frame_tf2_broadcaster') - self.tf_broadcaster = TransformBroadcaster(self) - self.timer = self.create_timer(0.1, self.broadcast_timer_callback) - - def broadcast_timer_callback(self): - t = TransformStamped() - - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'turtle1' - t.child_frame_id = 'carrot1' - t.transform.translation.x = 0.0 - t.transform.translation.y = 2.0 - t.transform.translation.z = 0.0 - t.transform.rotation.x = 0.0 - t.transform.rotation.y = 0.0 - t.transform.rotation.z = 0.0 - t.transform.rotation.w = 1.0 - - self.tf_broadcaster.sendTransform(t) - - - def main(): - try: - with rclpy.init(): - node = FixedFrameBroadcaster() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -The code is very similar to the tf2 broadcaster tutorial example and the only difference is that the transform here does not change over time. - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Let's take a look at the key lines in this piece of code. -Here we create a new transform, from the parent ``turtle1`` to the new child ``carrot1``. -The ``carrot1`` frame is 2 meters offset in y axis in terms of the ``turtle1`` frame. - -.. code-block:: python - - t = TransformStamped() - - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'turtle1' - t.child_frame_id = 'carrot1' - t.transform.translation.x = 0.0 - t.transform.translation.y = 2.0 - t.transform.translation.z = 0.0 - -1.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'fixed_frame_tf2_broadcaster = learning_tf2_py.fixed_frame_tf2_broadcaster:main', - -1.3 Write the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now let's create a launch file for this example. -With your text editor, create a new file called ``turtle_tf2_fixed_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory, check the type (``.py``, ``.xml``, or ``yaml``) of the previous tutorial's launch file and add the following lines: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.py - :name: turtle_tf2_fixed_frame_demo_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.yaml - :language: yaml - -This launch file imports the required packages and then creates a ``demo_nodes`` variable that will store nodes that we created in the previous tutorial's launch file. - -The last part of the code will add our fixed ``carrot1`` frame to the turtlesim world using our ``fixed_frame_tf2_broadcaster`` node. - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.py - :language: python - :lines: 14-18 - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.xml - :language: xml - :lines: 3-4 - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.yaml - :language: yaml - :lines: 6-9 - -1.4 Build -~~~~~~~~~ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ call install\setup.bat - -1.5 Run -~~~~~~~ - -Now you can start the turtle broadcaster demo: - -.. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_fixed_frame_demo_launch.xml # .py or .yaml are also acceptable - -You should notice that the new ``carrot1`` frame appeared in the transformation tree. - -.. image:: images/turtlesim_frames_carrot.png - -If you drive the first turtle around, you should notice that the behavior didn't change from the previous tutorial, even though we added a new frame. -That's because adding an extra frame does not affect the other frames and our listener is still using the previously defined frames. - -Therefore if we want our second turtle to follow the carrot instead of the first turtle, we need to change value of the ``target_frame``. -This can be done two ways. -One way is to pass the ``target_frame`` argument to the launch file directly from the console: - -.. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_fixed_frame_demo_launch.xml target_frame:=carrot1 # .py or .yaml are also acceptable - -The second way is to update the launch file. -To do so, open the ``turtle_tf2_fixed_frame_demo_launch.py`` file, and add the ``'target_frame': 'carrot1'`` parameter via ``launch_arguments`` argument. - -.. code-block:: python - - def generate_launch_description(): - demo_nodes = IncludeLaunchDescription( - ..., - launch_arguments={'target_frame': 'carrot1'}.items(), - ) - -Now rebuild the package, restart the ``turtle_tf2_fixed_frame_demo_launch.py``, and you'll see the second turtle following the carrot instead of the first turtle! - -.. image:: images/carrot_static.png - -2 Write the dynamic frame broadcaster -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The extra frame we published in this tutorial is a fixed frame that doesn't change over time in relation to the parent frame. -However, if you want to publish a moving frame you can code the broadcaster to change the frame over time. -Let's change our ``carrot1`` frame so that it changes relative to ``turtle1`` frame over time. -Go to the ``learning_tf2_py`` package we created in the previous tutorial. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the dynamic frame broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py -o dynamic_frame_tf2_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py -o dynamic_frame_tf2_broadcaster.py - -Now open the file called ``dynamic_frame_tf2_broadcaster.py``: - -.. code-block:: python - - import math - - from geometry_msgs.msg import TransformStamped - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros import TransformBroadcaster - - - class DynamicFrameBroadcaster(Node): - - def __init__(self): - super().__init__('dynamic_frame_tf2_broadcaster') - self.tf_broadcaster = TransformBroadcaster(self) - self.timer = self.create_timer(0.1, self.broadcast_timer_callback) - - def broadcast_timer_callback(self): - seconds, _ = self.get_clock().now().seconds_nanoseconds() - x = seconds * math.pi - - t = TransformStamped() - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'turtle1' - t.child_frame_id = 'carrot1' - t.transform.translation.x = 10 * math.sin(x) - t.transform.translation.y = 10 * math.cos(x) - t.transform.translation.z = 0.0 - t.transform.rotation.x = 0.0 - t.transform.rotation.y = 0.0 - t.transform.rotation.z = 0.0 - t.transform.rotation.w = 1.0 - - self.tf_broadcaster.sendTransform(t) - - - def main(): - try: - with rclpy.init(): - node = DynamicFrameBroadcaster() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Instead of a fixed definition of our x and y offsets, we are using the ``sin()`` and ``cos()`` functions on the current time so that the offset of ``carrot1`` is constantly changing. - -.. code-block:: python - - seconds, _ = self.get_clock().now().seconds_nanoseconds() - x = seconds * math.pi - ... - t.transform.translation.x = 10 * math.sin(x) - t.transform.translation.y = 10 * math.cos(x) - -2.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'dynamic_frame_tf2_broadcaster = learning_tf2_py.dynamic_frame_tf2_broadcaster:main', - -2.3 Write the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~ - -To test this code, create a new launch file ``turtle_tf2_dynamic_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory and check the type (``.py``, ``.xml``, or ``.yaml``) of previous tutorial's launch file and update it in the following code: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_dynamic_frame_demo_launch.py - :name: turtle_tf2_dynamic_frame_demo_launch.py - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_dynamic_frame_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_dynamic_frame_demo_launch.yaml - :language: yaml - - -2.4 Build -~~~~~~~~~ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -1.5 Run -~~~~~~~ - -Now you can start the dynamic frame demo: - -.. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_dynamic_frame_demo_launch.xml # .py or .yaml are also acceptable - -You should see that the second turtle is following the carrot's position that is constantly changing. - -.. image:: images/carrot_dynamic.png - -Summary -------- - -In this tutorial, you learned about the tf2 transformation tree, its structure, and its features. -You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. +.. redirect-from:: + + Tutorials/Tf2/Adding-A-Frame-Py + Tutorials/Intermediate/Tf2/Adding-A-Frame-Py + +Adding a frame (Python) +======================= + +**Goal:** Learn how to to add an extra frame to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 3 + :local: + +Background +---------- + +In previous tutorials, we recreated the turtle demo by writing a :doc:`tf2 broadcaster ` and a :doc:`tf2 listener `. +This tutorial will teach you how to add extra fixed and dynamic frames to the transformation tree. +In fact, adding a frame in tf2 is very similar to creating the tf2 broadcaster, but this example will show you some additional features of tf2. + +For many tasks related to transformations, it is easier to think inside a local frame. +For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. +tf2 allows you to define a local frame for each sensor, link, or joint in your system. +When transforming from one frame to another, tf2 will take care of all the hidden intermediate frame transformations that are introduced. + +tf2 tree +-------- + +tf2 builds up a tree structure of frames and, thus, does not allow a closed loop in the frame structure. +This means that a frame only has one single parent, but it can have multiple children. +Currently, our tf2 tree contains three frames: ``world``, ``turtle1`` and ``turtle2``. +The two turtle frames are children of the ``world`` frame. +If we want to add a new frame to tf2, one of the three existing frames needs to be the parent frame, and the new one will become its child frame. + +.. image:: images/turtlesim_frames.png + +Tasks +----- + +1 Write the fixed frame broadcaster +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In our turtle example, we'll add a new frame ``carrot1``, which will be the child of the ``turtle1``. +This frame will serve as the goal for the second turtle. + +Let's first create the source files. +Go to the ``learning_tf2_py`` package we created in the previous tutorials. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the fixed frame broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py -o fixed_frame_tf2_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/fixed_frame_tf2_broadcaster.py -o fixed_frame_tf2_broadcaster.py + +Now open the file called ``fixed_frame_tf2_broadcaster.py``. + +.. code-block:: python + + from geometry_msgs.msg import TransformStamped + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros import TransformBroadcaster + + + class FixedFrameBroadcaster(Node): + + def __init__(self): + super().__init__('fixed_frame_tf2_broadcaster') + self.tf_broadcaster = TransformBroadcaster(self) + self.timer = self.create_timer(0.1, self.broadcast_timer_callback) + + def broadcast_timer_callback(self): + t = TransformStamped() + + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'turtle1' + t.child_frame_id = 'carrot1' + t.transform.translation.x = 0.0 + t.transform.translation.y = 2.0 + t.transform.translation.z = 0.0 + t.transform.rotation.x = 0.0 + t.transform.rotation.y = 0.0 + t.transform.rotation.z = 0.0 + t.transform.rotation.w = 1.0 + + self.tf_broadcaster.sendTransform(t) + + + def main(): + try: + with rclpy.init(): + node = FixedFrameBroadcaster() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +The code is very similar to the tf2 broadcaster tutorial example and the only difference is that the transform here does not change over time. + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Let's take a look at the key lines in this piece of code. +Here we create a new transform, from the parent ``turtle1`` to the new child ``carrot1``. +The ``carrot1`` frame is 2 meters offset in y axis in terms of the ``turtle1`` frame. + +.. code-block:: python + + t = TransformStamped() + + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'turtle1' + t.child_frame_id = 'carrot1' + t.transform.translation.x = 0.0 + t.transform.translation.y = 2.0 + t.transform.translation.z = 0.0 + +1.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'fixed_frame_tf2_broadcaster = learning_tf2_py.fixed_frame_tf2_broadcaster:main', + +1.3 Write the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now let's create a launch file for this example. +With your text editor, create a new file called ``turtle_tf2_fixed_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory, check the type (``.py``, ``.xml``, or ``yaml``) of the previous tutorial's launch file and add the following lines: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.py + :name: turtle_tf2_fixed_frame_demo_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.yaml + :language: yaml + +This launch file imports the required packages and then creates a ``demo_nodes`` variable that will store nodes that we created in the previous tutorial's launch file. + +The last part of the code will add our fixed ``carrot1`` frame to the turtlesim world using our ``fixed_frame_tf2_broadcaster`` node. + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.py + :language: python + :lines: 14-18 + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.xml + :language: xml + :lines: 3-4 + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_fixed_frame_demo_launch.yaml + :language: yaml + :lines: 6-9 + +1.4 Build +~~~~~~~~~ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ call install\setup.bat + +1.5 Run +~~~~~~~ + +Now you can start the turtle broadcaster demo: + +.. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_fixed_frame_demo_launch.xml # .py or .yaml are also acceptable + +You should notice that the new ``carrot1`` frame appeared in the transformation tree. + +.. image:: images/turtlesim_frames_carrot.png + +If you drive the first turtle around, you should notice that the behavior didn't change from the previous tutorial, even though we added a new frame. +That's because adding an extra frame does not affect the other frames and our listener is still using the previously defined frames. + +Therefore if we want our second turtle to follow the carrot instead of the first turtle, we need to change value of the ``target_frame``. +This can be done two ways. +One way is to pass the ``target_frame`` argument to the launch file directly from the console: + +.. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_fixed_frame_demo_launch.xml target_frame:=carrot1 # .py or .yaml are also acceptable + +The second way is to update the launch file. +To do so, open the ``turtle_tf2_fixed_frame_demo_launch.py`` file, and add the ``'target_frame': 'carrot1'`` parameter via ``launch_arguments`` argument. + +.. code-block:: python + + def generate_launch_description(): + demo_nodes = IncludeLaunchDescription( + ..., + launch_arguments={'target_frame': 'carrot1'}.items(), + ) + +Now rebuild the package, restart the ``turtle_tf2_fixed_frame_demo_launch.py``, and you'll see the second turtle following the carrot instead of the first turtle! + +.. image:: images/carrot_static.png + +2 Write the dynamic frame broadcaster +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The extra frame we published in this tutorial is a fixed frame that doesn't change over time in relation to the parent frame. +However, if you want to publish a moving frame you can code the broadcaster to change the frame over time. +Let's change our ``carrot1`` frame so that it changes relative to ``turtle1`` frame over time. +Go to the ``learning_tf2_py`` package we created in the previous tutorial. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the dynamic frame broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py -o dynamic_frame_tf2_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/dynamic_frame_tf2_broadcaster.py -o dynamic_frame_tf2_broadcaster.py + +Now open the file called ``dynamic_frame_tf2_broadcaster.py``: + +.. code-block:: python + + import math + + from geometry_msgs.msg import TransformStamped + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros import TransformBroadcaster + + + class DynamicFrameBroadcaster(Node): + + def __init__(self): + super().__init__('dynamic_frame_tf2_broadcaster') + self.tf_broadcaster = TransformBroadcaster(self) + self.timer = self.create_timer(0.1, self.broadcast_timer_callback) + + def broadcast_timer_callback(self): + seconds, _ = self.get_clock().now().seconds_nanoseconds() + x = seconds * math.pi + + t = TransformStamped() + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'turtle1' + t.child_frame_id = 'carrot1' + t.transform.translation.x = 10 * math.sin(x) + t.transform.translation.y = 10 * math.cos(x) + t.transform.translation.z = 0.0 + t.transform.rotation.x = 0.0 + t.transform.rotation.y = 0.0 + t.transform.rotation.z = 0.0 + t.transform.rotation.w = 1.0 + + self.tf_broadcaster.sendTransform(t) + + + def main(): + try: + with rclpy.init(): + node = DynamicFrameBroadcaster() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Instead of a fixed definition of our x and y offsets, we are using the ``sin()`` and ``cos()`` functions on the current time so that the offset of ``carrot1`` is constantly changing. + +.. code-block:: python + + seconds, _ = self.get_clock().now().seconds_nanoseconds() + x = seconds * math.pi + ... + t.transform.translation.x = 10 * math.sin(x) + t.transform.translation.y = 10 * math.cos(x) + +2.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'dynamic_frame_tf2_broadcaster = learning_tf2_py.dynamic_frame_tf2_broadcaster:main', + +2.3 Write the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~ + +To test this code, create a new launch file ``turtle_tf2_dynamic_frame_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory and check the type (``.py``, ``.xml``, or ``.yaml``) of previous tutorial's launch file and update it in the following code: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_dynamic_frame_demo_launch.py + :name: turtle_tf2_dynamic_frame_demo_launch.py + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_dynamic_frame_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_dynamic_frame_demo_launch.yaml + :language: yaml + + +2.4 Build +~~~~~~~~~ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +1.5 Run +~~~~~~~ + +Now you can start the dynamic frame demo: + +.. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_dynamic_frame_demo_launch.xml # .py or .yaml are also acceptable + +You should see that the second turtle is following the carrot's position that is constantly changing. + +.. image:: images/carrot_dynamic.png + +Summary +------- + +In this tutorial, you learned about the tf2 transformation tree, its structure, and its features. +You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst index 1abe809c30c..60a5883306f 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst @@ -1,137 +1,138 @@ -.. redirect-from:: - - Tutorials/Tf2/Learning-About-Tf2-And-Time-Cpp - -.. _LearningAboutTf2AndTimeCpp: - -Using time (C++) -================ - -**Goal:** Learn how to get a transform at a specific time and wait for a transform to be available on the tf2 tree using ``lookupTransform()`` function. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials, we recreated the turtle demo by writing a :doc:`tf2 broadcaster ` and a :doc:`tf2 listener `. -We also learned how to :doc:`add a new frame to the transformation tree ` and learned how tf2 keeps track of a tree of coordinate frames. -This tree changes over time, and tf2 stores a time snapshot for every transform (for up to 10 seconds by default). -Until now we used the ``lookupTransform()`` function to get access to the latest available transforms in that tf2 tree, without knowing at what time that transform was recorded. -This tutorial will teach you how to get a transform at a specific time. - -Tasks ------ - -1 Update the listener node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's go back to where we ended in the :doc:`adding a frame tutorial `. -Go to the ``learning_tf2_cpp`` package. -Open ``turtle_tf2_listener.cpp`` and take a look at the ``lookupTransform()`` call: - -.. code-block:: C++ - - try { - t = tf_buffer_->lookupTransform( - toFrameRel, - fromFrameRel, - tf2::TimePointZero); - } catch (const tf2::TransformException & ex) { - -You can see that we specified a time equal to 0 by calling ``tf2::TimePointZero``. - -.. note:: - - The ``tf2`` package has it's own time type ``tf2::TimePoint``, which is different from ``rclcpp::Time``. - Many APIs in the package ``tf2_ros`` automatically convert between ``rclcpp::Time`` and ``tf2::TimePoint``. - - ``rclcpp::Time(0, 0, this->get_clock()->get_clock_type())`` could have been used here, but it would have been converted to ``tf2::TimePointZero`` anyways. - -For tf2, time 0 means "the latest available" transform in the buffer. -Now, change this line to get the transform at the current time, ``this->get_clock()->now()``: - -.. code-block:: C++ - - rclcpp::Time now = this->get_clock()->now(); - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - now); - } catch (const tf2::TransformException & ex) { - -Now build the package and try to run the launch file. - -.. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml # .py or .yaml are also acceptable - [INFO] [1629873136.345688064] [listener]: Could not transform turtle2 to turtle1: Lookup would - require extrapolation into the future. Requested time 1629873136.345539 but the latest data - is at time 1629873136.338804, when looking up transform from frame [turtle1] to frame [turtle2] - -The output tells you that the frame does not exist or that the data is in the future. - -To understand why is this happening we need to understand how buffers work. -Firstly, each listener has a buffer where it stores all the coordinate transforms coming from the different tf2 broadcasters. -Secondly, when a broadcaster sends out a transform, it takes some time before that transform gets into the buffer (usually a couple of milliseconds). -As a result, when you request a frame transform at time "now", you should wait a few milliseconds for that information to arrive. - -2 Fix the listener node -^^^^^^^^^^^^^^^^^^^^^^^ - -tf2 provides a nice tool that will wait until a transform becomes available. -You use this by adding a timeout parameter to ``lookupTransform()``. -To fix this, edit your code as shown below (add the last timeout parameter): - -.. code-block:: C++ - - rclcpp::Time now = this->get_clock()->now(); - try { - t = tf_buffer_->lookupTransform( - toFrameRel, - fromFrameRel, - now, - 50ms); - } catch (const tf2::TransformException & ex) { - -The ``lookupTransform()`` can take four arguments, where the last one is an optional timeout. -It will block for up to that duration waiting for it to timeout. - -3 Check the results -^^^^^^^^^^^^^^^^^^^ - -You can now build the package and run the launch file. - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py - -You should notice that ``lookupTransform()`` will actually block until the transform between the two turtles becomes available (this will usually take a few milliseconds). -Once the timeout has been reached (fifty milliseconds in this case), an exception will be raised only if the transform is still not available. - -Summary -------- - -In this tutorial, you learned how to acquire a transform at a specific timestamp and how to wait for a transform to be available on the tf2 tree when using the ``lookupTransform()`` function. +.. redirect-from:: + + Tutorials/Tf2/Learning-About-Tf2-And-Time-Cpp + Tutorials/Intermediate/Tf2/Learning-About-Tf2-And-Time-Cpp + +.. _LearningAboutTf2AndTimeCpp: + +Using time (C++) +================ + +**Goal:** Learn how to get a transform at a specific time and wait for a transform to be available on the tf2 tree using ``lookupTransform()`` function. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials, we recreated the turtle demo by writing a :doc:`tf2 broadcaster ` and a :doc:`tf2 listener `. +We also learned how to :doc:`add a new frame to the transformation tree ` and learned how tf2 keeps track of a tree of coordinate frames. +This tree changes over time, and tf2 stores a time snapshot for every transform (for up to 10 seconds by default). +Until now we used the ``lookupTransform()`` function to get access to the latest available transforms in that tf2 tree, without knowing at what time that transform was recorded. +This tutorial will teach you how to get a transform at a specific time. + +Tasks +----- + +1 Update the listener node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's go back to where we ended in the :doc:`adding a frame tutorial `. +Go to the ``learning_tf2_cpp`` package. +Open ``turtle_tf2_listener.cpp`` and take a look at the ``lookupTransform()`` call: + +.. code-block:: C++ + + try { + t = tf_buffer_->lookupTransform( + toFrameRel, + fromFrameRel, + tf2::TimePointZero); + } catch (const tf2::TransformException & ex) { + +You can see that we specified a time equal to 0 by calling ``tf2::TimePointZero``. + +.. note:: + + The ``tf2`` package has it's own time type ``tf2::TimePoint``, which is different from ``rclcpp::Time``. + Many APIs in the package ``tf2_ros`` automatically convert between ``rclcpp::Time`` and ``tf2::TimePoint``. + + ``rclcpp::Time(0, 0, this->get_clock()->get_clock_type())`` could have been used here, but it would have been converted to ``tf2::TimePointZero`` anyways. + +For tf2, time 0 means "the latest available" transform in the buffer. +Now, change this line to get the transform at the current time, ``this->get_clock()->now()``: + +.. code-block:: C++ + + rclcpp::Time now = this->get_clock()->now(); + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + now); + } catch (const tf2::TransformException & ex) { + +Now build the package and try to run the launch file. + +.. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml # .py or .yaml are also acceptable + [INFO] [1629873136.345688064] [listener]: Could not transform turtle2 to turtle1: Lookup would + require extrapolation into the future. Requested time 1629873136.345539 but the latest data + is at time 1629873136.338804, when looking up transform from frame [turtle1] to frame [turtle2] + +The output tells you that the frame does not exist or that the data is in the future. + +To understand why is this happening we need to understand how buffers work. +Firstly, each listener has a buffer where it stores all the coordinate transforms coming from the different tf2 broadcasters. +Secondly, when a broadcaster sends out a transform, it takes some time before that transform gets into the buffer (usually a couple of milliseconds). +As a result, when you request a frame transform at time "now", you should wait a few milliseconds for that information to arrive. + +2 Fix the listener node +^^^^^^^^^^^^^^^^^^^^^^^ + +tf2 provides a nice tool that will wait until a transform becomes available. +You use this by adding a timeout parameter to ``lookupTransform()``. +To fix this, edit your code as shown below (add the last timeout parameter): + +.. code-block:: C++ + + rclcpp::Time now = this->get_clock()->now(); + try { + t = tf_buffer_->lookupTransform( + toFrameRel, + fromFrameRel, + now, + 50ms); + } catch (const tf2::TransformException & ex) { + +The ``lookupTransform()`` can take four arguments, where the last one is an optional timeout. +It will block for up to that duration waiting for it to timeout. + +3 Check the results +^^^^^^^^^^^^^^^^^^^ + +You can now build the package and run the launch file. + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py + +You should notice that ``lookupTransform()`` will actually block until the transform between the two turtles becomes available (this will usually take a few milliseconds). +Once the timeout has been reached (fifty milliseconds in this case), an exception will be raised only if the transform is still not available. + +Summary +------- + +In this tutorial, you learned how to acquire a transform at a specific timestamp and how to wait for a transform to be available on the tf2 tree when using the ``lookupTransform()`` function. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst index 7b804229784..5e36494b165 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst @@ -1,90 +1,91 @@ -.. redirect-from:: - - Tutorials/Tf2/Tf2-Main - -.. _Tf2Main: - -``tf2`` -======= - -Many of the tf2 tutorials are available for both C++ and Python. -The tutorials are streamlined to complete either the C++ track or the Python track. -If you want to learn both C++ and Python, you should go through the tutorials once for C++ and once for Python. - -.. contents:: Contents - :depth: 2 - :local: - -.. toctree:: - :hidden: - - Introduction-To-Tf2 - Writing-A-Tf2-Static-Broadcaster-Py - Writing-A-Tf2-Static-Broadcaster-Cpp - Writing-A-Tf2-Broadcaster-Py - Writing-A-Tf2-Broadcaster-Cpp - Writing-A-Tf2-Listener-Py - Writing-A-Tf2-Listener-Cpp - Adding-A-Frame-Py - Adding-A-Frame-Cpp - Learning-About-Tf2-And-Time-Cpp - Time-Travel-With-Tf2-Cpp - Quaternion-Fundamentals - Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter - -Workspace setup ---------------- - -If you have not yet created a workspace in which to complete the tutorials, :doc:`follow this tutorial <../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>`. - -Learning tf2 ------------- - -#. :doc:`Introduction to tf2 <./Introduction-To-Tf2>`. - - This tutorial will give you a good idea of what tf2 can do for you. - It shows off some of the tf2 power in a multi-robot example using turtlesim. - This also introduces using ``tf2_echo``, ``view_frames``, and ``rviz``. - -#. Writing a static broadcaster :doc:`(Python) <./Writing-A-Tf2-Static-Broadcaster-Py>` :doc:`(C++) <./Writing-A-Tf2-Static-Broadcaster-Cpp>`. - - This tutorial teaches you how to broadcast static coordinate frames to tf2. - -#. Writing a broadcaster :doc:`(Python) <./Writing-A-Tf2-Broadcaster-Py>` :doc:`(C++) `. - - This tutorial teaches you how to broadcast the state of a robot to tf2. - -#. Writing a listener :doc:`(Python) <./Writing-A-Tf2-Listener-Py>` :doc:`(C++) <./Writing-A-Tf2-Listener-Cpp>`. - - This tutorial teaches you how to use tf2 to get access to frame transformations. - -#. Adding a frame :doc:`(Python) <./Adding-A-Frame-Py>` :doc:`(C++) `. - - This tutorial teaches you how to add an extra fixed frame to tf2. - -#. Using time :doc:`(C++) `. - - This tutorial teaches you to use the timeout in ``lookup_transform`` function to - wait for a transform to be available on the tf2 tree. - -#. Traveling in time :doc:`(C++) <./Time-Travel-With-Tf2-Cpp>`. - - This tutorial teaches you about advanced time travel features of tf2. - -Debugging tf2 -------------- - -#. :doc:`Quaternion fundamentals <./Quaternion-Fundamentals>`. - - This tutorial teaches you basics of quaternion usage in ROS 2. - -#. :doc:`Debugging tf2 problems <./Debugging-Tf2-Problems>`. - - This tutorial teaches you about a systematic approach for debugging tf2 related problems. - -Using sensor messages with tf2 ------------------------------- - -#. :doc:`Using stamped datatypes with tf2_ros::MessageFilter <./Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter>`. - - This tutorial teaches you how to use ``tf2_ros::MessageFilter`` to process stamped datatypes. +.. redirect-from:: + + Tutorials/Tf2/Tf2-Main + Tutorials/Intermediate/Tf2/Tf2-Main + +.. _Tf2Main: + +``tf2`` +======= + +Many of the tf2 tutorials are available for both C++ and Python. +The tutorials are streamlined to complete either the C++ track or the Python track. +If you want to learn both C++ and Python, you should go through the tutorials once for C++ and once for Python. + +.. contents:: Contents + :depth: 2 + :local: + +.. toctree:: + :hidden: + + Introduction-To-Tf2 + Writing-A-Tf2-Static-Broadcaster-Py + Writing-A-Tf2-Static-Broadcaster-Cpp + Writing-A-Tf2-Broadcaster-Py + Writing-A-Tf2-Broadcaster-Cpp + Writing-A-Tf2-Listener-Py + Writing-A-Tf2-Listener-Cpp + Adding-A-Frame-Py + Adding-A-Frame-Cpp + Learning-About-Tf2-And-Time-Cpp + Time-Travel-With-Tf2-Cpp + Quaternion-Fundamentals + Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter + +Workspace setup +--------------- + +If you have not yet created a workspace in which to complete the tutorials, :doc:`follow this tutorial <../Creating-A-Workspace/Creating-A-Workspace>`. + +Learning tf2 +------------ + +#. :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>`. + + This tutorial will give you a good idea of what tf2 can do for you. + It shows off some of the tf2 power in a multi-robot example using turtlesim. + This also introduces using ``tf2_echo``, ``view_frames``, and ``rviz``. + +#. Writing a static broadcaster :doc:`(Python) ` :doc:`(C++) `. + + This tutorial teaches you how to broadcast static coordinate frames to tf2. + +#. Writing a broadcaster :doc:`(Python) ` :doc:`(C++) `. + + This tutorial teaches you how to broadcast the state of a robot to tf2. + +#. Writing a listener :doc:`(Python) ` :doc:`(C++) `. + + This tutorial teaches you how to use tf2 to get access to frame transformations. + +#. Adding a frame :doc:`(Python) ` :doc:`(C++) `. + + This tutorial teaches you how to add an extra fixed frame to tf2. + +#. Using time :doc:`(C++) `. + + This tutorial teaches you to use the timeout in ``lookup_transform`` function to + wait for a transform to be available on the tf2 tree. + +#. Traveling in time :doc:`(C++) `. + + This tutorial teaches you about advanced time travel features of tf2. + +Debugging tf2 +------------- + +#. :doc:`Quaternion fundamentals <../../../interfaces/Working-with-interfaces/Quaternion-Fundamentals>`. + + This tutorial teaches you basics of quaternion usage in ROS 2. + +#. :doc:`Debugging tf2 problems <../../../../Developer-Tools/Debugging/Debugging-Tf2-Problems>`. + + This tutorial teaches you about a systematic approach for debugging tf2 related problems. + +Using sensor messages with tf2 +------------------------------ + +#. :doc:`Using stamped datatypes with tf2_ros::MessageFilter `. + + This tutorial teaches you how to use ``tf2_ros::MessageFilter`` to process stamped datatypes. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst index 11dfb10a627..75b077b4184 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst @@ -1,158 +1,159 @@ -.. redirect-from:: - - Tutorials/Tf2/Time-Travel-With-Tf2-Cpp - -.. _TimeTravelWithTf2Cpp: - -Traveling in time (C++) -======================= - -**Goal:** Learn about advanced time travel features of tf2. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In the previous tutorial, we discussed the :doc:`basics of tf2 and time <./Learning-About-Tf2-And-Time-Cpp>`. -This tutorial will take us one step further and expose a powerful tf2 trick: the time travel. -In short, one of the key features of tf2 library is that it is able to transform data in time as well as in space. - -This tf2 time travel feature can be useful for various tasks, like monitoring the pose of the robot for a long period of time or building a follower robot that will follow the "steps" of the leader. -We will use that time travel feature to look up transforms back in time and program ``turtle2`` to follow 5 seconds behind ``carrot1``. - -Time travel ------------ - -First, let's go back to where we ended in the previous tutorial :doc:`Using time <./Learning-About-Tf2-And-Time-Cpp>`. -Go to your ``learning_tf2_cpp`` package. - -Now, instead of making the second turtle go to where the carrot is now, we will make the second turtle go to where the first carrot was 5 seconds ago. -Edit the ``lookupTransform()`` call in ``turtle_tf2_listener.cpp`` file to - -.. code-block:: C++ - - rclcpp::Time when = this->get_clock()->now() - rclcpp::Duration(5, 0); - try { - t = tf_buffer_->lookupTransform( - toFrameRel, - fromFrameRel, - when, - 50ms); - } catch (const tf2::TransformException & ex) { - -Now if you run this, during the first 5 seconds, the second turtle would not know where to go because we do not yet have a 5-second history of poses of the carrot. -But what happens after these 5 seconds? -Build the package then let's just give it a try: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.py - -.. image:: images/turtlesim_delay1.png - -You should now notice that your turtle is driving around uncontrollably like in this screenshot. -Let's try to understand reason behind that behavior. - -#. In our code we asked tf2 the following question: "What was the pose of ``carrot1`` 5 seconds ago, relative to ``turtle2`` 5 seconds ago?". - This means we are controlling the second turtle based on where it was 5 seconds ago as well as where the first carrot was 5 seconds ago. - -#. However, what we really want to ask is: "What was the pose of ``carrot1`` 5 seconds ago, relative to the current position of the ``turtle2``?". - -Advanced API for lookupTransform() ----------------------------------- - -To ask the tf2 that particular question, we will use an advanced API that gives us the power to say explicitly when to acquire the specified transformations. -This is done by calling the ``lookupTransform()`` method with additional parameters. -Your code now would look like this: - -.. code-block:: C++ - - rclcpp::Time now = this->get_clock()->now(); - rclcpp::Time when = now - rclcpp::Duration(5, 0); - try { - t = tf_buffer_->lookupTransform( - toFrameRel, - now, - fromFrameRel, - when, - "world", - 50ms); - } catch (const tf2::TransformException & ex) { - -The advanced API for ``lookupTransform()`` takes six arguments: - -#. Target frame - -#. The time to transform to - -#. Source frame - -#. The time at which source frame will be evaluated - -#. Frame that does not change over time, in this case the ``world`` frame - -#. Time to wait for the target frame to become available - -To sum up, tf2 does the following in the background. -In the past, it computes the transform from the ``carrot1`` to the ``world``. -In the ``world`` frame, tf2 time travels from the past to now. -And at the current time, tf2 computes the transform from the ``world`` to the ``turtle2``. - -Checking the results --------------------- - -Build the package then let's run the simulation again, this time with the advanced time-travel API: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.py - -.. image:: images/turtlesim_delay2.png - -And yes, the second turtle is directed to where the first carrot was 5 seconds ago! - -Summary -------- - -In this tutorial, you have seen one of the advanced features of tf2. -You learned that tf2 can transform data in time and learned how to do that with turtlesim example. -tf2 allowed you to go back in time and make frame transformations between old and current poses of turtles by using the advanced ``lookupTransform()`` API. +.. redirect-from:: + + Tutorials/Tf2/Time-Travel-With-Tf2-Cpp + Tutorials/Intermediate/Tf2/Time-Travel-With-Tf2-Cpp + +.. _TimeTravelWithTf2Cpp: + +Traveling in time (C++) +======================= + +**Goal:** Learn about advanced time travel features of tf2. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In the previous tutorial, we discussed the :doc:`basics of tf2 and time `. +This tutorial will take us one step further and expose a powerful tf2 trick: the time travel. +In short, one of the key features of tf2 library is that it is able to transform data in time as well as in space. + +This tf2 time travel feature can be useful for various tasks, like monitoring the pose of the robot for a long period of time or building a follower robot that will follow the "steps" of the leader. +We will use that time travel feature to look up transforms back in time and program ``turtle2`` to follow 5 seconds behind ``carrot1``. + +Time travel +----------- + +First, let's go back to where we ended in the previous tutorial :doc:`Using time `. +Go to your ``learning_tf2_cpp`` package. + +Now, instead of making the second turtle go to where the carrot is now, we will make the second turtle go to where the first carrot was 5 seconds ago. +Edit the ``lookupTransform()`` call in ``turtle_tf2_listener.cpp`` file to + +.. code-block:: C++ + + rclcpp::Time when = this->get_clock()->now() - rclcpp::Duration(5, 0); + try { + t = tf_buffer_->lookupTransform( + toFrameRel, + fromFrameRel, + when, + 50ms); + } catch (const tf2::TransformException & ex) { + +Now if you run this, during the first 5 seconds, the second turtle would not know where to go because we do not yet have a 5-second history of poses of the carrot. +But what happens after these 5 seconds? +Build the package then let's just give it a try: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.py + +.. image:: images/turtlesim_delay1.png + +You should now notice that your turtle is driving around uncontrollably like in this screenshot. +Let's try to understand reason behind that behavior. + +#. In our code we asked tf2 the following question: "What was the pose of ``carrot1`` 5 seconds ago, relative to ``turtle2`` 5 seconds ago?". + This means we are controlling the second turtle based on where it was 5 seconds ago as well as where the first carrot was 5 seconds ago. + +#. However, what we really want to ask is: "What was the pose of ``carrot1`` 5 seconds ago, relative to the current position of the ``turtle2``?". + +Advanced API for lookupTransform() +---------------------------------- + +To ask the tf2 that particular question, we will use an advanced API that gives us the power to say explicitly when to acquire the specified transformations. +This is done by calling the ``lookupTransform()`` method with additional parameters. +Your code now would look like this: + +.. code-block:: C++ + + rclcpp::Time now = this->get_clock()->now(); + rclcpp::Time when = now - rclcpp::Duration(5, 0); + try { + t = tf_buffer_->lookupTransform( + toFrameRel, + now, + fromFrameRel, + when, + "world", + 50ms); + } catch (const tf2::TransformException & ex) { + +The advanced API for ``lookupTransform()`` takes six arguments: + +#. Target frame + +#. The time to transform to + +#. Source frame + +#. The time at which source frame will be evaluated + +#. Frame that does not change over time, in this case the ``world`` frame + +#. Time to wait for the target frame to become available + +To sum up, tf2 does the following in the background. +In the past, it computes the transform from the ``carrot1`` to the ``world``. +In the ``world`` frame, tf2 time travels from the past to now. +And at the current time, tf2 computes the transform from the ``world`` to the ``turtle2``. + +Checking the results +-------------------- + +Build the package then let's run the simulation again, this time with the advanced time-travel API: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_fixed_frame_demo_launch.py + +.. image:: images/turtlesim_delay2.png + +And yes, the second turtle is directed to where the first carrot was 5 seconds ago! + +Summary +------- + +In this tutorial, you have seen one of the advanced features of tf2. +You learned that tf2 can transform data in time and learned how to do that with turtlesim example. +tf2 allowed you to go back in time and make frame transformations between old and current poses of turtles by using the advanced ``lookupTransform()`` API. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst index 08c21018ea7..c40a2916609 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst @@ -1,771 +1,772 @@ -.. redirect-from:: - - Tutorials/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter - -.. _UsingStampedDatatypesWithTf2RosMessageFilter: - -Using stamped datatypes with ``tf2_ros::MessageFilter`` -======================================================= - -**Goal:** Learn how to use ``tf2_ros::MessageFilter`` to process stamped datatypes. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 3 - :local: - -Background ----------- - -This tutorial explains how to use sensor data with tf2. -Some real-world examples of sensor data are: - - * cameras, both mono and stereo - - * laser scans - -Suppose that a new turtle named ``turtle3`` is created and it doesn't have good odometry, but there is an overhead camera tracking its position and publishing it as a ``PointStamped`` message in relation to the ``world`` frame. - -``turtle1`` wants to know where ``turtle3`` is compared to itself. - -To do this ``turtle1`` must listen to the topic where ``turtle3``'s pose is being published, wait until transforms into the desired frame are ready, and then do its operations. -To make this easier the ``tf2_ros::MessageFilter`` is very useful. -The ``tf2_ros::MessageFilter`` will take a subscription to any ROS 2 message with a header and cache it until it is possible to transform it into the target frame. - -Prerequisites -------------- - -This tutorial expects you to have ``turtle_tf2_py`` package installed. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ sudo apt install ros-{DISTRO}-turtle-tf2-py - - .. group-tab:: From Source - - .. code-block:: console - - # Clone the required package repository inside src directory of the ros2_ws - $ git clone https://github.com/ros/geometry_tutorials.git -b ros2 - # Build the required package - $ colcon build --packages-select turtle_tf2_py - -Tasks ------ - -1 Write the broadcaster node of PointStamped messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For this tutorial we will set up a demo application which has a node (in Python) to broadcast the ``PointStamped`` position messages of ``turtle3``. - -First, let's create the source file. - -Go to the ``learning_tf2_py`` :doc:`package <./Writing-A-Tf2-Static-Broadcaster-Py>` we created in the previous tutorial. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example sensor message broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py -o turtle_tf2_message_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py -o turtle_tf2_message_broadcaster.py - -Open the file using your preferred text editor. - -.. code-block:: python - - from geometry_msgs.msg import PointStamped - from geometry_msgs.msg import Twist - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from turtlesim_msgs.msg import Pose - from turtlesim_msgs.srv import Spawn - - - class PointPublisher(Node): - - def __init__(self): - super().__init__('turtle_tf2_message_broadcaster') - - # Create a client to spawn a turtle - self.spawner = self.create_client(Spawn, 'spawn') - # Boolean values to store the information - # if the service for spawning turtle is available - self.turtle_spawning_service_ready = False - # if the turtle was successfully spawned - self.turtle_spawned = False - # if the topics of turtle3 can be subscribed - self.turtle_pose_cansubscribe = False - - self.timer = self.create_timer(1.0, self.on_timer) - - def on_timer(self): - if self.turtle_spawning_service_ready: - if self.turtle_spawned: - self.turtle_pose_cansubscribe = True - else: - if self.result.done(): - self.get_logger().info( - f'Successfully spawned {self.result.result().name}') - self.turtle_spawned = True - else: - self.get_logger().info('Spawn is not finished') - else: - if self.spawner.service_is_ready(): - # Initialize request with turtle name and coordinates - # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn - request = Spawn.Request() - request.name = 'turtle3' - request.x = 4.0 - request.y = 2.0 - request.theta = 0.0 - # Call request - self.result = self.spawner.call_async(request) - self.turtle_spawning_service_ready = True - else: - # Check if the service is ready - self.get_logger().info('Service is not ready') - - if self.turtle_pose_cansubscribe: - self.vel_pub = self.create_publisher(Twist, 'turtle3/cmd_vel', 10) - self.sub = self.create_subscription(Pose, 'turtle3/pose', self.handle_turtle_pose, 10) - self.pub = self.create_publisher(PointStamped, 'turtle3/turtle_point_stamped', 10) - - def handle_turtle_pose(self, msg): - vel_msg = Twist() - vel_msg.linear.x = 1.0 - vel_msg.angular.z = 1.0 - self.vel_pub.publish(vel_msg) - - ps = PointStamped() - ps.header.stamp = self.get_clock().now().to_msg() - ps.header.frame_id = 'world' - ps.point.x = msg.x - ps.point.y = msg.y - ps.point.z = 0.0 - self.pub.publish(ps) - - - def main(): - try: - with rclpy.init(): - node = PointPublisher() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now let's take a look at the code. -First, in the ``on_timer`` callback function, we spawn the ``turtle3`` by asynchronously calling the ``Spawn`` service of ``turtlesim_msgs``, and initialize its position at (4, 2, 0), when the turtle spawning service is ready. - -.. code-block:: python - - # Initialize request with turtle name and coordinates - # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn - request = Spawn.Request() - request.name = 'turtle3' - request.x = 4.0 - request.y = 2.0 - request.theta = 0.0 - # Call request - self.result = self.spawner.call_async(request) - -Afterward, the node publishes the topic ``turtle3/cmd_vel``, topic ``turtle3/turtle_point_stamped``, and subscribes to topic ``turtle3/pose`` and runs callback function ``handle_turtle_pose`` on every incoming message. - -.. code-block:: python - - self.vel_pub = self.create_publisher(Twist, '/turtle3/cmd_vel', 10) - self.sub = self.create_subscription(Pose, '/turtle3/pose', self.handle_turtle_pose, 10) - self.pub = self.create_publisher(PointStamped, '/turtle3/turtle_point_stamped', 10) - -Finally, in the callback function ``handle_turtle_pose``, we initialize the ``Twist`` messages of ``turtle3`` and publish them, which will make the ``turtle3`` move along a circle. -Then we fill up the ``PointStamped`` messages of ``turtle3`` with incoming ``Pose`` messages and publish them. - -.. code-block:: python - - vel_msg = Twist() - vel_msg.linear.x = 1.0 - vel_msg.angular.z = 1.0 - self.vel_pub.publish(vel_msg) - - ps = PointStamped() - ps.header.stamp = self.get_clock().now().to_msg() - ps.header.frame_id = 'world' - ps.point.x = msg.x - ps.point.y = msg.y - ps.point.z = 0.0 - self.pub.publish(ps) - -1.2 Write the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to run this demo, we need to create a launch file ``turtle_tf2_sensor_message_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` subdirectory of package ``learning_tf2_py``: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_sensor_message_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_sensor_message_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_sensor_message_launch.yaml - :language: yaml - - -1.3 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'turtle_tf2_message_broadcaster = learning_tf2_py.turtle_tf2_message_broadcaster:main', - -1.4 Add an data file -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 launch`` command to launch your launch file, you must add the data file to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Import the following libraries at the top, in ``setup.py``: - -.. code-block:: python - - ... - import os - from glob import glob - - -Add the following line between the ``'data_files':`` brackets: - -.. code-block:: python - - data_files=[ - ... - (os.path.join('share', package_name, 'launch'), glob('launch/*')), - ], - -1.5 Build -~~~~~~~~~ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself - -And then we can build the package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - - -2 Writing the message filter/listener node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now, to get the streaming ``PointStamped`` data of ``turtle3`` in the frame of ``turtle1`` reliably, we will create the source file of the message filter/listener node. - -Go to the ``learning_tf2_cpp`` :doc:`package <./Writing-A-Tf2-Static-Broadcaster-Cpp>` we created in the previous tutorial. -Inside the ``src/learning_tf2_cpp/src`` directory download file ``turtle_tf2_message_filter.cpp`` by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp -o turtle_tf2_message_filter.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp -o turtle_tf2_message_filter.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - - #include "geometry_msgs/msg/point_stamped.hpp" - #include "message_filters/subscriber.h" - #include "rclcpp/rclcpp.hpp" - #include "tf2_ros/buffer.h" - #include "tf2_ros/create_timer_ros.h" - #include "tf2_ros/message_filter.h" - #include "tf2_ros/transform_listener.h" - #ifdef TF2_CPP_HEADERS - #include "tf2_geometry_msgs/tf2_geometry_msgs.hpp" - #else - #include "tf2_geometry_msgs/tf2_geometry_msgs.h" - #endif - - using namespace std::chrono_literals; - - class PoseDrawer : public rclcpp::Node - { - public: - PoseDrawer() - : Node("turtle_tf2_pose_drawer") - { - // Declare and acquire `target_frame` parameter - target_frame_ = this->declare_parameter("target_frame", "turtle1"); - - std::chrono::duration buffer_timeout(1); - - tf2_buffer_ = std::make_shared(this->get_clock()); - // Create the timer interface before call to waitForTransform, - // to avoid a tf2_ros::CreateTimerInterfaceException exception - auto timer_interface = std::make_shared( - this->get_node_base_interface(), - this->get_node_timers_interface()); - tf2_buffer_->setCreateTimerInterface(timer_interface); - tf2_listener_ = - std::make_shared(*tf2_buffer_); - - point_sub_.subscribe(this, "/turtle3/turtle_point_stamped"); - tf2_filter_ = std::make_shared>( - point_sub_, *tf2_buffer_, target_frame_, 100, this->get_node_logging_interface(), - this->get_node_clock_interface(), buffer_timeout); - // Register a callback with tf2_ros::MessageFilter to be called when transforms are available - tf2_filter_->registerCallback(&PoseDrawer::msgCallback, this); - } - - private: - void msgCallback(const geometry_msgs::msg::PointStamped::SharedPtr point_ptr) - { - geometry_msgs::msg::PointStamped point_out; - try { - tf2_buffer_->transform(*point_ptr, point_out, target_frame_); - RCLCPP_INFO( - this->get_logger(), "Point of turtle3 in frame of turtle1: x:%f y:%f z:%f\n", - point_out.point.x, - point_out.point.y, - point_out.point.z); - } catch (const tf2::TransformException & ex) { - RCLCPP_WARN( - // Print exception which was caught - this->get_logger(), "Failure %s\n", ex.what()); - } - } - - std::string target_frame_; - std::shared_ptr tf2_buffer_; - std::shared_ptr tf2_listener_; - message_filters::Subscriber point_sub_; - std::shared_ptr> tf2_filter_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -First, you must include the ``tf2_ros::MessageFilter`` headers from the ``tf2_ros`` package, as well as the previously used ``tf2`` and ``ros2`` related headers. - -.. code-block:: C++ - - #include "geometry_msgs/msg/point_stamped.hpp" - #include "message_filters/subscriber.h" - #include "rclcpp/rclcpp.hpp" - #include "tf2_ros/buffer.h" - #include "tf2_ros/create_timer_ros.h" - #include "tf2_ros/message_filter.h" - #include "tf2_ros/transform_listener.h" - #ifdef TF2_CPP_HEADERS - #include "tf2_geometry_msgs/tf2_geometry_msgs.hpp" - #else - #include "tf2_geometry_msgs/tf2_geometry_msgs.h" - #endif - - -Second, there needs to be persistent instances of ``tf2_ros::Buffer``, ``tf2_ros::TransformListener`` and ``tf2_ros::MessageFilter``. - -.. code-block:: C++ - - std::string target_frame_; - std::shared_ptr tf2_buffer_; - std::shared_ptr tf2_listener_; - message_filters::Subscriber point_sub_; - std::shared_ptr> tf2_filter_; - - -Third, the ROS 2 ``message_filters::Subscriber`` must be initialized with the topic. -And the ``tf2_ros::MessageFilter`` must be initialized with that ``Subscriber`` object. -The other arguments of note in the ``MessageFilter`` constructor are the ``target_frame`` and the callback function. -The target frame is the frame into which it will make sure ``canTransform`` will succeed. -And the callback function is the function that will be called when the data is ready. - -.. code-block:: C++ - - PoseDrawer() - : Node("turtle_tf2_pose_drawer") - { - // Declare and acquire `target_frame` parameter - target_frame_ = this->declare_parameter("target_frame", "turtle1"); - - std::chrono::duration buffer_timeout(1); - - tf2_buffer_ = std::make_shared(this->get_clock()); - // Create the timer interface before call to waitForTransform, - // to avoid a tf2_ros::CreateTimerInterfaceException exception - auto timer_interface = std::make_shared( - this->get_node_base_interface(), - this->get_node_timers_interface()); - tf2_buffer_->setCreateTimerInterface(timer_interface); - tf2_listener_ = - std::make_shared(*tf2_buffer_); - - point_sub_.subscribe(this, "/turtle3/turtle_point_stamped"); - tf2_filter_ = std::make_shared>( - point_sub_, *tf2_buffer_, target_frame_, 100, this->get_node_logging_interface(), - this->get_node_clock_interface(), buffer_timeout); - // Register a callback with tf2_ros::MessageFilter to be called when transforms are available - tf2_filter_->registerCallback(&PoseDrawer::msgCallback, this); - } - - -And last, the callback method will call ``tf2_buffer_->transform`` when the data is ready and print output to the console. - -.. code-block:: C++ - - private: - void msgCallback(const geometry_msgs::msg::PointStamped::SharedPtr point_ptr) - { - geometry_msgs::msg::PointStamped point_out; - try { - tf2_buffer_->transform(*point_ptr, point_out, target_frame_); - RCLCPP_INFO( - this->get_logger(), "Point of turtle3 in frame of turtle1: x:%f y:%f z:%f\n", - point_out.point.x, - point_out.point.y, - point_out.point.z); - } catch (const tf2::TransformException & ex) { - RCLCPP_WARN( - // Print exception which was caught - this->get_logger(), "Failure %s\n", ex.what()); - } - } - - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Before building the package ``learning_tf2_cpp``, please add two another dependencies in the ``package.xml`` file of this package: - -.. code-block:: xml - - message_filters - tf2_geometry_msgs - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -And in the ``CMakeLists.txt`` file, add two lines below the existing dependencies: - -.. code-block:: console - - find_package(message_filters REQUIRED) - find_package(tf2_geometry_msgs REQUIRED) - -The lines below will deal with differences between ROS distributions: - -.. code-block:: console - - if(TARGET tf2_geometry_msgs::tf2_geometry_msgs) - get_target_property(_include_dirs tf2_geometry_msgs::tf2_geometry_msgs INTERFACE_INCLUDE_DIRECTORIES) - else() - set(_include_dirs ${tf2_geometry_msgs_INCLUDE_DIRS}) - endif() - - find_file(TF2_CPP_HEADERS - NAMES tf2_geometry_msgs.hpp - PATHS ${_include_dirs} - NO_CACHE - PATH_SUFFIXES tf2_geometry_msgs - ) - -After that, add the executable and name it ``turtle_tf2_message_filter``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - add_executable(turtle_tf2_message_filter src/turtle_tf2_message_filter.cpp) - target_link_libraries( - turtle_tf2_message_filter PUBLIC - geometry_msgs::geometry_msgs - message_filters::message_filters - rclcpp::rclcpp - tf2::tf2 - tf2_geometry_msgs::tf2_geometry_msgs - tf2_ros::tf2_ros - ) - - if(EXISTS ${TF2_CPP_HEADERS}) - target_compile_definitions(turtle_tf2_message_filter PUBLIC -DTF2_CPP_HEADERS) - endif() - -Finally, add the ``install(TARGETS…)`` section (below other existing nodes) so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - turtle_tf2_message_filter - DESTINATION lib/${PROJECT_NAME}) - -2.4 Build -~~~~~~~~~ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself - -Now open a new terminal, navigate to the root of your workspace, and rebuild the package with command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -3 Run -^^^^^ - -First we need to run several nodes (including the broadcaster node of PointStamped messages) by launching the launch file ``turtle_tf2_sensor_message_launch``: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_sensor_message_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_sensor_message_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_sensor_message_launch.py - -This will bring up the ``turtlesim`` window with two turtles, where ``turtle3`` is moving along a circle, while ``turtle1`` isn't moving at first. -But you can run the ``turtle_teleop_key`` node in another terminal to drive ``turtle1`` to move: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -.. image:: images/turtlesim_messagefilter.png - -Now if you echo the topic ``turtle3/turtle_point_stamped``: - -.. code-block:: console - - $ ros2 topic echo /turtle3/turtle_point_stamped - header: - stamp: - sec: 1629877510 - nanosec: 902607040 - frame_id: world - point: - x: 4.989276885986328 - y: 3.073937177658081 - z: 0.0 - --- - header: - stamp: - sec: 1629877510 - nanosec: 918389395 - frame_id: world - point: - x: 4.987966060638428 - y: 3.089883327484131 - z: 0.0 - --- - header: - stamp: - sec: 1629877510 - nanosec: 934186680 - frame_id: world - point: - x: 4.986400127410889 - y: 3.105806589126587 - z: 0.0 - --- - -When the demo is running, open another terminal and run the message filter/listener node: - -.. code-block:: console - - $ ros2 run learning_tf2_cpp turtle_tf2_message_filter - [INFO] [1630016162.006173900] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.493231 y:-2.961614 z:0.000000 - - [INFO] [1630016162.006291983] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.472169 y:-3.004742 z:0.000000 - - [INFO] [1630016162.006326234] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.479420 y:-2.990479 z:0.000000 - - [INFO] [1630016162.006355644] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.486441 y:-2.976102 z:0.000000 - - -Summary -------- - -In this tutorial you learned how to use sensor data/messages in tf2. -Specifically speaking, you learned how to publish ``PointStamped`` messages on a topic, and how to listen to the topic and transform the frame of ``PointStamped`` messages with ``tf2_ros::MessageFilter``. +.. redirect-from:: + + Tutorials/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter + Tutorials/Intermediate/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter + +.. _UsingStampedDatatypesWithTf2RosMessageFilter: + +Using stamped datatypes with ``tf2_ros::MessageFilter`` +======================================================= + +**Goal:** Learn how to use ``tf2_ros::MessageFilter`` to process stamped datatypes. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 3 + :local: + +Background +---------- + +This tutorial explains how to use sensor data with tf2. +Some real-world examples of sensor data are: + + * cameras, both mono and stereo + + * laser scans + +Suppose that a new turtle named ``turtle3`` is created and it doesn't have good odometry, but there is an overhead camera tracking its position and publishing it as a ``PointStamped`` message in relation to the ``world`` frame. + +``turtle1`` wants to know where ``turtle3`` is compared to itself. + +To do this ``turtle1`` must listen to the topic where ``turtle3``'s pose is being published, wait until transforms into the desired frame are ready, and then do its operations. +To make this easier the ``tf2_ros::MessageFilter`` is very useful. +The ``tf2_ros::MessageFilter`` will take a subscription to any ROS 2 message with a header and cache it until it is possible to transform it into the target frame. + +Prerequisites +------------- + +This tutorial expects you to have ``turtle_tf2_py`` package installed. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ sudo apt install ros-{DISTRO}-turtle-tf2-py + + .. group-tab:: From Source + + .. code-block:: console + + # Clone the required package repository inside src directory of the ros2_ws + $ git clone https://github.com/ros/geometry_tutorials.git -b ros2 + # Build the required package + $ colcon build --packages-select turtle_tf2_py + +Tasks +----- + +1 Write the broadcaster node of PointStamped messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For this tutorial we will set up a demo application which has a node (in Python) to broadcast the ``PointStamped`` position messages of ``turtle3``. + +First, let's create the source file. + +Go to the ``learning_tf2_py`` :doc:`package ` we created in the previous tutorial. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example sensor message broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py -o turtle_tf2_message_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_message_broadcaster.py -o turtle_tf2_message_broadcaster.py + +Open the file using your preferred text editor. + +.. code-block:: python + + from geometry_msgs.msg import PointStamped + from geometry_msgs.msg import Twist + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from turtlesim_msgs.msg import Pose + from turtlesim_msgs.srv import Spawn + + + class PointPublisher(Node): + + def __init__(self): + super().__init__('turtle_tf2_message_broadcaster') + + # Create a client to spawn a turtle + self.spawner = self.create_client(Spawn, 'spawn') + # Boolean values to store the information + # if the service for spawning turtle is available + self.turtle_spawning_service_ready = False + # if the turtle was successfully spawned + self.turtle_spawned = False + # if the topics of turtle3 can be subscribed + self.turtle_pose_cansubscribe = False + + self.timer = self.create_timer(1.0, self.on_timer) + + def on_timer(self): + if self.turtle_spawning_service_ready: + if self.turtle_spawned: + self.turtle_pose_cansubscribe = True + else: + if self.result.done(): + self.get_logger().info( + f'Successfully spawned {self.result.result().name}') + self.turtle_spawned = True + else: + self.get_logger().info('Spawn is not finished') + else: + if self.spawner.service_is_ready(): + # Initialize request with turtle name and coordinates + # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn + request = Spawn.Request() + request.name = 'turtle3' + request.x = 4.0 + request.y = 2.0 + request.theta = 0.0 + # Call request + self.result = self.spawner.call_async(request) + self.turtle_spawning_service_ready = True + else: + # Check if the service is ready + self.get_logger().info('Service is not ready') + + if self.turtle_pose_cansubscribe: + self.vel_pub = self.create_publisher(Twist, 'turtle3/cmd_vel', 10) + self.sub = self.create_subscription(Pose, 'turtle3/pose', self.handle_turtle_pose, 10) + self.pub = self.create_publisher(PointStamped, 'turtle3/turtle_point_stamped', 10) + + def handle_turtle_pose(self, msg): + vel_msg = Twist() + vel_msg.linear.x = 1.0 + vel_msg.angular.z = 1.0 + self.vel_pub.publish(vel_msg) + + ps = PointStamped() + ps.header.stamp = self.get_clock().now().to_msg() + ps.header.frame_id = 'world' + ps.point.x = msg.x + ps.point.y = msg.y + ps.point.z = 0.0 + self.pub.publish(ps) + + + def main(): + try: + with rclpy.init(): + node = PointPublisher() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now let's take a look at the code. +First, in the ``on_timer`` callback function, we spawn the ``turtle3`` by asynchronously calling the ``Spawn`` service of ``turtlesim_msgs``, and initialize its position at (4, 2, 0), when the turtle spawning service is ready. + +.. code-block:: python + + # Initialize request with turtle name and coordinates + # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn + request = Spawn.Request() + request.name = 'turtle3' + request.x = 4.0 + request.y = 2.0 + request.theta = 0.0 + # Call request + self.result = self.spawner.call_async(request) + +Afterward, the node publishes the topic ``turtle3/cmd_vel``, topic ``turtle3/turtle_point_stamped``, and subscribes to topic ``turtle3/pose`` and runs callback function ``handle_turtle_pose`` on every incoming message. + +.. code-block:: python + + self.vel_pub = self.create_publisher(Twist, '/turtle3/cmd_vel', 10) + self.sub = self.create_subscription(Pose, '/turtle3/pose', self.handle_turtle_pose, 10) + self.pub = self.create_publisher(PointStamped, '/turtle3/turtle_point_stamped', 10) + +Finally, in the callback function ``handle_turtle_pose``, we initialize the ``Twist`` messages of ``turtle3`` and publish them, which will make the ``turtle3`` move along a circle. +Then we fill up the ``PointStamped`` messages of ``turtle3`` with incoming ``Pose`` messages and publish them. + +.. code-block:: python + + vel_msg = Twist() + vel_msg.linear.x = 1.0 + vel_msg.angular.z = 1.0 + self.vel_pub.publish(vel_msg) + + ps = PointStamped() + ps.header.stamp = self.get_clock().now().to_msg() + ps.header.frame_id = 'world' + ps.point.x = msg.x + ps.point.y = msg.y + ps.point.z = 0.0 + self.pub.publish(ps) + +1.2 Write the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to run this demo, we need to create a launch file ``turtle_tf2_sensor_message_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` subdirectory of package ``learning_tf2_py``: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_sensor_message_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_sensor_message_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_sensor_message_launch.yaml + :language: yaml + + +1.3 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'turtle_tf2_message_broadcaster = learning_tf2_py.turtle_tf2_message_broadcaster:main', + +1.4 Add an data file +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 launch`` command to launch your launch file, you must add the data file to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Import the following libraries at the top, in ``setup.py``: + +.. code-block:: python + + ... + import os + from glob import glob + + +Add the following line between the ``'data_files':`` brackets: + +.. code-block:: python + + data_files=[ + ... + (os.path.join('share', package_name, 'launch'), glob('launch/*')), + ], + +1.5 Build +~~~~~~~~~ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself + +And then we can build the package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + + +2 Writing the message filter/listener node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now, to get the streaming ``PointStamped`` data of ``turtle3`` in the frame of ``turtle1`` reliably, we will create the source file of the message filter/listener node. + +Go to the ``learning_tf2_cpp`` :doc:`package ` we created in the previous tutorial. +Inside the ``src/learning_tf2_cpp/src`` directory download file ``turtle_tf2_message_filter.cpp`` by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp -o turtle_tf2_message_filter.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_message_filter.cpp -o turtle_tf2_message_filter.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + + #include "geometry_msgs/msg/point_stamped.hpp" + #include "message_filters/subscriber.h" + #include "rclcpp/rclcpp.hpp" + #include "tf2_ros/buffer.h" + #include "tf2_ros/create_timer_ros.h" + #include "tf2_ros/message_filter.h" + #include "tf2_ros/transform_listener.h" + #ifdef TF2_CPP_HEADERS + #include "tf2_geometry_msgs/tf2_geometry_msgs.hpp" + #else + #include "tf2_geometry_msgs/tf2_geometry_msgs.h" + #endif + + using namespace std::chrono_literals; + + class PoseDrawer : public rclcpp::Node + { + public: + PoseDrawer() + : Node("turtle_tf2_pose_drawer") + { + // Declare and acquire `target_frame` parameter + target_frame_ = this->declare_parameter("target_frame", "turtle1"); + + std::chrono::duration buffer_timeout(1); + + tf2_buffer_ = std::make_shared(this->get_clock()); + // Create the timer interface before call to waitForTransform, + // to avoid a tf2_ros::CreateTimerInterfaceException exception + auto timer_interface = std::make_shared( + this->get_node_base_interface(), + this->get_node_timers_interface()); + tf2_buffer_->setCreateTimerInterface(timer_interface); + tf2_listener_ = + std::make_shared(*tf2_buffer_); + + point_sub_.subscribe(this, "/turtle3/turtle_point_stamped"); + tf2_filter_ = std::make_shared>( + point_sub_, *tf2_buffer_, target_frame_, 100, this->get_node_logging_interface(), + this->get_node_clock_interface(), buffer_timeout); + // Register a callback with tf2_ros::MessageFilter to be called when transforms are available + tf2_filter_->registerCallback(&PoseDrawer::msgCallback, this); + } + + private: + void msgCallback(const geometry_msgs::msg::PointStamped::SharedPtr point_ptr) + { + geometry_msgs::msg::PointStamped point_out; + try { + tf2_buffer_->transform(*point_ptr, point_out, target_frame_); + RCLCPP_INFO( + this->get_logger(), "Point of turtle3 in frame of turtle1: x:%f y:%f z:%f\n", + point_out.point.x, + point_out.point.y, + point_out.point.z); + } catch (const tf2::TransformException & ex) { + RCLCPP_WARN( + // Print exception which was caught + this->get_logger(), "Failure %s\n", ex.what()); + } + } + + std::string target_frame_; + std::shared_ptr tf2_buffer_; + std::shared_ptr tf2_listener_; + message_filters::Subscriber point_sub_; + std::shared_ptr> tf2_filter_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +First, you must include the ``tf2_ros::MessageFilter`` headers from the ``tf2_ros`` package, as well as the previously used ``tf2`` and ``ros2`` related headers. + +.. code-block:: C++ + + #include "geometry_msgs/msg/point_stamped.hpp" + #include "message_filters/subscriber.h" + #include "rclcpp/rclcpp.hpp" + #include "tf2_ros/buffer.h" + #include "tf2_ros/create_timer_ros.h" + #include "tf2_ros/message_filter.h" + #include "tf2_ros/transform_listener.h" + #ifdef TF2_CPP_HEADERS + #include "tf2_geometry_msgs/tf2_geometry_msgs.hpp" + #else + #include "tf2_geometry_msgs/tf2_geometry_msgs.h" + #endif + + +Second, there needs to be persistent instances of ``tf2_ros::Buffer``, ``tf2_ros::TransformListener`` and ``tf2_ros::MessageFilter``. + +.. code-block:: C++ + + std::string target_frame_; + std::shared_ptr tf2_buffer_; + std::shared_ptr tf2_listener_; + message_filters::Subscriber point_sub_; + std::shared_ptr> tf2_filter_; + + +Third, the ROS 2 ``message_filters::Subscriber`` must be initialized with the topic. +And the ``tf2_ros::MessageFilter`` must be initialized with that ``Subscriber`` object. +The other arguments of note in the ``MessageFilter`` constructor are the ``target_frame`` and the callback function. +The target frame is the frame into which it will make sure ``canTransform`` will succeed. +And the callback function is the function that will be called when the data is ready. + +.. code-block:: C++ + + PoseDrawer() + : Node("turtle_tf2_pose_drawer") + { + // Declare and acquire `target_frame` parameter + target_frame_ = this->declare_parameter("target_frame", "turtle1"); + + std::chrono::duration buffer_timeout(1); + + tf2_buffer_ = std::make_shared(this->get_clock()); + // Create the timer interface before call to waitForTransform, + // to avoid a tf2_ros::CreateTimerInterfaceException exception + auto timer_interface = std::make_shared( + this->get_node_base_interface(), + this->get_node_timers_interface()); + tf2_buffer_->setCreateTimerInterface(timer_interface); + tf2_listener_ = + std::make_shared(*tf2_buffer_); + + point_sub_.subscribe(this, "/turtle3/turtle_point_stamped"); + tf2_filter_ = std::make_shared>( + point_sub_, *tf2_buffer_, target_frame_, 100, this->get_node_logging_interface(), + this->get_node_clock_interface(), buffer_timeout); + // Register a callback with tf2_ros::MessageFilter to be called when transforms are available + tf2_filter_->registerCallback(&PoseDrawer::msgCallback, this); + } + + +And last, the callback method will call ``tf2_buffer_->transform`` when the data is ready and print output to the console. + +.. code-block:: C++ + + private: + void msgCallback(const geometry_msgs::msg::PointStamped::SharedPtr point_ptr) + { + geometry_msgs::msg::PointStamped point_out; + try { + tf2_buffer_->transform(*point_ptr, point_out, target_frame_); + RCLCPP_INFO( + this->get_logger(), "Point of turtle3 in frame of turtle1: x:%f y:%f z:%f\n", + point_out.point.x, + point_out.point.y, + point_out.point.z); + } catch (const tf2::TransformException & ex) { + RCLCPP_WARN( + // Print exception which was caught + this->get_logger(), "Failure %s\n", ex.what()); + } + } + + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Before building the package ``learning_tf2_cpp``, please add two another dependencies in the ``package.xml`` file of this package: + +.. code-block:: xml + + message_filters + tf2_geometry_msgs + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +And in the ``CMakeLists.txt`` file, add two lines below the existing dependencies: + +.. code-block:: console + + find_package(message_filters REQUIRED) + find_package(tf2_geometry_msgs REQUIRED) + +The lines below will deal with differences between ROS distributions: + +.. code-block:: console + + if(TARGET tf2_geometry_msgs::tf2_geometry_msgs) + get_target_property(_include_dirs tf2_geometry_msgs::tf2_geometry_msgs INTERFACE_INCLUDE_DIRECTORIES) + else() + set(_include_dirs ${tf2_geometry_msgs_INCLUDE_DIRS}) + endif() + + find_file(TF2_CPP_HEADERS + NAMES tf2_geometry_msgs.hpp + PATHS ${_include_dirs} + NO_CACHE + PATH_SUFFIXES tf2_geometry_msgs + ) + +After that, add the executable and name it ``turtle_tf2_message_filter``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + add_executable(turtle_tf2_message_filter src/turtle_tf2_message_filter.cpp) + target_link_libraries( + turtle_tf2_message_filter PUBLIC + geometry_msgs::geometry_msgs + message_filters::message_filters + rclcpp::rclcpp + tf2::tf2 + tf2_geometry_msgs::tf2_geometry_msgs + tf2_ros::tf2_ros + ) + + if(EXISTS ${TF2_CPP_HEADERS}) + target_compile_definitions(turtle_tf2_message_filter PUBLIC -DTF2_CPP_HEADERS) + endif() + +Finally, add the ``install(TARGETS…)`` section (below other existing nodes) so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + turtle_tf2_message_filter + DESTINATION lib/${PROJECT_NAME}) + +2.4 Build +~~~~~~~~~ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim_msgs`` dependencies yourself + +Now open a new terminal, navigate to the root of your workspace, and rebuild the package with command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +3 Run +^^^^^ + +First we need to run several nodes (including the broadcaster node of PointStamped messages) by launching the launch file ``turtle_tf2_sensor_message_launch``: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_sensor_message_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_sensor_message_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_sensor_message_launch.py + +This will bring up the ``turtlesim`` window with two turtles, where ``turtle3`` is moving along a circle, while ``turtle1`` isn't moving at first. +But you can run the ``turtle_teleop_key`` node in another terminal to drive ``turtle1`` to move: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +.. image:: images/turtlesim_messagefilter.png + +Now if you echo the topic ``turtle3/turtle_point_stamped``: + +.. code-block:: console + + $ ros2 topic echo /turtle3/turtle_point_stamped + header: + stamp: + sec: 1629877510 + nanosec: 902607040 + frame_id: world + point: + x: 4.989276885986328 + y: 3.073937177658081 + z: 0.0 + --- + header: + stamp: + sec: 1629877510 + nanosec: 918389395 + frame_id: world + point: + x: 4.987966060638428 + y: 3.089883327484131 + z: 0.0 + --- + header: + stamp: + sec: 1629877510 + nanosec: 934186680 + frame_id: world + point: + x: 4.986400127410889 + y: 3.105806589126587 + z: 0.0 + --- + +When the demo is running, open another terminal and run the message filter/listener node: + +.. code-block:: console + + $ ros2 run learning_tf2_cpp turtle_tf2_message_filter + [INFO] [1630016162.006173900] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.493231 y:-2.961614 z:0.000000 + + [INFO] [1630016162.006291983] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.472169 y:-3.004742 z:0.000000 + + [INFO] [1630016162.006326234] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.479420 y:-2.990479 z:0.000000 + + [INFO] [1630016162.006355644] [turtle_tf2_pose_drawer]: Point of turtle3 in frame of turtle1: x:-6.486441 y:-2.976102 z:0.000000 + + +Summary +------- + +In this tutorial you learned how to use sensor data/messages in tf2. +Specifically speaking, you learned how to publish ``PointStamped`` messages on a topic, and how to listen to the topic and transform the frame of ``PointStamped`` messages with ``tf2_ros::MessageFilter``. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst index 9296083f96f..efae2bab67d 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst @@ -1,493 +1,494 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Cpp - -Writing a broadcaster (C++) -=========================== - -**Goal:** Learn how to broadcast the state of a robot to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <./Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. - -Prerequisites -------------- - -This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <./Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (C++) <./Writing-A-Tf2-Static-Broadcaster-Cpp>`. -We'll be reusing the ``learning_tf2_cpp`` package from that last tutorial. - -In previous tutorials, you learned how to :doc:`create a workspace <../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Write the broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. -Inside the ``src`` directory download the example broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2/LinearMath/Quaternion.hpp" - #include "tf2_ros/transform_broadcaster.h" - #include "turtlesim_msgs/msg/pose.hpp" - - class FramePublisher : public rclcpp::Node - { - public: - FramePublisher() - : Node("turtle_tf2_frame_publisher") - { - // Declare and acquire `turtlename` parameter - turtlename_ = this->declare_parameter("turtlename", "turtle"); - - // Initialize the transform broadcaster - tf_broadcaster_ = - std::make_unique(*this); - - // Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose - // callback function on each message - std::ostringstream stream; - stream << "/" << turtlename_.c_str() << "/pose"; - std::string topic_name = stream.str(); - - auto handle_turtle_pose = [this](const std::shared_ptr msg){ - geometry_msgs::msg::TransformStamped t; - - // Read message content and assign it to - // corresponding tf variables - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = turtlename_.c_str(); - - // Turtle only exists in 2D, thus we get x and y translation - // coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg->x; - t.transform.translation.y = msg->y; - t.transform.translation.z = 0.0; - - // For the same reason, turtle can only rotate around one axis - // and this why we set rotation in x and y to 0 and obtain - // rotation in z axis from the message - tf2::Quaternion q; - q.setRPY(0, 0, msg->theta); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - - // Send the transformation - tf_broadcaster_->sendTransform(t); - }; - subscription_ = this->create_subscription( - topic_name, 10, - handle_turtle_pose); - } - - private: - rclcpp::Subscription::SharedPtr subscription_; - std::unique_ptr tf_broadcaster_; - std::string turtlename_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. -Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. - -.. code-block:: C++ - - turtlename_ = this->declare_parameter("turtlename", "turtle"); - -Afterward, the node subscribes to topic ``turtleX/pose`` and runs function ``handle_turtle_pose`` on every incoming message. - -.. code-block:: C++ - - subscription_ = this->create_subscription( - topic_name, 10, - handle_turtle_pose); - -Now, we create a ``TransformStamped`` object and give it the appropriate metadata. - -#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``this->get_clock()->now()``. - This will return the current time used by the ``Node``. - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. - -#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. - -The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. - -.. code-block:: C++ - - geometry_msgs::msg::TransformStamped t; - - // Read message content and assign it to - // corresponding tf variables - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = turtlename_.c_str(); - -Here we copy the information from the 3D turtle pose into the 3D transform. - -.. code-block:: C++ - - // Turtle only exists in 2D, thus we get x and y translation - // coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg->x; - t.transform.translation.y = msg->y; - t.transform.translation.z = 0.0; - - // For the same reason, turtle can only rotate around one axis - // and this why we set rotation in x and y to 0 and obtain - // rotation in z axis from the message - tf2::Quaternion q; - q.setRPY(0, 0, msg->theta); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - -Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. - -.. code-block:: C++ - - // Send the transformation - tf_broadcaster_->sendTransform(t); - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - find_package(turtlesim_msgs REQUIRED) - add_executable(turtle_tf2_broadcaster src/turtle_tf2_broadcaster.cpp) - target_link_libraries( - turtle_tf2_broadcaster PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2::tf2 - tf2_ros::tf2_ros - turtlesim_msgs::turtlesim_msgs - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - turtle_tf2_broadcaster - DESTINATION lib/${PROJECT_NAME}) - -2 Write the launch file -^^^^^^^^^^^^^^^^^^^^^^^ - -Now create a launch file for this demo. -Create a ``launch`` folder in the ``src/learning_tf2_cpp`` directory. -With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_demo_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_demo_launch.py - :language: python - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Let's examine the launch file structure. -Each format has its own way of setting up the launch file: - -.. tabs:: - - .. group-tab:: XML - - XML launch files start with an XML declaration and a root ```` element. - - .. literalinclude:: launch/turtle_tf2_demo_launch.xml - :language: xml - :lines: 1-2 - - .. group-tab:: YAML - - YAML launch files start with a YAML version declaration and a ``launch:`` key. - - .. literalinclude:: launch/turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 1-3 - - .. group-tab:: Python - - In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. - It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. - - .. literalinclude:: launch/turtle_tf2_demo_launch.py - :language: python - :lines: 1-2 - -Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_demo_launch.xml - :language: xml - :lines: 3-6 - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 4-9 - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_demo_launch.py - :language: python - :lines: 5-20 - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Open ``package.xml`` with your text editor. -Add the following dependencies corresponding to your launch file's import statements: - -.. code-block:: xml - - launch - launch_ros - -This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. - -Make sure to save the file. - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Reopen ``CMakeLists.txt`` and add the line so that the launch files from the ``launch/`` folder will be installed. - -.. code-block:: console - - install(DIRECTORY launch - DESTINATION share/${PROJECT_NAME}) - -You can learn more about creating launch files in :doc:`this tutorial <../Launch/Creating-Launch-Files>`. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -4 Run -^^^^^ - -Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py - -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -You will now see that the turtlesim simulation have started with one turtle that you can control. - -.. image:: images/turtlesim_broadcast.png - -Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo world turtle1 - -This should show you the pose of the first turtle. -Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). -In your console output you will see something similar to this: - -.. code-block:: console - - At time 1625137663.912474878 - - Translation: [5.276, 7.930, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] - At time 1625137664.950813527 - - Translation: [3.750, 6.563, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] - At time 1625137665.906280726 - - Translation: [2.320, 5.282, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] - At time 1625137666.850775673 - - Translation: [2.153, 5.133, 0.000] - - Rotation: in Quaternion [0.000, 0.000, -0.365, 0.931] - -If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. -However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. - -Summary -------- - -In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. -To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener <./Writing-A-Tf2-Listener-Cpp>`. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Cpp + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Cpp + +Writing a broadcaster (C++) +=========================== + +**Goal:** Learn how to broadcast the state of a robot to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. + +Prerequisites +------------- + +This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (C++) `. +We'll be reusing the ``learning_tf2_cpp`` package from that last tutorial. + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Write the broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. +Inside the ``src`` directory download the example broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2/LinearMath/Quaternion.hpp" + #include "tf2_ros/transform_broadcaster.h" + #include "turtlesim_msgs/msg/pose.hpp" + + class FramePublisher : public rclcpp::Node + { + public: + FramePublisher() + : Node("turtle_tf2_frame_publisher") + { + // Declare and acquire `turtlename` parameter + turtlename_ = this->declare_parameter("turtlename", "turtle"); + + // Initialize the transform broadcaster + tf_broadcaster_ = + std::make_unique(*this); + + // Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose + // callback function on each message + std::ostringstream stream; + stream << "/" << turtlename_.c_str() << "/pose"; + std::string topic_name = stream.str(); + + auto handle_turtle_pose = [this](const std::shared_ptr msg){ + geometry_msgs::msg::TransformStamped t; + + // Read message content and assign it to + // corresponding tf variables + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = turtlename_.c_str(); + + // Turtle only exists in 2D, thus we get x and y translation + // coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg->x; + t.transform.translation.y = msg->y; + t.transform.translation.z = 0.0; + + // For the same reason, turtle can only rotate around one axis + // and this why we set rotation in x and y to 0 and obtain + // rotation in z axis from the message + tf2::Quaternion q; + q.setRPY(0, 0, msg->theta); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + + // Send the transformation + tf_broadcaster_->sendTransform(t); + }; + subscription_ = this->create_subscription( + topic_name, 10, + handle_turtle_pose); + } + + private: + rclcpp::Subscription::SharedPtr subscription_; + std::unique_ptr tf_broadcaster_; + std::string turtlename_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. +Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. + +.. code-block:: C++ + + turtlename_ = this->declare_parameter("turtlename", "turtle"); + +Afterward, the node subscribes to topic ``turtleX/pose`` and runs function ``handle_turtle_pose`` on every incoming message. + +.. code-block:: C++ + + subscription_ = this->create_subscription( + topic_name, 10, + handle_turtle_pose); + +Now, we create a ``TransformStamped`` object and give it the appropriate metadata. + +#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``this->get_clock()->now()``. + This will return the current time used by the ``Node``. + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. + +#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. + +The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. + +.. code-block:: C++ + + geometry_msgs::msg::TransformStamped t; + + // Read message content and assign it to + // corresponding tf variables + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = turtlename_.c_str(); + +Here we copy the information from the 3D turtle pose into the 3D transform. + +.. code-block:: C++ + + // Turtle only exists in 2D, thus we get x and y translation + // coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg->x; + t.transform.translation.y = msg->y; + t.transform.translation.z = 0.0; + + // For the same reason, turtle can only rotate around one axis + // and this why we set rotation in x and y to 0 and obtain + // rotation in z axis from the message + tf2::Quaternion q; + q.setRPY(0, 0, msg->theta); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + +Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. + +.. code-block:: C++ + + // Send the transformation + tf_broadcaster_->sendTransform(t); + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + find_package(turtlesim_msgs REQUIRED) + add_executable(turtle_tf2_broadcaster src/turtle_tf2_broadcaster.cpp) + target_link_libraries( + turtle_tf2_broadcaster PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2::tf2 + tf2_ros::tf2_ros + turtlesim_msgs::turtlesim_msgs + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + turtle_tf2_broadcaster + DESTINATION lib/${PROJECT_NAME}) + +2 Write the launch file +^^^^^^^^^^^^^^^^^^^^^^^ + +Now create a launch file for this demo. +Create a ``launch`` folder in the ``src/learning_tf2_cpp`` directory. +With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_demo_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_demo_launch.py + :language: python + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Let's examine the launch file structure. +Each format has its own way of setting up the launch file: + +.. tabs:: + + .. group-tab:: XML + + XML launch files start with an XML declaration and a root ```` element. + + .. literalinclude:: launch/turtle_tf2_demo_launch.xml + :language: xml + :lines: 1-2 + + .. group-tab:: YAML + + YAML launch files start with a YAML version declaration and a ``launch:`` key. + + .. literalinclude:: launch/turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 1-3 + + .. group-tab:: Python + + In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. + It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. + + .. literalinclude:: launch/turtle_tf2_demo_launch.py + :language: python + :lines: 1-2 + +Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_demo_launch.xml + :language: xml + :lines: 3-6 + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 4-9 + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_demo_launch.py + :language: python + :lines: 5-20 + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Open ``package.xml`` with your text editor. +Add the following dependencies corresponding to your launch file's import statements: + +.. code-block:: xml + + launch + launch_ros + +This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. + +Make sure to save the file. + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Reopen ``CMakeLists.txt`` and add the line so that the launch files from the ``launch/`` folder will be installed. + +.. code-block:: console + + install(DIRECTORY launch + DESTINATION share/${PROJECT_NAME}) + +You can learn more about creating launch files in :doc:`this tutorial <../../../../Developer-Tools/Launch/Creating-Launch-Files>`. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +4 Run +^^^^^ + +Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py + +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +You will now see that the turtlesim simulation have started with one turtle that you can control. + +.. image:: images/turtlesim_broadcast.png + +Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo world turtle1 + +This should show you the pose of the first turtle. +Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). +In your console output you will see something similar to this: + +.. code-block:: console + + At time 1625137663.912474878 + - Translation: [5.276, 7.930, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] + At time 1625137664.950813527 + - Translation: [3.750, 6.563, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] + At time 1625137665.906280726 + - Translation: [2.320, 5.282, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] + At time 1625137666.850775673 + - Translation: [2.153, 5.133, 0.000] + - Rotation: in Quaternion [0.000, 0.000, -0.365, 0.931] + +If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. +However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. + +Summary +------- + +In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. +To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst index 27e00a956d2..a6474d78dab 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst @@ -1,511 +1,512 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Py - -Writing a broadcaster (Python) -============================== - -**Goal:** Learn how to broadcast the state of a robot to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <./Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. - -Prerequisites -------------- - -This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <./Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (Python) <./Writing-A-Tf2-Static-Broadcaster-Py>`. -We'll be reusing the ``learning_tf2_py`` package from that last tutorial. - -In previous tutorials, you learned how to :doc:`create a workspace <../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Write the broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_py`` package we created in the previous tutorial. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py - -Now open the file called ``turtle_tf2_broadcaster.py`` using your preferred text editor. - -.. code-block:: python - - import math - - from geometry_msgs.msg import TransformStamped - - import numpy as np - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros import TransformBroadcaster - - from turtlesim_msgs.msg import Pose - - - def quaternion_from_euler(ai, aj, ak): - ai /= 2.0 - aj /= 2.0 - ak /= 2.0 - ci = math.cos(ai) - si = math.sin(ai) - cj = math.cos(aj) - sj = math.sin(aj) - ck = math.cos(ak) - sk = math.sin(ak) - cc = ci*ck - cs = ci*sk - sc = si*ck - ss = si*sk - - q = np.empty((4, )) - q[0] = cj*sc - sj*cs - q[1] = cj*ss + sj*cc - q[2] = cj*cs - sj*sc - q[3] = cj*cc + sj*ss - - return q - - - class FramePublisher(Node): - - def __init__(self): - super().__init__('turtle_tf2_frame_publisher') - - # Declare and acquire `turtlename` parameter - self.turtlename = self.declare_parameter( - 'turtlename', 'turtle').get_parameter_value().string_value - - # Initialize the transform broadcaster - self.tf_broadcaster = TransformBroadcaster(self) - - # Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose - # callback function on each message - self.subscription = self.create_subscription( - Pose, - f'/{self.turtlename}/pose', - self.handle_turtle_pose, - 1) - self.subscription # prevent unused variable warning - - def handle_turtle_pose(self, msg): - t = TransformStamped() - - # Read message content and assign it to - # corresponding tf variables - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = self.turtlename - - # Turtle only exists in 2D, thus we get x and y translation - # coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg.x - t.transform.translation.y = msg.y - t.transform.translation.z = 0.0 - - # For the same reason, turtle can only rotate around one axis - # and this why we set rotation in x and y to 0 and obtain - # rotation in z axis from the message - q = quaternion_from_euler(0, 0, msg.theta) - t.transform.rotation.x = q[0] - t.transform.rotation.y = q[1] - t.transform.rotation.z = q[2] - t.transform.rotation.w = q[3] - - # Send the transformation - self.tf_broadcaster.sendTransform(t) - - - def main(): - try: - with rclpy.init(): - node = FramePublisher() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. -Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. - -.. code-block:: python - - self.turtlename = self.declare_parameter( - 'turtlename', 'turtle').get_parameter_value().string_value - -Afterward, the node subscribes to topic ``{self.turtlename}/pose`` and runs function ``handle_turtle_pose`` on every incoming message. - -.. code-block:: python - - self .subscription = self.create_subscription( - Pose, - f'/{self.turtlename}/pose', - self.handle_turtle_pose, - 1) - -Now, we create a ``TransformStamped`` object and give it the appropriate metadata. - -#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``self.get_clock().now()``. - This will return the current time used by the ``Node``. - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. - -#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. - -The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. - -.. code-block:: python - - t = TransformStamped() - - # Read message content and assign it to - # corresponding tf variables - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = self.turtlename - -Here we copy the information from the 3D turtle pose into the 3D transform. - -.. code-block:: python - - # Turtle only exists in 2D, thus we get x and y translation - # coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg.x - t.transform.translation.y = msg.y - t.transform.translation.z = 0.0 - - # For the same reason, turtle can only rotate around one axis - # and this why we set rotation in x and y to 0 and obtain - # rotation in z axis from the message - q = quaternion_from_euler(0, 0, msg.theta) - t.transform.rotation.x = q[0] - t.transform.rotation.y = q[1] - t.transform.rotation.z = q[2] - t.transform.rotation.w = q[3] - -Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. - -.. code-block:: python - - # Send the transformation - self.tf_broadcaster.sendTransform(t) - -1.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point -to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'turtle_tf2_broadcaster = learning_tf2_py.turtle_tf2_broadcaster:main', - -2 Write the launch file -^^^^^^^^^^^^^^^^^^^^^^^ - -Now create a launch file for this demo. -Create a ``launch`` folder in the ``src/learning_tf2_py`` directory. -With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml - :language: xml - :name: turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml - :language: yaml - :name: turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.py - :language: python - :name: turtle_tf2_demo_launch.py - - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Let's examine the launch file structure. -Each format has its own way of setting up the launch file: - -.. tabs:: - - .. group-tab:: XML - - XML launch files start with an XML declaration and a root ```` element. - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml - :language: xml - :lines: 1-2 - - .. group-tab:: YAML - - YAML launch files start with a YAML version declaration and a ``launch:`` key. - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 1-3 - - .. group-tab:: Python - - In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. - It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.py - :language: python - :lines: 1-2 - -Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml - :language: xml - :lines: 3-6 - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 4-9 - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.py - :language: python - :lines: 5-20 - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files are located. - -Open ``package.xml`` with your text editor. -Add the following dependencies corresponding to your launch file's import statements: - -.. code-block:: xml - - launch - launch_ros - -This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. - -Make sure to save the file. - -2.3 Update setup.py -~~~~~~~~~~~~~~~~~~~ - -Reopen ``setup.py`` and add the line so that the launch files from the ``launch/`` folder will be installed. -The ``data_files`` field should now look like this: - -.. code-block:: python - - data_files=[ - ... - (os.path.join('share', package_name, 'launch'), glob('launch/*')), - ], - -Also add the appropriate imports at the top of the file: - -.. code-block:: python - - import os - from glob import glob - -You can learn more about creating launch files in :doc:`this tutorial <../Launch/Creating-Launch-Files>`. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - -4 Run -^^^^^ - -Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py - -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -You will now see that the turtlesim simulation has started with one turtle that you can control. - -.. image:: images/turtlesim_broadcast.png - -Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo world turtle1 - -This should show you the pose of the first turtle. -Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). -In your console output you will see something similar to this: - -.. code-block:: console - - At time 1714913843.708748879 - - Translation: [4.541, 3.889, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.999, -0.035] - - Rotation: in RPY (radian) [0.000, -0.000, -3.072] - - Rotation: in RPY (degree) [0.000, -0.000, -176.013] - - Matrix: - -0.998 0.070 0.000 4.541 - -0.070 -0.998 0.000 3.889 - 0.000 0.000 1.000 0.000 - 0.000 0.000 0.000 1.000 - -If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. -However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. - -Summary -------- - -In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. -To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener <./Writing-A-Tf2-Listener-Py>`. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Py + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Py + +Writing a broadcaster (Python) +============================== + +**Goal:** Learn how to broadcast the state of a robot to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. + +Prerequisites +------------- + +This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (Python) `. +We'll be reusing the ``learning_tf2_py`` package from that last tutorial. + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Write the broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_py`` package we created in the previous tutorial. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py + +Now open the file called ``turtle_tf2_broadcaster.py`` using your preferred text editor. + +.. code-block:: python + + import math + + from geometry_msgs.msg import TransformStamped + + import numpy as np + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros import TransformBroadcaster + + from turtlesim_msgs.msg import Pose + + + def quaternion_from_euler(ai, aj, ak): + ai /= 2.0 + aj /= 2.0 + ak /= 2.0 + ci = math.cos(ai) + si = math.sin(ai) + cj = math.cos(aj) + sj = math.sin(aj) + ck = math.cos(ak) + sk = math.sin(ak) + cc = ci*ck + cs = ci*sk + sc = si*ck + ss = si*sk + + q = np.empty((4, )) + q[0] = cj*sc - sj*cs + q[1] = cj*ss + sj*cc + q[2] = cj*cs - sj*sc + q[3] = cj*cc + sj*ss + + return q + + + class FramePublisher(Node): + + def __init__(self): + super().__init__('turtle_tf2_frame_publisher') + + # Declare and acquire `turtlename` parameter + self.turtlename = self.declare_parameter( + 'turtlename', 'turtle').get_parameter_value().string_value + + # Initialize the transform broadcaster + self.tf_broadcaster = TransformBroadcaster(self) + + # Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose + # callback function on each message + self.subscription = self.create_subscription( + Pose, + f'/{self.turtlename}/pose', + self.handle_turtle_pose, + 1) + self.subscription # prevent unused variable warning + + def handle_turtle_pose(self, msg): + t = TransformStamped() + + # Read message content and assign it to + # corresponding tf variables + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = self.turtlename + + # Turtle only exists in 2D, thus we get x and y translation + # coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg.x + t.transform.translation.y = msg.y + t.transform.translation.z = 0.0 + + # For the same reason, turtle can only rotate around one axis + # and this why we set rotation in x and y to 0 and obtain + # rotation in z axis from the message + q = quaternion_from_euler(0, 0, msg.theta) + t.transform.rotation.x = q[0] + t.transform.rotation.y = q[1] + t.transform.rotation.z = q[2] + t.transform.rotation.w = q[3] + + # Send the transformation + self.tf_broadcaster.sendTransform(t) + + + def main(): + try: + with rclpy.init(): + node = FramePublisher() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. +Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. + +.. code-block:: python + + self.turtlename = self.declare_parameter( + 'turtlename', 'turtle').get_parameter_value().string_value + +Afterward, the node subscribes to topic ``{self.turtlename}/pose`` and runs function ``handle_turtle_pose`` on every incoming message. + +.. code-block:: python + + self .subscription = self.create_subscription( + Pose, + f'/{self.turtlename}/pose', + self.handle_turtle_pose, + 1) + +Now, we create a ``TransformStamped`` object and give it the appropriate metadata. + +#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``self.get_clock().now()``. + This will return the current time used by the ``Node``. + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. + +#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. + +The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. + +.. code-block:: python + + t = TransformStamped() + + # Read message content and assign it to + # corresponding tf variables + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = self.turtlename + +Here we copy the information from the 3D turtle pose into the 3D transform. + +.. code-block:: python + + # Turtle only exists in 2D, thus we get x and y translation + # coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg.x + t.transform.translation.y = msg.y + t.transform.translation.z = 0.0 + + # For the same reason, turtle can only rotate around one axis + # and this why we set rotation in x and y to 0 and obtain + # rotation in z axis from the message + q = quaternion_from_euler(0, 0, msg.theta) + t.transform.rotation.x = q[0] + t.transform.rotation.y = q[1] + t.transform.rotation.z = q[2] + t.transform.rotation.w = q[3] + +Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. + +.. code-block:: python + + # Send the transformation + self.tf_broadcaster.sendTransform(t) + +1.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point +to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'turtle_tf2_broadcaster = learning_tf2_py.turtle_tf2_broadcaster:main', + +2 Write the launch file +^^^^^^^^^^^^^^^^^^^^^^^ + +Now create a launch file for this demo. +Create a ``launch`` folder in the ``src/learning_tf2_py`` directory. +With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml + :language: xml + :name: turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml + :language: yaml + :name: turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.py + :language: python + :name: turtle_tf2_demo_launch.py + + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Let's examine the launch file structure. +Each format has its own way of setting up the launch file: + +.. tabs:: + + .. group-tab:: XML + + XML launch files start with an XML declaration and a root ```` element. + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml + :language: xml + :lines: 1-2 + + .. group-tab:: YAML + + YAML launch files start with a YAML version declaration and a ``launch:`` key. + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 1-3 + + .. group-tab:: Python + + In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. + It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.py + :language: python + :lines: 1-2 + +Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml + :language: xml + :lines: 3-6 + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 4-9 + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.py + :language: python + :lines: 5-20 + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files are located. + +Open ``package.xml`` with your text editor. +Add the following dependencies corresponding to your launch file's import statements: + +.. code-block:: xml + + launch + launch_ros + +This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. + +Make sure to save the file. + +2.3 Update setup.py +~~~~~~~~~~~~~~~~~~~ + +Reopen ``setup.py`` and add the line so that the launch files from the ``launch/`` folder will be installed. +The ``data_files`` field should now look like this: + +.. code-block:: python + + data_files=[ + ... + (os.path.join('share', package_name, 'launch'), glob('launch/*')), + ], + +Also add the appropriate imports at the top of the file: + +.. code-block:: python + + import os + from glob import glob + +You can learn more about creating launch files in :doc:`this tutorial <../../../../Developer-Tools/Launch/Creating-Launch-Files>`. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + +4 Run +^^^^^ + +Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py + +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +You will now see that the turtlesim simulation has started with one turtle that you can control. + +.. image:: images/turtlesim_broadcast.png + +Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo world turtle1 + +This should show you the pose of the first turtle. +Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). +In your console output you will see something similar to this: + +.. code-block:: console + + At time 1714913843.708748879 + - Translation: [4.541, 3.889, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.999, -0.035] + - Rotation: in RPY (radian) [0.000, -0.000, -3.072] + - Rotation: in RPY (degree) [0.000, -0.000, -176.013] + - Matrix: + -0.998 0.070 0.000 4.541 + -0.070 -0.998 0.000 3.889 + 0.000 0.000 1.000 0.000 + 0.000 0.000 0.000 1.000 + +If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. +However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. + +Summary +------- + +In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. +To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst index 24207958340..5f724368f78 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst @@ -1,414 +1,415 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Listener-Cpp - -Writing a listener (C++) -======================== - -**Goal:** Learn how to use tf2 to get access to frame transformations. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. - -In this tutorial we'll create a tf2 listener to start using tf2. - -Prerequisites -------------- - -This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (C++) <./Writing-A-Tf2-Static-Broadcaster-Cpp>` and the :doc:`tf2 broadcaster tutorial (C++) <./Writing-A-Tf2-Broadcaster-Cpp>`. -In the previous tutorial, we created a ``learning_tf2_cpp`` package, which is where we will continue working from. - -Tasks ------ - -1 Write the listener node -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. -Inside the ``src`` directory download the example listener code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "geometry_msgs/msg/twist.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2/exceptions.hpp" - #include "tf2_ros/transform_listener.h" - #include "tf2_ros/buffer.h" - #include "turtlesim_msgs/srv/spawn.hpp" - - using namespace std::chrono_literals; - - class FrameListener : public rclcpp::Node - { - public: - FrameListener() - : Node("turtle_tf2_frame_listener"), - turtle_spawning_service_ready_(false), - turtle_spawned_(false) - { - // Declare and acquire `target_frame` parameter - target_frame_ = this->declare_parameter("target_frame", "turtle1"); - - tf_buffer_ = - std::make_unique(this->get_clock()); - tf_listener_ = - std::make_shared(*tf_buffer_); - - // Create a client to spawn a turtle - spawner_ = - this->create_client("spawn"); - - // Create turtle2 velocity publisher - publisher_ = - this->create_publisher("turtle2/cmd_vel", 1); - - // Call on_timer function every second - timer_ = this->create_wall_timer( - 1s, [this]() {return this->on_timer();}); - } - - private: - void on_timer() - { - // Store frame names in variables that will be used to - // compute transformations - std::string fromFrameRel = target_frame_.c_str(); - std::string toFrameRel = "turtle2"; - - if (turtle_spawning_service_ready_) { - if (turtle_spawned_) { - geometry_msgs::msg::TransformStamped t; - - // Look up for the transformation between target_frame and turtle2 frames - // and send velocity commands for turtle2 to reach target_frame - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePointZero); - } catch (const tf2::TransformException & ex) { - RCLCPP_INFO( - this->get_logger(), "Could not transform %s to %s: %s", - toFrameRel.c_str(), fromFrameRel.c_str(), ex.what()); - return; - } - - geometry_msgs::msg::Twist msg; - - static const double scaleRotationRate = 1.0; - msg.angular.z = scaleRotationRate * atan2( - t.transform.translation.y, - t.transform.translation.x); - - static const double scaleForwardSpeed = 0.5; - msg.linear.x = scaleForwardSpeed * sqrt( - pow(t.transform.translation.x, 2) + - pow(t.transform.translation.y, 2)); - - publisher_->publish(msg); - } else { - RCLCPP_INFO(this->get_logger(), "Successfully spawned"); - turtle_spawned_ = true; - } - } else { - // Check if the service is ready - if (spawner_->service_is_ready()) { - // Initialize request with turtle name and coordinates - // Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn - auto request = std::make_shared(); - request->x = 4.0; - request->y = 2.0; - request->theta = 0.0; - request->name = "turtle2"; - - // Call request - using ServiceResponseFuture = - rclcpp::Client::SharedFuture; - auto response_received_callback = [this](ServiceResponseFuture future) { - auto result = future.get(); - if (strcmp(result->name.c_str(), "turtle2") == 0) { - turtle_spawning_service_ready_ = true; - } else { - RCLCPP_ERROR(this->get_logger(), "Service callback result mismatch"); - } - }; - auto result = spawner_->async_send_request(request, response_received_callback); - } else { - RCLCPP_INFO(this->get_logger(), "Service is not ready"); - } - } - } - - // Boolean values to store the information - // if the service for spawning turtle is available - bool turtle_spawning_service_ready_; - // if the turtle was successfully spawned - bool turtle_spawned_; - rclcpp::Client::SharedPtr spawner_{nullptr}; - rclcpp::TimerBase::SharedPtr timer_{nullptr}; - rclcpp::Publisher::SharedPtr publisher_{nullptr}; - std::shared_ptr tf_listener_{nullptr}; - std::unique_ptr tf_buffer_; - std::string target_frame_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (C++) <../../Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>` tutorial. - -Now, let's take a look at the code that is relevant to get access to frame transformations. -The ``tf2_ros`` contains a ``TransformListener`` class that makes the task of receiving transforms easier. - -.. code-block:: C++ - - #include "tf2_ros/transform_listener.h" - -Here, we create a ``TransformListener`` object. -Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. - -.. code-block:: C++ - - tf_listener_ = - std::make_shared(*tf_buffer_); - -Finally, we query the listener for a specific transformation. -We call ``lookup_transform`` method with following arguments: - -#. Target frame - -#. Source frame - -#. The time at which we want to transform - -Providing ``tf2::TimePointZero`` will just get us the latest available transform. -All this is wrapped in a try-catch block to handle possible exceptions. - -.. code-block:: C++ - - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePointZero); - -The resulting transformation represents the position and orientation of the target turtle relative to ``turtle2``. -The angle between the turtles is then used to calculate a velocity command to follow the target turtle. -For more general information about tf2 see also the :doc:`tf2 page in the Concepts section <../../../Concepts/Intermediate/About-Tf2>`. - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_listener``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - add_executable(turtle_tf2_listener src/turtle_tf2_listener.cpp) - target_link_libraries( - turtle_tf2_listener PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2::tf2 - tf2_ros::tf2_ros - turtlesim_msgs::turtlesim_msgs - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - turtle_tf2_listener - DESTINATION lib/${PROJECT_NAME}) - -2 Update the launch file -^^^^^^^^^^^^^^^^^^^^^^^^ - -Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. -The resulting file should look like: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/listener_cpp_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/listener_cpp_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/listener_cpp_launch.yaml - :language: yaml - -This will declare a ``target_frame`` launch argument, start a broadcaster for the second turtle that we will spawn and a listener that will subscribe to those transformations. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -4 Run -^^^^^ - -Now you're ready to start your full turtle demo: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py - -You should see the turtle sim with two turtles. -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! - -Summary -------- - -In this tutorial you learned how to use tf2 to get access to frame transformations. -You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <./Introduction-To-Tf2>` tutorial. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Listener-Cpp + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Cpp + +Writing a listener (C++) +======================== + +**Goal:** Learn how to use tf2 to get access to frame transformations. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. + +In this tutorial we'll create a tf2 listener to start using tf2. + +Prerequisites +------------- + +This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (C++) ` and the :doc:`tf2 broadcaster tutorial (C++) `. +In the previous tutorial, we created a ``learning_tf2_cpp`` package, which is where we will continue working from. + +Tasks +----- + +1 Write the listener node +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. +Inside the ``src`` directory download the example listener code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "geometry_msgs/msg/twist.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2/exceptions.hpp" + #include "tf2_ros/transform_listener.h" + #include "tf2_ros/buffer.h" + #include "turtlesim_msgs/srv/spawn.hpp" + + using namespace std::chrono_literals; + + class FrameListener : public rclcpp::Node + { + public: + FrameListener() + : Node("turtle_tf2_frame_listener"), + turtle_spawning_service_ready_(false), + turtle_spawned_(false) + { + // Declare and acquire `target_frame` parameter + target_frame_ = this->declare_parameter("target_frame", "turtle1"); + + tf_buffer_ = + std::make_unique(this->get_clock()); + tf_listener_ = + std::make_shared(*tf_buffer_); + + // Create a client to spawn a turtle + spawner_ = + this->create_client("spawn"); + + // Create turtle2 velocity publisher + publisher_ = + this->create_publisher("turtle2/cmd_vel", 1); + + // Call on_timer function every second + timer_ = this->create_wall_timer( + 1s, [this]() {return this->on_timer();}); + } + + private: + void on_timer() + { + // Store frame names in variables that will be used to + // compute transformations + std::string fromFrameRel = target_frame_.c_str(); + std::string toFrameRel = "turtle2"; + + if (turtle_spawning_service_ready_) { + if (turtle_spawned_) { + geometry_msgs::msg::TransformStamped t; + + // Look up for the transformation between target_frame and turtle2 frames + // and send velocity commands for turtle2 to reach target_frame + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePointZero); + } catch (const tf2::TransformException & ex) { + RCLCPP_INFO( + this->get_logger(), "Could not transform %s to %s: %s", + toFrameRel.c_str(), fromFrameRel.c_str(), ex.what()); + return; + } + + geometry_msgs::msg::Twist msg; + + static const double scaleRotationRate = 1.0; + msg.angular.z = scaleRotationRate * atan2( + t.transform.translation.y, + t.transform.translation.x); + + static const double scaleForwardSpeed = 0.5; + msg.linear.x = scaleForwardSpeed * sqrt( + pow(t.transform.translation.x, 2) + + pow(t.transform.translation.y, 2)); + + publisher_->publish(msg); + } else { + RCLCPP_INFO(this->get_logger(), "Successfully spawned"); + turtle_spawned_ = true; + } + } else { + // Check if the service is ready + if (spawner_->service_is_ready()) { + // Initialize request with turtle name and coordinates + // Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn + auto request = std::make_shared(); + request->x = 4.0; + request->y = 2.0; + request->theta = 0.0; + request->name = "turtle2"; + + // Call request + using ServiceResponseFuture = + rclcpp::Client::SharedFuture; + auto response_received_callback = [this](ServiceResponseFuture future) { + auto result = future.get(); + if (strcmp(result->name.c_str(), "turtle2") == 0) { + turtle_spawning_service_ready_ = true; + } else { + RCLCPP_ERROR(this->get_logger(), "Service callback result mismatch"); + } + }; + auto result = spawner_->async_send_request(request, response_received_callback); + } else { + RCLCPP_INFO(this->get_logger(), "Service is not ready"); + } + } + } + + // Boolean values to store the information + // if the service for spawning turtle is available + bool turtle_spawning_service_ready_; + // if the turtle was successfully spawned + bool turtle_spawned_; + rclcpp::Client::SharedPtr spawner_{nullptr}; + rclcpp::TimerBase::SharedPtr timer_{nullptr}; + rclcpp::Publisher::SharedPtr publisher_{nullptr}; + std::shared_ptr tf_listener_{nullptr}; + std::unique_ptr tf_buffer_; + std::string target_frame_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (C++) <../Writing-A-Simple-Cpp-Service-And-Client>` tutorial. + +Now, let's take a look at the code that is relevant to get access to frame transformations. +The ``tf2_ros`` contains a ``TransformListener`` class that makes the task of receiving transforms easier. + +.. code-block:: C++ + + #include "tf2_ros/transform_listener.h" + +Here, we create a ``TransformListener`` object. +Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. + +.. code-block:: C++ + + tf_listener_ = + std::make_shared(*tf_buffer_); + +Finally, we query the listener for a specific transformation. +We call ``lookup_transform`` method with following arguments: + +#. Target frame + +#. Source frame + +#. The time at which we want to transform + +Providing ``tf2::TimePointZero`` will just get us the latest available transform. +All this is wrapped in a try-catch block to handle possible exceptions. + +.. code-block:: C++ + + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePointZero); + +The resulting transformation represents the position and orientation of the target turtle relative to ``turtle2``. +The angle between the turtles is then used to calculate a velocity command to follow the target turtle. +For more general information about tf2 see also the :doc:`tf2 page in the Concepts section <../../../interfaces/About-Tf2/About-Tf2>`. + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_listener``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + add_executable(turtle_tf2_listener src/turtle_tf2_listener.cpp) + target_link_libraries( + turtle_tf2_listener PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2::tf2 + tf2_ros::tf2_ros + turtlesim_msgs::turtlesim_msgs + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + turtle_tf2_listener + DESTINATION lib/${PROJECT_NAME}) + +2 Update the launch file +^^^^^^^^^^^^^^^^^^^^^^^^ + +Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. +The resulting file should look like: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/listener_cpp_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/listener_cpp_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/listener_cpp_launch.yaml + :language: yaml + +This will declare a ``target_frame`` launch argument, start a broadcaster for the second turtle that we will spawn and a listener that will subscribe to those transformations. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +4 Run +^^^^^ + +Now you're ready to start your full turtle demo: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py + +You should see the turtle sim with two turtles. +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! + +Summary +------- + +In this tutorial you learned how to use tf2 to get access to frame transformations. +You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst index 5b8c28b967e..48bc8933d31 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst @@ -1,368 +1,369 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Listener-Py - -Writing a listener (Python) -=========================== - -**Goal:** Learn how to use tf2 to get access to frame transformations. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. - -In this tutorial we'll create a tf2 listener to start using tf2. - -Prerequisites -------------- - -This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (Python) <./Writing-A-Tf2-Static-Broadcaster-Py>` and :doc:`tf2 broadcaster tutorial (Python) <./Writing-A-Tf2-Broadcaster-Py>`. -In the previous tutorial, we created a ``learning_tf2_py`` package, which is where we will continue working from. - -Tasks ------ - -1 Write the listener node -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_py`` package we created in the previous tutorial. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example listener code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py - -Now open the file called ``turtle_tf2_listener.py`` using your preferred text editor. - -.. code-block:: python - - import math - - from geometry_msgs.msg import Twist - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros import TransformException - from tf2_ros.buffer import Buffer - from tf2_ros.transform_listener import TransformListener - - from turtlesim_msgs.srv import Spawn - - - class FrameListener(Node): - - def __init__(self): - super().__init__('turtle_tf2_frame_listener') - - # Declare and acquire `target_frame` parameter - self.target_frame = self.declare_parameter( - 'target_frame', 'turtle1').get_parameter_value().string_value - - self.tf_buffer = Buffer() - self.tf_listener = TransformListener(self.tf_buffer, self) - - # Create a client to spawn a turtle - self.spawner = self.create_client(Spawn, 'spawn') - # Boolean values to store the information - # if the service for spawning turtle is available - self.turtle_spawning_service_ready = False - # if the turtle was successfully spawned - self.turtle_spawned = False - - # Create turtle2 velocity publisher - self.publisher = self.create_publisher(Twist, 'turtle2/cmd_vel', 1) - - # Call on_timer function every second - self.timer = self.create_timer(1.0, self.on_timer) - - def on_timer(self): - # Store frame names in variables that will be used to - # compute transformations - from_frame_rel = self.target_frame - to_frame_rel = 'turtle2' - - if self.turtle_spawning_service_ready: - if self.turtle_spawned: - # Look up for the transformation between target_frame and turtle2 frames - # and send velocity commands for turtle2 to reach target_frame - try: - t = self.tf_buffer.lookup_transform( - to_frame_rel, - from_frame_rel, - rclpy.time.Time()) - except TransformException as ex: - self.get_logger().info( - f'Could not transform {to_frame_rel} to {from_frame_rel}: {ex}') - return - - msg = Twist() - scale_rotation_rate = 1.0 - msg.angular.z = scale_rotation_rate * math.atan2( - t.transform.translation.y, - t.transform.translation.x) - - scale_forward_speed = 0.5 - msg.linear.x = scale_forward_speed * math.sqrt( - t.transform.translation.x ** 2 + - t.transform.translation.y ** 2) - - self.publisher.publish(msg) - else: - if self.result.done(): - self.get_logger().info( - f'Successfully spawned {self.result.result().name}') - self.turtle_spawned = True - else: - self.get_logger().info('Spawn is not finished') - else: - if self.spawner.service_is_ready(): - # Initialize request with turtle name and coordinates - # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn - request = Spawn.Request() - request.name = 'turtle2' - request.x = float(4) - request.y = float(2) - request.theta = float(0) - # Call request - self.result = self.spawner.call_async(request) - self.turtle_spawning_service_ready = True - else: - # Check if the service is ready - self.get_logger().info('Service is not ready') - - - def main(): - try: - with rclpy.init(): - node = FrameListener() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (Python) <../../Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial. - -Now, let's take a look at the code that is relevant to get access to frame transformations. -The ``tf2_ros`` package provides an implementation of a ``TransformListener`` to help make the task of receiving transforms easier. - -.. code-block:: python - - from tf2_ros.transform_listener import TransformListener - -Here, we create a ``TransformListener`` object. -Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. - -.. code-block:: python - - self.tf_listener = TransformListener(self.tf_buffer, self) - -Finally, we query the listener for a specific transformation. -We call ``lookup_transform`` method with following arguments: - -#. Target frame - -#. Source frame - -#. The time at which we want to transform - -Providing ``rclpy.time.Time()`` will just get us the latest available transform. -All this is wrapped in a try-except block to handle possible exceptions. - -.. code-block:: python - - t = self.tf_buffer.lookup_transform( - to_frame_rel, - from_frame_rel, - rclpy.time.Time()) - -1.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'turtle_tf2_listener = learning_tf2_py.turtle_tf2_listener:main', - -2 Update the launch file -^^^^^^^^^^^^^^^^^^^^^^^^ - -Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. -The resulting file should look like: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/listener_py_launch.xml - :language: xml - :name: turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. literalinclude:: launch/listener_py_launch.yaml - :language: yaml - :name: turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. literalinclude:: launch/listener_py_launch.py - :language: python - :name: turtle_tf2_demo_launch.py - -This will declare a ``target_frame`` launch argument, start a broadcaster for second turtle that we will spawn and listener that will subscribe to those transformations. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - - -4 Run -^^^^^ - -Now you're ready to start your full turtle demo: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py - -You should see the turtle sim with two turtles. -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! - -Summary -------- - -In this tutorial you learned how to use tf2 to get access to frame transformations. -You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <./Introduction-To-Tf2>` tutorial. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Listener-Py + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Py + +Writing a listener (Python) +=========================== + +**Goal:** Learn how to use tf2 to get access to frame transformations. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. + +In this tutorial we'll create a tf2 listener to start using tf2. + +Prerequisites +------------- + +This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (Python) ` and :doc:`tf2 broadcaster tutorial (Python) `. +In the previous tutorial, we created a ``learning_tf2_py`` package, which is where we will continue working from. + +Tasks +----- + +1 Write the listener node +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_py`` package we created in the previous tutorial. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example listener code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py + +Now open the file called ``turtle_tf2_listener.py`` using your preferred text editor. + +.. code-block:: python + + import math + + from geometry_msgs.msg import Twist + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros import TransformException + from tf2_ros.buffer import Buffer + from tf2_ros.transform_listener import TransformListener + + from turtlesim_msgs.srv import Spawn + + + class FrameListener(Node): + + def __init__(self): + super().__init__('turtle_tf2_frame_listener') + + # Declare and acquire `target_frame` parameter + self.target_frame = self.declare_parameter( + 'target_frame', 'turtle1').get_parameter_value().string_value + + self.tf_buffer = Buffer() + self.tf_listener = TransformListener(self.tf_buffer, self) + + # Create a client to spawn a turtle + self.spawner = self.create_client(Spawn, 'spawn') + # Boolean values to store the information + # if the service for spawning turtle is available + self.turtle_spawning_service_ready = False + # if the turtle was successfully spawned + self.turtle_spawned = False + + # Create turtle2 velocity publisher + self.publisher = self.create_publisher(Twist, 'turtle2/cmd_vel', 1) + + # Call on_timer function every second + self.timer = self.create_timer(1.0, self.on_timer) + + def on_timer(self): + # Store frame names in variables that will be used to + # compute transformations + from_frame_rel = self.target_frame + to_frame_rel = 'turtle2' + + if self.turtle_spawning_service_ready: + if self.turtle_spawned: + # Look up for the transformation between target_frame and turtle2 frames + # and send velocity commands for turtle2 to reach target_frame + try: + t = self.tf_buffer.lookup_transform( + to_frame_rel, + from_frame_rel, + rclpy.time.Time()) + except TransformException as ex: + self.get_logger().info( + f'Could not transform {to_frame_rel} to {from_frame_rel}: {ex}') + return + + msg = Twist() + scale_rotation_rate = 1.0 + msg.angular.z = scale_rotation_rate * math.atan2( + t.transform.translation.y, + t.transform.translation.x) + + scale_forward_speed = 0.5 + msg.linear.x = scale_forward_speed * math.sqrt( + t.transform.translation.x ** 2 + + t.transform.translation.y ** 2) + + self.publisher.publish(msg) + else: + if self.result.done(): + self.get_logger().info( + f'Successfully spawned {self.result.result().name}') + self.turtle_spawned = True + else: + self.get_logger().info('Spawn is not finished') + else: + if self.spawner.service_is_ready(): + # Initialize request with turtle name and coordinates + # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn + request = Spawn.Request() + request.name = 'turtle2' + request.x = float(4) + request.y = float(2) + request.theta = float(0) + # Call request + self.result = self.spawner.call_async(request) + self.turtle_spawning_service_ready = True + else: + # Check if the service is ready + self.get_logger().info('Service is not ready') + + + def main(): + try: + with rclpy.init(): + node = FrameListener() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (Python) <../Writing-A-Simple-Py-Service-And-Client>` tutorial. + +Now, let's take a look at the code that is relevant to get access to frame transformations. +The ``tf2_ros`` package provides an implementation of a ``TransformListener`` to help make the task of receiving transforms easier. + +.. code-block:: python + + from tf2_ros.transform_listener import TransformListener + +Here, we create a ``TransformListener`` object. +Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. + +.. code-block:: python + + self.tf_listener = TransformListener(self.tf_buffer, self) + +Finally, we query the listener for a specific transformation. +We call ``lookup_transform`` method with following arguments: + +#. Target frame + +#. Source frame + +#. The time at which we want to transform + +Providing ``rclpy.time.Time()`` will just get us the latest available transform. +All this is wrapped in a try-except block to handle possible exceptions. + +.. code-block:: python + + t = self.tf_buffer.lookup_transform( + to_frame_rel, + from_frame_rel, + rclpy.time.Time()) + +1.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'turtle_tf2_listener = learning_tf2_py.turtle_tf2_listener:main', + +2 Update the launch file +^^^^^^^^^^^^^^^^^^^^^^^^ + +Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. +The resulting file should look like: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/listener_py_launch.xml + :language: xml + :name: turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. literalinclude:: launch/listener_py_launch.yaml + :language: yaml + :name: turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. literalinclude:: launch/listener_py_launch.py + :language: python + :name: turtle_tf2_demo_launch.py + +This will declare a ``target_frame`` launch argument, start a broadcaster for second turtle that we will spawn and listener that will subscribe to those transformations. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + + +4 Run +^^^^^ + +Now you're ready to start your full turtle demo: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py + +You should see the turtle sim with two turtles. +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! + +Summary +------- + +In this tutorial you learned how to use tf2 to get access to frame transformations. +You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst index c3e45da2ba6..25be3f8fbb5 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst @@ -1,439 +1,440 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp - -Writing a static broadcaster (C++) -================================== - -**Goal:** Learn how to broadcast static coordinate frames to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. -For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. - -This is a standalone tutorial covering the basics of static transforms, which consists of two parts. -In the first part we will write code to publish static transforms to tf2. -In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <./Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First we will create a package that will be used for this tutorial and the following ones. -The package called ``learning_tf2_cpp`` will depend on ``geometry_msgs``, ``rclcpp``, ``tf2``, ``tf2_ros``, and ``turtlesim``. -Code for this tutorial is stored `here `_. - -Open a new terminal and :doc:`source your ROS 2 installation <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. -Navigate to workspace's ``src`` folder and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies geometry_msgs rclcpp tf2 tf2_ros turtlesim -- learning_tf2_cpp - -Your terminal will return a message verifying the creation of your package ``learning_tf2_cpp`` and all its necessary files and folders. - -2 Write the static broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Inside the ``src/learning_tf2_cpp/src`` directory download the example static broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2/LinearMath/Quaternion.hpp" - #include "tf2_ros/static_transform_broadcaster.h" - - class StaticFramePublisher : public rclcpp::Node - { - public: - explicit StaticFramePublisher(char * transformation[]) - : Node("static_turtle_tf2_broadcaster") - { - tf_static_broadcaster_ = std::make_shared(this); - - // Publish static transforms once at startup - this->make_transforms(transformation); - } - - private: - void make_transforms(char * transformation[]) - { - geometry_msgs::msg::TransformStamped t; - - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = transformation[1]; - - t.transform.translation.x = atof(transformation[2]); - t.transform.translation.y = atof(transformation[3]); - t.transform.translation.z = atof(transformation[4]); - tf2::Quaternion q; - q.setRPY( - atof(transformation[5]), - atof(transformation[6]), - atof(transformation[7])); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - - tf_static_broadcaster_->sendTransform(t); - } - - std::shared_ptr tf_static_broadcaster_; - }; - - int main(int argc, char * argv[]) - { - auto logger = rclcpp::get_logger("logger"); - - // Obtain parameters from command line arguments - if (argc != 8) { - RCLCPP_INFO( - logger, "Invalid number of parameters\nusage: " - "$ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster " - "child_frame_name x y z roll pitch yaw"); - return 1; - } - - // As the parent frame of the transform is `world`, it is - // necessary to check that the frame name passed is different - if (strcmp(argv[1], "world") == 0) { - RCLCPP_INFO(logger, "Your static turtle name cannot be 'world'"); - return 1; - } - - // Pass parameters and initialize node - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared(argv)); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now let's look at the code that is relevant to publishing the static turtle pose to tf2. -The first lines include the required header files. -First we include ``geometry_msgs/msg/transform_stamped.hpp`` to access the ``TransformStamped`` message type, which we will publish to the transformation tree. - -.. code-block:: C++ - - #include "geometry_msgs/msg/transform_stamped.hpp" - -Afterward, ``rclcpp`` is included so its ``rclcpp::Node`` class can be used. - -.. code-block:: C++ - - #include "rclcpp/rclcpp.hpp" - -``tf2::Quaternion`` is a class for a quaternion that provides convenient functions for converting Euler angles to quaternions and vice versa. -We also include ``tf2_ros/static_transform_broadcaster.h`` to use the ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. - -.. code-block:: C++ - - #include "tf2/LinearMath/Quaternion.hpp" - #include "tf2_ros/static_transform_broadcaster.h" - -The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. -Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. - -.. code-block:: C++ - - tf_static_broadcaster_ = std::make_shared(this); - - this->make_transforms(transformation); - -Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. -Before passing the actual transform values we need to give it the appropriate metadata. - -#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``this->get_clock()->now()`` - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` - -#. Finally, we need to set the name of the child frame of the link we're creating - -.. code-block:: C++ - - geometry_msgs::msg::TransformStamped t; - - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = transformation[1]; - -Here we populate the 6D pose (translation and rotation) of the turtle. - -.. code-block:: C++ - - t.transform.translation.x = atof(transformation[2]); - t.transform.translation.y = atof(transformation[3]); - t.transform.translation.z = atof(transformation[4]); - tf2::Quaternion q; - q.setRPY( - atof(transformation[5]), - atof(transformation[6]), - atof(transformation[7])); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - -Finally, we broadcast static transform using the ``sendTransform()`` function. - -.. code-block:: C++ - - tf_static_broadcaster_->sendTransform(t); - -2.2 Update package.xml -~~~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``src/learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`Create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Learning tf2 with rclcpp - Your Name - Apache-2.0 - -Make sure to save the file. - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Add the executable to the CMakeLists.txt and name it ``static_turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - add_executable(static_turtle_tf2_broadcaster src/static_turtle_tf2_broadcaster.cpp) - target_link_libraries( - static_turtle_tf2_broadcaster PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2::tf2 - tf2_ros::tf2_ros - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - static_turtle_tf2_broadcaster - DESTINATION lib/${PROJECT_NAME}) - -3 Build -^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - - -4 Run -^^^^^ - -Now run the ``static_turtle_tf2_broadcaster`` node: - -.. code-block:: console - - $ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 - -This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. - -We can now check that the static transform has been published by echoing the ``tf_static`` topic. -If everything is well you should see a single static transform: - -.. code-block:: console - - $ ros2 topic echo /tf_static - transforms: - - header: - stamp: - sec: 1622908754 - nanosec: 208515730 - frame_id: world - child_frame_id: mystaticturtle - transform: - translation: - x: 0.0 - y: 0.0 - z: 1.0 - rotation: - x: 0.0 - y: 0.0 - z: 0.0 - w: 1.0 - -The proper way to publish static transforms -------------------------------------------- - -This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. -In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. -``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. - -The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. -In ROS 2, roll/pitch/yaw refers to rotation about the x/y/z-axis, respectively. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle - -The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle - -``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. -For example: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/static_transform_publisher_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/static_transform_publisher_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/static_transform_publisher_launch.py - :language: python - -Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. - -Summary -------- - -In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. -In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. -Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp + +Writing a static broadcaster (C++) +================================== + +**Goal:** Learn how to broadcast static coordinate frames to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. +For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. + +This is a standalone tutorial covering the basics of static transforms, which consists of two parts. +In the first part we will write code to publish static transforms to tf2. +In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First we will create a package that will be used for this tutorial and the following ones. +The package called ``learning_tf2_cpp`` will depend on ``geometry_msgs``, ``rclcpp``, ``tf2``, ``tf2_ros``, and ``turtlesim``. +Code for this tutorial is stored `here `_. + +Open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Navigate to workspace's ``src`` folder and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies geometry_msgs rclcpp tf2 tf2_ros turtlesim -- learning_tf2_cpp + +Your terminal will return a message verifying the creation of your package ``learning_tf2_cpp`` and all its necessary files and folders. + +2 Write the static broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Inside the ``src/learning_tf2_cpp/src`` directory download the example static broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2/LinearMath/Quaternion.hpp" + #include "tf2_ros/static_transform_broadcaster.h" + + class StaticFramePublisher : public rclcpp::Node + { + public: + explicit StaticFramePublisher(char * transformation[]) + : Node("static_turtle_tf2_broadcaster") + { + tf_static_broadcaster_ = std::make_shared(this); + + // Publish static transforms once at startup + this->make_transforms(transformation); + } + + private: + void make_transforms(char * transformation[]) + { + geometry_msgs::msg::TransformStamped t; + + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = transformation[1]; + + t.transform.translation.x = atof(transformation[2]); + t.transform.translation.y = atof(transformation[3]); + t.transform.translation.z = atof(transformation[4]); + tf2::Quaternion q; + q.setRPY( + atof(transformation[5]), + atof(transformation[6]), + atof(transformation[7])); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + + tf_static_broadcaster_->sendTransform(t); + } + + std::shared_ptr tf_static_broadcaster_; + }; + + int main(int argc, char * argv[]) + { + auto logger = rclcpp::get_logger("logger"); + + // Obtain parameters from command line arguments + if (argc != 8) { + RCLCPP_INFO( + logger, "Invalid number of parameters\nusage: " + "$ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster " + "child_frame_name x y z roll pitch yaw"); + return 1; + } + + // As the parent frame of the transform is `world`, it is + // necessary to check that the frame name passed is different + if (strcmp(argv[1], "world") == 0) { + RCLCPP_INFO(logger, "Your static turtle name cannot be 'world'"); + return 1; + } + + // Pass parameters and initialize node + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared(argv)); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now let's look at the code that is relevant to publishing the static turtle pose to tf2. +The first lines include the required header files. +First we include ``geometry_msgs/msg/transform_stamped.hpp`` to access the ``TransformStamped`` message type, which we will publish to the transformation tree. + +.. code-block:: C++ + + #include "geometry_msgs/msg/transform_stamped.hpp" + +Afterward, ``rclcpp`` is included so its ``rclcpp::Node`` class can be used. + +.. code-block:: C++ + + #include "rclcpp/rclcpp.hpp" + +``tf2::Quaternion`` is a class for a quaternion that provides convenient functions for converting Euler angles to quaternions and vice versa. +We also include ``tf2_ros/static_transform_broadcaster.h`` to use the ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. + +.. code-block:: C++ + + #include "tf2/LinearMath/Quaternion.hpp" + #include "tf2_ros/static_transform_broadcaster.h" + +The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. +Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. + +.. code-block:: C++ + + tf_static_broadcaster_ = std::make_shared(this); + + this->make_transforms(transformation); + +Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. +Before passing the actual transform values we need to give it the appropriate metadata. + +#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``this->get_clock()->now()`` + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` + +#. Finally, we need to set the name of the child frame of the link we're creating + +.. code-block:: C++ + + geometry_msgs::msg::TransformStamped t; + + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = transformation[1]; + +Here we populate the 6D pose (translation and rotation) of the turtle. + +.. code-block:: C++ + + t.transform.translation.x = atof(transformation[2]); + t.transform.translation.y = atof(transformation[3]); + t.transform.translation.z = atof(transformation[4]); + tf2::Quaternion q; + q.setRPY( + atof(transformation[5]), + atof(transformation[6]), + atof(transformation[7])); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + +Finally, we broadcast static transform using the ``sendTransform()`` function. + +.. code-block:: C++ + + tf_static_broadcaster_->sendTransform(t); + +2.2 Update package.xml +~~~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``src/learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`Create a package <../Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Learning tf2 with rclcpp + Your Name + Apache-2.0 + +Make sure to save the file. + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Add the executable to the CMakeLists.txt and name it ``static_turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + add_executable(static_turtle_tf2_broadcaster src/static_turtle_tf2_broadcaster.cpp) + target_link_libraries( + static_turtle_tf2_broadcaster PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2::tf2 + tf2_ros::tf2_ros + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + static_turtle_tf2_broadcaster + DESTINATION lib/${PROJECT_NAME}) + +3 Build +^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + + +4 Run +^^^^^ + +Now run the ``static_turtle_tf2_broadcaster`` node: + +.. code-block:: console + + $ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 + +This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. + +We can now check that the static transform has been published by echoing the ``tf_static`` topic. +If everything is well you should see a single static transform: + +.. code-block:: console + + $ ros2 topic echo /tf_static + transforms: + - header: + stamp: + sec: 1622908754 + nanosec: 208515730 + frame_id: world + child_frame_id: mystaticturtle + transform: + translation: + x: 0.0 + y: 0.0 + z: 1.0 + rotation: + x: 0.0 + y: 0.0 + z: 0.0 + w: 1.0 + +The proper way to publish static transforms +------------------------------------------- + +This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. +In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. +``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. + +The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. +In ROS 2, roll/pitch/yaw refers to rotation about the x/y/z-axis, respectively. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle + +The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle + +``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. +For example: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/static_transform_publisher_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/static_transform_publisher_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/static_transform_publisher_launch.py + :language: python + +Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. + +Summary +------- + +In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. +In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. +Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst index b3ae335f1ed..f431b90cd22 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst @@ -1,458 +1,459 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Py - -Writing a static broadcaster (Python) -===================================== - -**Goal:** Learn how to broadcast static coordinate frames to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. -For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. - -This is a standalone tutorial covering the basics of static transforms, which consists of two parts. -In the first part we will write code to publish static transforms to tf2. -In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <./Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First we will create a package that will be used for this tutorial and the following ones. -The package called ``learning_tf2_py`` will depend on ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs``. -Code for this tutorial is stored `here `_. - -Open a new terminal and :doc:`source your ROS 2 installation <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. -Navigate to workspace's ``src`` folder and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 -- learning_tf2_py - -Your terminal will return a message verifying the creation of your package ``learning_tf2_py`` and all its necessary files and folders. - -2 Write the static broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example static broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py - -Now open the file called ``static_turtle_tf2_broadcaster.py`` using your preferred text editor. - -.. code-block:: python - - import math - import sys - - from geometry_msgs.msg import TransformStamped - - import numpy as np - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster - - - def quaternion_from_euler(ai, aj, ak): - ai /= 2.0 - aj /= 2.0 - ak /= 2.0 - ci = math.cos(ai) - si = math.sin(ai) - cj = math.cos(aj) - sj = math.sin(aj) - ck = math.cos(ak) - sk = math.sin(ak) - cc = ci*ck - cs = ci*sk - sc = si*ck - ss = si*sk - - q = np.empty((4, )) - q[0] = cj*sc - sj*cs - q[1] = cj*ss + sj*cc - q[2] = cj*cs - sj*sc - q[3] = cj*cc + sj*ss - - return q - - - class StaticFramePublisher(Node): - """ - Broadcast transforms that never change. - - This example publishes transforms from `world` to a static turtle frame. - The transforms are only published once at startup, and are constant for all - time. - """ - - def __init__(self, transformation): - super().__init__('static_turtle_tf2_broadcaster') - - self.tf_static_broadcaster = StaticTransformBroadcaster(self) - - # Publish static transforms once at startup - self.make_transforms(transformation) - - def make_transforms(self, transformation): - t = TransformStamped() - - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = transformation[1] - - t.transform.translation.x = float(transformation[2]) - t.transform.translation.y = float(transformation[3]) - t.transform.translation.z = float(transformation[4]) - quat = quaternion_from_euler( - float(transformation[5]), float(transformation[6]), float(transformation[7])) - t.transform.rotation.x = quat[0] - t.transform.rotation.y = quat[1] - t.transform.rotation.z = quat[2] - t.transform.rotation.w = quat[3] - - self.tf_static_broadcaster.sendTransform(t) - - - def main(): - try: - logger = rclpy.logging.get_logger('logger') - - # obtain parameters from command line arguments - if len(sys.argv) != 8: - logger.info('Invalid number of parameters. Usage: \n' - '$ ros2 run learning_tf2_py static_turtle_tf2_broadcaster' - 'child_frame_name x y z roll pitch yaw') - sys.exit(1) - - if sys.argv[1] == 'world': - logger.info('Your static turtle name cannot be "world"') - sys.exit(2) - - # pass parameters and initialize node - with rclpy.init(): - node = StaticFramePublisher(sys.argv) - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now let's look at the code that is relevant to publishing the static turtle pose to tf2. -The first lines import required packages. -First we import the ``TransformStamped`` from the ``geometry_msgs``, which provides us a template for the message that we will publish to the transformation tree. - -.. code-block:: python - - from geometry_msgs.msg import TransformStamped - -Afterward, ``rclpy`` is imported so its ``Node`` class can be used. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The ``tf2_ros`` package provides a ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. -To use the ``StaticTransformBroadcaster``, we need to import it from the ``tf2_ros`` module. - -.. code-block:: python - - from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster - -The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. -Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. - -.. code-block:: python - - self.tf_static_broadcaster = StaticTransformBroadcaster(self) - self.make_transforms(transformation) - -Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. -Before passing the actual transform values we need to give it the appropriate metadata. - -#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``self.get_clock().now()`` - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` - -#. Finally, we need to set the name of the child frame of the link we're creating - -.. code-block:: python - - t = TransformStamped() - - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = transformation[1] - -Here we populate the 6D pose (translation and rotation) of the turtle. - -.. code-block:: python - - t.transform.translation.x = float(transformation[2]) - t.transform.translation.y = float(transformation[3]) - t.transform.translation.z = float(transformation[4]) - quat = quaternion_from_euler( - float(transformation[5]), float(transformation[6]), float(transformation[7])) - t.transform.rotation.x = quat[0] - t.transform.rotation.y = quat[1] - t.transform.rotation.z = quat[2] - t.transform.rotation.w = quat[3] - -Finally, we broadcast static transform using the ``sendTransform()`` function. - -.. code-block:: python - - self.tf_static_broadcaster.sendTransform(t) - -2.2 Update package.xml -~~~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``src/learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`Create a package <../../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Learning tf2 with rclpy - Your Name - Apache-2.0 - -After the lines above, add the following dependencies corresponding to your node's import statements: - -.. code-block:: xml - - geometry_msgs - python3-numpy - rclpy - tf2_ros_py - turtlesim_msgs - -This declares the required ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs`` dependencies when its code is executed. - -Make sure to save the file. - -2.3 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'static_turtle_tf2_broadcaster = learning_tf2_py.static_turtle_tf2_broadcaster:main', - -3 Build -^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - - -4 Run -^^^^^ - -Now run the ``static_turtle_tf2_broadcaster`` node: - -.. code-block:: console - - $ ros2 run learning_tf2_py static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 - -This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. - -We can now check that the static transform has been published by echoing the ``tf_static`` topic -If everything is well you should see a single static transform: - -.. code-block:: console - - $ ros2 topic echo /tf_static - transforms: - - header: - stamp: - sec: 1622908754 - nanosec: 208515730 - frame_id: world - child_frame_id: mystaticturtle - transform: - translation: - x: 0.0 - y: 0.0 - z: 1.0 - rotation: - x: 0.0 - y: 0.0 - z: 0.0 - w: 1.0 - -The proper way to publish static transforms -------------------------------------------- - -This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. -In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. -``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. - -The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. -In ROS 2, roll/pitch/yaw refers to rotation in radians about the x/y/z-axis, respectively. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle - -The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle - -``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. -For example: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/static_transform_publisher_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/static_transform_publisher_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/static_transform_publisher_launch.py - :language: python - -Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. - -Summary -------- - -In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. -In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. -Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Py + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Py + +Writing a static broadcaster (Python) +===================================== + +**Goal:** Learn how to broadcast static coordinate frames to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. +For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. + +This is a standalone tutorial covering the basics of static transforms, which consists of two parts. +In the first part we will write code to publish static transforms to tf2. +In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First we will create a package that will be used for this tutorial and the following ones. +The package called ``learning_tf2_py`` will depend on ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs``. +Code for this tutorial is stored `here `_. + +Open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Navigate to workspace's ``src`` folder and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 -- learning_tf2_py + +Your terminal will return a message verifying the creation of your package ``learning_tf2_py`` and all its necessary files and folders. + +2 Write the static broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example static broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py + +Now open the file called ``static_turtle_tf2_broadcaster.py`` using your preferred text editor. + +.. code-block:: python + + import math + import sys + + from geometry_msgs.msg import TransformStamped + + import numpy as np + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster + + + def quaternion_from_euler(ai, aj, ak): + ai /= 2.0 + aj /= 2.0 + ak /= 2.0 + ci = math.cos(ai) + si = math.sin(ai) + cj = math.cos(aj) + sj = math.sin(aj) + ck = math.cos(ak) + sk = math.sin(ak) + cc = ci*ck + cs = ci*sk + sc = si*ck + ss = si*sk + + q = np.empty((4, )) + q[0] = cj*sc - sj*cs + q[1] = cj*ss + sj*cc + q[2] = cj*cs - sj*sc + q[3] = cj*cc + sj*ss + + return q + + + class StaticFramePublisher(Node): + """ + Broadcast transforms that never change. + + This example publishes transforms from `world` to a static turtle frame. + The transforms are only published once at startup, and are constant for all + time. + """ + + def __init__(self, transformation): + super().__init__('static_turtle_tf2_broadcaster') + + self.tf_static_broadcaster = StaticTransformBroadcaster(self) + + # Publish static transforms once at startup + self.make_transforms(transformation) + + def make_transforms(self, transformation): + t = TransformStamped() + + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = transformation[1] + + t.transform.translation.x = float(transformation[2]) + t.transform.translation.y = float(transformation[3]) + t.transform.translation.z = float(transformation[4]) + quat = quaternion_from_euler( + float(transformation[5]), float(transformation[6]), float(transformation[7])) + t.transform.rotation.x = quat[0] + t.transform.rotation.y = quat[1] + t.transform.rotation.z = quat[2] + t.transform.rotation.w = quat[3] + + self.tf_static_broadcaster.sendTransform(t) + + + def main(): + try: + logger = rclpy.logging.get_logger('logger') + + # obtain parameters from command line arguments + if len(sys.argv) != 8: + logger.info('Invalid number of parameters. Usage: \n' + '$ ros2 run learning_tf2_py static_turtle_tf2_broadcaster' + 'child_frame_name x y z roll pitch yaw') + sys.exit(1) + + if sys.argv[1] == 'world': + logger.info('Your static turtle name cannot be "world"') + sys.exit(2) + + # pass parameters and initialize node + with rclpy.init(): + node = StaticFramePublisher(sys.argv) + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now let's look at the code that is relevant to publishing the static turtle pose to tf2. +The first lines import required packages. +First we import the ``TransformStamped`` from the ``geometry_msgs``, which provides us a template for the message that we will publish to the transformation tree. + +.. code-block:: python + + from geometry_msgs.msg import TransformStamped + +Afterward, ``rclpy`` is imported so its ``Node`` class can be used. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The ``tf2_ros`` package provides a ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. +To use the ``StaticTransformBroadcaster``, we need to import it from the ``tf2_ros`` module. + +.. code-block:: python + + from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster + +The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. +Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. + +.. code-block:: python + + self.tf_static_broadcaster = StaticTransformBroadcaster(self) + self.make_transforms(transformation) + +Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. +Before passing the actual transform values we need to give it the appropriate metadata. + +#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``self.get_clock().now()`` + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` + +#. Finally, we need to set the name of the child frame of the link we're creating + +.. code-block:: python + + t = TransformStamped() + + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = transformation[1] + +Here we populate the 6D pose (translation and rotation) of the turtle. + +.. code-block:: python + + t.transform.translation.x = float(transformation[2]) + t.transform.translation.y = float(transformation[3]) + t.transform.translation.z = float(transformation[4]) + quat = quaternion_from_euler( + float(transformation[5]), float(transformation[6]), float(transformation[7])) + t.transform.rotation.x = quat[0] + t.transform.rotation.y = quat[1] + t.transform.rotation.z = quat[2] + t.transform.rotation.w = quat[3] + +Finally, we broadcast static transform using the ``sendTransform()`` function. + +.. code-block:: python + + self.tf_static_broadcaster.sendTransform(t) + +2.2 Update package.xml +~~~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``src/learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`Create a package <../Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Learning tf2 with rclpy + Your Name + Apache-2.0 + +After the lines above, add the following dependencies corresponding to your node's import statements: + +.. code-block:: xml + + geometry_msgs + python3-numpy + rclpy + tf2_ros_py + turtlesim_msgs + +This declares the required ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs`` dependencies when its code is executed. + +Make sure to save the file. + +2.3 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'static_turtle_tf2_broadcaster = learning_tf2_py.static_turtle_tf2_broadcaster:main', + +3 Build +^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + + +4 Run +^^^^^ + +Now run the ``static_turtle_tf2_broadcaster`` node: + +.. code-block:: console + + $ ros2 run learning_tf2_py static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 + +This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. + +We can now check that the static transform has been published by echoing the ``tf_static`` topic +If everything is well you should see a single static transform: + +.. code-block:: console + + $ ros2 topic echo /tf_static + transforms: + - header: + stamp: + sec: 1622908754 + nanosec: 208515730 + frame_id: world + child_frame_id: mystaticturtle + transform: + translation: + x: 0.0 + y: 0.0 + z: 1.0 + rotation: + x: 0.0 + y: 0.0 + z: 0.0 + w: 1.0 + +The proper way to publish static transforms +------------------------------------------- + +This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. +In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. +``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. + +The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. +In ROS 2, roll/pitch/yaw refers to rotation in radians about the x/y/z-axis, respectively. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle + +The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle + +``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. +For example: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/static_transform_publisher_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/static_transform_publisher_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/static_transform_publisher_launch.py + :language: python + +Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. + +Summary +------- + +In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. +In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. +Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst index 0d40c8bfc40..894705aeec4 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst @@ -1,439 +1,440 @@ -.. redirect-from:: - - Tutorials/Using-Parameters-In-A-Class-CPP - -.. _CppParamNode: - -Using parameters in a class (C++) -================================= - -**Goal:** Create and run a class with ROS parameters using C++. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When making your own :doc:`nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` you will sometimes need to add parameters that can be set from the launch file. - -This tutorial will show you how to create those parameters in a C++ class, and how to set them using launch file. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <./Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <./Creating-Your-First-ROS2-Package>`. -You have also learned about :doc:`parameters <../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and their function in a ROS 2 system. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -Navigate into ``ros2_ws/src`` and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_parameters --dependencies rclcpp - -Your terminal will return a message verifying the creation of your package ``cpp_parameters`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. - -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - C++ parameter tutorial - Your Name - Apache-2.0 - -2 Write the C++ node -^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/cpp_parameters/src`` directory, create a new file called ``cpp_parameters_node.cpp`` and paste the following code within: - -.. code-block:: C++ - - #include - #include - #include - - #include - - using namespace std::chrono_literals; - - class MinimalParam : public rclcpp::Node - { - public: - MinimalParam() - : Node("minimal_param_node") - { - this->declare_parameter("my_parameter", "world"); - - auto timer_callback = [this](){ - std::string my_param = this->get_parameter("my_parameter").as_string(); - - RCLCPP_INFO(this->get_logger(), "Hello %s!", my_param.c_str()); - - std::vector all_new_parameters{rclcpp::Parameter("my_parameter", "world")}; - this->set_parameters(all_new_parameters); - }; - timer_ = this->create_wall_timer(1000ms, timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - }; - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ -The ``#include`` statements at the top are the package dependencies. - -The next piece of code creates the class and the constructor. -The first line of this constructor creates a parameter with the name ``my_parameter`` and a default value of ``world``. -The parameter type is inferred from the default value, so in this case it would be set to a string type. -Next, a `lambda function `_ called ``timer_callback`` is declared. -It performs a by-reference capture of the current object ``this``, takes no input arguments and returns void. -The first line of our ``timer_callback`` function gets the parameter ``my_parameter`` from the node, and stores it in ``my_param``. -Then the ``RCLCPP_INFO`` function ensures the event is logged. -The ``set_parameters`` function sets the parameter ``my_parameter`` back to the default string value ``world``. -In the case that the user changed the parameter externally, this ensures it is always reset back to the original. -In the end, ``timer_`` is initialized with a period of 1000ms, which causes the ``timer_callback`` function to be executed once a second. - -.. code-block:: C++ - - class MinimalParam : public rclcpp::Node - { - public: - MinimalParam() - : Node("minimal_param_node") - { - this->declare_parameter("my_parameter", "world"); - - auto timer_callback = [this](){ - std::string my_param = this->get_parameter("my_parameter").as_string(); - - RCLCPP_INFO(this->get_logger(), "Hello %s!", my_param.c_str()); - - std::vector all_new_parameters{rclcpp::Parameter("my_parameter", "world")}; - this->set_parameters(all_new_parameters); - }; - timer_ = this->create_wall_timer(1000ms, timer_callback); - } - -Last is the declaration of ``timer_``. - -.. code-block:: C++ - - private: - rclcpp::TimerBase::SharedPtr timer_; - -Following our ``MinimalParam`` is our ``main``. -Here ROS 2 is initialized, an instance of the ``MinimalParam`` class is constructed, and ``rclcpp::spin`` starts processing data from the node. - -.. code-block:: C++ - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.1.1 (Optional) Add ParameterDescriptor -"""""""""""""""""""""""""""""""""""""""" -Optionally, you can set a descriptor for the parameter. -Descriptors allow you to specify a text description of the parameter and its constraints, like making it read-only, specifying a range, etc. -For that to work, the code in the constructor has to be changed to: - -.. code-block:: C++ - - // ... - - class MinimalParam : public rclcpp::Node - { - public: - MinimalParam() - : Node("minimal_param_node") - { - auto param_desc = rcl_interfaces::msg::ParameterDescriptor{}; - param_desc.description = "This parameter is mine!"; - - this->declare_parameter("my_parameter", "world", param_desc); - - auto timer_callback = [this](){ - std::string my_param = this->get_parameter("my_parameter").as_string(); - - RCLCPP_INFO(this->get_logger(), "Hello %s!", my_param.c_str()); - - std::vector all_new_parameters{rclcpp::Parameter("my_parameter", "world")}; - this->set_parameters(all_new_parameters); - }; - timer_ = this->create_wall_timer(1000ms, timer_callback); - - } - -The rest of the code remains the same. -Once you run the node, you can then run ``ros2 param describe /minimal_param_node my_parameter`` to see the type and description. - - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. -Below the dependency ``find_package(rclcpp REQUIRED)`` add the following lines of code. - -.. code-block:: cmake - - add_executable(minimal_param_node src/cpp_parameters_node.cpp) - target_link_libraries(minimal_param_node rclcpp::rclcpp) - - install(TARGETS - minimal_param_node - DESTINATION lib/${PROJECT_NAME} - ) - - -3 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select cpp_parameters - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select cpp_parameters - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_parameters - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node. -The terminal should return the ``Hello World`` message every second: - -.. code-block:: console - - $ ros2 run cpp_parameters minimal_param_node - [INFO] [minimal_param_node]: Hello world! - -Now you can see the default value of your parameter, but you want to be able to set it yourself. -There are four ways to accomplish this. - -3.1 Change via the console -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This part will use the knowledge you have gained from the :doc:`tutorial about parameters <../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and apply it to the node you have just created. - -Make sure the node is running: - -.. code-block:: console - - $ ros2 run cpp_parameters minimal_param_node - -Open another terminal, source the setup files from inside ``ros2_ws`` again, and enter the following line: - -.. code-block:: console - - $ ros2 param list - -There you will see the custom parameter ``my_parameter``. -To change it, simply run the following line in the console: - -.. code-block:: console - - $ ros2 param set /minimal_param_node my_parameter earth - -You know it went well if you got the output ``Set parameter successful``. -If you look at the other terminal, you should see the output change to ``[INFO] [minimal_param_node]: Hello earth!`` - -3.2 Change via a launch file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -You can also set the parameter in a launch file, but first you will need to add the launch directory. -Inside the ``ros2_ws/src/cpp_parameters/`` directory, create a new directory called ``launch``. -In there, create a new file called ``cpp_parameters_launch.py`` - - -.. literalinclude:: launch/cpp_parameters_launch.py - :language: python - -Here you can see that we set ``my_parameter`` to ``earth`` when we launch our node ``minimal_param_node``. -By adding the two lines below, we ensure our output is printed in our console. - -.. code-block:: python - - output="screen", - emulate_tty=True, - -Now open the ``CMakeLists.txt`` file. -Below the lines you added earlier, add the following lines of code. - -.. code-block:: cmake - - install( - DIRECTORY launch - DESTINATION share/${PROJECT_NAME} - ) - -Open a console and navigate to the root of your workspace, ``ros2_ws``, and build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select cpp_parameters - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select cpp_parameters - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_parameters - -Then source the setup files in a new terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node using the launch file we have just created. -The terminal should return the following message the first time: - -.. code-block:: console - - $ ros2 launch cpp_parameters cpp_parameters_launch.py - [INFO] [custom_minimal_param_node]: Hello earth! - -Further outputs should show ``[INFO] [minimal_param_node]: Hello world!`` every second. - -3.3 Change via launch file loading parameters from YAML file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Instead of listing parameters and their values in launch file, you can create a separate YAML file that will be loaded in launch file. -Placing parameters in a YAML file makes it easier to organize them, for example, by assigning them to different namespaces. -You can read more about it :ref:`here `. - -.. note:: - - While declaring, getting and setting parameter value inside your C++ node, you should use dot as a separator between parameter's namespace and name. - -3.4 Change via passing YAML file as an argument at node startup -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Return to :ref:`tutorial about parameters ` to remind yourself, how to load parameters file at node startup using CLI. - -Summary -------- - -You created a node with a custom parameter that can be set either from a launch file or the command line. -You added the dependencies, executables, and a launch file to the package configuration files so that you could build and run them, and see the parameter in action. - -Next steps ----------- - -Now that you have some packages and ROS 2 systems of your own, the :doc:`next tutorial <./Getting-Started-With-Ros2doctor>` will show you how to examine issues in your environment and systems in case you have problems. - -Related content ---------------- - -* For more detailed information about using YAML files to load parameters, please refer to :ref:`this section ` of Managing large projects tutorial. -* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (C++) <../Intermediate/Monitoring-For-Parameter-Changes-CPP>` tutorial. +.. redirect-from:: + + Tutorials/Using-Parameters-In-A-Class-CPP + Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-CPP + +.. _CppParamNode: + +Using parameters in a class (C++) +================================= + +**Goal:** Create and run a class with ROS parameters using C++. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When making your own :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` you will sometimes need to add parameters that can be set from the launch file. + +This tutorial will show you how to create those parameters in a C++ class, and how to set them using launch file. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. +You have also learned about :doc:`parameters <../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and their function in a ROS 2 system. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +Navigate into ``ros2_ws/src`` and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_parameters --dependencies rclcpp + +Your terminal will return a message verifying the creation of your package ``cpp_parameters`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. + +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + C++ parameter tutorial + Your Name + Apache-2.0 + +2 Write the C++ node +^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/cpp_parameters/src`` directory, create a new file called ``cpp_parameters_node.cpp`` and paste the following code within: + +.. code-block:: C++ + + #include + #include + #include + + #include + + using namespace std::chrono_literals; + + class MinimalParam : public rclcpp::Node + { + public: + MinimalParam() + : Node("minimal_param_node") + { + this->declare_parameter("my_parameter", "world"); + + auto timer_callback = [this](){ + std::string my_param = this->get_parameter("my_parameter").as_string(); + + RCLCPP_INFO(this->get_logger(), "Hello %s!", my_param.c_str()); + + std::vector all_new_parameters{rclcpp::Parameter("my_parameter", "world")}; + this->set_parameters(all_new_parameters); + }; + timer_ = this->create_wall_timer(1000ms, timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + }; + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ +The ``#include`` statements at the top are the package dependencies. + +The next piece of code creates the class and the constructor. +The first line of this constructor creates a parameter with the name ``my_parameter`` and a default value of ``world``. +The parameter type is inferred from the default value, so in this case it would be set to a string type. +Next, a `lambda function `_ called ``timer_callback`` is declared. +It performs a by-reference capture of the current object ``this``, takes no input arguments and returns void. +The first line of our ``timer_callback`` function gets the parameter ``my_parameter`` from the node, and stores it in ``my_param``. +Then the ``RCLCPP_INFO`` function ensures the event is logged. +The ``set_parameters`` function sets the parameter ``my_parameter`` back to the default string value ``world``. +In the case that the user changed the parameter externally, this ensures it is always reset back to the original. +In the end, ``timer_`` is initialized with a period of 1000ms, which causes the ``timer_callback`` function to be executed once a second. + +.. code-block:: C++ + + class MinimalParam : public rclcpp::Node + { + public: + MinimalParam() + : Node("minimal_param_node") + { + this->declare_parameter("my_parameter", "world"); + + auto timer_callback = [this](){ + std::string my_param = this->get_parameter("my_parameter").as_string(); + + RCLCPP_INFO(this->get_logger(), "Hello %s!", my_param.c_str()); + + std::vector all_new_parameters{rclcpp::Parameter("my_parameter", "world")}; + this->set_parameters(all_new_parameters); + }; + timer_ = this->create_wall_timer(1000ms, timer_callback); + } + +Last is the declaration of ``timer_``. + +.. code-block:: C++ + + private: + rclcpp::TimerBase::SharedPtr timer_; + +Following our ``MinimalParam`` is our ``main``. +Here ROS 2 is initialized, an instance of the ``MinimalParam`` class is constructed, and ``rclcpp::spin`` starts processing data from the node. + +.. code-block:: C++ + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.1.1 (Optional) Add ParameterDescriptor +"""""""""""""""""""""""""""""""""""""""" +Optionally, you can set a descriptor for the parameter. +Descriptors allow you to specify a text description of the parameter and its constraints, like making it read-only, specifying a range, etc. +For that to work, the code in the constructor has to be changed to: + +.. code-block:: C++ + + // ... + + class MinimalParam : public rclcpp::Node + { + public: + MinimalParam() + : Node("minimal_param_node") + { + auto param_desc = rcl_interfaces::msg::ParameterDescriptor{}; + param_desc.description = "This parameter is mine!"; + + this->declare_parameter("my_parameter", "world", param_desc); + + auto timer_callback = [this](){ + std::string my_param = this->get_parameter("my_parameter").as_string(); + + RCLCPP_INFO(this->get_logger(), "Hello %s!", my_param.c_str()); + + std::vector all_new_parameters{rclcpp::Parameter("my_parameter", "world")}; + this->set_parameters(all_new_parameters); + }; + timer_ = this->create_wall_timer(1000ms, timer_callback); + + } + +The rest of the code remains the same. +Once you run the node, you can then run ``ros2 param describe /minimal_param_node my_parameter`` to see the type and description. + + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. +Below the dependency ``find_package(rclcpp REQUIRED)`` add the following lines of code. + +.. code-block:: cmake + + add_executable(minimal_param_node src/cpp_parameters_node.cpp) + target_link_libraries(minimal_param_node rclcpp::rclcpp) + + install(TARGETS + minimal_param_node + DESTINATION lib/${PROJECT_NAME} + ) + + +3 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select cpp_parameters + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select cpp_parameters + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_parameters + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node. +The terminal should return the ``Hello World`` message every second: + +.. code-block:: console + + $ ros2 run cpp_parameters minimal_param_node + [INFO] [minimal_param_node]: Hello world! + +Now you can see the default value of your parameter, but you want to be able to set it yourself. +There are four ways to accomplish this. + +3.1 Change via the console +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This part will use the knowledge you have gained from the :doc:`tutorial about parameters <../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and apply it to the node you have just created. + +Make sure the node is running: + +.. code-block:: console + + $ ros2 run cpp_parameters minimal_param_node + +Open another terminal, source the setup files from inside ``ros2_ws`` again, and enter the following line: + +.. code-block:: console + + $ ros2 param list + +There you will see the custom parameter ``my_parameter``. +To change it, simply run the following line in the console: + +.. code-block:: console + + $ ros2 param set /minimal_param_node my_parameter earth + +You know it went well if you got the output ``Set parameter successful``. +If you look at the other terminal, you should see the output change to ``[INFO] [minimal_param_node]: Hello earth!`` + +3.2 Change via a launch file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +You can also set the parameter in a launch file, but first you will need to add the launch directory. +Inside the ``ros2_ws/src/cpp_parameters/`` directory, create a new directory called ``launch``. +In there, create a new file called ``cpp_parameters_launch.py`` + + +.. literalinclude:: launch/cpp_parameters_launch.py + :language: python + +Here you can see that we set ``my_parameter`` to ``earth`` when we launch our node ``minimal_param_node``. +By adding the two lines below, we ensure our output is printed in our console. + +.. code-block:: python + + output="screen", + emulate_tty=True, + +Now open the ``CMakeLists.txt`` file. +Below the lines you added earlier, add the following lines of code. + +.. code-block:: cmake + + install( + DIRECTORY launch + DESTINATION share/${PROJECT_NAME} + ) + +Open a console and navigate to the root of your workspace, ``ros2_ws``, and build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select cpp_parameters + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select cpp_parameters + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_parameters + +Then source the setup files in a new terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node using the launch file we have just created. +The terminal should return the following message the first time: + +.. code-block:: console + + $ ros2 launch cpp_parameters cpp_parameters_launch.py + [INFO] [custom_minimal_param_node]: Hello earth! + +Further outputs should show ``[INFO] [minimal_param_node]: Hello world!`` every second. + +3.3 Change via launch file loading parameters from YAML file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Instead of listing parameters and their values in launch file, you can create a separate YAML file that will be loaded in launch file. +Placing parameters in a YAML file makes it easier to organize them, for example, by assigning them to different namespaces. +You can read more about it :ref:`here `. + +.. note:: + + While declaring, getting and setting parameter value inside your C++ node, you should use dot as a separator between parameter's namespace and name. + +3.4 Change via passing YAML file as an argument at node startup +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Return to :ref:`tutorial about parameters ` to remind yourself, how to load parameters file at node startup using CLI. + +Summary +------- + +You created a node with a custom parameter that can be set either from a launch file or the command line. +You added the dependencies, executables, and a launch file to the package configuration files so that you could build and run them, and see the parameter in action. + +Next steps +---------- + +Now that you have some packages and ROS 2 systems of your own, the :doc:`next tutorial ` will show you how to examine issues in your environment and systems in case you have problems. + +Related content +--------------- + +* For more detailed information about using YAML files to load parameters, please refer to :ref:`this section ` of Managing large projects tutorial. +* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (C++) <../../parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst index 4592829a879..221ac557191 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst @@ -1,450 +1,451 @@ -.. redirect-from:: - - Tutorials/Using-Parameters-In-A-Class-Python - -.. _PythonParamNode: - -Using parameters in a class (Python) -==================================== - -**Goal:** Create and run a class with ROS parameters using Python. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When making your own :doc:`nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` you will sometimes need to add parameters that can be set from the launch file. - -This tutorial will show you how to create those parameters in a Python class, and how to set them using launch file. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <./Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <./Creating-Your-First-ROS2-Package>`. -You have also learned about :doc:`parameters <../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and their function in a ROS 2 system. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -Navigate into ``ros2_ws/src`` and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 python_parameters --dependencies rclpy - -Your terminal will return a message verifying the creation of your package ``python_parameters`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. - -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - Python parameter tutorial - Your Name - Apache-2.0 - -2 Write the Python node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/python_parameters/python_parameters`` directory, create a new file called ``python_parameters_node.py`` and paste the following code within: - -.. code-block:: Python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - class MinimalParam(Node): - def __init__(self): - super().__init__('minimal_param_node') - - self.declare_parameter('my_parameter', 'world') - - self.timer = self.create_timer(1, self.timer_callback) - - def timer_callback(self): - my_param = self.get_parameter('my_parameter').get_parameter_value().string_value - - self.get_logger().info('Hello %s!' % my_param) - - my_new_param = rclpy.parameter.Parameter( - 'my_parameter', - rclpy.Parameter.Type.STRING, - 'world' - ) - all_new_parameters = [my_new_param] - self.set_parameters(all_new_parameters) - - def main(): - try: - with rclpy.init(): - node = MinimalParam() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - if __name__ == '__main__': - main() - - - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ -The ``import`` statements at the top are used to import the package dependencies. - -The next piece of code creates the class and the constructor. -The line ``self.declare_parameter('my_parameter', 'world')`` of the constructor creates a parameter with the name ``my_parameter`` and a default value of ``world``. -The parameter type is inferred from the default value, so in this case it would be set to a string type. -Next the ``timer`` is initialized with a period of 1, which causes the ``timer_callback`` function to be executed once a second. - -.. code-block:: Python - - class MinimalParam(Node): - def __init__(self): - super().__init__('minimal_param_node') - - self.declare_parameter('my_parameter', 'world') - - self.timer = self.create_timer(1, self.timer_callback) - -The first line of our ``timer_callback`` function gets the parameter ``my_parameter`` from the node, and stores it in ``my_param``. -Next the ``get_logger`` function ensures the event is logged. -The ``set_parameters`` function then sets the parameter ``my_parameter`` back to the default string value ``world``. -In the case that the user changed the parameter externally, this ensures it is always reset back to the original. - -.. code-block:: Python - - def timer_callback(self): - my_param = self.get_parameter('my_parameter').get_parameter_value().string_value - - self.get_logger().info('Hello %s!' % my_param) - - my_new_param = rclpy.parameter.Parameter( - 'my_parameter', - rclpy.Parameter.Type.STRING, - 'world' - ) - all_new_parameters = [my_new_param] - self.set_parameters(all_new_parameters) - -Following the ``timer_callback`` is our ``main``. -Here ROS 2 is initialized, an instance of the ``MinimalParam`` class is constructed, and ``rclpy.spin`` starts processing data from the node. - -.. code-block:: Python - - def main(): - try: - with rclpy.init(): - node = MinimalParam() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - if __name__ == '__main__': - main() - - -2.1.1 (Optional) Add ParameterDescriptor -"""""""""""""""""""""""""""""""""""""""" -Optionally, you can set a descriptor for the parameter. -Descriptors allow you to specify a text description of the parameter and its constraints, like making it read-only, specifying a range, etc. -For that to work, the ``__init__`` code has to be changed to: - -.. code-block:: Python - - # ... - - class MinimalParam(Node): - def __init__(self): - super().__init__('minimal_param_node') - - from rcl_interfaces.msg import ParameterDescriptor - my_parameter_descriptor = ParameterDescriptor(description='This parameter is mine!') - - self.declare_parameter('my_parameter', 'world', my_parameter_descriptor) - - self.timer = self.create_timer(1, self.timer_callback) - -Since we are importing ``rcl_interfaces``, we need to add the dependency to ``package.xml`` to avoid any dependency issue in the future: - -.. code-block:: xml - - # ... - rclpy - rcl_interfaces - -The rest of the code remains the same. -Once you run the node, you can then run ``ros2 param describe /minimal_param_node my_parameter`` to see the type and description. - -2.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file. -Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: - -.. code-block:: python - - maintainer='YourName', - maintainer_email='you@email.com', - description='Python parameter tutorial', - license='Apache-2.0', - -Add the following line within the ``console_scripts`` brackets of the ``entry_points`` field: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'minimal_param_node = python_parameters.python_parameters_node:main', - ], - }, - -Don't forget to save. - - -3 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select python_parameters - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select python_parameters - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select python_parameters - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node. -The terminal should return ``Hello world!`` every second: - -.. code-block:: console - - $ ros2 run python_parameters minimal_param_node - [INFO] [parameter_node]: Hello world! - -Now you can see the default value of your parameter, but you want to be able to set it yourself. -There are four ways to accomplish this. - -3.1 Change via the console -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This part will use the knowledge you have gained from the :doc:`tutorial about parameters <../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and apply it to the node you have just created. - -Make sure the node is running: - -.. code-block:: console - - $ ros2 run python_parameters minimal_param_node - -Open another terminal, source the setup files from inside ``ros2_ws`` again, and enter the following line: - -.. code-block:: console - - $ ros2 param list - -There you will see the custom parameter ``my_parameter``. -To change it, simply run the following line in the console: - -.. code-block:: console - - $ ros2 param set /minimal_param_node my_parameter earth - -You know it went well if you get the output ``Set parameter successful``. -If you look at the other terminal, you should see the output change to ``[INFO] [minimal_param_node]: Hello earth!`` - -Since the node afterwards set the parameter back to ``world``, further outputs show ``[INFO] [minimal_param_node]: Hello world!`` - -3.2 Change via a launch file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can also set parameters in a launch file, but first you will need to add a launch directory. -Inside the ``ros2_ws/src/python_parameters/`` directory, create a new directory called ``launch``. -In there, create a new file called ``python_parameters_launch.py`` - -.. literalinclude:: launch/python_parameters_launch.py - :language: python - -Here you can see that we set ``my_parameter`` to ``earth`` when we launch our node ``parameter_node``. -By adding the two lines below, we ensure our output is printed in our console. - -.. code-block:: console - - output="screen", - emulate_tty=True, - -Now open the ``setup.py`` file. -Add the ``import`` statements to the top of the file, and the other new statement to the ``data_files`` parameter to include all launch files: - -.. code-block:: Python - - import os - from glob import glob - # ... - - setup( - # ... - data_files=[ - # ... - (os.path.join('share', package_name, 'launch'), glob('launch/*')), - ] - ) - -Open a console and navigate to the root of your workspace, ``ros2_ws``, and build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select python_parameters - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select python_parameters - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select python_parameters - -Then source the setup files in a new terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node using the launch file we have just created: - -.. code-block:: console - - $ ros2 launch python_parameters python_parameters_launch.py - [INFO] [custom_minimal_param_node]: Hello earth! - -Further outputs should show ``[INFO] [minimal_param_node]: Hello world!`` every second. - -3.3 Change via launch file loading parameters from YAML file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Instead of listing parameters and their values in launch file, you can create a separate YAML file that will be loaded in launch file. -Placing parameters in a YAML file makes it easier to organize them, for example, by assigning them to different namespaces. -You can read more about it :ref:`here `. - -.. note:: - - While declaring, getting and setting parameter value inside your Python node, you should use dot as a separator between parameter's namespace and name. - -3.4 Change via passing YAML file as an argument at node startup -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Return to :ref:`tutorial about parameters ` to remind yourself, how to load parameters file at node startup using CLI. - -Summary -------- - -You created a node with a custom parameter that can be set either from a launch file or the command line. -You added the dependencies, executables, and a launch file to the package configuration files so that you could build and run them, and see the parameter in action. - -Next steps ----------- - -Now that you have some packages and ROS 2 systems of your own, the :doc:`next tutorial <./Getting-Started-With-Ros2doctor>` will show you how to examine issues in your environment and systems in case you have problems. - -Related content ---------------- - -* For more detailed information about using YAML files to load parameters, please refer to :ref:`this section ` of Managing large projects tutorial. -* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (Python) <../Intermediate/Monitoring-For-Parameter-Changes-Python>` tutorial. +.. redirect-from:: + + Tutorials/Using-Parameters-In-A-Class-Python + Tutorials/Beginner-Client-Libraries/Using-Parameters-In-A-Class-Python + +.. _PythonParamNode: + +Using parameters in a class (Python) +==================================== + +**Goal:** Create and run a class with ROS parameters using Python. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When making your own :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` you will sometimes need to add parameters that can be set from the launch file. + +This tutorial will show you how to create those parameters in a Python class, and how to set them using launch file. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. +You have also learned about :doc:`parameters <../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and their function in a ROS 2 system. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +Navigate into ``ros2_ws/src`` and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 python_parameters --dependencies rclpy + +Your terminal will return a message verifying the creation of your package ``python_parameters`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. + +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + Python parameter tutorial + Your Name + Apache-2.0 + +2 Write the Python node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/python_parameters/python_parameters`` directory, create a new file called ``python_parameters_node.py`` and paste the following code within: + +.. code-block:: Python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + class MinimalParam(Node): + def __init__(self): + super().__init__('minimal_param_node') + + self.declare_parameter('my_parameter', 'world') + + self.timer = self.create_timer(1, self.timer_callback) + + def timer_callback(self): + my_param = self.get_parameter('my_parameter').get_parameter_value().string_value + + self.get_logger().info('Hello %s!' % my_param) + + my_new_param = rclpy.parameter.Parameter( + 'my_parameter', + rclpy.Parameter.Type.STRING, + 'world' + ) + all_new_parameters = [my_new_param] + self.set_parameters(all_new_parameters) + + def main(): + try: + with rclpy.init(): + node = MinimalParam() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + if __name__ == '__main__': + main() + + + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ +The ``import`` statements at the top are used to import the package dependencies. + +The next piece of code creates the class and the constructor. +The line ``self.declare_parameter('my_parameter', 'world')`` of the constructor creates a parameter with the name ``my_parameter`` and a default value of ``world``. +The parameter type is inferred from the default value, so in this case it would be set to a string type. +Next the ``timer`` is initialized with a period of 1, which causes the ``timer_callback`` function to be executed once a second. + +.. code-block:: Python + + class MinimalParam(Node): + def __init__(self): + super().__init__('minimal_param_node') + + self.declare_parameter('my_parameter', 'world') + + self.timer = self.create_timer(1, self.timer_callback) + +The first line of our ``timer_callback`` function gets the parameter ``my_parameter`` from the node, and stores it in ``my_param``. +Next the ``get_logger`` function ensures the event is logged. +The ``set_parameters`` function then sets the parameter ``my_parameter`` back to the default string value ``world``. +In the case that the user changed the parameter externally, this ensures it is always reset back to the original. + +.. code-block:: Python + + def timer_callback(self): + my_param = self.get_parameter('my_parameter').get_parameter_value().string_value + + self.get_logger().info('Hello %s!' % my_param) + + my_new_param = rclpy.parameter.Parameter( + 'my_parameter', + rclpy.Parameter.Type.STRING, + 'world' + ) + all_new_parameters = [my_new_param] + self.set_parameters(all_new_parameters) + +Following the ``timer_callback`` is our ``main``. +Here ROS 2 is initialized, an instance of the ``MinimalParam`` class is constructed, and ``rclpy.spin`` starts processing data from the node. + +.. code-block:: Python + + def main(): + try: + with rclpy.init(): + node = MinimalParam() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + if __name__ == '__main__': + main() + + +2.1.1 (Optional) Add ParameterDescriptor +"""""""""""""""""""""""""""""""""""""""" +Optionally, you can set a descriptor for the parameter. +Descriptors allow you to specify a text description of the parameter and its constraints, like making it read-only, specifying a range, etc. +For that to work, the ``__init__`` code has to be changed to: + +.. code-block:: Python + + # ... + + class MinimalParam(Node): + def __init__(self): + super().__init__('minimal_param_node') + + from rcl_interfaces.msg import ParameterDescriptor + my_parameter_descriptor = ParameterDescriptor(description='This parameter is mine!') + + self.declare_parameter('my_parameter', 'world', my_parameter_descriptor) + + self.timer = self.create_timer(1, self.timer_callback) + +Since we are importing ``rcl_interfaces``, we need to add the dependency to ``package.xml`` to avoid any dependency issue in the future: + +.. code-block:: xml + + # ... + rclpy + rcl_interfaces + +The rest of the code remains the same. +Once you run the node, you can then run ``ros2 param describe /minimal_param_node my_parameter`` to see the type and description. + +2.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file. +Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: + +.. code-block:: python + + maintainer='YourName', + maintainer_email='you@email.com', + description='Python parameter tutorial', + license='Apache-2.0', + +Add the following line within the ``console_scripts`` brackets of the ``entry_points`` field: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'minimal_param_node = python_parameters.python_parameters_node:main', + ], + }, + +Don't forget to save. + + +3 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select python_parameters + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select python_parameters + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select python_parameters + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node. +The terminal should return ``Hello world!`` every second: + +.. code-block:: console + + $ ros2 run python_parameters minimal_param_node + [INFO] [parameter_node]: Hello world! + +Now you can see the default value of your parameter, but you want to be able to set it yourself. +There are four ways to accomplish this. + +3.1 Change via the console +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This part will use the knowledge you have gained from the :doc:`tutorial about parameters <../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` and apply it to the node you have just created. + +Make sure the node is running: + +.. code-block:: console + + $ ros2 run python_parameters minimal_param_node + +Open another terminal, source the setup files from inside ``ros2_ws`` again, and enter the following line: + +.. code-block:: console + + $ ros2 param list + +There you will see the custom parameter ``my_parameter``. +To change it, simply run the following line in the console: + +.. code-block:: console + + $ ros2 param set /minimal_param_node my_parameter earth + +You know it went well if you get the output ``Set parameter successful``. +If you look at the other terminal, you should see the output change to ``[INFO] [minimal_param_node]: Hello earth!`` + +Since the node afterwards set the parameter back to ``world``, further outputs show ``[INFO] [minimal_param_node]: Hello world!`` + +3.2 Change via a launch file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also set parameters in a launch file, but first you will need to add a launch directory. +Inside the ``ros2_ws/src/python_parameters/`` directory, create a new directory called ``launch``. +In there, create a new file called ``python_parameters_launch.py`` + +.. literalinclude:: launch/python_parameters_launch.py + :language: python + +Here you can see that we set ``my_parameter`` to ``earth`` when we launch our node ``parameter_node``. +By adding the two lines below, we ensure our output is printed in our console. + +.. code-block:: console + + output="screen", + emulate_tty=True, + +Now open the ``setup.py`` file. +Add the ``import`` statements to the top of the file, and the other new statement to the ``data_files`` parameter to include all launch files: + +.. code-block:: Python + + import os + from glob import glob + # ... + + setup( + # ... + data_files=[ + # ... + (os.path.join('share', package_name, 'launch'), glob('launch/*')), + ] + ) + +Open a console and navigate to the root of your workspace, ``ros2_ws``, and build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select python_parameters + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select python_parameters + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select python_parameters + +Then source the setup files in a new terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node using the launch file we have just created: + +.. code-block:: console + + $ ros2 launch python_parameters python_parameters_launch.py + [INFO] [custom_minimal_param_node]: Hello earth! + +Further outputs should show ``[INFO] [minimal_param_node]: Hello world!`` every second. + +3.3 Change via launch file loading parameters from YAML file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Instead of listing parameters and their values in launch file, you can create a separate YAML file that will be loaded in launch file. +Placing parameters in a YAML file makes it easier to organize them, for example, by assigning them to different namespaces. +You can read more about it :ref:`here `. + +.. note:: + + While declaring, getting and setting parameter value inside your Python node, you should use dot as a separator between parameter's namespace and name. + +3.4 Change via passing YAML file as an argument at node startup +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Return to :ref:`tutorial about parameters ` to remind yourself, how to load parameters file at node startup using CLI. + +Summary +------- + +You created a node with a custom parameter that can be set either from a launch file or the command line. +You added the dependencies, executables, and a launch file to the package configuration files so that you could build and run them, and see the parameter in action. + +Next steps +---------- + +Now that you have some packages and ROS 2 systems of your own, the :doc:`next tutorial ` will show you how to examine issues in your environment and systems in case you have problems. + +Related content +--------------- + +* For more detailed information about using YAML files to load parameters, please refer to :ref:`this section ` of Managing large projects tutorial. +* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (Python) <../../parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst index 8c489f99606..6ef863961d1 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst @@ -1,536 +1,537 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Cpp-Publisher-And-Subscriber - -.. _CppPubSub: - -Writing a simple publisher and subscriber (C++) -=============================================== - -**Goal:** Create and run a publisher and subscriber node using C++. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -:doc:`Nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` are executable processes that communicate over the ROS graph. -In this tutorial, the nodes will pass information in the form of string messages to each other over a :doc:`topic <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. -The example used here is a simple "talker" and "listener" system; one node publishes data and the other subscribes to the topic so it can receive that data. - -The code used in these examples can be found `here `__. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <./Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <./Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -So, navigate into ``ros2_ws/src``, and run the package creation command: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_pubsub - -Your terminal will return a message verifying the creation of your package ``cpp_pubsub`` and all its necessary files and folders. - -Navigate into ``ros2_ws/src/cpp_pubsub/src``. -Recall that this is the directory in any CMake package where the source files containing executables belong. - - -2 Write the publisher node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Download the example talker code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp - -Now there will be a new file named ``publisher_lambda_function.cpp``. -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - - /* This example creates a subclass of Node and uses a fancy C++11 lambda - * function to shorten the callback syntax, at the expense of making the - * code somewhat more difficult to understand at first glance. */ - - class MinimalPublisher : public rclcpp::Node - { - public: - MinimalPublisher() - : Node("minimal_publisher"), count_(0) - { - publisher_ = this->create_publisher("topic", 10); - auto timer_callback = - [this]() -> void { - auto message = std_msgs::msg::String(); - message.data = "Hello, world! " + std::to_string(this->count_++); - RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); - this->publisher_->publish(message); - }; - timer_ = this->create_wall_timer(500ms, timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; - size_t count_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The top of the code includes the standard C++ headers you will be using. -After the standard C++ headers is the ``rclcpp/rclcpp.hpp`` include which allows you to use the most common pieces of the ROS 2 system. -Last is ``std_msgs/msg/string.hpp``, which includes the built-in message type you will use to publish data. - -.. code-block:: C++ - - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - -These lines represent the node's dependencies. -Recall that dependencies have to be added to ``package.xml`` and ``CMakeLists.txt``, which you'll do in the next section. - -The next line creates the node class ``MinimalPublisher`` by inheriting from ``rclcpp::Node``. -Every ``this`` in the code is referring to the node. - -.. code-block:: C++ - - class MinimalPublisher : public rclcpp::Node - -The public constructor names the node ``minimal_publisher`` and initializes ``count_`` to 0. -Inside the constructor, the publisher is initialized with the ``String`` message type, the topic name ``topic``, and the required queue size to limit messages in the event of a backup. -Next, a `lambda function `_ called ``timer_callback`` is declared. -It performs a by-reference capture of the current object ``this``, takes no input arguments and returns void. -The ``timer_callback`` function creates a new message of type ``String``, sets its data with the desired string and publishes it. -The ``RCLCPP_INFO`` macro ensures every published message is printed to the console. -At last, ``timer_`` is initialized, which causes the ``timer_callback`` function to be executed twice a second. - -.. code-block:: C++ - - public: - MinimalPublisher() - : Node("minimal_publisher"), count_(0) - { - publisher_ = this->create_publisher("topic", 10); - auto timer_callback = - [this]() -> void { - auto message = std_msgs::msg::String(); - message.data = "Hello, world! " + std::to_string(this->count_++); - RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); - this->publisher_->publish(message); - }; - timer_ = this->create_wall_timer(500ms, timer_callback); - } - -In the bottom of the class is the declaration of the timer, publisher, and counter fields. - -.. code-block:: C++ - - private: - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; - size_t count_; - -Following the ``MinimalPublisher`` class is ``main``, where the node actually executes. -``rclcpp::init`` initializes ROS 2, and ``rclcpp::spin`` starts processing data from the node, including callbacks from the timer. - -.. code-block:: C++ - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``ros2_ws/src/cpp_pubsub`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`previous tutorial <./Creating-Your-First-ROS2-Package>`, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Examples of minimal publisher/subscriber using rclcpp - Your Name - Apache-2.0 - -Add a new line after the ``ament_cmake`` buildtool dependency and paste the following dependencies corresponding to your node's include statements: - -.. code-block:: xml - - rclcpp - std_msgs - -This declares the package needs ``rclcpp`` and ``std_msgs`` when its code is built and executed. - -Make sure to save the file. - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. -Below the existing dependency ``find_package(ament_cmake REQUIRED)``, add the lines: - -.. code-block:: cmake - - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - -After that, add the executable and name it ``talker`` so you can run your node using ``ros2 run``: - -.. code-block:: cmake - - add_executable(talker src/publisher_lambda_function.cpp) - target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - -Finally, add the ``install(TARGETS...)`` section so ``ros2 run`` can find your executable: - -.. code-block:: cmake - - install(TARGETS - talker - DESTINATION lib/${PROJECT_NAME}) - -You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(cpp_pubsub) - - # Default to C++20 - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - - add_executable(talker src/publisher_lambda_function.cpp) - target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - talker - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - -You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. - -3 Write the subscriber node -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Return to ``ros2_ws/src/cpp_pubsub/src`` to create the next node. -Enter the following code in your terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp - -Check to ensure that these files exist: - -.. code-block:: console - - publisher_lambda_function.cpp subscriber_lambda_function.cpp - -Open the ``subscriber_lambda_function.cpp`` with your text editor. - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - class MinimalSubscriber : public rclcpp::Node - { - public: - MinimalSubscriber() - : Node("minimal_subscriber") - { - auto topic_callback = - [this](std_msgs::msg::String::UniquePtr msg) -> void { - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); - }; - subscription_ = - this->create_subscription("topic", 10, topic_callback); - } - - private: - rclcpp::Subscription::SharedPtr subscription_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The subscriber node's code is nearly identical to the publisher's. -Now the node is named ``minimal_subscriber``, and the constructor uses the node's ``create_subscription`` function to execute the callback. - -There is no timer because the subscriber simply responds whenever data is published to the ``topic`` topic. - -The ``topic_callback`` function receives the string message data published over the topic, and simply writes it to the console using the ``RCLCPP_INFO`` macro. - -Recall from the :doc:`topic tutorial <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. - -.. code-block:: C++ - - public: - MinimalSubscriber() - : Node("minimal_subscriber") - { - auto topic_callback = - [this](std_msgs::msg::String::UniquePtr msg) -> void { - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); - }; - subscription_ = - this->create_subscription("topic", 10, topic_callback); - } - -The only field declaration in this class is the subscription. - -.. code-block:: C++ - - private: - rclcpp::Subscription::SharedPtr subscription_; - -The ``main`` function is exactly the same, except now it spins the ``MinimalSubscriber`` node. -For the publisher node, spinning meant starting the timer, but for the subscriber it simply means preparing to receive messages whenever they come. - -Since this node has the same dependencies as the publisher node, there's nothing new to add to ``package.xml``. - -3.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Reopen ``CMakeLists.txt`` and add the executable and target for the subscriber node below the publisher's entries. - -.. code-block:: cmake - - add_executable(listener src/subscriber_lambda_function.cpp) - target_link_libraries(listener PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - talker - listener - DESTINATION lib/${PROJECT_NAME}) - -Make sure to save the file, and then your pub/sub system should be ready. - -.. _cpppubsub-build-and-run: - -4 Build and run -^^^^^^^^^^^^^^^ -You likely already have the ``rclcpp`` and ``std_msgs`` packages installed as part of your ROS 2 system. -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Still in the root of your workspace, ``ros2_ws``, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select cpp_pubsub - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select cpp_pubsub - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_pubsub - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the talker node. -The terminal should start publishing info messages every 0.5 seconds, like so: - -.. code-block:: console - - $ ros2 run cpp_pubsub talker - [INFO] [minimal_publisher]: Publishing: "Hello World: 0" - [INFO] [minimal_publisher]: Publishing: "Hello World: 1" - [INFO] [minimal_publisher]: Publishing: "Hello World: 2" - [INFO] [minimal_publisher]: Publishing: "Hello World: 3" - [INFO] [minimal_publisher]: Publishing: "Hello World: 4" - -Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. -The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time: - -.. code-block:: console - - $ ros2 run cpp_pubsub listener - [INFO] [minimal_subscriber]: I heard: "Hello World: 10" - [INFO] [minimal_subscriber]: I heard: "Hello World: 11" - [INFO] [minimal_subscriber]: I heard: "Hello World: 12" - [INFO] [minimal_subscriber]: I heard: "Hello World: 13" - [INFO] [minimal_subscriber]: I heard: "Hello World: 14" - -Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. - -Summary -------- - -You created two nodes to publish and subscribe to data over a topic. -Before compiling and running them, you added their dependencies and executables to the package configuration files. - -Next steps ----------- - -Next you'll create another simple ROS 2 package using the service/client model. -Again, you can choose to write it in either :doc:`C++ <./Writing-A-Simple-Cpp-Service-And-Client>` or :doc:`Python <./Writing-A-Simple-Py-Service-And-Client>`. - -Related content ---------------- - -There are several ways you could write a publisher and subscriber in C++; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. +.. redirect-from:: + + Tutorials/Writing-A-Simple-Cpp-Publisher-And-Subscriber + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber + +.. _CppPubSub: + +Writing a simple publisher and subscriber (C++) +=============================================== + +**Goal:** Create and run a publisher and subscriber node using C++. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +:doc:`Nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` are executable processes that communicate over the ROS graph. +In this tutorial, the nodes will pass information in the form of string messages to each other over a :doc:`topic <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. +The example used here is a simple "talker" and "listener" system; one node publishes data and the other subscribes to the topic so it can receive that data. + +The code used in these examples can be found `here `__. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +So, navigate into ``ros2_ws/src``, and run the package creation command: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_pubsub + +Your terminal will return a message verifying the creation of your package ``cpp_pubsub`` and all its necessary files and folders. + +Navigate into ``ros2_ws/src/cpp_pubsub/src``. +Recall that this is the directory in any CMake package where the source files containing executables belong. + + +2 Write the publisher node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Download the example talker code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp + +Now there will be a new file named ``publisher_lambda_function.cpp``. +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + + /* This example creates a subclass of Node and uses a fancy C++11 lambda + * function to shorten the callback syntax, at the expense of making the + * code somewhat more difficult to understand at first glance. */ + + class MinimalPublisher : public rclcpp::Node + { + public: + MinimalPublisher() + : Node("minimal_publisher"), count_(0) + { + publisher_ = this->create_publisher("topic", 10); + auto timer_callback = + [this]() -> void { + auto message = std_msgs::msg::String(); + message.data = "Hello, world! " + std::to_string(this->count_++); + RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); + this->publisher_->publish(message); + }; + timer_ = this->create_wall_timer(500ms, timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; + size_t count_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The top of the code includes the standard C++ headers you will be using. +After the standard C++ headers is the ``rclcpp/rclcpp.hpp`` include which allows you to use the most common pieces of the ROS 2 system. +Last is ``std_msgs/msg/string.hpp``, which includes the built-in message type you will use to publish data. + +.. code-block:: C++ + + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + +These lines represent the node's dependencies. +Recall that dependencies have to be added to ``package.xml`` and ``CMakeLists.txt``, which you'll do in the next section. + +The next line creates the node class ``MinimalPublisher`` by inheriting from ``rclcpp::Node``. +Every ``this`` in the code is referring to the node. + +.. code-block:: C++ + + class MinimalPublisher : public rclcpp::Node + +The public constructor names the node ``minimal_publisher`` and initializes ``count_`` to 0. +Inside the constructor, the publisher is initialized with the ``String`` message type, the topic name ``topic``, and the required queue size to limit messages in the event of a backup. +Next, a `lambda function `_ called ``timer_callback`` is declared. +It performs a by-reference capture of the current object ``this``, takes no input arguments and returns void. +The ``timer_callback`` function creates a new message of type ``String``, sets its data with the desired string and publishes it. +The ``RCLCPP_INFO`` macro ensures every published message is printed to the console. +At last, ``timer_`` is initialized, which causes the ``timer_callback`` function to be executed twice a second. + +.. code-block:: C++ + + public: + MinimalPublisher() + : Node("minimal_publisher"), count_(0) + { + publisher_ = this->create_publisher("topic", 10); + auto timer_callback = + [this]() -> void { + auto message = std_msgs::msg::String(); + message.data = "Hello, world! " + std::to_string(this->count_++); + RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); + this->publisher_->publish(message); + }; + timer_ = this->create_wall_timer(500ms, timer_callback); + } + +In the bottom of the class is the declaration of the timer, publisher, and counter fields. + +.. code-block:: C++ + + private: + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; + size_t count_; + +Following the ``MinimalPublisher`` class is ``main``, where the node actually executes. +``rclcpp::init`` initializes ROS 2, and ``rclcpp::spin`` starts processing data from the node, including callbacks from the timer. + +.. code-block:: C++ + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``ros2_ws/src/cpp_pubsub`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`previous tutorial `, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Examples of minimal publisher/subscriber using rclcpp + Your Name + Apache-2.0 + +Add a new line after the ``ament_cmake`` buildtool dependency and paste the following dependencies corresponding to your node's include statements: + +.. code-block:: xml + + rclcpp + std_msgs + +This declares the package needs ``rclcpp`` and ``std_msgs`` when its code is built and executed. + +Make sure to save the file. + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. +Below the existing dependency ``find_package(ament_cmake REQUIRED)``, add the lines: + +.. code-block:: cmake + + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + +After that, add the executable and name it ``talker`` so you can run your node using ``ros2 run``: + +.. code-block:: cmake + + add_executable(talker src/publisher_lambda_function.cpp) + target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + +Finally, add the ``install(TARGETS...)`` section so ``ros2 run`` can find your executable: + +.. code-block:: cmake + + install(TARGETS + talker + DESTINATION lib/${PROJECT_NAME}) + +You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(cpp_pubsub) + + # Default to C++20 + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + + add_executable(talker src/publisher_lambda_function.cpp) + target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + talker + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + +You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. + +3 Write the subscriber node +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Return to ``ros2_ws/src/cpp_pubsub/src`` to create the next node. +Enter the following code in your terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp + +Check to ensure that these files exist: + +.. code-block:: console + + publisher_lambda_function.cpp subscriber_lambda_function.cpp + +Open the ``subscriber_lambda_function.cpp`` with your text editor. + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + class MinimalSubscriber : public rclcpp::Node + { + public: + MinimalSubscriber() + : Node("minimal_subscriber") + { + auto topic_callback = + [this](std_msgs::msg::String::UniquePtr msg) -> void { + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); + }; + subscription_ = + this->create_subscription("topic", 10, topic_callback); + } + + private: + rclcpp::Subscription::SharedPtr subscription_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The subscriber node's code is nearly identical to the publisher's. +Now the node is named ``minimal_subscriber``, and the constructor uses the node's ``create_subscription`` function to execute the callback. + +There is no timer because the subscriber simply responds whenever data is published to the ``topic`` topic. + +The ``topic_callback`` function receives the string message data published over the topic, and simply writes it to the console using the ``RCLCPP_INFO`` macro. + +Recall from the :doc:`topic tutorial <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. + +.. code-block:: C++ + + public: + MinimalSubscriber() + : Node("minimal_subscriber") + { + auto topic_callback = + [this](std_msgs::msg::String::UniquePtr msg) -> void { + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); + }; + subscription_ = + this->create_subscription("topic", 10, topic_callback); + } + +The only field declaration in this class is the subscription. + +.. code-block:: C++ + + private: + rclcpp::Subscription::SharedPtr subscription_; + +The ``main`` function is exactly the same, except now it spins the ``MinimalSubscriber`` node. +For the publisher node, spinning meant starting the timer, but for the subscriber it simply means preparing to receive messages whenever they come. + +Since this node has the same dependencies as the publisher node, there's nothing new to add to ``package.xml``. + +3.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Reopen ``CMakeLists.txt`` and add the executable and target for the subscriber node below the publisher's entries. + +.. code-block:: cmake + + add_executable(listener src/subscriber_lambda_function.cpp) + target_link_libraries(listener PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + talker + listener + DESTINATION lib/${PROJECT_NAME}) + +Make sure to save the file, and then your pub/sub system should be ready. + +.. _cpppubsub-build-and-run: + +4 Build and run +^^^^^^^^^^^^^^^ +You likely already have the ``rclcpp`` and ``std_msgs`` packages installed as part of your ROS 2 system. +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Still in the root of your workspace, ``ros2_ws``, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select cpp_pubsub + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select cpp_pubsub + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_pubsub + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the talker node. +The terminal should start publishing info messages every 0.5 seconds, like so: + +.. code-block:: console + + $ ros2 run cpp_pubsub talker + [INFO] [minimal_publisher]: Publishing: "Hello World: 0" + [INFO] [minimal_publisher]: Publishing: "Hello World: 1" + [INFO] [minimal_publisher]: Publishing: "Hello World: 2" + [INFO] [minimal_publisher]: Publishing: "Hello World: 3" + [INFO] [minimal_publisher]: Publishing: "Hello World: 4" + +Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. +The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time: + +.. code-block:: console + + $ ros2 run cpp_pubsub listener + [INFO] [minimal_subscriber]: I heard: "Hello World: 10" + [INFO] [minimal_subscriber]: I heard: "Hello World: 11" + [INFO] [minimal_subscriber]: I heard: "Hello World: 12" + [INFO] [minimal_subscriber]: I heard: "Hello World: 13" + [INFO] [minimal_subscriber]: I heard: "Hello World: 14" + +Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. + +Summary +------- + +You created two nodes to publish and subscribe to data over a topic. +Before compiling and running them, you added their dependencies and executables to the package configuration files. + +Next steps +---------- + +Next you'll create another simple ROS 2 package using the service/client model. +Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. + +Related content +--------------- + +There are several ways you could write a publisher and subscriber in C++; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst index 4c439fe43dd..40cfbe1b061 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst @@ -1,409 +1,410 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Cpp-Service-And-Client - -.. _CppSrvCli: - -Writing a simple service and client (C++) -========================================= - -**Goal:** Create and run service and client nodes using C++. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When :doc:`nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. -The structure of the request and response is determined by a ``.srv`` file. - -The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. - - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <./Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <./Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -Navigate into ``ros2_ws/src`` and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_srvcli --dependencies rclcpp example_interfaces - -Your terminal will return a message verifying the creation of your package ``cpp_srvcli`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. -``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: - -.. code-block:: bash - - int64 a - int64 b - --- - int64 sum - -The first two lines are the parameters of the request, and below the dashes is the response. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. - -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - C++ client server tutorial - Your Name - Apache-2.0 - - -2 Write the service node -^^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_server.cpp`` and paste the following code within: - -.. code-block:: C++ - - #include - #include - - #include "example_interfaces/srv/add_two_ints.hpp" - #include "rclcpp/rclcpp.hpp" - - using AddTwoInts = example_interfaces::srv::AddTwoInts; - rclcpp::Node::SharedPtr g_node = nullptr; - - void handle_service( - const std::shared_ptr request_header, - const std::shared_ptr request, - const std::shared_ptr response) - { - (void)request_header; - RCLCPP_INFO( - g_node->get_logger(), - "request: %" PRId64 " + %" PRId64, request->a, request->b); - response->sum = request->a + request->b; - } - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - g_node = rclcpp::Node::make_shared("minimal_service"); - auto server = g_node->create_service("add_two_ints", handle_service); - rclcpp::spin(g_node); - rclcpp::shutdown(); - g_node = nullptr; - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The first ``#include`` statements are your package dependencies. - -The ``handle_service`` function adds two integers from the request and gives the sum to the response, while notifying the console of its status using logs. - -.. code-block:: C++ - - void handle_service( - const std::shared_ptr request_header, - const std::shared_ptr request, - const std::shared_ptr response) - { - (void)request_header; - RCLCPP_INFO( - g_node->get_logger(), - "request: %" PRId64 " + %" PRId64, request->a, request->b); - response->sum = request->a + request->b; - } - -The ``main`` function accomplishes the following, line by line: - -* Initializes ROS 2 C++ client library: - - .. code-block:: C++ - - rclcpp::init(argc, argv); - -* Creates a node named ``minimal_service``: - - .. code-block:: C++ - - g_node = rclcpp::Node::make_shared("minimal_service"); - -* Creates a service named ``add_two_ints`` for that node and automatically advertises it over the networks with the ``handle_service`` method: - - .. code-block:: C++ - - auto server = g_node->create_service("add_two_ints", handle_service); - -* Spins the node, making the service available. - - .. code-block:: C++ - - rclcpp::spin(g_node); - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -The ``add_executable`` macro generates an executable you can run using ``ros2 run``. -Add the following code block to ``CMakeLists.txt`` just below the dependencies to create an executable named ``server``: - -.. code-block:: cmake - - add_executable(server src/add_two_ints_server.cpp) - target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) - -So ``ros2 run`` can find the executable, add the following lines to the end of the file, right before ``ament_package()``: - -.. code-block:: cmake - - install(TARGETS - server - DESTINATION lib/${PROJECT_NAME}) - -You could build your package now, source the local setup files, and run it, but let's create the client node first so you can see the full system at work. - -3 Write the client node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_client.cpp`` and paste the following code within: - -.. code-block:: C++ - - #include - #include - #include - - #include "example_interfaces/srv/add_two_ints.hpp" - #include "rclcpp/rclcpp.hpp" - - using AddTwoInts = example_interfaces::srv::AddTwoInts; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - auto node = rclcpp::Node::make_shared("minimal_client"); - auto client = node->create_client("add_two_ints"); - while (!client->wait_for_service(std::chrono::seconds(1))) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); - return 1; - } - RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); - } - auto request = std::make_shared(); - request->a = 41; - request->b = 1; - auto result_future = client->async_send_request(request); - if (rclcpp::spin_until_future_complete(node, result_future) != - rclcpp::FutureReturnCode::SUCCESS) - { - RCLCPP_ERROR(node->get_logger(), "service call failed :("); - client->remove_pending_request(result_future); - return 1; - } - auto result = result_future.get(); - RCLCPP_INFO( - node->get_logger(), "result of %" PRId64 " + %" PRId64 " = %" PRId64, - request->a, request->b, result->sum); - rclcpp::shutdown(); - return 0; - } - - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Similar to the service node, the following lines of code create the node and then create the client for that node: - -.. code-block:: C++ - - auto node = rclcpp::Node::make_shared("minimal_client"); - auto client = node->create_client("add_two_ints"); - -Next, the code waits for the service to appear. -The ``while`` loop gives the client 1 second to search for service nodes in the network. -If it can't find any, it will continue waiting. -If the client is canceled (e.g. by you entering ``Ctrl+C`` into the terminal), it will return an error log message stating it was interrupted. - -.. code-block:: C++ - - while (!client->wait_for_service(std::chrono::seconds(1))) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); - return 1; - } - RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); - } - -Next, the request is created. -Its structure is defined by the ``.srv`` file mentioned earlier. - -.. code-block:: C++ - - auto request = std::make_shared(); - request->a = 41; - request->b = 1; - - -Then the client sends its request, and the node spins until it receives its response, or fails. - -3.2 Add executable -~~~~~~~~~~~~~~~~~~ - -Return to ``CMakeLists.txt`` to add the executable and target for the new node. -After removing some unnecessary boilerplate from the automatically generated file, your ``CMakeLists.txt`` should look like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(cpp_srvcli) - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(example_interfaces REQUIRED) - - add_executable(server src/add_two_ints_server.cpp) - target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) - - add_executable(client src/add_two_ints_client.cpp) - target_link_libraries(client PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) - - install(TARGETS - server - client - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - - -4 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select cpp_srvcli - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select cpp_srvcli - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_srvcli - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the service node: - -.. code-block:: console - - $ ros2 run cpp_srvcli server - -The terminal should wait for incoming requests. - -Open another terminal, source the setup files from inside ``ros2_ws`` again. -Start the client node, followed by any two integers separated by a space. -The client sends the request to the service, which computes the sum and returns the result: - -.. code-block:: console - - $ ros2 run cpp_srvcli client - [INFO] [minimal_client]: result of 41 + 1: 42 - -The client should receive the response above. - -Return to the terminal where your service node is running. -You will see that it published log messages when it received the request and the data it received, and the response it sent back: - -.. code-block:: console - - [INFO] [minimal_service]: request: 41 + 1 - -Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. - -Summary -------- - -You created two nodes to request and respond to data over a service. -You added their dependencies and executables to the package configuration files so that you could build and run them, and see a service/client system at work. - -Next steps ----------- - -In the last few tutorials you've been utilizing interfaces to pass data across topics and services. -Next, you'll learn how to :doc:`create custom interfaces <./Custom-ROS2-Interfaces>`. - -Related content ---------------- - -* There are several ways you could write a service and client in C++; check out the ``minimal_service`` and ``minimal_client`` packages in the `ros2/examples `_ repo. +.. redirect-from:: + + Tutorials/Writing-A-Simple-Cpp-Service-And-Client + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client + +.. _CppSrvCli: + +Writing a simple service and client (C++) +========================================= + +**Goal:** Create and run service and client nodes using C++. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. +The structure of the request and response is determined by a ``.srv`` file. + +The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. + + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +Navigate into ``ros2_ws/src`` and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_srvcli --dependencies rclcpp example_interfaces + +Your terminal will return a message verifying the creation of your package ``cpp_srvcli`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. +``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: + +.. code-block:: bash + + int64 a + int64 b + --- + int64 sum + +The first two lines are the parameters of the request, and below the dashes is the response. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. + +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + C++ client server tutorial + Your Name + Apache-2.0 + + +2 Write the service node +^^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_server.cpp`` and paste the following code within: + +.. code-block:: C++ + + #include + #include + + #include "example_interfaces/srv/add_two_ints.hpp" + #include "rclcpp/rclcpp.hpp" + + using AddTwoInts = example_interfaces::srv::AddTwoInts; + rclcpp::Node::SharedPtr g_node = nullptr; + + void handle_service( + const std::shared_ptr request_header, + const std::shared_ptr request, + const std::shared_ptr response) + { + (void)request_header; + RCLCPP_INFO( + g_node->get_logger(), + "request: %" PRId64 " + %" PRId64, request->a, request->b); + response->sum = request->a + request->b; + } + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + g_node = rclcpp::Node::make_shared("minimal_service"); + auto server = g_node->create_service("add_two_ints", handle_service); + rclcpp::spin(g_node); + rclcpp::shutdown(); + g_node = nullptr; + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The first ``#include`` statements are your package dependencies. + +The ``handle_service`` function adds two integers from the request and gives the sum to the response, while notifying the console of its status using logs. + +.. code-block:: C++ + + void handle_service( + const std::shared_ptr request_header, + const std::shared_ptr request, + const std::shared_ptr response) + { + (void)request_header; + RCLCPP_INFO( + g_node->get_logger(), + "request: %" PRId64 " + %" PRId64, request->a, request->b); + response->sum = request->a + request->b; + } + +The ``main`` function accomplishes the following, line by line: + +* Initializes ROS 2 C++ client library: + + .. code-block:: C++ + + rclcpp::init(argc, argv); + +* Creates a node named ``minimal_service``: + + .. code-block:: C++ + + g_node = rclcpp::Node::make_shared("minimal_service"); + +* Creates a service named ``add_two_ints`` for that node and automatically advertises it over the networks with the ``handle_service`` method: + + .. code-block:: C++ + + auto server = g_node->create_service("add_two_ints", handle_service); + +* Spins the node, making the service available. + + .. code-block:: C++ + + rclcpp::spin(g_node); + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +The ``add_executable`` macro generates an executable you can run using ``ros2 run``. +Add the following code block to ``CMakeLists.txt`` just below the dependencies to create an executable named ``server``: + +.. code-block:: cmake + + add_executable(server src/add_two_ints_server.cpp) + target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) + +So ``ros2 run`` can find the executable, add the following lines to the end of the file, right before ``ament_package()``: + +.. code-block:: cmake + + install(TARGETS + server + DESTINATION lib/${PROJECT_NAME}) + +You could build your package now, source the local setup files, and run it, but let's create the client node first so you can see the full system at work. + +3 Write the client node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_client.cpp`` and paste the following code within: + +.. code-block:: C++ + + #include + #include + #include + + #include "example_interfaces/srv/add_two_ints.hpp" + #include "rclcpp/rclcpp.hpp" + + using AddTwoInts = example_interfaces::srv::AddTwoInts; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + auto node = rclcpp::Node::make_shared("minimal_client"); + auto client = node->create_client("add_two_ints"); + while (!client->wait_for_service(std::chrono::seconds(1))) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); + return 1; + } + RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); + } + auto request = std::make_shared(); + request->a = 41; + request->b = 1; + auto result_future = client->async_send_request(request); + if (rclcpp::spin_until_future_complete(node, result_future) != + rclcpp::FutureReturnCode::SUCCESS) + { + RCLCPP_ERROR(node->get_logger(), "service call failed :("); + client->remove_pending_request(result_future); + return 1; + } + auto result = result_future.get(); + RCLCPP_INFO( + node->get_logger(), "result of %" PRId64 " + %" PRId64 " = %" PRId64, + request->a, request->b, result->sum); + rclcpp::shutdown(); + return 0; + } + + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Similar to the service node, the following lines of code create the node and then create the client for that node: + +.. code-block:: C++ + + auto node = rclcpp::Node::make_shared("minimal_client"); + auto client = node->create_client("add_two_ints"); + +Next, the code waits for the service to appear. +The ``while`` loop gives the client 1 second to search for service nodes in the network. +If it can't find any, it will continue waiting. +If the client is canceled (e.g. by you entering ``Ctrl+C`` into the terminal), it will return an error log message stating it was interrupted. + +.. code-block:: C++ + + while (!client->wait_for_service(std::chrono::seconds(1))) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); + return 1; + } + RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); + } + +Next, the request is created. +Its structure is defined by the ``.srv`` file mentioned earlier. + +.. code-block:: C++ + + auto request = std::make_shared(); + request->a = 41; + request->b = 1; + + +Then the client sends its request, and the node spins until it receives its response, or fails. + +3.2 Add executable +~~~~~~~~~~~~~~~~~~ + +Return to ``CMakeLists.txt`` to add the executable and target for the new node. +After removing some unnecessary boilerplate from the automatically generated file, your ``CMakeLists.txt`` should look like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(cpp_srvcli) + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(example_interfaces REQUIRED) + + add_executable(server src/add_two_ints_server.cpp) + target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) + + add_executable(client src/add_two_ints_client.cpp) + target_link_libraries(client PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) + + install(TARGETS + server + client + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + + +4 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select cpp_srvcli + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select cpp_srvcli + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_srvcli + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the service node: + +.. code-block:: console + + $ ros2 run cpp_srvcli server + +The terminal should wait for incoming requests. + +Open another terminal, source the setup files from inside ``ros2_ws`` again. +Start the client node, followed by any two integers separated by a space. +The client sends the request to the service, which computes the sum and returns the result: + +.. code-block:: console + + $ ros2 run cpp_srvcli client + [INFO] [minimal_client]: result of 41 + 1: 42 + +The client should receive the response above. + +Return to the terminal where your service node is running. +You will see that it published log messages when it received the request and the data it received, and the response it sent back: + +.. code-block:: console + + [INFO] [minimal_service]: request: 41 + 1 + +Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. + +Summary +------- + +You created two nodes to request and respond to data over a service. +You added their dependencies and executables to the package configuration files so that you could build and run them, and see a service/client system at work. + +Next steps +---------- + +In the last few tutorials you've been utilizing interfaces to pass data across topics and services. +Next, you'll learn how to :doc:`create custom interfaces `. + +Related content +--------------- + +* There are several ways you could write a service and client in C++; check out the ``minimal_service`` and ``minimal_client`` packages in the `ros2/examples `_ repo. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst index 10d98f34be5..4b520500c85 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst @@ -1,515 +1,516 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Py-Publisher-And-Subscriber - -.. _PyPubSub: - -Writing a simple publisher and subscriber (Python) -================================================== - -**Goal:** Create and run a publisher and subscriber node using Python. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial, you will create :doc:`nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that pass information in the form of string messages to each other over a :doc:`topic <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. -The example used here is a simple "talker" and "listener" system; -one node publishes data and the other subscribes to the topic so it can receive that data. - -The code used in these examples can be found `here `__. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <./Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <./Creating-Your-First-ROS2-Package>`. - -A basic understanding of Python is recommended, but not entirely necessary. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -So, navigate into ``ros2_ws/src``, and run the package creation command: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_pubsub - -Your terminal will return a message verifying the creation of your package ``py_pubsub`` and all its necessary files and folders. - -2 Write the publisher node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Navigate into ``ros2_ws/src/py_pubsub/py_pubsub``. -Recall that this directory is a `Python package `__ with the same name as the ROS 2 package it's nested in. - -Download the example talker code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py - -Now there will be a new file named ``publisher_member_function.py`` adjacent to ``__init__.py``. - -Open the file using your preferred text editor. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from std_msgs.msg import String - - - class MinimalPublisher(Node): - - def __init__(self): - super().__init__('minimal_publisher') - self.publisher_ = self.create_publisher(String, 'topic', 10) - timer_period = 0.5 # seconds - self.timer = self.create_timer(timer_period, self.timer_callback) - self.i = 0 - - def timer_callback(self): - msg = String() - msg.data = 'Hello World: %d' % self.i - self.publisher_.publish(msg) - self.get_logger().info('Publishing: "%s"' % msg.data) - self.i += 1 - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_publisher = MinimalPublisher() - - rclpy.spin(minimal_publisher) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The first lines of code after the comments import {package(rclpy)} so its `Node <{package_link(rclpy)}api/node.html>`__ class can be used. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The next statement imports the built-in {interface(std_msgs/msg/String)} message type that the node uses to structure the data that it passes on the topic. - -.. code-block:: python - - from std_msgs.msg import String - -These lines represent the node's dependencies. -Recall that dependencies have to be added to ``package.xml``, which you'll do in the next section. - -Next, the ``MinimalPublisher`` class is created, which inherits from (or is a subclass of) `Node <{package_link(rclpy)}api/node.html>`__. - -.. code-block:: python - - class MinimalPublisher(Node): - -Following is the definition of the class's constructor. -``super().__init__`` calls the `Node <{package_link(rclpy)}api/node.html>`__ class's constructor and gives it your node name, in this case ``minimal_publisher``. - -`create_publisher <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_publisher>`__ declares that the node publishes messages of type {interface(std_msgs/msg/String)} (imported from the ``std_msgs.msg`` module), over a topic named ``topic``, and that the "queue size" is 10. -Queue size is a required :doc:`Quality of Service ` (QoS) setting that limits the amount of queued messages if a subscriber is not receiving them fast enough. - -Next, `create_timer <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_timer>`__ is used to create a callback that executes every 0.5 seconds. -``self.i`` is a counter used in the callback. - -.. code-block:: python - - def __init__(self): - super().__init__('minimal_publisher') - self.publisher_ = self.create_publisher(String, 'topic', 10) - timer_period = 0.5 # seconds - self.timer = self.create_timer(timer_period, self.timer_callback) - self.i = 0 - -``timer_callback`` creates a message with the counter value appended, publishes it, and prints it to the console with `get_logger() <{package_link(rclpy)}api/node.html#rclpy.node.Node.get_logger>`__'s `info() <{package_link(rclpy)}rclpy.impl.rcutils_logger.html#rclpy.impl.rcutils_logger.RcutilsLogger.info>`__ function. - -.. code-block:: python - - def timer_callback(self): - msg = String() - msg.data = 'Hello World: %d' % self.i - self.publisher_.publish(msg) - self.get_logger().info('Publishing: "%s"' % msg.data) - self.i += 1 - -Lastly, the main function is defined. - -.. code-block:: python - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_publisher = MinimalPublisher() - - rclpy.spin(minimal_publisher) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - -First the {package(rclpy)} library is initialized, then the node is created, and then it "spins" the node (using `spin() <{package_link(rclpy)}api/init_shutdown.html#rclpy.spin>`__) so its callbacks are called. - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``ros2_ws/src/py_pubsub`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`previous tutorial <./Creating-Your-First-ROS2-Package>`, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Examples of minimal publisher/subscriber using rclpy - Your Name - Apache-2.0 - -After the lines above, add the following dependencies corresponding to your node's import statements: - -.. code-block:: xml - - rclpy - std_msgs - -This declares the package needs {package(rclpy)} and {package(std_msgs)} when its code is executed. - -Make sure to save the file. - -2.3 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file. -Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: - -.. code-block:: python - - maintainer='YourName', - maintainer_email='you@email.com', - description='Examples of minimal publisher/subscriber using rclpy', - license='Apache-2.0', - -Add the following line within the ``console_scripts`` brackets of the `entry_points `__ field: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'talker = py_pubsub.publisher_member_function:main', - ], - }, - -Don't forget to save. - -2.4 Check setup.cfg -~~~~~~~~~~~~~~~~~~~ - -The contents of the ``setup.cfg`` file should be correctly populated automatically, like so: - -.. code-block:: ini - - [develop] - script_dir=$base/lib/py_pubsub - [install] - install_scripts=$base/lib/py_pubsub - -This is simply telling `setuptools `__ to put your executables in ``lib``, because ``ros2 run`` will look for them there. - -You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. - -3 Write the subscriber node -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Return to ``ros2_ws/src/py_pubsub/py_pubsub`` to create the next node. -Enter the following code in your terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py - -Now the directory should have these files: - -.. code-block:: console - - __init__.py publisher_member_function.py subscriber_member_function.py - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Open the ``subscriber_member_function.py`` with your text editor. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from std_msgs.msg import String - - - class MinimalSubscriber(Node): - - def __init__(self): - super().__init__('minimal_subscriber') - self.subscription = self.create_subscription( - String, - 'topic', - self.listener_callback, - 10) - self.subscription # prevent unused variable warning - - def listener_callback(self, msg): - self.get_logger().info('I heard: "%s"' % msg.data) - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_subscriber = MinimalSubscriber() - - rclpy.spin(minimal_subscriber) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -The subscriber node's code is nearly identical to the publisher's. -The constructor creates a subscriber with the same arguments as the publisher using `create_subscription <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_subscription>`__. -Recall from the :doc:`topics tutorial <../Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. - -.. code-block:: python - - self.subscription = self.create_subscription( - String, - 'topic', - self.listener_callback, - 10) - -The subscriber's constructor and callback don't include any timer definition, because it doesn't need one. -Its callback gets called as soon as it receives a message. - -The callback definition simply prints an info message to the console, along with the data it received. -Recall that the publisher defines ``msg.data = 'Hello World: %d' % self.i`` - -.. code-block:: python - - def listener_callback(self, msg): - self.get_logger().info('I heard: "%s"' % msg.data) - -The ``main`` definition is almost exactly the same, replacing the creation and spinning of the publisher with the subscriber. - -.. code-block:: python - - minimal_subscriber = MinimalSubscriber() - - rclpy.spin(minimal_subscriber) - -Since this node has the same dependencies as the publisher, there's nothing new to add to ``package.xml``. -The ``setup.cfg`` file can also remain untouched. - - -3.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Reopen ``setup.py`` and add the entry point for the subscriber node below the publisher's entry point. -The `entry_points `__ field should now look like this: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'talker = py_pubsub.publisher_member_function:main', - 'listener = py_pubsub.subscriber_member_function:main', - ], - }, - -Make sure to save the file, and then your pub/sub system should be ready. - -4 Build and run -^^^^^^^^^^^^^^^ -You likely already have the {package(rclpy)} and {package(std_msgs)} packages installed as part of your ROS 2 system. -It's good practice to run `rosdep `__ (check the :doc:`rosdep tutorial `) in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Still in the root of your workspace, ``ros2_ws``, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select py_pubsub - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select py_pubsub - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select py_pubsub - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the talker node. -The terminal should start publishing info messages every 0.5 seconds, like so: - -.. code-block:: console - - $ ros2 run py_pubsub talker - [info] [minimal_publisher]: publishing: "hello world: 0" - [info] [minimal_publisher]: publishing: "hello world: 1" - [info] [minimal_publisher]: publishing: "hello world: 2" - [info] [minimal_publisher]: publishing: "hello world: 3" - [info] [minimal_publisher]: publishing: "hello world: 4" - ... - -Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. -The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: - -.. code-block:: console - - $ ros2 run py_pubsub listener - [INFO] [minimal_subscriber]: I heard: "Hello World: 10" - [INFO] [minimal_subscriber]: I heard: "Hello World: 11" - [INFO] [minimal_subscriber]: I heard: "Hello World: 12" - [INFO] [minimal_subscriber]: I heard: "Hello World: 13" - [INFO] [minimal_subscriber]: I heard: "Hello World: 14" - -Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. - -Summary -------- - -You created two nodes to publish and subscribe to data over a topic. -Before running them, you added their dependencies and entry points to the package configuration files. - -Next steps ----------- - -Next you'll create another simple ROS 2 package using the service/client model. -Again, you can choose to write it in either :doc:`C++ <./Writing-A-Simple-Cpp-Service-And-Client>` or :doc:`Python <./Writing-A-Simple-Py-Service-And-Client>`. - -Related content ---------------- - -There are several ways you could write a publisher and subscriber in Python; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. +.. redirect-from:: + + Tutorials/Writing-A-Simple-Py-Publisher-And-Subscriber + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber + +.. _PyPubSub: + +Writing a simple publisher and subscriber (Python) +================================================== + +**Goal:** Create and run a publisher and subscriber node using Python. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial, you will create :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that pass information in the form of string messages to each other over a :doc:`topic <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. +The example used here is a simple "talker" and "listener" system; +one node publishes data and the other subscribes to the topic so it can receive that data. + +The code used in these examples can be found `here `__. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +A basic understanding of Python is recommended, but not entirely necessary. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +So, navigate into ``ros2_ws/src``, and run the package creation command: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_pubsub + +Your terminal will return a message verifying the creation of your package ``py_pubsub`` and all its necessary files and folders. + +2 Write the publisher node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate into ``ros2_ws/src/py_pubsub/py_pubsub``. +Recall that this directory is a `Python package `__ with the same name as the ROS 2 package it's nested in. + +Download the example talker code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py + +Now there will be a new file named ``publisher_member_function.py`` adjacent to ``__init__.py``. + +Open the file using your preferred text editor. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from std_msgs.msg import String + + + class MinimalPublisher(Node): + + def __init__(self): + super().__init__('minimal_publisher') + self.publisher_ = self.create_publisher(String, 'topic', 10) + timer_period = 0.5 # seconds + self.timer = self.create_timer(timer_period, self.timer_callback) + self.i = 0 + + def timer_callback(self): + msg = String() + msg.data = 'Hello World: %d' % self.i + self.publisher_.publish(msg) + self.get_logger().info('Publishing: "%s"' % msg.data) + self.i += 1 + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_publisher = MinimalPublisher() + + rclpy.spin(minimal_publisher) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The first lines of code after the comments import {package(rclpy)} so its `Node <{package_link(rclpy)}api/node.html>`__ class can be used. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The next statement imports the built-in {interface(std_msgs/msg/String)} message type that the node uses to structure the data that it passes on the topic. + +.. code-block:: python + + from std_msgs.msg import String + +These lines represent the node's dependencies. +Recall that dependencies have to be added to ``package.xml``, which you'll do in the next section. + +Next, the ``MinimalPublisher`` class is created, which inherits from (or is a subclass of) `Node <{package_link(rclpy)}api/node.html>`__. + +.. code-block:: python + + class MinimalPublisher(Node): + +Following is the definition of the class's constructor. +``super().__init__`` calls the `Node <{package_link(rclpy)}api/node.html>`__ class's constructor and gives it your node name, in this case ``minimal_publisher``. + +`create_publisher <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_publisher>`__ declares that the node publishes messages of type {interface(std_msgs/msg/String)} (imported from the ``std_msgs.msg`` module), over a topic named ``topic``, and that the "queue size" is 10. +Queue size is a required :doc:`Quality of Service <../../topics/About-Quality-of-Service-Settings>` (QoS) setting that limits the amount of queued messages if a subscriber is not receiving them fast enough. + +Next, `create_timer <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_timer>`__ is used to create a callback that executes every 0.5 seconds. +``self.i`` is a counter used in the callback. + +.. code-block:: python + + def __init__(self): + super().__init__('minimal_publisher') + self.publisher_ = self.create_publisher(String, 'topic', 10) + timer_period = 0.5 # seconds + self.timer = self.create_timer(timer_period, self.timer_callback) + self.i = 0 + +``timer_callback`` creates a message with the counter value appended, publishes it, and prints it to the console with `get_logger() <{package_link(rclpy)}api/node.html#rclpy.node.Node.get_logger>`__'s `info() <{package_link(rclpy)}rclpy.impl.rcutils_logger.html#rclpy.impl.rcutils_logger.RcutilsLogger.info>`__ function. + +.. code-block:: python + + def timer_callback(self): + msg = String() + msg.data = 'Hello World: %d' % self.i + self.publisher_.publish(msg) + self.get_logger().info('Publishing: "%s"' % msg.data) + self.i += 1 + +Lastly, the main function is defined. + +.. code-block:: python + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_publisher = MinimalPublisher() + + rclpy.spin(minimal_publisher) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + +First the {package(rclpy)} library is initialized, then the node is created, and then it "spins" the node (using `spin() <{package_link(rclpy)}api/init_shutdown.html#rclpy.spin>`__) so its callbacks are called. + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``ros2_ws/src/py_pubsub`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`previous tutorial `, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Examples of minimal publisher/subscriber using rclpy + Your Name + Apache-2.0 + +After the lines above, add the following dependencies corresponding to your node's import statements: + +.. code-block:: xml + + rclpy + std_msgs + +This declares the package needs {package(rclpy)} and {package(std_msgs)} when its code is executed. + +Make sure to save the file. + +2.3 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file. +Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: + +.. code-block:: python + + maintainer='YourName', + maintainer_email='you@email.com', + description='Examples of minimal publisher/subscriber using rclpy', + license='Apache-2.0', + +Add the following line within the ``console_scripts`` brackets of the `entry_points `__ field: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'talker = py_pubsub.publisher_member_function:main', + ], + }, + +Don't forget to save. + +2.4 Check setup.cfg +~~~~~~~~~~~~~~~~~~~ + +The contents of the ``setup.cfg`` file should be correctly populated automatically, like so: + +.. code-block:: ini + + [develop] + script_dir=$base/lib/py_pubsub + [install] + install_scripts=$base/lib/py_pubsub + +This is simply telling `setuptools `__ to put your executables in ``lib``, because ``ros2 run`` will look for them there. + +You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. + +3 Write the subscriber node +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Return to ``ros2_ws/src/py_pubsub/py_pubsub`` to create the next node. +Enter the following code in your terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py + +Now the directory should have these files: + +.. code-block:: console + + __init__.py publisher_member_function.py subscriber_member_function.py + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Open the ``subscriber_member_function.py`` with your text editor. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from std_msgs.msg import String + + + class MinimalSubscriber(Node): + + def __init__(self): + super().__init__('minimal_subscriber') + self.subscription = self.create_subscription( + String, + 'topic', + self.listener_callback, + 10) + self.subscription # prevent unused variable warning + + def listener_callback(self, msg): + self.get_logger().info('I heard: "%s"' % msg.data) + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_subscriber = MinimalSubscriber() + + rclpy.spin(minimal_subscriber) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +The subscriber node's code is nearly identical to the publisher's. +The constructor creates a subscriber with the same arguments as the publisher using `create_subscription <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_subscription>`__. +Recall from the :doc:`topics tutorial <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. + +.. code-block:: python + + self.subscription = self.create_subscription( + String, + 'topic', + self.listener_callback, + 10) + +The subscriber's constructor and callback don't include any timer definition, because it doesn't need one. +Its callback gets called as soon as it receives a message. + +The callback definition simply prints an info message to the console, along with the data it received. +Recall that the publisher defines ``msg.data = 'Hello World: %d' % self.i`` + +.. code-block:: python + + def listener_callback(self, msg): + self.get_logger().info('I heard: "%s"' % msg.data) + +The ``main`` definition is almost exactly the same, replacing the creation and spinning of the publisher with the subscriber. + +.. code-block:: python + + minimal_subscriber = MinimalSubscriber() + + rclpy.spin(minimal_subscriber) + +Since this node has the same dependencies as the publisher, there's nothing new to add to ``package.xml``. +The ``setup.cfg`` file can also remain untouched. + + +3.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Reopen ``setup.py`` and add the entry point for the subscriber node below the publisher's entry point. +The `entry_points `__ field should now look like this: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'talker = py_pubsub.publisher_member_function:main', + 'listener = py_pubsub.subscriber_member_function:main', + ], + }, + +Make sure to save the file, and then your pub/sub system should be ready. + +4 Build and run +^^^^^^^^^^^^^^^ +You likely already have the {package(rclpy)} and {package(std_msgs)} packages installed as part of your ROS 2 system. +It's good practice to run `rosdep `__ (check the :doc:`rosdep tutorial `) in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Still in the root of your workspace, ``ros2_ws``, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select py_pubsub + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select py_pubsub + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select py_pubsub + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the talker node. +The terminal should start publishing info messages every 0.5 seconds, like so: + +.. code-block:: console + + $ ros2 run py_pubsub talker + [info] [minimal_publisher]: publishing: "hello world: 0" + [info] [minimal_publisher]: publishing: "hello world: 1" + [info] [minimal_publisher]: publishing: "hello world: 2" + [info] [minimal_publisher]: publishing: "hello world: 3" + [info] [minimal_publisher]: publishing: "hello world: 4" + ... + +Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. +The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: + +.. code-block:: console + + $ ros2 run py_pubsub listener + [INFO] [minimal_subscriber]: I heard: "Hello World: 10" + [INFO] [minimal_subscriber]: I heard: "Hello World: 11" + [INFO] [minimal_subscriber]: I heard: "Hello World: 12" + [INFO] [minimal_subscriber]: I heard: "Hello World: 13" + [INFO] [minimal_subscriber]: I heard: "Hello World: 14" + +Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. + +Summary +------- + +You created two nodes to publish and subscribe to data over a topic. +Before running them, you added their dependencies and entry points to the package configuration files. + +Next steps +---------- + +Next you'll create another simple ROS 2 package using the service/client model. +Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. + +Related content +--------------- + +There are several ways you could write a publisher and subscriber in Python; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst index b14497f9317..3aef7151fc2 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst @@ -1,394 +1,395 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Py-Service-And-Client - -.. _PySrvCli: - -Writing a simple service and client (Python) -============================================ - -**Goal:** Create and run service and client nodes using Python. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When :doc:`nodes <../Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. -The structure of the request and response is determined by a ``.srv`` file. - -The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <./Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <./Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -Navigate into ``ros2_ws/src`` and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_srvcli --dependencies rclpy example_interfaces - -Your terminal will return a message verifying the creation of your package ``py_srvcli`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. -``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: - -.. code-block:: bash - - int64 a - int64 b - --- - int64 sum - -The first two lines are the parameters of the request, and below the dashes is the response. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. - -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - Python client server tutorial - Your Name - Apache-2.0 - -1.2 Update ``setup.py`` -~~~~~~~~~~~~~~~~~~~~~~~ - -Add the same information to the ``setup.py`` file for the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields: - -.. code-block:: python - - maintainer='Your Name', - maintainer_email='you@email.com', - description='Python client server tutorial', - license='Apache-2.0', - -2 Write the service node -^^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``service_member_function.py`` and paste the following code within: - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalService(Node): - - def __init__(self): - super().__init__('minimal_service') - self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) - - def add_two_ints_callback(self, request, response): - response.sum = request.a + request.b - self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) - - return response - - - def main(): - try: - with rclpy.init(): - minimal_service = MinimalService() - - rclpy.spin(minimal_service) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The first ``import`` statement imports the ``AddTwoInts`` service type from the ``example_interfaces`` package. -The following ``import`` statements import the necessary ROS 2 Python client library interfaces. - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The ``MinimalService`` class constructor initializes the node with the name ``minimal_service``. -Then, it creates a service and defines the type, name, and callback. - -.. code-block:: python - - def __init__(self): - super().__init__('minimal_service') - self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) - -The definition of the service callback receives the request data, sums it, and returns the sum as a response. - -.. code-block:: python - - def add_two_ints_callback(self, request, response): - response.sum = request.a + request.b - self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) - - return response - -Finally, the main class initializes the ROS 2 Python client library, instantiates the ``MinimalService`` class to create the service node and spins the node to handle callbacks. - -2.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``ros2_ws/src/py_srvcli`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'service = py_srvcli.service_member_function:main', - -3 Write the client node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``client_member_function.py`` and paste the following code within: - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalClientAsync(Node): - - def __init__(self): - super().__init__('minimal_client_async') - self.cli = self.create_client(AddTwoInts, 'add_two_ints') - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddTwoInts.Request() - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - return self.cli.call_async(self.req) - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_client = MinimalClientAsync() - future = minimal_client.send_request() - rclpy.spin_until_future_complete(minimal_client, future) - response = future.result() - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -As with the service code, we first ``import`` the necessary libraries. - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The ``MinimalClientAsync`` class constructor initializes the node with the name ``minimal_client_async``. -The constructor definition creates a client with the same type and name as the service node. -The type and name must match for the client and service to be able to communicate. -The ``while`` loop in the constructor checks if a service matching the type and name of the client is available once a second. -Finally it creates a new ``AddTwoInts`` request object. - -.. code-block:: python - - def __init__(self): - super().__init__('minimal_client_async') - self.cli = self.create_client(AddTwoInts, 'add_two_ints') - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddTwoInts.Request() - -Below the constructor is the ``send_request`` method, which will send the request and spin until it receives the response or fails. - -.. code-block:: python - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - return self.cli.call_async(self.req) - -Finally we have the ``main`` method, which constructs a ``MinimalClientAsync`` object, sends the request using the passed-in command-line arguments, calls ``rclpy.spin_until_future_complete`` to wait for the result, and logs the results. - -.. code-block:: python - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_client = MinimalClientAsync() - future = minimal_client.send_request() - rclpy.spin_until_future_complete(minimal_client, future) - response = future.result() - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -.. warning:: - - Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. - For more details see the :doc:`sync deadlock article <../../../How-To-Guides/Sync-Vs-Async>`. - -3.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Like the service node, you also have to add an entry point to be able to run the client node. - -The ``entry_points`` field of your ``setup.py`` file should look like this: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'service = py_srvcli.service_member_function:main', - 'client = py_srvcli.client_member_function:main', - ], - }, - -4 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. code-block:: console - - $ colcon build --packages-select py_srvcli - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the service node: - -.. code-block:: console - - $ ros2 run py_srvcli service - -The node will wait for the client's request. - -Open another terminal and source the setup files from inside ``ros2_ws`` again. -Start the client node. -The client sends the request to the service, which computes the sum and returns the result: - -.. code-block:: console - - $ ros2 run py_srvcli client - [INFO] [minimal_client_async]: Result of add_two_ints: for 41 + 1 = 42 - -Return to the terminal where your service node is running. -You will see that it published log messages when it received the request: - -.. code-block:: console - - [INFO] [minimal_service]: Incoming request - a: 41 b: 1 - -Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. - - -Summary -------- - -You created two nodes to request and respond to data over a service. -You added their dependencies and executables to the package configuration files so that you could build and run them, allowing you to see a service/client system at work. - -Next steps ----------- - -In the last few tutorials you've been utilizing interfaces to pass data across topics and services. -Next, you'll learn how to :doc:`create custom interfaces <./Custom-ROS2-Interfaces>`. - -Related content ---------------- - -* There are several ways you could write a service and client in Python; check out the ``minimal_client`` and ``minimal_service`` packages in the `ros2/examples `_ repo. - -* In this tutorial, you used the ``call_async()`` API in your client node to call the service. - There is another service call API available for Python called synchronous calls. - We do not recommend using synchronous calls, but if you'd like to learn more about them, read the guide to :doc:`Synchronous vs. asynchronous clients <../../How-To-Guides/Sync-Vs-Async>`. +.. redirect-from:: + + Tutorials/Writing-A-Simple-Py-Service-And-Client + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client + +.. _PySrvCli: + +Writing a simple service and client (Python) +============================================ + +**Goal:** Create and run service and client nodes using Python. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. +The structure of the request and response is determined by a ``.srv`` file. + +The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +Navigate into ``ros2_ws/src`` and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_srvcli --dependencies rclpy example_interfaces + +Your terminal will return a message verifying the creation of your package ``py_srvcli`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. +``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: + +.. code-block:: bash + + int64 a + int64 b + --- + int64 sum + +The first two lines are the parameters of the request, and below the dashes is the response. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. + +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + Python client server tutorial + Your Name + Apache-2.0 + +1.2 Update ``setup.py`` +~~~~~~~~~~~~~~~~~~~~~~~ + +Add the same information to the ``setup.py`` file for the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields: + +.. code-block:: python + + maintainer='Your Name', + maintainer_email='you@email.com', + description='Python client server tutorial', + license='Apache-2.0', + +2 Write the service node +^^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``service_member_function.py`` and paste the following code within: + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalService(Node): + + def __init__(self): + super().__init__('minimal_service') + self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) + + def add_two_ints_callback(self, request, response): + response.sum = request.a + request.b + self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) + + return response + + + def main(): + try: + with rclpy.init(): + minimal_service = MinimalService() + + rclpy.spin(minimal_service) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The first ``import`` statement imports the ``AddTwoInts`` service type from the ``example_interfaces`` package. +The following ``import`` statements import the necessary ROS 2 Python client library interfaces. + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The ``MinimalService`` class constructor initializes the node with the name ``minimal_service``. +Then, it creates a service and defines the type, name, and callback. + +.. code-block:: python + + def __init__(self): + super().__init__('minimal_service') + self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) + +The definition of the service callback receives the request data, sums it, and returns the sum as a response. + +.. code-block:: python + + def add_two_ints_callback(self, request, response): + response.sum = request.a + request.b + self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) + + return response + +Finally, the main class initializes the ROS 2 Python client library, instantiates the ``MinimalService`` class to create the service node and spins the node to handle callbacks. + +2.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``ros2_ws/src/py_srvcli`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'service = py_srvcli.service_member_function:main', + +3 Write the client node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``client_member_function.py`` and paste the following code within: + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalClientAsync(Node): + + def __init__(self): + super().__init__('minimal_client_async') + self.cli = self.create_client(AddTwoInts, 'add_two_ints') + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddTwoInts.Request() + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + return self.cli.call_async(self.req) + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_client = MinimalClientAsync() + future = minimal_client.send_request() + rclpy.spin_until_future_complete(minimal_client, future) + response = future.result() + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +As with the service code, we first ``import`` the necessary libraries. + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The ``MinimalClientAsync`` class constructor initializes the node with the name ``minimal_client_async``. +The constructor definition creates a client with the same type and name as the service node. +The type and name must match for the client and service to be able to communicate. +The ``while`` loop in the constructor checks if a service matching the type and name of the client is available once a second. +Finally it creates a new ``AddTwoInts`` request object. + +.. code-block:: python + + def __init__(self): + super().__init__('minimal_client_async') + self.cli = self.create_client(AddTwoInts, 'add_two_ints') + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddTwoInts.Request() + +Below the constructor is the ``send_request`` method, which will send the request and spin until it receives the response or fails. + +.. code-block:: python + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + return self.cli.call_async(self.req) + +Finally we have the ``main`` method, which constructs a ``MinimalClientAsync`` object, sends the request using the passed-in command-line arguments, calls ``rclpy.spin_until_future_complete`` to wait for the result, and logs the results. + +.. code-block:: python + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_client = MinimalClientAsync() + future = minimal_client.send_request() + rclpy.spin_until_future_complete(minimal_client, future) + response = future.result() + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +.. warning:: + + Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. + For more details see the :doc:`sync deadlock article <../../../How-To-Guides/Sync-Vs-Async>`. + +3.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Like the service node, you also have to add an entry point to be able to run the client node. + +The ``entry_points`` field of your ``setup.py`` file should look like this: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'service = py_srvcli.service_member_function:main', + 'client = py_srvcli.client_member_function:main', + ], + }, + +4 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. code-block:: console + + $ colcon build --packages-select py_srvcli + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the service node: + +.. code-block:: console + + $ ros2 run py_srvcli service + +The node will wait for the client's request. + +Open another terminal and source the setup files from inside ``ros2_ws`` again. +Start the client node. +The client sends the request to the service, which computes the sum and returns the result: + +.. code-block:: console + + $ ros2 run py_srvcli client + [INFO] [minimal_client_async]: Result of add_two_ints: for 41 + 1 = 42 + +Return to the terminal where your service node is running. +You will see that it published log messages when it received the request: + +.. code-block:: console + + [INFO] [minimal_service]: Incoming request + a: 41 b: 1 + +Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. + + +Summary +------- + +You created two nodes to request and respond to data over a service. +You added their dependencies and executables to the package configuration files so that you could build and run them, allowing you to see a service/client system at work. + +Next steps +---------- + +In the last few tutorials you've been utilizing interfaces to pass data across topics and services. +Next, you'll learn how to :doc:`create custom interfaces `. + +Related content +--------------- + +* There are several ways you could write a service and client in Python; check out the ``minimal_client`` and ``minimal_service`` packages in the `ros2/examples `_ repo. + +* In this tutorial, you used the ``call_async()`` API in your client node to call the service. + There is another service call API available for Python called synchronous calls. + We do not recommend using synchronous calls, but if you'd like to learn more about them, read the guide to :doc:`Synchronous vs. asynchronous clients <../../services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst index 0ec3997b533..a8b98553b34 100644 --- a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst +++ b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst @@ -1,160 +1,161 @@ -.. redirect-from:: - - Concepts/About-Tf2 - -Tf2 -=== - -.. contents:: Table of Contents - :local: - -Overview --------- - -tf2 is the transform library, which lets the user keep track of multiple coordinate frames over time. -tf2 maintains the relationship between coordinate frames in a tree structure buffered in time and lets the user transform points, vectors, etc. between any two coordinate frames at any desired point in time. - -.. image:: ../images/ros2_tf2_frames.png - -Properties of tf2 ------------------ - -A robotic system typically has many 3D coordinate frames that change over time, such as a world frame, base frame, gripper frame, head frame, etc. -tf2 keeps track of all these frames over time, and allows you to ask questions like: - -* Where was the head frame relative to the world frame 5 seconds ago? -* What is the pose of the object in my gripper relative to my base? -* What is the current pose of the base frame in the map frame? - -tf2 can operate in a distributed system. -This means all the information about the coordinate frames of a robot is available to all ROS 2 components on any computer in the system. -tf2 can have every component in your distributed system build its own transform information database or have a central node that gathers and stores all transform information. - -.. mermaid:: - - flowchart LR - E((Earth)) - E --> A[[Car A]] - E --> B[[Car B]] - E --> C{{Satellite C}} - E --> D((Moon D)) - -Publishing transforms -^^^^^^^^^^^^^^^^^^^^^ - -When publishing transforms we typically think of the transforms as the transform from one frame to the other. -The semantic difference is whether you are transforming data represented in a frame or transforming the frame itself. -These values are directly inverse. -Transforms published in the ``geometry_msgs/msg/Transform`` message represent the frame formulation. -Keep this in mind when debugging published transforms they are the inverse of what you will lookup depending on what direction you're traversing the transform tree. - -.. math:: - - - _{B}T^{data}_{A} = (_{B}T^{frame}_{A})^{-1} - -The TF library handles inverting these elements for you depending on which way you're traversing the transform tree. -For the rest of this document we will just use :math:`T^{data}` but the ``data`` is unwritten. - -Position -^^^^^^^^ - -If the driver in car :math:`A` observes something and a person on the ground wants to know where it is relative to it's position, you transform the observation from the source frame to the target frame. - -.. math:: - - _{E}T_{A} * P_{A}^{Obs} = P_{E}^{Obs} - - -Now if a person in car B wants to know where it is too you can compute the net transform. - - -.. math:: - - _{B}T_{E} * _{E}T_{A} * P_{A}^{Obs} = _{B}T_{A} * P_{A}^{Obs} = P_{B}^{Obs} - - -This is exactly what ``lookupTransform`` provides where ``A`` is the *source* ``frame_id`` and ``B`` is the *target* ``frame_id``. - -It is recommended to use the ``transform(target_frame, ...)`` methods when possible because they will read the *source* ``frame_id`` from the datatype and write out the *target* ``frame_id`` in the resulting datatype and the math will be taken care of internally. - -If :math:`P` is a ``Stamped`` datatype then :math:`_A` is it's ``frame_id``. - -As an example, if a root frame ``A`` is one meter below frame ``B`` the transform from ``A`` to ``B`` is positive. - -However when converting data from coordinate frame ``B`` to coordinate frame ``A`` you have to use the inverse of this value. -This can be seen as you'll be adding value to the height when you change to the lower reference frame. -However if you are transforming data from coordinate frame ``A`` into coordinate frame ``B`` the height is reduced because the new reference is higher. - -.. math:: - - - _{B}T_{A} = (_{B}{Tf}_{A})^{-1} - - -Velocity -^^^^^^^^ - -For representing ``Velocity`` we have three pieces of information. -:math:`V^{moving\_frame - reference\_frame}_{observing\_frame}` -This velocity represents the velocity between the moving frame and the reference frame. -And it is represented in the observing frame. - -For example a driver in Car A can report that they're driving forward (observed in A) at 1m/s (relative to earth) so that would be :math:`V_{A}^{A - E} = (1,0,0)` -Whereas that same velocity could be observed from the view point of the earth (lets assume the car is driving east and Earth is NED), it would be :math:`V_{E}^{A - E} = (0, 1, 0)` - -However transforms can show that these are actually the same with: - -.. math:: - - _{E}T_{A} * V_{A}^{A - E} = V_{E}^{A - E} - - -Velocities can be added or subtracted if they're represented in the same frame, in this case ``Obs``. - -.. math:: - - V_{Obs}^{A - C} = V_{Obs}^{A - B} + V_{Obs}^{D - C} - -Velocities can be "reversed" by inverting. - -.. math:: - - V_{Obs}^{A - C} = -(V_{Obs}^{C - A}) - -If you want to compare two velocities you must first transform them into the same observational frame first. - - -Tutorials ---------- - -We created a set of :doc:`tutorials <../../Tutorials/Intermediate/Tf2/Tf2-Main>` that walks you through using tf2, step by step. -You can get started on the :doc:`introduction to tf2 <../../Tutorials/Intermediate/Tf2/Introduction-To-Tf2>` tutorial. -For a complete list of all tf2 and tf2-related tutorials check out the :doc:`tutorials <../../Tutorials/Intermediate/Tf2/Tf2-Main>` page. - -There are essentially two main tasks that any user would use tf2 for, listening for transforms and broadcasting transforms. - -If you want to use tf2 to transform between coordinate frames, your nodes will need to listen for transforms. -What you will do is receive and buffer all coordinate frames that are broadcasted in the system, and query for specific transforms between frames. -Check out the "Writing a listener" tutorial :doc:`(Python) <../../Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Py>` :doc:`(C++) <../../Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Cpp>` to learn more. - -To extend the capabilities of a robot, you will need to start broadcasting transforms. -Broadcasting transforms means to send out the relative pose of coordinate frames to the rest of the system. -A system can have many broadcasters that each provide information about a different part of the robot. -Check out the "Writing a broadcaster" tutorial :doc:`(Python) <../../Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Py>` :doc:`(C++) <../../Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Cpp>` to learn more. - -In addition to that, tf2 can broadcast static transforms that do not change over time. -This mainly saves storage and lookup time, but also reduces the publishing overhead. -You should note that static transforms are published once and assumed to not change, so no history is stored. -If you want to define static transforms in your tf2 tree, take a look at the "Writing a static broadcaster" :doc:`(Python) <../../Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Py>` :doc:`(C++) <../../Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp>` tutorial. - -You can also learn how to add fixed and dynamic frames to your tf2 tree in the "Adding a frame" :doc:`(Python) <../../Tutorials/Intermediate/Tf2/Adding-A-Frame-Py>` :doc:`(C++) <../../Tutorials/Intermediate/Tf2/Adding-A-Frame-Cpp>` tutorial. - -Once you are finished with the basic tutorials, you can move on to learn about tf2 and time. -The tf2 and time tutorial :doc:`(C++) <../../Tutorials/Intermediate/Tf2/Learning-About-Tf2-And-Time-Cpp>` teaches the basic principles of tf2 and time. -The advanced tutorial about tf2 and time :doc:`(C++) <../../Tutorials/Intermediate/Tf2/Time-Travel-With-Tf2-Cpp>` teaches the principles of time traveling with tf2. - -Paper ------ - -There is a paper on tf2 presented at TePRA 2013: `tf: The transform library `_. +.. redirect-from:: + + Concepts/About-Tf2 + Concepts/Intermediate/About-Tf2 + +Tf2 +=== + +.. contents:: Table of Contents + :local: + +Overview +-------- + +tf2 is the transform library, which lets the user keep track of multiple coordinate frames over time. +tf2 maintains the relationship between coordinate frames in a tree structure buffered in time and lets the user transform points, vectors, etc. between any two coordinate frames at any desired point in time. + +.. image:: ../images/ros2_tf2_frames.png + +Properties of tf2 +----------------- + +A robotic system typically has many 3D coordinate frames that change over time, such as a world frame, base frame, gripper frame, head frame, etc. +tf2 keeps track of all these frames over time, and allows you to ask questions like: + +* Where was the head frame relative to the world frame 5 seconds ago? +* What is the pose of the object in my gripper relative to my base? +* What is the current pose of the base frame in the map frame? + +tf2 can operate in a distributed system. +This means all the information about the coordinate frames of a robot is available to all ROS 2 components on any computer in the system. +tf2 can have every component in your distributed system build its own transform information database or have a central node that gathers and stores all transform information. + +.. mermaid:: + + flowchart LR + E((Earth)) + E --> A[[Car A]] + E --> B[[Car B]] + E --> C{{Satellite C}} + E --> D((Moon D)) + +Publishing transforms +^^^^^^^^^^^^^^^^^^^^^ + +When publishing transforms we typically think of the transforms as the transform from one frame to the other. +The semantic difference is whether you are transforming data represented in a frame or transforming the frame itself. +These values are directly inverse. +Transforms published in the ``geometry_msgs/msg/Transform`` message represent the frame formulation. +Keep this in mind when debugging published transforms they are the inverse of what you will lookup depending on what direction you're traversing the transform tree. + +.. math:: + + + _{B}T^{data}_{A} = (_{B}T^{frame}_{A})^{-1} + +The TF library handles inverting these elements for you depending on which way you're traversing the transform tree. +For the rest of this document we will just use :math:`T^{data}` but the ``data`` is unwritten. + +Position +^^^^^^^^ + +If the driver in car :math:`A` observes something and a person on the ground wants to know where it is relative to it's position, you transform the observation from the source frame to the target frame. + +.. math:: + + _{E}T_{A} * P_{A}^{Obs} = P_{E}^{Obs} + + +Now if a person in car B wants to know where it is too you can compute the net transform. + + +.. math:: + + _{B}T_{E} * _{E}T_{A} * P_{A}^{Obs} = _{B}T_{A} * P_{A}^{Obs} = P_{B}^{Obs} + + +This is exactly what ``lookupTransform`` provides where ``A`` is the *source* ``frame_id`` and ``B`` is the *target* ``frame_id``. + +It is recommended to use the ``transform(target_frame, ...)`` methods when possible because they will read the *source* ``frame_id`` from the datatype and write out the *target* ``frame_id`` in the resulting datatype and the math will be taken care of internally. + +If :math:`P` is a ``Stamped`` datatype then :math:`_A` is it's ``frame_id``. + +As an example, if a root frame ``A`` is one meter below frame ``B`` the transform from ``A`` to ``B`` is positive. + +However when converting data from coordinate frame ``B`` to coordinate frame ``A`` you have to use the inverse of this value. +This can be seen as you'll be adding value to the height when you change to the lower reference frame. +However if you are transforming data from coordinate frame ``A`` into coordinate frame ``B`` the height is reduced because the new reference is higher. + +.. math:: + + + _{B}T_{A} = (_{B}{Tf}_{A})^{-1} + + +Velocity +^^^^^^^^ + +For representing ``Velocity`` we have three pieces of information. +:math:`V^{moving\_frame - reference\_frame}_{observing\_frame}` +This velocity represents the velocity between the moving frame and the reference frame. +And it is represented in the observing frame. + +For example a driver in Car A can report that they're driving forward (observed in A) at 1m/s (relative to earth) so that would be :math:`V_{A}^{A - E} = (1,0,0)` +Whereas that same velocity could be observed from the view point of the earth (lets assume the car is driving east and Earth is NED), it would be :math:`V_{E}^{A - E} = (0, 1, 0)` + +However transforms can show that these are actually the same with: + +.. math:: + + _{E}T_{A} * V_{A}^{A - E} = V_{E}^{A - E} + + +Velocities can be added or subtracted if they're represented in the same frame, in this case ``Obs``. + +.. math:: + + V_{Obs}^{A - C} = V_{Obs}^{A - B} + V_{Obs}^{D - C} + +Velocities can be "reversed" by inverting. + +.. math:: + + V_{Obs}^{A - C} = -(V_{Obs}^{C - A}) + +If you want to compare two velocities you must first transform them into the same observational frame first. + + +Tutorials +--------- + +We created a set of :doc:`tutorials <../../client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` that walks you through using tf2, step by step. +You can get started on the :doc:`introduction to tf2 <../Working-with-interfaces/Introduction-To-Tf2>` tutorial. +For a complete list of all tf2 and tf2-related tutorials check out the :doc:`tutorials <../../client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` page. + +There are essentially two main tasks that any user would use tf2 for, listening for transforms and broadcasting transforms. + +If you want to use tf2 to transform between coordinate frames, your nodes will need to listen for transforms. +What you will do is receive and buffer all coordinate frames that are broadcasted in the system, and query for specific transforms between frames. +Check out the "Writing a listener" tutorial :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp>` to learn more. + +To extend the capabilities of a robot, you will need to start broadcasting transforms. +Broadcasting transforms means to send out the relative pose of coordinate frames to the rest of the system. +A system can have many broadcasters that each provide information about a different part of the robot. +Check out the "Writing a broadcaster" tutorial :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp>` to learn more. + +In addition to that, tf2 can broadcast static transforms that do not change over time. +This mainly saves storage and lookup time, but also reduces the publishing overhead. +You should note that static transforms are published once and assumed to not change, so no history is stored. +If you want to define static transforms in your tf2 tree, take a look at the "Writing a static broadcaster" :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp>` tutorial. + +You can also learn how to add fixed and dynamic frames to your tf2 tree in the "Adding a frame" :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp>` tutorial. + +Once you are finished with the basic tutorials, you can move on to learn about tf2 and time. +The tf2 and time tutorial :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp>` teaches the basic principles of tf2 and time. +The advanced tutorial about tf2 and time :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp>` teaches the principles of time traveling with tf2. + +Paper +----- + +There is a paper on tf2 presented at TePRA 2013: `tf: The transform library `_. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Topics-Services-Actions.rst b/source/ROS-Framework/interfaces/Topics-Services-Actions.rst index dc37818d99c..79995d63698 100644 --- a/source/ROS-Framework/interfaces/Topics-Services-Actions.rst +++ b/source/ROS-Framework/interfaces/Topics-Services-Actions.rst @@ -1,39 +1,43 @@ -.. _TopicsServicesActions: - -Topics vs Services vs Actions -============================= - -.. contents:: Contents - :depth: 1 - :local: - -When designing a system there are three primary styles of interfaces. -The specifications for the content is in the :doc:`Interfaces Overview <../Concepts/Basic/About-Interfaces>`. -This is written to provide the reader with guidelines about when to use each type of interface. - -Topics ------- - -* Should be used for continuous data streams (sensor data, robot state, ...) -* Are for continuous data flow. - Data might be published and subscribed at any time independent of any senders/receivers. - Many to many connection. - Callbacks receive data once it is available. - The publisher decides when data is sent. - -Services --------- - -* Should be used for remote procedure calls that terminate quickly, e.g. for querying the state of a node or doing a quick calculation such as IK. - They should never be used for longer running processes, in particular processes that might be required to preempt if exceptional situations occur and they should never change or depend on state to avoid unwanted side effects for other nodes. - -Actions -------- - -* Should be used for any discrete behavior that moves a robot or that runs for a longer time but provides feedback during execution. -* The most important property of actions is that they can be preempted and preemption should always be implemented cleanly by action servers. -* Actions can keep state for the lifetime of a goal, i.e. if executing two action goals in parallel on the same server, for each client a separate state instance can be kept since the goal is uniquely identified by its id. -* Slow perception routines which take several seconds to terminate or initiating a lower-level control mode are good use cases for actions. -* More complex non-blocking background processing. - Used for longer tasks like execution of robot actions. - Semantically for real-world actions. +.. redirect-from:: + + How-To-Guides/Topics-Services-Actions + +.. _TopicsServicesActions: + +Topics vs Services vs Actions +============================= + +.. contents:: Contents + :depth: 1 + :local: + +When designing a system there are three primary styles of interfaces. +The specifications for the content is in the :doc:`Interfaces Overview <../About-Interfaces>`. +This is written to provide the reader with guidelines about when to use each type of interface. + +Topics +------ + +* Should be used for continuous data streams (sensor data, robot state, ...) +* Are for continuous data flow. + Data might be published and subscribed at any time independent of any senders/receivers. + Many to many connection. + Callbacks receive data once it is available. + The publisher decides when data is sent. + +Services +-------- + +* Should be used for remote procedure calls that terminate quickly, e.g. for querying the state of a node or doing a quick calculation such as IK. + They should never be used for longer running processes, in particular processes that might be required to preempt if exceptional situations occur and they should never change or depend on state to avoid unwanted side effects for other nodes. + +Actions +------- + +* Should be used for any discrete behavior that moves a robot or that runs for a longer time but provides feedback during execution. +* The most important property of actions is that they can be preempted and preemption should always be implemented cleanly by action servers. +* Actions can keep state for the lifetime of a goal, i.e. if executing two action goals in parallel on the same server, for each client a separate state instance can be kept since the goal is uniquely identified by its id. +* Slow perception routines which take several seconds to terminate or initiating a lower-level control mode are good use cases for actions. +* More complex non-blocking background processing. + Used for longer tasks like execution of robot actions. + Semantically for real-world actions. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2.rst index 542b8a3c103..c5d001f75f6 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2.rst @@ -1,172 +1,173 @@ -.. redirect-from:: - - Tutorials/Tf2/Introduction-To-Tf2 - -.. _IntroToTf2: - -Introducing ``tf2`` -=================== - -**Goal:** Run a turtlesim demo and see some of the power of tf2 in a multi-robot example using turtlesim. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Installing the demo -------------------- - -Let's start by installing the demo package and its dependencies. - -.. tabs:: - - .. group-tab:: Ubuntu Packages - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim - - .. group-tab:: RHEL Packages - - .. code-block:: console - - $ sudo dnf install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim - - .. group-tab:: From Source - - .. code-block:: console - - $ git clone https://github.com/ros/geometry_tutorials.git -b ros2 - -Running the demo ----------------- - -Now that we've installed the ``turtle_tf2_py`` tutorial package let's run the demo. -First, open a new terminal and :doc:`source your ROS 2 installation <../../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. -Then run the following command: - -.. code-block:: console - - $ ros2 launch turtle_tf2_py turtle_tf2_demo.launch.py - -You will see the turtlesim start with two turtles. - -.. image:: images/turtlesim_follow1.png - -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Once the turtlesim is started you can drive the central turtle around in the turtlesim using the keyboard arrow keys, -select the second terminal window so that your keystrokes will be captured to drive the turtle. - -.. image:: images/turtlesim_follow2.png - -You can see that one turtle continuously moves to follow the turtle you are driving around. - -What is happening? ------------------- - -This demo is using the tf2 library to create three coordinate frames: a ``world`` frame, a ``turtle1`` frame, and a ``turtle2`` frame. -This tutorial uses a *tf2 broadcaster* to publish the turtle coordinate frames and a *tf2 listener* to compute the difference in the turtle frames and move one turtle to follow the other. - -tf2 tools ---------- - -Now let's look at how tf2 is being used to create this demo. -We can use ``tf2_tools`` to look at what tf2 is doing behind the scenes. - -1 Using view_frames -^^^^^^^^^^^^^^^^^^^ - -``view_frames`` creates a diagram of the frames being broadcast by tf2 over ROS. -Note that this utility only works on Linux; if you are Windows, skip to "Using tf2_echo" below. - -.. code-block:: console - - $ ros2 run tf2_tools view_frames - Listening to tf data during 5 seconds... - Generating graph in frames.pdf file... - -Here a tf2 listener is listening to the frames that are being broadcast over ROS and drawing a tree of how the frames are connected. -To view the tree, open the resulting ``frames.pdf`` with your favorite PDF viewer. - -.. image:: images/turtlesim_frames.png - -Here we can see three frames that are broadcast by tf2: ``world``, ``turtle1``, and ``turtle2``. -The ``world`` frame is the parent of the ``turtle1`` and ``turtle2`` frames. -``view_frames`` also reports some diagnostic information about when the oldest and most -recent frame transforms were received and how fast the tf2 frame is published to tf2 for debugging purposes. - -2 Using tf2_echo -^^^^^^^^^^^^^^^^ - -``tf2_echo`` reports the transform between any two frames broadcast over ROS. - -Usage: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo [source_frame] [target_frame] - -Let's look at the transform of the ``turtle2`` frame with respect to ``turtle1`` frame which is equivalent to: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo turtle2 turtle1 - At time 1683385337.850619099 - - Translation: [2.157, 0.901, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.172, 0.985] - - Rotation: in RPY (radian) [0.000, -0.000, 0.345] - - Rotation: in RPY (degree) [0.000, -0.000, 19.760] - - Matrix: - 0.941 -0.338 0.000 2.157 - 0.338 0.941 0.000 0.901 - 0.000 0.000 1.000 0.000 - 0.000 0.000 0.000 1.000 - At time 1683385338.841997774 - - Translation: [1.256, 0.216, 0.000] - - Rotation: in Quaternion [0.000, 0.000, -0.016, 1.000] - - Rotation: in RPY (radian) [0.000, 0.000, -0.032] - - Rotation: in RPY (degree) [0.000, 0.000, -1.839] - - Matrix: - 0.999 0.032 0.000 1.256 - -0.032 0.999 -0.000 0.216 - -0.000 0.000 1.000 0.000 - 0.000 0.000 0.000 1.000 - - -You will see the transform displayed as the ``tf2_echo`` listener receives the frames broadcast over ROS 2. - -As you drive your turtle around you will see the transform change as the two turtles move relative to each other. - -rviz2 and tf2 -------------- - -``rviz2`` is a visualization tool that is useful for examining tf2 frames. -Let's look at our turtle frames using ``rviz2`` by starting it with a configuration file using the ``-d`` option: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ ros2 run rviz2 rviz2 -d $(ros2 pkg prefix --share turtle_tf2_py)/rviz/turtle_rviz.rviz - - .. group-tab:: Windows - - .. code-block:: console - - $ for /f "usebackq tokens=*" %a in (`ros2 pkg prefix --share turtle_tf2_py`) do rviz2 -d %a/rviz/turtle_rviz.rviz - -.. image:: images/turtlesim_rviz.png - -In the side bar you will see the frames broadcast by tf2. -As you drive the turtle around you will see the frames move in rviz. +.. redirect-from:: + + Tutorials/Tf2/Introduction-To-Tf2 + Tutorials/Intermediate/Tf2/Introduction-To-Tf2 + +.. _IntroToTf2: + +Introducing ``tf2`` +=================== + +**Goal:** Run a turtlesim demo and see some of the power of tf2 in a multi-robot example using turtlesim. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Installing the demo +------------------- + +Let's start by installing the demo package and its dependencies. + +.. tabs:: + + .. group-tab:: Ubuntu Packages + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim + + .. group-tab:: RHEL Packages + + .. code-block:: console + + $ sudo dnf install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim + + .. group-tab:: From Source + + .. code-block:: console + + $ git clone https://github.com/ros/geometry_tutorials.git -b ros2 + +Running the demo +---------------- + +Now that we've installed the ``turtle_tf2_py`` tutorial package let's run the demo. +First, open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Then run the following command: + +.. code-block:: console + + $ ros2 launch turtle_tf2_py turtle_tf2_demo.launch.py + +You will see the turtlesim start with two turtles. + +.. image:: images/turtlesim_follow1.png + +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Once the turtlesim is started you can drive the central turtle around in the turtlesim using the keyboard arrow keys, +select the second terminal window so that your keystrokes will be captured to drive the turtle. + +.. image:: images/turtlesim_follow2.png + +You can see that one turtle continuously moves to follow the turtle you are driving around. + +What is happening? +------------------ + +This demo is using the tf2 library to create three coordinate frames: a ``world`` frame, a ``turtle1`` frame, and a ``turtle2`` frame. +This tutorial uses a *tf2 broadcaster* to publish the turtle coordinate frames and a *tf2 listener* to compute the difference in the turtle frames and move one turtle to follow the other. + +tf2 tools +--------- + +Now let's look at how tf2 is being used to create this demo. +We can use ``tf2_tools`` to look at what tf2 is doing behind the scenes. + +1 Using view_frames +^^^^^^^^^^^^^^^^^^^ + +``view_frames`` creates a diagram of the frames being broadcast by tf2 over ROS. +Note that this utility only works on Linux; if you are Windows, skip to "Using tf2_echo" below. + +.. code-block:: console + + $ ros2 run tf2_tools view_frames + Listening to tf data during 5 seconds... + Generating graph in frames.pdf file... + +Here a tf2 listener is listening to the frames that are being broadcast over ROS and drawing a tree of how the frames are connected. +To view the tree, open the resulting ``frames.pdf`` with your favorite PDF viewer. + +.. image:: images/turtlesim_frames.png + +Here we can see three frames that are broadcast by tf2: ``world``, ``turtle1``, and ``turtle2``. +The ``world`` frame is the parent of the ``turtle1`` and ``turtle2`` frames. +``view_frames`` also reports some diagnostic information about when the oldest and most +recent frame transforms were received and how fast the tf2 frame is published to tf2 for debugging purposes. + +2 Using tf2_echo +^^^^^^^^^^^^^^^^ + +``tf2_echo`` reports the transform between any two frames broadcast over ROS. + +Usage: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo [source_frame] [target_frame] + +Let's look at the transform of the ``turtle2`` frame with respect to ``turtle1`` frame which is equivalent to: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo turtle2 turtle1 + At time 1683385337.850619099 + - Translation: [2.157, 0.901, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.172, 0.985] + - Rotation: in RPY (radian) [0.000, -0.000, 0.345] + - Rotation: in RPY (degree) [0.000, -0.000, 19.760] + - Matrix: + 0.941 -0.338 0.000 2.157 + 0.338 0.941 0.000 0.901 + 0.000 0.000 1.000 0.000 + 0.000 0.000 0.000 1.000 + At time 1683385338.841997774 + - Translation: [1.256, 0.216, 0.000] + - Rotation: in Quaternion [0.000, 0.000, -0.016, 1.000] + - Rotation: in RPY (radian) [0.000, 0.000, -0.032] + - Rotation: in RPY (degree) [0.000, 0.000, -1.839] + - Matrix: + 0.999 0.032 0.000 1.256 + -0.032 0.999 -0.000 0.216 + -0.000 0.000 1.000 0.000 + 0.000 0.000 0.000 1.000 + + +You will see the transform displayed as the ``tf2_echo`` listener receives the frames broadcast over ROS 2. + +As you drive your turtle around you will see the transform change as the two turtles move relative to each other. + +rviz2 and tf2 +------------- + +``rviz2`` is a visualization tool that is useful for examining tf2 frames. +Let's look at our turtle frames using ``rviz2`` by starting it with a configuration file using the ``-d`` option: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ ros2 run rviz2 rviz2 -d $(ros2 pkg prefix --share turtle_tf2_py)/rviz/turtle_rviz.rviz + + .. group-tab:: Windows + + .. code-block:: console + + $ for /f "usebackq tokens=*" %a in (`ros2 pkg prefix --share turtle_tf2_py`) do rviz2 -d %a/rviz/turtle_rviz.rviz + +.. image:: images/turtlesim_rviz.png + +In the side bar you will see the frames broadcast by tf2. +As you drive the turtle around you will see the frames move in rviz. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst index 5eff1c20b11..9b279eea5b3 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst @@ -1,245 +1,246 @@ -.. redirect-from:: - - Tutorials/Tf2/Quaternion-Fundamentals - -.. _QuaternionFundamentals: - -Quaternion fundamentals -======================= - -**Goal:** Learn the basics of quaternion usage in ROS 2. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -A quaternion is a 4-tuple representation of orientation, which is more concise than a rotation matrix. -Quaternions are very efficient for analyzing situations where rotations in three dimensions are involved. -Quaternions are used widely in robotics, quantum mechanics, computer vision, and 3D animation. - -You can learn more about the underlying mathematical concept on `Wikipedia `_. -You can also take a look at an explorable video series `Visualizing quaternions `_ made by `3blue1brown `_. - -In this tutorial, you will learn how quaternions and conversion methods work in ROS 2. - -Prerequisites -------------- - -You can take a look at libraries like `transforms3d `_, `scipy.spatial.transform `_, `pytransform3d `_, `numpy-quaternion `_ or `blender.mathutils `_. - -However, this is not a hard requirement and you can stick to any other geometric transformation library that suit you best. - -Components of a quaternion --------------------------- - -ROS 2 uses quaternions to track and apply rotations. -A quaternion has 4 components ``(x, y, z, w)``. -In ROS 2, ``w`` is last, but in some libraries like Eigen, ``w`` can be placed at the first position. -The commonly-used unit quaternion that yields no rotation about the x/y/z axes is ``(0, 0, 0, 1)``, and can be created in a following way: - -.. code-block:: C++ - - #include - ... - - tf2::Quaternion q; - // Create a quaternion from roll/pitch/yaw in radians (0, 0, 0) - q.setRPY(0, 0, 0); - // Print the quaternion components (0, 0, 0, 1) - RCLCPP_INFO(this->get_logger(), "%f %f %f %f", - q.x(), q.y(), q.z(), q.w()); - -The magnitude of a quaternion should always be one. -If numerical errors cause a quaternion magnitude other than one, ROS 2 will print warnings. -To avoid these warnings, normalize the quaternion: - -.. code-block:: C++ - - q.normalize(); - -Quaternion types in ROS 2 -------------------------- - -ROS 2 uses two quaternion datatypes: ``tf2::Quaternion`` and its equivalent ``geometry_msgs::msg::Quaternion``. -To convert between them in C++, use the methods of ``tf2_geometry_msgs``. - -.. code-block:: C++ - - #include - ... - - tf2::Quaternion tf2_quat, tf2_quat_from_msg; - tf2_quat.setRPY(roll, pitch, yaw); - // Convert tf2::Quaternion to geometry_msgs::msg::Quaternion - geometry_msgs::msg::Quaternion msg_quat = tf2::toMsg(tf2_quat); - - // Convert geometry_msgs::msg::Quaternion to tf2::Quaternion - tf2::convert(msg_quat, tf2_quat_from_msg); - // or - tf2::fromMsg(msg_quat, tf2_quat_from_msg); - -There is no ``tf2::Quaternion`` equivalent in Python. -Instead, the builtin ``list`` is used. - -.. code-block:: python - - from geometry_msgs.msg import Quaternion - ... - - # Create a list of floats, which is compatible with tf2 - # Quaternion methods - quat_tf = [0.0, 1.0, 0.0, 0.0] - - # Convert a list to geometry_msgs.msg.Quaternion - msg_quat = Quaternion(x=quat_tf[0], y=quat_tf[1], z=quat_tf[2], w=quat_tf[3]) - -Quaternion operations ---------------------- - -1 Think in RPY then convert to quaternion -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -It's easy for us to think of rotations about axes, but hard to think in terms of quaternions. -A suggestion is to calculate target rotations in terms of the three individual rotations *roll* (about an X-axis), *pitch* (about the Y-axis), and *yaw* (about the Z-axis), and then convert to a quaternion. - -.. code-block:: python - - # quaternion_from_euler method is available in turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py - q = quaternion_from_euler(1.5707, 0, -1.5707) - print(f'The quaternion representation is x: {q[0]} y: {q[1]} z: {q[2]} w: {q[3]}.') - -This method relates to `Euler angles `_. -There are several ways of applying Euler angles. -The one described above, which ROS 2 adopts, is called *fixed (or static) frame* RPY. -This means that the three individual rotations are applied to the original, unmoving coordinate axes. -This is contrary to *relative frame*, where rotations are applied to the coordinate axes that get transformed by preceding rotations. - - -2 Applying a quaternion rotation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To apply the rotation of one quaternion to a pose, simply multiply the previous quaternion of the pose by the quaternion representing the desired rotation. -The order of this multiplication matters. - -C++ - -.. code-block:: C++ - - #include - ... - - tf2::Quaternion q_orig, q_rot, q_new; - - q_orig.setRPY(0.0, 0.0, 0.0); - // Rotate the previous pose by 180* about X - q_rot.setRPY(3.14159, 0.0, 0.0); - q_new = q_rot * q_orig; - q_new.normalize(); - -Python - -.. code-block:: python - - q_orig = quaternion_from_euler(0, 0, 0) - # Rotate the previous pose by 180* about X - q_rot = quaternion_from_euler(3.14159, 0, 0) - q_new = quaternion_multiply(q_rot, q_orig) - - -3 Inverting a quaternion -^^^^^^^^^^^^^^^^^^^^^^^^ - -An easy way to invert a quaternion is to negate the x-, y-, and z-components: - -.. code-block:: python - - q[0] = -q[0] - q[1] = -q[1] - q[2] = -q[2] - -.. note:: - - This should not be confused with negating *all* elements of the quaternion. - -4 Relative rotations -^^^^^^^^^^^^^^^^^^^^ - -Say you have two quaternions from the same frame, ``q_1`` and ``q_2``. -You want to find the relative rotation, ``q_r``, that converts ``q_1`` to ``q_2`` in a following manner: - -.. code-block:: C++ - - q_2 = q_r * q_1 - -You can solve for ``q_r`` similarly to solving a matrix equation. -Invert ``q_1`` and right-multiply both sides. -Again, the order of multiplication is important: - -.. code-block:: C++ - - q_r = q_2 * q_1_inverse - -Here's an example to get the relative rotation from the previous robot pose to the current robot pose in python: - -.. code-block:: python - - def quaternion_multiply(q0, q1): - """ - Multiplies two quaternions. - - Input - :param q0: A 4 element array containing the first quaternion (q01, q11, q21, q31) - :param q1: A 4 element array containing the second quaternion (q02, q12, q22, q32) - - Output - :return: A 4 element array containing the final quaternion (q03,q13,q23,q33) in (w, x, y, z) order - - """ - # Extract the values from q0 - x0 = q0[0] - y0 = q0[1] - z0 = q0[2] - w0 = q0[3] - - # Extract the values from q1 - x1 = q1[0] - y1 = q1[1] - z1 = q1[2] - w1 = q1[3] - - # Compute the product of the two quaternions, term by term - q0q1_w = w0 * w1 - x0 * x1 - y0 * y1 - z0 * z1 - q0q1_x = w0 * x1 + x0 * w1 + y0 * z1 - z0 * y1 - q0q1_y = w0 * y1 - x0 * z1 + y0 * w1 + z0 * x1 - q0q1_z = w0 * z1 + x0 * y1 - y0 * x1 + z0 * w1 - - # Create a 4 element array containing the final quaternion - final_quaternion = np.array([q0q1_w, q0q1_x, q0q1_y, q0q1_z]) - - # Return a 4 element array containing the final quaternion (q02,q12,q22,q32) - return final_quaternion - - q1_inv[0] = -prev_pose.pose.orientation.x # Negate for inverse - q1_inv[1] = -prev_pose.pose.orientation.y # Negate for inverse - q1_inv[2] = -prev_pose.pose.orientation.z # Negate for inverse - q1_inv[3] = prev_pose.pose.orientation.w - - q2[0] = current_pose.pose.orientation.x - q2[1] = current_pose.pose.orientation.y - q2[2] = current_pose.pose.orientation.z - q2[3] = current_pose.pose.orientation.w - - qr = quaternion_multiply(q2, q1_inv) - -Summary -------- - -In this tutorial, you learned about the fundamental concepts of a quaternion and its related mathematical operations, like inversion and rotation. -You also learned about its usage examples in ROS 2 and conversion methods between two separate Quaternion classes. +.. redirect-from:: + + Tutorials/Tf2/Quaternion-Fundamentals + Tutorials/Intermediate/Tf2/Quaternion-Fundamentals + +.. _QuaternionFundamentals: + +Quaternion fundamentals +======================= + +**Goal:** Learn the basics of quaternion usage in ROS 2. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +A quaternion is a 4-tuple representation of orientation, which is more concise than a rotation matrix. +Quaternions are very efficient for analyzing situations where rotations in three dimensions are involved. +Quaternions are used widely in robotics, quantum mechanics, computer vision, and 3D animation. + +You can learn more about the underlying mathematical concept on `Wikipedia `_. +You can also take a look at an explorable video series `Visualizing quaternions `_ made by `3blue1brown `_. + +In this tutorial, you will learn how quaternions and conversion methods work in ROS 2. + +Prerequisites +------------- + +You can take a look at libraries like `transforms3d `_, `scipy.spatial.transform `_, `pytransform3d `_, `numpy-quaternion `_ or `blender.mathutils `_. + +However, this is not a hard requirement and you can stick to any other geometric transformation library that suit you best. + +Components of a quaternion +-------------------------- + +ROS 2 uses quaternions to track and apply rotations. +A quaternion has 4 components ``(x, y, z, w)``. +In ROS 2, ``w`` is last, but in some libraries like Eigen, ``w`` can be placed at the first position. +The commonly-used unit quaternion that yields no rotation about the x/y/z axes is ``(0, 0, 0, 1)``, and can be created in a following way: + +.. code-block:: C++ + + #include + ... + + tf2::Quaternion q; + // Create a quaternion from roll/pitch/yaw in radians (0, 0, 0) + q.setRPY(0, 0, 0); + // Print the quaternion components (0, 0, 0, 1) + RCLCPP_INFO(this->get_logger(), "%f %f %f %f", + q.x(), q.y(), q.z(), q.w()); + +The magnitude of a quaternion should always be one. +If numerical errors cause a quaternion magnitude other than one, ROS 2 will print warnings. +To avoid these warnings, normalize the quaternion: + +.. code-block:: C++ + + q.normalize(); + +Quaternion types in ROS 2 +------------------------- + +ROS 2 uses two quaternion datatypes: ``tf2::Quaternion`` and its equivalent ``geometry_msgs::msg::Quaternion``. +To convert between them in C++, use the methods of ``tf2_geometry_msgs``. + +.. code-block:: C++ + + #include + ... + + tf2::Quaternion tf2_quat, tf2_quat_from_msg; + tf2_quat.setRPY(roll, pitch, yaw); + // Convert tf2::Quaternion to geometry_msgs::msg::Quaternion + geometry_msgs::msg::Quaternion msg_quat = tf2::toMsg(tf2_quat); + + // Convert geometry_msgs::msg::Quaternion to tf2::Quaternion + tf2::convert(msg_quat, tf2_quat_from_msg); + // or + tf2::fromMsg(msg_quat, tf2_quat_from_msg); + +There is no ``tf2::Quaternion`` equivalent in Python. +Instead, the builtin ``list`` is used. + +.. code-block:: python + + from geometry_msgs.msg import Quaternion + ... + + # Create a list of floats, which is compatible with tf2 + # Quaternion methods + quat_tf = [0.0, 1.0, 0.0, 0.0] + + # Convert a list to geometry_msgs.msg.Quaternion + msg_quat = Quaternion(x=quat_tf[0], y=quat_tf[1], z=quat_tf[2], w=quat_tf[3]) + +Quaternion operations +--------------------- + +1 Think in RPY then convert to quaternion +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +It's easy for us to think of rotations about axes, but hard to think in terms of quaternions. +A suggestion is to calculate target rotations in terms of the three individual rotations *roll* (about an X-axis), *pitch* (about the Y-axis), and *yaw* (about the Z-axis), and then convert to a quaternion. + +.. code-block:: python + + # quaternion_from_euler method is available in turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py + q = quaternion_from_euler(1.5707, 0, -1.5707) + print(f'The quaternion representation is x: {q[0]} y: {q[1]} z: {q[2]} w: {q[3]}.') + +This method relates to `Euler angles `_. +There are several ways of applying Euler angles. +The one described above, which ROS 2 adopts, is called *fixed (or static) frame* RPY. +This means that the three individual rotations are applied to the original, unmoving coordinate axes. +This is contrary to *relative frame*, where rotations are applied to the coordinate axes that get transformed by preceding rotations. + + +2 Applying a quaternion rotation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To apply the rotation of one quaternion to a pose, simply multiply the previous quaternion of the pose by the quaternion representing the desired rotation. +The order of this multiplication matters. + +C++ + +.. code-block:: C++ + + #include + ... + + tf2::Quaternion q_orig, q_rot, q_new; + + q_orig.setRPY(0.0, 0.0, 0.0); + // Rotate the previous pose by 180* about X + q_rot.setRPY(3.14159, 0.0, 0.0); + q_new = q_rot * q_orig; + q_new.normalize(); + +Python + +.. code-block:: python + + q_orig = quaternion_from_euler(0, 0, 0) + # Rotate the previous pose by 180* about X + q_rot = quaternion_from_euler(3.14159, 0, 0) + q_new = quaternion_multiply(q_rot, q_orig) + + +3 Inverting a quaternion +^^^^^^^^^^^^^^^^^^^^^^^^ + +An easy way to invert a quaternion is to negate the x-, y-, and z-components: + +.. code-block:: python + + q[0] = -q[0] + q[1] = -q[1] + q[2] = -q[2] + +.. note:: + + This should not be confused with negating *all* elements of the quaternion. + +4 Relative rotations +^^^^^^^^^^^^^^^^^^^^ + +Say you have two quaternions from the same frame, ``q_1`` and ``q_2``. +You want to find the relative rotation, ``q_r``, that converts ``q_1`` to ``q_2`` in a following manner: + +.. code-block:: C++ + + q_2 = q_r * q_1 + +You can solve for ``q_r`` similarly to solving a matrix equation. +Invert ``q_1`` and right-multiply both sides. +Again, the order of multiplication is important: + +.. code-block:: C++ + + q_r = q_2 * q_1_inverse + +Here's an example to get the relative rotation from the previous robot pose to the current robot pose in python: + +.. code-block:: python + + def quaternion_multiply(q0, q1): + """ + Multiplies two quaternions. + + Input + :param q0: A 4 element array containing the first quaternion (q01, q11, q21, q31) + :param q1: A 4 element array containing the second quaternion (q02, q12, q22, q32) + + Output + :return: A 4 element array containing the final quaternion (q03,q13,q23,q33) in (w, x, y, z) order + + """ + # Extract the values from q0 + x0 = q0[0] + y0 = q0[1] + z0 = q0[2] + w0 = q0[3] + + # Extract the values from q1 + x1 = q1[0] + y1 = q1[1] + z1 = q1[2] + w1 = q1[3] + + # Compute the product of the two quaternions, term by term + q0q1_w = w0 * w1 - x0 * x1 - y0 * y1 - z0 * z1 + q0q1_x = w0 * x1 + x0 * w1 + y0 * z1 - z0 * y1 + q0q1_y = w0 * y1 - x0 * z1 + y0 * w1 + z0 * x1 + q0q1_z = w0 * z1 + x0 * y1 - y0 * x1 + z0 * w1 + + # Create a 4 element array containing the final quaternion + final_quaternion = np.array([q0q1_w, q0q1_x, q0q1_y, q0q1_z]) + + # Return a 4 element array containing the final quaternion (q02,q12,q22,q32) + return final_quaternion + + q1_inv[0] = -prev_pose.pose.orientation.x # Negate for inverse + q1_inv[1] = -prev_pose.pose.orientation.y # Negate for inverse + q1_inv[2] = -prev_pose.pose.orientation.z # Negate for inverse + q1_inv[3] = prev_pose.pose.orientation.w + + q2[0] = current_pose.pose.orientation.x + q2[1] = current_pose.pose.orientation.y + q2[2] = current_pose.pose.orientation.z + q2[3] = current_pose.pose.orientation.w + + qr = quaternion_multiply(q2, q1_inv) + +Summary +------- + +In this tutorial, you learned about the fundamental concepts of a quaternion and its related mathematical operations, like inversion and rotation. +You also learned about its usage examples in ROS 2 and conversion methods between two separate Quaternion classes. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst index eb8155a2aa3..e3fc86ff6ce 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst @@ -1,738 +1,739 @@ -.. redirect-from:: - - Tutorials/Ros2bag/Recording-And-Playing-Back-Data - -.. _ROS2Bag: - -Recording and playing back data -=============================== - -**Goal:** Record data published on a topic, a service and an action so you can replay and examine it any time. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``ros2 bag`` is a command line tool for recording data published on topics, services and actions in your ROS 2 system. -It accumulates the data passed on any number of topics, services and actions, then saves it in a database. -You can then replay the data to reproduce the results of your tests and experiments. -Recording topics, services and actions is also a great way to share your work and allow others to recreate it. - - -Prerequisites -------------- - -You should have ``ros2 bag`` installed as a part of your regular ROS 2 setup. - -If you need to install ROS 2, see the :doc:`Installation instructions <../../../Installation>`. - -This tutorial talks about concepts covered in previous tutorials, like :doc:`nodes <../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../Understanding-ROS2-Services/Understanding-ROS2-Services>` and :doc:`actions <../Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. -It also uses the :doc:`turtlesim package <../Introducing-Turtlesim/Introducing-Turtlesim>`, :doc:`Service Introspection Demo <../../Demos/Service-Introspection>` and :doc:`Action Introspection Demo <../../Demos/Action-Introspection>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - - -Managing Topic Data -------------------- - -1 Setup -^^^^^^^ - -You'll be recording your keyboard input in the ``turtlesim`` system to save and replay later on, so begin by starting up the ``/turtlesim`` and ``/teleop_turtle`` nodes. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Let's also make a new directory to store our saved recordings, just as good practice: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir bag_files - $ cd bag_files - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir bag_files - $ cd bag_files - - .. group-tab:: Windows - - .. code-block:: console - - $ md bag_files - $ cd bag_files - - -2 Choose a topic -^^^^^^^^^^^^^^^^ - -``ros2 bag`` can record data from messages published to topics. -To see the list of your system's topics, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 topic list - /parameter_events - /rosout - /turtle1/cmd_vel - /turtle1/color_sensor - /turtle1/pose - -In the topics tutorial, you learned that the ``/turtle_teleop`` node publishes commands on the ``/turtle1/cmd_vel`` topic to make the turtle move in turtlesim. - -To see the data that ``/turtle1/cmd_vel`` is publishing, run the command: - -.. code-block:: console - - $ ros2 topic echo /turtle1/cmd_vel - -Nothing will show up at first because no data is being published by the teleop. -Return to the terminal where you ran the teleop and select it so it's active. -Use the arrow keys to move the turtle around, and you will see data being published on the terminal running ``ros2 topic echo``. - -.. code-block:: console - - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - - -3 Record topics -^^^^^^^^^^^^^^^ - -3.1 Record a single topic -~~~~~~~~~~~~~~~~~~~~~~~~~ - -To record the data published to a topic use the command syntax: - -.. code-block:: console - - $ ros2 bag record --topics - -Before running this command on your chosen topic, open a new terminal and move into the ``bag_files`` directory you created earlier, because the rosbag file will save in the directory where you run it. - -Run the command: - -.. code-block:: console - - $ ros2 bag record --topics /turtle1/cmd_vel - [INFO] [rosbag2_storage]: Opened database 'rosbag2_2019_10_11-05_18_45'. - [INFO] [rosbag2_transport]: Listening for topics... - [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' - [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... - -Now ``ros2 bag`` is recording the data published on the ``/turtle1/cmd_vel`` topic. -Return to the teleop terminal and move the turtle around again. -The movements don't matter, but try to make a recognizable pattern to see when you replay the data later. - -.. image:: images/record.png - -Press :kbd:`Ctrl-C` to stop recording. - -The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. -This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. - -3.2 Record multiple topics -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can also record multiple topics, as well as change the name of the bag directory ``ros2 bag`` saves to. - -Run the following command: - -.. code-block:: console - - $ ros2 bag record -o subset --topics /turtle1/cmd_vel /turtle1/pose - [INFO] [rosbag2_storage]: Opened database 'subset'. - [INFO] [rosbag2_transport]: Listening for topics... - [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' - [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/pose' - [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... - -The ``-o`` option allows you to choose a unique name for your bag directory. -The following string, in this case ``subset``, is the bag directory name. - -To record more than one topic at a time, simply list each topic separated by a space after ``--topics``. -In this case, the command output above confirms that both topics are being recorded. - -You can move the turtle around and press :kbd:`Ctrl-C` when you're finished. - -.. note:: - - There is another option you can add to the command, ``-a``, which records all the topics on your system. - -3.3 Split recording into multiple files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can also split your recording into multiple files, based on either recording duration or file size. -``-d `` ensures that each file only lasts ```` seconds before it starts writing to a new file, or ``-b `` ensures that each file does not exceed ```` bytes in file size. -This prevents large and unwieldy file sizes, and protects against losing all data if the recording operation becomes corrupted at some point. - -Run the following for at least 15 seconds, allowing for three 5-second bag files to be written: - -.. code-block:: console - - $ ros2 bag record -o subset_split -d 5 --topics /turtle1/cmd_vel /turtle1/pose - [INFO] [rosbag2_recorder]: Press SPACE for pausing/resuming - [INFO] [rosbag2_recorder]: Listening for topics... - [INFO] [rosbag2_recorder]: Event publisher thread: Starting - [INFO] [rosbag2_recorder]: Recording... - [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/cmd_vel' - [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/pose' - [INFO] [rosbag2_recorder]: All requested topics are subscribed. Stopping discovery... - [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while - [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while - [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while - -Press :kbd:`Ctrl-C` when you're finished. -You should find a ``subset_split`` directory with these files inside: ``0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, ``1_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and so on. - -4 Inspect topic data -^^^^^^^^^^^^^^^^^^^^ - -You can see details about your recording by running: - -.. code-block:: console - - $ ros2 bag info - -Running this command on the ``subset`` bag recording will return a list of information: - -.. code-block:: console - - $ ros2 bag info subset - Files: subset_0.mcap - Bag size: 228.5 KiB - Storage id: mcap - ROS Distro: rolling - Duration: 48.47s - Start: Oct 11 2019 06:09:09.12 (1570799349.12) - End Oct 11 2019 06:09:57.60 (1570799397.60) - Messages: 3013 - Topic information: Topic: /turtle1/cmd_vel | Type: geometry_msgs/msg/Twist | Count: 9 | Serialization Format: cdr - Topic: /turtle1/pose | Type: turtlesim_msgs/msg/Pose | Count: 3004 | Serialization Format: cdr - Services: 0 - Service information: - Actions: 0 - Action information: - -Alternatively, you can also call ``ros2 bag info`` on an individual file, such as ``subset_split/0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and it will only show information for that portion of the recording; in this case, the first 5 seconds. - -5 Play topic data -^^^^^^^^^^^^^^^^^ - -5.1 Play a single bag -~~~~~~~~~~~~~~~~~~~~~ - -Before replaying the bag, enter :kbd:`Ctrl-C` in the terminal where the teleop is running. -Then make sure your turtlesim window is visible so you can see the bag file in action. - -Enter the command: - -.. code-block:: console - - $ ros2 bag play subset - [INFO] [rosbag2_player]: Set rate to 1 - [INFO] [rosbag2_player]: Adding keyboard callbacks. - [INFO] [rosbag2_player]: Press SPACE for Pause/Resume - [INFO] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message - [INFO] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% - [INFO] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% - Progress bar enabled at 3 Hz. - Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped - [INFO] [rosbag2_player]: Playback until timestamp: -1 - - - ====== Playback Progress ====== - [1751923361.427372456] Duration 0.00/48.47 [R] - -Your turtle will follow the same path you entered while recording (though not 100% exactly; turtlesim is sensitive to small changes in the system's timing). - -.. image:: images/playback.png - -Because the ``subset`` file recorded the ``/turtle1/pose`` topic, the ``ros2 bag play`` command won't quit for as long as you had turtlesim running, even if you weren't moving. - -This is because as long as the ``/turtlesim`` node is active, it publishes data on the ``/turtle1/pose`` topic at regular intervals. -You may have noticed in the ``ros2 bag info`` example result above that the ``/turtle1/cmd_vel`` topic's ``Count`` information was only 9; that's how many times we pressed the arrow keys while recording. - -Notice that ``/turtle1/pose`` has a ``Count`` value of over 3000; while we were recording, data was published on that topic 3000 times. - -To get an idea of how often position data is published, you can run the command: - -.. code-block:: console - - $ ros2 topic hz /turtle1/pose - -5.2 Play multiple bags -~~~~~~~~~~~~~~~~~~~~~~ - -At times, it is relevant to split the desired recorded topics amongst multiple recordings, as a way to distribute the recording workload. -As an example, we can record ``/turtle1/cmd_vel`` and ``/turtle1/pose`` each to their own bag. - -Create two terminal instances. -In the first one, run the following: - -.. code-block:: console - - $ ros2 bag record -o subset_cmd_vel --topics /turtle1/cmd_vel - -In the second terminal, run this: - -.. code-block:: console - - $ ros2 bag record -o subset_pose --topics /turtle1/pose - -Move the turtle around as you did before, then end both recordings with :kbd:`Ctrl-C` when finished. - -To have these two recordings play in parallel with correct timing, call ``ros2 bag play`` with ``-i `` for each bag you want to include. -In this case, run: - -.. code-block:: console - - $ ros2 bag play -i subset_cmd_vel -i subset_pose - -This will play the ``subset_cmd_vel`` and ``subset_pose`` recordings together, with the playback synced to replicate the original order of messages. -If used, the optional argument ``--message-order {received,sent}`` determines whether the messages are sequenced according to the time they were received or published (defaults to received). -This applies to playing a single bag as well. - -Managing Service Data ---------------------- - -1 Setup -^^^^^^^ - -You'll be recording service data between ``introspection_client`` and ``introspection_service``, then display and replay that same data later on. -To record service data between service client and server, ``Service Introspection`` must be enabled on the node. - -Let's start ``introspection_client`` and ``introspection_service`` nodes and enable ``Service Introspection``. -You can see more details for :doc:`Service Introspection Demo <../../Demos/Service-Introspection>`. - -Open a new terminal and run ``introspection_service``, enabling ``Service Introspection``: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp introspection_service --ros-args -p service_configure_introspection:=contents - -Open another terminal and run ``introspection_client``, enabling ``Service Introspection``: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp introspection_client --ros-args -p client_configure_introspection:=contents - -2 Check service availability -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``ros2 bag`` can only record data from available services. -To see the list of your system's services, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 service list - /add_two_ints - /introspection_client/describe_parameters - /introspection_client/get_parameter_types - /introspection_client/get_parameters - /introspection_client/get_type_description - /introspection_client/list_parameters - /introspection_client/set_parameters - /introspection_client/set_parameters_atomically - /introspection_service/describe_parameters - /introspection_service/get_parameter_types - /introspection_service/get_parameters - /introspection_service/get_type_description - /introspection_service/list_parameters - /introspection_service/set_parameters - /introspection_service/set_parameters_atomically - -To check if ``Service Introspection`` is enabled on the client and service, run the command: - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - info: - event_type: REQUEST_SENT - stamp: - sec: 1713995389 - nanosec: 386809259 - client_gid: [1, 15, 96, 219, 162, 1, 108, 201, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 133 - request: [{a: 2, b: 3}] - response: [] - --- - -You should see the service communication. - -3 Record services -^^^^^^^^^^^^^^^^^ - -To record service data, the following options are supported. -Service data can be recorded with topics at the same time. - -To record specific services: - -.. code-block:: console - - $ ros2 bag record --service - -To record all services: - -.. code-block:: console - - $ ros2 bag record --all-services - -Run the command: - -.. code-block:: console - - $ ros2 bag record --service /add_two_ints - [INFO] [1713995957.643573503] [rosbag2_recorder]: Press SPACE for pausing/resuming - [INFO] [1713995957.662067587] [rosbag2_recorder]: Event publisher thread: Starting - [INFO] [1713995957.662067614] [rosbag2_recorder]: Listening for topics... - [INFO] [1713995957.666048323] [rosbag2_recorder]: Subscribed to topic '/add_two_ints/_service_event' - [INFO] [1713995957.666092458] [rosbag2_recorder]: Recording... - -Now ``ros2 bag`` is recording the service data published on the ``/add_two_ints`` service. -To stop the recording, enter :kbd:`Ctrl-C` in the terminal. - -The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. -This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. - -4 Inspect service data -^^^^^^^^^^^^^^^^^^^^^^ - -You can see details about your recording by running: - -.. code-block:: console - - $ ros2 bag info - Files: rosbag2_2024_04_24-14_59_17_0.mcap - Bag size: 15.1 KiB - Storage id: mcap - ROS Distro: rolling - Duration: 9.211s - Start: Apr 24 2024 14:59:17.676 (1713995957.676) - End: Apr 24 2024 14:59:26.888 (1713995966.888) - Messages: 0 - Topic information: - Service: 1 - Service information: Service: /add_two_ints | Type: example_interfaces/srv/AddTwoInts | Event Count: 78 | Serialization Format: cdr - -5 Play service data -^^^^^^^^^^^^^^^^^^^ - -Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``introspection_client`` is running. -When ``introspection_client`` stops running, ``introspection_service`` also stops printing the result because there are no incoming requests. - -Replaying the service data from the bag file will start sending the requests to ``introspection_service``. - -Enter the command: - -.. code-block:: console - - $ ros2 bag play --publish-service-requests - [INFO] [1713997477.870856190] [rosbag2_player]: Set rate to 1 - [INFO] [1713997477.877417477] [rosbag2_player]: Adding keyboard callbacks. - [INFO] [1713997477.877442404] [rosbag2_player]: Press SPACE for Pause/Resume - [INFO] [1713997477.877447855] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message - [INFO] [1713997477.877452655] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% - [INFO] [1713997477.877456954] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% - [INFO] [1713997477.877573647] [rosbag2_player]: Playback until timestamp: -1 - -Your ``introspection_service`` terminal will once again start printing the following service messages: - -.. code-block:: console - - [INFO] [1713997478.090466075] [introspection_service]: Incoming request - a: 2 b: 3 - -This is because ``ros2 bag play`` sends the service request data from the bag file to the ``/add_two_ints`` service. - -We can also introspect service communication as ``ros2 bag play`` is playing it back to verify the ``introspection_service``. - -Run this command before ``ros2 bag play`` to see the ``introspection_service``: - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - -You can see the service request from the bag file and the service response from ``introspection_service``. - -.. code-block:: console - - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1713998176 - nanosec: 372700698 - client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: RESPONSE_SENT - stamp: - sec: 1713998176 - nanosec: 373016882 - client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [] - response: [{sum: 5}] - -.. _record-play-data-action: - -Managing Action Data --------------------- - -1 Setup -^^^^^^^ - -You'll be recording action data between ``fibonacci_action_client`` and ``fibonacci_action_server``, then display and replay that same data later on. -To record action data between action client and server, ``Action Introspection`` must be enabled on the nodes. - -Let's start ``fibonacci_action_client`` and ``fibonacci_action_server`` nodes and enable ``Action Introspection``. -You can see more details for :doc:`Action Introspection Demo <../../Demos/Action-Introspection>`. - -Open a new terminal and run ``fibonacci_action_server``, enabling ``Action Introspection``: - -.. code-block:: console - - $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents - -Open another terminal and run ``fibonacci_action_client``, enabling ``Action Introspection``: - -.. code-block:: console - - $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents - -2 Check action availability -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``ros2 bag`` can only record data from available actions. -To see the list of your system's actions, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 action list - /fibonacci - -To check if ``Action Introspection`` is enabled on the action, run the command: - -.. code-block:: console - - $ ros2 action echo --flow-style /fibonacci - interface: GOAL_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1744917904 - nanosec: 760683446 - client_gid: [1, 15, 165, 231, 234, 109, 65, 202, 0, 0, 0, 0, 0, 0, 19, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [81, 55, 121, 145, 81, 66, 209, 93, 214, 113, 255, 100, 120, 6, 102, 83]}, goal: {order: 10}}] - response: [] - --- - ... - -3 Record actions -^^^^^^^^^^^^^^^^ - -To record action data, the following options are supported. -Action data can be recorded with topics and services at the same time. - -To record specific actions: - -.. code-block:: console - - $ ros2 bag record --action - -To record all actions: - -.. code-block:: console - - $ ros2 bag record --all-actions - -Run the command: - -.. code-block:: console - - $ ros2 bag record --action /fibonacci - [INFO] [1744953225.214114862] [rosbag2_recorder]: Press SPACE for pausing/resuming - [INFO] [1744953225.218369761] [rosbag2_recorder]: Listening for topics... - [INFO] [1744953225.218386223] [rosbag2_recorder]: Event publisher thread: Starting - [INFO] [1744953225.218580294] [rosbag2_recorder]: Recording... - [INFO] [1744953225.725417634] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/cancel_goal/_service_event' - [INFO] [1744953225.727901848] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/feedback' - [INFO] [1744953225.729655213] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/get_result/_service_event' - [INFO] [1744953225.731315612] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/send_goal/_service_event' - [INFO] [1744953225.735061252] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/status' - ... - -Now ``ros2 bag`` is recording the action data for the ``/fibonacci`` action: goal, result, and feedback. -To stop the recording, enter :kbd:`Ctrl-C` in the terminal. - -The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. -This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. - -4 Inspect action data -^^^^^^^^^^^^^^^^^^^^^ - -You can see details about your recording by running: - -.. code-block:: console - - $ ros2 bag info - Files: rosbag2_2025_04_17-22_20_40_0.mcap - Bag size: 20.7 KiB - Storage id: mcap - ROS Distro: rolling - Duration: 9.019568080s - Start: Apr 17 2025 22:20:47.263125070 (1744953647.263125070) - End: Apr 17 2025 22:20:56.282693150 (1744953656.282693150) - Messages: 0 - Topic information: - Services: 0 - Service information: - Actions: 1 - Action information: - Action: /fibonacci | Type: example_interfaces/action/Fibonacci | Topics: 2 | Service: 3 | Serialization Format: cdr - Topic: feedback | Count: 9 - Topic: status | Count: 3 - Service: send_goal | Event Count: 4 - Service: cancel_goal | Event Count: 0 - Service: get_result | Event Count: 4 - -5 Play action data -^^^^^^^^^^^^^^^^^^ - -Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``fibonacci_action_client`` is running. -When ``fibonacci_action_client`` stops running, ``fibonacci_action_server`` also stops printing the result because there are no incoming requests. - -Replaying the action data from the bag file will start sending the requests to ``fibonacci_action_server``. - -Enter the command: - -.. code-block:: console - - $ ros2 bag play --send-actions-as-client - [INFO] [1744953720.691068674] [rosbag2_player]: Set rate to 1 - [INFO] [1744953720.702365209] [rosbag2_player]: Adding keyboard callbacks. - [INFO] [1744953720.702409447] [rosbag2_player]: Press SPACE for Pause/Resume - [INFO] [1744953720.702423063] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message - [INFO] [1744953720.702431404] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% - [INFO] [1744953720.702437677] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% - Progress bar enabled at 3 Hz. - Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped - [INFO] [1744953720.702577680] [rosbag2_player]: Playback until timestamp: -1 - - - ====== Playback Progress ====== - [1744953656.281683207] Duration 9.02/9.02 [R] - -Your ``fibonacci_action_server`` terminal will once again start printing the following service messages: - -.. code-block:: console - - [INFO] [1744953720.815577088] [fibonacci_action_server]: Executing goal... - [INFO] [1744953720.815927050] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1]) - [INFO] [1744953721.816509658] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2]) - [INFO] [1744953722.817220270] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3]) - [INFO] [1744953723.817876426] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5]) - [INFO] [1744953724.818498515] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8]) - [INFO] [1744953725.819182228] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13]) - [INFO] [1744953726.820032562] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21]) - [INFO] [1744953727.820738690] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]) - [INFO] [1744953728.821449308] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]) - -This is because ``ros2 bag play`` sends the action goal request data from the bag file to the ``/fibonacci`` action. - -We can also introspect action communication as ``ros2 bag play`` is playing it back to verify the ``fibonacci_action_server``. - -Run this command before ``ros2 bag play`` to see the ``fibonacci_action_server``. -You can see the action goal request from the bag file and the service response from ``fibonacci_action_server``: - -.. code-block:: console - - $ ros2 action echo --flow-style /fibonacci - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [34, 116, 225, 217, 48, 121, 146, 36, 240, 98, 99, 134, 55, 227, 184, 72]}, stamp: {sec: 1744953720, nanosec: 804984321}}, status: 4}] - --- - interface: GOAL_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1744953927 - nanosec: 957359210 - client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, goal: {order: 10}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: RESPONSE_SENT - stamp: - sec: 1744953927 - nanosec: 957726145 - client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] - sequence_number: 1 - request: [] - response: [{accepted: true, stamp: {sec: 1744953927, nanosec: 957615866}}] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, stamp: {sec: 1744953927, nanosec: 957663383}}, status: 2}] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12] - feedback: - sequence: [0, 1, 1] - --- - ... - -Summary -------- - -You can record data passed on topics, services and actions in your ROS 2 system using the ``ros2 bag`` command. -Whether you're sharing your work with others or introspecting your own experiments, it's a great tool to know about. - -Next steps ----------- - -You've completed the "Beginner: CLI Tools" tutorials! -The next step is tackling the "Beginner: Client Libraries" tutorials, starting with :doc:`../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`. - -Related content ---------------- - -A more thorough explanation of ``ros2 bag`` can be found in the README `here `__. -For more information on service recording and playback can be found in the design document `here `__. -For more information on action recording and playback can be found in the design document `here `__. -For more information on QoS compatibility and ``ros2 bag``, see :doc:`../../../How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback`. +.. redirect-from:: + + Tutorials/Ros2bag/Recording-And-Playing-Back-Data + Tutorials/Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data + +.. _ROS2Bag: + +Recording and playing back data +=============================== + +**Goal:** Record data published on a topic, a service and an action so you can replay and examine it any time. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``ros2 bag`` is a command line tool for recording data published on topics, services and actions in your ROS 2 system. +It accumulates the data passed on any number of topics, services and actions, then saves it in a database. +You can then replay the data to reproduce the results of your tests and experiments. +Recording topics, services and actions is also a great way to share your work and allow others to recreate it. + + +Prerequisites +------------- + +You should have ``ros2 bag`` installed as a part of your regular ROS 2 setup. + +If you need to install ROS 2, see the :doc:`Installation instructions <../../../../Get-Started/Installation>`. + +This tutorial talks about concepts covered in previous tutorials, like :doc:`nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>` and :doc:`actions <../../../actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. +It also uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`, :doc:`Service Introspection Demo <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>` and :doc:`Action Introspection Demo <../../../actions/Working-with-actions/Action-Introspection>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + + +Managing Topic Data +------------------- + +1 Setup +^^^^^^^ + +You'll be recording your keyboard input in the ``turtlesim`` system to save and replay later on, so begin by starting up the ``/turtlesim`` and ``/teleop_turtle`` nodes. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Let's also make a new directory to store our saved recordings, just as good practice: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir bag_files + $ cd bag_files + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir bag_files + $ cd bag_files + + .. group-tab:: Windows + + .. code-block:: console + + $ md bag_files + $ cd bag_files + + +2 Choose a topic +^^^^^^^^^^^^^^^^ + +``ros2 bag`` can record data from messages published to topics. +To see the list of your system's topics, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 topic list + /parameter_events + /rosout + /turtle1/cmd_vel + /turtle1/color_sensor + /turtle1/pose + +In the topics tutorial, you learned that the ``/turtle_teleop`` node publishes commands on the ``/turtle1/cmd_vel`` topic to make the turtle move in turtlesim. + +To see the data that ``/turtle1/cmd_vel`` is publishing, run the command: + +.. code-block:: console + + $ ros2 topic echo /turtle1/cmd_vel + +Nothing will show up at first because no data is being published by the teleop. +Return to the terminal where you ran the teleop and select it so it's active. +Use the arrow keys to move the turtle around, and you will see data being published on the terminal running ``ros2 topic echo``. + +.. code-block:: console + + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + + +3 Record topics +^^^^^^^^^^^^^^^ + +3.1 Record a single topic +~~~~~~~~~~~~~~~~~~~~~~~~~ + +To record the data published to a topic use the command syntax: + +.. code-block:: console + + $ ros2 bag record --topics + +Before running this command on your chosen topic, open a new terminal and move into the ``bag_files`` directory you created earlier, because the rosbag file will save in the directory where you run it. + +Run the command: + +.. code-block:: console + + $ ros2 bag record --topics /turtle1/cmd_vel + [INFO] [rosbag2_storage]: Opened database 'rosbag2_2019_10_11-05_18_45'. + [INFO] [rosbag2_transport]: Listening for topics... + [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' + [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... + +Now ``ros2 bag`` is recording the data published on the ``/turtle1/cmd_vel`` topic. +Return to the teleop terminal and move the turtle around again. +The movements don't matter, but try to make a recognizable pattern to see when you replay the data later. + +.. image:: images/record.png + +Press :kbd:`Ctrl-C` to stop recording. + +The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. +This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. + +3.2 Record multiple topics +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also record multiple topics, as well as change the name of the bag directory ``ros2 bag`` saves to. + +Run the following command: + +.. code-block:: console + + $ ros2 bag record -o subset --topics /turtle1/cmd_vel /turtle1/pose + [INFO] [rosbag2_storage]: Opened database 'subset'. + [INFO] [rosbag2_transport]: Listening for topics... + [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' + [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/pose' + [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... + +The ``-o`` option allows you to choose a unique name for your bag directory. +The following string, in this case ``subset``, is the bag directory name. + +To record more than one topic at a time, simply list each topic separated by a space after ``--topics``. +In this case, the command output above confirms that both topics are being recorded. + +You can move the turtle around and press :kbd:`Ctrl-C` when you're finished. + +.. note:: + + There is another option you can add to the command, ``-a``, which records all the topics on your system. + +3.3 Split recording into multiple files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also split your recording into multiple files, based on either recording duration or file size. +``-d `` ensures that each file only lasts ```` seconds before it starts writing to a new file, or ``-b `` ensures that each file does not exceed ```` bytes in file size. +This prevents large and unwieldy file sizes, and protects against losing all data if the recording operation becomes corrupted at some point. + +Run the following for at least 15 seconds, allowing for three 5-second bag files to be written: + +.. code-block:: console + + $ ros2 bag record -o subset_split -d 5 --topics /turtle1/cmd_vel /turtle1/pose + [INFO] [rosbag2_recorder]: Press SPACE for pausing/resuming + [INFO] [rosbag2_recorder]: Listening for topics... + [INFO] [rosbag2_recorder]: Event publisher thread: Starting + [INFO] [rosbag2_recorder]: Recording... + [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/cmd_vel' + [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/pose' + [INFO] [rosbag2_recorder]: All requested topics are subscribed. Stopping discovery... + [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while + [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while + [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while + +Press :kbd:`Ctrl-C` when you're finished. +You should find a ``subset_split`` directory with these files inside: ``0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, ``1_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and so on. + +4 Inspect topic data +^^^^^^^^^^^^^^^^^^^^ + +You can see details about your recording by running: + +.. code-block:: console + + $ ros2 bag info + +Running this command on the ``subset`` bag recording will return a list of information: + +.. code-block:: console + + $ ros2 bag info subset + Files: subset_0.mcap + Bag size: 228.5 KiB + Storage id: mcap + ROS Distro: rolling + Duration: 48.47s + Start: Oct 11 2019 06:09:09.12 (1570799349.12) + End Oct 11 2019 06:09:57.60 (1570799397.60) + Messages: 3013 + Topic information: Topic: /turtle1/cmd_vel | Type: geometry_msgs/msg/Twist | Count: 9 | Serialization Format: cdr + Topic: /turtle1/pose | Type: turtlesim_msgs/msg/Pose | Count: 3004 | Serialization Format: cdr + Services: 0 + Service information: + Actions: 0 + Action information: + +Alternatively, you can also call ``ros2 bag info`` on an individual file, such as ``subset_split/0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and it will only show information for that portion of the recording; in this case, the first 5 seconds. + +5 Play topic data +^^^^^^^^^^^^^^^^^ + +5.1 Play a single bag +~~~~~~~~~~~~~~~~~~~~~ + +Before replaying the bag, enter :kbd:`Ctrl-C` in the terminal where the teleop is running. +Then make sure your turtlesim window is visible so you can see the bag file in action. + +Enter the command: + +.. code-block:: console + + $ ros2 bag play subset + [INFO] [rosbag2_player]: Set rate to 1 + [INFO] [rosbag2_player]: Adding keyboard callbacks. + [INFO] [rosbag2_player]: Press SPACE for Pause/Resume + [INFO] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message + [INFO] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% + [INFO] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% + Progress bar enabled at 3 Hz. + Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped + [INFO] [rosbag2_player]: Playback until timestamp: -1 + + + ====== Playback Progress ====== + [1751923361.427372456] Duration 0.00/48.47 [R] + +Your turtle will follow the same path you entered while recording (though not 100% exactly; turtlesim is sensitive to small changes in the system's timing). + +.. image:: images/playback.png + +Because the ``subset`` file recorded the ``/turtle1/pose`` topic, the ``ros2 bag play`` command won't quit for as long as you had turtlesim running, even if you weren't moving. + +This is because as long as the ``/turtlesim`` node is active, it publishes data on the ``/turtle1/pose`` topic at regular intervals. +You may have noticed in the ``ros2 bag info`` example result above that the ``/turtle1/cmd_vel`` topic's ``Count`` information was only 9; that's how many times we pressed the arrow keys while recording. + +Notice that ``/turtle1/pose`` has a ``Count`` value of over 3000; while we were recording, data was published on that topic 3000 times. + +To get an idea of how often position data is published, you can run the command: + +.. code-block:: console + + $ ros2 topic hz /turtle1/pose + +5.2 Play multiple bags +~~~~~~~~~~~~~~~~~~~~~~ + +At times, it is relevant to split the desired recorded topics amongst multiple recordings, as a way to distribute the recording workload. +As an example, we can record ``/turtle1/cmd_vel`` and ``/turtle1/pose`` each to their own bag. + +Create two terminal instances. +In the first one, run the following: + +.. code-block:: console + + $ ros2 bag record -o subset_cmd_vel --topics /turtle1/cmd_vel + +In the second terminal, run this: + +.. code-block:: console + + $ ros2 bag record -o subset_pose --topics /turtle1/pose + +Move the turtle around as you did before, then end both recordings with :kbd:`Ctrl-C` when finished. + +To have these two recordings play in parallel with correct timing, call ``ros2 bag play`` with ``-i `` for each bag you want to include. +In this case, run: + +.. code-block:: console + + $ ros2 bag play -i subset_cmd_vel -i subset_pose + +This will play the ``subset_cmd_vel`` and ``subset_pose`` recordings together, with the playback synced to replicate the original order of messages. +If used, the optional argument ``--message-order {received,sent}`` determines whether the messages are sequenced according to the time they were received or published (defaults to received). +This applies to playing a single bag as well. + +Managing Service Data +--------------------- + +1 Setup +^^^^^^^ + +You'll be recording service data between ``introspection_client`` and ``introspection_service``, then display and replay that same data later on. +To record service data between service client and server, ``Service Introspection`` must be enabled on the node. + +Let's start ``introspection_client`` and ``introspection_service`` nodes and enable ``Service Introspection``. +You can see more details for :doc:`Service Introspection Demo <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>`. + +Open a new terminal and run ``introspection_service``, enabling ``Service Introspection``: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp introspection_service --ros-args -p service_configure_introspection:=contents + +Open another terminal and run ``introspection_client``, enabling ``Service Introspection``: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp introspection_client --ros-args -p client_configure_introspection:=contents + +2 Check service availability +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``ros2 bag`` can only record data from available services. +To see the list of your system's services, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 service list + /add_two_ints + /introspection_client/describe_parameters + /introspection_client/get_parameter_types + /introspection_client/get_parameters + /introspection_client/get_type_description + /introspection_client/list_parameters + /introspection_client/set_parameters + /introspection_client/set_parameters_atomically + /introspection_service/describe_parameters + /introspection_service/get_parameter_types + /introspection_service/get_parameters + /introspection_service/get_type_description + /introspection_service/list_parameters + /introspection_service/set_parameters + /introspection_service/set_parameters_atomically + +To check if ``Service Introspection`` is enabled on the client and service, run the command: + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + info: + event_type: REQUEST_SENT + stamp: + sec: 1713995389 + nanosec: 386809259 + client_gid: [1, 15, 96, 219, 162, 1, 108, 201, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 133 + request: [{a: 2, b: 3}] + response: [] + --- + +You should see the service communication. + +3 Record services +^^^^^^^^^^^^^^^^^ + +To record service data, the following options are supported. +Service data can be recorded with topics at the same time. + +To record specific services: + +.. code-block:: console + + $ ros2 bag record --service + +To record all services: + +.. code-block:: console + + $ ros2 bag record --all-services + +Run the command: + +.. code-block:: console + + $ ros2 bag record --service /add_two_ints + [INFO] [1713995957.643573503] [rosbag2_recorder]: Press SPACE for pausing/resuming + [INFO] [1713995957.662067587] [rosbag2_recorder]: Event publisher thread: Starting + [INFO] [1713995957.662067614] [rosbag2_recorder]: Listening for topics... + [INFO] [1713995957.666048323] [rosbag2_recorder]: Subscribed to topic '/add_two_ints/_service_event' + [INFO] [1713995957.666092458] [rosbag2_recorder]: Recording... + +Now ``ros2 bag`` is recording the service data published on the ``/add_two_ints`` service. +To stop the recording, enter :kbd:`Ctrl-C` in the terminal. + +The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. +This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. + +4 Inspect service data +^^^^^^^^^^^^^^^^^^^^^^ + +You can see details about your recording by running: + +.. code-block:: console + + $ ros2 bag info + Files: rosbag2_2024_04_24-14_59_17_0.mcap + Bag size: 15.1 KiB + Storage id: mcap + ROS Distro: rolling + Duration: 9.211s + Start: Apr 24 2024 14:59:17.676 (1713995957.676) + End: Apr 24 2024 14:59:26.888 (1713995966.888) + Messages: 0 + Topic information: + Service: 1 + Service information: Service: /add_two_ints | Type: example_interfaces/srv/AddTwoInts | Event Count: 78 | Serialization Format: cdr + +5 Play service data +^^^^^^^^^^^^^^^^^^^ + +Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``introspection_client`` is running. +When ``introspection_client`` stops running, ``introspection_service`` also stops printing the result because there are no incoming requests. + +Replaying the service data from the bag file will start sending the requests to ``introspection_service``. + +Enter the command: + +.. code-block:: console + + $ ros2 bag play --publish-service-requests + [INFO] [1713997477.870856190] [rosbag2_player]: Set rate to 1 + [INFO] [1713997477.877417477] [rosbag2_player]: Adding keyboard callbacks. + [INFO] [1713997477.877442404] [rosbag2_player]: Press SPACE for Pause/Resume + [INFO] [1713997477.877447855] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message + [INFO] [1713997477.877452655] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% + [INFO] [1713997477.877456954] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% + [INFO] [1713997477.877573647] [rosbag2_player]: Playback until timestamp: -1 + +Your ``introspection_service`` terminal will once again start printing the following service messages: + +.. code-block:: console + + [INFO] [1713997478.090466075] [introspection_service]: Incoming request + a: 2 b: 3 + +This is because ``ros2 bag play`` sends the service request data from the bag file to the ``/add_two_ints`` service. + +We can also introspect service communication as ``ros2 bag play`` is playing it back to verify the ``introspection_service``. + +Run this command before ``ros2 bag play`` to see the ``introspection_service``: + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + +You can see the service request from the bag file and the service response from ``introspection_service``. + +.. code-block:: console + + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1713998176 + nanosec: 372700698 + client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: RESPONSE_SENT + stamp: + sec: 1713998176 + nanosec: 373016882 + client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [] + response: [{sum: 5}] + +.. _record-play-data-action: + +Managing Action Data +-------------------- + +1 Setup +^^^^^^^ + +You'll be recording action data between ``fibonacci_action_client`` and ``fibonacci_action_server``, then display and replay that same data later on. +To record action data between action client and server, ``Action Introspection`` must be enabled on the nodes. + +Let's start ``fibonacci_action_client`` and ``fibonacci_action_server`` nodes and enable ``Action Introspection``. +You can see more details for :doc:`Action Introspection Demo <../../../actions/Working-with-actions/Action-Introspection>`. + +Open a new terminal and run ``fibonacci_action_server``, enabling ``Action Introspection``: + +.. code-block:: console + + $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents + +Open another terminal and run ``fibonacci_action_client``, enabling ``Action Introspection``: + +.. code-block:: console + + $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents + +2 Check action availability +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``ros2 bag`` can only record data from available actions. +To see the list of your system's actions, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 action list + /fibonacci + +To check if ``Action Introspection`` is enabled on the action, run the command: + +.. code-block:: console + + $ ros2 action echo --flow-style /fibonacci + interface: GOAL_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1744917904 + nanosec: 760683446 + client_gid: [1, 15, 165, 231, 234, 109, 65, 202, 0, 0, 0, 0, 0, 0, 19, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [81, 55, 121, 145, 81, 66, 209, 93, 214, 113, 255, 100, 120, 6, 102, 83]}, goal: {order: 10}}] + response: [] + --- + ... + +3 Record actions +^^^^^^^^^^^^^^^^ + +To record action data, the following options are supported. +Action data can be recorded with topics and services at the same time. + +To record specific actions: + +.. code-block:: console + + $ ros2 bag record --action + +To record all actions: + +.. code-block:: console + + $ ros2 bag record --all-actions + +Run the command: + +.. code-block:: console + + $ ros2 bag record --action /fibonacci + [INFO] [1744953225.214114862] [rosbag2_recorder]: Press SPACE for pausing/resuming + [INFO] [1744953225.218369761] [rosbag2_recorder]: Listening for topics... + [INFO] [1744953225.218386223] [rosbag2_recorder]: Event publisher thread: Starting + [INFO] [1744953225.218580294] [rosbag2_recorder]: Recording... + [INFO] [1744953225.725417634] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/cancel_goal/_service_event' + [INFO] [1744953225.727901848] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/feedback' + [INFO] [1744953225.729655213] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/get_result/_service_event' + [INFO] [1744953225.731315612] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/send_goal/_service_event' + [INFO] [1744953225.735061252] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/status' + ... + +Now ``ros2 bag`` is recording the action data for the ``/fibonacci`` action: goal, result, and feedback. +To stop the recording, enter :kbd:`Ctrl-C` in the terminal. + +The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. +This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. + +4 Inspect action data +^^^^^^^^^^^^^^^^^^^^^ + +You can see details about your recording by running: + +.. code-block:: console + + $ ros2 bag info + Files: rosbag2_2025_04_17-22_20_40_0.mcap + Bag size: 20.7 KiB + Storage id: mcap + ROS Distro: rolling + Duration: 9.019568080s + Start: Apr 17 2025 22:20:47.263125070 (1744953647.263125070) + End: Apr 17 2025 22:20:56.282693150 (1744953656.282693150) + Messages: 0 + Topic information: + Services: 0 + Service information: + Actions: 1 + Action information: + Action: /fibonacci | Type: example_interfaces/action/Fibonacci | Topics: 2 | Service: 3 | Serialization Format: cdr + Topic: feedback | Count: 9 + Topic: status | Count: 3 + Service: send_goal | Event Count: 4 + Service: cancel_goal | Event Count: 0 + Service: get_result | Event Count: 4 + +5 Play action data +^^^^^^^^^^^^^^^^^^ + +Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``fibonacci_action_client`` is running. +When ``fibonacci_action_client`` stops running, ``fibonacci_action_server`` also stops printing the result because there are no incoming requests. + +Replaying the action data from the bag file will start sending the requests to ``fibonacci_action_server``. + +Enter the command: + +.. code-block:: console + + $ ros2 bag play --send-actions-as-client + [INFO] [1744953720.691068674] [rosbag2_player]: Set rate to 1 + [INFO] [1744953720.702365209] [rosbag2_player]: Adding keyboard callbacks. + [INFO] [1744953720.702409447] [rosbag2_player]: Press SPACE for Pause/Resume + [INFO] [1744953720.702423063] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message + [INFO] [1744953720.702431404] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% + [INFO] [1744953720.702437677] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% + Progress bar enabled at 3 Hz. + Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped + [INFO] [1744953720.702577680] [rosbag2_player]: Playback until timestamp: -1 + + + ====== Playback Progress ====== + [1744953656.281683207] Duration 9.02/9.02 [R] + +Your ``fibonacci_action_server`` terminal will once again start printing the following service messages: + +.. code-block:: console + + [INFO] [1744953720.815577088] [fibonacci_action_server]: Executing goal... + [INFO] [1744953720.815927050] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1]) + [INFO] [1744953721.816509658] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2]) + [INFO] [1744953722.817220270] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3]) + [INFO] [1744953723.817876426] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5]) + [INFO] [1744953724.818498515] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8]) + [INFO] [1744953725.819182228] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13]) + [INFO] [1744953726.820032562] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21]) + [INFO] [1744953727.820738690] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]) + [INFO] [1744953728.821449308] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]) + +This is because ``ros2 bag play`` sends the action goal request data from the bag file to the ``/fibonacci`` action. + +We can also introspect action communication as ``ros2 bag play`` is playing it back to verify the ``fibonacci_action_server``. + +Run this command before ``ros2 bag play`` to see the ``fibonacci_action_server``. +You can see the action goal request from the bag file and the service response from ``fibonacci_action_server``: + +.. code-block:: console + + $ ros2 action echo --flow-style /fibonacci + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [34, 116, 225, 217, 48, 121, 146, 36, 240, 98, 99, 134, 55, 227, 184, 72]}, stamp: {sec: 1744953720, nanosec: 804984321}}, status: 4}] + --- + interface: GOAL_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1744953927 + nanosec: 957359210 + client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, goal: {order: 10}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: RESPONSE_SENT + stamp: + sec: 1744953927 + nanosec: 957726145 + client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] + sequence_number: 1 + request: [] + response: [{accepted: true, stamp: {sec: 1744953927, nanosec: 957615866}}] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, stamp: {sec: 1744953927, nanosec: 957663383}}, status: 2}] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12] + feedback: + sequence: [0, 1, 1] + --- + ... + +Summary +------- + +You can record data passed on topics, services and actions in your ROS 2 system using the ``ros2 bag`` command. +Whether you're sharing your work with others or introspecting your own experiments, it's a great tool to know about. + +Next steps +---------- + +You've completed the "Beginner: CLI Tools" tutorials! +The next step is tackling the "Beginner: Client Libraries" tutorials, starting with :doc:`../../../client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`. + +Related content +--------------- + +A more thorough explanation of ``ros2 bag`` can be found in the README `here `__. +For more information on service recording and playback can be found in the design document `here `__. +For more information on action recording and playback can be found in the design document `here `__. +For more information on QoS compatibility and ``ros2 bag``, see :doc:`../../../../Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback`. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/About-Composition.rst b/source/ROS-Framework/nodes/About-Composition.rst index 97e68beb8e1..7e56e0d063b 100644 --- a/source/ROS-Framework/nodes/About-Composition.rst +++ b/source/ROS-Framework/nodes/About-Composition.rst @@ -1,137 +1,138 @@ -.. redirect-from:: - - Concepts/About-Composition - -Composition -=========== - -.. contents:: Table of Contents - :local: - -ROS 1 - Nodes vs. Nodelets --------------------------- - -In ROS 1 you can write your code either as a `ROS node `__ or as a `ROS nodelet `__. -ROS 1 nodes are compiled into executables. -ROS 1 nodelets on the other hand are compiled into a shared library which is then loaded at runtime by a container process. - -ROS 2 - Unified API -------------------- - -In ROS 2 the recommended way of writing your code is similar to a nodelet - we call it a ``Component``. -This makes it easy to add common concepts to existing code, like a `life cycle `__. -Having different APIs, which was the biggest drawback in ROS 1, is avoided in ROS 2 since both approaches use the same API. - -.. note:: - - It is still possible to use the node-like style of "writing your own main" but for the common case it is not recommended. - -By making the process layout a deploy-time decision the user can choose between: - -* running multiple nodes in separate processes with the benefits of process/fault isolation as well as easier debugging of individual nodes and -* running multiple nodes in a single process with the lower overhead and optionally more efficient communication (see :doc:`Intra Process Communication <../../Tutorials/Demos/Intra-Process-Communication>`). - -Additionally ``ros2 launch`` can be used to automate these actions through specialized launch actions. - -.. _ComponentContainer: - -Component Container -------------------- - -A component container is a host process that allows you to load and manage multiple components at runtime within the same process space. - -As of now, the following generic component container types are available: - -* ``component_container`` - - * Component container that uses a single ``SingleThreadedExecutor`` to execute the components. - -* ``component_container --executor-type multi-threaded`` - - * Component container that uses a single ``MultiThreadedExecutor`` to execute the components. - -* ``component_container --executor-type events-cbg`` - - * Component container that uses a single ``EventsCBGExecutor`` to execute the components. - -* ``component_container --executor-type single-threaded --isolated`` - - * Component container that uses a dedicated executor for each component: available options are ``SingleThreadedExecutor`` (default), ``MultiThreadedExecutor``, and ``EventsCBGExecutor``. - -For both isolated and non-isolated component containers using the ``MultiThreadedExecutor`` or ``EventsCBGExecutor``, the number of event processing threads can be configured via the ROS parameter ``thread_num``. -In isolated mode, every dedicated executor will be created with ``thread_num`` threads. - -For more information about the types of executors, see the :ref:`TypesOfExecutors`. -For more information about the options of each component container, see :ref:`ComponentContainerTypes` in the composition tutorial. - -Writing a Component -------------------- - -Since a component is only built into a shared library, it doesn't have a ``main`` function (see `Talker source code `__). -A component is commonly a subclass of ``rclcpp::Node``. -Since it is not in control of the thread, it shouldn't perform any long running or blocking tasks in its constructor. -Instead, it can use timers to get periodic notifications. -Additionally, it can create publishers, subscriptions, servers, and clients. - -An important aspect of making such a class a component is that the class registers itself using macros from the package ``rclcpp_components`` (see the last line in the source code). -This makes the component discoverable when its library is being loaded into a running process - it acts as kind of an entry point. - -Additionally, once a component is created, it must be registered with the index to be discoverable by the tooling. - -.. code-block:: cmake - - add_library(talker_component SHARED src/talker_component.cpp) - rclcpp_components_register_nodes(talker_component "composition::Talker") - # To register multiple components in the same shared library, use multiple calls - # rclcpp_components_register_nodes(talker_component "composition::Talker2") - -For an example, :doc:`check out this tutorial <../../Tutorials/Intermediate/Writing-a-Composable-Node>` - -.. note:: - - In order for the component_container to be able to find desired components, it must be executed or launched from a shell that has sourced the corresponding workspace. - -CMake Registration Macros -------------------------- - -ROS 2 provides two CMake macros for registering components, each serving a different purpose: - -``rclcpp_components_register_node`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This macro registers a component and generates a standalone executable. -Use this when you want both composability and the ability to run the node as a standalone process. - -.. code-block:: cmake - - add_library(talker_component SHARED src/talker_component.cpp) - rclcpp_components_register_node(talker_component - PLUGIN "composition::Talker" - EXECUTABLE talker) - -``rclcpp_components_register_nodes`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This macro registers one or more components for runtime composition **without** creating standalone executables. -Use this when you want pure component libraries that will be loaded into component containers at runtime. - -.. code-block:: cmake - - add_library(talker_component SHARED src/talker_component.cpp) - rclcpp_components_register_nodes(talker_component "composition::Talker") - -Using Components ----------------- - -The `composition `__ package contains a couple of different approaches on how to use components. -The three most common ones are: - -#. Start a (`generic container process `__) and call the ROS service `load_node `__ offered by the container. - The ROS service will then load the component specified by the passed package name and library name and start executing it within the running process. - Instead of calling the ROS service programmatically you can also use a `command line tool `__ to invoke the ROS service with the passed command line arguments -#. Create a `custom executable `__ containing multiple nodes which are known at compile time. - This approach requires that each component has a header file (which is not strictly needed for the first case). -#. Create a launch file and use ``ros2 launch`` to create a container process with multiple components loaded. - -Practical application ---------------------- - -Try the :doc:`Composition demos <../../Tutorials/Intermediate/Composition>`. +.. redirect-from:: + + Concepts/About-Composition + Concepts/Intermediate/About-Composition + +Composition +=========== + +.. contents:: Table of Contents + :local: + +ROS 1 - Nodes vs. Nodelets +-------------------------- + +In ROS 1 you can write your code either as a `ROS node `__ or as a `ROS nodelet `__. +ROS 1 nodes are compiled into executables. +ROS 1 nodelets on the other hand are compiled into a shared library which is then loaded at runtime by a container process. + +ROS 2 - Unified API +------------------- + +In ROS 2 the recommended way of writing your code is similar to a nodelet - we call it a ``Component``. +This makes it easy to add common concepts to existing code, like a `life cycle `__. +Having different APIs, which was the biggest drawback in ROS 1, is avoided in ROS 2 since both approaches use the same API. + +.. note:: + + It is still possible to use the node-like style of "writing your own main" but for the common case it is not recommended. + +By making the process layout a deploy-time decision the user can choose between: + +* running multiple nodes in separate processes with the benefits of process/fault isolation as well as easier debugging of individual nodes and +* running multiple nodes in a single process with the lower overhead and optionally more efficient communication (see :doc:`Intra Process Communication `). + +Additionally ``ros2 launch`` can be used to automate these actions through specialized launch actions. + +.. _ComponentContainer: + +Component Container +------------------- + +A component container is a host process that allows you to load and manage multiple components at runtime within the same process space. + +As of now, the following generic component container types are available: + +* ``component_container`` + + * Component container that uses a single ``SingleThreadedExecutor`` to execute the components. + +* ``component_container --executor-type multi-threaded`` + + * Component container that uses a single ``MultiThreadedExecutor`` to execute the components. + +* ``component_container --executor-type events-cbg`` + + * Component container that uses a single ``EventsCBGExecutor`` to execute the components. + +* ``component_container --executor-type single-threaded --isolated`` + + * Component container that uses a dedicated executor for each component: available options are ``SingleThreadedExecutor`` (default), ``MultiThreadedExecutor``, and ``EventsCBGExecutor``. + +For both isolated and non-isolated component containers using the ``MultiThreadedExecutor`` or ``EventsCBGExecutor``, the number of event processing threads can be configured via the ROS parameter ``thread_num``. +In isolated mode, every dedicated executor will be created with ``thread_num`` threads. + +For more information about the types of executors, see the :ref:`TypesOfExecutors`. +For more information about the options of each component container, see :ref:`ComponentContainerTypes` in the composition tutorial. + +Writing a Component +------------------- + +Since a component is only built into a shared library, it doesn't have a ``main`` function (see `Talker source code `__). +A component is commonly a subclass of ``rclcpp::Node``. +Since it is not in control of the thread, it shouldn't perform any long running or blocking tasks in its constructor. +Instead, it can use timers to get periodic notifications. +Additionally, it can create publishers, subscriptions, servers, and clients. + +An important aspect of making such a class a component is that the class registers itself using macros from the package ``rclcpp_components`` (see the last line in the source code). +This makes the component discoverable when its library is being loaded into a running process - it acts as kind of an entry point. + +Additionally, once a component is created, it must be registered with the index to be discoverable by the tooling. + +.. code-block:: cmake + + add_library(talker_component SHARED src/talker_component.cpp) + rclcpp_components_register_nodes(talker_component "composition::Talker") + # To register multiple components in the same shared library, use multiple calls + # rclcpp_components_register_nodes(talker_component "composition::Talker2") + +For an example, :doc:`check out this tutorial ` + +.. note:: + + In order for the component_container to be able to find desired components, it must be executed or launched from a shell that has sourced the corresponding workspace. + +CMake Registration Macros +------------------------- + +ROS 2 provides two CMake macros for registering components, each serving a different purpose: + +``rclcpp_components_register_node`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +This macro registers a component and generates a standalone executable. +Use this when you want both composability and the ability to run the node as a standalone process. + +.. code-block:: cmake + + add_library(talker_component SHARED src/talker_component.cpp) + rclcpp_components_register_node(talker_component + PLUGIN "composition::Talker" + EXECUTABLE talker) + +``rclcpp_components_register_nodes`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +This macro registers one or more components for runtime composition **without** creating standalone executables. +Use this when you want pure component libraries that will be loaded into component containers at runtime. + +.. code-block:: cmake + + add_library(talker_component SHARED src/talker_component.cpp) + rclcpp_components_register_nodes(talker_component "composition::Talker") + +Using Components +---------------- + +The `composition `__ package contains a couple of different approaches on how to use components. +The three most common ones are: + +#. Start a (`generic container process `__) and call the ROS service `load_node `__ offered by the container. + The ROS service will then load the component specified by the passed package name and library name and start executing it within the running process. + Instead of calling the ROS service programmatically you can also use a `command line tool `__ to invoke the ROS service with the passed command line arguments +#. Create a `custom executable `__ containing multiple nodes which are known at compile time. + This approach requires that each component has a header file (which is not strictly needed for the first case). +#. Create a launch file and use ``ros2 launch`` to create a container process with multiple components loaded. + +Practical application +--------------------- + +Try the :doc:`Composition demos `. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/About-Discovery.rst b/source/ROS-Framework/nodes/About-Discovery.rst index 0d5a0cda2f2..78f50e34157 100644 --- a/source/ROS-Framework/nodes/About-Discovery.rst +++ b/source/ROS-Framework/nodes/About-Discovery.rst @@ -1,21 +1,25 @@ -Discovery -========= - -.. contents:: Table of Contents - :local: - -Discovery of nodes happens automatically through the underlying middleware of ROS 2. -It can be summarized as follows: - -#. When a node is started, it advertises its presence to other nodes on the network with the same ROS domain (set with the ROS_DOMAIN_ID environment variable). - Nodes respond to this advertisement with information about themselves so that the appropriate connections can be made and the nodes can communicate. -#. Nodes periodically advertise their presence so that connections can be made with new-found entities, even after the initial discovery period. -#. Nodes advertise to other nodes when they go offline. - -Nodes will only establish connections with other nodes if they have compatible :doc:`Quality of Service <../../Tutorials/Demos/Quality-of-Service>` settings. - -Take the :ref:`talker-listener demo ` for example. -Running the C++ talker node in one terminal will publish messages on a topic, -and the Python listener node running in another terminal will subscribe to messages on the same topic. - -You should see that these nodes discover each other automatically, and begin to exchange messages. +.. redirect-from:: + + Concepts/Basic/About-Discovery + +Discovery +========= + +.. contents:: Table of Contents + :local: + +Discovery of nodes happens automatically through the underlying middleware of ROS 2. +It can be summarized as follows: + +#. When a node is started, it advertises its presence to other nodes on the network with the same ROS domain (set with the ROS_DOMAIN_ID environment variable). + Nodes respond to this advertisement with information about themselves so that the appropriate connections can be made and the nodes can communicate. +#. Nodes periodically advertise their presence so that connections can be made with new-found entities, even after the initial discovery period. +#. Nodes advertise to other nodes when they go offline. + +Nodes will only establish connections with other nodes if they have compatible :doc:`Quality of Service <../topics/Working-with-topics/Quality-of-Service>` settings. + +Take the :ref:`talker-listener demo ` for example. +Running the C++ talker node in one terminal will publish messages on a topic, +and the Python listener node running in another terminal will subscribe to messages on the same topic. + +You should see that these nodes discover each other automatically, and begin to exchange messages. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/About-Domain-ID.rst b/source/ROS-Framework/nodes/About-Domain-ID.rst index 73ca15e4e5a..48e96f48c1c 100644 --- a/source/ROS-Framework/nodes/About-Domain-ID.rst +++ b/source/ROS-Framework/nodes/About-Domain-ID.rst @@ -1,163 +1,164 @@ -.. redirect-from:: - - Concepts/About-Domain-ID - -The ROS_DOMAIN_ID -================= - -.. contents:: Table of Contents - :local: - -Overview --------- - -As explained elsewhere, the default middleware that ROS 2 uses for communication is DDS. -In DDS, the primary mechanism for having different logical networks share a physical network is known as the Domain ID. -ROS 2 nodes on the same domain can freely discover and send messages to each other, while ROS 2 nodes on different domains cannot. -All ROS 2 nodes use domain ID 0 by default. -To avoid interference between different groups of computers running ROS 2 on the same network, a different domain ID should be set for each group. - -Choosing a domain ID (short version) ------------------------------------- - -The text below explains the derivation of the range of domain IDs that should be used in ROS 2. -To skip that background and just choose a safe number, simply choose a domain ID between 0 and 101, inclusive. - - -Choosing a domain ID (long version) ------------------------------------ - -The domain ID is used by DDS to compute the UDP ports that will be used for discovery and communication. -See `this article `__ for details on how the ports are computed. -Remembering our basic networking, the UDP port is an `unsigned 16-bit integer `__. -Thus, the highest port number that can be allocated is 65535. -Doing some math with the formula in the article above, this means that the highest domain ID that can possibly be assigned is 232, while the lowest that can be assigned is 0. - -Platform-specific constraints -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For maximum compatibility, some additional platform-specific constraints should be followed when choosing a domain ID. -In particular, it is best to avoid allocating domain IDs in the operating system's `ephemeral port range `__. -This avoids possible conflicts between the ports used by the ROS 2 nodes and other networking services on the computers. - -Here are some platform-specific notes about ephemeral ports. - -.. tabs:: - - .. group-tab:: Linux - - By default, the Linux kernel uses ports 32768-60999 for ephemeral ports. - This means that domain IDs 0-101 and 215-232 can be safely used without colliding with ephemeral ports. - The ephemeral port range is configurable in Linux by setting custom values in ``/proc/sys/net/ipv4/ip_local_port_range``. - If a custom ephemeral port range is used, the above numbers may have to be adjusted accordingly. - - .. group-tab:: macOS - - By default, the ephemeral port range on macOS is 49152-65535. - This means that domain IDs 0-166 can be safely used without colliding with ephemeral ports. - The ephemeral port range is configurable in macOS by setting custom sysctl values for ``net.inet.ip.portrange.first`` and ``net.inet.ip.portrange.last``. - If a custom ephemeral port range is used, the above numbers may have to be adjusted accordingly. - - .. group-tab:: Windows - - By default, the ephemeral port range on Windows is 49152-65535. - This means that domain IDs 0-166 can be safely used without colliding with ephemeral ports. - The ephemeral port range is configurable in Windows by `using netsh `__. - If a custom ephemeral port range is used, the above numbers may have to be adjusted accordingly. - -Participant constraints -^^^^^^^^^^^^^^^^^^^^^^^ - -For each ROS 2 process running on a computer, one DDS "participant" is created. -Since each DDS participant takes up two ports on the computer, running more than 120 ROS 2 processes on one computer may spill over into other domain IDs or the ephemeral ports. - -To see why, consider the domain IDs 1 and 2. - -- Domain ID 1 uses port 7650 and 7651 for multicast. -- Domain ID 2 uses port 7900 and 7901 for multicast. -- When creating the 1st process (zeroth participant) in domain ID 1, the ports 7660 and 7661 are used for unicast. -- When creating the 120th process (119th participant) in domain ID 1, the ports 7898 and 7899 are used for unicast. -- When creating the 121st process (120th participant) in domain ID 1, the ports 7900 and 7901 are used for unicast and overlap with domain ID 2. - -If it is known that the computer will only ever be on a single domain ID at a time, and the domain ID is low enough, it is safe to create more ROS 2 processes than this. - -When choosing a domain ID that is near the top of the range of platform-specific domain IDs, one additional constraint should be considered. - -For instance, assume a Linux computer with a domain ID of 101: - -- The zero'th ROS 2 process on the computer will connect to ports 32650, 32651, 32660, and 32661. -- The first ROS 2 process on the computer will connect to ports 32650, 32651, 32662, and 32663. -- The 53rd ROS 2 process on the computer will connect to ports 32650, 32651, 32766, and 32767. -- The 54th ROS 2 process on the computer will connect to ports 32650, 32651, 32768, and 32769, running into the ephemeral port range. - -Thus the maximum number of processes that should be created when using domain ID 101 on Linux is 54. -Similarly, the maximum number of processes that should be created when using domain ID 232 on Linux is 63, as the maximum port number is 65535. - -The situation is similar on macOS and Windows, though the numbers are different. -On macOS and Windows, when choosing a domain ID of 166 (the top of the range), the maximum number of ROS 2 processes that can be created on a computer before running into the ephemeral port range is 120. - -Domain ID to UDP Port Calculator -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. raw:: html - - - - - - - - - - -
-
- - - - - - - - - - - - - - - - - -
-
-
- - +.. redirect-from:: + + Concepts/About-Domain-ID + Concepts/Intermediate/About-Domain-ID + +The ROS_DOMAIN_ID +================= + +.. contents:: Table of Contents + :local: + +Overview +-------- + +As explained elsewhere, the default middleware that ROS 2 uses for communication is DDS. +In DDS, the primary mechanism for having different logical networks share a physical network is known as the Domain ID. +ROS 2 nodes on the same domain can freely discover and send messages to each other, while ROS 2 nodes on different domains cannot. +All ROS 2 nodes use domain ID 0 by default. +To avoid interference between different groups of computers running ROS 2 on the same network, a different domain ID should be set for each group. + +Choosing a domain ID (short version) +------------------------------------ + +The text below explains the derivation of the range of domain IDs that should be used in ROS 2. +To skip that background and just choose a safe number, simply choose a domain ID between 0 and 101, inclusive. + + +Choosing a domain ID (long version) +----------------------------------- + +The domain ID is used by DDS to compute the UDP ports that will be used for discovery and communication. +See `this article `__ for details on how the ports are computed. +Remembering our basic networking, the UDP port is an `unsigned 16-bit integer `__. +Thus, the highest port number that can be allocated is 65535. +Doing some math with the formula in the article above, this means that the highest domain ID that can possibly be assigned is 232, while the lowest that can be assigned is 0. + +Platform-specific constraints +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For maximum compatibility, some additional platform-specific constraints should be followed when choosing a domain ID. +In particular, it is best to avoid allocating domain IDs in the operating system's `ephemeral port range `__. +This avoids possible conflicts between the ports used by the ROS 2 nodes and other networking services on the computers. + +Here are some platform-specific notes about ephemeral ports. + +.. tabs:: + + .. group-tab:: Linux + + By default, the Linux kernel uses ports 32768-60999 for ephemeral ports. + This means that domain IDs 0-101 and 215-232 can be safely used without colliding with ephemeral ports. + The ephemeral port range is configurable in Linux by setting custom values in ``/proc/sys/net/ipv4/ip_local_port_range``. + If a custom ephemeral port range is used, the above numbers may have to be adjusted accordingly. + + .. group-tab:: macOS + + By default, the ephemeral port range on macOS is 49152-65535. + This means that domain IDs 0-166 can be safely used without colliding with ephemeral ports. + The ephemeral port range is configurable in macOS by setting custom sysctl values for ``net.inet.ip.portrange.first`` and ``net.inet.ip.portrange.last``. + If a custom ephemeral port range is used, the above numbers may have to be adjusted accordingly. + + .. group-tab:: Windows + + By default, the ephemeral port range on Windows is 49152-65535. + This means that domain IDs 0-166 can be safely used without colliding with ephemeral ports. + The ephemeral port range is configurable in Windows by `using netsh `__. + If a custom ephemeral port range is used, the above numbers may have to be adjusted accordingly. + +Participant constraints +^^^^^^^^^^^^^^^^^^^^^^^ + +For each ROS 2 process running on a computer, one DDS "participant" is created. +Since each DDS participant takes up two ports on the computer, running more than 120 ROS 2 processes on one computer may spill over into other domain IDs or the ephemeral ports. + +To see why, consider the domain IDs 1 and 2. + +- Domain ID 1 uses port 7650 and 7651 for multicast. +- Domain ID 2 uses port 7900 and 7901 for multicast. +- When creating the 1st process (zeroth participant) in domain ID 1, the ports 7660 and 7661 are used for unicast. +- When creating the 120th process (119th participant) in domain ID 1, the ports 7898 and 7899 are used for unicast. +- When creating the 121st process (120th participant) in domain ID 1, the ports 7900 and 7901 are used for unicast and overlap with domain ID 2. + +If it is known that the computer will only ever be on a single domain ID at a time, and the domain ID is low enough, it is safe to create more ROS 2 processes than this. + +When choosing a domain ID that is near the top of the range of platform-specific domain IDs, one additional constraint should be considered. + +For instance, assume a Linux computer with a domain ID of 101: + +- The zero'th ROS 2 process on the computer will connect to ports 32650, 32651, 32660, and 32661. +- The first ROS 2 process on the computer will connect to ports 32650, 32651, 32662, and 32663. +- The 53rd ROS 2 process on the computer will connect to ports 32650, 32651, 32766, and 32767. +- The 54th ROS 2 process on the computer will connect to ports 32650, 32651, 32768, and 32769, running into the ephemeral port range. + +Thus the maximum number of processes that should be created when using domain ID 101 on Linux is 54. +Similarly, the maximum number of processes that should be created when using domain ID 232 on Linux is 63, as the maximum port number is 65535. + +The situation is similar on macOS and Windows, though the numbers are different. +On macOS and Windows, when choosing a domain ID of 166 (the top of the range), the maximum number of ROS 2 processes that can be created on a computer before running into the ephemeral port range is 120. + +Domain ID to UDP Port Calculator +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. raw:: html + + + + + + + + + + +
+
+ + + + + + + + + + + + + + + + + +
+
+
+ + \ No newline at end of file diff --git a/source/ROS-Framework/nodes/About-Logging/About-Logging.rst b/source/ROS-Framework/nodes/About-Logging/About-Logging.rst index abd2ccee1ab..0b5c3027d34 100644 --- a/source/ROS-Framework/nodes/About-Logging/About-Logging.rst +++ b/source/ROS-Framework/nodes/About-Logging/About-Logging.rst @@ -1,383 +1,384 @@ -.. redirect-from:: - - Logging - Concepts/About-Logging - -Logging and logger configuration -================================ - -.. contents:: Table of Contents - :local: - -Overview --------- - -The logging subsystem in ROS 2 aims to deliver logging messages to a variety of targets, including: - -* To the console (if one is attached) -* To log files on disk (if local storage is available) -* To the ``/rosout`` topic on the ROS 2 network - -By default, log messages in ROS 2 nodes will go out to the console (on stderr), to log files on disk, and to the ``/rosout`` topic on the ROS 2 network. -All of the targets can be individually enabled or disabled on a per-node basis. - -The rest of this document will go over some of the ideas behind the logging subsystem. - -Severity level --------------- - -Log messages have a severity level associated with them: ``DEBUG``, ``INFO``, ``WARN``, ``ERROR`` or ``FATAL``, in ascending order. - -A logger will only process log messages with severity at or higher than a specified level chosen for the logger. - -Each node has a logger associated with it that automatically includes the node's name and namespace. -If the node's name is externally remapped to something other than what is defined in the source code, it will be reflected in the logger name. -Non-node loggers can also be created that use a specific name. - -Logger names represent a hierarchy. -If the level of a logger named "abc.def" is unset, it will defer to the level of its parent named "abc", and if that level is also unset, the default logger level will be used. -When the level of logger "abc" is changed, all of its descendants (e.g. "abc.def", "abc.ghi.jkl") will have their level impacted unless their level has been explicitly set. - -APIs ----- - -These are the APIs that end users of the ROS 2 logging infrastructure should use, split up by client library. - -.. tabs:: - - .. group-tab:: C++ - - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}`` - output the given printf-style message every time this line is hit - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_ONCE`` - output the given printf-style message only the first time this line is hit - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_EXPRESSION`` - output the given printf-style message only if the given expression is true - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_FUNCTION`` - output the given printf-style message only if the given function returns true - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_SKIPFIRST`` - output the given printf-style message all but the first time this line is hit - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_THROTTLE`` - output the given printf-style message no more than the given rate in integer milliseconds - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_SKIPFIRST_THROTTLE`` - output the given printf-style message no more than the given rate in integer milliseconds, but skip the first - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM`` - output the given C++ stream-style message every time this line is hit - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_ONCE`` - output the given C++ stream-style message only the first time this line is hit - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_EXPRESSION`` - output the given C++ stream-style message only if the given expression is true - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_FUNCTION`` - output the given C++ stream-style message only if the given function returns true - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_SKIPFIRST`` - output the given C++ stream-style message all but the first time this line is hit - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_THROTTLE`` - output the given C++ stream-style message no more than the given rate in integer milliseconds - * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_SKIPFIRST_THROTTLE`` - output the given C++ stream-style message no more than the given rate in integer milliseconds, but skip the first - - Each of the above APIs takes an ``rclcpp::Logger`` object as the first argument. - This can be pulled from the node API by calling ``node->get_logger()`` (recommended), or by constructing a stand-alone ``rclcpp::Logger`` object. - - * ``rcutils_logging_set_logger_level`` - Set the logging level for a particular logger name to the given severity level - * ``rcutils_logging_get_logger_effective_level`` - Given a logger name, return the logger level (which may be unset) - - .. group-tab:: Python - - * ``logger.{debug,info,warning,error,fatal}`` - output the given Python string to the logging infrastructure. - The calls accept the following keyword args to control behavior: - - * ``throttle_duration_sec`` - if not None, the duration of the throttle interval in floating-point seconds - * ``skip_first`` - if True, output the message all but the first time this line is hit - * ``once`` - if True, only output the message the first time this line is hit - - * ``rclpy.logging.set_logger_level`` - Set the logging level for a particular logger name to the given severity level - * ``rclpy.logging.get_logger_effective_level`` - Given a logger name, return the logger level (which may be unset) - -Configuration -------------- - -Since ``rclcpp`` and ``rclpy`` use the same underlying logging infrastructure, the configuration options are the same. - -.. _logging-configuration-environment-variables: - -Environment variables -^^^^^^^^^^^^^^^^^^^^^ - -The following environment variables control some aspects of the ROS 2 loggers. -For each of the environment settings, note that this is a process-wide setting, so it applies to all nodes in that process. - -* ``RCL_LOGGING_IMPLEMENTATION`` - Control which logging backend implementation to use at runtime (when using dynamic loading, which is the default). - If non-empty, use the specified logging implementation library (e.g., ``rcl_logging_spdlog``, ``rcl_logging_noop``). - If empty or not set, defaults to ``rcl_logging_spdlog``. - This variable has no effect when RCL is built with static linking to a specific logging implementation. - See the ``rcl_logging_implementation`` section below for more details. -* ``RCL_LOGGING_SPDLOG_FLUSH_PERIOD_SECONDS`` - Control the periodic flush interval for log files when using the ``rcl_logging_spdlog`` backend. - By default, logs are flushed every 5 seconds and immediately on error-level messages. - If set to ``0``, logs are flushed immediately on every log message (unbuffered mode, which may impact performance). - If set to a positive integer ``N``, logs are flushed every ``N`` seconds plus immediately on error-level messages. - If set to an invalid value (non-integer, negative, or trailing characters), initialization will fail with an error. -* ``ROS_LOG_DIR`` - Control the logging directory that is used for writing logging messages to disk (if that is enabled). - If non-empty, use the exact directory as specified in this variable. - If empty, use the contents of the ``ROS_HOME`` environment variable to construct a path of the form ``$ROS_HOME/.log``. - In all cases, the ``~`` character is expanded to the user's HOME directory. -* ``ROS_HOME`` - Control the home directory that is used for various ROS files, including logging and config files. - In the context of logging, this variable is used to construct a path to a directory for log files. - If non-empty, use the contents of this variable for the ROS_HOME path. - In all cases, the ``~`` character is expanded to the users's HOME directory. -* ``RCUTILS_LOGGING_USE_STDOUT`` - Control what stream output messages go to. - If this is unset or 0, use stderr. - If this is 1, use stdout. -* ``RCUTILS_LOGGING_BUFFERED_STREAM`` - Control whether the logging stream (as configured in ``RCUTILS_LOGGING_USE_STDOUT``) should be line buffered or unbuffered. - If this is unset, use the default of the stream (generally line buffered for stdout, and unbuffered for stderr). - If this is 0, force the stream to be unbuffered. - If this is 1, force the stream to be line buffered. -* ``RCUTILS_COLORIZED_OUTPUT`` - Control whether colors are used when outputting messages. - If unset, automatically determine based on the platform and whether the console is a TTY. - If 0, force disable using colors for output. - If 1, force enable using colors for output. -* ``RCUTILS_CONSOLE_OUTPUT_FORMAT`` - Control the fields that are output for each log message. - The available fields are: - - * ``{severity}`` - The severity level. - * ``{name}`` - The name of the logger (may be empty). - * ``{message}`` - The log message (may be empty). - * ``{function_name}`` - The function name this was called from (may be empty). - * ``{file_name}`` - The file name this was called from (may be empty). - * ``{short_file_name}`` - The file name without the directory path (basename only) this was called from (may be empty). - * ``{time}`` - The time in seconds since the epoch. - * ``{time_as_nanoseconds}`` - The time in nanoseconds since the epoch. - * ``{date_time_with_ms}`` - The time in ISO format, e.g. ``2024-06-11 09:29:19.304`` - * ``{line_number}`` - The line number this was called from (may be empty). - - If no format is given, a default of ``[{severity}] [{time}] [{name}]: {message}`` is used. - -``RCUTILS_CONSOLE_OUTPUT_FORMAT`` also supports the following escape character syntax. - -.. list-table:: - :header-rows: 1 - - * - Escape character syntax - - Character represented - * - ``\a`` - - Alert - * - ``\b`` - - Backspace - * - ``\n`` - - New line - * - ``\r`` - - Carriage return - * - ``\t`` - - Horizontal tab - -Node creation -^^^^^^^^^^^^^ - -When initializing a ROS 2 node, it is possible to control some aspects of the behavior via node options. -Since these are per-node options, they can be set differently for different nodes even when the nodes are composed into a single process. - -* ``log_levels`` - The log level to use for a component within this particular node. - This can be set with the following: ``ros2 run demo_nodes_cpp talker --ros-args --log-level talker:=DEBUG`` -* ``external_log_config_file`` - The external file to use to configure the backend logger. - If it is NULL, the default configuration will be used. - Note that the format of this file is backend-specific (and is currently unimplemented for the default backend logger of spdlog). - This can be set with the following: ``ros2 run demo_nodes_cpp talker --ros-args --log-config-file log-config.txt`` -* ``log_stdout_disabled`` - Whether to disable writing log messages to the console. - This can be done with the following: ``ros2 run demo_nodes_cpp talker --ros-args --disable-stdout-logs`` -* ``log_rosout_disabled`` - Whether to disable writing log messages out to ``/rosout``. - This can significantly save on network bandwidth, but external observers will not be able to monitor logging. - This can be done with the following: ``ros2 run demo_nodes_cpp talker --ros-args --disable-rosout-logs`` -* ``log_ext_lib_disabled`` - Whether to completely disable the use of an external logger. - This may be faster in some cases, but means that logs will not be written to disk. - This can be done with the following: ``ros2 run demo_nodes_cpp talker --ros-args --disable-external-lib-logs`` - -Logging subsystem design ------------------------- - -The image below shows the main pieces to the logging subsystem and how they interact. -Note that ``rcl`` can link to logging implementations either through the ``rcl_logging_implementation`` abstraction layer (for runtime dynamic loading, the default) or directly to a specific implementation like ``rcl_logging_spdlog`` (for static linking). - -.. figure:: ../images/ros2_logging_architecture.png - :alt: ROS 2 logging architecture - :width: 550px - :align: center - -rcutils -^^^^^^^ - -``rcutils`` has a logging implementation that can format log messages according to a certain format (see ``Configuration`` above), and output those log messages to a console. -``rcutils`` implements a complete logging solution, but allows higher-level components to insert themselves into the logging infrastructure in a dependency-injection model. -This will become more evident when we talk about the ``rcl`` layer below. - -Note that this is a *per-process* logging implementation, so anything that is configured at this level will affect the entire process, not just individual nodes. - -rcl_logging_implementation -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``rcl_logging_implementation`` is a package that enables runtime dynamic loading of logging backends in ROS 2, similar to how ``rmw_implementation`` works for middleware selection. -This abstraction layer allows users to switch between different logging implementations (such as ``rcl_logging_spdlog`` and ``rcl_logging_noop``) without rebuilding RCL or application code. - -.. figure:: ../images/rcl_logging_implementation.png - :alt: rcl_logging_implementation architecture - :width: 550px - :align: center - -Runtime Dynamic Loading vs Static Linking -"""""""""""""""""""""""""""""""""""""""""" - -The logging system supports two build configurations: - -Dynamic Loading (Default) -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -By default, ``rcl`` links against ``rcl_logging_implementation``, which dynamically loads the logging backend at runtime. -This approach provides maximum flexibility, allowing the logging implementation to be changed via environment variables without recompilation. - -When using dynamic loading: - -* The logging implementation is loaded as a shared library at runtime -* The actual implementation can be selected via the ``RCL_LOGGING_IMPLEMENTATION`` environment variable -* No rebuild is required to switch between logging implementations -* All logging interface function symbols are resolved lazily when first accessed - -Static Linking -~~~~~~~~~~~~~~ - -For embedded systems or deployment scenarios requiring static linking, the build system can be configured to link directly to a specific logging implementation: - -* Set the CMake variable ``RCL_LOGGING_IMPLEMENTATION`` at build time to specify the implementation (e.g., ``rcl_logging_spdlog``, ``rcl_logging_noop``) -* Alternatively, set the ``RCL_LOGGING_IMPLEMENTATION`` environment variable before running CMake -* The specified implementation will be statically linked into the final executable -* Runtime switching is NOT available with static linking - -Environment Variable Configuration -""""""""""""""""""""""""""""""""""" - -When using dynamic loading (the default), the ``RCL_LOGGING_IMPLEMENTATION`` environment variable controls which logging backend is loaded at runtime. - -Syntax -~~~~~~ - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - export RCL_LOGGING_IMPLEMENTATION= - - .. group-tab:: macOS - - .. code-block:: console - - export RCL_LOGGING_IMPLEMENTATION= - - .. group-tab:: Windows - - .. code-block:: console - - set RCL_LOGGING_IMPLEMENTATION= - -Available implementations -~~~~~~~~~~~~~~~~~~~~~~~~~ - -* ``rcl_logging_spdlog`` - Full-featured logging using the spdlog library (default) -* ``rcl_logging_noop`` - No-op implementation that discards all log messages (useful for performance-critical applications) - -Example usage -~~~~~~~~~~~~~ - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - # Use spdlog for logging (default behavior) - export RCL_LOGGING_IMPLEMENTATION=rcl_logging_spdlog - ros2 run demo_nodes_cpp talker - - # Use no-op logging implementation that discards all log messages to the logging backend - export RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop - ros2 run demo_nodes_cpp talker - - .. group-tab:: macOS - - .. code-block:: console - - # Use spdlog for logging (default behavior) - export RCL_LOGGING_IMPLEMENTATION=rcl_logging_spdlog - ros2 run demo_nodes_cpp talker - - # Use no-op logging implementation that discards all log messages to the logging backend - export RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop - ros2 run demo_nodes_cpp talker - - .. group-tab:: Windows - - .. code-block:: console - - # Use spdlog for logging (default behavior) - set RCL_LOGGING_IMPLEMENTATION=rcl_logging_spdlog - ros2 run demo_nodes_cpp talker - - # Use no-op logging implementation that discards all log messages to the logging backend - set RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop - ros2 run demo_nodes_cpp talker - -If the environment variable is not set, the system defaults to ``rcl_logging_spdlog``. - -Implementation Details -~~~~~~~~~~~~~~~~~~~~~~ - -The ``rcl_logging_implementation`` package: - -* Uses ``rcpputils::SharedLibrary`` for cross-platform dynamic library loading -* Loads all logging interface function symbols at initialization -* Maintains symbol references until the process exits -* Falls back to the default implementation if the requested implementation cannot be found -* Provides the same API surface as the underlying implementations, ensuring transparency to client code - -This architecture allows system integrators to: - -* Select appropriate logging implementations for different deployment scenarios -* Disable logging in production for improved performance without code changes -* Switch logging backends for debugging or development purposes -* Package different logging implementations and select them at runtime - -rcl_logging_spdlog -^^^^^^^^^^^^^^^^^^ - -``rcl_logging_spdlog`` implements the ``rcl_logging_interface`` API, and thus provides external logging services to the ``rcl`` layer. -In particular, the ``rcl_logging_spdlog`` implementation takes formatted log messages and writes them out to log files on disk using the ``spdlog`` library, typically within ``~/.ros/log`` (though this is configurable; see ``Configuration`` above). - -rcl -^^^ - -The logging subsystem in ``rcl`` uses ``rcutils`` and ``rcl_logging_spdlog`` to provide the bulk of the ROS 2 logging services. -When log messages come in, ``rcl`` decides where to send them. -There are 3 main places that logging messages can be delivered; an individual node may have any combination of them enabled: - -* To the console via the ``rcutils`` layer -* To disk via the ``rcl_logging_spdlog`` layer -* To the ``/rosout`` topic on the ROS 2 network via the RMW layer - -rclcpp -^^^^^^ - -This is the main ROS 2 C++ API which sits atop the ``rcl`` API. -In the context of logging, ``rclcpp`` provides the ``RCLCPP_`` logging macros; see ``APIs`` above for a complete list. -When one of the ``RCLCPP_`` macros runs, it checks the current severity level of the node against the severity level of the macro. -If the severity level of the macro is greater than or equal to the node severity level, the message will be formatted and output to all of the places that are currently configured. -Note that ``rclcpp`` uses a global mutex for log calls, so all logging calls within the same process end up being single-threaded. - - -rclpy -^^^^^ - -This is the main ROS 2 Python API which sits atop the ``rcl`` API. -In the context of logging, ``rclpy`` provides the ``logger.debug``-style functions; see ``APIs`` above for a complete list. -When one of the ``logger.debug`` functions runs, it checks the current severity level of the node against the severity level of the macro. -If the severity level of the macro is greater than or equal to the node severity level, the message will be formatted and output to all of the places that are currently configured. - - -Logging usage -------------- - -.. tabs:: - - .. group-tab:: C++ - - * See the `rclcpp logging demo `_ for some simple examples. - * See the :doc:`logging demo <../../Tutorials/Demos/Logging-and-logger-configuration>` for example usage. - - .. group-tab:: Python - - * See the `rclpy examples `__ for example usage of a node's logger. - * See the `rclpy tests `__ for example usage of keyword arguments (e.g. ``skip_first``, ``once``). +.. redirect-from:: + + Logging + Concepts/About-Logging + Concepts/Intermediate/About-Logging + +Logging and logger configuration +================================ + +.. contents:: Table of Contents + :local: + +Overview +-------- + +The logging subsystem in ROS 2 aims to deliver logging messages to a variety of targets, including: + +* To the console (if one is attached) +* To log files on disk (if local storage is available) +* To the ``/rosout`` topic on the ROS 2 network + +By default, log messages in ROS 2 nodes will go out to the console (on stderr), to log files on disk, and to the ``/rosout`` topic on the ROS 2 network. +All of the targets can be individually enabled or disabled on a per-node basis. + +The rest of this document will go over some of the ideas behind the logging subsystem. + +Severity level +-------------- + +Log messages have a severity level associated with them: ``DEBUG``, ``INFO``, ``WARN``, ``ERROR`` or ``FATAL``, in ascending order. + +A logger will only process log messages with severity at or higher than a specified level chosen for the logger. + +Each node has a logger associated with it that automatically includes the node's name and namespace. +If the node's name is externally remapped to something other than what is defined in the source code, it will be reflected in the logger name. +Non-node loggers can also be created that use a specific name. + +Logger names represent a hierarchy. +If the level of a logger named "abc.def" is unset, it will defer to the level of its parent named "abc", and if that level is also unset, the default logger level will be used. +When the level of logger "abc" is changed, all of its descendants (e.g. "abc.def", "abc.ghi.jkl") will have their level impacted unless their level has been explicitly set. + +APIs +---- + +These are the APIs that end users of the ROS 2 logging infrastructure should use, split up by client library. + +.. tabs:: + + .. group-tab:: C++ + + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}`` - output the given printf-style message every time this line is hit + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_ONCE`` - output the given printf-style message only the first time this line is hit + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_EXPRESSION`` - output the given printf-style message only if the given expression is true + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_FUNCTION`` - output the given printf-style message only if the given function returns true + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_SKIPFIRST`` - output the given printf-style message all but the first time this line is hit + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_THROTTLE`` - output the given printf-style message no more than the given rate in integer milliseconds + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_SKIPFIRST_THROTTLE`` - output the given printf-style message no more than the given rate in integer milliseconds, but skip the first + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM`` - output the given C++ stream-style message every time this line is hit + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_ONCE`` - output the given C++ stream-style message only the first time this line is hit + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_EXPRESSION`` - output the given C++ stream-style message only if the given expression is true + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_FUNCTION`` - output the given C++ stream-style message only if the given function returns true + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_SKIPFIRST`` - output the given C++ stream-style message all but the first time this line is hit + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_THROTTLE`` - output the given C++ stream-style message no more than the given rate in integer milliseconds + * ``RCLCPP_{DEBUG,INFO,WARN,ERROR,FATAL}_STREAM_SKIPFIRST_THROTTLE`` - output the given C++ stream-style message no more than the given rate in integer milliseconds, but skip the first + + Each of the above APIs takes an ``rclcpp::Logger`` object as the first argument. + This can be pulled from the node API by calling ``node->get_logger()`` (recommended), or by constructing a stand-alone ``rclcpp::Logger`` object. + + * ``rcutils_logging_set_logger_level`` - Set the logging level for a particular logger name to the given severity level + * ``rcutils_logging_get_logger_effective_level`` - Given a logger name, return the logger level (which may be unset) + + .. group-tab:: Python + + * ``logger.{debug,info,warning,error,fatal}`` - output the given Python string to the logging infrastructure. + The calls accept the following keyword args to control behavior: + + * ``throttle_duration_sec`` - if not None, the duration of the throttle interval in floating-point seconds + * ``skip_first`` - if True, output the message all but the first time this line is hit + * ``once`` - if True, only output the message the first time this line is hit + + * ``rclpy.logging.set_logger_level`` - Set the logging level for a particular logger name to the given severity level + * ``rclpy.logging.get_logger_effective_level`` - Given a logger name, return the logger level (which may be unset) + +Configuration +------------- + +Since ``rclcpp`` and ``rclpy`` use the same underlying logging infrastructure, the configuration options are the same. + +.. _logging-configuration-environment-variables: + +Environment variables +^^^^^^^^^^^^^^^^^^^^^ + +The following environment variables control some aspects of the ROS 2 loggers. +For each of the environment settings, note that this is a process-wide setting, so it applies to all nodes in that process. + +* ``RCL_LOGGING_IMPLEMENTATION`` - Control which logging backend implementation to use at runtime (when using dynamic loading, which is the default). + If non-empty, use the specified logging implementation library (e.g., ``rcl_logging_spdlog``, ``rcl_logging_noop``). + If empty or not set, defaults to ``rcl_logging_spdlog``. + This variable has no effect when RCL is built with static linking to a specific logging implementation. + See the ``rcl_logging_implementation`` section below for more details. +* ``RCL_LOGGING_SPDLOG_FLUSH_PERIOD_SECONDS`` - Control the periodic flush interval for log files when using the ``rcl_logging_spdlog`` backend. + By default, logs are flushed every 5 seconds and immediately on error-level messages. + If set to ``0``, logs are flushed immediately on every log message (unbuffered mode, which may impact performance). + If set to a positive integer ``N``, logs are flushed every ``N`` seconds plus immediately on error-level messages. + If set to an invalid value (non-integer, negative, or trailing characters), initialization will fail with an error. +* ``ROS_LOG_DIR`` - Control the logging directory that is used for writing logging messages to disk (if that is enabled). + If non-empty, use the exact directory as specified in this variable. + If empty, use the contents of the ``ROS_HOME`` environment variable to construct a path of the form ``$ROS_HOME/.log``. + In all cases, the ``~`` character is expanded to the user's HOME directory. +* ``ROS_HOME`` - Control the home directory that is used for various ROS files, including logging and config files. + In the context of logging, this variable is used to construct a path to a directory for log files. + If non-empty, use the contents of this variable for the ROS_HOME path. + In all cases, the ``~`` character is expanded to the users's HOME directory. +* ``RCUTILS_LOGGING_USE_STDOUT`` - Control what stream output messages go to. + If this is unset or 0, use stderr. + If this is 1, use stdout. +* ``RCUTILS_LOGGING_BUFFERED_STREAM`` - Control whether the logging stream (as configured in ``RCUTILS_LOGGING_USE_STDOUT``) should be line buffered or unbuffered. + If this is unset, use the default of the stream (generally line buffered for stdout, and unbuffered for stderr). + If this is 0, force the stream to be unbuffered. + If this is 1, force the stream to be line buffered. +* ``RCUTILS_COLORIZED_OUTPUT`` - Control whether colors are used when outputting messages. + If unset, automatically determine based on the platform and whether the console is a TTY. + If 0, force disable using colors for output. + If 1, force enable using colors for output. +* ``RCUTILS_CONSOLE_OUTPUT_FORMAT`` - Control the fields that are output for each log message. + The available fields are: + + * ``{severity}`` - The severity level. + * ``{name}`` - The name of the logger (may be empty). + * ``{message}`` - The log message (may be empty). + * ``{function_name}`` - The function name this was called from (may be empty). + * ``{file_name}`` - The file name this was called from (may be empty). + * ``{short_file_name}`` - The file name without the directory path (basename only) this was called from (may be empty). + * ``{time}`` - The time in seconds since the epoch. + * ``{time_as_nanoseconds}`` - The time in nanoseconds since the epoch. + * ``{date_time_with_ms}`` - The time in ISO format, e.g. ``2024-06-11 09:29:19.304`` + * ``{line_number}`` - The line number this was called from (may be empty). + + If no format is given, a default of ``[{severity}] [{time}] [{name}]: {message}`` is used. + +``RCUTILS_CONSOLE_OUTPUT_FORMAT`` also supports the following escape character syntax. + +.. list-table:: + :header-rows: 1 + + * - Escape character syntax + - Character represented + * - ``\a`` + - Alert + * - ``\b`` + - Backspace + * - ``\n`` + - New line + * - ``\r`` + - Carriage return + * - ``\t`` + - Horizontal tab + +Node creation +^^^^^^^^^^^^^ + +When initializing a ROS 2 node, it is possible to control some aspects of the behavior via node options. +Since these are per-node options, they can be set differently for different nodes even when the nodes are composed into a single process. + +* ``log_levels`` - The log level to use for a component within this particular node. + This can be set with the following: ``ros2 run demo_nodes_cpp talker --ros-args --log-level talker:=DEBUG`` +* ``external_log_config_file`` - The external file to use to configure the backend logger. + If it is NULL, the default configuration will be used. + Note that the format of this file is backend-specific (and is currently unimplemented for the default backend logger of spdlog). + This can be set with the following: ``ros2 run demo_nodes_cpp talker --ros-args --log-config-file log-config.txt`` +* ``log_stdout_disabled`` - Whether to disable writing log messages to the console. + This can be done with the following: ``ros2 run demo_nodes_cpp talker --ros-args --disable-stdout-logs`` +* ``log_rosout_disabled`` - Whether to disable writing log messages out to ``/rosout``. + This can significantly save on network bandwidth, but external observers will not be able to monitor logging. + This can be done with the following: ``ros2 run demo_nodes_cpp talker --ros-args --disable-rosout-logs`` +* ``log_ext_lib_disabled`` - Whether to completely disable the use of an external logger. + This may be faster in some cases, but means that logs will not be written to disk. + This can be done with the following: ``ros2 run demo_nodes_cpp talker --ros-args --disable-external-lib-logs`` + +Logging subsystem design +------------------------ + +The image below shows the main pieces to the logging subsystem and how they interact. +Note that ``rcl`` can link to logging implementations either through the ``rcl_logging_implementation`` abstraction layer (for runtime dynamic loading, the default) or directly to a specific implementation like ``rcl_logging_spdlog`` (for static linking). + +.. figure:: ../images/ros2_logging_architecture.png + :alt: ROS 2 logging architecture + :width: 550px + :align: center + +rcutils +^^^^^^^ + +``rcutils`` has a logging implementation that can format log messages according to a certain format (see ``Configuration`` above), and output those log messages to a console. +``rcutils`` implements a complete logging solution, but allows higher-level components to insert themselves into the logging infrastructure in a dependency-injection model. +This will become more evident when we talk about the ``rcl`` layer below. + +Note that this is a *per-process* logging implementation, so anything that is configured at this level will affect the entire process, not just individual nodes. + +rcl_logging_implementation +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``rcl_logging_implementation`` is a package that enables runtime dynamic loading of logging backends in ROS 2, similar to how ``rmw_implementation`` works for middleware selection. +This abstraction layer allows users to switch between different logging implementations (such as ``rcl_logging_spdlog`` and ``rcl_logging_noop``) without rebuilding RCL or application code. + +.. figure:: ../images/rcl_logging_implementation.png + :alt: rcl_logging_implementation architecture + :width: 550px + :align: center + +Runtime Dynamic Loading vs Static Linking +"""""""""""""""""""""""""""""""""""""""""" + +The logging system supports two build configurations: + +Dynamic Loading (Default) +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By default, ``rcl`` links against ``rcl_logging_implementation``, which dynamically loads the logging backend at runtime. +This approach provides maximum flexibility, allowing the logging implementation to be changed via environment variables without recompilation. + +When using dynamic loading: + +* The logging implementation is loaded as a shared library at runtime +* The actual implementation can be selected via the ``RCL_LOGGING_IMPLEMENTATION`` environment variable +* No rebuild is required to switch between logging implementations +* All logging interface function symbols are resolved lazily when first accessed + +Static Linking +~~~~~~~~~~~~~~ + +For embedded systems or deployment scenarios requiring static linking, the build system can be configured to link directly to a specific logging implementation: + +* Set the CMake variable ``RCL_LOGGING_IMPLEMENTATION`` at build time to specify the implementation (e.g., ``rcl_logging_spdlog``, ``rcl_logging_noop``) +* Alternatively, set the ``RCL_LOGGING_IMPLEMENTATION`` environment variable before running CMake +* The specified implementation will be statically linked into the final executable +* Runtime switching is NOT available with static linking + +Environment Variable Configuration +""""""""""""""""""""""""""""""""""" + +When using dynamic loading (the default), the ``RCL_LOGGING_IMPLEMENTATION`` environment variable controls which logging backend is loaded at runtime. + +Syntax +~~~~~~ + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + export RCL_LOGGING_IMPLEMENTATION= + + .. group-tab:: macOS + + .. code-block:: console + + export RCL_LOGGING_IMPLEMENTATION= + + .. group-tab:: Windows + + .. code-block:: console + + set RCL_LOGGING_IMPLEMENTATION= + +Available implementations +~~~~~~~~~~~~~~~~~~~~~~~~~ + +* ``rcl_logging_spdlog`` - Full-featured logging using the spdlog library (default) +* ``rcl_logging_noop`` - No-op implementation that discards all log messages (useful for performance-critical applications) + +Example usage +~~~~~~~~~~~~~ + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + # Use spdlog for logging (default behavior) + export RCL_LOGGING_IMPLEMENTATION=rcl_logging_spdlog + ros2 run demo_nodes_cpp talker + + # Use no-op logging implementation that discards all log messages to the logging backend + export RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop + ros2 run demo_nodes_cpp talker + + .. group-tab:: macOS + + .. code-block:: console + + # Use spdlog for logging (default behavior) + export RCL_LOGGING_IMPLEMENTATION=rcl_logging_spdlog + ros2 run demo_nodes_cpp talker + + # Use no-op logging implementation that discards all log messages to the logging backend + export RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop + ros2 run demo_nodes_cpp talker + + .. group-tab:: Windows + + .. code-block:: console + + # Use spdlog for logging (default behavior) + set RCL_LOGGING_IMPLEMENTATION=rcl_logging_spdlog + ros2 run demo_nodes_cpp talker + + # Use no-op logging implementation that discards all log messages to the logging backend + set RCL_LOGGING_IMPLEMENTATION=rcl_logging_noop + ros2 run demo_nodes_cpp talker + +If the environment variable is not set, the system defaults to ``rcl_logging_spdlog``. + +Implementation Details +~~~~~~~~~~~~~~~~~~~~~~ + +The ``rcl_logging_implementation`` package: + +* Uses ``rcpputils::SharedLibrary`` for cross-platform dynamic library loading +* Loads all logging interface function symbols at initialization +* Maintains symbol references until the process exits +* Falls back to the default implementation if the requested implementation cannot be found +* Provides the same API surface as the underlying implementations, ensuring transparency to client code + +This architecture allows system integrators to: + +* Select appropriate logging implementations for different deployment scenarios +* Disable logging in production for improved performance without code changes +* Switch logging backends for debugging or development purposes +* Package different logging implementations and select them at runtime + +rcl_logging_spdlog +^^^^^^^^^^^^^^^^^^ + +``rcl_logging_spdlog`` implements the ``rcl_logging_interface`` API, and thus provides external logging services to the ``rcl`` layer. +In particular, the ``rcl_logging_spdlog`` implementation takes formatted log messages and writes them out to log files on disk using the ``spdlog`` library, typically within ``~/.ros/log`` (though this is configurable; see ``Configuration`` above). + +rcl +^^^ + +The logging subsystem in ``rcl`` uses ``rcutils`` and ``rcl_logging_spdlog`` to provide the bulk of the ROS 2 logging services. +When log messages come in, ``rcl`` decides where to send them. +There are 3 main places that logging messages can be delivered; an individual node may have any combination of them enabled: + +* To the console via the ``rcutils`` layer +* To disk via the ``rcl_logging_spdlog`` layer +* To the ``/rosout`` topic on the ROS 2 network via the RMW layer + +rclcpp +^^^^^^ + +This is the main ROS 2 C++ API which sits atop the ``rcl`` API. +In the context of logging, ``rclcpp`` provides the ``RCLCPP_`` logging macros; see ``APIs`` above for a complete list. +When one of the ``RCLCPP_`` macros runs, it checks the current severity level of the node against the severity level of the macro. +If the severity level of the macro is greater than or equal to the node severity level, the message will be formatted and output to all of the places that are currently configured. +Note that ``rclcpp`` uses a global mutex for log calls, so all logging calls within the same process end up being single-threaded. + + +rclpy +^^^^^ + +This is the main ROS 2 Python API which sits atop the ``rcl`` API. +In the context of logging, ``rclpy`` provides the ``logger.debug``-style functions; see ``APIs`` above for a complete list. +When one of the ``logger.debug`` functions runs, it checks the current severity level of the node against the severity level of the macro. +If the severity level of the macro is greater than or equal to the node severity level, the message will be formatted and output to all of the places that are currently configured. + + +Logging usage +------------- + +.. tabs:: + + .. group-tab:: C++ + + * See the `rclcpp logging demo `_ for some simple examples. + * See the :doc:`logging demo <../../../Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration>` for example usage. + + .. group-tab:: Python + + * See the `rclpy examples `__ for example usage of a node's logger. + * See the `rclpy tests `__ for example usage of keyword arguments (e.g. ``skip_first``, ``once``). \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst b/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst index bdd458648ea..66d50f784e6 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst @@ -1,430 +1,431 @@ -.. redirect-from:: - - Composition - Tutorials/Composition - -Composing multiple nodes in a single process -============================================ - -.. contents:: Table of Contents - :depth: 2 - :local: - -**Goal:** Compose multiple nodes into a single process. - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -Background ----------- - -See the :doc:`conceptual article <../../Concepts/Intermediate/About-Composition>`. - -For information on how to write a composable node, :doc:`check out this tutorial `. - -Prerequisites -------------- - -This tutorial uses executables from the `rclcpp_components `__, `ros2component `__, `composition `__, and `image_tools `__ packages. -If you've followed the :doc:`installation instructions <../../Installation>` for your platform, these should already be installed. - -Run the demos -------------- - -Discover available components -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To see what components are registered and available in the workspace, execute the following in a shell: - -.. code-block:: console - - $ ros2 component types - (... components of other packages here) - composition - composition::Talker - composition::Listener - composition::NodeLikeListener - composition::Server - composition::Client - (... components of other packages here) - - -Run-time composition using ROS services with a publisher and subscriber -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In the first shell, start the component container: - -.. code-block:: console - - $ ros2 run rclcpp_components component_container - -Open the second shell and verify that the container is running via ``ros2`` command line tools. -You should see a name of the component: - -.. code-block:: console - - $ ros2 component list - /ComponentManager - -In the second shell load the talker component (see `talker `__ source code). -The command will return the unique ID of the loaded component as well as the node name: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker - Loaded component 1 into '/ComponentManager' container node as '/talker' - -Now the first shell should show a message that the component was loaded as well as repeated message for publishing a message. - -Run another command in the second shell to load the listener component (see `listener `__ source code): - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Listener - Loaded component 2 into '/ComponentManager' container node as '/listener' - -The ``ros2`` command line utility can now be used to inspect the state of the container: - -.. code-block:: console - - $ ros2 component list - /ComponentManager - 1 /talker - 2 /listener - -Now the first shell should show repeated output for each received message. - -Run-time composition using ROS services with a server and client -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The example with a server and a client is very similar. - -In the first shell: - -.. code-block:: console - - $ ros2 run rclcpp_components component_container - -In the second shell (see `server `__ and `client `__ source code): - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Server - $ ros2 component load /ComponentManager composition composition::Client - -In this case the client sends a request to the server, the server processes the request and replies with a response, and the client prints the received response. - -Compile-time composition with hardcoded nodes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This demo shows that the same shared libraries can be reused to compile a single executable running multiple components without using ROS interfaces. -The executable contains all four components from above: talker and listener as well as server and client, which is hardcoded in the main function. - -In the shell call (see `source code `__): - -.. code-block:: console - - $ ros2 run composition manual_composition - -This should show repeated messages from both pairs, the talker and the listener as well as the server and the client. - -.. note:: - - Manually-composed components will not be reflected in the ``ros2 component list`` command line tool output. - -Run-time composition using dlopen -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This demo presents an alternative to run-time composition by creating a generic container process and explicitly passing the libraries to load without using ROS interfaces. -The process will open each library and create one instance of each "rclcpp::Node" class in the library (`source code `__). - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ ros2 run composition dlopen_composition `ros2 pkg prefix composition`/lib/libtalker_component.so `ros2 pkg prefix composition`/lib/liblistener_component.so - - .. group-tab:: macOS - - .. code-block:: console - - $ ros2 run composition dlopen_composition `ros2 pkg prefix composition`/lib/libtalker_component.dylib `ros2 pkg prefix composition`/lib/liblistener_component.dylib - - .. group-tab:: Windows - - .. code-block:: console - - $ ros2 pkg prefix composition - - to get the path to where composition is installed. - Then call - - .. code-block:: console - - $ ros2 run composition dlopen_composition \bin\talker_component.dll \bin\listener_component.dll - -Now the shell should show repeated output for each sent and received message. - -.. note:: - - dlopen-composed components will not be reflected in the ``ros2 component list`` command line tool output. - - -Composition using launch actions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While the command line tools are useful for debugging and diagnosing component configurations, it is frequently more convenient to start a set of components at the same time. -To automate this action, we can use a `launch file `__: - -.. code-block:: console - - $ ros2 launch composition composition_demo_launch.py - - -Advanced Topics ---------------- - -Now that we have seen the basic operation of components, we can discuss a few more advanced topics. - -.. _ComponentContainerTypes: - -Component container types -^^^^^^^^^^^^^^^^^^^^^^^^^ - -As introduced in :ref:`ComponentContainer`, there are a few component container types with different options. -You can choose the most appropriate component container type for your requirement. - -* ``component_container`` with ``SingleThreadedExecutor``. - - .. code-block:: console - - $ ros2 run rclcpp_components component_container - -* ``component_container`` with ``MultiThreadedExecutor`` composed of 4 threads. - * ``thread_num`` parameter option is available to specify the number of threads in ``MultiThreadedExecutor``. - If omitted, the executor will run with the maximum available threads on the system. - - .. code-block:: console - - $ ros2 run rclcpp_components component_container --executor-type multi-threaded --ros-args -p thread_num:=4 - -* ``component_container`` with ``EventsCBGExecutor`` composed of a single thread. - * ``thread_num`` parameter option is available to specify the number of threads in ``EventsCBGExecutor``. - If omitted, the executor will run with the maximum available threads on the system. - - .. code-block:: console - - $ ros2 run rclcpp_components component_container --executor-type events-cbg --ros-args -p thread_num:=1 - -* ``component_container`` with a dedicated ``MultiThreadedExecutor`` for each component. - - .. code-block:: console - - $ ros2 run rclcpp_components component_container --executor-type multi-threaded --isolated - -Unloading components -^^^^^^^^^^^^^^^^^^^^ - -In the first shell, start the component container: - -.. code-block:: console - - $ ros2 run rclcpp_components component_container - -Verify that the container is running via ``ros2`` command line tools: - -.. code-block:: console - - $ ros2 component list - /ComponentManager - -In the second shell load both the talker and listener as we have before: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker - Loaded component 1 into '/ComponentManager' container node as '/talker' - $ ros2 component load /ComponentManager composition composition::Listener - Loaded component 2 into '/ComponentManager' container node as '/listener' - -The unique ID of a component is printed when it gets loaded. -You can also get the unique IDs of all components by just listing them now that they are loaded: - -.. code-block:: console - - $ ros2 component list - /ComponentManager - 1 /talker - 2 /listener - -Use the unique ID to unload the component from the component container. - -.. code-block:: console - - $ ros2 component unload /ComponentManager 1 2 - Unloaded component 1 from '/ComponentManager' container - Unloaded component 2 from '/ComponentManager' container - -In the first shell, verify that the repeated messages from talker and listener have stopped. - - -Remapping container name and namespace -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The component manager name and namespace can be remapped via standard command line arguments: - -.. code-block:: console - - $ ros2 run rclcpp_components component_container --ros-args -r __node:=MyContainer -r __ns:=/ns - -In a second shell, components can be loaded by using the updated container name: - -.. code-block:: console - - $ ros2 component load /ns/MyContainer composition composition::Listener - -.. note:: - - Namespace remappings of the container do not affect loaded components. - - -Remap component names and namespaces -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Component names and namespaces may be adjusted via arguments to the load command. - -In the first shell, start the component container: - -.. code-block:: console - - $ ros2 run rclcpp_components component_container - - -Some examples of how to remap names and namespaces. - -Remap node name: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker --node-name talker2 - -Remap namespace: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker --node-namespace /ns - -Remap both: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker --node-name talker3 --node-namespace /ns2 - -Now use ``ros2`` command line utility: - -.. code-block:: console - - $ ros2 component list - /ComponentManager - 1 /talker2 - 2 /ns/talker - 3 /ns2/talker3 - -.. note:: - - Namespace remappings of the container do not affect loaded components. - -Passing parameter values into components -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``ros2 component load`` command-line supports passing arbitrary parameters to the node as it is constructed. -This functionality can be used as follows: - -.. code-block:: console - - $ ros2 component load /ComponentManager image_tools image_tools::Cam2Image -p burger_mode:=true - $ ros2 run rqt_image_view rqt_image_view # Shows burgers bouncing, instead of image from camera - -Passing additional arguments into components -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``ros2 component load`` command-line supports passing particular options to the component manager for use when constructing the node. - -The following example shows the use of the extra arguments ``use_intra_process_comms`` and ``forward_global_arguments``: - -.. code-block:: console - - $ ros2 component load /ComponentManager composition composition::Talker -e use_intra_process_comms:=true -e forward_global_arguments:=false - -The following extra arguments are supported. - -.. list-table:: Extra Arguments for Component Manager - :widths: 15 15 15 15 - :header-rows: 1 - - * - Argument - - Type - - Default - - Description - * - ``forward_global_arguments`` - - Boolean - - True - - Apply global arguments to the component node when loading. - * - ``enable_rosout`` - - Boolean - - True - - Enable the ``rosout`` topic publisher in the component node. - * - ``use_intra_process_comms`` - - Boolean - - False - - Enable intra-process communication in the component node. - * - ``enable_topic_statistics`` - - Boolean - - False - - Enable a topic statistics publisher in the component node. - * - ``start_parameter_services`` - - Boolean - - True - - Enable services to manage parameters in the component node. - * - ``start_parameter_event_publisher`` - - Boolean - - True - - Enable the parameter event publisher in the component node. - * - ``use_clock_thread`` - - Boolean - - True - - Enable a dedicated clock thread in the component node. - * - ``enable_logger_service`` - - Boolean - - False - - Enable logger level management service in the component node. - - -Composable nodes as shared libraries ------------------------------------- - -If you want to export a composable node as a shared library from a package and use that node in another package that does link-time composition, add code to the CMake file which imports the actual targets in downstream packages. - -Then install the generated file and export the generated file. - -A practical example can be seen here: `ROS Discourse - Ament best practice for sharing libraries `__ - -Composing Non-Node Derived Components -------------------------------------- - -In ROS 2, components allow for more efficient use of system resources and provide a powerful feature that enables you to create reusable functionality that is not tied to a specific node. - -One advantage of using components is that they allow you to create non-node derived functionality as standalone executables or shared libraries that can be loaded into the ROS system as needed. - -To create a component that is not derived from a node, follow these guidelines: - -1. Implement a constructor that takes ``const rclcpp::NodeOptions&`` as its argument. -2. Implement the ``get_node_base_interface()`` method, which should return a ``NodeBaseInterface::SharedPtr``. - You can use the ``get_node_base_interface()`` method of a node that you create in your constructor to provide this interface. - -Here's an example of a component that is not derived from a node, which listens to a ROS topic: `node_like_listener_component `__. - -For more information on this topic, you can refer to this `discussion `__. +.. redirect-from:: + + Composition + Tutorials/Composition + Tutorials/Intermediate/Composition + +Composing multiple nodes in a single process +============================================ + +.. contents:: Table of Contents + :depth: 2 + :local: + +**Goal:** Compose multiple nodes into a single process. + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +Background +---------- + +See the :doc:`conceptual article <../About-Composition>`. + +For information on how to write a composable node, :doc:`check out this tutorial `. + +Prerequisites +------------- + +This tutorial uses executables from the `rclcpp_components `__, `ros2component `__, `composition `__, and `image_tools `__ packages. +If you've followed the :doc:`installation instructions <../../../Get-Started/Installation>` for your platform, these should already be installed. + +Run the demos +------------- + +Discover available components +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To see what components are registered and available in the workspace, execute the following in a shell: + +.. code-block:: console + + $ ros2 component types + (... components of other packages here) + composition + composition::Talker + composition::Listener + composition::NodeLikeListener + composition::Server + composition::Client + (... components of other packages here) + + +Run-time composition using ROS services with a publisher and subscriber +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In the first shell, start the component container: + +.. code-block:: console + + $ ros2 run rclcpp_components component_container + +Open the second shell and verify that the container is running via ``ros2`` command line tools. +You should see a name of the component: + +.. code-block:: console + + $ ros2 component list + /ComponentManager + +In the second shell load the talker component (see `talker `__ source code). +The command will return the unique ID of the loaded component as well as the node name: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker + Loaded component 1 into '/ComponentManager' container node as '/talker' + +Now the first shell should show a message that the component was loaded as well as repeated message for publishing a message. + +Run another command in the second shell to load the listener component (see `listener `__ source code): + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Listener + Loaded component 2 into '/ComponentManager' container node as '/listener' + +The ``ros2`` command line utility can now be used to inspect the state of the container: + +.. code-block:: console + + $ ros2 component list + /ComponentManager + 1 /talker + 2 /listener + +Now the first shell should show repeated output for each received message. + +Run-time composition using ROS services with a server and client +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The example with a server and a client is very similar. + +In the first shell: + +.. code-block:: console + + $ ros2 run rclcpp_components component_container + +In the second shell (see `server `__ and `client `__ source code): + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Server + $ ros2 component load /ComponentManager composition composition::Client + +In this case the client sends a request to the server, the server processes the request and replies with a response, and the client prints the received response. + +Compile-time composition with hardcoded nodes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This demo shows that the same shared libraries can be reused to compile a single executable running multiple components without using ROS interfaces. +The executable contains all four components from above: talker and listener as well as server and client, which is hardcoded in the main function. + +In the shell call (see `source code `__): + +.. code-block:: console + + $ ros2 run composition manual_composition + +This should show repeated messages from both pairs, the talker and the listener as well as the server and the client. + +.. note:: + + Manually-composed components will not be reflected in the ``ros2 component list`` command line tool output. + +Run-time composition using dlopen +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This demo presents an alternative to run-time composition by creating a generic container process and explicitly passing the libraries to load without using ROS interfaces. +The process will open each library and create one instance of each "rclcpp::Node" class in the library (`source code `__). + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ ros2 run composition dlopen_composition `ros2 pkg prefix composition`/lib/libtalker_component.so `ros2 pkg prefix composition`/lib/liblistener_component.so + + .. group-tab:: macOS + + .. code-block:: console + + $ ros2 run composition dlopen_composition `ros2 pkg prefix composition`/lib/libtalker_component.dylib `ros2 pkg prefix composition`/lib/liblistener_component.dylib + + .. group-tab:: Windows + + .. code-block:: console + + $ ros2 pkg prefix composition + + to get the path to where composition is installed. + Then call + + .. code-block:: console + + $ ros2 run composition dlopen_composition \bin\talker_component.dll \bin\listener_component.dll + +Now the shell should show repeated output for each sent and received message. + +.. note:: + + dlopen-composed components will not be reflected in the ``ros2 component list`` command line tool output. + + +Composition using launch actions +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While the command line tools are useful for debugging and diagnosing component configurations, it is frequently more convenient to start a set of components at the same time. +To automate this action, we can use a `launch file `__: + +.. code-block:: console + + $ ros2 launch composition composition_demo_launch.py + + +Advanced Topics +--------------- + +Now that we have seen the basic operation of components, we can discuss a few more advanced topics. + +.. _ComponentContainerTypes: + +Component container types +^^^^^^^^^^^^^^^^^^^^^^^^^ + +As introduced in :ref:`ComponentContainer`, there are a few component container types with different options. +You can choose the most appropriate component container type for your requirement. + +* ``component_container`` with ``SingleThreadedExecutor``. + + .. code-block:: console + + $ ros2 run rclcpp_components component_container + +* ``component_container`` with ``MultiThreadedExecutor`` composed of 4 threads. + * ``thread_num`` parameter option is available to specify the number of threads in ``MultiThreadedExecutor``. + If omitted, the executor will run with the maximum available threads on the system. + + .. code-block:: console + + $ ros2 run rclcpp_components component_container --executor-type multi-threaded --ros-args -p thread_num:=4 + +* ``component_container`` with ``EventsCBGExecutor`` composed of a single thread. + * ``thread_num`` parameter option is available to specify the number of threads in ``EventsCBGExecutor``. + If omitted, the executor will run with the maximum available threads on the system. + + .. code-block:: console + + $ ros2 run rclcpp_components component_container --executor-type events-cbg --ros-args -p thread_num:=1 + +* ``component_container`` with a dedicated ``MultiThreadedExecutor`` for each component. + + .. code-block:: console + + $ ros2 run rclcpp_components component_container --executor-type multi-threaded --isolated + +Unloading components +^^^^^^^^^^^^^^^^^^^^ + +In the first shell, start the component container: + +.. code-block:: console + + $ ros2 run rclcpp_components component_container + +Verify that the container is running via ``ros2`` command line tools: + +.. code-block:: console + + $ ros2 component list + /ComponentManager + +In the second shell load both the talker and listener as we have before: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker + Loaded component 1 into '/ComponentManager' container node as '/talker' + $ ros2 component load /ComponentManager composition composition::Listener + Loaded component 2 into '/ComponentManager' container node as '/listener' + +The unique ID of a component is printed when it gets loaded. +You can also get the unique IDs of all components by just listing them now that they are loaded: + +.. code-block:: console + + $ ros2 component list + /ComponentManager + 1 /talker + 2 /listener + +Use the unique ID to unload the component from the component container. + +.. code-block:: console + + $ ros2 component unload /ComponentManager 1 2 + Unloaded component 1 from '/ComponentManager' container + Unloaded component 2 from '/ComponentManager' container + +In the first shell, verify that the repeated messages from talker and listener have stopped. + + +Remapping container name and namespace +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The component manager name and namespace can be remapped via standard command line arguments: + +.. code-block:: console + + $ ros2 run rclcpp_components component_container --ros-args -r __node:=MyContainer -r __ns:=/ns + +In a second shell, components can be loaded by using the updated container name: + +.. code-block:: console + + $ ros2 component load /ns/MyContainer composition composition::Listener + +.. note:: + + Namespace remappings of the container do not affect loaded components. + + +Remap component names and namespaces +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Component names and namespaces may be adjusted via arguments to the load command. + +In the first shell, start the component container: + +.. code-block:: console + + $ ros2 run rclcpp_components component_container + + +Some examples of how to remap names and namespaces. + +Remap node name: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker --node-name talker2 + +Remap namespace: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker --node-namespace /ns + +Remap both: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker --node-name talker3 --node-namespace /ns2 + +Now use ``ros2`` command line utility: + +.. code-block:: console + + $ ros2 component list + /ComponentManager + 1 /talker2 + 2 /ns/talker + 3 /ns2/talker3 + +.. note:: + + Namespace remappings of the container do not affect loaded components. + +Passing parameter values into components +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``ros2 component load`` command-line supports passing arbitrary parameters to the node as it is constructed. +This functionality can be used as follows: + +.. code-block:: console + + $ ros2 component load /ComponentManager image_tools image_tools::Cam2Image -p burger_mode:=true + $ ros2 run rqt_image_view rqt_image_view # Shows burgers bouncing, instead of image from camera + +Passing additional arguments into components +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``ros2 component load`` command-line supports passing particular options to the component manager for use when constructing the node. + +The following example shows the use of the extra arguments ``use_intra_process_comms`` and ``forward_global_arguments``: + +.. code-block:: console + + $ ros2 component load /ComponentManager composition composition::Talker -e use_intra_process_comms:=true -e forward_global_arguments:=false + +The following extra arguments are supported. + +.. list-table:: Extra Arguments for Component Manager + :widths: 15 15 15 15 + :header-rows: 1 + + * - Argument + - Type + - Default + - Description + * - ``forward_global_arguments`` + - Boolean + - True + - Apply global arguments to the component node when loading. + * - ``enable_rosout`` + - Boolean + - True + - Enable the ``rosout`` topic publisher in the component node. + * - ``use_intra_process_comms`` + - Boolean + - False + - Enable intra-process communication in the component node. + * - ``enable_topic_statistics`` + - Boolean + - False + - Enable a topic statistics publisher in the component node. + * - ``start_parameter_services`` + - Boolean + - True + - Enable services to manage parameters in the component node. + * - ``start_parameter_event_publisher`` + - Boolean + - True + - Enable the parameter event publisher in the component node. + * - ``use_clock_thread`` + - Boolean + - True + - Enable a dedicated clock thread in the component node. + * - ``enable_logger_service`` + - Boolean + - False + - Enable logger level management service in the component node. + + +Composable nodes as shared libraries +------------------------------------ + +If you want to export a composable node as a shared library from a package and use that node in another package that does link-time composition, add code to the CMake file which imports the actual targets in downstream packages. + +Then install the generated file and export the generated file. + +A practical example can be seen here: `ROS Discourse - Ament best practice for sharing libraries `__ + +Composing Non-Node Derived Components +------------------------------------- + +In ROS 2, components allow for more efficient use of system resources and provide a powerful feature that enables you to create reusable functionality that is not tied to a specific node. + +One advantage of using components is that they allow you to create non-node derived functionality as standalone executables or shared libraries that can be loaded into the ROS system as needed. + +To create a component that is not derived from a node, follow these guidelines: + +1. Implement a constructor that takes ``const rclcpp::NodeOptions&`` as its argument. +2. Implement the ``get_node_base_interface()`` method, which should return a ``NodeBaseInterface::SharedPtr``. + You can use the ``get_node_base_interface()`` method of a node that you create in your constructor to provide this interface. + +Here's an example of a component that is not derived from a node, which listens to a ROS topic: `node_like_listener_component `__. + +For more information on this topic, you can refer to this `discussion `__. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst index 52da78b1dad..85e9705389e 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst @@ -1,105 +1,106 @@ -.. redirect-from:: - - Tutorials/Launch/CLI-Intro - -.. _ROS2Launch: - -Launching nodes -=============== - -**Goal:** Use a command line tool to launch multiple nodes at once. - -**Tutorial Level:** Beginner - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In most of the introductory tutorials, you have been opening new terminals for every new node you run. -As you create more complex systems with more and more nodes running simultaneously, opening terminals and reentering configuration details becomes tedious. - -Launch files allow you to start up and configure a number of executables containing ROS 2 nodes simultaneously. - -Running a single launch file with the ``ros2 launch`` command will start up your entire system - all nodes and their configurations - at once. - -Prerequisites -------------- - -Before starting these tutorials, install ROS 2 by following the instructions on the ROS 2 :doc:`../../../Installation/` page. - -The commands used in this tutorial assume you followed the binary packages installation guide for your operating system (deb packages for Linux). -You can still follow along if you built from source, but the path to your setup files will likely be different. -You also won't be able to use the ``sudo apt install ros--`` command (used frequently in the beginner level tutorials) if you install from source. - -If you are using Linux and are not already familiar with the shell, `this tutorial `__ will help. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - -Tasks ------ - -Running a Launch File -^^^^^^^^^^^^^^^^^^^^^ - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 launch turtlesim multisim.launch.py - -This command will run the following launch file: - -.. literalinclude:: launch/multisim.launch.py - :language: python - -.. note:: - - The launch file above is written in Python, but you can also use XML and YAML to create launch files. - You can see a comparison of these different ROS 2 launch formats in :doc:`../../../How-To-Guides/Launch-file-different-formats`. - -This will run two turtlesim nodes: - -.. image:: images/turtlesim_multisim.png - -For now, don't worry about the contents of this launch file. -You can find more information on ROS 2 launch in the :doc:`ROS 2 launch tutorials <../../Intermediate/Launch/Launch-Main>`. - -(Optional) Control the Turtlesim Nodes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now that these nodes are running, you can control them like any other ROS 2 nodes. -For example, you can make the turtles drive in opposite directions by opening up two additional terminals and running the following commands: - -In the second terminal: - -.. code-block:: console - - $ ros2 topic pub /turtlesim1/turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - -In the third terminal: - -.. code-block:: console - - $ ros2 topic pub /turtlesim2/turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: -1.8}}" - -After running these commands, you should see something like the following: - -.. image:: images/turtlesim_multisim_spin.png - -Summary -------- - -The significance of what you've done so far is that you've run two turtlesim nodes with one command. -Once you learn to write your own launch files, you'll be able to run multiple nodes - and set up their configuration - in a similar way, with the ``ros2 launch`` command. - -For more tutorials on ROS 2 launch files, see the :doc:`main launch file tutorial page<../../Intermediate/Launch/Launch-Main>`. - -Next steps ----------- - -In the next tutorial, :doc:`../Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data`, you'll learn about another helpful tool, ``ros2 bag``. +.. redirect-from:: + + Tutorials/Launch/CLI-Intro + Tutorials/Beginner-CLI-Tools/Launching-Multiple-Nodes/Launching-Multiple-Nodes + +.. _ROS2Launch: + +Launching nodes +=============== + +**Goal:** Use a command line tool to launch multiple nodes at once. + +**Tutorial Level:** Beginner + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In most of the introductory tutorials, you have been opening new terminals for every new node you run. +As you create more complex systems with more and more nodes running simultaneously, opening terminals and reentering configuration details becomes tedious. + +Launch files allow you to start up and configure a number of executables containing ROS 2 nodes simultaneously. + +Running a single launch file with the ``ros2 launch`` command will start up your entire system - all nodes and their configurations - at once. + +Prerequisites +------------- + +Before starting these tutorials, install ROS 2 by following the instructions on the ROS 2 :doc:`../../../../Get-Started/Installation` page. + +The commands used in this tutorial assume you followed the binary packages installation guide for your operating system (deb packages for Linux). +You can still follow along if you built from source, but the path to your setup files will likely be different. +You also won't be able to use the ``sudo apt install ros--`` command (used frequently in the beginner level tutorials) if you install from source. + +If you are using Linux and are not already familiar with the shell, `this tutorial `__ will help. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +Running a Launch File +^^^^^^^^^^^^^^^^^^^^^ + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 launch turtlesim multisim.launch.py + +This command will run the following launch file: + +.. literalinclude:: launch/multisim.launch.py + :language: python + +.. note:: + + The launch file above is written in Python, but you can also use XML and YAML to create launch files. + You can see a comparison of these different ROS 2 launch formats in :doc:`../../../../Developer-Tools/Launch/Launch-file-different-formats`. + +This will run two turtlesim nodes: + +.. image:: images/turtlesim_multisim.png + +For now, don't worry about the contents of this launch file. +You can find more information on ROS 2 launch in the :doc:`ROS 2 launch tutorials <../../../../Developer-Tools/Launch/Launch-Main>`. + +(Optional) Control the Turtlesim Nodes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now that these nodes are running, you can control them like any other ROS 2 nodes. +For example, you can make the turtles drive in opposite directions by opening up two additional terminals and running the following commands: + +In the second terminal: + +.. code-block:: console + + $ ros2 topic pub /turtlesim1/turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + +In the third terminal: + +.. code-block:: console + + $ ros2 topic pub /turtlesim2/turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: -1.8}}" + +After running these commands, you should see something like the following: + +.. image:: images/turtlesim_multisim_spin.png + +Summary +------- + +The significance of what you've done so far is that you've run two turtlesim nodes with one command. +Once you learn to write your own launch files, you'll be able to run multiple nodes - and set up their configuration - in a similar way, with the ``ros2 launch`` command. + +For more tutorials on ROS 2 launch files, see the :doc:`main launch file tutorial page <../../../../Developer-Tools/Launch/Launch-Main>`. + +Next steps +---------- + +In the next tutorial, :doc:`../../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data`, you'll learn about another helpful tool, ``ros2 bag``. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst index c3916226f40..1370ccfc609 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst @@ -1,54 +1,55 @@ -.. redirect-from:: - - Managed-Nodes - Tutorials/Managed-Nodes - -Managing node lifecycles - example -================================== - -Managed lifecycles for nodes allow greater control over the state of the ROS system. -This example uses a simple talker/listener pair of managed nodes to show how a managed lifecycle can be implemented and used. -You can use the example to understand and experiment with managing nodes in this way. - -**Area: ROS-framework | Content-type: example | Experience: expert** - -.. contents:: Contents - :depth: 2 - :local: - -Summary -------- - -ROS 2 introduces the concept of managed nodes, also called lifecycle nodes. -These nodes can be used to ensure that resources are correctly initialised, activated, deactivated, and cleaned up as the node moves between lifecycle states. -A common use case is nodes that control hardware, where devices such as cameras, lidars, motor drivers, and other sensors and actuators must be started, configured, and shut down in a controlled order. - -Using lifecycle nodes helps ensure hardware is only initialised when it is ready, and is safely released during shutdown or error recovery. -The following packages enable you to implement these managed nodes: `rclcpp_lifecycle `__ (implementation library) and `lifecycle_msgs `__ (interface definitions). - -Prerequisites -------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -Example -------- - -Access the example -^^^^^^^^^^^^^^^^^^ - -Information on how to run the example is here: `lifecycle_demo_launch.py `__ - -Commentary -^^^^^^^^^^ - -For more information about how to run it and what's happening, see: `lifecycle README `__ - -Related content ---------------- - -Packages/reference: - -* `rclcpp_lifecycle `_ (implementation library): Package containing a prototype for lifecycle implementation. -* `lifecycle_msgs `_ (interface definitions): Package containing some lifecycle related message and service definitions. -* `lifecycle `_: Package containing demos for lifecycle implementation. +.. redirect-from:: + + Managed-Nodes + Tutorials/Managed-Nodes + Tutorials/Demos/Managed-Nodes + +Managing node lifecycles - example +================================== + +Managed lifecycles for nodes allow greater control over the state of the ROS system. +This example uses a simple talker/listener pair of managed nodes to show how a managed lifecycle can be implemented and used. +You can use the example to understand and experiment with managing nodes in this way. + +**Area: ROS-framework | Content-type: example | Experience: expert** + +.. contents:: Contents + :depth: 2 + :local: + +Summary +------- + +ROS 2 introduces the concept of managed nodes, also called lifecycle nodes. +These nodes can be used to ensure that resources are correctly initialised, activated, deactivated, and cleaned up as the node moves between lifecycle states. +A common use case is nodes that control hardware, where devices such as cameras, lidars, motor drivers, and other sensors and actuators must be started, configured, and shut down in a controlled order. + +Using lifecycle nodes helps ensure hardware is only initialised when it is ready, and is safely released during shutdown or error recovery. +The following packages enable you to implement these managed nodes: `rclcpp_lifecycle `__ (implementation library) and `lifecycle_msgs `__ (interface definitions). + +Prerequisites +------------- + +See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. + +Example +------- + +Access the example +^^^^^^^^^^^^^^^^^^ + +Information on how to run the example is here: `lifecycle_demo_launch.py `__ + +Commentary +^^^^^^^^^^ + +For more information about how to run it and what's happening, see: `lifecycle README `__ + +Related content +--------------- + +Packages/reference: + +* `rclcpp_lifecycle `_ (implementation library): Package containing a prototype for lifecycle implementation. +* `lifecycle_msgs `_ (interface definitions): Package containing some lifecycle related message and service definitions. +* `lifecycle `_: Package containing demos for lifecycle implementation. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst index 15542dd9deb..3065dda2060 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst @@ -1,196 +1,197 @@ -.. redirect-from:: - - Tutorials/Understanding-ROS2-Nodes - -.. _ROS2Nodes: - -Understanding nodes -=================== - -**Goal:** Learn about the function of nodes in ROS 2, and the tools to interact with them. - -**Tutorial level:** Beginner - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -1 The ROS 2 graph -^^^^^^^^^^^^^^^^^ - -Over the next few tutorials, you will learn about a series of core ROS 2 concepts that make up what is referred to as the "ROS (2) graph". - -The ROS graph is a network of ROS 2 elements processing data together at the same time. -It encompasses all executables and the connections between them if you were to map them all out and visualize them. - -2 Nodes in ROS 2 -^^^^^^^^^^^^^^^^ - -Each node in ROS should be responsible for a single, modular purpose, e.g. controlling the wheel motors or publishing the sensor data from a laser range-finder. -Each node can send and receive data from other nodes via topics, services, actions, or parameters. - -.. image:: images/Nodes-TopicandService.gif - -A full robotic system is comprised of many nodes working in concert. -In ROS 2, a single executable (C++ program, Python program, etc.) can contain one or more nodes. - -Prerequisites -------------- - -The :doc:`previous tutorial <../Introducing-Turtlesim/Introducing-Turtlesim>` shows you how to install the ``turtlesim`` package used here. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - -Tasks ------ - -1 ros2 run -^^^^^^^^^^ - -The command ``ros2 run`` launches an executable from a package. - -.. code-block:: console - - $ ros2 run - -To run turtlesim, open a new terminal, and enter the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -The turtlesim window will open, as you saw in the :doc:`previous tutorial <../Introducing-Turtlesim/Introducing-Turtlesim>`. - -Here, the package name is ``turtlesim`` and the executable name is ``turtlesim_node``. - -We still don't know the node name, however. -You can find node names by using ``ros2 node list`` - -2 ros2 node list -^^^^^^^^^^^^^^^^ - -``ros2 node list`` will show you the names of all running nodes. -This is especially useful when you want to interact with a node, or when you have a system running many nodes and need to keep track of them. - -Open a new terminal while turtlesim is still running in the other one, and enter the following command. -The terminal will return the node name: - -.. code-block:: console - - $ ros2 node list - /turtlesim - -Open another new terminal and start the teleop node with the command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Here, we are referring to the ``turtlesim`` package again, but this time we target the executable named ``turtle_teleop_key``. - -Return to the terminal where you ran ``ros2 node list`` and run it again. -You will now see the names of two active nodes: - -.. code-block:: console - - $ ros2 node list - /turtlesim - /teleop_turtle - -2.1 Remapping -~~~~~~~~~~~~~ - -`Remapping `__ allows you to reassign default node properties, like node name, topic names, service names, etc., to custom values. -In the last tutorial, you used remapping on ``turtle_teleop_key`` to change the cmd_vel topic and target **turtle2**. - -Now, let's reassign the name of our ``/turtlesim`` node. -In a new terminal, run the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node --ros-args --remap __node:=my_turtle - -Since you're calling ``ros2 run`` on turtlesim again, another turtlesim window will open. -However, now if you return to the terminal where you ran ``ros2 node list``, and run it again, you will see three node names: - -.. code-block:: console - - /my_turtle - /turtlesim - /teleop_turtle - -3 ros2 node info -^^^^^^^^^^^^^^^^ - -Now that you know the names of your nodes, you can access more information about them with: - -.. code-block:: console - - $ ros2 node info - -To examine your latest node, ``my_turtle``, run the following command: - -.. code-block:: console - - $ ros2 node info /my_turtle - /my_turtle - Subscribers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /turtle1/cmd_vel: geometry_msgs/msg/Twist - Publishers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /rosout: rcl_interfaces/msg/Log - /turtle1/color_sensor: turtlesim_msgs/msg/Color - /turtle1/pose: turtlesim_msgs/msg/Pose - Service Servers: - /clear: std_srvs/srv/Empty - /kill: turtlesim_msgs/srv/Kill - /my_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters - /my_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes - /my_turtle/get_parameters: rcl_interfaces/srv/GetParameters - /my_turtle/list_parameters: rcl_interfaces/srv/ListParameters - /my_turtle/set_parameters: rcl_interfaces/srv/SetParameters - /my_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically - /reset: std_srvs/srv/Empty - /spawn: turtlesim_msgs/srv/Spawn - /turtle1/set_pen: turtlesim_msgs/srv/SetPen - /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute - /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative - Service Clients: - - Action Servers: - /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute - Action Clients: - -``ros2 node info`` returns a list of subscribers, publishers, services, and actions. -i.e. the ROS graph connections that interact with that node. - -Now try running the same command on the ``/teleop_turtle`` node, and see how its connections differ from ``my_turtle``. - -You will learn more about the ROS graph connection concepts including the message types in the upcoming tutorials. - -Summary -------- - -A node is a fundamental ROS 2 element that serves a single, modular purpose in a robotics system. - -In this tutorial, you utilized nodes created in the ``turtlesim`` package by running the executables ``turtlesim_node`` and ``turtle_teleop_key``. - -You learned how to use ``ros2 node list`` to discover active node names and ``ros2 node info`` to introspect a single node. -These tools are vital to understanding the flow of data in a complex, real-world robot system. - -Next steps ----------- - -Now that you understand nodes in ROS 2, you can move on to the :doc:`topics tutorial <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. -Topics are one of the communication types that connects nodes. - -Related content ---------------- - -The :doc:`../../../Concepts` page adds some more detail to the concept of nodes. +.. redirect-from:: + + Tutorials/Understanding-ROS2-Nodes + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes + +.. _ROS2Nodes: + +Understanding nodes +=================== + +**Goal:** Learn about the function of nodes in ROS 2, and the tools to interact with them. + +**Tutorial level:** Beginner + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +1 The ROS 2 graph +^^^^^^^^^^^^^^^^^ + +Over the next few tutorials, you will learn about a series of core ROS 2 concepts that make up what is referred to as the "ROS (2) graph". + +The ROS graph is a network of ROS 2 elements processing data together at the same time. +It encompasses all executables and the connections between them if you were to map them all out and visualize them. + +2 Nodes in ROS 2 +^^^^^^^^^^^^^^^^ + +Each node in ROS should be responsible for a single, modular purpose, e.g. controlling the wheel motors or publishing the sensor data from a laser range-finder. +Each node can send and receive data from other nodes via topics, services, actions, or parameters. + +.. image:: images/Nodes-TopicandService.gif + +A full robotic system is comprised of many nodes working in concert. +In ROS 2, a single executable (C++ program, Python program, etc.) can contain one or more nodes. + +Prerequisites +------------- + +The :doc:`previous tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` shows you how to install the ``turtlesim`` package used here. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 ros2 run +^^^^^^^^^^ + +The command ``ros2 run`` launches an executable from a package. + +.. code-block:: console + + $ ros2 run + +To run turtlesim, open a new terminal, and enter the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +The turtlesim window will open, as you saw in the :doc:`previous tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +Here, the package name is ``turtlesim`` and the executable name is ``turtlesim_node``. + +We still don't know the node name, however. +You can find node names by using ``ros2 node list`` + +2 ros2 node list +^^^^^^^^^^^^^^^^ + +``ros2 node list`` will show you the names of all running nodes. +This is especially useful when you want to interact with a node, or when you have a system running many nodes and need to keep track of them. + +Open a new terminal while turtlesim is still running in the other one, and enter the following command. +The terminal will return the node name: + +.. code-block:: console + + $ ros2 node list + /turtlesim + +Open another new terminal and start the teleop node with the command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Here, we are referring to the ``turtlesim`` package again, but this time we target the executable named ``turtle_teleop_key``. + +Return to the terminal where you ran ``ros2 node list`` and run it again. +You will now see the names of two active nodes: + +.. code-block:: console + + $ ros2 node list + /turtlesim + /teleop_turtle + +2.1 Remapping +~~~~~~~~~~~~~ + +`Remapping `__ allows you to reassign default node properties, like node name, topic names, service names, etc., to custom values. +In the last tutorial, you used remapping on ``turtle_teleop_key`` to change the cmd_vel topic and target **turtle2**. + +Now, let's reassign the name of our ``/turtlesim`` node. +In a new terminal, run the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node --ros-args --remap __node:=my_turtle + +Since you're calling ``ros2 run`` on turtlesim again, another turtlesim window will open. +However, now if you return to the terminal where you ran ``ros2 node list``, and run it again, you will see three node names: + +.. code-block:: console + + /my_turtle + /turtlesim + /teleop_turtle + +3 ros2 node info +^^^^^^^^^^^^^^^^ + +Now that you know the names of your nodes, you can access more information about them with: + +.. code-block:: console + + $ ros2 node info + +To examine your latest node, ``my_turtle``, run the following command: + +.. code-block:: console + + $ ros2 node info /my_turtle + /my_turtle + Subscribers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /turtle1/cmd_vel: geometry_msgs/msg/Twist + Publishers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /rosout: rcl_interfaces/msg/Log + /turtle1/color_sensor: turtlesim_msgs/msg/Color + /turtle1/pose: turtlesim_msgs/msg/Pose + Service Servers: + /clear: std_srvs/srv/Empty + /kill: turtlesim_msgs/srv/Kill + /my_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters + /my_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes + /my_turtle/get_parameters: rcl_interfaces/srv/GetParameters + /my_turtle/list_parameters: rcl_interfaces/srv/ListParameters + /my_turtle/set_parameters: rcl_interfaces/srv/SetParameters + /my_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically + /reset: std_srvs/srv/Empty + /spawn: turtlesim_msgs/srv/Spawn + /turtle1/set_pen: turtlesim_msgs/srv/SetPen + /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute + /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative + Service Clients: + + Action Servers: + /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute + Action Clients: + +``ros2 node info`` returns a list of subscribers, publishers, services, and actions. +i.e. the ROS graph connections that interact with that node. + +Now try running the same command on the ``/teleop_turtle`` node, and see how its connections differ from ``my_turtle``. + +You will learn more about the ROS graph connection concepts including the message types in the upcoming tutorials. + +Summary +------- + +A node is a fundamental ROS 2 element that serves a single, modular purpose in a robotics system. + +In this tutorial, you utilized nodes created in the ``turtlesim`` package by running the executables ``turtlesim_node`` and ``turtle_teleop_key``. + +You learned how to use ``ros2 node list`` to discover active node names and ``ros2 node info`` to introspect a single node. +These tools are vital to understanding the flow of data in a complex, real-world robot system. + +Next steps +---------- + +Now that you understand nodes in ROS 2, you can move on to the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. +Topics are one of the communication types that connects nodes. + +Related content +--------------- + +The :doc:`../../../../Concepts` page adds some more detail to the concept of nodes. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst index 84c2901ba5f..3a78dee8384 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst @@ -1,248 +1,252 @@ -Using the Node Interfaces Template Class (C++) -============================================== - -**Goal:** Learn how to access ``Node`` information using ``rclcpp::NodeInterfaces<>`` - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - - -Overview --------- - -Not all ROS Nodes are created equally! -The ``rclcpp::Node`` and ``rclcpp_lifecycle::LifecycleNode`` classes do not share an inheritance tree, which means ROS developers can run into compile time type issues when they want to write a function that takes in a ROS node pointer as an argument. -To address this issue, ``rclcpp`` includes the ``rclcpp::NodeInterfaces<>`` template type that should be used as the preferred convention for passing for both conventional and lifecycle nodes to functions. -This `ROSCon 2023 lightning talk `_ summarizes the issue and remedy succinctly. -The following tutorial will show you how to use ``rclcpp::NodeInterfaces<>`` as reliable and compact interface for all ROS node types. - -The ``rclcpp::NodeInterfaces<>`` template class provides a compact and efficient way to manage Node Interfaces in ROS 2. -This is particularly useful when working with different types of ``Nodes``, such as ``rclcpp::Node`` and ``rclcpp_lifecycle::LifecycleNode``, which do not share the same inheritance tree. - -1 Accessing Node Information with a ``SharedPtr`` -------------------------------------------------- - -In the example below, we create a simple ``Node`` called ``Simple_Node`` and define a function ``node_info`` that accepts a ``SharedPtr`` to the ``Node``. -The function retrieves and prints the name of the ``Node``. - -.. code-block:: c++ - - #include - #include "rclcpp/rclcpp.hpp" - - void node_info(rclcpp::Node::SharedPtr node) - { - RCLCPP_INFO(node->get_logger(), "Node name: %s", node->get_name()); - } - - class SimpleNode : public rclcpp::Node - { - public: - SimpleNode(const std::string & node_name) - : Node(node_name) - { - } - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - auto node = std::make_shared("Simple_Node"); - node_info(node); - } - -Output: - -.. code-block:: console - - [INFO] [Simple_Node]: Node name: Simple_Node - -While this approach works well for arguments of type ``rclcpp::Node``, it does not work for other node types like ``rclcpp_lifecycle::LifecycleNode``. - -2 Explicitly pass ``rclcpp::node_interfaces`` ---------------------------------------------- - -A more robust approach, applicable to all node types, is to explicitly pass ``rclcpp::node_interfaces`` as function arguments, as demonstrated in the example below. -In the example that follows, we create function called ``node_info`` that take as arguments two ``rclcpp::node_interfaces``, ``NodeBaseInterface`` and ``NodeLoggingInterface`` and prints the ``Node`` name. -We then create two nodes of type ``rclcpp_lifecycle::LifecycleNode`` and ``rclcpp::Node`` and pass their interfaces in ``node_info``. - -.. code-block:: c++ - - void node_info(std::shared_ptr base_interface, - std::shared_ptr logging_interface) - { - RCLCPP_INFO(logging_interface->get_logger(), "Node name: %s", base_interface->get_name()); - } - - class SimpleNode : public rclcpp::Node - { - public: - SimpleNode(const std::string & node_name) - : Node(node_name) - { - } - }; - - class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode - { - public: - explicit LifecycleTalker(const std::string & node_name, bool intra_process_comms = false) - : rclcpp_lifecycle::LifecycleNode(node_name, - rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms)) - {} - } - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::executors::SingleThreadedExecutor exe; - auto node = std::make_shared("Simple_Node"); - auto lc_node = std::make_shared("Simple_LifeCycle_Node"); - node_info(node->get_node_base_interface(),node->get_node_logging_interface()); - node_info(lc_node->get_node_base_interface(),lc_node->get_node_logging_interface()); - } - -Output: - -.. code-block:: console - - [INFO] [Simple_Node]: Node name: Simple_Node - [INFO] [Simple_LifeCycle_Node]: Node name: Simple_LifeCycle_Node - -As functions grow in complexity, the number of ``rclcpp::node_interfaces`` arguments also increases, leading to readability and compactness issues. -To make the code more flexible and compatible with different node types, we use ``rclcpp::NodeInterfaces<>``. - -3 Using ``rclcpp::NodeInterfaces<>`` ------------------------------------- - -The recommended way of accessing a ``Node`` type's information is through the ``Node Interfaces``. - -Below, similar to the previous example, a ``rclcpp_lifecycle::LifecycleNode`` and a ``rclcpp::Node`` are created. - -.. code-block:: c++ - - #include - #include - #include - #include "lifecycle_msgs/msg/transition.hpp" - #include "rclcpp/rclcpp.hpp" - #include "rclcpp_lifecycle/lifecycle_node.hpp" - #include "rclcpp_lifecycle/lifecycle_publisher.hpp" - #include "rclcpp/node_interfaces/node_interfaces.hpp" - - using MyNodeInterfaces = - rclcpp::node_interfaces::NodeInterfaces; - - void node_info(MyNodeInterfaces interfaces) - { - auto base_interface = interfaces.get_node_base_interface(); - auto logging_interface = interfaces.get_node_logging_interface(); - RCLCPP_INFO(logging_interface->get_logger(), "Node name: %s", base_interface->get_name()); - } - - class SimpleNode : public rclcpp::Node - { - public: - SimpleNode(const std::string & node_name) - : Node(node_name) - { - } - }; - - class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode - { - public: - explicit LifecycleTalker(const std::string & node_name, bool intra_process_comms = false) - : rclcpp_lifecycle::LifecycleNode(node_name, - rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms)) - {} - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::executors::SingleThreadedExecutor exe; - auto node = std::make_shared("Simple_Node"); - auto lc_node = std::make_shared("Simple_LifeCycle_Node"); - node_info(*node); - node_info(*lc_node); - } - -Output: - -.. code-block:: console - - [INFO] [Simple_Node]: Node name: Simple_Node - [INFO] [Simple_LifeCycle_Node]: Node name: Simple_LifeCycle_Node - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -.. code-block:: c++ - - using MyNodeInterfaces = - rclcpp::node_interfaces::NodeInterfaces; - - void node_info(MyNodeInterfaces interfaces) - { - auto base_interface = interfaces.get_node_base_interface(); - auto logging_interface = interfaces.get_node_logging_interface(); - RCLCPP_INFO(logging_interface->get_logger(), "Node name: %s", base_interface->get_name()); - } - -Instead of accepting ``SharedPtr`` or a node interface, this function takes a reference to a ``rclcpp::node_interfaces::NodeInterfaces`` object. -Another advantage of using this approach is the support for implicit conversion of node-like objects. -This means that it is possible to directly pass any node-like object to a function expecting a ``rclcpp::node_interfaces::NodeInterfaces`` object. - -It extracts: - -* ``NodeBaseInterface`` Provides basic node functionalities. -* ``NodeLoggingInterface`` Enables logging. - -Then, it retrieves and prints the node name. - -.. code-block:: c++ - - class SimpleNode : public rclcpp::Node - { - public: - SimpleNode(const std::string & node_name) - : Node(node_name) - { - } - }; - - class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode - { - public: - explicit LifecycleTalker(const std::string & node_name, bool intra_process_comms = false) - : rclcpp_lifecycle::LifecycleNode(node_name, - rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms)) - {} - }; - -Next, we create a ``rclcpp::Node`` as well as a ``rclcpp_lifecycle::LifecycleNode`` class. -The ``rclcpp_lifecycle::LifecycleNode`` class often includes functions for the state transitions ``Unconfigured``, ``Inactive``, ``Active``, and ``Finalized``. -However, they are not included for demonstration purposes. - -.. code-block:: c++ - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::executors::SingleThreadedExecutor exe; - auto node = std::make_shared("Simple_Node"); - auto lc_node = std::make_shared("Simple_LifeCycle_Node"); - node_info(*node); - node_info(*lc_node); - } - -In the main function, a ``SharedPtr`` to both ``rclcpp_lifecycle::LifecycleNode`` and ``rclcpp::Node`` is created. -The function declared above is called once with each node type as an argument. - -.. note:: The ``SharedPtr`` needs to be dereferenced as the template accepts a reference to the ``NodeT`` object. +.. redirect-from:: + + Tutorials/Intermediate/Using-Node-Interfaces-Template-Class + +Using the Node Interfaces Template Class (C++) +============================================== + +**Goal:** Learn how to access ``Node`` information using ``rclcpp::NodeInterfaces<>`` + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + + +Overview +-------- + +Not all ROS Nodes are created equally! +The ``rclcpp::Node`` and ``rclcpp_lifecycle::LifecycleNode`` classes do not share an inheritance tree, which means ROS developers can run into compile time type issues when they want to write a function that takes in a ROS node pointer as an argument. +To address this issue, ``rclcpp`` includes the ``rclcpp::NodeInterfaces<>`` template type that should be used as the preferred convention for passing for both conventional and lifecycle nodes to functions. +This `ROSCon 2023 lightning talk `_ summarizes the issue and remedy succinctly. +The following tutorial will show you how to use ``rclcpp::NodeInterfaces<>`` as reliable and compact interface for all ROS node types. + +The ``rclcpp::NodeInterfaces<>`` template class provides a compact and efficient way to manage Node Interfaces in ROS 2. +This is particularly useful when working with different types of ``Nodes``, such as ``rclcpp::Node`` and ``rclcpp_lifecycle::LifecycleNode``, which do not share the same inheritance tree. + +1 Accessing Node Information with a ``SharedPtr`` +------------------------------------------------- + +In the example below, we create a simple ``Node`` called ``Simple_Node`` and define a function ``node_info`` that accepts a ``SharedPtr`` to the ``Node``. +The function retrieves and prints the name of the ``Node``. + +.. code-block:: c++ + + #include + #include "rclcpp/rclcpp.hpp" + + void node_info(rclcpp::Node::SharedPtr node) + { + RCLCPP_INFO(node->get_logger(), "Node name: %s", node->get_name()); + } + + class SimpleNode : public rclcpp::Node + { + public: + SimpleNode(const std::string & node_name) + : Node(node_name) + { + } + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + auto node = std::make_shared("Simple_Node"); + node_info(node); + } + +Output: + +.. code-block:: console + + [INFO] [Simple_Node]: Node name: Simple_Node + +While this approach works well for arguments of type ``rclcpp::Node``, it does not work for other node types like ``rclcpp_lifecycle::LifecycleNode``. + +2 Explicitly pass ``rclcpp::node_interfaces`` +--------------------------------------------- + +A more robust approach, applicable to all node types, is to explicitly pass ``rclcpp::node_interfaces`` as function arguments, as demonstrated in the example below. +In the example that follows, we create function called ``node_info`` that take as arguments two ``rclcpp::node_interfaces``, ``NodeBaseInterface`` and ``NodeLoggingInterface`` and prints the ``Node`` name. +We then create two nodes of type ``rclcpp_lifecycle::LifecycleNode`` and ``rclcpp::Node`` and pass their interfaces in ``node_info``. + +.. code-block:: c++ + + void node_info(std::shared_ptr base_interface, + std::shared_ptr logging_interface) + { + RCLCPP_INFO(logging_interface->get_logger(), "Node name: %s", base_interface->get_name()); + } + + class SimpleNode : public rclcpp::Node + { + public: + SimpleNode(const std::string & node_name) + : Node(node_name) + { + } + }; + + class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode + { + public: + explicit LifecycleTalker(const std::string & node_name, bool intra_process_comms = false) + : rclcpp_lifecycle::LifecycleNode(node_name, + rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms)) + {} + } + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::executors::SingleThreadedExecutor exe; + auto node = std::make_shared("Simple_Node"); + auto lc_node = std::make_shared("Simple_LifeCycle_Node"); + node_info(node->get_node_base_interface(),node->get_node_logging_interface()); + node_info(lc_node->get_node_base_interface(),lc_node->get_node_logging_interface()); + } + +Output: + +.. code-block:: console + + [INFO] [Simple_Node]: Node name: Simple_Node + [INFO] [Simple_LifeCycle_Node]: Node name: Simple_LifeCycle_Node + +As functions grow in complexity, the number of ``rclcpp::node_interfaces`` arguments also increases, leading to readability and compactness issues. +To make the code more flexible and compatible with different node types, we use ``rclcpp::NodeInterfaces<>``. + +3 Using ``rclcpp::NodeInterfaces<>`` +------------------------------------ + +The recommended way of accessing a ``Node`` type's information is through the ``Node Interfaces``. + +Below, similar to the previous example, a ``rclcpp_lifecycle::LifecycleNode`` and a ``rclcpp::Node`` are created. + +.. code-block:: c++ + + #include + #include + #include + #include "lifecycle_msgs/msg/transition.hpp" + #include "rclcpp/rclcpp.hpp" + #include "rclcpp_lifecycle/lifecycle_node.hpp" + #include "rclcpp_lifecycle/lifecycle_publisher.hpp" + #include "rclcpp/node_interfaces/node_interfaces.hpp" + + using MyNodeInterfaces = + rclcpp::node_interfaces::NodeInterfaces; + + void node_info(MyNodeInterfaces interfaces) + { + auto base_interface = interfaces.get_node_base_interface(); + auto logging_interface = interfaces.get_node_logging_interface(); + RCLCPP_INFO(logging_interface->get_logger(), "Node name: %s", base_interface->get_name()); + } + + class SimpleNode : public rclcpp::Node + { + public: + SimpleNode(const std::string & node_name) + : Node(node_name) + { + } + }; + + class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode + { + public: + explicit LifecycleTalker(const std::string & node_name, bool intra_process_comms = false) + : rclcpp_lifecycle::LifecycleNode(node_name, + rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms)) + {} + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::executors::SingleThreadedExecutor exe; + auto node = std::make_shared("Simple_Node"); + auto lc_node = std::make_shared("Simple_LifeCycle_Node"); + node_info(*node); + node_info(*lc_node); + } + +Output: + +.. code-block:: console + + [INFO] [Simple_Node]: Node name: Simple_Node + [INFO] [Simple_LifeCycle_Node]: Node name: Simple_LifeCycle_Node + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +.. code-block:: c++ + + using MyNodeInterfaces = + rclcpp::node_interfaces::NodeInterfaces; + + void node_info(MyNodeInterfaces interfaces) + { + auto base_interface = interfaces.get_node_base_interface(); + auto logging_interface = interfaces.get_node_logging_interface(); + RCLCPP_INFO(logging_interface->get_logger(), "Node name: %s", base_interface->get_name()); + } + +Instead of accepting ``SharedPtr`` or a node interface, this function takes a reference to a ``rclcpp::node_interfaces::NodeInterfaces`` object. +Another advantage of using this approach is the support for implicit conversion of node-like objects. +This means that it is possible to directly pass any node-like object to a function expecting a ``rclcpp::node_interfaces::NodeInterfaces`` object. + +It extracts: + +* ``NodeBaseInterface`` Provides basic node functionalities. +* ``NodeLoggingInterface`` Enables logging. + +Then, it retrieves and prints the node name. + +.. code-block:: c++ + + class SimpleNode : public rclcpp::Node + { + public: + SimpleNode(const std::string & node_name) + : Node(node_name) + { + } + }; + + class LifecycleTalker : public rclcpp_lifecycle::LifecycleNode + { + public: + explicit LifecycleTalker(const std::string & node_name, bool intra_process_comms = false) + : rclcpp_lifecycle::LifecycleNode(node_name, + rclcpp::NodeOptions().use_intra_process_comms(intra_process_comms)) + {} + }; + +Next, we create a ``rclcpp::Node`` as well as a ``rclcpp_lifecycle::LifecycleNode`` class. +The ``rclcpp_lifecycle::LifecycleNode`` class often includes functions for the state transitions ``Unconfigured``, ``Inactive``, ``Active``, and ``Finalized``. +However, they are not included for demonstration purposes. + +.. code-block:: c++ + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::executors::SingleThreadedExecutor exe; + auto node = std::make_shared("Simple_Node"); + auto lc_node = std::make_shared("Simple_LifeCycle_Node"); + node_info(*node); + node_info(*lc_node); + } + +In the main function, a ``SharedPtr`` to both ``rclcpp_lifecycle::LifecycleNode`` and ``rclcpp::Node`` is created. +The function declared above is called once with each node type as an argument. + +.. note:: The ``SharedPtr`` needs to be dereferenced as the template accepts a reference to the ``NodeT`` object. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst index 2ff4b5ceea3..b9e7811a2ed 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst @@ -1,132 +1,133 @@ -.. redirect-from:: - - Tutorials/Rqt-Console/Using-Rqt-Console - -.. _rqt_console: - -Using ``rqt_console`` to view logs -================================== - -**Goal:** Get to know ``rqt_console``, a tool for introspecting log messages. - -**Tutorial level:** Beginner - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``rqt_console`` is a GUI tool used to introspect log messages in ROS 2. -Typically, log messages show up in your terminal. -With ``rqt_console``, you can collect those messages over time, view them closely and in a more organized manner, filter them, save them and even reload the saved files to introspect at a different time. - -Nodes use logs to output messages concerning events and status in a variety of ways. -Their content is usually informational, for the sake of the user. - -Prerequisites -------------- - -You will need :doc:`rqt_console and turtlesim <../Introducing-Turtlesim/Introducing-Turtlesim>` installed. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - - -Tasks ------ - -1 Setup -^^^^^^^ - -Start ``rqt_console`` in a new terminal with the following command: - -.. code-block:: console - - $ ros2 run rqt_console rqt_console - -The ``rqt_console`` window will open: - -.. image:: images/console.png - -The first section of the console is where log messages from your system will display. - -In the middle you have the option to filter messages by excluding severity levels. -You can also add more exclusion filters using the plus-sign button to the right. - -The bottom section is for highlighting messages that include a string you input. -You can add more filters to this section as well. - -Now start ``turtlesim`` in a new terminal with the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -2 Messages on rqt_console -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To produce log messages for ``rqt_console`` to display, let's have the turtle run into the wall. -In a new terminal, enter the ``ros2 topic pub`` command (discussed in detail in the :doc:`topics tutorial <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`) below: - -.. code-block:: console - - $ ros2 topic pub -r 1 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}" - -Since the above command is publishing the topic at a steady rate, the turtle is continuously running into the wall. -In ``rqt_console`` you will see the same message with the ``Warn`` severity level displayed over and over, like so: - -.. image:: images/warn.png - -Press ``Ctrl+C`` in the terminal where you ran the ``ros2 topic pub`` command to stop your turtle from running into the wall. - -3 Logger levels -^^^^^^^^^^^^^^^ - -ROS 2's logger levels are ordered by severity: - - 1. Fatal - 2. Error - 3. Warn - 4. Info - 5. Debug - -There is no exact standard for what each level indicates, but it's safe to assume that: - -* ``Fatal`` messages indicate the system is going to terminate to try to protect itself from detriment. -* ``Error`` messages indicate significant issues that won't necessarily damage the system, but are preventing it from functioning properly. -* ``Warn`` messages indicate unexpected activity or non-ideal results that might represent a deeper issue, but don't harm functionality outright. -* ``Info`` messages indicate event and status updates that serve as a visual verification that the system is running as expected. -* ``Debug`` messages detail the entire step-by-step process of the system execution. - -The default level is ``Info``. -You will only see messages of the default severity level and more-severe levels. - -Normally, only ``Debug`` messages are hidden because they're the only level less severe than ``Info``. -For example, if you set the default level to ``Warn``, you would only see messages of severity ``Warn``, ``Error``, and ``Fatal``. - -3.1 Set the default logger level -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can set the default logger level when you first run the ``/turtlesim`` node using remapping. -Enter the following command in your terminal: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node --ros-args --log-level WARN - -Now you won't see the initial ``Info`` level messages that came up in the console last time you started ``turtlesim``. -That's because ``Info`` messages are lower priority than the new default severity, ``Warn``. - -Summary -------- - -``rqt_console`` can be very helpful if you need to closely examine the log messages from your system. -You might want to examine log messages for any number of reasons, usually to find out where something went wrong and the series of events leading up to that. - -Next steps ----------- - -The next tutorial will teach you about starting multiple nodes at once with :doc:`ROS 2 Launch <../Launching-Multiple-Nodes/Launching-Multiple-Nodes>`. +.. redirect-from:: + + Tutorials/Rqt-Console/Using-Rqt-Console + Tutorials/Beginner-CLI-Tools/Using-Rqt-Console/Using-Rqt-Console + +.. _rqt_console: + +Using ``rqt_console`` to view logs +================================== + +**Goal:** Get to know ``rqt_console``, a tool for introspecting log messages. + +**Tutorial level:** Beginner + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``rqt_console`` is a GUI tool used to introspect log messages in ROS 2. +Typically, log messages show up in your terminal. +With ``rqt_console``, you can collect those messages over time, view them closely and in a more organized manner, filter them, save them and even reload the saved files to introspect at a different time. + +Nodes use logs to output messages concerning events and status in a variety of ways. +Their content is usually informational, for the sake of the user. + +Prerequisites +------------- + +You will need :doc:`rqt_console and turtlesim <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` installed. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + + +Tasks +----- + +1 Setup +^^^^^^^ + +Start ``rqt_console`` in a new terminal with the following command: + +.. code-block:: console + + $ ros2 run rqt_console rqt_console + +The ``rqt_console`` window will open: + +.. image:: images/console.png + +The first section of the console is where log messages from your system will display. + +In the middle you have the option to filter messages by excluding severity levels. +You can also add more exclusion filters using the plus-sign button to the right. + +The bottom section is for highlighting messages that include a string you input. +You can add more filters to this section as well. + +Now start ``turtlesim`` in a new terminal with the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +2 Messages on rqt_console +^^^^^^^^^^^^^^^^^^^^^^^^^ + +To produce log messages for ``rqt_console`` to display, let's have the turtle run into the wall. +In a new terminal, enter the ``ros2 topic pub`` command (discussed in detail in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`) below: + +.. code-block:: console + + $ ros2 topic pub -r 1 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}" + +Since the above command is publishing the topic at a steady rate, the turtle is continuously running into the wall. +In ``rqt_console`` you will see the same message with the ``Warn`` severity level displayed over and over, like so: + +.. image:: images/warn.png + +Press ``Ctrl+C`` in the terminal where you ran the ``ros2 topic pub`` command to stop your turtle from running into the wall. + +3 Logger levels +^^^^^^^^^^^^^^^ + +ROS 2's logger levels are ordered by severity: + + 1. Fatal + 2. Error + 3. Warn + 4. Info + 5. Debug + +There is no exact standard for what each level indicates, but it's safe to assume that: + +* ``Fatal`` messages indicate the system is going to terminate to try to protect itself from detriment. +* ``Error`` messages indicate significant issues that won't necessarily damage the system, but are preventing it from functioning properly. +* ``Warn`` messages indicate unexpected activity or non-ideal results that might represent a deeper issue, but don't harm functionality outright. +* ``Info`` messages indicate event and status updates that serve as a visual verification that the system is running as expected. +* ``Debug`` messages detail the entire step-by-step process of the system execution. + +The default level is ``Info``. +You will only see messages of the default severity level and more-severe levels. + +Normally, only ``Debug`` messages are hidden because they're the only level less severe than ``Info``. +For example, if you set the default level to ``Warn``, you would only see messages of severity ``Warn``, ``Error``, and ``Fatal``. + +3.1 Set the default logger level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can set the default logger level when you first run the ``/turtlesim`` node using remapping. +Enter the following command in your terminal: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node --ros-args --log-level WARN + +Now you won't see the initial ``Info`` level messages that came up in the console last time you started ``turtlesim``. +That's because ``Info`` messages are lower priority than the new default severity, ``Warn``. + +Summary +------- + +``rqt_console`` can be very helpful if you need to closely examine the log messages from your system. +You might want to examine log messages for any number of reasons, usually to find out where something went wrong and the series of events leading up to that. + +Next steps +---------- + +The next tutorial will teach you about starting multiple nodes at once with :doc:`ROS 2 Launch <../Launching-Multiple-Nodes/Launching-Multiple-Nodes>`. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst index dcc8473bcf0..9023216154a 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst @@ -1,578 +1,582 @@ -Using Callback Groups -===================== - -When running a node in a Multi-Threaded Executor, ROS 2 offers callback -groups as a tool for controlling the execution of different callbacks. -This page is meant as a guide on how to use callback groups efficiently. -It is assumed that the reader has a basic understanding -about the concept of :doc:`executors <../Concepts/Intermediate/About-Executors>`. - -.. contents:: Table of Contents - :local: - -Basics of callback groups -------------------------- - -When running a node in a Multi-Threaded Executor, -ROS 2 offers two different types of callback groups for controlling -execution of callbacks: - -* Mutually Exclusive Callback Group -* Reentrant Callback Group - -These callback groups restrict the execution of their callbacks in -different ways. -In short: - -* Mutually Exclusive Callback Group prevents its callbacks from being - executed in parallel - essentially making it as if the callbacks in the group - were executed by a SingleThreadedExecutor. -* Reentrant Callback Group allows the executor to schedule and execute - the group's callbacks in any way it sees fit, without restrictions. - This means that, in addition to different callbacks being run parallel - to each other, different instances of the same callback may also be - executed concurrently. -* Callbacks belonging to different callback groups (of any type) can always - be executed parallel to each other. - -It is also important to keep in mind that different ROS 2 entities relay -their callback group to all callbacks they spawn. -For example, if one assigns a callback group to an action client, -all callbacks created by the client will be assigned to that callback group. - -Callback groups can be created by a node's ``create_callback_group`` -function in rclcpp and by calling the constructor of the group in rclpy. -The callback group can then be passed as argument/option when creating a subscription, timer, etc. -A reference to the callback group should be retained, otherwise the callback -associated with the callback group will not be called by the executor. - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: cpp - - my_callback_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - - rclcpp::SubscriptionOptions options; - options.callback_group = my_callback_group; - - my_subscription = create_subscription("/topic", rclcpp::SensorDataQoS(), - callback, options); - - .. group-tab:: Python - - .. code-block:: python - - my_callback_group = MutuallyExclusiveCallbackGroup() - my_subscription = self.create_subscription(Int32, "/topic", self.callback, qos_profile=1, - callback_group=my_callback_group) - -If the user does not specify any callback group when creating a subscription, -timer, etc., this entity will be assigned to the node's default callback group. -The default callback group is a Mutually Exclusive Callback Group and it can be -queried via ``NodeBaseInterface::get_default_callback_group()`` in rclcpp and -via ``Node.default_callback_group`` in rclpy. - -About callbacks -^^^^^^^^^^^^^^^ - -In the context of ROS 2 and executors, a callback means a function whose -scheduling and execution is handled by an executor. -Examples of callbacks in this context are - -* subscription callbacks (receiving and handling data from a topic), -* timer callbacks, -* service callbacks (for executing service requests in a server), -* different callbacks in action servers and clients, -* done-callbacks of Futures. - -Below are a couple important points about callbacks that should be kept -in mind when working with callback groups. - -* Almost everything in ROS 2 is a callback! - Every function that is run by an executor is, by definition, a callback. - The non-callback functions in a ROS 2 system are found mainly at - the edge of the system (user and sensor inputs etc). -* Sometimes the callbacks are hidden and their presence may not be obvious - from the user/developer API. - This is the case especially with any kind of "synchronous" call to a - service or an action (in rclpy). - For example, the synchronous call ``Client.call(request)`` to a service - adds a Future's done-callback that needs to be executed during the - execution of the function call, but this callback is not directly - visible to the user. - - -Controlling execution ---------------------- - -In order to control execution with callback groups, one can consider the -following guidelines. - -For the interaction of an individual callback with itself: - -* Register it to a Reentrant Callback Group if it should be executed in parallel to itself. - An example case could be an action/service server that needs to be able to - process several action calls in parallel to each other. - -* Register it to a Mutually Exclusive Callback Group if it should **never** be executed in parallel to itself. - An example case could be a timer callback that runs a control loop that publishes control commands. - -For the interaction of different callbacks with each other: - -* Register them to the same Mutually Exclusive Callback Group if they should **never** be executed in parallel. - An example case could be that the callbacks are accessing shared critical and non-thread-safe resources. - -If they should be executed in parallel, you have two options, -depending on whether the individual callbacks should be able to overlap themselves or not: - -* Register them to different Mutually Exclusive Callback Groups (no overlap of the individual callbacks) - -* Register them to a Reentrant Callback Group (overlap of the individual callbacks) - -An example case of running different callbacks in parallel is a Node that has -a synchronous service client and a timer calling this service. -See the detailed example below. - -Avoiding deadlocks ------------------- - -Setting up callback groups of a node incorrectly can lead to deadlocks (or -other unwanted behavior), especially if one desires to use synchronous calls to -services or actions. -Indeed, even the API documentation of ROS 2 mentions that -synchronous calls to actions or services should not be done in callbacks, -because it can lead to deadlocks. -While using asynchronous calls is indeed safer in this regard, synchronous -calls can also be made to work. -On the other hand, synchronous calls also have their advantages, such as -making the code simpler and easier to understand. -Hence, this section provides some guidelines on how to set up a node's -callback groups correctly in order to avoid deadlocks. - -First thing to note here is that every node's default callback group is a -Mutually Exclusive Callback Group. -If the user does not specify any other callback group when creating a timer, -subscription, client etc., any callbacks created then or later by these -entities will use the node's default callback group. -Furthermore, if everything in a node uses the same Mutually Exclusive -Callback Group, that node essentially acts as if it was handled -by a Single-Threaded Executor, even if a multi-threaded one is specified! -Thus, whenever one decides to use a Multi-Threaded Executor, -some callback group(s) should always be specified in order for the -executor choice to make sense. - -With the above in mind, here are a couple guidelines to help avoid deadlocks: - -* If you make a synchronous call in any type of a callback, this callback and - the client making the call need to belong to - - * different callback groups (of any type), or - * a Reentrant Callback Group. - -* If the above configuration is not possible due to other requirements - such - as thread-safety and/or blocking of other callbacks while waiting for the - result (or if you want to make absolutely sure that there is never a - possibility of a deadlock), use asynchronous calls. - -Failing the first point will always cause a deadlock. -An example of such a case would be making a synchronous service call -in a timer callback (see the next section for an example). - - -Examples --------- - -Let us look at some simple examples of different callback group setups. -The following demo code considers calling a service synchronously in a timer -callback. - -Demo code -^^^^^^^^^ - -We have two nodes - one providing a simple service: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: cpp - - #include - #include "rclcpp/rclcpp.hpp" - #include "std_srvs/srv/empty.hpp" - - using namespace std::placeholders; - - namespace cb_group_demo - { - class ServiceNode : public rclcpp::Node - { - public: - ServiceNode() : Node("service_node") - { - auto service_callback = [this]( - const std::shared_ptr request_header, - const std::shared_ptr request, - const std::shared_ptr response) - { - (void)request_header; - (void)request; - (void)response; - RCLCPP_INFO(this->get_logger(), "Received request, responding..."); - }; - service_ptr_ = this->create_service( - "test_service", - service_callback - ); - } - - private: - rclcpp::Service::SharedPtr service_ptr_; - - }; // class ServiceNode - } // namespace cb_group_demo - - int main(int argc, char* argv[]) - { - rclcpp::init(argc, argv); - auto service_node = std::make_shared(); - - RCLCPP_INFO(service_node->get_logger(), "Starting server node, shut down with CTRL-C"); - rclcpp::spin(service_node); - RCLCPP_INFO(service_node->get_logger(), "Keyboard interrupt, shutting down.\n"); - - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - from std_srvs.srv import Empty - - class ServiceNode(Node): - def __init__(self): - super().__init__('service_node') - self.srv = self.create_service(Empty, 'test_service', callback=self.service_callback) - - def service_callback(self, request, result): - self.get_logger().info('Received request, responding...') - return result - - - if __name__ == '__main__': - try: - with rclpy.init(): - node = ServiceNode() - node.get_logger().info("Starting server node, shut down with CTRL-C") - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -and another containing a client to the service along with a timer for making -service calls: - -.. tabs:: - - .. group-tab:: C++ - - *Note:* The API of service client in rclcpp does not offer a - synchronous call method similar to the one in rclpy, so we - wait on the future object to simulate the effect of a - synchronous call. - - .. code-block:: cpp - - #include - #include - #include "rclcpp/rclcpp.hpp" - #include "std_srvs/srv/empty.hpp" - - using namespace std::chrono_literals; - - namespace cb_group_demo - { - class DemoNode : public rclcpp::Node - { - public: - DemoNode() : Node("client_node") - { - client_cb_group_ = nullptr; - timer_cb_group_ = nullptr; - client_ptr_ = this->create_client("test_service", rmw_qos_profile_services_default, - client_cb_group_); - - auto timer_callback = [this](){ - RCLCPP_INFO(this->get_logger(), "Sending request"); - auto request = std::make_shared(); - auto result_future = client_ptr_->async_send_request(request); - std::future_status status = result_future.wait_for(10s); // timeout to guarantee a graceful finish - if (status == std::future_status::ready) { - RCLCPP_INFO(this->get_logger(), "Received response"); - } - }; - - timer_ptr_ = this->create_wall_timer(1s, timer_callback, timer_cb_group_); - } - - private: - rclcpp::CallbackGroup::SharedPtr client_cb_group_; - rclcpp::CallbackGroup::SharedPtr timer_cb_group_; - rclcpp::Client::SharedPtr client_ptr_; - rclcpp::TimerBase::SharedPtr timer_ptr_; - - }; // class DemoNode - } // namespace cb_group_demo - - int main(int argc, char* argv[]) - { - rclcpp::init(argc, argv); - auto client_node = std::make_shared(); - rclcpp::executors::MultiThreadedExecutor executor; - executor.add_node(client_node); - - RCLCPP_INFO(client_node->get_logger(), "Starting client node, shut down with CTRL-C"); - executor.spin(); - RCLCPP_INFO(client_node->get_logger(), "Keyboard interrupt, shutting down.\n"); - - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException, MultiThreadedExecutor - from rclpy.callback_groups import MutuallyExclusiveCallbackGroup, ReentrantCallbackGroup - from rclpy.node import Node - from std_srvs.srv import Empty - - - class CallbackGroupDemo(Node): - def __init__(self): - super().__init__('client_node') - - client_cb_group = None - timer_cb_group = None - self.client = self.create_client(Empty, 'test_service', callback_group=client_cb_group) - self.call_timer = self.create_timer(1, self._timer_cb, callback_group=timer_cb_group) - - def _timer_cb(self): - self.get_logger().info('Sending request') - _ = self.client.call(Empty.Request()) - self.get_logger().info('Received response') - - - if __name__ == '__main__': - try: - with rclpy.init(): - node = CallbackGroupDemo() - executor = MultiThreadedExecutor() - executor.add_node(node) - - node.get_logger().info('Beginning client, shut down with CTRL-C') - executor.spin() - except (KeyboardInterrupt, ExternalShutdownException): - pass - -The client node's constructor contains options for setting the -callback groups of the service client and the timer. -With the default setting above (both being ``nullptr`` / ``None``), -both the timer and the client will use the node's default -Mutually Exclusive Callback Group. - -The problem -^^^^^^^^^^^ - -Since we are making service calls with a 1 second timer, the -expected outcome is that the service gets called once a second, -the client always gets a response and prints ``Received response``. -If we try running the server and client nodes -in terminals, we get the following outputs. - -.. tabs:: - - .. group-tab:: Client - - .. code-block:: console - - [INFO] [1653034371.758739131] [client_node]: Starting client node, shut down with CTRL-C - [INFO] [1653034372.755865649] [client_node]: Sending request - ^C[INFO] [1653034398.161674869] [client_node]: Keyboard interrupt, shutting down. - - .. group-tab:: Server - - .. code-block:: console - - [INFO] [1653034355.308958238] [service_node]: Starting server node, shut down with CTRL-C - [INFO] [1653034372.758197320] [service_node]: Received request, responding... - ^C[INFO] [1653034416.021962246] [service_node]: Keyboard interrupt, shutting down. - -So, it turns out that instead of the service being called repeatedly, -the response of the first call is never received, after which the -client node seemingly gets stuck and does not make further calls. -That is, the execution stopped at a deadlock! - -The reason for this is that the timer callback and the client are -using the same Mutually Exclusive Callback Group (the node's default). -When the service call is made, the client then passes its callback -group to the Future object (hidden inside the call-method in the -Python version) whose done-callback needs to execute for the result -of the service call to be available. -But because this done-callback and the timer callback are in the -same Mutually Exclusive group and the timer callback is still -executing (waiting for the result of the service call), -the done-callback never gets to execute. -The stuck timer callback also blocks any other executions of itself, so the -timer does not fire for a second time. - -Solution -^^^^^^^^ - -We can fix this easily - for example - by assigning the timer and client -to different callback groups. -Thus, let us change the first two lines of the client node's constructor -to be as follows (everything else shall stay the same): - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: cpp - - client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - timer_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - - .. group-tab:: Python - - .. code-block:: python - - client_cb_group = MutuallyExclusiveCallbackGroup() - timer_cb_group = MutuallyExclusiveCallbackGroup() - -Now we get the expected result, i.e. the timer fires repeatedly and -each service call gets the result as it should: - -.. tabs:: - - .. group-tab:: Client - - .. code-block:: console - - [INFO] [1653067523.431731177] [client_node]: Starting client node, shut down with CTRL-C - [INFO] [1653067524.431912821] [client_node]: Sending request - [INFO] [1653067524.433230445] [client_node]: Received response - [INFO] [1653067525.431869330] [client_node]: Sending request - [INFO] [1653067525.432912803] [client_node]: Received response - [INFO] [1653067526.431844726] [client_node]: Sending request - [INFO] [1653067526.432893954] [client_node]: Received response - [INFO] [1653067527.431828287] [client_node]: Sending request - [INFO] [1653067527.432848369] [client_node]: Received response - ^C[INFO] [1653067528.400052749] [client_node]: Keyboard interrupt, shutting down. - - .. group-tab:: Server - - .. code-block:: console - - [INFO] [1653067522.052866001] [service_node]: Starting server node, shut down with CTRL-C - [INFO] [1653067524.432577720] [service_node]: Received request, responding... - [INFO] [1653067525.432365009] [service_node]: Received request, responding... - [INFO] [1653067526.432300261] [service_node]: Received request, responding... - [INFO] [1653067527.432272441] [service_node]: Received request, responding... - ^C[INFO] [1653034416.021962246] [service_node]: KeyboardInterrupt, shutting down. - -One might consider if just avoiding the node's default callback group -is enough. -This is not the case: replacing the default group by a -different Mutually Exclusive group changes nothing. -Thus, the following configuration also leads to the previously -discovered deadlock. - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: cpp - - client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - timer_cb_group_ = client_cb_group_; - - .. group-tab:: Python - - .. code-block:: python - - client_cb_group = MutuallyExclusiveCallbackGroup() - timer_cb_group = client_cb_group - -In fact, the exact condition with which everything works in this case -is that the timer and client must not belong to the same -Mutually Exclusive group. -Hence, all of the following configurations (and some others as well) -produce the desired outcome where the timer fires -repeatedly and service calls are completed. - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: cpp - - client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::Reentrant); - timer_cb_group_ = client_cb_group_; - - or - - .. code-block:: cpp - - client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - timer_cb_group_ = nullptr; - - or - - .. code-block:: cpp - - client_cb_group_ = nullptr; - timer_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); - - or - - .. code-block:: cpp - - client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::Reentrant); - timer_cb_group_ = nullptr; - - .. group-tab:: Python - - .. code-block:: python - - client_cb_group = ReentrantCallbackGroup() - timer_cb_group = client_cb_group - - or - - .. code-block:: python - - client_cb_group = MutuallyExclusiveCallbackGroup() - timer_cb_group = None - - or - - .. code-block:: python - - client_cb_group = None - timer_cb_group = MutuallyExclusiveCallbackGroup() - - or - - .. code-block:: python - - client_cb_group = ReentrantCallbackGroup() - timer_cb_group = None +.. redirect-from:: + + How-To-Guides/Using-callback-groups + +Using Callback Groups +===================== + +When running a node in a Multi-Threaded Executor, ROS 2 offers callback +groups as a tool for controlling the execution of different callbacks. +This page is meant as a guide on how to use callback groups efficiently. +It is assumed that the reader has a basic understanding +about the concept of :doc:`executors <../../client-libraries/About-Executors/About-Executors>`. + +.. contents:: Table of Contents + :local: + +Basics of callback groups +------------------------- + +When running a node in a Multi-Threaded Executor, +ROS 2 offers two different types of callback groups for controlling +execution of callbacks: + +* Mutually Exclusive Callback Group +* Reentrant Callback Group + +These callback groups restrict the execution of their callbacks in +different ways. +In short: + +* Mutually Exclusive Callback Group prevents its callbacks from being + executed in parallel - essentially making it as if the callbacks in the group + were executed by a SingleThreadedExecutor. +* Reentrant Callback Group allows the executor to schedule and execute + the group's callbacks in any way it sees fit, without restrictions. + This means that, in addition to different callbacks being run parallel + to each other, different instances of the same callback may also be + executed concurrently. +* Callbacks belonging to different callback groups (of any type) can always + be executed parallel to each other. + +It is also important to keep in mind that different ROS 2 entities relay +their callback group to all callbacks they spawn. +For example, if one assigns a callback group to an action client, +all callbacks created by the client will be assigned to that callback group. + +Callback groups can be created by a node's ``create_callback_group`` +function in rclcpp and by calling the constructor of the group in rclpy. +The callback group can then be passed as argument/option when creating a subscription, timer, etc. +A reference to the callback group should be retained, otherwise the callback +associated with the callback group will not be called by the executor. + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: cpp + + my_callback_group = create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + + rclcpp::SubscriptionOptions options; + options.callback_group = my_callback_group; + + my_subscription = create_subscription("/topic", rclcpp::SensorDataQoS(), + callback, options); + + .. group-tab:: Python + + .. code-block:: python + + my_callback_group = MutuallyExclusiveCallbackGroup() + my_subscription = self.create_subscription(Int32, "/topic", self.callback, qos_profile=1, + callback_group=my_callback_group) + +If the user does not specify any callback group when creating a subscription, +timer, etc., this entity will be assigned to the node's default callback group. +The default callback group is a Mutually Exclusive Callback Group and it can be +queried via ``NodeBaseInterface::get_default_callback_group()`` in rclcpp and +via ``Node.default_callback_group`` in rclpy. + +About callbacks +^^^^^^^^^^^^^^^ + +In the context of ROS 2 and executors, a callback means a function whose +scheduling and execution is handled by an executor. +Examples of callbacks in this context are + +* subscription callbacks (receiving and handling data from a topic), +* timer callbacks, +* service callbacks (for executing service requests in a server), +* different callbacks in action servers and clients, +* done-callbacks of Futures. + +Below are a couple important points about callbacks that should be kept +in mind when working with callback groups. + +* Almost everything in ROS 2 is a callback! + Every function that is run by an executor is, by definition, a callback. + The non-callback functions in a ROS 2 system are found mainly at + the edge of the system (user and sensor inputs etc). +* Sometimes the callbacks are hidden and their presence may not be obvious + from the user/developer API. + This is the case especially with any kind of "synchronous" call to a + service or an action (in rclpy). + For example, the synchronous call ``Client.call(request)`` to a service + adds a Future's done-callback that needs to be executed during the + execution of the function call, but this callback is not directly + visible to the user. + + +Controlling execution +--------------------- + +In order to control execution with callback groups, one can consider the +following guidelines. + +For the interaction of an individual callback with itself: + +* Register it to a Reentrant Callback Group if it should be executed in parallel to itself. + An example case could be an action/service server that needs to be able to + process several action calls in parallel to each other. + +* Register it to a Mutually Exclusive Callback Group if it should **never** be executed in parallel to itself. + An example case could be a timer callback that runs a control loop that publishes control commands. + +For the interaction of different callbacks with each other: + +* Register them to the same Mutually Exclusive Callback Group if they should **never** be executed in parallel. + An example case could be that the callbacks are accessing shared critical and non-thread-safe resources. + +If they should be executed in parallel, you have two options, +depending on whether the individual callbacks should be able to overlap themselves or not: + +* Register them to different Mutually Exclusive Callback Groups (no overlap of the individual callbacks) + +* Register them to a Reentrant Callback Group (overlap of the individual callbacks) + +An example case of running different callbacks in parallel is a Node that has +a synchronous service client and a timer calling this service. +See the detailed example below. + +Avoiding deadlocks +------------------ + +Setting up callback groups of a node incorrectly can lead to deadlocks (or +other unwanted behavior), especially if one desires to use synchronous calls to +services or actions. +Indeed, even the API documentation of ROS 2 mentions that +synchronous calls to actions or services should not be done in callbacks, +because it can lead to deadlocks. +While using asynchronous calls is indeed safer in this regard, synchronous +calls can also be made to work. +On the other hand, synchronous calls also have their advantages, such as +making the code simpler and easier to understand. +Hence, this section provides some guidelines on how to set up a node's +callback groups correctly in order to avoid deadlocks. + +First thing to note here is that every node's default callback group is a +Mutually Exclusive Callback Group. +If the user does not specify any other callback group when creating a timer, +subscription, client etc., any callbacks created then or later by these +entities will use the node's default callback group. +Furthermore, if everything in a node uses the same Mutually Exclusive +Callback Group, that node essentially acts as if it was handled +by a Single-Threaded Executor, even if a multi-threaded one is specified! +Thus, whenever one decides to use a Multi-Threaded Executor, +some callback group(s) should always be specified in order for the +executor choice to make sense. + +With the above in mind, here are a couple guidelines to help avoid deadlocks: + +* If you make a synchronous call in any type of a callback, this callback and + the client making the call need to belong to + + * different callback groups (of any type), or + * a Reentrant Callback Group. + +* If the above configuration is not possible due to other requirements - such + as thread-safety and/or blocking of other callbacks while waiting for the + result (or if you want to make absolutely sure that there is never a + possibility of a deadlock), use asynchronous calls. + +Failing the first point will always cause a deadlock. +An example of such a case would be making a synchronous service call +in a timer callback (see the next section for an example). + + +Examples +-------- + +Let us look at some simple examples of different callback group setups. +The following demo code considers calling a service synchronously in a timer +callback. + +Demo code +^^^^^^^^^ + +We have two nodes - one providing a simple service: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: cpp + + #include + #include "rclcpp/rclcpp.hpp" + #include "std_srvs/srv/empty.hpp" + + using namespace std::placeholders; + + namespace cb_group_demo + { + class ServiceNode : public rclcpp::Node + { + public: + ServiceNode() : Node("service_node") + { + auto service_callback = [this]( + const std::shared_ptr request_header, + const std::shared_ptr request, + const std::shared_ptr response) + { + (void)request_header; + (void)request; + (void)response; + RCLCPP_INFO(this->get_logger(), "Received request, responding..."); + }; + service_ptr_ = this->create_service( + "test_service", + service_callback + ); + } + + private: + rclcpp::Service::SharedPtr service_ptr_; + + }; // class ServiceNode + } // namespace cb_group_demo + + int main(int argc, char* argv[]) + { + rclcpp::init(argc, argv); + auto service_node = std::make_shared(); + + RCLCPP_INFO(service_node->get_logger(), "Starting server node, shut down with CTRL-C"); + rclcpp::spin(service_node); + RCLCPP_INFO(service_node->get_logger(), "Keyboard interrupt, shutting down.\n"); + + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + from std_srvs.srv import Empty + + class ServiceNode(Node): + def __init__(self): + super().__init__('service_node') + self.srv = self.create_service(Empty, 'test_service', callback=self.service_callback) + + def service_callback(self, request, result): + self.get_logger().info('Received request, responding...') + return result + + + if __name__ == '__main__': + try: + with rclpy.init(): + node = ServiceNode() + node.get_logger().info("Starting server node, shut down with CTRL-C") + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +and another containing a client to the service along with a timer for making +service calls: + +.. tabs:: + + .. group-tab:: C++ + + *Note:* The API of service client in rclcpp does not offer a + synchronous call method similar to the one in rclpy, so we + wait on the future object to simulate the effect of a + synchronous call. + + .. code-block:: cpp + + #include + #include + #include "rclcpp/rclcpp.hpp" + #include "std_srvs/srv/empty.hpp" + + using namespace std::chrono_literals; + + namespace cb_group_demo + { + class DemoNode : public rclcpp::Node + { + public: + DemoNode() : Node("client_node") + { + client_cb_group_ = nullptr; + timer_cb_group_ = nullptr; + client_ptr_ = this->create_client("test_service", rmw_qos_profile_services_default, + client_cb_group_); + + auto timer_callback = [this](){ + RCLCPP_INFO(this->get_logger(), "Sending request"); + auto request = std::make_shared(); + auto result_future = client_ptr_->async_send_request(request); + std::future_status status = result_future.wait_for(10s); // timeout to guarantee a graceful finish + if (status == std::future_status::ready) { + RCLCPP_INFO(this->get_logger(), "Received response"); + } + }; + + timer_ptr_ = this->create_wall_timer(1s, timer_callback, timer_cb_group_); + } + + private: + rclcpp::CallbackGroup::SharedPtr client_cb_group_; + rclcpp::CallbackGroup::SharedPtr timer_cb_group_; + rclcpp::Client::SharedPtr client_ptr_; + rclcpp::TimerBase::SharedPtr timer_ptr_; + + }; // class DemoNode + } // namespace cb_group_demo + + int main(int argc, char* argv[]) + { + rclcpp::init(argc, argv); + auto client_node = std::make_shared(); + rclcpp::executors::MultiThreadedExecutor executor; + executor.add_node(client_node); + + RCLCPP_INFO(client_node->get_logger(), "Starting client node, shut down with CTRL-C"); + executor.spin(); + RCLCPP_INFO(client_node->get_logger(), "Keyboard interrupt, shutting down.\n"); + + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException, MultiThreadedExecutor + from rclpy.callback_groups import MutuallyExclusiveCallbackGroup, ReentrantCallbackGroup + from rclpy.node import Node + from std_srvs.srv import Empty + + + class CallbackGroupDemo(Node): + def __init__(self): + super().__init__('client_node') + + client_cb_group = None + timer_cb_group = None + self.client = self.create_client(Empty, 'test_service', callback_group=client_cb_group) + self.call_timer = self.create_timer(1, self._timer_cb, callback_group=timer_cb_group) + + def _timer_cb(self): + self.get_logger().info('Sending request') + _ = self.client.call(Empty.Request()) + self.get_logger().info('Received response') + + + if __name__ == '__main__': + try: + with rclpy.init(): + node = CallbackGroupDemo() + executor = MultiThreadedExecutor() + executor.add_node(node) + + node.get_logger().info('Beginning client, shut down with CTRL-C') + executor.spin() + except (KeyboardInterrupt, ExternalShutdownException): + pass + +The client node's constructor contains options for setting the +callback groups of the service client and the timer. +With the default setting above (both being ``nullptr`` / ``None``), +both the timer and the client will use the node's default +Mutually Exclusive Callback Group. + +The problem +^^^^^^^^^^^ + +Since we are making service calls with a 1 second timer, the +expected outcome is that the service gets called once a second, +the client always gets a response and prints ``Received response``. +If we try running the server and client nodes +in terminals, we get the following outputs. + +.. tabs:: + + .. group-tab:: Client + + .. code-block:: console + + [INFO] [1653034371.758739131] [client_node]: Starting client node, shut down with CTRL-C + [INFO] [1653034372.755865649] [client_node]: Sending request + ^C[INFO] [1653034398.161674869] [client_node]: Keyboard interrupt, shutting down. + + .. group-tab:: Server + + .. code-block:: console + + [INFO] [1653034355.308958238] [service_node]: Starting server node, shut down with CTRL-C + [INFO] [1653034372.758197320] [service_node]: Received request, responding... + ^C[INFO] [1653034416.021962246] [service_node]: Keyboard interrupt, shutting down. + +So, it turns out that instead of the service being called repeatedly, +the response of the first call is never received, after which the +client node seemingly gets stuck and does not make further calls. +That is, the execution stopped at a deadlock! + +The reason for this is that the timer callback and the client are +using the same Mutually Exclusive Callback Group (the node's default). +When the service call is made, the client then passes its callback +group to the Future object (hidden inside the call-method in the +Python version) whose done-callback needs to execute for the result +of the service call to be available. +But because this done-callback and the timer callback are in the +same Mutually Exclusive group and the timer callback is still +executing (waiting for the result of the service call), +the done-callback never gets to execute. +The stuck timer callback also blocks any other executions of itself, so the +timer does not fire for a second time. + +Solution +^^^^^^^^ + +We can fix this easily - for example - by assigning the timer and client +to different callback groups. +Thus, let us change the first two lines of the client node's constructor +to be as follows (everything else shall stay the same): + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: cpp + + client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + timer_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + + .. group-tab:: Python + + .. code-block:: python + + client_cb_group = MutuallyExclusiveCallbackGroup() + timer_cb_group = MutuallyExclusiveCallbackGroup() + +Now we get the expected result, i.e. the timer fires repeatedly and +each service call gets the result as it should: + +.. tabs:: + + .. group-tab:: Client + + .. code-block:: console + + [INFO] [1653067523.431731177] [client_node]: Starting client node, shut down with CTRL-C + [INFO] [1653067524.431912821] [client_node]: Sending request + [INFO] [1653067524.433230445] [client_node]: Received response + [INFO] [1653067525.431869330] [client_node]: Sending request + [INFO] [1653067525.432912803] [client_node]: Received response + [INFO] [1653067526.431844726] [client_node]: Sending request + [INFO] [1653067526.432893954] [client_node]: Received response + [INFO] [1653067527.431828287] [client_node]: Sending request + [INFO] [1653067527.432848369] [client_node]: Received response + ^C[INFO] [1653067528.400052749] [client_node]: Keyboard interrupt, shutting down. + + .. group-tab:: Server + + .. code-block:: console + + [INFO] [1653067522.052866001] [service_node]: Starting server node, shut down with CTRL-C + [INFO] [1653067524.432577720] [service_node]: Received request, responding... + [INFO] [1653067525.432365009] [service_node]: Received request, responding... + [INFO] [1653067526.432300261] [service_node]: Received request, responding... + [INFO] [1653067527.432272441] [service_node]: Received request, responding... + ^C[INFO] [1653034416.021962246] [service_node]: KeyboardInterrupt, shutting down. + +One might consider if just avoiding the node's default callback group +is enough. +This is not the case: replacing the default group by a +different Mutually Exclusive group changes nothing. +Thus, the following configuration also leads to the previously +discovered deadlock. + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: cpp + + client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + timer_cb_group_ = client_cb_group_; + + .. group-tab:: Python + + .. code-block:: python + + client_cb_group = MutuallyExclusiveCallbackGroup() + timer_cb_group = client_cb_group + +In fact, the exact condition with which everything works in this case +is that the timer and client must not belong to the same +Mutually Exclusive group. +Hence, all of the following configurations (and some others as well) +produce the desired outcome where the timer fires +repeatedly and service calls are completed. + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: cpp + + client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::Reentrant); + timer_cb_group_ = client_cb_group_; + + or + + .. code-block:: cpp + + client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + timer_cb_group_ = nullptr; + + or + + .. code-block:: cpp + + client_cb_group_ = nullptr; + timer_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::MutuallyExclusive); + + or + + .. code-block:: cpp + + client_cb_group_ = this->create_callback_group(rclcpp::CallbackGroupType::Reentrant); + timer_cb_group_ = nullptr; + + .. group-tab:: Python + + .. code-block:: python + + client_cb_group = ReentrantCallbackGroup() + timer_cb_group = client_cb_group + + or + + .. code-block:: python + + client_cb_group = MutuallyExclusiveCallbackGroup() + timer_cb_group = None + + or + + .. code-block:: python + + client_cb_group = None + timer_cb_group = MutuallyExclusiveCallbackGroup() + + or + + .. code-block:: python + + client_cb_group = ReentrantCallbackGroup() + timer_cb_group = None \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst b/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst index 2d633e3974c..f0ef3231fc7 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst @@ -1,171 +1,175 @@ -Writing a Composable Node (C++) -=============================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Starting Place --------------- - -Let's assume that you have a regular ``rclcpp::Node`` executable that you want to run in the same process as other nodes to enable more efficient communication. - -We'll start from having a class that directly inherits from ``Node``, and that also has a main method defined. - -.. code-block:: c++ - - namespace palomino - { - class VincentDriver : public rclcpp::Node - { - // ... - }; - } - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -This will typically be compiled as an executable in your Cmake. - -.. code-block:: cmake - - # ... - add_executable(vincent_driver src/vincent_driver.cpp) - # ... - install(TARGETS vincent_driver - DESTINATION lib/${PROJECT_NAME} - ) - -Code Updates ------------- - -Add the Package Dependency -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Your `package.xml `__ should have a dependency on ``rclcpp_components``, a la - -.. code-block:: xml - - rclcpp_components - -Alternatively, you can independently add a ``build_depend/exec_depend``. - -Class Definition -^^^^^^^^^^^^^^^^ - -The only change to your class definition that you may have to do is ensure that `the constructor for the class `__ takes a ``NodeOptions`` argument. - -.. code-block:: c++ - - VincentDriver(const rclcpp::NodeOptions & options) : Node("vincent_driver", options) - { - // ... - } - -No More Main Method -^^^^^^^^^^^^^^^^^^^ - -Replace your main method with a ``pluginlib``-style macro invocation. - -.. code-block:: c++ - - #include - RCLCPP_COMPONENTS_REGISTER_NODE(palomino::VincentDriver) - -.. caution:: - If the main method you are replacing contains a ``MultiThreadedExecutor``, be sure to make note and ensure that your container node is multithreaded. - See section below. - -CMake Changes -^^^^^^^^^^^^^ -First, add ``rclcpp_components`` as a dependency in your CMakeLists.txt with: - -.. code-block:: cmake - - find_package(rclcpp_components REQUIRED) - -Second, we're going to replace our ``add_executable`` with a ``add_library`` with a new target name. - -.. code-block:: cmake - - add_library(vincent_driver_component SHARED src/vincent_driver.cpp) - -Third, replace other build commands that used the old target to act on the new target. -Don't forget to add ``rclcpp_components::component`` in ``target_link_libraries``. -i.e. ``target_link_libraries(vincent_driver ...)`` becomes ``target_link_libraries(vincent_driver_component rclcpp_components::component ...)`` - -Fourth, add a new command to declare your component. - -.. code-block:: cmake - - rclcpp_components_register_node( - vincent_driver_component - PLUGIN "palomino::VincentDriver" - EXECUTABLE vincent_driver - ) - -Fifth and finally, change any installation commands in the CMake that operated on the old target to install the library version instead. -For instance, do not install either target into ``lib/${PROJECT_NAME}``. -Replace with the library installation. - -.. code-block:: cmake - - ament_export_targets(export_vincent_driver_component) - install(TARGETS vincent_driver_component - EXPORT export_vincent_driver_component - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - - -Running Your Node ------------------ - -See the :doc:`Composition tutorial ` for an in-depth look at composing nodes. -The quick and dirty version is that if you had the following in your Python launch file, - -.. code-block:: python - - from launch_ros.actions import Node - - # .. - - ld.add_action(Node( - package='palomino', - executable='vincent_driver', - # .. - )) - -you can replace it with - -.. code-block:: python - - from launch_ros.actions import ComposableNodeContainer - from launch_ros.descriptions import ComposableNode - - # .. - ld.add_action(ComposableNodeContainer( - name='a_buncha_nodes', - namespace='', - package='rclcpp_components', - executable='component_container', - composable_node_descriptions=[ - ComposableNode( - package='palomino', - plugin='palomino::VincentDriver', - name='vincent_driver', - # .. - extra_arguments=[{'use_intra_process_comms': True}], - ), - ] - )) - -.. caution:: - - If you need multi-threading, simply add the ``--executor-type multi-threaded`` argument to your container node. +.. redirect-from:: + + Tutorials/Intermediate/Writing-a-Composable-Node + +Writing a Composable Node (C++) +=============================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Starting Place +-------------- + +Let's assume that you have a regular ``rclcpp::Node`` executable that you want to run in the same process as other nodes to enable more efficient communication. + +We'll start from having a class that directly inherits from ``Node``, and that also has a main method defined. + +.. code-block:: c++ + + namespace palomino + { + class VincentDriver : public rclcpp::Node + { + // ... + }; + } + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +This will typically be compiled as an executable in your Cmake. + +.. code-block:: cmake + + # ... + add_executable(vincent_driver src/vincent_driver.cpp) + # ... + install(TARGETS vincent_driver + DESTINATION lib/${PROJECT_NAME} + ) + +Code Updates +------------ + +Add the Package Dependency +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Your `package.xml `__ should have a dependency on ``rclcpp_components``, a la + +.. code-block:: xml + + rclcpp_components + +Alternatively, you can independently add a ``build_depend/exec_depend``. + +Class Definition +^^^^^^^^^^^^^^^^ + +The only change to your class definition that you may have to do is ensure that `the constructor for the class `__ takes a ``NodeOptions`` argument. + +.. code-block:: c++ + + VincentDriver(const rclcpp::NodeOptions & options) : Node("vincent_driver", options) + { + // ... + } + +No More Main Method +^^^^^^^^^^^^^^^^^^^ + +Replace your main method with a ``pluginlib``-style macro invocation. + +.. code-block:: c++ + + #include + RCLCPP_COMPONENTS_REGISTER_NODE(palomino::VincentDriver) + +.. caution:: + If the main method you are replacing contains a ``MultiThreadedExecutor``, be sure to make note and ensure that your container node is multithreaded. + See section below. + +CMake Changes +^^^^^^^^^^^^^ +First, add ``rclcpp_components`` as a dependency in your CMakeLists.txt with: + +.. code-block:: cmake + + find_package(rclcpp_components REQUIRED) + +Second, we're going to replace our ``add_executable`` with a ``add_library`` with a new target name. + +.. code-block:: cmake + + add_library(vincent_driver_component SHARED src/vincent_driver.cpp) + +Third, replace other build commands that used the old target to act on the new target. +Don't forget to add ``rclcpp_components::component`` in ``target_link_libraries``. +i.e. ``target_link_libraries(vincent_driver ...)`` becomes ``target_link_libraries(vincent_driver_component rclcpp_components::component ...)`` + +Fourth, add a new command to declare your component. + +.. code-block:: cmake + + rclcpp_components_register_node( + vincent_driver_component + PLUGIN "palomino::VincentDriver" + EXECUTABLE vincent_driver + ) + +Fifth and finally, change any installation commands in the CMake that operated on the old target to install the library version instead. +For instance, do not install either target into ``lib/${PROJECT_NAME}``. +Replace with the library installation. + +.. code-block:: cmake + + ament_export_targets(export_vincent_driver_component) + install(TARGETS vincent_driver_component + EXPORT export_vincent_driver_component + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + + +Running Your Node +----------------- + +See the :doc:`Composition tutorial ` for an in-depth look at composing nodes. +The quick and dirty version is that if you had the following in your Python launch file, + +.. code-block:: python + + from launch_ros.actions import Node + + # .. + + ld.add_action(Node( + package='palomino', + executable='vincent_driver', + # .. + )) + +you can replace it with + +.. code-block:: python + + from launch_ros.actions import ComposableNodeContainer + from launch_ros.descriptions import ComposableNode + + # .. + ld.add_action(ComposableNodeContainer( + name='a_buncha_nodes', + namespace='', + package='rclcpp_components', + executable='component_container', + composable_node_descriptions=[ + ComposableNode( + package='palomino', + plugin='palomino::VincentDriver', + name='vincent_driver', + # .. + extra_arguments=[{'use_intra_process_comms': True}], + ), + ] + )) + +.. caution:: + + If you need multi-threading, simply add the ``--executor-type multi-threaded`` argument to your container node. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst b/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst index ff350fec809..170bb14b01b 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst @@ -1,393 +1,394 @@ -.. redirect-from:: - - Intra-Process-Communication - Tutorials/Intra-Process-Communication - -Setting up efficient intra-process communication -================================================ - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -ROS applications typically consist of a composition of individual "nodes" which perform narrow tasks and are decoupled from other parts of the system. -This promotes fault isolation, faster development, modularity, and code reuse, but it often comes at the cost of performance. -After ROS 1 was initially developed, the need for efficient composition of nodes became obvious and Nodelets were developed. -In ROS 2 we aim to improve on the design of Nodelets by addressing some fundamental problems that required restructuring of nodes. - -In this demo we'll be highlighting how nodes can be composed manually, by defining the nodes separately but combining them in different process layouts without changing the node's code or limiting its abilities. - -Installing the demos --------------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-intra-process-demo`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Running and understanding the demos ------------------------------------ - -There are a few different demos: some are toy problems designed to highlight features of the intra-process communications functionality and some are end to end examples which use OpenCV and demonstrate the ability to recombine nodes into different configurations. - -The two node pipeline demo -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This demo is designed to show that the intra-process publish/subscribe connection can result in zero-copy transport of messages when publishing and subscribing with ``std::unique_ptr``\ s. - -First let's take a look at the source: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/intra_process_demo/src/two_node_pipeline/two_node_pipeline.cpp - -.. code-block:: c++ - - #include - #include - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/int32.hpp" - - using namespace std::chrono_literals; - - // Node that produces messages. - struct Producer : public rclcpp::Node - { - Producer(const std::string & name, const std::string & output) - : Node(name, rclcpp::NodeOptions().use_intra_process_comms(true)) - { - // Create a publisher on the output topic. - pub_ = this->create_publisher(output, 10); - std::weak_ptr::type> captured_pub = pub_; - // Create a timer which publishes on the output topic at ~1Hz. - auto callback = [captured_pub]() -> void { - auto pub_ptr = captured_pub.lock(); - if (!pub_ptr) { - return; - } - static int32_t count = 0; - std_msgs::msg::Int32::UniquePtr msg(new std_msgs::msg::Int32()); - msg->data = count++; - printf( - "Published message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, - reinterpret_cast(msg.get())); - pub_ptr->publish(std::move(msg)); - }; - timer_ = this->create_wall_timer(1s, callback); - } - - rclcpp::Publisher::SharedPtr pub_; - rclcpp::TimerBase::SharedPtr timer_; - }; - - // Node that consumes messages. - struct Consumer : public rclcpp::Node - { - Consumer(const std::string & name, const std::string & input) - : Node(name, rclcpp::NodeOptions().use_intra_process_comms(true)) - { - // Create a subscription on the input topic which prints on receipt of new messages. - sub_ = this->create_subscription( - input, - 10, - [](std_msgs::msg::Int32::UniquePtr msg) { - printf( - " Received message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, - reinterpret_cast(msg.get())); - }); - } - - rclcpp::Subscription::SharedPtr sub_; - }; - - int main(int argc, char * argv[]) - { - setvbuf(stdout, NULL, _IONBF, BUFSIZ); - rclcpp::init(argc, argv); - rclcpp::executors::SingleThreadedExecutor executor; - - auto producer = std::make_shared("producer", "number"); - auto consumer = std::make_shared("consumer", "number"); - - executor.add_node(producer); - executor.add_node(consumer); - executor.spin(); - - rclcpp::shutdown(); - - return 0; - } - -As you can see by looking at the ``main`` function, we have a producer and a consumer node, we add them to a single threaded executor, and then call spin. - -If you look at the "producer" node's implementation in the ``Producer`` struct, you can see that we have created a publisher which publishes on the "number" topic and a timer which periodically creates a new message, prints out its address in memory and its content's value and then publishes it. - -The "consumer" node is a bit simpler, you can see its implementation in the ``Consumer`` struct, as it only subscribes to the "number" topic and prints the address and value of the message it receives. - -The expectation is that the producer will print out an address and value and the consumer will print out a matching address and value. -This demonstrates that intra-process communication is indeed working and unnecessary copies are avoided, at least for simple graphs. - -Let's run the demo by executing ``ros2 run intra_process_demo two_node_pipeline`` executable (don't forget to source the setup file first): - -.. code-block:: console - - $ ros2 run intra_process_demo two_node_pipeline - Published message with value: 0, and address: 0x7fb02303faf0 - Published message with value: 1, and address: 0x7fb020cf0520 - Received message with value: 1, and address: 0x7fb020cf0520 - Published message with value: 2, and address: 0x7fb020e12900 - Received message with value: 2, and address: 0x7fb020e12900 - Published message with value: 3, and address: 0x7fb020cf0520 - Received message with value: 3, and address: 0x7fb020cf0520 - Published message with value: 4, and address: 0x7fb020e12900 - Received message with value: 4, and address: 0x7fb020e12900 - Published message with value: 5, and address: 0x7fb02303cea0 - Received message with value: 5, and address: 0x7fb02303cea0 - [...] - -One thing you'll notice is that the messages tick along at about one per second. -This is because we told the timer to fire at about once per second. - -Also you may have noticed that the first message (with value ``0``) does not have a corresponding "Received message ..." line. -This is because publish/subscribe is "best effort" and we do not have any "latching" like behavior enabled. -This means that if the publisher publishes a message before the subscription has been established, the subscription will not receive that message. -This race condition can result in the first few messages being lost. -In this case, since they only come once per second, usually only the first message is lost. - -Finally, you can see that "Published message..." and "Received message ..." lines with the same value also have the same address. -This shows that the address of the message being received is the same as the one that was published and that it is not a copy. -This is because we're publishing and subscribing with ``std::unique_ptr``\ s which allow ownership of a message to be moved around the system safely. -You can also publish and subscribe with ``const &`` and ``std::shared_ptr``, but zero-copy will not occur in that case. - -The cyclic pipeline demo -^^^^^^^^^^^^^^^^^^^^^^^^ - -This demo is similar to the previous one, but instead of the producer creating a new message for each iteration, this demo only ever uses one message instance. -This is achieved by creating a cycle in the graph and "kicking off" communication by externally making one of the nodes publish before spinning the executor: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/intra_process_demo/src/cyclic_pipeline/cyclic_pipeline.cpp - -.. code-block:: c++ - - #include - #include - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/int32.hpp" - - using namespace std::chrono_literals; - - // This node receives an Int32, waits 1 second, then increments and sends it. - struct IncrementerPipe : public rclcpp::Node - { - IncrementerPipe(const std::string & name, const std::string & in, const std::string & out) - : Node(name, rclcpp::NodeOptions().use_intra_process_comms(true)) - { - // Create a publisher on the output topic. - pub = this->create_publisher(out, 10); - std::weak_ptr::type> captured_pub = pub; - // Create a subscription on the input topic. - sub = this->create_subscription( - in, - 10, - [captured_pub](std_msgs::msg::Int32::UniquePtr msg) { - auto pub_ptr = captured_pub.lock(); - if (!pub_ptr) { - return; - } - printf( - "Received message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, - reinterpret_cast(msg.get())); - printf(" sleeping for 1 second...\n"); - if (!rclcpp::sleep_for(1s)) { - return; // Return if the sleep failed (e.g. on :kbd:`ctrl-c`). - } - printf(" done.\n"); - msg->data++; // Increment the message's data. - printf( - "Incrementing and sending with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, - reinterpret_cast(msg.get())); - pub_ptr->publish(std::move(msg)); // Send the message along to the output topic. - }); - } - - rclcpp::Publisher::SharedPtr pub; - rclcpp::Subscription::SharedPtr sub; - }; - - int main(int argc, char * argv[]) - { - setvbuf(stdout, NULL, _IONBF, BUFSIZ); - rclcpp::init(argc, argv); - rclcpp::executors::SingleThreadedExecutor executor; - - // Create a simple loop by connecting the in and out topics of two IncrementerPipe's. - // The expectation is that the address of the message being passed between them never changes. - auto pipe1 = std::make_shared("pipe1", "topic1", "topic2"); - auto pipe2 = std::make_shared("pipe2", "topic2", "topic1"); - rclcpp::sleep_for(1s); // Wait for subscriptions to be established to avoid race conditions. - // Publish the first message (kicking off the cycle). - std::unique_ptr msg(new std_msgs::msg::Int32()); - msg->data = 42; - printf( - "Published first message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, - reinterpret_cast(msg.get())); - pipe1->pub->publish(std::move(msg)); - - executor.add_node(pipe1); - executor.add_node(pipe2); - executor.spin(); - - rclcpp::shutdown(); - - return 0; - } - -Unlike the previous demo, this demo uses only one Node, instantiated twice with different names and configurations. -The graph ends up being ``pipe1`` -> ``pipe2`` -> ``pipe1`` ... in a loop. - -The line ``pipe1->pub->publish(std::move(msg));`` kicks the process off, but from then on the messages are passed back and forth between the nodes by each one calling publish within its own subscription callback. - -The expectation here is that the nodes pass the message back and forth, once a second, incrementing the value of the message each time. -Because the message is being published and subscribed to as a ``unique_ptr`` the same message created at the beginning is continuously used. - -To test those expectations, let's run it: - -.. code-block:: console - - $ ros2 run intra_process_demo cyclic_pipeline - Published first message with value: 42, and address: 0x7fd2ce0a2bc0 - Received message with value: 42, and address: 0x7fd2ce0a2bc0 - sleeping for 1 second... - done. - Incrementing and sending with value: 43, and address: 0x7fd2ce0a2bc0 - Received message with value: 43, and address: 0x7fd2ce0a2bc0 - sleeping for 1 second... - done. - Incrementing and sending with value: 44, and address: 0x7fd2ce0a2bc0 - Received message with value: 44, and address: 0x7fd2ce0a2bc0 - sleeping for 1 second... - done. - Incrementing and sending with value: 45, and address: 0x7fd2ce0a2bc0 - Received message with value: 45, and address: 0x7fd2ce0a2bc0 - sleeping for 1 second... - done. - Incrementing and sending with value: 46, and address: 0x7fd2ce0a2bc0 - Received message with value: 46, and address: 0x7fd2ce0a2bc0 - sleeping for 1 second... - done. - Incrementing and sending with value: 47, and address: 0x7fd2ce0a2bc0 - Received message with value: 47, and address: 0x7fd2ce0a2bc0 - sleeping for 1 second... - [...] - -You should see ever increasing numbers on each iteration, starting with 42... because 42, and the whole time it reuses the same message, as demonstrated by the pointer addresses which do not change, which avoids unnecessary copies. - -The image pipeline demo -^^^^^^^^^^^^^^^^^^^^^^^ - -In this demo we'll use OpenCV to capture, annotate, and then view images. - -.. note:: - - If you are on macOS and these examples do not work or you receive an error like ``ddsi_conn_write failed -1``, then you'll need to increase your system wide UDP packet size: - - .. code-block:: console - - $ sudo sysctl -w net.inet.udp.recvspace=209715 - $ sudo sysctl -w net.inet.udp.maxdgram=65500 - - These changes will not persist after a reboot. - -Simple pipeline -~~~~~~~~~~~~~~~ - -First we'll have a pipeline of three nodes, arranged as such: ``camera_node`` -> ``watermark_node`` -> ``image_view_node`` - -The ``camera_node`` reads from camera device ``0`` on your computer, writes some information on the image and publishes it. -The ``watermark_node`` subscribes to the output of the ``camera_node`` and adds more text before publishing it too. -Finally, the ``image_view_node`` subscribes to the output of the ``watermark_node``, writes more text to the image and then visualizes it with ``cv::imshow``. - -In each node the process id and the pointer address of the ROS message is written onto the image with ``cv::putText``. -The watermark and image view nodes are designed to modify the image without copying it and so the addresses imprinted on the image should all be the same as long as the nodes are in the same process and the graph remains organized in a pipeline as sketched above. - -.. note:: - - On some systems (we've seen it happen on Linux), the address printed to the screen might not change. - This is because the same unique pointer is being reused. - In this situation, the pipeline is still running. - -Let's run the demo by executing the following executable: - -.. code-block:: console - - $ ros2 run intra_process_demo image_pipeline_all_in_one - -You should see something like this: - - -.. image:: images/intra-process-demo-pipeline-single-window.png - - -You can pause the rendering of the image by pressing the spacebar and you can resume by pressing the spacebar again. -You can also press ``q`` or ``ESC`` to exit. - -If you pause the image viewer, you should be able to compare the addresses written on the image and see that they are the same. - -Pipeline with two image viewers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now let's look at an example just like the one above, except it has two image view nodes. -All the nodes are still in the same process, but now there will be two instances of the ``image_view_node`` and so two image view windows should show up. -(Note for macOS users: your image view windows might be on top of each other). -Let's run it with the command: - -.. code-block:: console - - $ ros2 run intra_process_demo image_pipeline_with_two_image_view - - -.. image:: images/intra-process-demo-pipeline-two-windows-copy.png - - -Just like the last example, you can pause the rendering with the spacebar and continue by pressing the spacebar a second time. -You can stop the updating to inspect the pointers written to the screen. - -As you can see in the example image above, we have one image with all of the pointers the same and then another image with the same pointers as the first image for the first two entries, but the last pointer on the second image is different. -To understand why this is happening consider the graph's topology: - -.. code-block:: bash - - camera_node -> watermark_node -> image_view_node - -> image_view_node2 - -The link between the ``camera_node`` and the ``watermark_node`` can use the same pointer without copying because there is only one intra-process subscription to which the message should be delivered. -But for the link between the ``watermark_node`` and the two image view nodes the relationship is one to many, so if the image view nodes were using ``unique_ptr`` callbacks then it would be impossible to deliver the ownership of the same pointer to both. -It can be, however, delivered to one of them. -Which one would get the original pointer is not defined, but instead is simply the last to be delivered. -And so one of the images being viewed is the original, with all the pointers the same, and the other is a copy of the original image, made between the ``watermark_node`` and one of the ``image_view_node`` instances, which will have a different pointer for the third line of text. - -Pipeline with inter-process viewer -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -One other important thing to get right is to avoid interruption of the intra-process zero-copy behavior when inter-process subscriptions are made. -To test this we can run the first image pipeline demo, ``image_pipeline_all_in_one``, and then run an instance of the stand alone ``image_view_node`` (don't forget to prefix them with ``ros2 run intra_process_demo`` in the terminal). -This will look something like this: - - -.. image:: images/intra-process-demo-pipeline-inter-process.png - - -It's hard to pause both images at the same time so the images may not line up, but the important thing to notice is that the ``image_pipeline_all_in_one`` image view shows the same address for each step. -This means that the intra-process zero-copy is preserved even when an external view is subscribed as well. -You can also see that the inter-process image view has different process IDs for the first two lines of text and the process ID of the standalone image viewer in the third line of text. +.. redirect-from:: + + Intra-Process-Communication + Tutorials/Intra-Process-Communication + Tutorials/Demos/Intra-Process-Communication + +Setting up efficient intra-process communication +================================================ + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +ROS applications typically consist of a composition of individual "nodes" which perform narrow tasks and are decoupled from other parts of the system. +This promotes fault isolation, faster development, modularity, and code reuse, but it often comes at the cost of performance. +After ROS 1 was initially developed, the need for efficient composition of nodes became obvious and Nodelets were developed. +In ROS 2 we aim to improve on the design of Nodelets by addressing some fundamental problems that required restructuring of nodes. + +In this demo we'll be highlighting how nodes can be composed manually, by defining the nodes separately but combining them in different process layouts without changing the node's code or limiting its abilities. + +Installing the demos +-------------------- + +See the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-intra-process-demo`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Running and understanding the demos +----------------------------------- + +There are a few different demos: some are toy problems designed to highlight features of the intra-process communications functionality and some are end to end examples which use OpenCV and demonstrate the ability to recombine nodes into different configurations. + +The two node pipeline demo +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This demo is designed to show that the intra-process publish/subscribe connection can result in zero-copy transport of messages when publishing and subscribing with ``std::unique_ptr``\ s. + +First let's take a look at the source: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/intra_process_demo/src/two_node_pipeline/two_node_pipeline.cpp + +.. code-block:: c++ + + #include + #include + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/int32.hpp" + + using namespace std::chrono_literals; + + // Node that produces messages. + struct Producer : public rclcpp::Node + { + Producer(const std::string & name, const std::string & output) + : Node(name, rclcpp::NodeOptions().use_intra_process_comms(true)) + { + // Create a publisher on the output topic. + pub_ = this->create_publisher(output, 10); + std::weak_ptr::type> captured_pub = pub_; + // Create a timer which publishes on the output topic at ~1Hz. + auto callback = [captured_pub]() -> void { + auto pub_ptr = captured_pub.lock(); + if (!pub_ptr) { + return; + } + static int32_t count = 0; + std_msgs::msg::Int32::UniquePtr msg(new std_msgs::msg::Int32()); + msg->data = count++; + printf( + "Published message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, + reinterpret_cast(msg.get())); + pub_ptr->publish(std::move(msg)); + }; + timer_ = this->create_wall_timer(1s, callback); + } + + rclcpp::Publisher::SharedPtr pub_; + rclcpp::TimerBase::SharedPtr timer_; + }; + + // Node that consumes messages. + struct Consumer : public rclcpp::Node + { + Consumer(const std::string & name, const std::string & input) + : Node(name, rclcpp::NodeOptions().use_intra_process_comms(true)) + { + // Create a subscription on the input topic which prints on receipt of new messages. + sub_ = this->create_subscription( + input, + 10, + [](std_msgs::msg::Int32::UniquePtr msg) { + printf( + " Received message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, + reinterpret_cast(msg.get())); + }); + } + + rclcpp::Subscription::SharedPtr sub_; + }; + + int main(int argc, char * argv[]) + { + setvbuf(stdout, NULL, _IONBF, BUFSIZ); + rclcpp::init(argc, argv); + rclcpp::executors::SingleThreadedExecutor executor; + + auto producer = std::make_shared("producer", "number"); + auto consumer = std::make_shared("consumer", "number"); + + executor.add_node(producer); + executor.add_node(consumer); + executor.spin(); + + rclcpp::shutdown(); + + return 0; + } + +As you can see by looking at the ``main`` function, we have a producer and a consumer node, we add them to a single threaded executor, and then call spin. + +If you look at the "producer" node's implementation in the ``Producer`` struct, you can see that we have created a publisher which publishes on the "number" topic and a timer which periodically creates a new message, prints out its address in memory and its content's value and then publishes it. + +The "consumer" node is a bit simpler, you can see its implementation in the ``Consumer`` struct, as it only subscribes to the "number" topic and prints the address and value of the message it receives. + +The expectation is that the producer will print out an address and value and the consumer will print out a matching address and value. +This demonstrates that intra-process communication is indeed working and unnecessary copies are avoided, at least for simple graphs. + +Let's run the demo by executing ``ros2 run intra_process_demo two_node_pipeline`` executable (don't forget to source the setup file first): + +.. code-block:: console + + $ ros2 run intra_process_demo two_node_pipeline + Published message with value: 0, and address: 0x7fb02303faf0 + Published message with value: 1, and address: 0x7fb020cf0520 + Received message with value: 1, and address: 0x7fb020cf0520 + Published message with value: 2, and address: 0x7fb020e12900 + Received message with value: 2, and address: 0x7fb020e12900 + Published message with value: 3, and address: 0x7fb020cf0520 + Received message with value: 3, and address: 0x7fb020cf0520 + Published message with value: 4, and address: 0x7fb020e12900 + Received message with value: 4, and address: 0x7fb020e12900 + Published message with value: 5, and address: 0x7fb02303cea0 + Received message with value: 5, and address: 0x7fb02303cea0 + [...] + +One thing you'll notice is that the messages tick along at about one per second. +This is because we told the timer to fire at about once per second. + +Also you may have noticed that the first message (with value ``0``) does not have a corresponding "Received message ..." line. +This is because publish/subscribe is "best effort" and we do not have any "latching" like behavior enabled. +This means that if the publisher publishes a message before the subscription has been established, the subscription will not receive that message. +This race condition can result in the first few messages being lost. +In this case, since they only come once per second, usually only the first message is lost. + +Finally, you can see that "Published message..." and "Received message ..." lines with the same value also have the same address. +This shows that the address of the message being received is the same as the one that was published and that it is not a copy. +This is because we're publishing and subscribing with ``std::unique_ptr``\ s which allow ownership of a message to be moved around the system safely. +You can also publish and subscribe with ``const &`` and ``std::shared_ptr``, but zero-copy will not occur in that case. + +The cyclic pipeline demo +^^^^^^^^^^^^^^^^^^^^^^^^ + +This demo is similar to the previous one, but instead of the producer creating a new message for each iteration, this demo only ever uses one message instance. +This is achieved by creating a cycle in the graph and "kicking off" communication by externally making one of the nodes publish before spinning the executor: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/intra_process_demo/src/cyclic_pipeline/cyclic_pipeline.cpp + +.. code-block:: c++ + + #include + #include + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/int32.hpp" + + using namespace std::chrono_literals; + + // This node receives an Int32, waits 1 second, then increments and sends it. + struct IncrementerPipe : public rclcpp::Node + { + IncrementerPipe(const std::string & name, const std::string & in, const std::string & out) + : Node(name, rclcpp::NodeOptions().use_intra_process_comms(true)) + { + // Create a publisher on the output topic. + pub = this->create_publisher(out, 10); + std::weak_ptr::type> captured_pub = pub; + // Create a subscription on the input topic. + sub = this->create_subscription( + in, + 10, + [captured_pub](std_msgs::msg::Int32::UniquePtr msg) { + auto pub_ptr = captured_pub.lock(); + if (!pub_ptr) { + return; + } + printf( + "Received message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, + reinterpret_cast(msg.get())); + printf(" sleeping for 1 second...\n"); + if (!rclcpp::sleep_for(1s)) { + return; // Return if the sleep failed (e.g. on :kbd:`ctrl-c`). + } + printf(" done.\n"); + msg->data++; // Increment the message's data. + printf( + "Incrementing and sending with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, + reinterpret_cast(msg.get())); + pub_ptr->publish(std::move(msg)); // Send the message along to the output topic. + }); + } + + rclcpp::Publisher::SharedPtr pub; + rclcpp::Subscription::SharedPtr sub; + }; + + int main(int argc, char * argv[]) + { + setvbuf(stdout, NULL, _IONBF, BUFSIZ); + rclcpp::init(argc, argv); + rclcpp::executors::SingleThreadedExecutor executor; + + // Create a simple loop by connecting the in and out topics of two IncrementerPipe's. + // The expectation is that the address of the message being passed between them never changes. + auto pipe1 = std::make_shared("pipe1", "topic1", "topic2"); + auto pipe2 = std::make_shared("pipe2", "topic2", "topic1"); + rclcpp::sleep_for(1s); // Wait for subscriptions to be established to avoid race conditions. + // Publish the first message (kicking off the cycle). + std::unique_ptr msg(new std_msgs::msg::Int32()); + msg->data = 42; + printf( + "Published first message with value: %d, and address: 0x%" PRIXPTR "\n", msg->data, + reinterpret_cast(msg.get())); + pipe1->pub->publish(std::move(msg)); + + executor.add_node(pipe1); + executor.add_node(pipe2); + executor.spin(); + + rclcpp::shutdown(); + + return 0; + } + +Unlike the previous demo, this demo uses only one Node, instantiated twice with different names and configurations. +The graph ends up being ``pipe1`` -> ``pipe2`` -> ``pipe1`` ... in a loop. + +The line ``pipe1->pub->publish(std::move(msg));`` kicks the process off, but from then on the messages are passed back and forth between the nodes by each one calling publish within its own subscription callback. + +The expectation here is that the nodes pass the message back and forth, once a second, incrementing the value of the message each time. +Because the message is being published and subscribed to as a ``unique_ptr`` the same message created at the beginning is continuously used. + +To test those expectations, let's run it: + +.. code-block:: console + + $ ros2 run intra_process_demo cyclic_pipeline + Published first message with value: 42, and address: 0x7fd2ce0a2bc0 + Received message with value: 42, and address: 0x7fd2ce0a2bc0 + sleeping for 1 second... + done. + Incrementing and sending with value: 43, and address: 0x7fd2ce0a2bc0 + Received message with value: 43, and address: 0x7fd2ce0a2bc0 + sleeping for 1 second... + done. + Incrementing and sending with value: 44, and address: 0x7fd2ce0a2bc0 + Received message with value: 44, and address: 0x7fd2ce0a2bc0 + sleeping for 1 second... + done. + Incrementing and sending with value: 45, and address: 0x7fd2ce0a2bc0 + Received message with value: 45, and address: 0x7fd2ce0a2bc0 + sleeping for 1 second... + done. + Incrementing and sending with value: 46, and address: 0x7fd2ce0a2bc0 + Received message with value: 46, and address: 0x7fd2ce0a2bc0 + sleeping for 1 second... + done. + Incrementing and sending with value: 47, and address: 0x7fd2ce0a2bc0 + Received message with value: 47, and address: 0x7fd2ce0a2bc0 + sleeping for 1 second... + [...] + +You should see ever increasing numbers on each iteration, starting with 42... because 42, and the whole time it reuses the same message, as demonstrated by the pointer addresses which do not change, which avoids unnecessary copies. + +The image pipeline demo +^^^^^^^^^^^^^^^^^^^^^^^ + +In this demo we'll use OpenCV to capture, annotate, and then view images. + +.. note:: + + If you are on macOS and these examples do not work or you receive an error like ``ddsi_conn_write failed -1``, then you'll need to increase your system wide UDP packet size: + + .. code-block:: console + + $ sudo sysctl -w net.inet.udp.recvspace=209715 + $ sudo sysctl -w net.inet.udp.maxdgram=65500 + + These changes will not persist after a reboot. + +Simple pipeline +~~~~~~~~~~~~~~~ + +First we'll have a pipeline of three nodes, arranged as such: ``camera_node`` -> ``watermark_node`` -> ``image_view_node`` + +The ``camera_node`` reads from camera device ``0`` on your computer, writes some information on the image and publishes it. +The ``watermark_node`` subscribes to the output of the ``camera_node`` and adds more text before publishing it too. +Finally, the ``image_view_node`` subscribes to the output of the ``watermark_node``, writes more text to the image and then visualizes it with ``cv::imshow``. + +In each node the process id and the pointer address of the ROS message is written onto the image with ``cv::putText``. +The watermark and image view nodes are designed to modify the image without copying it and so the addresses imprinted on the image should all be the same as long as the nodes are in the same process and the graph remains organized in a pipeline as sketched above. + +.. note:: + + On some systems (we've seen it happen on Linux), the address printed to the screen might not change. + This is because the same unique pointer is being reused. + In this situation, the pipeline is still running. + +Let's run the demo by executing the following executable: + +.. code-block:: console + + $ ros2 run intra_process_demo image_pipeline_all_in_one + +You should see something like this: + + +.. image:: images/intra-process-demo-pipeline-single-window.png + + +You can pause the rendering of the image by pressing the spacebar and you can resume by pressing the spacebar again. +You can also press ``q`` or ``ESC`` to exit. + +If you pause the image viewer, you should be able to compare the addresses written on the image and see that they are the same. + +Pipeline with two image viewers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now let's look at an example just like the one above, except it has two image view nodes. +All the nodes are still in the same process, but now there will be two instances of the ``image_view_node`` and so two image view windows should show up. +(Note for macOS users: your image view windows might be on top of each other). +Let's run it with the command: + +.. code-block:: console + + $ ros2 run intra_process_demo image_pipeline_with_two_image_view + + +.. image:: images/intra-process-demo-pipeline-two-windows-copy.png + + +Just like the last example, you can pause the rendering with the spacebar and continue by pressing the spacebar a second time. +You can stop the updating to inspect the pointers written to the screen. + +As you can see in the example image above, we have one image with all of the pointers the same and then another image with the same pointers as the first image for the first two entries, but the last pointer on the second image is different. +To understand why this is happening consider the graph's topology: + +.. code-block:: bash + + camera_node -> watermark_node -> image_view_node + -> image_view_node2 + +The link between the ``camera_node`` and the ``watermark_node`` can use the same pointer without copying because there is only one intra-process subscription to which the message should be delivered. +But for the link between the ``watermark_node`` and the two image view nodes the relationship is one to many, so if the image view nodes were using ``unique_ptr`` callbacks then it would be impossible to deliver the ownership of the same pointer to both. +It can be, however, delivered to one of them. +Which one would get the original pointer is not defined, but instead is simply the last to be delivered. +And so one of the images being viewed is the original, with all the pointers the same, and the other is a copy of the original image, made between the ``watermark_node`` and one of the ``image_view_node`` instances, which will have a different pointer for the third line of text. + +Pipeline with inter-process viewer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One other important thing to get right is to avoid interruption of the intra-process zero-copy behavior when inter-process subscriptions are made. +To test this we can run the first image pipeline demo, ``image_pipeline_all_in_one``, and then run an instance of the stand alone ``image_view_node`` (don't forget to prefix them with ``ros2 run intra_process_demo`` in the terminal). +This will look something like this: + + +.. image:: images/intra-process-demo-pipeline-inter-process.png + + +It's hard to pause both images at the same time so the images may not line up, but the important thing to notice is that the ``image_pipeline_all_in_one`` image view shows the same address for each step. +This means that the intra-process zero-copy is preserved even when an external view is subscribed as well. +You can also see that the inter-process image view has different process IDs for the first two lines of text and the process ID of the standalone image viewer in the third line of text. \ No newline at end of file diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst index e3bc70af3a4..8f955cddba1 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst @@ -1,463 +1,464 @@ -.. redirect-from:: - - Tutorials/Monitoring-For-Parameter-Changes-CPP - -Monitoring for parameter changes (C++) -====================================== - -**Goal:** Learn to use the ParameterEventHandler class to monitor and respond to parameter changes. - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Often a node needs to respond to changes to its own parameters or another node's parameters. -The ParameterEventHandler class makes it easy to listen for parameter changes so that your code can respond to them. -This tutorial will show you how to use the C++ version of the ParameterEventHandler class to monitor for changes to a node's own parameters as well as changes to another node's parameters. - -Prerequisites -------------- - -Before starting this tutorial, you should first complete the following tutorials: - -- :doc:`../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters` -- :doc:`../Beginner-Client-Libraries/Using-Parameters-In-A-Class-CPP` - -Tasks ------ - -In this tutorial, you will create a new package to contain some sample code, write some C++ code to use the ParameterEventHandler class, and test the resulting code. - - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First, open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -So, navigate into ``ros2_ws/src`` and then create a new package there: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_parameter_event_handler --dependencies rclcpp - -Your terminal will return a message verifying the creation of your package ``cpp_parameter_event_handler`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - C++ parameter events client tutorial - Your Name - Apache-2.0 - -2 Write the C++ node -^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/cpp_parameter_event_handler/src`` directory, create a new file called ``parameter_event_handler.cpp`` and paste the following code within: - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - - class SampleNodeWithParameters : public rclcpp::Node - { - public: - SampleNodeWithParameters() - : Node("node_with_parameters") - { - this->declare_parameter("an_int_param", 0); - - // Create a parameter subscriber that can be used to monitor parameter changes - // (for this node's parameters as well as other nodes' parameters) - param_subscriber_ = std::make_shared(this); - - // Set a callback for this node's integer parameter, "an_int_param" - auto cb = [this](const rclcpp::Parameter & p) { - RCLCPP_INFO( - this->get_logger(), "cb: Received an update to parameter \"%s\" of type %s: \"%ld\"", - p.get_name().c_str(), - p.get_type_name().c_str(), - p.as_int()); - }; - cb_handle_ = param_subscriber_->add_parameter_callback("an_int_param", cb); - } - - private: - std::shared_ptr param_subscriber_; - std::shared_ptr cb_handle_; - }; - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ -The first statement, ``#include `` is included so that the code can utilize the std::make_shared template. -The next, ``#include "rclcpp/rclcpp.hpp"`` is included to allow the code to reference the various functionality provided by the rclcpp interface, including the ParameterEventHandler class. - -After the class declaration, the code defines a class, ``SampleNodeWithParameters``. -The constructor for the class declares an integer parameter ``an_int_param``, with a default value of 0. -Next, the code creates a ``ParameterEventHandler`` that will be used to monitor changes to parameters. -Finally, the code creates a lambda function and sets it as the callback to invoke whenever ``an_int_param`` is updated. - -.. note:: - - It is very important to save the handle that is returned by ``add_parameter_callback``; otherwise, the callback will not be properly registered. - -.. code-block:: C++ - - SampleNodeWithParameters() - : Node("node_with_parameters") - { - this->declare_parameter("an_int_param", 0); - - // Create a parameter subscriber that can be used to monitor parameter changes - // (for this node's parameters as well as other nodes' parameters) - param_subscriber_ = std::make_shared(this); - - // Set a callback for this node's integer parameter, "an_int_param" - auto cb = [this](const rclcpp::Parameter & p) { - RCLCPP_INFO( - this->get_logger(), "cb: Received an update to parameter \"%s\" of type %s: \"%ld\"", - p.get_name().c_str(), - p.get_type_name().c_str(), - p.as_int()); - }; - cb_handle_ = param_subscriber_->add_parameter_callback("an_int_param", cb); - } - -Following the ``SampleNodeWithParameters`` is a typical ``main`` function which initializes ROS, spins the sample node so that it can send and receive messages, and then shuts down after the user enters ^C at the console. - -.. code-block:: C++ - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - - return 0; - } - - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -To build this code, first open the ``CMakeLists.txt`` file and add the following lines of code below the dependency ``find_package(rclcpp REQUIRED)`` - -.. code-block:: console - - add_executable(parameter_event_handler src/parameter_event_handler.cpp) - target_link_libraries(parameter_event_handler PUBLIC rclcpp::rclcpp) - - install(TARGETS - parameter_event_handler - DESTINATION lib/${PROJECT_NAME} - ) - -3 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro $ROS_DISTRO -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. code-block:: console - - $ colcon build --packages-select cpp_parameter_event_handler - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the node: - -.. code-block:: console - - $ ros2 run cpp_parameter_event_handler parameter_event_handler - -The node is now active and has a single parameter and will print a message whenever this parameter is updated. -To test this, open up another terminal and source the ROS setup file as before (``. install/setup.bash``) and execute the following command: - -.. code-block:: console - - $ ros2 param set node_with_parameters an_int_param 43 - -The terminal running the node will display a message similar to the following: - -.. code-block:: console - - [INFO] [1606950498.422461764] [node_with_parameters]: cb: Received an update to parameter "an_int_param" of type integer: "43" - -The callback we set previously in the node has been invoked and has displayed the new updated value. -You can now terminate the running parameter_event_handler sample using ^C in the terminal. - -Extensions ----------- - -So far, we built and tested a small node that monitors a single parameter owned by the node itself. -Using this node as a base, two other usecases where the ParameterEventHandler can be useful are presented below. - -Monitor changes to another node's parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can also use the ParameterEventHandler to monitor parameter changes to another node's parameters. -Let's update the SampleNodeWithParameters class to also monitor for changes to a parameter in another node. -We will use the parameter_blackboard demo application to host a double parameter that we will monitor for updates. - -First update the constructor to add the following code after the existing code: - -.. code-block:: C++ - - // Now, add a callback to monitor any changes to the remote node's parameter. In this - // case, we supply the remote node name. - auto cb2 = [this](const rclcpp::Parameter & p) { - RCLCPP_INFO( - this->get_logger(), "cb2: Received an update to parameter \"%s\" of type: %s: \"%.02lf\"", - p.get_name().c_str(), - p.get_type_name().c_str(), - p.as_double()); - }; - auto remote_node_name = std::string("parameter_blackboard"); - auto remote_param_name = std::string("a_double_param"); - cb_handle2_ = param_subscriber_->add_parameter_callback(remote_param_name, cb2, remote_node_name); - - -Then add another member variable, ``cb_handle2`` for the additional callback handle: - -.. code-block:: C++ - - private: - std::shared_ptr param_subscriber_; - std::shared_ptr cb_handle_; - std::shared_ptr cb_handle2_; // Add this - }; - - -In a terminal, navigate back to the root of your workspace, ``ros2_ws``, and build your updated package as before: - -.. code-block:: console - - $ colcon build --packages-select cpp_parameter_event_handler - -Then source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now, to test monitoring of remote parameters, first run the newly-built parameter_event_handler code: - -.. code-block:: console - - $ ros2 run cpp_parameter_event_handler parameter_event_handler - -Next, from another terminal (with ROS initialized), run the parameter_blackboard demo application, as follows: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp parameter_blackboard - -Finally, from a third terminal (with ROS initialized), let's set a parameter on the parameter_blackboard node: - -.. code-block:: console - - $ ros2 param set parameter_blackboard a_double_param 3.45 - -Upon executing this command, you should see output in the parameter_event_handler window, indicating that the callback function was invoked upon the parameter update: - -.. code-block:: console - - [INFO] [1606952588.237531933] [node_with_parameters]: cb2: Received an update to parameter "a_double_param" of type: double: "3.45" - -Monitor all node parameters simultaneously -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you need to monitor multiple nodes or parameters at the same time, it would be cumbersome to have to call ``add_parameter_callback`` once for each of them. -In this case, you can use ``add_parameter_event_callback`` to register a single callback that fires when *any* parameters of *any* nodes change. - -To do this, first update the SampleNodeWithParameters constructor to add the following code: - -.. code-block:: C++ - - this->declare_parameter("another_double_param", 0.0); - - ... - - auto event_cb = [this](const rcl_interfaces::msg::ParameterEvent & parameter_event) { - RCLCPP_INFO( - this->get_logger(), "Received parameter event from node \"%s\"", - parameter_event.node.c_str()); - - for (const auto& p : parameter_event.changed_parameters) { - RCLCPP_INFO( - this->get_logger(), "Inside event: \"%s\" changed to %s", - p.name.c_str(), - rclcpp::Parameter::from_parameter_msg(p).value_to_string().c_str()); - }; - }; - event_cb_handle_ = param_subscriber_->add_parameter_event_callback(event_cb); - -This declares a new double parameter ``another_double_param`` and adds an event callback that will monitor both parameters. -Note that the ``parameter_event`` is of type {interface(rcl_interfaces/msg/ParameterEvent)}. -Although it's not shown in this tutorial, event callbacks can also be used to monitor when parameters are added or deleted. - -Finally, don't forget to add the event callback handle as a private member: - -.. code-block:: C++ - - private: - ... - std::shared_ptr event_cb_handle_; - -Navigate back to the root of your workspace, ``ros2_ws``, and rebuild your updated package as before: - -.. code-block:: console - - $ colcon build --packages-select cpp_parameter_event_handler - -Then source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\setup.bat - -To test the new event callback, first run the parameter_event_handler node: - -.. code-block:: console - - $ ros2 run cpp_parameter_event_handler parameter_event_handler - -Then, from a second terminal (with ROS sourced), let's set the original int parameter: - -.. code-block:: console - - $ ros2 param set node_with_parameters an_int_param 44 - -Upon executing this command, you should see both the single-parameter callback, as well as the event callback being fired: - -.. code-block:: console - - [INFO] [1747144403.418980063] [node_with_parameters]: cb: Received an update to parameter "an_int_param" of type integer: "44" - [INFO] [1747144403.419086611] [node_with_parameters]: Received parameter event from node "/node_with_parameters" - [INFO] [1747144403.419114103] [node_with_parameters]: Inside event: "an_int_param" changed to 44 - -Now set the new double parameter: - -.. code-block:: console - - $ ros2 param set node_with_parameters another_double_param 4.4 - -Since no single-parameter callback was added (via ``add_parameter_callback``) for the double parameter, we should see only the event callback fire: - -.. code-block:: console - - [INFO] [1747144452.917437113] [node_with_parameters]: Received parameter event from node "/node_with_parameters" - [INFO] [1747144452.917591649] [node_with_parameters]: Inside event: "another_double_param" changed to 4.400000 - -.. note:: - - When setting multiple parameters at once, it's best to use ``set_parameters_atomically``, explained in :doc:`../../Concepts/Basic/About-Parameters`. - This way, the event callback is only fired once. - -Summary -------- - -You created a node with a parameter and used the ParameterEventHandler class to set a callback to monitor changes to that parameter. -You also used the same class to monitor changes to a remote node, and to monitor all parameters in a single event callback. -The ParameterEventHandler is a convenient way to monitor for parameter changes so that you can then respond to the updated values. - -Related content ---------------- - -To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../How-To-Guides/Migrating-from-ROS1/Migrating-Parameters>` tutorial. +.. redirect-from:: + + Tutorials/Monitoring-For-Parameter-Changes-CPP + Tutorials/Intermediate/Monitoring-For-Parameter-Changes-CPP + +Monitoring for parameter changes (C++) +====================================== + +**Goal:** Learn to use the ParameterEventHandler class to monitor and respond to parameter changes. + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Often a node needs to respond to changes to its own parameters or another node's parameters. +The ParameterEventHandler class makes it easy to listen for parameter changes so that your code can respond to them. +This tutorial will show you how to use the C++ version of the ParameterEventHandler class to monitor for changes to a node's own parameters as well as changes to another node's parameters. + +Prerequisites +------------- + +Before starting this tutorial, you should first complete the following tutorials: + +- :doc:`Understanding-ROS2-Parameters/Understanding-ROS2-Parameters` +- :doc:`../../client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP` + +Tasks +----- + +In this tutorial, you will create a new package to contain some sample code, write some C++ code to use the ParameterEventHandler class, and test the resulting code. + + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First, open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +So, navigate into ``ros2_ws/src`` and then create a new package there: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_parameter_event_handler --dependencies rclcpp + +Your terminal will return a message verifying the creation of your package ``cpp_parameter_event_handler`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + C++ parameter events client tutorial + Your Name + Apache-2.0 + +2 Write the C++ node +^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/cpp_parameter_event_handler/src`` directory, create a new file called ``parameter_event_handler.cpp`` and paste the following code within: + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + + class SampleNodeWithParameters : public rclcpp::Node + { + public: + SampleNodeWithParameters() + : Node("node_with_parameters") + { + this->declare_parameter("an_int_param", 0); + + // Create a parameter subscriber that can be used to monitor parameter changes + // (for this node's parameters as well as other nodes' parameters) + param_subscriber_ = std::make_shared(this); + + // Set a callback for this node's integer parameter, "an_int_param" + auto cb = [this](const rclcpp::Parameter & p) { + RCLCPP_INFO( + this->get_logger(), "cb: Received an update to parameter \"%s\" of type %s: \"%ld\"", + p.get_name().c_str(), + p.get_type_name().c_str(), + p.as_int()); + }; + cb_handle_ = param_subscriber_->add_parameter_callback("an_int_param", cb); + } + + private: + std::shared_ptr param_subscriber_; + std::shared_ptr cb_handle_; + }; + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ +The first statement, ``#include `` is included so that the code can utilize the std::make_shared template. +The next, ``#include "rclcpp/rclcpp.hpp"`` is included to allow the code to reference the various functionality provided by the rclcpp interface, including the ParameterEventHandler class. + +After the class declaration, the code defines a class, ``SampleNodeWithParameters``. +The constructor for the class declares an integer parameter ``an_int_param``, with a default value of 0. +Next, the code creates a ``ParameterEventHandler`` that will be used to monitor changes to parameters. +Finally, the code creates a lambda function and sets it as the callback to invoke whenever ``an_int_param`` is updated. + +.. note:: + + It is very important to save the handle that is returned by ``add_parameter_callback``; otherwise, the callback will not be properly registered. + +.. code-block:: C++ + + SampleNodeWithParameters() + : Node("node_with_parameters") + { + this->declare_parameter("an_int_param", 0); + + // Create a parameter subscriber that can be used to monitor parameter changes + // (for this node's parameters as well as other nodes' parameters) + param_subscriber_ = std::make_shared(this); + + // Set a callback for this node's integer parameter, "an_int_param" + auto cb = [this](const rclcpp::Parameter & p) { + RCLCPP_INFO( + this->get_logger(), "cb: Received an update to parameter \"%s\" of type %s: \"%ld\"", + p.get_name().c_str(), + p.get_type_name().c_str(), + p.as_int()); + }; + cb_handle_ = param_subscriber_->add_parameter_callback("an_int_param", cb); + } + +Following the ``SampleNodeWithParameters`` is a typical ``main`` function which initializes ROS, spins the sample node so that it can send and receive messages, and then shuts down after the user enters ^C at the console. + +.. code-block:: C++ + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + + return 0; + } + + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +To build this code, first open the ``CMakeLists.txt`` file and add the following lines of code below the dependency ``find_package(rclcpp REQUIRED)`` + +.. code-block:: console + + add_executable(parameter_event_handler src/parameter_event_handler.cpp) + target_link_libraries(parameter_event_handler PUBLIC rclcpp::rclcpp) + + install(TARGETS + parameter_event_handler + DESTINATION lib/${PROJECT_NAME} + ) + +3 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro $ROS_DISTRO -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. code-block:: console + + $ colcon build --packages-select cpp_parameter_event_handler + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the node: + +.. code-block:: console + + $ ros2 run cpp_parameter_event_handler parameter_event_handler + +The node is now active and has a single parameter and will print a message whenever this parameter is updated. +To test this, open up another terminal and source the ROS setup file as before (``. install/setup.bash``) and execute the following command: + +.. code-block:: console + + $ ros2 param set node_with_parameters an_int_param 43 + +The terminal running the node will display a message similar to the following: + +.. code-block:: console + + [INFO] [1606950498.422461764] [node_with_parameters]: cb: Received an update to parameter "an_int_param" of type integer: "43" + +The callback we set previously in the node has been invoked and has displayed the new updated value. +You can now terminate the running parameter_event_handler sample using ^C in the terminal. + +Extensions +---------- + +So far, we built and tested a small node that monitors a single parameter owned by the node itself. +Using this node as a base, two other usecases where the ParameterEventHandler can be useful are presented below. + +Monitor changes to another node's parameters +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can also use the ParameterEventHandler to monitor parameter changes to another node's parameters. +Let's update the SampleNodeWithParameters class to also monitor for changes to a parameter in another node. +We will use the parameter_blackboard demo application to host a double parameter that we will monitor for updates. + +First update the constructor to add the following code after the existing code: + +.. code-block:: C++ + + // Now, add a callback to monitor any changes to the remote node's parameter. In this + // case, we supply the remote node name. + auto cb2 = [this](const rclcpp::Parameter & p) { + RCLCPP_INFO( + this->get_logger(), "cb2: Received an update to parameter \"%s\" of type: %s: \"%.02lf\"", + p.get_name().c_str(), + p.get_type_name().c_str(), + p.as_double()); + }; + auto remote_node_name = std::string("parameter_blackboard"); + auto remote_param_name = std::string("a_double_param"); + cb_handle2_ = param_subscriber_->add_parameter_callback(remote_param_name, cb2, remote_node_name); + + +Then add another member variable, ``cb_handle2`` for the additional callback handle: + +.. code-block:: C++ + + private: + std::shared_ptr param_subscriber_; + std::shared_ptr cb_handle_; + std::shared_ptr cb_handle2_; // Add this + }; + + +In a terminal, navigate back to the root of your workspace, ``ros2_ws``, and build your updated package as before: + +.. code-block:: console + + $ colcon build --packages-select cpp_parameter_event_handler + +Then source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now, to test monitoring of remote parameters, first run the newly-built parameter_event_handler code: + +.. code-block:: console + + $ ros2 run cpp_parameter_event_handler parameter_event_handler + +Next, from another terminal (with ROS initialized), run the parameter_blackboard demo application, as follows: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp parameter_blackboard + +Finally, from a third terminal (with ROS initialized), let's set a parameter on the parameter_blackboard node: + +.. code-block:: console + + $ ros2 param set parameter_blackboard a_double_param 3.45 + +Upon executing this command, you should see output in the parameter_event_handler window, indicating that the callback function was invoked upon the parameter update: + +.. code-block:: console + + [INFO] [1606952588.237531933] [node_with_parameters]: cb2: Received an update to parameter "a_double_param" of type: double: "3.45" + +Monitor all node parameters simultaneously +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you need to monitor multiple nodes or parameters at the same time, it would be cumbersome to have to call ``add_parameter_callback`` once for each of them. +In this case, you can use ``add_parameter_event_callback`` to register a single callback that fires when *any* parameters of *any* nodes change. + +To do this, first update the SampleNodeWithParameters constructor to add the following code: + +.. code-block:: C++ + + this->declare_parameter("another_double_param", 0.0); + + ... + + auto event_cb = [this](const rcl_interfaces::msg::ParameterEvent & parameter_event) { + RCLCPP_INFO( + this->get_logger(), "Received parameter event from node \"%s\"", + parameter_event.node.c_str()); + + for (const auto& p : parameter_event.changed_parameters) { + RCLCPP_INFO( + this->get_logger(), "Inside event: \"%s\" changed to %s", + p.name.c_str(), + rclcpp::Parameter::from_parameter_msg(p).value_to_string().c_str()); + }; + }; + event_cb_handle_ = param_subscriber_->add_parameter_event_callback(event_cb); + +This declares a new double parameter ``another_double_param`` and adds an event callback that will monitor both parameters. +Note that the ``parameter_event`` is of type {interface(rcl_interfaces/msg/ParameterEvent)}. +Although it's not shown in this tutorial, event callbacks can also be used to monitor when parameters are added or deleted. + +Finally, don't forget to add the event callback handle as a private member: + +.. code-block:: C++ + + private: + ... + std::shared_ptr event_cb_handle_; + +Navigate back to the root of your workspace, ``ros2_ws``, and rebuild your updated package as before: + +.. code-block:: console + + $ colcon build --packages-select cpp_parameter_event_handler + +Then source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\setup.bat + +To test the new event callback, first run the parameter_event_handler node: + +.. code-block:: console + + $ ros2 run cpp_parameter_event_handler parameter_event_handler + +Then, from a second terminal (with ROS sourced), let's set the original int parameter: + +.. code-block:: console + + $ ros2 param set node_with_parameters an_int_param 44 + +Upon executing this command, you should see both the single-parameter callback, as well as the event callback being fired: + +.. code-block:: console + + [INFO] [1747144403.418980063] [node_with_parameters]: cb: Received an update to parameter "an_int_param" of type integer: "44" + [INFO] [1747144403.419086611] [node_with_parameters]: Received parameter event from node "/node_with_parameters" + [INFO] [1747144403.419114103] [node_with_parameters]: Inside event: "an_int_param" changed to 44 + +Now set the new double parameter: + +.. code-block:: console + + $ ros2 param set node_with_parameters another_double_param 4.4 + +Since no single-parameter callback was added (via ``add_parameter_callback``) for the double parameter, we should see only the event callback fire: + +.. code-block:: console + + [INFO] [1747144452.917437113] [node_with_parameters]: Received parameter event from node "/node_with_parameters" + [INFO] [1747144452.917591649] [node_with_parameters]: Inside event: "another_double_param" changed to 4.400000 + +.. note:: + + When setting multiple parameters at once, it's best to use ``set_parameters_atomically``, explained in :doc:`../../About-Parameters`. + This way, the event callback is only fired once. + +Summary +------- + +You created a node with a parameter and used the ParameterEventHandler class to set a callback to monitor changes to that parameter. +You also used the same class to monitor changes to a remote node, and to monitor all parameters in a single event callback. +The ParameterEventHandler is a convenient way to monitor for parameter changes so that you can then respond to the updated values. + +Related content +--------------- + +To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst index 0623e652778..38fd683e2b7 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst @@ -1,452 +1,456 @@ -Monitoring for parameter changes (Python) -========================================= - -**Goal:** Learn to use the ParameterEventHandler class to monitor and respond to parameter changes. - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Often a node needs to respond to changes to its own parameters or another node's parameters. -The ParameterEventHandler class makes it easy to listen for parameter changes so that your code can respond to them. -This tutorial will show you how to use the Python version of the ParameterEventHandler class to monitor for changes to a node's own parameters as well as changes to another node's parameters. - -Prerequisites -------------- - -Before starting this tutorial, you should first complete the following tutorials: - -- :doc:`../Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters` -- :doc:`../Beginner-Client-Libraries/Using-Parameters-In-A-Class-Python` - -Tasks ------ - -In this tutorial, you will create a new package to contain some sample code, write some Python code to use the ParameterEventHandler class, and test the resulting code. - - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First, open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -So, navigate into ``ros2_ws/src`` and then create a new package there: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 python_parameter_event_handler --dependencies rclpy - -Your terminal will return a message verifying the creation of your package ``python_parameter_event_handler`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - Python parameter events client tutorial - Your Name - Apache-2.0 - -2 Write the Python node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/python_parameter_event_handler/python_parameter_event_handler`` directory, create a new file called ``parameter_event_handler.py`` and paste the following code within: - -.. code-block:: Python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - import rclpy.parameter - - from rclpy.parameter_event_handler import ParameterEventHandler - - - class SampleNodeWithParameters(Node): - def __init__(self): - super().__init__('node_with_parameters') - - self.declare_parameter('an_int_param', 0) - - self.handler = ParameterEventHandler(self) - - self.callback_handle = self.handler.add_parameter_callback( - parameter_name="an_int_param", - node_name="node_with_parameters", - callback=self.callback, - ) - - def callback(self, p: rclpy.parameter.Parameter) -> None: - self.get_logger().info(f"Received an update to parameter: {p.name}: {rclpy.parameter.parameter_value_to_python(p.value)}") - - - def main(): - try: - with rclpy.init(): - node = SampleNodeWithParameters() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The ``import`` statements at the top are used to import the package dependencies. - -.. code-block:: Python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - import rclpy.parameter - - from rclpy.parameter_event_handler import ParameterEventHandler - -The next piece of code creates the class ``SampleNodeWithParameters`` and the constructor. -The constructor for the class declares an integer parameter ``an_int_param``, with a default value of 0. -Next, the code creates a ``ParameterEventHandler`` that will be used to monitor changes to parameters. - -.. code-block:: Python - - class SampleNodeWithParameters(Node): - def __init__(self): - super().__init__('node_with_parameters') - - self.declare_parameter('an_int_param', 0) - - self.handler = ParameterEventHandler(self) - - -Finally, we add a parameter callback and get a callback handler for the new callback. - -.. note:: - - It is very important to save the handle that is returned by ``add_parameter_callback``; otherwise, the callback will not be properly registered. - -.. code-block:: Python - - self.callback_handle = self.handler.add_parameter_callback( - parameter_name="an_int_param", - node_name="node_with_parameters", - callback=self.callback, - ) - -For the callback function, we use the ``callback`` method of the ``SampleNodeWithParameters`` class. - -.. code-block:: Python - - def callback(self, p: rclpy.parameter.Parameter) -> None: - self.get_logger().info(f"Received an update to parameter: {p.name}: {rclpy.parameter.parameter_value_to_python(p.value)}") - - -Following the ``SampleNodeWithParameters`` is a typical ``main`` function which initializes ROS, spins the sample node so that it can send and receive messages, and then shuts down after the user enters ^C at the console. - -.. code-block:: Python - - def main(): - try: - with rclpy.init(): - node = SampleNodeWithParameters() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - -2.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file. -Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: - -.. code-block:: Python - - maintainer='YourName', - maintainer_email='you@email.com', - description='Python parameter tutorial', - license='Apache-2.0', - -Add the following line within the ``console_scripts`` brackets of the ``entry_points`` field: - -.. code-block:: Python - - entry_points={ - 'console_scripts': [ - 'node_with_parameters = python_parameter_event_handler.parameter_event_handler:main', - ], - }, - - -3 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro $ROS_DISTRO -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. code-block:: console - - $ colcon build --packages-select python_parameter_event_handler - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\setup.bat - -Now run the node: - -.. code-block:: console - - $ ros2 run python_parameter_event_handler node_with_parameters - -The node is now active and has a single parameter and will print a message whenever this parameter is updated. -To test this, open up another terminal and source the ROS setup file as before and execute the following command: - -.. code-block:: console - - $ ros2 param set node_with_parameters an_int_param 43 - -The terminal running the node will display a message similar to the following: - -.. code-block:: console - - [INFO] [1698483083.315084660] [node_with_parameters]: Received an update to parameter: an_int_param: 43 - -The callback we set previously in the node has been invoked and has displayed the new updated value. -You can now terminate the running parameter_event_handler sample using ^C in the terminal. - -Extensions ----------- - -So far, we built and tested a small node that monitors a single parameter owned by the node itself. -Using this node as a base, two other usecases where the ParameterEventHandler can be useful are presented below. - -Monitor changes to another node's parameters -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can also use the ParameterEventHandler to monitor parameter changes to another node's parameters. -Let's update the SampleNodeWithParameters class to monitor for changes to a parameter in another node. -We will use the parameter_blackboard demo application to host a double parameter that we will monitor for updates. - -First update the constructor to add the following code after the existing code: - -.. code-block:: Python - - def __init__(...): - ... - self.callback_handle2 = self.handler.add_parameter_callback( - parameter_name="a_double_param", - node_name="parameter_blackboard", - callback=self.callback, - ) - - -In a terminal, navigate back to the root of your workspace, ``ros2_ws``, and build your updated package as before: - -.. code-block:: console - - $ colcon build --packages-select python_parameter_event_handler - -Then source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\setup.bat - -Now, to test monitoring of remote parameters, first run the newly-built parameter_event_handler code: - -.. code-block:: console - - $ ros2 run python_parameter_event_handler node_with_parameters - -Next, from another terminal (with ROS initialized), run the parameter_blackboard demo application, as follows: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp parameter_blackboard - -Finally, from a third terminal (with ROS initialized), let's set a parameter on the parameter_blackboard node: - -.. code-block:: console - - $ ros2 param set parameter_blackboard a_double_param 3.45 - -Upon executing this command, you should see output in the parameter_event_handler window, indicating that the callback function was invoked upon the parameter update: - -.. code-block:: console - - [INFO] [1699821958.757770223] [node_with_parameters]: Received an update to parameter: a_double_param: 3.45 - -Monitor all node parameters simultaneously -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you need to monitor multiple nodes or parameters at the same time, it would be cumbersome to have to call ``add_parameter_callback`` once for each of them. -In this case, you can use ``add_parameter_event_callback`` to register a single callback that fires when *any* parameters of *any* nodes change. - -To do this, first update the SampleNodeWithParameters constructor to add the following code: - -.. code-block:: Python - - def __init__(...): - self.declare_parameter("another_double_param", 0.0) - ... - self.event_calback_handle = self.handler.add_parameter_event_callback( - callback=self.event_callback, - ) - -This declares a new double parameter ``another_double_param`` and adds an event callback that will monitor both parameters. -The event callback signature is different from that of regular single-parameter callbacks, so we need to define a suitable callback as well: - -.. code-block:: Python - - def event_callback(self, parameter_event): - self.get_logger().info(f"Received parameter event from node {parameter_event.node}") - - for p in parameter_event.changed_parameters: - self.get_logger().info( - f"Inside event: {p.name} changed to: {rclpy.parameter.parameter_value_to_python(p.value)}" - ) - -Note that the ``parameter_event`` is of type {interface(rcl_interfaces/msg/ParameterEvent)}. -Although it's not shown in this tutorial, event callbacks can also be used to monitor when parameters are added or deleted. - -Navigate back to the root of your workspace, ``ros2_ws``, and rebuild your updated package as before: - -.. code-block:: console - - $ colcon build --packages-select python_parameter_event_handler - -Then source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\setup.bat - -To test the new event callback, first run the parameter_event_handler node: - -.. code-block:: console - - $ ros2 run python_parameter_event_handler node_with_parameters - -Then, from a second terminal (with ROS sourced), let's set the original int parameter: - -.. code-block:: console - - $ ros2 param set node_with_parameters an_int_param 44 - -Upon executing this command, you should see both the single-parameter callback, as well as the event callback being fired: - -.. code-block:: console - - [INFO] [1746414766.240101027] [node_with_parameters]: Received an update to parameter: an_int_param: 44 - [INFO] [1746414766.243499816] [node_with_parameters]: Received parameter event from node /node_with_parameters - [INFO] [1746414766.244271445] [node_with_parameters]: Inside event: an_int_param changed to: 4 - -Now set the new double parameter: - -.. code-block:: console - - $ ros2 param set node_with_parameters another_double_param 4.4 - -Since no single-parameter callback was added (via ``add_parameter_callback``) for the double parameter, we should see only the event callback fire: - -.. code-block:: console - - [INFO] [1746414962.604832196] [node_with_parameters]: Received parameter event from node /node_with_parameters - [INFO] [1746414962.607429035] [node_with_parameters]: Inside event: another_double_param changed to: 4.4 - -.. note:: - - When setting multiple parameters at once, it's best to use ``set_parameters_atomically``, explained in :doc:`../../Concepts/Basic/About-Parameters`. - This way, the event callback is only fired once. - -Summary -------- - -You created a node with a parameter and used the ParameterEventHandler class to set a callback to monitor changes to that parameter. -You also used the same class to monitor changes to a remote node, and to monitor all parameters in a single event callback. -The ParameterEventHandler is a convenient way to monitor for parameter changes so that you can then respond to the updated values. - -Related content ---------------- - -To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../How-To-Guides/Migrating-from-ROS1/Migrating-Parameters>` tutorial. +.. redirect-from:: + + Tutorials/Intermediate/Monitoring-For-Parameter-Changes-Python + +Monitoring for parameter changes (Python) +========================================= + +**Goal:** Learn to use the ParameterEventHandler class to monitor and respond to parameter changes. + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Often a node needs to respond to changes to its own parameters or another node's parameters. +The ParameterEventHandler class makes it easy to listen for parameter changes so that your code can respond to them. +This tutorial will show you how to use the Python version of the ParameterEventHandler class to monitor for changes to a node's own parameters as well as changes to another node's parameters. + +Prerequisites +------------- + +Before starting this tutorial, you should first complete the following tutorials: + +- :doc:`Understanding-ROS2-Parameters/Understanding-ROS2-Parameters` +- :doc:`../../client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python` + +Tasks +----- + +In this tutorial, you will create a new package to contain some sample code, write some Python code to use the ParameterEventHandler class, and test the resulting code. + + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First, open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Follow :ref:`these instructions ` to create a new workspace named ``ros2_ws``. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +So, navigate into ``ros2_ws/src`` and then create a new package there: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 python_parameter_event_handler --dependencies rclpy + +Your terminal will return a message verifying the creation of your package ``python_parameter_event_handler`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + Python parameter events client tutorial + Your Name + Apache-2.0 + +2 Write the Python node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/python_parameter_event_handler/python_parameter_event_handler`` directory, create a new file called ``parameter_event_handler.py`` and paste the following code within: + +.. code-block:: Python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + import rclpy.parameter + + from rclpy.parameter_event_handler import ParameterEventHandler + + + class SampleNodeWithParameters(Node): + def __init__(self): + super().__init__('node_with_parameters') + + self.declare_parameter('an_int_param', 0) + + self.handler = ParameterEventHandler(self) + + self.callback_handle = self.handler.add_parameter_callback( + parameter_name="an_int_param", + node_name="node_with_parameters", + callback=self.callback, + ) + + def callback(self, p: rclpy.parameter.Parameter) -> None: + self.get_logger().info(f"Received an update to parameter: {p.name}: {rclpy.parameter.parameter_value_to_python(p.value)}") + + + def main(): + try: + with rclpy.init(): + node = SampleNodeWithParameters() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The ``import`` statements at the top are used to import the package dependencies. + +.. code-block:: Python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + import rclpy.parameter + + from rclpy.parameter_event_handler import ParameterEventHandler + +The next piece of code creates the class ``SampleNodeWithParameters`` and the constructor. +The constructor for the class declares an integer parameter ``an_int_param``, with a default value of 0. +Next, the code creates a ``ParameterEventHandler`` that will be used to monitor changes to parameters. + +.. code-block:: Python + + class SampleNodeWithParameters(Node): + def __init__(self): + super().__init__('node_with_parameters') + + self.declare_parameter('an_int_param', 0) + + self.handler = ParameterEventHandler(self) + + +Finally, we add a parameter callback and get a callback handler for the new callback. + +.. note:: + + It is very important to save the handle that is returned by ``add_parameter_callback``; otherwise, the callback will not be properly registered. + +.. code-block:: Python + + self.callback_handle = self.handler.add_parameter_callback( + parameter_name="an_int_param", + node_name="node_with_parameters", + callback=self.callback, + ) + +For the callback function, we use the ``callback`` method of the ``SampleNodeWithParameters`` class. + +.. code-block:: Python + + def callback(self, p: rclpy.parameter.Parameter) -> None: + self.get_logger().info(f"Received an update to parameter: {p.name}: {rclpy.parameter.parameter_value_to_python(p.value)}") + + +Following the ``SampleNodeWithParameters`` is a typical ``main`` function which initializes ROS, spins the sample node so that it can send and receive messages, and then shuts down after the user enters ^C at the console. + +.. code-block:: Python + + def main(): + try: + with rclpy.init(): + node = SampleNodeWithParameters() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + +2.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file. +Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: + +.. code-block:: Python + + maintainer='YourName', + maintainer_email='you@email.com', + description='Python parameter tutorial', + license='Apache-2.0', + +Add the following line within the ``console_scripts`` brackets of the ``entry_points`` field: + +.. code-block:: Python + + entry_points={ + 'console_scripts': [ + 'node_with_parameters = python_parameter_event_handler.parameter_event_handler:main', + ], + }, + + +3 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro $ROS_DISTRO -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. code-block:: console + + $ colcon build --packages-select python_parameter_event_handler + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\setup.bat + +Now run the node: + +.. code-block:: console + + $ ros2 run python_parameter_event_handler node_with_parameters + +The node is now active and has a single parameter and will print a message whenever this parameter is updated. +To test this, open up another terminal and source the ROS setup file as before and execute the following command: + +.. code-block:: console + + $ ros2 param set node_with_parameters an_int_param 43 + +The terminal running the node will display a message similar to the following: + +.. code-block:: console + + [INFO] [1698483083.315084660] [node_with_parameters]: Received an update to parameter: an_int_param: 43 + +The callback we set previously in the node has been invoked and has displayed the new updated value. +You can now terminate the running parameter_event_handler sample using ^C in the terminal. + +Extensions +---------- + +So far, we built and tested a small node that monitors a single parameter owned by the node itself. +Using this node as a base, two other usecases where the ParameterEventHandler can be useful are presented below. + +Monitor changes to another node's parameters +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can also use the ParameterEventHandler to monitor parameter changes to another node's parameters. +Let's update the SampleNodeWithParameters class to monitor for changes to a parameter in another node. +We will use the parameter_blackboard demo application to host a double parameter that we will monitor for updates. + +First update the constructor to add the following code after the existing code: + +.. code-block:: Python + + def __init__(...): + ... + self.callback_handle2 = self.handler.add_parameter_callback( + parameter_name="a_double_param", + node_name="parameter_blackboard", + callback=self.callback, + ) + + +In a terminal, navigate back to the root of your workspace, ``ros2_ws``, and build your updated package as before: + +.. code-block:: console + + $ colcon build --packages-select python_parameter_event_handler + +Then source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\setup.bat + +Now, to test monitoring of remote parameters, first run the newly-built parameter_event_handler code: + +.. code-block:: console + + $ ros2 run python_parameter_event_handler node_with_parameters + +Next, from another terminal (with ROS initialized), run the parameter_blackboard demo application, as follows: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp parameter_blackboard + +Finally, from a third terminal (with ROS initialized), let's set a parameter on the parameter_blackboard node: + +.. code-block:: console + + $ ros2 param set parameter_blackboard a_double_param 3.45 + +Upon executing this command, you should see output in the parameter_event_handler window, indicating that the callback function was invoked upon the parameter update: + +.. code-block:: console + + [INFO] [1699821958.757770223] [node_with_parameters]: Received an update to parameter: a_double_param: 3.45 + +Monitor all node parameters simultaneously +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you need to monitor multiple nodes or parameters at the same time, it would be cumbersome to have to call ``add_parameter_callback`` once for each of them. +In this case, you can use ``add_parameter_event_callback`` to register a single callback that fires when *any* parameters of *any* nodes change. + +To do this, first update the SampleNodeWithParameters constructor to add the following code: + +.. code-block:: Python + + def __init__(...): + self.declare_parameter("another_double_param", 0.0) + ... + self.event_calback_handle = self.handler.add_parameter_event_callback( + callback=self.event_callback, + ) + +This declares a new double parameter ``another_double_param`` and adds an event callback that will monitor both parameters. +The event callback signature is different from that of regular single-parameter callbacks, so we need to define a suitable callback as well: + +.. code-block:: Python + + def event_callback(self, parameter_event): + self.get_logger().info(f"Received parameter event from node {parameter_event.node}") + + for p in parameter_event.changed_parameters: + self.get_logger().info( + f"Inside event: {p.name} changed to: {rclpy.parameter.parameter_value_to_python(p.value)}" + ) + +Note that the ``parameter_event`` is of type {interface(rcl_interfaces/msg/ParameterEvent)}. +Although it's not shown in this tutorial, event callbacks can also be used to monitor when parameters are added or deleted. + +Navigate back to the root of your workspace, ``ros2_ws``, and rebuild your updated package as before: + +.. code-block:: console + + $ colcon build --packages-select python_parameter_event_handler + +Then source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\setup.bat + +To test the new event callback, first run the parameter_event_handler node: + +.. code-block:: console + + $ ros2 run python_parameter_event_handler node_with_parameters + +Then, from a second terminal (with ROS sourced), let's set the original int parameter: + +.. code-block:: console + + $ ros2 param set node_with_parameters an_int_param 44 + +Upon executing this command, you should see both the single-parameter callback, as well as the event callback being fired: + +.. code-block:: console + + [INFO] [1746414766.240101027] [node_with_parameters]: Received an update to parameter: an_int_param: 44 + [INFO] [1746414766.243499816] [node_with_parameters]: Received parameter event from node /node_with_parameters + [INFO] [1746414766.244271445] [node_with_parameters]: Inside event: an_int_param changed to: 4 + +Now set the new double parameter: + +.. code-block:: console + + $ ros2 param set node_with_parameters another_double_param 4.4 + +Since no single-parameter callback was added (via ``add_parameter_callback``) for the double parameter, we should see only the event callback fire: + +.. code-block:: console + + [INFO] [1746414962.604832196] [node_with_parameters]: Received parameter event from node /node_with_parameters + [INFO] [1746414962.607429035] [node_with_parameters]: Inside event: another_double_param changed to: 4.4 + +.. note:: + + When setting multiple parameters at once, it's best to use ``set_parameters_atomically``, explained in :doc:`../../About-Parameters`. + This way, the event callback is only fired once. + +Summary +------- + +You created a node with a parameter and used the ParameterEventHandler class to set a callback to monitor changes to that parameter. +You also used the same class to monitor changes to a remote node, and to monitor all parameters in a single event callback. +The ParameterEventHandler is a convenient way to monitor for parameter changes so that you can then respond to the updated values. + +Related content +--------------- + +To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst b/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst index c8ddf2d62f2..ff5bfb952ba 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst @@ -1,251 +1,252 @@ -.. redirect-from:: - - Tutorials/Parameters/Understanding-ROS2-Parameters - -.. _ROS2Params: - -Understanding parameters -======================== - -**Goal:** Learn how to get, set, save and reload parameters in ROS 2. - -**Tutorial level:** Beginner - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -A parameter is a configuration value of a node. -You can think of parameters as node settings. -A node can store parameters as integers, floats, booleans, strings, and lists. -In ROS 2, each node maintains its own parameters. -For more background on parameters, please see :doc:`the concept document <../../../Concepts/Basic/About-Parameters>`. - -Prerequisites -------------- - -This tutorial uses the :doc:`turtlesim package <../Introducing-Turtlesim/Introducing-Turtlesim>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ - -Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - - -2 ros2 param list -^^^^^^^^^^^^^^^^^ - -To see the parameters belonging to your nodes, open a new terminal and enter the command: - -.. code-block:: console - - $ ros2 param list - /teleop_turtle: - qos_overrides./parameter_events.publisher.depth - qos_overrides./parameter_events.publisher.durability - qos_overrides./parameter_events.publisher.history - qos_overrides./parameter_events.publisher.reliability - scale_angular - scale_linear - use_sim_time - /turtlesim: - background_b - background_g - background_r - qos_overrides./parameter_events.publisher.depth - qos_overrides./parameter_events.publisher.durability - qos_overrides./parameter_events.publisher.history - qos_overrides./parameter_events.publisher.reliability - use_sim_time - - -You see the node namespaces, ``/teleop_turtle`` and ``/turtlesim``, followed by each node's parameters. - -The namespaces of the parameter and its name are separated using dots as you can see, for example, in ``parameter_events.publisher.depth``. - -Every node has the parameter ``use_sim_time``; it's not unique to turtlesim. - -Based on their names, it looks like ``/turtlesim``'s parameters determine the background color of the turtlesim window using RGB color values. - -To determine a parameter's type, you can use ``ros2 param get``. - - -3 ros2 param get -^^^^^^^^^^^^^^^^ - -To display the type and current value of a parameter, use the command: - -.. code-block:: console - - $ ros2 param get - -You can also query a parameter across all nodes by omitting the node name: - -.. code-block:: console - - $ ros2 param get - -Let's find out the current value of ``/turtlesim``'s parameter ``background_g``: - -.. code-block:: console - - $ ros2 param get /turtlesim background_g - Integer value is: 86 - -Now you know ``background_g`` holds an integer value. - -If you run the same command on ``background_r`` and ``background_b``, you will get the values ``69`` and ``255``, respectively. - -You can also check the ``use_sim_time`` parameter across all nodes: - -.. code-block:: console - - $ ros2 param get use_sim_time - -This will display the parameter value for each node that has this parameter set. - -4 ros2 param set -^^^^^^^^^^^^^^^^ - -To change a parameter's value at runtime, use the command: - -.. code-block:: console - - $ ros2 param set - -Let's change ``/turtlesim``'s background color: - -.. code-block:: console - - $ ros2 param set /turtlesim background_r 150 - Set parameter successful - -The background of your turtlesim window should change colors: - -.. image:: images/set.png - -Setting parameters with the ``set`` command will only change them in your current session, not permanently. -However, you can save your settings and reload them the next time you start a node. - -5 ros2 param dump -^^^^^^^^^^^^^^^^^ - -You can view all of a node's current parameter values by using the command: - -.. code-block:: console - - $ ros2 param dump - -The command prints to the standard output (stdout) by default but you can also redirect the parameter values into a file to save them for later. -To save your current configuration of ``/turtlesim``'s parameters into the file ``turtlesim.yaml``, enter the command: - -.. code-block:: console - - $ ros2 param dump /turtlesim > turtlesim.yaml - -You will find a new file in the current working directory your shell is running in. -If you open this file, you'll see the following content: - -.. code-block:: YAML - - /turtlesim: - ros__parameters: - background_b: 255 - background_g: 86 - background_r: 150 - qos_overrides: - /parameter_events: - publisher: - depth: 1000 - durability: volatile - history: keep_last - reliability: reliable - use_sim_time: false - -Dumping parameters comes in handy if you want to reload the node with the same parameters in the future. - -6 ros2 param load -^^^^^^^^^^^^^^^^^ - -You can load parameters from a file to a currently running node using the command: - -.. code-block:: console - - $ ros2 param load - -To load the ``turtlesim.yaml`` file generated with ``ros2 param dump`` into ``/turtlesim`` node's parameters, enter the command: - -.. code-block:: console - - $ ros2 param load /turtlesim turtlesim.yaml - Set parameter background_b successful - Set parameter background_g successful - Set parameter background_r successful - Set parameter qos_overrides./parameter_events.publisher.depth failed: parameter 'qos_overrides./parameter_events.publisher.depth' cannot be set because it is read-only - Set parameter qos_overrides./parameter_events.publisher.durability failed: parameter 'qos_overrides./parameter_events.publisher.durability' cannot be set because it is read-only - Set parameter qos_overrides./parameter_events.publisher.history failed: parameter 'qos_overrides./parameter_events.publisher.history' cannot be set because it is read-only - Set parameter qos_overrides./parameter_events.publisher.reliability failed: parameter 'qos_overrides./parameter_events.publisher.reliability' cannot be set because it is read-only - Set parameter use_sim_time successful - -.. note:: - - Read-only parameters can only be modified at startup and not afterwards, that is why there are some warnings for the "qos_overrides" parameters. - -.. _LoadParameterFileOnNodeStartup: - -7 Load parameter file on node startup -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To start the same node using your saved parameter values, use: - -.. code-block:: console - - $ ros2 run --ros-args --params-file - -This is the same command you always use to start turtlesim, with the added flags ``--ros-args`` and ``--params-file``, followed by the file you want to load. - -Stop your running turtlesim node, and try reloading it with your saved parameters, using: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node --ros-args --params-file turtlesim.yaml - -The turtlesim window should appear as usual, but with the purple background you set earlier. - -.. note:: - - When a parameter file is used at node startup, all parameters, including the read-only ones, will be updated. - -Summary -------- - -Nodes have parameters to define their default configuration values. -You can ``get`` and ``set`` parameter values from the command line. -You can also save the parameter settings to a file to reload them in a future session. - -Next steps ----------- - -Jumping back to ROS 2 communication methods, in the next tutorial you'll learn about :doc:`actions <../Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. +.. redirect-from:: + + Tutorials/Parameters/Understanding-ROS2-Parameters + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters + +.. _ROS2Params: + +Understanding parameters +======================== + +**Goal:** Learn how to get, set, save and reload parameters in ROS 2. + +**Tutorial level:** Beginner + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +A parameter is a configuration value of a node. +You can think of parameters as node settings. +A node can store parameters as integers, floats, booleans, strings, and lists. +In ROS 2, each node maintains its own parameters. +For more background on parameters, please see :doc:`the concept document <../../../About-Parameters>`. + +Prerequisites +------------- + +This tutorial uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ + +Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + + +2 ros2 param list +^^^^^^^^^^^^^^^^^ + +To see the parameters belonging to your nodes, open a new terminal and enter the command: + +.. code-block:: console + + $ ros2 param list + /teleop_turtle: + qos_overrides./parameter_events.publisher.depth + qos_overrides./parameter_events.publisher.durability + qos_overrides./parameter_events.publisher.history + qos_overrides./parameter_events.publisher.reliability + scale_angular + scale_linear + use_sim_time + /turtlesim: + background_b + background_g + background_r + qos_overrides./parameter_events.publisher.depth + qos_overrides./parameter_events.publisher.durability + qos_overrides./parameter_events.publisher.history + qos_overrides./parameter_events.publisher.reliability + use_sim_time + + +You see the node namespaces, ``/teleop_turtle`` and ``/turtlesim``, followed by each node's parameters. + +The namespaces of the parameter and its name are separated using dots as you can see, for example, in ``parameter_events.publisher.depth``. + +Every node has the parameter ``use_sim_time``; it's not unique to turtlesim. + +Based on their names, it looks like ``/turtlesim``'s parameters determine the background color of the turtlesim window using RGB color values. + +To determine a parameter's type, you can use ``ros2 param get``. + + +3 ros2 param get +^^^^^^^^^^^^^^^^ + +To display the type and current value of a parameter, use the command: + +.. code-block:: console + + $ ros2 param get + +You can also query a parameter across all nodes by omitting the node name: + +.. code-block:: console + + $ ros2 param get + +Let's find out the current value of ``/turtlesim``'s parameter ``background_g``: + +.. code-block:: console + + $ ros2 param get /turtlesim background_g + Integer value is: 86 + +Now you know ``background_g`` holds an integer value. + +If you run the same command on ``background_r`` and ``background_b``, you will get the values ``69`` and ``255``, respectively. + +You can also check the ``use_sim_time`` parameter across all nodes: + +.. code-block:: console + + $ ros2 param get use_sim_time + +This will display the parameter value for each node that has this parameter set. + +4 ros2 param set +^^^^^^^^^^^^^^^^ + +To change a parameter's value at runtime, use the command: + +.. code-block:: console + + $ ros2 param set + +Let's change ``/turtlesim``'s background color: + +.. code-block:: console + + $ ros2 param set /turtlesim background_r 150 + Set parameter successful + +The background of your turtlesim window should change colors: + +.. image:: images/set.png + +Setting parameters with the ``set`` command will only change them in your current session, not permanently. +However, you can save your settings and reload them the next time you start a node. + +5 ros2 param dump +^^^^^^^^^^^^^^^^^ + +You can view all of a node's current parameter values by using the command: + +.. code-block:: console + + $ ros2 param dump + +The command prints to the standard output (stdout) by default but you can also redirect the parameter values into a file to save them for later. +To save your current configuration of ``/turtlesim``'s parameters into the file ``turtlesim.yaml``, enter the command: + +.. code-block:: console + + $ ros2 param dump /turtlesim > turtlesim.yaml + +You will find a new file in the current working directory your shell is running in. +If you open this file, you'll see the following content: + +.. code-block:: YAML + + /turtlesim: + ros__parameters: + background_b: 255 + background_g: 86 + background_r: 150 + qos_overrides: + /parameter_events: + publisher: + depth: 1000 + durability: volatile + history: keep_last + reliability: reliable + use_sim_time: false + +Dumping parameters comes in handy if you want to reload the node with the same parameters in the future. + +6 ros2 param load +^^^^^^^^^^^^^^^^^ + +You can load parameters from a file to a currently running node using the command: + +.. code-block:: console + + $ ros2 param load + +To load the ``turtlesim.yaml`` file generated with ``ros2 param dump`` into ``/turtlesim`` node's parameters, enter the command: + +.. code-block:: console + + $ ros2 param load /turtlesim turtlesim.yaml + Set parameter background_b successful + Set parameter background_g successful + Set parameter background_r successful + Set parameter qos_overrides./parameter_events.publisher.depth failed: parameter 'qos_overrides./parameter_events.publisher.depth' cannot be set because it is read-only + Set parameter qos_overrides./parameter_events.publisher.durability failed: parameter 'qos_overrides./parameter_events.publisher.durability' cannot be set because it is read-only + Set parameter qos_overrides./parameter_events.publisher.history failed: parameter 'qos_overrides./parameter_events.publisher.history' cannot be set because it is read-only + Set parameter qos_overrides./parameter_events.publisher.reliability failed: parameter 'qos_overrides./parameter_events.publisher.reliability' cannot be set because it is read-only + Set parameter use_sim_time successful + +.. note:: + + Read-only parameters can only be modified at startup and not afterwards, that is why there are some warnings for the "qos_overrides" parameters. + +.. _LoadParameterFileOnNodeStartup: + +7 Load parameter file on node startup +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To start the same node using your saved parameter values, use: + +.. code-block:: console + + $ ros2 run --ros-args --params-file + +This is the same command you always use to start turtlesim, with the added flags ``--ros-args`` and ``--params-file``, followed by the file you want to load. + +Stop your running turtlesim node, and try reloading it with your saved parameters, using: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node --ros-args --params-file turtlesim.yaml + +The turtlesim window should appear as usual, but with the purple background you set earlier. + +.. note:: + + When a parameter file is used at node startup, all parameters, including the read-only ones, will be updated. + +Summary +------- + +Nodes have parameters to define their default configuration values. +You can ``get`` and ``set`` parameter values from the command line. +You can also save the parameter settings to a file to reload them in a future session. + +Next steps +---------- + +Jumping back to ROS 2 communication methods, in the next tutorial you'll learn about :doc:`actions <../../../actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. \ No newline at end of file diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst b/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst index 427a3fb0820..22fe33e8a86 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst @@ -1,127 +1,131 @@ -Using the ``ros2 param`` command-line tool -========================================== - -.. contents:: Table of Contents - :depth: 1 - :local: - -Parameters in ROS 2 can be get, set, listed, and described through a set of services as described in :doc:`the concept document <../Concepts/Basic/About-Parameters>`. -The ``ros2 param`` command-line tool is a wrapper around these service calls that makes it easy to manipulate parameters from the command-line. - -``ros2 param list`` -------------------- - -This command will list all of the available parameters on a given node, or on all discoverable nodes if no node is given. - -To get all of the parameters on a given node: - -.. code-block:: console - - $ ros2 param list /my_node - -To get all of the parameters on all nodes in the system (this can take a long time on a complicated network): - -.. code-block:: console - - $ ros2 param list - -``ros2 param get`` ------------------- - -This command will get the value of a particular parameter. -It can query a specific node or search across all nodes. - -To get the value of a parameter across all nodes: - -.. code-block:: console - - $ ros2 param get use_sim_time - -This will display the parameter value for each node that has this parameter set. - -To get the value of a parameter on a specific node: - -.. code-block:: console - - $ ros2 param get /my_node use_sim_time - -``ros2 param set`` ------------------- - -This command will set the value of a particular parameter on a particular node. -For most parameters, the type of the new value must be the same as the existing type. - -To set the value of a parameter on a node: - -.. code-block:: console - - $ ros2 param set /my_node use_sim_time false - -The value that is passed on the command-line is in YAML, which allows arbitrary YAML expressions to be used. -However, it also means that certain expressions will be interpreted differently than might be expected. -For instance, if the parameter ``my_string`` on node ``my_node`` is of type string, the following will not work: - -.. code-block:: console - - $ ros2 param set /my_node my_string off - -That's because YAML is interpreting "off" as a boolean, and ``my_string`` is a string type. -This can be worked around by using the YAML syntax for explicitly setting strings, e.g.: - -.. code-block:: console - - $ ros param set /my_node my_string '!!str off' - -Additionally, YAML supports heterogeneous lists, containing (say) a string, a boolean, and an integer. -However, ROS 2 parameters do not support heterogeneous lists, so any YAML list that has multiple types will be interpreted as a string. -Assuming that the parameter ``my_int_array`` on node ``my_node`` is of type integer array, the following will not work: - -.. code-block:: console - - $ ros param set /my_node my_int_array '[foo,off,1]' - -The following string typed parameter would work: - -.. code-block:: console - - $ ros param set /my_node my_string '[foo,off,1]' - -``ros2 param delete`` ---------------------- - -This command will remove a parameter from a particular node. -However, note that this can only remove dynamic parameters (not declared parameters). -See :doc:`the concept document <../Concepts/Basic/About-Parameters>` for more information. - -.. code-block:: console - - $ ros2 param delete /my_node my_string - -``ros2 param describe`` ------------------------ - -This command will provide a textual description of a particular parameter on a particular node: - -.. code-block:: console - - $ ros2 param describe /my_node use_sim_time - -``ros2 param dump`` -------------------- - -This command will print out all of the parameters on a particular node in a YAML file format. -The output of this command can then be used to re-run the node with the same parameters later: - -.. code-block:: console - - $ ros2 param dump /my_node - -``ros2 param load`` -------------------- - -This command will load the values of the parameters from a YAML file into a particular node. -That is, this command can reload values at runtime that were dumped out by ``ros2 param dump``: - -.. code-block:: console - - $ ros2 param load /my_node my_node.yaml +.. redirect-from:: + + How-To-Guides/Using-ros2-param + +Using the ``ros2 param`` command-line tool +========================================== + +.. contents:: Table of Contents + :depth: 1 + :local: + +Parameters in ROS 2 can be get, set, listed, and described through a set of services as described in :doc:`the concept document <../../About-Parameters>`. +The ``ros2 param`` command-line tool is a wrapper around these service calls that makes it easy to manipulate parameters from the command-line. + +``ros2 param list`` +------------------- + +This command will list all of the available parameters on a given node, or on all discoverable nodes if no node is given. + +To get all of the parameters on a given node: + +.. code-block:: console + + $ ros2 param list /my_node + +To get all of the parameters on all nodes in the system (this can take a long time on a complicated network): + +.. code-block:: console + + $ ros2 param list + +``ros2 param get`` +------------------ + +This command will get the value of a particular parameter. +It can query a specific node or search across all nodes. + +To get the value of a parameter across all nodes: + +.. code-block:: console + + $ ros2 param get use_sim_time + +This will display the parameter value for each node that has this parameter set. + +To get the value of a parameter on a specific node: + +.. code-block:: console + + $ ros2 param get /my_node use_sim_time + +``ros2 param set`` +------------------ + +This command will set the value of a particular parameter on a particular node. +For most parameters, the type of the new value must be the same as the existing type. + +To set the value of a parameter on a node: + +.. code-block:: console + + $ ros2 param set /my_node use_sim_time false + +The value that is passed on the command-line is in YAML, which allows arbitrary YAML expressions to be used. +However, it also means that certain expressions will be interpreted differently than might be expected. +For instance, if the parameter ``my_string`` on node ``my_node`` is of type string, the following will not work: + +.. code-block:: console + + $ ros2 param set /my_node my_string off + +That's because YAML is interpreting "off" as a boolean, and ``my_string`` is a string type. +This can be worked around by using the YAML syntax for explicitly setting strings, e.g.: + +.. code-block:: console + + $ ros param set /my_node my_string '!!str off' + +Additionally, YAML supports heterogeneous lists, containing (say) a string, a boolean, and an integer. +However, ROS 2 parameters do not support heterogeneous lists, so any YAML list that has multiple types will be interpreted as a string. +Assuming that the parameter ``my_int_array`` on node ``my_node`` is of type integer array, the following will not work: + +.. code-block:: console + + $ ros param set /my_node my_int_array '[foo,off,1]' + +The following string typed parameter would work: + +.. code-block:: console + + $ ros param set /my_node my_string '[foo,off,1]' + +``ros2 param delete`` +--------------------- + +This command will remove a parameter from a particular node. +However, note that this can only remove dynamic parameters (not declared parameters). +See :doc:`the concept document <../../About-Parameters>` for more information. + +.. code-block:: console + + $ ros2 param delete /my_node my_string + +``ros2 param describe`` +----------------------- + +This command will provide a textual description of a particular parameter on a particular node: + +.. code-block:: console + + $ ros2 param describe /my_node use_sim_time + +``ros2 param dump`` +------------------- + +This command will print out all of the parameters on a particular node in a YAML file format. +The output of this command can then be used to re-run the node with the same parameters later: + +.. code-block:: console + + $ ros2 param dump /my_node + +``ros2 param load`` +------------------- + +This command will load the values of the parameters from a YAML file into a particular node. +That is, this command can reload values at runtime that were dumped out by ``ros2 param dump``: + +.. code-block:: console + + $ ros2 param load /my_node my_node.yaml \ No newline at end of file diff --git a/source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst b/source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst index ce064640ace..b88e0b6affc 100644 --- a/source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst +++ b/source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst @@ -1,150 +1,151 @@ -.. redirect-from:: - - Guides/Sync-Vs-Async - Tutorials/Sync-Vs-Async - -.. _SyncAsync: - -Synchronous vs. asynchronous service clients -============================================ - -**Level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Introduction ------------- - -This guide is intended to warn users of the risks associated with the Python synchronous service client ``call()`` API. -It is very easy to mistakenly cause deadlock when calling services synchronously, so we do not recommend using ``call()``. - -We provide an example on how to use ``call()`` correctly for experienced users who wish to use synchronous calls and are aware of the pitfalls. -We also highlight possible scenarios for deadlock that accompany it. - -Because we recommend avoiding sync calls, this guide will also address the features and usage of the recommended alternative, async calls (``call_async()``). - -The C++ service call API is only available in async, so the comparisons and examples in this guide pertain to Python services and clients. -The definition of async given here generally applies to C++, with some exceptions. - -1 Synchronous calls -------------------- - -A synchronous client will block the calling thread when sending a request to a service until a response has been received; nothing else can happen on that thread during the call. -The call can take arbitrary amounts of time to complete. -Once complete, the response returns directly to the client. - -The following is an example of how to correctly execute a synchronous service call from a client node, similar to the async node in the :doc:`Simple Service and Client <../Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial. - -.. code-block:: python - - from threading import Thread - - from example_interfaces.srv import AddTwoInts - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - class MinimalClientSync(Node): - - def __init__(self): - super().__init__('minimal_client_sync') - self.cli = self.create_client(AddTwoInts, 'add_two_ints') - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddTwoInts.Request() - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - return self.cli.call(self.req) - # This only works because rclpy.spin() is called in a separate thread below. - # Another configuration, like spinning later in main() or calling this method from a timer callback, would result in a deadlock. - - def main(): - try: - with rclpy.init(): - minimal_client = MinimalClientSync() - - spin_thread = Thread(target=rclpy.spin, args=(minimal_client,)) - spin_thread.start() - - response = minimal_client.send_request() - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -Note inside ``main()`` that the client calls ``rclpy.spin`` in a separate thread. -Both ``send_request`` and ``rclpy.spin`` are blocking, so they need to be on separate threads. - -1.1 Sync deadlock ------------------ - -There are several ways that the synchronous ``call()`` API can cause deadlock. - -As mentioned in the comments of the example above, failing to create a separate thread to spin ``rclpy`` is one cause of deadlock. -When a client is blocking a thread waiting for a response, but the response can only be returned on that same thread, the client will never stop waiting, and nothing else can happen. - -Another cause of deadlock is blocking ``rclpy.spin`` by calling a service synchronously in a subscription, timer callback or service callback. -For example, if the synchronous client's ``send_request`` is placed in a callback: - -.. code-block:: python - - def trigger_request(msg): - response = minimal_client.send_request() # This will cause deadlock - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - subscription = minimal_client.create_subscription(String, 'trigger', trigger_request, 10) - - rclpy.spin(minimal_client) - -Deadlock occurs because ``rclpy.spin`` will not preempt the callback with the ``send_request`` call. -In general, callbacks should only perform light and fast operations. - -.. warning:: - - When deadlock occurs, you will not receive any indication that the service is blocked. - There will be no warning or exception thrown, no indication in the stack trace, and the call will not fail. - -2 Asynchronous calls --------------------- - -Async calls in ``rclpy`` are entirely safe and the recommended method of calling services. -They can be made from anywhere without running the risk of blocking other ROS and non-ROS processes, unlike sync calls. - -An asynchronous client will immediately return ``future``, a value that indicates whether the call and response is finished (not the value of the response itself), after sending a request to a service. -The returned ``future`` may be queried for a response at any time. - -Since sending a request doesn't block anything, a loop can be used to both spin ``rclpy`` and check ``future`` in the same thread, for example: - -.. code-block:: python - - while rclpy.ok(): - rclpy.spin_once(node) - if future.done(): - #Get response - -The :doc:`Simple Service and Client <../Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial for Python illustrates how to perform an async service call and retrieve the ``future`` using a loop. - -The ``future`` can also be retrieved using a timer or callback, like in `this example `_, a dedicated thread, or by another method. -It is up to you, as the caller, to decide how to store ``future``, check on its status, and retrieve your response. - -Summary -------- - -It is not recommended to implement a synchronous service client. -They are susceptible to deadlock, but will not provide any indication of issue when deadlock occurs. -If you must use synchronous calls, the example in section `1 Synchronous calls`_ is a safe method of doing so. -You should also be aware of the conditions that cause deadlock outlined in section `1.1 Sync deadlock`_. -We recommend using async service clients instead. +.. redirect-from:: + + Guides/Sync-Vs-Async + Tutorials/Sync-Vs-Async + How-To-Guides/Sync-Vs-Async + +.. _SyncAsync: + +Synchronous vs. asynchronous service clients +============================================ + +**Level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Introduction +------------ + +This guide is intended to warn users of the risks associated with the Python synchronous service client ``call()`` API. +It is very easy to mistakenly cause deadlock when calling services synchronously, so we do not recommend using ``call()``. + +We provide an example on how to use ``call()`` correctly for experienced users who wish to use synchronous calls and are aware of the pitfalls. +We also highlight possible scenarios for deadlock that accompany it. + +Because we recommend avoiding sync calls, this guide will also address the features and usage of the recommended alternative, async calls (``call_async()``). + +The C++ service call API is only available in async, so the comparisons and examples in this guide pertain to Python services and clients. +The definition of async given here generally applies to C++, with some exceptions. + +1 Synchronous calls +------------------- + +A synchronous client will block the calling thread when sending a request to a service until a response has been received; nothing else can happen on that thread during the call. +The call can take arbitrary amounts of time to complete. +Once complete, the response returns directly to the client. + +The following is an example of how to correctly execute a synchronous service call from a client node, similar to the async node in the :doc:`Simple Service and Client <../../client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial. + +.. code-block:: python + + from threading import Thread + + from example_interfaces.srv import AddTwoInts + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + class MinimalClientSync(Node): + + def __init__(self): + super().__init__('minimal_client_sync') + self.cli = self.create_client(AddTwoInts, 'add_two_ints') + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddTwoInts.Request() + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + return self.cli.call(self.req) + # This only works because rclpy.spin() is called in a separate thread below. + # Another configuration, like spinning later in main() or calling this method from a timer callback, would result in a deadlock. + + def main(): + try: + with rclpy.init(): + minimal_client = MinimalClientSync() + + spin_thread = Thread(target=rclpy.spin, args=(minimal_client,)) + spin_thread.start() + + response = minimal_client.send_request() + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +Note inside ``main()`` that the client calls ``rclpy.spin`` in a separate thread. +Both ``send_request`` and ``rclpy.spin`` are blocking, so they need to be on separate threads. + +1.1 Sync deadlock +----------------- + +There are several ways that the synchronous ``call()`` API can cause deadlock. + +As mentioned in the comments of the example above, failing to create a separate thread to spin ``rclpy`` is one cause of deadlock. +When a client is blocking a thread waiting for a response, but the response can only be returned on that same thread, the client will never stop waiting, and nothing else can happen. + +Another cause of deadlock is blocking ``rclpy.spin`` by calling a service synchronously in a subscription, timer callback or service callback. +For example, if the synchronous client's ``send_request`` is placed in a callback: + +.. code-block:: python + + def trigger_request(msg): + response = minimal_client.send_request() # This will cause deadlock + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + subscription = minimal_client.create_subscription(String, 'trigger', trigger_request, 10) + + rclpy.spin(minimal_client) + +Deadlock occurs because ``rclpy.spin`` will not preempt the callback with the ``send_request`` call. +In general, callbacks should only perform light and fast operations. + +.. warning:: + + When deadlock occurs, you will not receive any indication that the service is blocked. + There will be no warning or exception thrown, no indication in the stack trace, and the call will not fail. + +2 Asynchronous calls +-------------------- + +Async calls in ``rclpy`` are entirely safe and the recommended method of calling services. +They can be made from anywhere without running the risk of blocking other ROS and non-ROS processes, unlike sync calls. + +An asynchronous client will immediately return ``future``, a value that indicates whether the call and response is finished (not the value of the response itself), after sending a request to a service. +The returned ``future`` may be queried for a response at any time. + +Since sending a request doesn't block anything, a loop can be used to both spin ``rclpy`` and check ``future`` in the same thread, for example: + +.. code-block:: python + + while rclpy.ok(): + rclpy.spin_once(node) + if future.done(): + #Get response + +The :doc:`Simple Service and Client <../../client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial for Python illustrates how to perform an async service call and retrieve the ``future`` using a loop. + +The ``future`` can also be retrieved using a timer or callback, like in `this example `_, a dedicated thread, or by another method. +It is up to you, as the caller, to decide how to store ``future``, check on its status, and retrieve your response. + +Summary +------- + +It is not recommended to implement a synchronous service client. +They are susceptible to deadlock, but will not provide any indication of issue when deadlock occurs. +If you must use synchronous calls, the example in section `1 Synchronous calls`_ is a safe method of doing so. +You should also be aware of the conditions that cause deadlock outlined in section `1.1 Sync deadlock`_. +We recommend using async service clients instead. \ No newline at end of file diff --git a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst b/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst index a2a5560b16d..c56cf0a95c0 100644 --- a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst +++ b/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst @@ -1,415 +1,416 @@ -.. redirect-from:: - - Tutorials/Services/Understanding-ROS2-Services - -.. _ROS2Services: - -Understanding services -====================== - -**Goal:** Learn about services in ROS 2 using command line tools. - -**Tutorial level:** Beginner - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Services are another method of communication for nodes in the ROS graph. -Services are based on a call-and-response model versus the publisher-subscriber model of topics. -While topics allow nodes to subscribe to data streams and get continual updates, services only provide data when they are specifically called by a client. - -.. image:: images/Service-SingleServiceClient.gif - -.. image:: images/Service-MultipleServiceClient.gif - -Prerequisites -------------- - -Some concepts mentioned in this tutorial, like :doc:`Nodes <../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`Topics <../Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, were covered in previous tutorials in the series. - -You will need the :doc:`turtlesim package <../Introducing-Turtlesim/Introducing-Turtlesim>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ -Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -2 ros2 service list -^^^^^^^^^^^^^^^^^^^ - -Running the ``ros2 service list`` command in a new terminal will return a list of all the services currently active in the system: - -.. code-block:: console - - $ ros2 service list - /clear - /kill - /reset - /spawn - /teleop_turtle/describe_parameters - /teleop_turtle/get_parameter_types - /teleop_turtle/get_parameters - /teleop_turtle/list_parameters - /teleop_turtle/set_parameters - /teleop_turtle/set_parameters_atomically - /turtle1/set_pen - /turtle1/teleport_absolute - /turtle1/teleport_relative - /turtlesim/describe_parameters - /turtlesim/get_parameter_types - /turtlesim/get_parameters - /turtlesim/list_parameters - /turtlesim/set_parameters - /turtlesim/set_parameters_atomically - -You will see that both nodes have the same six services with ``parameters`` in their names. -Nearly every node in ROS 2 has these infrastructure services that parameters are built off of. -There will be more about parameters in the next tutorial. -In this tutorial, the parameter services will be omitted from the discussion. - -For now, let's focus on the turtlesim-specific services, ``/clear``, ``/kill``, ``/reset``, ``/spawn``, ``/turtle1/set_pen``, ``/turtle1/teleport_absolute``, and ``/turtle1/teleport_relative``. -You may recall interacting with some of these services using rqt in the :doc:`Use turtlesim, ros2, and rqt <../Introducing-Turtlesim/Introducing-Turtlesim>` tutorial. - - -3 ros2 service type -^^^^^^^^^^^^^^^^^^^ - -Services have types that describe how the request and response data of a service is structured. -Service types are defined similarly to topic types, except service types have two parts: one message for the request and another for the response. - -To find out the type of a service, use the command: - -.. code-block:: console - - $ ros2 service type - -Let's take a look at turtlesim's ``/clear`` service. -In a new terminal, enter the command: - -.. code-block:: console - - $ ros2 service type /clear - std_srvs/srv/Empty - -The ``Empty`` type means the service call sends no data when making a request and receives no data when receiving a response. - -3.1 ros2 service list -t -~~~~~~~~~~~~~~~~~~~~~~~~ - -To see the types of all the active services at the same time, you can append the ``--show-types`` option, abbreviated as ``-t``, to the ``list`` command: - -.. code-block:: console - - $ ros2 service list -t - /clear [std_srvs/srv/Empty] - /kill [turtlesim_msgs/srv/Kill] - /reset [std_srvs/srv/Empty] - /spawn [turtlesim_msgs/srv/Spawn] - ... - /turtle1/set_pen [turtlesim_msgs/srv/SetPen] - /turtle1/teleport_absolute [turtlesim_msgs/srv/TeleportAbsolute] - /turtle1/teleport_relative [turtlesim_msgs/srv/TeleportRelative] - ... - -4 ros2 service info -^^^^^^^^^^^^^^^^^^^ - -To see information of a particular service, use the command: - -.. code-block:: console - - $ ros2 service info - -This returns the service type and the count of service clients and servers. - -For example, you can find the count of clients and servers for the ``/clear`` service: - -.. code-block:: console - - $ ros2 service info /clear - Type: std_srvs/srv/Empty - Clients count: 0 - Services count: 1 - -4.1 ros2 service info --verbose -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For more detailed information about a service, you can append the ``--verbose`` (or ``-v``) option to the ``info`` command: - -.. code-block:: console - - $ ros2 service info --verbose - -For example: you can get verbose information about the ``/clear`` service: - -.. code-block:: console - - $ ros2 service info --verbose /clear - -This will return additional information including the node name and namespace of the service server, as well as the underlying middleware (RMW) implementation details. -An important information for Developers that the ``Endpoint count`` will be 2 for DDS based RMW implementations (connextdds, cyclone, fastrtps) because DDS creates two endpoints (one for request and one for response) for each service server. - -.. code-block:: console - - Type: std_srvs/srv/Empty - Clients count: 0 - Services count: 1 - Node name: turtlesim - Node namespace: / - Service type: std_srvs/srv/Empty - Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 - Endpoint type: SERVER - Endpoint count: 2 - GIDs: - - Request Reader : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.13.04 - - Response Writer : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.14.03 - QoS profiles: - - Request Reader : - Reliability: RELIABLE - History (Depth): KEEP_LAST (10) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Response Writer : - Reliability: RELIABLE - History (Depth): KEEP_LAST (10) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -Where as for non-DDS based RMW implementations like ``rmw_zenoh_cpp``, the ``Endpoint count`` will be 1 because it uses a single endpoint for both request and response. - -.. code-block:: console - - Type: std_srvs/srv/Empty - Clients count: 0 - Services count: 1 - Node name: turtlesim - Node namespace: / - Service type: std_srvs/srv/Empty - Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 - Endpoint type: SERVER - Endpoint count: 1 - GID: 59.b0.ea.78.57.3c.52.b4.c6.e9.af.44.22.3d.7c.f5 - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (10) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -If you want to learn more about different RMW implementations, refer to the :doc:`About Different Middleware Vendors <../../../Concepts/Intermediate/About-Different-Middleware-Vendors>` concept. - -5 ros2 service find -^^^^^^^^^^^^^^^^^^^ - -If you want to find all the services of a specific type, you can use the command: - -.. code-block:: console - - $ ros2 service find - -For example, you can find all the ``Empty`` typed services like this: - -.. code-block:: console - - $ ros2 service find std_srvs/srv/Empty - /clear - /reset - -6 ros2 interface show -^^^^^^^^^^^^^^^^^^^^^ - -You can call services from the command line, but first you need to know the structure of the input arguments. - -.. code-block:: console - - $ ros2 interface show - -Try this on the ``/clear`` service's type, ``Empty``: - -.. code-block:: console - - $ ros2 interface show std_srvs/srv/Empty - --- - -The ``---`` separates the request structure (above) from the response structure (below). -But, as you learned earlier, the ``Empty`` type doesn't send or receive any data. -So, naturally, its structure is blank. - -Let's introspect a service with a type that sends and receives data, like ``/spawn``. -From the results of ``ros2 service list -t``, we know ``/spawn``'s type is ``turtlesim_msgs/srv/Spawn``. - -To see the request and response arguments of the ``/spawn`` service, run the command: - -.. code-block:: console - - $ ros2 interface show turtlesim_msgs/srv/Spawn - float32 x - float32 y - float32 theta - string name # Optional. A unique name will be created and returned if this is empty - --- - string name - -The information above the ``---`` line tells us the arguments needed to call ``/spawn``. -``x``, ``y`` and ``theta`` determine the 2D pose of the spawned turtle, and ``name`` is clearly optional. - -The information below the line isn't something you need to know in this case, but it can help you understand the data type of the response you get from the call. - -7 ros2 service call -^^^^^^^^^^^^^^^^^^^ - -Now that you know what a service type is, how to find a service's type, and how to find the structure of that type's arguments, you can call a service using: - -.. code-block:: console - - $ ros2 service call - -The ```` part is optional. -For example, you know that ``Empty`` typed services don't have any arguments: - -.. code-block:: console - - $ ros2 service call /clear std_srvs/srv/Empty - -This command will clear the turtlesim window of any lines your turtle has drawn. - -.. image:: images/clear.png - -Now let's spawn a new turtle by calling ``/spawn`` and setting arguments. -Input ```` in a service call from the command-line need to be in YAML syntax. - -Enter the command: - -.. code-block:: console - - $ ros2 service call /spawn turtlesim_msgs/srv/Spawn "{x: 2, y: 2, theta: 0.2, name: ''}" - requester: making request: turtlesim_msgs.srv.Spawn_Request(x=2.0, y=2.0, theta=0.2, name='') - - response: - turtlesim_msgs.srv.Spawn_Response(name='turtle2') - -You will get this method-style view of what's happening, and then the service response. - -Your turtlesim window will update with the newly spawned turtle right away: - -.. image:: images/spawn.png - -8 ros2 service echo -^^^^^^^^^^^^^^^^^^^ - -To see the data communication between a service client and a service server you can ``echo`` the service using: - -.. code-block:: console - - $ ros2 service echo - -``ros2 service echo`` depends on service introspection of a service client and server, that is disabled by default. -To enable it, users must call ``configure_introspection`` after creating a service client or server. - -Start up the ``introspection_client`` and ``introspection_service`` service introspection demo. - -.. code-block:: console - - $ ros2 launch demo_nodes_cpp introspect_services_launch.py - -Open another terminal and run the following to enable service introspection for ``introspection_client`` and ``introspection_service``. - -.. code-block:: console - - $ ros2 param set /introspection_service service_configure_introspection contents - $ ros2 param set /introspection_client client_configure_introspection contents - -Now we are able to see the service communication between ``introspection_client`` and ``introspection_service`` via ``ros2 service echo``. - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - info: - event_type: REQUEST_SENT - stamp: - sec: 1709408301 - nanosec: 423227292 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 618 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1709408301 - nanosec: 423601471 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 618 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: RESPONSE_SENT - stamp: - sec: 1709408301 - nanosec: 423900744 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 618 - request: [] - response: [{sum: 5}] - --- - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1709408301 - nanosec: 424153133 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 618 - request: [] - response: [{sum: 5}] - --- - -Summary -------- - -Nodes can communicate using services in ROS 2. -Unlike a topic - a one way communication pattern where a node publishes information that can be consumed by one or more subscribers - a service is a request/response pattern where a client makes a request to a node providing the service and the service processes the request and generates a response. - -You generally don't want to use a service for continuous calls; topics or even actions would be better suited. - -In this tutorial you used command line tools to identify, introspect, and call services. - -Next steps ----------- - -In the next tutorial, :doc:`../Understanding-ROS2-Parameters/Understanding-ROS2-Parameters`, you will learn about configuring node settings. - -Related content ---------------- - -Check out `this tutorial `_; it's an excellent realistic application of ROS services using a Robotis robot arm. +.. redirect-from:: + + Tutorials/Services/Understanding-ROS2-Services + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services + +.. _ROS2Services: + +Understanding services +====================== + +**Goal:** Learn about services in ROS 2 using command line tools. + +**Tutorial level:** Beginner + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Services are another method of communication for nodes in the ROS graph. +Services are based on a call-and-response model versus the publisher-subscriber model of topics. +While topics allow nodes to subscribe to data streams and get continual updates, services only provide data when they are specifically called by a client. + +.. image:: images/Service-SingleServiceClient.gif + +.. image:: images/Service-MultipleServiceClient.gif + +Prerequisites +------------- + +Some concepts mentioned in this tutorial, like :doc:`Nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`Topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, were covered in previous tutorials in the series. + +You will need the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ +Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +2 ros2 service list +^^^^^^^^^^^^^^^^^^^ + +Running the ``ros2 service list`` command in a new terminal will return a list of all the services currently active in the system: + +.. code-block:: console + + $ ros2 service list + /clear + /kill + /reset + /spawn + /teleop_turtle/describe_parameters + /teleop_turtle/get_parameter_types + /teleop_turtle/get_parameters + /teleop_turtle/list_parameters + /teleop_turtle/set_parameters + /teleop_turtle/set_parameters_atomically + /turtle1/set_pen + /turtle1/teleport_absolute + /turtle1/teleport_relative + /turtlesim/describe_parameters + /turtlesim/get_parameter_types + /turtlesim/get_parameters + /turtlesim/list_parameters + /turtlesim/set_parameters + /turtlesim/set_parameters_atomically + +You will see that both nodes have the same six services with ``parameters`` in their names. +Nearly every node in ROS 2 has these infrastructure services that parameters are built off of. +There will be more about parameters in the next tutorial. +In this tutorial, the parameter services will be omitted from the discussion. + +For now, let's focus on the turtlesim-specific services, ``/clear``, ``/kill``, ``/reset``, ``/spawn``, ``/turtle1/set_pen``, ``/turtle1/teleport_absolute``, and ``/turtle1/teleport_relative``. +You may recall interacting with some of these services using rqt in the :doc:`Use turtlesim, ros2, and rqt <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` tutorial. + + +3 ros2 service type +^^^^^^^^^^^^^^^^^^^ + +Services have types that describe how the request and response data of a service is structured. +Service types are defined similarly to topic types, except service types have two parts: one message for the request and another for the response. + +To find out the type of a service, use the command: + +.. code-block:: console + + $ ros2 service type + +Let's take a look at turtlesim's ``/clear`` service. +In a new terminal, enter the command: + +.. code-block:: console + + $ ros2 service type /clear + std_srvs/srv/Empty + +The ``Empty`` type means the service call sends no data when making a request and receives no data when receiving a response. + +3.1 ros2 service list -t +~~~~~~~~~~~~~~~~~~~~~~~~ + +To see the types of all the active services at the same time, you can append the ``--show-types`` option, abbreviated as ``-t``, to the ``list`` command: + +.. code-block:: console + + $ ros2 service list -t + /clear [std_srvs/srv/Empty] + /kill [turtlesim_msgs/srv/Kill] + /reset [std_srvs/srv/Empty] + /spawn [turtlesim_msgs/srv/Spawn] + ... + /turtle1/set_pen [turtlesim_msgs/srv/SetPen] + /turtle1/teleport_absolute [turtlesim_msgs/srv/TeleportAbsolute] + /turtle1/teleport_relative [turtlesim_msgs/srv/TeleportRelative] + ... + +4 ros2 service info +^^^^^^^^^^^^^^^^^^^ + +To see information of a particular service, use the command: + +.. code-block:: console + + $ ros2 service info + +This returns the service type and the count of service clients and servers. + +For example, you can find the count of clients and servers for the ``/clear`` service: + +.. code-block:: console + + $ ros2 service info /clear + Type: std_srvs/srv/Empty + Clients count: 0 + Services count: 1 + +4.1 ros2 service info --verbose +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For more detailed information about a service, you can append the ``--verbose`` (or ``-v``) option to the ``info`` command: + +.. code-block:: console + + $ ros2 service info --verbose + +For example: you can get verbose information about the ``/clear`` service: + +.. code-block:: console + + $ ros2 service info --verbose /clear + +This will return additional information including the node name and namespace of the service server, as well as the underlying middleware (RMW) implementation details. +An important information for Developers that the ``Endpoint count`` will be 2 for DDS based RMW implementations (connextdds, cyclone, fastrtps) because DDS creates two endpoints (one for request and one for response) for each service server. + +.. code-block:: console + + Type: std_srvs/srv/Empty + Clients count: 0 + Services count: 1 + Node name: turtlesim + Node namespace: / + Service type: std_srvs/srv/Empty + Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 + Endpoint type: SERVER + Endpoint count: 2 + GIDs: + - Request Reader : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.13.04 + - Response Writer : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.14.03 + QoS profiles: + - Request Reader : + Reliability: RELIABLE + History (Depth): KEEP_LAST (10) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + - Response Writer : + Reliability: RELIABLE + History (Depth): KEEP_LAST (10) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +Where as for non-DDS based RMW implementations like ``rmw_zenoh_cpp``, the ``Endpoint count`` will be 1 because it uses a single endpoint for both request and response. + +.. code-block:: console + + Type: std_srvs/srv/Empty + Clients count: 0 + Services count: 1 + Node name: turtlesim + Node namespace: / + Service type: std_srvs/srv/Empty + Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 + Endpoint type: SERVER + Endpoint count: 1 + GID: 59.b0.ea.78.57.3c.52.b4.c6.e9.af.44.22.3d.7c.f5 + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (10) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +If you want to learn more about different RMW implementations, refer to the :doc:`About Different Middleware Vendors <../../../client-libraries/About-Different-Middleware-Vendors>` concept. + +5 ros2 service find +^^^^^^^^^^^^^^^^^^^ + +If you want to find all the services of a specific type, you can use the command: + +.. code-block:: console + + $ ros2 service find + +For example, you can find all the ``Empty`` typed services like this: + +.. code-block:: console + + $ ros2 service find std_srvs/srv/Empty + /clear + /reset + +6 ros2 interface show +^^^^^^^^^^^^^^^^^^^^^ + +You can call services from the command line, but first you need to know the structure of the input arguments. + +.. code-block:: console + + $ ros2 interface show + +Try this on the ``/clear`` service's type, ``Empty``: + +.. code-block:: console + + $ ros2 interface show std_srvs/srv/Empty + --- + +The ``---`` separates the request structure (above) from the response structure (below). +But, as you learned earlier, the ``Empty`` type doesn't send or receive any data. +So, naturally, its structure is blank. + +Let's introspect a service with a type that sends and receives data, like ``/spawn``. +From the results of ``ros2 service list -t``, we know ``/spawn``'s type is ``turtlesim_msgs/srv/Spawn``. + +To see the request and response arguments of the ``/spawn`` service, run the command: + +.. code-block:: console + + $ ros2 interface show turtlesim_msgs/srv/Spawn + float32 x + float32 y + float32 theta + string name # Optional. A unique name will be created and returned if this is empty + --- + string name + +The information above the ``---`` line tells us the arguments needed to call ``/spawn``. +``x``, ``y`` and ``theta`` determine the 2D pose of the spawned turtle, and ``name`` is clearly optional. + +The information below the line isn't something you need to know in this case, but it can help you understand the data type of the response you get from the call. + +7 ros2 service call +^^^^^^^^^^^^^^^^^^^ + +Now that you know what a service type is, how to find a service's type, and how to find the structure of that type's arguments, you can call a service using: + +.. code-block:: console + + $ ros2 service call + +The ```` part is optional. +For example, you know that ``Empty`` typed services don't have any arguments: + +.. code-block:: console + + $ ros2 service call /clear std_srvs/srv/Empty + +This command will clear the turtlesim window of any lines your turtle has drawn. + +.. image:: images/clear.png + +Now let's spawn a new turtle by calling ``/spawn`` and setting arguments. +Input ```` in a service call from the command-line need to be in YAML syntax. + +Enter the command: + +.. code-block:: console + + $ ros2 service call /spawn turtlesim_msgs/srv/Spawn "{x: 2, y: 2, theta: 0.2, name: ''}" + requester: making request: turtlesim_msgs.srv.Spawn_Request(x=2.0, y=2.0, theta=0.2, name='') + + response: + turtlesim_msgs.srv.Spawn_Response(name='turtle2') + +You will get this method-style view of what's happening, and then the service response. + +Your turtlesim window will update with the newly spawned turtle right away: + +.. image:: images/spawn.png + +8 ros2 service echo +^^^^^^^^^^^^^^^^^^^ + +To see the data communication between a service client and a service server you can ``echo`` the service using: + +.. code-block:: console + + $ ros2 service echo + +``ros2 service echo`` depends on service introspection of a service client and server, that is disabled by default. +To enable it, users must call ``configure_introspection`` after creating a service client or server. + +Start up the ``introspection_client`` and ``introspection_service`` service introspection demo. + +.. code-block:: console + + $ ros2 launch demo_nodes_cpp introspect_services_launch.py + +Open another terminal and run the following to enable service introspection for ``introspection_client`` and ``introspection_service``. + +.. code-block:: console + + $ ros2 param set /introspection_service service_configure_introspection contents + $ ros2 param set /introspection_client client_configure_introspection contents + +Now we are able to see the service communication between ``introspection_client`` and ``introspection_service`` via ``ros2 service echo``. + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + info: + event_type: REQUEST_SENT + stamp: + sec: 1709408301 + nanosec: 423227292 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 618 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1709408301 + nanosec: 423601471 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 618 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: RESPONSE_SENT + stamp: + sec: 1709408301 + nanosec: 423900744 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 618 + request: [] + response: [{sum: 5}] + --- + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1709408301 + nanosec: 424153133 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 618 + request: [] + response: [{sum: 5}] + --- + +Summary +------- + +Nodes can communicate using services in ROS 2. +Unlike a topic - a one way communication pattern where a node publishes information that can be consumed by one or more subscribers - a service is a request/response pattern where a client makes a request to a node providing the service and the service processes the request and generates a response. + +You generally don't want to use a service for continuous calls; topics or even actions would be better suited. + +In this tutorial you used command line tools to identify, introspect, and call services. + +Next steps +---------- + +In the next tutorial, :doc:`../../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters`, you will learn about configuring node settings. + +Related content +--------------- + +Check out `this tutorial `_; it's an excellent realistic application of ROS services using a Robotis robot arm. \ No newline at end of file diff --git a/source/ROS-Framework/topics/About-Quality-of-Service-Settings.rst b/source/ROS-Framework/topics/About-Quality-of-Service-Settings.rst index a3bef6c9033..ac3c83b152c 100644 --- a/source/ROS-Framework/topics/About-Quality-of-Service-Settings.rst +++ b/source/ROS-Framework/topics/About-Quality-of-Service-Settings.rst @@ -1,335 +1,336 @@ -.. redirect-from:: - - About-Quality-of-Service-Settings - Concepts/About-Quality-of-Service-Settings - -Quality of Service settings -=========================== - -.. contents:: Table of Contents - :local: - -Overview --------- - -ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes. -With the right set of Quality of Service policies, ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between. -Unlike ROS 1, which primarily only supported TCP, ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a "best effort" policy would be more suitable, or in real-time computing systems where the right Quality of Service profile is needed to meet deadlines. - -A set of QoS "policies" combine to form a QoS "profile". -Given the complexity of choosing the correct QoS policies for a given scenario, ROS 2 provides a set of predefined QoS profiles for common use cases (e.g. sensor data). -At the same time, developers are given the flexibility to control specific policies of the QoS profiles. - -QoS profiles can be specified for publishers, subscriptions, service servers and clients. -A QoS profile can be applied independently to each instance of the aforementioned entities, but if different profiles are used, it is possible that they will be incompatible, preventing the delivery of messages. - -.. _about_qos_policies: - -QoS policies ------------- - -The base QoS profile currently includes settings for the following policies: - -* History - - * *Keep last*: only store up to N samples, configurable via the queue depth option. - * *Keep all*: store all samples, subject to the configured resource limits of the underlying middleware. - -* Depth - - * *Queue size*: only honored if the "history" policy was set to "keep last". - -* Reliability - - * *Best effort*: attempt to deliver samples, but may lose them if the network is not robust. - * *Reliable*: guarantee that samples are delivered, may retry multiple times. - -* Durability - - * *Transient local*: the publisher becomes responsible for persisting samples for "late-joining" subscriptions. - * *Volatile*: no attempt is made to persist samples. - -* Deadline - - * *Duration*: the expected maximum amount of time between subsequent messages being published to a topic - -* Lifespan - - * *Duration*: the maximum amount of time between the publishing and the reception of a message without the message being considered stale or expired (expired messages are silently dropped and are effectively never received). - -* Liveliness - - * *Automatic*: the system will consider all of the node's publishers to be alive for another "lease duration" when any one of its publishers has published a message. - * *Manual by topic*: the system will consider the publisher to be alive for another "lease duration" if it manually asserts that it is still alive (via a call to the publisher API). - -* Lease Duration - - * *Duration*: the maximum period of time a publisher has to indicate that it is alive before the system considers it to have lost liveliness (losing liveliness could be an indication of a failure). - -For each of the policies that is not a duration, there is also the option of "system default", which uses the default of the underlying middleware. -For each of the policies that is a duration, there also exists a "default" option that means the duration is unspecified, which the underlying middleware will usually interpret as an infinitely long duration. - -Comparison to ROS 1 -^^^^^^^^^^^^^^^^^^^ - -The "history" and "depth" policies in ROS 2 combine to provide functionality akin to the queue size in ROS 1. - -The "reliability" policy in ROS 2 is akin to the use of either UDPROS (only in ``roscpp``) for "best effort", or TCPROS (ROS 1 default) for "reliable". -Note however that even the reliable policy in ROS 2 is implemented using UDP, which allows for multicasting if appropriate. - -The "durability" policy "transient local", combined with any depth, provides functionality similar to that of "latching" publishers. -The remaining policies in ROS 2 are not akin to anything that is available in ROS 1, meaning that ROS 2 is more featureful than ROS 1 in this respect. -It is possible that in the future, even more QoS policies will be available in ROS 2. - - -QoS profiles ------------- - -Profiles allow developers to focus on their applications without worrying about every QoS setting possible. -A QoS profile defines a set of policies that are expected to go well together for a particular use case. - -The currently defined QoS profiles are: - -* Default QoS settings for publishers and subscriptions - - In order to make the transition from ROS 1 to ROS 2 easier, exercising a similar network behavior is desirable. - By default, publishers and subscriptions in ROS 2 have "keep last" for history with a queue size of 10, "reliable" for reliability, "volatile" for durability, and "system default" for liveliness. - Deadline, lifespan, and lease durations are also all set to "default". - -* Services - - In the same vein as publishers and subscriptions, services are reliable. - It is especially important for services to use volatile durability, as otherwise service servers that re-start may receive outdated requests. - While the client is protected from receiving multiple responses, the server is not protected from side-effects of receiving the outdated requests. - -* Sensor data - - For sensor data, in most cases it's more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. - That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some. - For that reason the sensor data profile uses best effort reliability and a smaller queue size. - -* Parameters - - Parameters in ROS 2 are based on services, and as such have a similar profile. - The difference is that parameters use a much larger queue depth so that requests do not get lost when, for example, the parameter client is unable to reach the parameter service server. - -* System default - - This uses the RMW implementation's default values for all of the policies. - Different RMW implementations may have different defaults. - -`Click here `__ for the specific policies in use for the above profiles. -The settings in these profiles are subject to further tweaks, based on the feedback from the community. - -.. _about-qos_compatibilities: - -QoS compatibilities -------------------- - -**Note:** This section refers to publishers and subscriptions but the content applies to service servers and clients in the same manner. - -QoS profiles may be configured for publishers and subscriptions independently. -A connection between a publisher and a subscription is only made if the pair has compatible QoS profiles. - -QoS profile compatibility is determined based on a "Request vs Offered" model. -Subscriptions *request* a QoS profile that is the "minimum quality" that it is willing to accept, and publishers *offer* a QoS profile that is the "maximum quality" that it is able to provide. -Connections are only made if every policy of the requested QoS profile is not more stringent than that of the offered QoS profile. -Multiple subscriptions can be connected to a single publisher simultaneously even if their requested QoS profiles are different. -The compatibility between a publisher and a subscription is unaffected by the presence of other publishers and subscriptions. - -The following tables show the compatibility of the different policy settings and the result: - -*Compatibility of reliability QoS policies:* - -.. list-table:: - :header-rows: 1 - - * - Publisher - - Subscription - - Compatible - * - Best effort - - Best effort - - Yes - * - Best effort - - Reliable - - No - * - Reliable - - Best effort - - Yes - * - Reliable - - Reliable - - Yes - -*Compatibility of durability QoS policies:* - -.. list-table:: - :header-rows: 1 - - * - Publisher - - Subscription - - Compatible - - Result - * - Volatile - - Volatile - - Yes - - New messages only - * - Volatile - - Transient local - - No - - No communication - * - Transient local - - Volatile - - Yes - - New messages only - * - Transient local - - Transient local - - Yes - - New and old messages - -To achieve a "latched" topic that is visible to late subscribers, -both the publisher and subscriber must agree to use 'Transient Local'. - -*Compatibility of deadline QoS policies:* - - Assume *x* and *y* are arbitrary valid duration values. - -.. list-table:: - :header-rows: 1 - - * - Publisher - - Subscription - - Compatible - * - Default - - Default - - Yes - * - Default - - *x* - - No - * - *x* - - Default - - Yes - * - *x* - - *x* - - Yes - * - *x* - - *y* (where *y* > *x*) - - Yes - * - *x* - - *y* (where *y* < *x*) - - No - -*Compatibility of liveliness QoS policies:* - -.. list-table:: - :header-rows: 1 - - * - Publisher - - Subscription - - Compatible - * - Automatic - - Automatic - - Yes - * - Automatic - - Manual by topic - - No - * - Manual by topic - - Automatic - - Yes - * - Manual by topic - - Manual by topic - - Yes - -*Compatibility of lease duration QoS policies:* - - Assume *x* and *y* are arbitrary valid duration values. - -.. list-table:: - :header-rows: 1 - - * - Publisher - - Subscription - - Compatible - * - Default - - Default - - Yes - * - Default - - *x* - - No - * - *x* - - Default - - Yes - * - *x* - - *x* - - Yes - * - *x* - - *y* (where *y* > *x*) - - Yes - * - *x* - - *y* (where *y* < *x*) - - No - -In order for a connection to be made, all of the policies that affect compatibility must be compatible. -For example, even if a requested and offered QoS profile pair has compatible reliability QoS policies, but they have incompatible durability QoS policies, a connection will still not be made. - -When connections are not made, no messages will be passed between the publisher and subscription. -There are mechanisms to detect this situation, which will be covered in a later section. - -Comparison to ROS 1 -^^^^^^^^^^^^^^^^^^^ - -Historically in ROS 1, any publisher and subscriber with the same message type on the same topic would be connected. -The possibility of incompatible requested and offered QoS profiles is something new to be aware of when using ROS 2. - -.. _about-qos_qos-events: - -QoS events ----------- - -Some QoS policies have possible events related to them. -Developers may provide each publisher and subscription with callback functions that are triggered by these QoS events and handle them in a way they see fit, similar to how messages received on a topic are handled. - -Developers may subscribe to the following QoS events that are associated with a publisher: - -* Offered deadline missed - - The publisher has not published a message within the expected duration that was set out by the deadline QoS policy. - -* Liveliness lost - - The publisher has failed to indicate its liveliness within the lease duration. - -* Offered incompatible QoS - - The publisher has encountered a subscription on the same topic that is requesting a QoS profile that the offered QoS profile cannot satisfy, resulting in no connection between the publisher and that subscription. - -Developers may subscribe to the following QoS events that are associated with a subscription: - -* Requested deadline missed - - The subscription has not received a message within the expected duration that was set out by the deadline QoS policy. - -* Liveliness changed - - The subscription has noticed that one or more publishers on the subscribed topic has failed to indicate their liveliness within the lease duration. - -* Requested incompatible QoS - - The subscription has encountered a publisher on the same topic that is offering a QoS profile that does not satisfy the requested QoS profile, resulting in no connection between the subscription and that publisher. - -.. _about-qos_matched-events: - -Matched events --------------- - -In addition to QoS events, matched events can be generated when any publisher and subscription establishes or drops the connection between them. -Developers may provide each publisher and subscription with callback functions that are triggered by matched events and handle them in a way they see fit, similar to how messages received on a topic are handled. - -Developers can subscribe to this event with a publisher or a subscription. - -* publisher: this event happens when it finds a subscription which matches the topic and has compatible QoS or a connected subscription is disconnected -* subscription: this event happens when it finds a publisher which matches the topic and has compatible QoS or a connected publisher is disconnected - -There are demos showing how to use the event: - -* rclcpp: `demo code `__ -* rclpy: `demo code `__ +.. redirect-from:: + + About-Quality-of-Service-Settings + Concepts/About-Quality-of-Service-Settings + Concepts/Intermediate/About-Quality-of-Service-Settings + +Quality of Service settings +=========================== + +.. contents:: Table of Contents + :local: + +Overview +-------- + +ROS 2 offers a rich variety of Quality of Service (QoS) policies that allow you to tune communication between nodes. +With the right set of Quality of Service policies, ROS 2 can be as reliable as TCP or as best-effort as UDP, with many, many possible states in between. +Unlike ROS 1, which primarily only supported TCP, ROS 2 benefits from the flexibility of the underlying DDS transport in environments with lossy wireless networks where a "best effort" policy would be more suitable, or in real-time computing systems where the right Quality of Service profile is needed to meet deadlines. + +A set of QoS "policies" combine to form a QoS "profile". +Given the complexity of choosing the correct QoS policies for a given scenario, ROS 2 provides a set of predefined QoS profiles for common use cases (e.g. sensor data). +At the same time, developers are given the flexibility to control specific policies of the QoS profiles. + +QoS profiles can be specified for publishers, subscriptions, service servers and clients. +A QoS profile can be applied independently to each instance of the aforementioned entities, but if different profiles are used, it is possible that they will be incompatible, preventing the delivery of messages. + +.. _about_qos_policies: + +QoS policies +------------ + +The base QoS profile currently includes settings for the following policies: + +* History + + * *Keep last*: only store up to N samples, configurable via the queue depth option. + * *Keep all*: store all samples, subject to the configured resource limits of the underlying middleware. + +* Depth + + * *Queue size*: only honored if the "history" policy was set to "keep last". + +* Reliability + + * *Best effort*: attempt to deliver samples, but may lose them if the network is not robust. + * *Reliable*: guarantee that samples are delivered, may retry multiple times. + +* Durability + + * *Transient local*: the publisher becomes responsible for persisting samples for "late-joining" subscriptions. + * *Volatile*: no attempt is made to persist samples. + +* Deadline + + * *Duration*: the expected maximum amount of time between subsequent messages being published to a topic + +* Lifespan + + * *Duration*: the maximum amount of time between the publishing and the reception of a message without the message being considered stale or expired (expired messages are silently dropped and are effectively never received). + +* Liveliness + + * *Automatic*: the system will consider all of the node's publishers to be alive for another "lease duration" when any one of its publishers has published a message. + * *Manual by topic*: the system will consider the publisher to be alive for another "lease duration" if it manually asserts that it is still alive (via a call to the publisher API). + +* Lease Duration + + * *Duration*: the maximum period of time a publisher has to indicate that it is alive before the system considers it to have lost liveliness (losing liveliness could be an indication of a failure). + +For each of the policies that is not a duration, there is also the option of "system default", which uses the default of the underlying middleware. +For each of the policies that is a duration, there also exists a "default" option that means the duration is unspecified, which the underlying middleware will usually interpret as an infinitely long duration. + +Comparison to ROS 1 +^^^^^^^^^^^^^^^^^^^ + +The "history" and "depth" policies in ROS 2 combine to provide functionality akin to the queue size in ROS 1. + +The "reliability" policy in ROS 2 is akin to the use of either UDPROS (only in ``roscpp``) for "best effort", or TCPROS (ROS 1 default) for "reliable". +Note however that even the reliable policy in ROS 2 is implemented using UDP, which allows for multicasting if appropriate. + +The "durability" policy "transient local", combined with any depth, provides functionality similar to that of "latching" publishers. +The remaining policies in ROS 2 are not akin to anything that is available in ROS 1, meaning that ROS 2 is more featureful than ROS 1 in this respect. +It is possible that in the future, even more QoS policies will be available in ROS 2. + + +QoS profiles +------------ + +Profiles allow developers to focus on their applications without worrying about every QoS setting possible. +A QoS profile defines a set of policies that are expected to go well together for a particular use case. + +The currently defined QoS profiles are: + +* Default QoS settings for publishers and subscriptions + + In order to make the transition from ROS 1 to ROS 2 easier, exercising a similar network behavior is desirable. + By default, publishers and subscriptions in ROS 2 have "keep last" for history with a queue size of 10, "reliable" for reliability, "volatile" for durability, and "system default" for liveliness. + Deadline, lifespan, and lease durations are also all set to "default". + +* Services + + In the same vein as publishers and subscriptions, services are reliable. + It is especially important for services to use volatile durability, as otherwise service servers that re-start may receive outdated requests. + While the client is protected from receiving multiple responses, the server is not protected from side-effects of receiving the outdated requests. + +* Sensor data + + For sensor data, in most cases it's more important to receive readings in a timely fashion, rather than ensuring that all of them arrive. + That is, developers want the latest samples as soon as they are captured, at the expense of maybe losing some. + For that reason the sensor data profile uses best effort reliability and a smaller queue size. + +* Parameters + + Parameters in ROS 2 are based on services, and as such have a similar profile. + The difference is that parameters use a much larger queue depth so that requests do not get lost when, for example, the parameter client is unable to reach the parameter service server. + +* System default + + This uses the RMW implementation's default values for all of the policies. + Different RMW implementations may have different defaults. + +`Click here `__ for the specific policies in use for the above profiles. +The settings in these profiles are subject to further tweaks, based on the feedback from the community. + +.. _about-qos_compatibilities: + +QoS compatibilities +------------------- + +**Note:** This section refers to publishers and subscriptions but the content applies to service servers and clients in the same manner. + +QoS profiles may be configured for publishers and subscriptions independently. +A connection between a publisher and a subscription is only made if the pair has compatible QoS profiles. + +QoS profile compatibility is determined based on a "Request vs Offered" model. +Subscriptions *request* a QoS profile that is the "minimum quality" that it is willing to accept, and publishers *offer* a QoS profile that is the "maximum quality" that it is able to provide. +Connections are only made if every policy of the requested QoS profile is not more stringent than that of the offered QoS profile. +Multiple subscriptions can be connected to a single publisher simultaneously even if their requested QoS profiles are different. +The compatibility between a publisher and a subscription is unaffected by the presence of other publishers and subscriptions. + +The following tables show the compatibility of the different policy settings and the result: + +*Compatibility of reliability QoS policies:* + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Compatible + * - Best effort + - Best effort + - Yes + * - Best effort + - Reliable + - No + * - Reliable + - Best effort + - Yes + * - Reliable + - Reliable + - Yes + +*Compatibility of durability QoS policies:* + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Compatible + - Result + * - Volatile + - Volatile + - Yes + - New messages only + * - Volatile + - Transient local + - No + - No communication + * - Transient local + - Volatile + - Yes + - New messages only + * - Transient local + - Transient local + - Yes + - New and old messages + +To achieve a "latched" topic that is visible to late subscribers, +both the publisher and subscriber must agree to use 'Transient Local'. + +*Compatibility of deadline QoS policies:* + + Assume *x* and *y* are arbitrary valid duration values. + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Compatible + * - Default + - Default + - Yes + * - Default + - *x* + - No + * - *x* + - Default + - Yes + * - *x* + - *x* + - Yes + * - *x* + - *y* (where *y* > *x*) + - Yes + * - *x* + - *y* (where *y* < *x*) + - No + +*Compatibility of liveliness QoS policies:* + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Compatible + * - Automatic + - Automatic + - Yes + * - Automatic + - Manual by topic + - No + * - Manual by topic + - Automatic + - Yes + * - Manual by topic + - Manual by topic + - Yes + +*Compatibility of lease duration QoS policies:* + + Assume *x* and *y* are arbitrary valid duration values. + +.. list-table:: + :header-rows: 1 + + * - Publisher + - Subscription + - Compatible + * - Default + - Default + - Yes + * - Default + - *x* + - No + * - *x* + - Default + - Yes + * - *x* + - *x* + - Yes + * - *x* + - *y* (where *y* > *x*) + - Yes + * - *x* + - *y* (where *y* < *x*) + - No + +In order for a connection to be made, all of the policies that affect compatibility must be compatible. +For example, even if a requested and offered QoS profile pair has compatible reliability QoS policies, but they have incompatible durability QoS policies, a connection will still not be made. + +When connections are not made, no messages will be passed between the publisher and subscription. +There are mechanisms to detect this situation, which will be covered in a later section. + +Comparison to ROS 1 +^^^^^^^^^^^^^^^^^^^ + +Historically in ROS 1, any publisher and subscriber with the same message type on the same topic would be connected. +The possibility of incompatible requested and offered QoS profiles is something new to be aware of when using ROS 2. + +.. _about-qos_qos-events: + +QoS events +---------- + +Some QoS policies have possible events related to them. +Developers may provide each publisher and subscription with callback functions that are triggered by these QoS events and handle them in a way they see fit, similar to how messages received on a topic are handled. + +Developers may subscribe to the following QoS events that are associated with a publisher: + +* Offered deadline missed + + The publisher has not published a message within the expected duration that was set out by the deadline QoS policy. + +* Liveliness lost + + The publisher has failed to indicate its liveliness within the lease duration. + +* Offered incompatible QoS + + The publisher has encountered a subscription on the same topic that is requesting a QoS profile that the offered QoS profile cannot satisfy, resulting in no connection between the publisher and that subscription. + +Developers may subscribe to the following QoS events that are associated with a subscription: + +* Requested deadline missed + + The subscription has not received a message within the expected duration that was set out by the deadline QoS policy. + +* Liveliness changed + + The subscription has noticed that one or more publishers on the subscribed topic has failed to indicate their liveliness within the lease duration. + +* Requested incompatible QoS + + The subscription has encountered a publisher on the same topic that is offering a QoS profile that does not satisfy the requested QoS profile, resulting in no connection between the subscription and that publisher. + +.. _about-qos_matched-events: + +Matched events +-------------- + +In addition to QoS events, matched events can be generated when any publisher and subscription establishes or drops the connection between them. +Developers may provide each publisher and subscription with callback functions that are triggered by matched events and handle them in a way they see fit, similar to how messages received on a topic are handled. + +Developers can subscribe to this event with a publisher or a subscription. + +* publisher: this event happens when it finds a subscription which matches the topic and has compatible QoS or a connected subscription is disconnected +* subscription: this event happens when it finds a publisher which matches the topic and has compatible QoS or a connected publisher is disconnected + +There are demos showing how to use the event: + +* rclcpp: `demo code `__ +* rclpy: `demo code `__ \ No newline at end of file diff --git a/source/ROS-Framework/topics/About-Topic-Statistics.rst b/source/ROS-Framework/topics/About-Topic-Statistics.rst index 369a684cc02..95630a44dbb 100644 --- a/source/ROS-Framework/topics/About-Topic-Statistics.rst +++ b/source/ROS-Framework/topics/About-Topic-Statistics.rst @@ -1,71 +1,72 @@ -.. redirect-from:: - - About-Topic-Statistics - Concepts/About-Topic-Statistics - -Topic statistics -================ - -.. contents:: Table of Contents - :local: - -Overview --------- - -ROS 2 provides integrated measurement of statistics for messages received by any subscription. -Allowing a user to collect subscription statistics enables them to characterize the performance of their system or aid in diagnosis of any present issues. - -The measurements provided are the received message age and received message period. -For each measurement the statistics provided are the average, maximum, minimum, standard deviation, and sample count. -These statistics are calculated in a moving window. - -How statistics are calculated ------------------------------ - -Each statistic set is calculated in constant time and constant memory by using the utilities implemented in the `libstatistics_collector `__ package. -When a new message is received by a subscription, this is a new sample for calculation in the current measurement window. -The average calculated is simply a `moving average `__. -The maximum, minimum, and sample count are updated upon receipt of each new sample, whereas the standard deviation is calculated using `Welford's online algorithm `__. - -Types of statistics calculated ------------------------------- - -* Received message period - - * Units: milliseconds - * Uses the system clock to measure the period between received messages - -* Received message age - - * Units: milliseconds - * Requires a message to have a timestamp populated in the header field in order to calculate the age of the message as sent from a publisher - -Behavior --------- - -By default, Topic Statistics measurements are not enabled. -After enabling this feature for a specific node via the subscription configuration options, both received message age and received message period measurements are enabled for that specific subscription. - -The data is published as a `statistics_msg/msg/MetricsMessage -`__ at a configurable period (default 1 second) to a configurable topic (default ``/statistics``). -Note that the publishing period also serves as the sample collection window period. - -Since received message period requires a message timestamp in a header field, empty data is published. -That is, all statistics values are NaN if no timestamp is found. -Publishing NaN values instead of not publishing at all avoids the absence of a signal problem and is meant to explicitly show that a measurement could not be made. - -The first sample of each window for the received message period statistic does not yield a measurement. -This is because calculating this statistic requires knowing the time the previous message arrived, so subsequent samples in the window yield measurements. - -Comparison to ROS 1 -------------------- - -Similar to ROS 1 `Topic Statistics `__, both message age and message period are calculated, albeit from the subscription side. -Other ROS 1 metrics, e.g., the number of dropped messages or traffic volume, are currently not provided. - -Support -------- - -This feature is currently supported in ROS 2 Foxy for C++ only (rclcpp). -Future work and improvements, such as Python support, can be found -`here `__. +.. redirect-from:: + + About-Topic-Statistics + Concepts/About-Topic-Statistics + Concepts/Intermediate/About-Topic-Statistics + +Topic statistics +================ + +.. contents:: Table of Contents + :local: + +Overview +-------- + +ROS 2 provides integrated measurement of statistics for messages received by any subscription. +Allowing a user to collect subscription statistics enables them to characterize the performance of their system or aid in diagnosis of any present issues. + +The measurements provided are the received message age and received message period. +For each measurement the statistics provided are the average, maximum, minimum, standard deviation, and sample count. +These statistics are calculated in a moving window. + +How statistics are calculated +----------------------------- + +Each statistic set is calculated in constant time and constant memory by using the utilities implemented in the `libstatistics_collector `__ package. +When a new message is received by a subscription, this is a new sample for calculation in the current measurement window. +The average calculated is simply a `moving average `__. +The maximum, minimum, and sample count are updated upon receipt of each new sample, whereas the standard deviation is calculated using `Welford's online algorithm `__. + +Types of statistics calculated +------------------------------ + +* Received message period + + * Units: milliseconds + * Uses the system clock to measure the period between received messages + +* Received message age + + * Units: milliseconds + * Requires a message to have a timestamp populated in the header field in order to calculate the age of the message as sent from a publisher + +Behavior +-------- + +By default, Topic Statistics measurements are not enabled. +After enabling this feature for a specific node via the subscription configuration options, both received message age and received message period measurements are enabled for that specific subscription. + +The data is published as a `statistics_msg/msg/MetricsMessage +`__ at a configurable period (default 1 second) to a configurable topic (default ``/statistics``). +Note that the publishing period also serves as the sample collection window period. + +Since received message period requires a message timestamp in a header field, empty data is published. +That is, all statistics values are NaN if no timestamp is found. +Publishing NaN values instead of not publishing at all avoids the absence of a signal problem and is meant to explicitly show that a measurement could not be made. + +The first sample of each window for the received message period statistic does not yield a measurement. +This is because calculating this statistic requires knowing the time the previous message arrived, so subsequent samples in the window yield measurements. + +Comparison to ROS 1 +------------------- + +Similar to ROS 1 `Topic Statistics `__, both message age and message period are calculated, albeit from the subscription side. +Other ROS 1 metrics, e.g., the number of dropped messages or traffic volume, are currently not provided. + +Support +------- + +This feature is currently supported in ROS 2 Foxy for C++ only (rclcpp). +Future work and improvements, such as Python support, can be found +`here `__. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst b/source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst index 6518c802d99..0539313ca1f 100644 --- a/source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst +++ b/source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst @@ -1,549 +1,550 @@ -.. redirect-from:: - - Tutorials/Topics/Understanding-ROS2-Topics - -.. _ROS2Topics: - -Understanding topics -==================== - -**Goal:** Use rqt_graph and command line tools to introspect ROS 2 topics. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -ROS 2 breaks complex systems down into many modular nodes. -Topics are a vital element of the ROS graph that act as a bus for nodes to exchange messages. - -.. image:: images/Topic-SinglePublisherandSingleSubscriber.gif - -A node may publish data to any number of topics and simultaneously have subscriptions to any number of topics. - -.. image:: images/Topic-MultiplePublisherandMultipleSubscriber.gif - -Topics are one of the main ways in which data is moved between nodes and therefore between different parts of the system. - - -Prerequisites -------------- - -The :doc:`previous tutorial <../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` provides some useful background information on nodes that is built upon here. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ - -By now you should be comfortable starting up turtlesim. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Recall from the :doc:`previous tutorial <../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that the names of these nodes are ``/turtlesim`` and ``/teleop_turtle`` by default. - - -2 rqt_graph -^^^^^^^^^^^ - -Throughout this tutorial, we will use ``rqt_graph`` to visualize the changing nodes and topics, as well as the connections between them. - -The :doc:`turtlesim tutorial <../Introducing-Turtlesim/Introducing-Turtlesim>` tells you how to install rqt and all its plugins, including ``rqt_graph``. - -To run rqt_graph, open a new terminal and enter the command: - -.. code-block:: console - - $ ros2 run rqt_graph rqt_graph - -You can also open rqt_graph by opening ``rqt`` and selecting **Plugins** > **Introspection** > **Node Graph**. - -.. image:: images/rqt_graph.png - -You should see the above nodes and topic, as well as two actions around the periphery of the graph (let's ignore those for now). -If you hover your mouse over the topic in the center, you'll see the color highlighting like in the image above. - -The graph is depicting how the ``/turtlesim`` node and the ``/teleop_turtle`` node are communicating with each other over a topic. -The ``/teleop_turtle`` node is publishing data (the keystrokes you enter to move the turtle around) to the ``/turtle1/cmd_vel`` topic, and the ``/turtlesim`` node is subscribed to that topic to receive the data. - -The highlighting feature of rqt_graph is very helpful when examining more complex systems with many nodes and topics connected in many different ways. - -rqt_graph is a graphical introspection tool. -Now we'll look at some command line tools for introspecting topics. - - -3 ros2 topic list -^^^^^^^^^^^^^^^^^ - -Running the ``ros2 topic list`` command in a new terminal will return a list of all the topics currently active in the system: - -.. code-block:: console - - $ ros2 topic list - /parameter_events - /rosout - /turtle1/cmd_vel - /turtle1/color_sensor - /turtle1/pose - -``ros2 topic list -t`` will return the same list of topics, this time with the topic type appended in brackets: - -.. code-block:: console - - $ ros2 topic list -t - /parameter_events [rcl_interfaces/msg/ParameterEvent] - /rosout [rcl_interfaces/msg/Log] - /turtle1/cmd_vel [geometry_msgs/msg/Twist] - /turtle1/color_sensor [turtlesim_msgs/msg/Color] - /turtle1/pose [turtlesim_msgs/msg/Pose] - -These attributes, particularly the type, are how nodes know they're talking about the same information as it moves over topics. - -If you're wondering where all these topics are in rqt_graph, you can uncheck all the boxes under **Hide:** - -.. image:: images/unhide.png - -For now, though, leave those options checked to avoid confusion. - -4 ros2 topic echo -^^^^^^^^^^^^^^^^^ - -To see the data being published on a topic, use: - -.. code-block:: console - - $ ros2 topic echo - -Since we know that ``/teleop_turtle`` publishes data to ``/turtlesim`` over the ``/turtle1/cmd_vel`` topic, let's use ``echo`` to introspect that topic: - -.. code-block:: console - - $ ros2 topic echo /turtle1/cmd_vel - -At first, this command won't return any data. -That's because it's waiting for ``/teleop_turtle`` to publish something. - -Return to the terminal where ``turtle_teleop_key`` is running and use the arrows to move the turtle around. -Watch the terminal where your ``echo`` is running at the same time, and you'll see position data being published for every movement you make: - -.. code-block:: console - - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -Now return to rqt_graph and uncheck the **Debug** box. - -.. image:: images/debug.png - -``/_ros2cli_26646`` is the node created by the ``echo`` command we just ran (the number might be different). -Now you can see that the publisher is publishing data over the ``cmd_vel`` topic, and two subscribers are subscribed to it. - -5 ros2 topic info -^^^^^^^^^^^^^^^^^ - -Topics don't have to only be one-to-one communication; they can be one-to-many, many-to-one, or many-to-many. - -Another way to look at this is running: - -.. code-block:: console - - $ ros2 topic info /turtle1/cmd_vel - Type: geometry_msgs/msg/Twist - Publisher count: 1 - Subscription count: 2 - -5.1 ros2 topic info --verbose -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For more detailed information about a topic, you can use the ``--verbose`` (or ``-v``) flag: - -.. code-block:: console - - $ ros2 topic info /turtle1/cmd_vel --verbose - -This will return additional details including: - -- Node names and namespaces of publishers and subscribers -- Topic type -- QoS profiles - -.. code-block:: console - - Type: geometry_msgs/msg/Twist - - Publisher count: 1 - - Node name: teleop_turtle - Node namespace: / - Topic type: geometry_msgs/msg/Twist - Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a - Endpoint type: PUBLISHER - GID: 24.ba.3e.e7.c1.51.bb.46.21.41.de.36.1b.14.73.5e - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (7) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Subscription count: 2 - - Node name: _ros2cli_300492 - Node namespace: / - Topic type: geometry_msgs/msg/Twist - Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a - Endpoint type: SUBSCRIPTION - GID: cc.4d.98.79.29.91.fe.25.8a.0a.c9.03.db.1a.ec.81 - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (5) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Node name: turtlesim - Node namespace: / - Topic type: geometry_msgs/msg/Twist - Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a - Endpoint type: SUBSCRIPTION - GID: 9c.33.59.38.b2.f2.42.47.69.1b.7f.0e.5e.1d.86.f5 - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (7) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -6 ros2 interface show -^^^^^^^^^^^^^^^^^^^^^ - -Nodes send data over topics using messages. -Publishers and subscribers must send and receive the same type of message to communicate. - -The topic types we saw earlier after running ``ros2 topic list -t`` let us know what message type is used on each topic. -Recall that the ``cmd_vel`` topic has the type: - -.. code-block:: console - - geometry_msgs/msg/Twist - -This means that in the package ``geometry_msgs`` there is a ``msg`` called ``Twist``. - -Now we can run ``ros2 interface show `` on this type to learn its details. -Specifically, what structure of data the message expects. - -.. code-block:: console - - $ ros2 interface show geometry_msgs/msg/Twist - -Which will return: - -.. code-block:: text - - # This expresses velocity in free space broken into its linear and angular parts. - Vector3 linear - float64 x - float64 y - float64 z - Vector3 angular - float64 x - float64 y - float64 z - -This tells you that the ``/turtlesim`` node is expecting a message with two vectors, ``linear`` and ``angular``, of three elements each. -If you recall the data we saw ``/teleop_turtle`` passing to ``/turtlesim`` with the ``echo`` command, it's in the same structure: - -.. code-block:: console - - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -7 ros2 topic pub -^^^^^^^^^^^^^^^^ - -Now that you have the message structure, you can publish data to a topic directly from the command line using: - -.. code-block:: console - - $ ros2 topic pub '' - -The ``''`` argument is the actual data you'll pass to the topic, in the structure you just discovered in the previous section. - -There are four main ways to use the ``pub`` command as shown below. -However, the autocomplete feature described in ``c.`` and ``d.`` is not supported in Windows. - -a. **Publishing dictionary strings**: - - In order to publish data to a topic, you need to pass the data in the form of YAML strings. - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - - However, you do not need to specify the entire message, if you are just changing the linear or angular velocity, you can just specify the values you want to change. - - For example, if you want to change the linear velocity to 2.0 and keep the angular velocity at 1.8, you can do the following: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0}, angular: {z: 1.8}}" - -b. **Publishing an empty message**: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist - - This will publish the default values for the message type at 1 Hz. - In this case, this equivalent to the following command: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}" --rate 1 - -c. **Using autocomplete**: - - You can trigger the autocomplete feature of your terminal by the following: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist - --keep-alive - --max-wait-time-secs - --node-name - --once - --print - --qos-depth - --qos-durability - --qos-history - --qos-liveliness - --qos-liveliness-lease-duration-seconds - --qos-profile - --qos-reliability - --rate - --spin-time - --stdin - --times - --use-sim-time - --wait-matching-subscriptions - --yaml-file - -1 - -n - -p - -r - -s - -t - -w - \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' - - All the options will be autocompleted by pressing the :kbd:`tab` key after the entering the first few characters of the option. - However, the topic message prototype will only be autocompleted after ``\'`` is entered. - - This is because the terminal does not recognize the single quote as part of the autocomplete string. - Hence it needs to be escaped by using ``\'`` to be recognized as part of the string. - - The final autocompleted string will look like this: - - .. code-block:: bash - - ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist 'linear: - x: 0.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - ' - - This string is editable and you can change the values of the message type as required. - -d. **Using the raw autocompleted string**: - - As mentioned above, the autocompleted string for ``geometry_msgs/msg/Twist`` looks like this: - - .. code-block:: console - - \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' - - This can be directly used in place of the yaml string in the command line. - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' - - -The turtle (and commonly the real robots which it is meant to emulate) require a steady stream of commands to operate continuously. -So, to get the turtle moving, and keep it moving, you can use the following dictionary string: - -.. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - -.. image:: images/pub_stream.png - -At times you may want to publish data to your topic only once (rather than continuously). -To publish your command just once add the ``--once`` option. - -.. code-block:: console - - $ ros2 topic pub --once -w 2 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - -``--once`` is an optional argument meaning "publish one message then exit". - -``-w 2`` is an optional argument meaning "wait for two matching subscriptions". -This is needed because we have both turtlesim and the topic echo subscribed. - -You will see the following output in the terminal: - -.. code-block:: console - - Waiting for at least 2 matching subscription(s)... - publisher: beginning loop - publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=1.8)) - -And you will see your turtle move like so: - -.. image:: images/pub_once.png - - -You can refresh rqt_graph to see what's happening graphically. -You will see that the ``ros2 topic pub ...`` node (``/_ros2cli_30358``) is publishing over the ``/turtle1/cmd_vel`` topic, which is being received by both the ``ros2 topic echo ...`` node (``/_ros2cli_26646``) and the ``/turtlesim`` node now. - -.. image:: images/rqt_graph2.png - -Finally, you can run ``echo`` on the ``pose`` topic and recheck rqt_graph: - -.. code-block:: console - - $ ros2 topic echo /turtle1/pose - -.. image:: images/rqt_graph3.png - -You can see that the ``/turtlesim`` node is also publishing to the ``pose`` topic, which the new ``echo`` node has subscribed to. - -When publishing messages with timestamps, ``pub`` has two methods to automatically fill them out with the current time. -For messages with a ``std_msgs/msg/Header``, the header field can be set to ``auto`` to fill out the ``stamp`` field. - -.. code-block:: console - - $ ros2 topic pub /pose geometry_msgs/msg/PoseStamped '{header: "auto", pose: {position: {x: 1.0, y: 2.0, z: 3.0}}}' - -If the message does not use a full header, but just has a field with type ``builtin_interfaces/msg/Time``, that can be set to the value ``now``. - -.. code-block:: console - - $ ros2 topic pub /reference sensor_msgs/msg/TimeReference '{header: "auto", time_ref: "now", source: "dumy"}' - -8 ros2 topic hz -^^^^^^^^^^^^^^^ - -You can also view the rate at which data is published using: - -.. code-block:: console - - $ ros2 topic hz /turtle1/pose - average rate: 59.354 - min: 0.005s max: 0.027s std dev: 0.00284s window: 58 - -It will return data on the rate at which the ``/turtlesim`` node is publishing data to the ``pose`` topic. - -Recall that you set the rate of ``turtle1/cmd_vel`` to publish at a steady 1 Hz using ``ros2 topic pub --rate 1``. -If you run the above command with ``turtle1/cmd_vel`` instead of ``turtle1/pose``, you will see an average reflecting that rate. - -.. Note:: The rate reflects the receiving rate on the subscription created by the ``ros2 topic hz`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher rate. - -9 ros2 topic bw -^^^^^^^^^^^^^^^ - -The bandwidth used by a topic can be viewed using: - -.. code-block:: console - - $ ros2 topic bw /turtle1/pose - Subscribed to [/turtle1/pose] - 1.51 KB/s from 62 messages - Message size mean: 0.02 KB min: 0.02 KB max: 0.02 KB - -It returns the bandwidth utilization and number of messages being published to the ``/turtle1/pose`` topic. - -.. Note:: The bandwidth reflects the receiving rate on the subscription created by the ``ros2 topic bw`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher's bandwidth. - -10 ros2 topic find -^^^^^^^^^^^^^^^^^^ - -To list a list of available topics of a given type use: - -.. code-block:: console - - $ ros2 topic find - -Recall that the ``cmd_vel`` topic has the type: - -.. code-block:: console - - geometry_msgs/msg/Twist - -Using the ``find`` command outputs topics available when given the message type: - -.. code-block:: console - - $ ros2 topic find geometry_msgs/msg/Twist - /turtle1/cmd_vel - -11 Clean up -^^^^^^^^^^^ - -At this point you'll have a lot of nodes running. -Don't forget to stop them by entering ``Ctrl+C`` in each terminal. - -Summary -------- - -Nodes publish information over topics, which allows any number of other nodes to subscribe to and access that information. -In this tutorial you examined the connections between several nodes over topics using rqt_graph and command line tools. -You should now have a good idea of how data moves around a ROS 2 system. - -Next steps ----------- - -Next you'll learn about another communication type in the ROS graph with the tutorial :doc:`../Understanding-ROS2-Services/Understanding-ROS2-Services`. +.. redirect-from:: + + Tutorials/Topics/Understanding-ROS2-Topics + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics + +.. _ROS2Topics: + +Understanding topics +==================== + +**Goal:** Use rqt_graph and command line tools to introspect ROS 2 topics. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +ROS 2 breaks complex systems down into many modular nodes. +Topics are a vital element of the ROS graph that act as a bus for nodes to exchange messages. + +.. image:: images/Topic-SinglePublisherandSingleSubscriber.gif + +A node may publish data to any number of topics and simultaneously have subscriptions to any number of topics. + +.. image:: images/Topic-MultiplePublisherandMultipleSubscriber.gif + +Topics are one of the main ways in which data is moved between nodes and therefore between different parts of the system. + + +Prerequisites +------------- + +The :doc:`previous tutorial <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` provides some useful background information on nodes that is built upon here. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ + +By now you should be comfortable starting up turtlesim. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Recall from the :doc:`previous tutorial <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that the names of these nodes are ``/turtlesim`` and ``/teleop_turtle`` by default. + + +2 rqt_graph +^^^^^^^^^^^ + +Throughout this tutorial, we will use ``rqt_graph`` to visualize the changing nodes and topics, as well as the connections between them. + +The :doc:`turtlesim tutorial <../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` tells you how to install rqt and all its plugins, including ``rqt_graph``. + +To run rqt_graph, open a new terminal and enter the command: + +.. code-block:: console + + $ ros2 run rqt_graph rqt_graph + +You can also open rqt_graph by opening ``rqt`` and selecting **Plugins** > **Introspection** > **Node Graph**. + +.. image:: images/rqt_graph.png + +You should see the above nodes and topic, as well as two actions around the periphery of the graph (let's ignore those for now). +If you hover your mouse over the topic in the center, you'll see the color highlighting like in the image above. + +The graph is depicting how the ``/turtlesim`` node and the ``/teleop_turtle`` node are communicating with each other over a topic. +The ``/teleop_turtle`` node is publishing data (the keystrokes you enter to move the turtle around) to the ``/turtle1/cmd_vel`` topic, and the ``/turtlesim`` node is subscribed to that topic to receive the data. + +The highlighting feature of rqt_graph is very helpful when examining more complex systems with many nodes and topics connected in many different ways. + +rqt_graph is a graphical introspection tool. +Now we'll look at some command line tools for introspecting topics. + + +3 ros2 topic list +^^^^^^^^^^^^^^^^^ + +Running the ``ros2 topic list`` command in a new terminal will return a list of all the topics currently active in the system: + +.. code-block:: console + + $ ros2 topic list + /parameter_events + /rosout + /turtle1/cmd_vel + /turtle1/color_sensor + /turtle1/pose + +``ros2 topic list -t`` will return the same list of topics, this time with the topic type appended in brackets: + +.. code-block:: console + + $ ros2 topic list -t + /parameter_events [rcl_interfaces/msg/ParameterEvent] + /rosout [rcl_interfaces/msg/Log] + /turtle1/cmd_vel [geometry_msgs/msg/Twist] + /turtle1/color_sensor [turtlesim_msgs/msg/Color] + /turtle1/pose [turtlesim_msgs/msg/Pose] + +These attributes, particularly the type, are how nodes know they're talking about the same information as it moves over topics. + +If you're wondering where all these topics are in rqt_graph, you can uncheck all the boxes under **Hide:** + +.. image:: images/unhide.png + +For now, though, leave those options checked to avoid confusion. + +4 ros2 topic echo +^^^^^^^^^^^^^^^^^ + +To see the data being published on a topic, use: + +.. code-block:: console + + $ ros2 topic echo + +Since we know that ``/teleop_turtle`` publishes data to ``/turtlesim`` over the ``/turtle1/cmd_vel`` topic, let's use ``echo`` to introspect that topic: + +.. code-block:: console + + $ ros2 topic echo /turtle1/cmd_vel + +At first, this command won't return any data. +That's because it's waiting for ``/teleop_turtle`` to publish something. + +Return to the terminal where ``turtle_teleop_key`` is running and use the arrows to move the turtle around. +Watch the terminal where your ``echo`` is running at the same time, and you'll see position data being published for every movement you make: + +.. code-block:: console + + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +Now return to rqt_graph and uncheck the **Debug** box. + +.. image:: images/debug.png + +``/_ros2cli_26646`` is the node created by the ``echo`` command we just ran (the number might be different). +Now you can see that the publisher is publishing data over the ``cmd_vel`` topic, and two subscribers are subscribed to it. + +5 ros2 topic info +^^^^^^^^^^^^^^^^^ + +Topics don't have to only be one-to-one communication; they can be one-to-many, many-to-one, or many-to-many. + +Another way to look at this is running: + +.. code-block:: console + + $ ros2 topic info /turtle1/cmd_vel + Type: geometry_msgs/msg/Twist + Publisher count: 1 + Subscription count: 2 + +5.1 ros2 topic info --verbose +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For more detailed information about a topic, you can use the ``--verbose`` (or ``-v``) flag: + +.. code-block:: console + + $ ros2 topic info /turtle1/cmd_vel --verbose + +This will return additional details including: + +- Node names and namespaces of publishers and subscribers +- Topic type +- QoS profiles + +.. code-block:: console + + Type: geometry_msgs/msg/Twist + + Publisher count: 1 + + Node name: teleop_turtle + Node namespace: / + Topic type: geometry_msgs/msg/Twist + Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a + Endpoint type: PUBLISHER + GID: 24.ba.3e.e7.c1.51.bb.46.21.41.de.36.1b.14.73.5e + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (7) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + + Subscription count: 2 + + Node name: _ros2cli_300492 + Node namespace: / + Topic type: geometry_msgs/msg/Twist + Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a + Endpoint type: SUBSCRIPTION + GID: cc.4d.98.79.29.91.fe.25.8a.0a.c9.03.db.1a.ec.81 + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (5) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + + Node name: turtlesim + Node namespace: / + Topic type: geometry_msgs/msg/Twist + Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a + Endpoint type: SUBSCRIPTION + GID: 9c.33.59.38.b2.f2.42.47.69.1b.7f.0e.5e.1d.86.f5 + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (7) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +6 ros2 interface show +^^^^^^^^^^^^^^^^^^^^^ + +Nodes send data over topics using messages. +Publishers and subscribers must send and receive the same type of message to communicate. + +The topic types we saw earlier after running ``ros2 topic list -t`` let us know what message type is used on each topic. +Recall that the ``cmd_vel`` topic has the type: + +.. code-block:: console + + geometry_msgs/msg/Twist + +This means that in the package ``geometry_msgs`` there is a ``msg`` called ``Twist``. + +Now we can run ``ros2 interface show `` on this type to learn its details. +Specifically, what structure of data the message expects. + +.. code-block:: console + + $ ros2 interface show geometry_msgs/msg/Twist + +Which will return: + +.. code-block:: text + + # This expresses velocity in free space broken into its linear and angular parts. + Vector3 linear + float64 x + float64 y + float64 z + Vector3 angular + float64 x + float64 y + float64 z + +This tells you that the ``/turtlesim`` node is expecting a message with two vectors, ``linear`` and ``angular``, of three elements each. +If you recall the data we saw ``/teleop_turtle`` passing to ``/turtlesim`` with the ``echo`` command, it's in the same structure: + +.. code-block:: console + + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +7 ros2 topic pub +^^^^^^^^^^^^^^^^ + +Now that you have the message structure, you can publish data to a topic directly from the command line using: + +.. code-block:: console + + $ ros2 topic pub '' + +The ``''`` argument is the actual data you'll pass to the topic, in the structure you just discovered in the previous section. + +There are four main ways to use the ``pub`` command as shown below. +However, the autocomplete feature described in ``c.`` and ``d.`` is not supported in Windows. + +a. **Publishing dictionary strings**: + + In order to publish data to a topic, you need to pass the data in the form of YAML strings. + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + + However, you do not need to specify the entire message, if you are just changing the linear or angular velocity, you can just specify the values you want to change. + + For example, if you want to change the linear velocity to 2.0 and keep the angular velocity at 1.8, you can do the following: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0}, angular: {z: 1.8}}" + +b. **Publishing an empty message**: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist + + This will publish the default values for the message type at 1 Hz. + In this case, this equivalent to the following command: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}" --rate 1 + +c. **Using autocomplete**: + + You can trigger the autocomplete feature of your terminal by the following: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist + --keep-alive + --max-wait-time-secs + --node-name + --once + --print + --qos-depth + --qos-durability + --qos-history + --qos-liveliness + --qos-liveliness-lease-duration-seconds + --qos-profile + --qos-reliability + --rate + --spin-time + --stdin + --times + --use-sim-time + --wait-matching-subscriptions + --yaml-file + -1 + -n + -p + -r + -s + -t + -w + \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' + + All the options will be autocompleted by pressing the :kbd:`tab` key after the entering the first few characters of the option. + However, the topic message prototype will only be autocompleted after ``\'`` is entered. + + This is because the terminal does not recognize the single quote as part of the autocomplete string. + Hence it needs to be escaped by using ``\'`` to be recognized as part of the string. + + The final autocompleted string will look like this: + + .. code-block:: bash + + ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist 'linear: + x: 0.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + ' + + This string is editable and you can change the values of the message type as required. + +d. **Using the raw autocompleted string**: + + As mentioned above, the autocompleted string for ``geometry_msgs/msg/Twist`` looks like this: + + .. code-block:: console + + \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' + + This can be directly used in place of the yaml string in the command line. + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' + + +The turtle (and commonly the real robots which it is meant to emulate) require a steady stream of commands to operate continuously. +So, to get the turtle moving, and keep it moving, you can use the following dictionary string: + +.. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + +.. image:: images/pub_stream.png + +At times you may want to publish data to your topic only once (rather than continuously). +To publish your command just once add the ``--once`` option. + +.. code-block:: console + + $ ros2 topic pub --once -w 2 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + +``--once`` is an optional argument meaning "publish one message then exit". + +``-w 2`` is an optional argument meaning "wait for two matching subscriptions". +This is needed because we have both turtlesim and the topic echo subscribed. + +You will see the following output in the terminal: + +.. code-block:: console + + Waiting for at least 2 matching subscription(s)... + publisher: beginning loop + publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=1.8)) + +And you will see your turtle move like so: + +.. image:: images/pub_once.png + + +You can refresh rqt_graph to see what's happening graphically. +You will see that the ``ros2 topic pub ...`` node (``/_ros2cli_30358``) is publishing over the ``/turtle1/cmd_vel`` topic, which is being received by both the ``ros2 topic echo ...`` node (``/_ros2cli_26646``) and the ``/turtlesim`` node now. + +.. image:: images/rqt_graph2.png + +Finally, you can run ``echo`` on the ``pose`` topic and recheck rqt_graph: + +.. code-block:: console + + $ ros2 topic echo /turtle1/pose + +.. image:: images/rqt_graph3.png + +You can see that the ``/turtlesim`` node is also publishing to the ``pose`` topic, which the new ``echo`` node has subscribed to. + +When publishing messages with timestamps, ``pub`` has two methods to automatically fill them out with the current time. +For messages with a ``std_msgs/msg/Header``, the header field can be set to ``auto`` to fill out the ``stamp`` field. + +.. code-block:: console + + $ ros2 topic pub /pose geometry_msgs/msg/PoseStamped '{header: "auto", pose: {position: {x: 1.0, y: 2.0, z: 3.0}}}' + +If the message does not use a full header, but just has a field with type ``builtin_interfaces/msg/Time``, that can be set to the value ``now``. + +.. code-block:: console + + $ ros2 topic pub /reference sensor_msgs/msg/TimeReference '{header: "auto", time_ref: "now", source: "dumy"}' + +8 ros2 topic hz +^^^^^^^^^^^^^^^ + +You can also view the rate at which data is published using: + +.. code-block:: console + + $ ros2 topic hz /turtle1/pose + average rate: 59.354 + min: 0.005s max: 0.027s std dev: 0.00284s window: 58 + +It will return data on the rate at which the ``/turtlesim`` node is publishing data to the ``pose`` topic. + +Recall that you set the rate of ``turtle1/cmd_vel`` to publish at a steady 1 Hz using ``ros2 topic pub --rate 1``. +If you run the above command with ``turtle1/cmd_vel`` instead of ``turtle1/pose``, you will see an average reflecting that rate. + +.. Note:: The rate reflects the receiving rate on the subscription created by the ``ros2 topic hz`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher rate. + +9 ros2 topic bw +^^^^^^^^^^^^^^^ + +The bandwidth used by a topic can be viewed using: + +.. code-block:: console + + $ ros2 topic bw /turtle1/pose + Subscribed to [/turtle1/pose] + 1.51 KB/s from 62 messages + Message size mean: 0.02 KB min: 0.02 KB max: 0.02 KB + +It returns the bandwidth utilization and number of messages being published to the ``/turtle1/pose`` topic. + +.. Note:: The bandwidth reflects the receiving rate on the subscription created by the ``ros2 topic bw`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher's bandwidth. + +10 ros2 topic find +^^^^^^^^^^^^^^^^^^ + +To list a list of available topics of a given type use: + +.. code-block:: console + + $ ros2 topic find + +Recall that the ``cmd_vel`` topic has the type: + +.. code-block:: console + + geometry_msgs/msg/Twist + +Using the ``find`` command outputs topics available when given the message type: + +.. code-block:: console + + $ ros2 topic find geometry_msgs/msg/Twist + /turtle1/cmd_vel + +11 Clean up +^^^^^^^^^^^ + +At this point you'll have a lot of nodes running. +Don't forget to stop them by entering ``Ctrl+C`` in each terminal. + +Summary +------- + +Nodes publish information over topics, which allows any number of other nodes to subscribe to and access that information. +In this tutorial you examined the connections between several nodes over topics using rqt_graph and command line tools. +You should now have a good idea of how data moves around a ROS 2 system. + +Next steps +---------- + +Next you'll learn about another communication type in the ROS graph with the tutorial :doc:`../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services`. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst b/source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst index 33c8b50e684..b31a6a09151 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst +++ b/source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst @@ -1,311 +1,312 @@ -.. redirect-from:: - - Tutorials/Content-Filtering-Subscription - -Creating a content filtering subscription -========================================= - -**Goal:** Create a content filtering subscription. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 1 - :local: - -Overview --------- - -ROS 2 applications typically consist of topics to transmit data from publishers to subscriptions. -Basically, subscriptions receive all published data from publishers on the topic. -But sometimes, a subscription might be interested in only a subset of the data which is being sent by publishers. -A content filtering subscription allows to receive only the data of interest for the application. - -In this demo, we'll be highlighting how to create a content filtering subscription and how they work. - -RMW Support ------------ - -Content filtering subscriptions require RMW implementation support. - -.. list-table:: Content-Filtering-Subscription Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - * - rmw_zenoh_cpp - - not supported - -Currently all RMW implementations that support content filtering subscriptions are `DDS `__ based. -That means that the supported filtering expressions and parameters are also dependent on `DDS `__, you can refer to `DDS specification `__ ``Annex B - Syntax for Queries and Filters`` for details. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Temperature filtering demo --------------------------- - -This demo shows how a content filtering subscription can be used to only receive temperature values that are out of the acceptable temperature range, detecting emergencies. -The content filtering subscription filters out the uninteresting temperature data, so that the subscription callback is not issued. - -ContentFilteringPublisher: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_publisher.cpp - -.. code-block:: c++ - - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp_components/register_node_macro.hpp" - - #include "std_msgs/msg/float32.hpp" - - #include "demo_nodes_cpp/visibility_control.h" - - namespace demo_nodes_cpp - { - // The simulated temperature data starts from -100.0 and ends at 150.0 with a step size of 10.0 - constexpr std::array TEMPERATURE_SETTING {-100.0f, 150.0f, 10.0f}; - - // Create a ContentFilteringPublisher class that subclasses the generic rclcpp::Node base class. - // The main function below will instantiate the class as a ROS node. - class ContentFilteringPublisher final : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit ContentFilteringPublisher(const rclcpp::NodeOptions & options) - : Node("content_filtering_publisher", options) - { - // Create a function for when messages are to be sent. - auto publish_message = - [this]() -> void - { - msg_ = std::make_unique(); - msg_->data = temperature_; - temperature_ += TEMPERATURE_SETTING[2]; - if (temperature_ > TEMPERATURE_SETTING[1]) { - temperature_ = TEMPERATURE_SETTING[0]; - } - RCLCPP_INFO(this->get_logger(), "Publishing: '%f'", msg_->data); - // Put the message into a queue to be processed by the middleware. - // This call is non-blocking. - pub_->publish(std::move(msg_)); - }; - // Create a publisher with a custom Quality of Service profile. - // Uniform initialization is suggested so it can be trivially changed to - // rclcpp::KeepAll{} if the user wishes. - // (rclcpp::KeepLast(7) -> rclcpp::KeepAll() fails to compile) - rclcpp::QoS qos(rclcpp::KeepLast{7}); - pub_ = this->create_publisher("temperature", qos); - - int64_t publish_ms = this->declare_parameter("publish_ms", 1000); - - // Use a timer to schedule periodic message publishing. - timer_ = this->create_wall_timer(std::chrono::milliseconds(publish_ms), publish_message); - } - - private: - float temperature_ = TEMPERATURE_SETTING[0]; - std::unique_ptr msg_; - rclcpp::Publisher::SharedPtr pub_; - rclcpp::TimerBase::SharedPtr timer_; - }; - - } // namespace demo_nodes_cpp - -The content filter is defined in the subscription side, publishers don't need to be configured in any special way to allow content filtering. -The ``ContentFilteringPublisher`` node publishes simulated temperature data starting from -100.0 and ending at 150.0 with a step size of 10.0 every second. - -We can run the demo by running the ``ros2 run demo_nodes_cpp content_filtering_publisher`` executable (don't forget to source the setup file first): - -.. code-block:: console - - $ ros2 run demo_nodes_cpp content_filtering_publisher - [INFO] [1651094594.822753479] [content_filtering_publisher]: Publishing: '-100.000000' - [INFO] [1651094595.822723857] [content_filtering_publisher]: Publishing: '-90.000000' - [INFO] [1651094596.822752996] [content_filtering_publisher]: Publishing: '-80.000000' - [INFO] [1651094597.822752475] [content_filtering_publisher]: Publishing: '-70.000000' - [INFO] [1651094598.822721485] [content_filtering_publisher]: Publishing: '-60.000000' - [INFO] [1651094599.822696188] [content_filtering_publisher]: Publishing: '-50.000000' - [INFO] [1651094600.822699217] [content_filtering_publisher]: Publishing: '-40.000000' - [INFO] [1651094601.822744113] [content_filtering_publisher]: Publishing: '-30.000000' - [INFO] [1651094602.822694805] [content_filtering_publisher]: Publishing: '-20.000000' - [INFO] [1651094603.822735805] [content_filtering_publisher]: Publishing: '-10.000000' - [INFO] [1651094604.822722094] [content_filtering_publisher]: Publishing: '0.000000' - [INFO] [1651094605.822699960] [content_filtering_publisher]: Publishing: '10.000000' - [INFO] [1651094606.822748946] [content_filtering_publisher]: Publishing: '20.000000' - [INFO] [1651094607.822694017] [content_filtering_publisher]: Publishing: '30.000000' - [INFO] [1651094608.822708798] [content_filtering_publisher]: Publishing: '40.000000' - [INFO] [1651094609.822692417] [content_filtering_publisher]: Publishing: '50.000000' - [INFO] [1651094610.822696426] [content_filtering_publisher]: Publishing: '60.000000' - [INFO] [1651094611.822751913] [content_filtering_publisher]: Publishing: '70.000000' - [INFO] [1651094612.822692231] [content_filtering_publisher]: Publishing: '80.000000' - [INFO] [1651094613.822745549] [content_filtering_publisher]: Publishing: '90.000000' - [INFO] [1651094614.822701982] [content_filtering_publisher]: Publishing: '100.000000' - [INFO] [1651094615.822691465] [content_filtering_publisher]: Publishing: '110.000000' - [INFO] [1651094616.822649070] [content_filtering_publisher]: Publishing: '120.000000' - [INFO] [1651094617.822693616] [content_filtering_publisher]: Publishing: '130.000000' - [INFO] [1651094618.822691832] [content_filtering_publisher]: Publishing: '140.000000' - [INFO] [1651094619.822688452] [content_filtering_publisher]: Publishing: '150.000000' - [INFO] [1651094620.822645327] [content_filtering_publisher]: Publishing: '-100.000000' - [INFO] [1651094621.822689219] [content_filtering_publisher]: Publishing: '-90.000000' - [INFO] [1651094622.822694292] [content_filtering_publisher]: Publishing: '-80.000000' - [...] - -ContentFilteringSubscriber: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_subscriber.cpp - -.. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp_components/register_node_macro.hpp" - #include "rcpputils/join.hpp" - - #include "std_msgs/msg/float32.hpp" - - #include "demo_nodes_cpp/visibility_control.h" - - namespace demo_nodes_cpp - { - // Emergency temperature data less than -30 or greater than 100 - constexpr std::array EMERGENCY_TEMPERATURE {-30.0f, 100.0f}; - - // Create a ContentFilteringSubscriber class that subclasses the generic rclcpp::Node base class. - // The main function below will instantiate the class as a ROS node. - class ContentFilteringSubscriber : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit ContentFilteringSubscriber(const rclcpp::NodeOptions & options) - : Node("content_filtering_subscriber", options) - { - // Create a callback function for when messages are received. - auto callback = - [this](const std_msgs::msg::Float32 & msg) -> void - { - if (msg.data < EMERGENCY_TEMPERATURE[0] || msg.data > EMERGENCY_TEMPERATURE[1]) { - RCLCPP_INFO( - this->get_logger(), - "I receive an emergency temperature data: [%f]", msg.data); - } else { - RCLCPP_INFO(this->get_logger(), "I receive a temperature data: [%f]", msg.data); - } - }; - - // Initialize a subscription with a content filter to receive emergency temperature data that - // are less than -30 or greater than 100. - rclcpp::SubscriptionOptions sub_options; - sub_options.content_filter_options.filter_expression = "data < %0 OR data > %1"; - sub_options.content_filter_options.expression_parameters = { - std::to_string(EMERGENCY_TEMPERATURE[0]), - std::to_string(EMERGENCY_TEMPERATURE[1]) - }; - - sub_ = create_subscription("temperature", 10, callback, sub_options); - - if (!sub_->is_cft_enabled()) { - RCLCPP_WARN( - this->get_logger(), "Content filter is not enabled since it's not supported"); - } else { - RCLCPP_INFO( - this->get_logger(), - "subscribed to topic \"%s\" with content filter options \"%s, {%s}\"", - sub_->get_topic_name(), - sub_options.content_filter_options.filter_expression.c_str(), - rcpputils::join(sub_options.content_filter_options.expression_parameters, ", ").c_str()); - } - } - - private: - rclcpp::Subscription::SharedPtr sub_; - }; - - } // namespace demo_nodes_cpp - -To enable content filtering, applications can set the filtering expression and the expression parameters in ``SubscriptionOptions``. -The application can also check if content filtering is enabled on the subscription. - -In this demo, the ``ContentFilteringSubscriber`` node creates a content filtering subscription that receives a message only if the temperature value is less than -30.0 or greater than 100.0. - -As commented before, content filtering subscription support depends on the RMW implementation. -Applications can use the ``is_cft_enabled`` method to check if content filtering is actually enabled on the subscription. - -To test content filtering subscription, let's run it: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp content_filtering_subscriber - [INFO] [1651094590.682660703] [content_filtering_subscriber]: subscribed to topic "/temperature" with content filter options "data < %0 OR data > %1, {-30.000000, 100.000000}" - [INFO] [1651094594.823805294] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] - [INFO] [1651094595.823419993] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] - [INFO] [1651094596.823410859] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] - [INFO] [1651094597.823350377] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] - [INFO] [1651094598.823282657] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] - [INFO] [1651094599.823297857] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] - [INFO] [1651094600.823355597] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] - [INFO] [1651094615.823315377] [content_filtering_subscriber]: I receive an emergency temperature data: [110.000000] - [INFO] [1651094616.823258458] [content_filtering_subscriber]: I receive an emergency temperature data: [120.000000] - [INFO] [1651094617.823323525] [content_filtering_subscriber]: I receive an emergency temperature data: [130.000000] - [INFO] [1651094618.823315527] [content_filtering_subscriber]: I receive an emergency temperature data: [140.000000] - [INFO] [1651094619.823331424] [content_filtering_subscriber]: I receive an emergency temperature data: [150.000000] - [INFO] [1651094620.823271748] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] - [INFO] [1651094621.823343550] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] - [INFO] [1651094622.823286326] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] - [INFO] [1651094623.823371031] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] - [INFO] [1651094624.823333112] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] - [INFO] [1651094625.823266469] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] - [INFO] [1651094626.823284093] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] - -You should see a message showing the content filtering options used and logs for each message received only if the temperature value is less than -30.0 or greater than 100.0. - -If content filtering is not supported by the RMW implementation, the subscription will still be created without content filtering enabled. -We can try that by executing ``RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_publisher``. - -.. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_subscriber - [WARN] [1651096637.893842072] [content_filtering_subscriber]: Content filter is not enabled since it is not supported - [INFO] [1651096641.246043703] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] - [INFO] [1651096642.245833527] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] - [INFO] [1651096643.245743471] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] - [INFO] [1651096644.245833932] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] - [INFO] [1651096645.245916679] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] - [INFO] [1651096646.245861895] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] - [INFO] [1651096647.245946352] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] - [INFO] [1651096648.245934569] [content_filtering_subscriber]: I receive a temperature data: [-30.000000] - [INFO] [1651096649.245877906] [content_filtering_subscriber]: I receive a temperature data: [-20.000000] - [INFO] [1651096650.245939068] [content_filtering_subscriber]: I receive a temperature data: [-10.000000] - [INFO] [1651096651.245911450] [content_filtering_subscriber]: I receive a temperature data: [0.000000] - [INFO] [1651096652.245879830] [content_filtering_subscriber]: I receive a temperature data: [10.000000] - [INFO] [1651096653.245858329] [content_filtering_subscriber]: I receive a temperature data: [20.000000] - [INFO] [1651096654.245916370] [content_filtering_subscriber]: I receive a temperature data: [30.000000] - [INFO] [1651096655.245933741] [content_filtering_subscriber]: I receive a temperature data: [40.000000] - [INFO] [1651096656.245833975] [content_filtering_subscriber]: I receive a temperature data: [50.000000] - [INFO] [1651096657.245971483] [content_filtering_subscriber]: I receive a temperature data: [60.000000] - -You can see the message ``Content filter is not enabled`` because underlying RMW implementation does not support the feature, but the demo still successfully creates the normal subscription to receive all temperature data. - -Related content ---------------- - -- `content filtering examples `__ that covers all interfaces for content filtering subscription. -- `content filtering design PR `__ +.. redirect-from:: + + Tutorials/Content-Filtering-Subscription + Tutorials/Demos/Content-Filtering-Subscription + +Creating a content filtering subscription +========================================= + +**Goal:** Create a content filtering subscription. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 1 + :local: + +Overview +-------- + +ROS 2 applications typically consist of topics to transmit data from publishers to subscriptions. +Basically, subscriptions receive all published data from publishers on the topic. +But sometimes, a subscription might be interested in only a subset of the data which is being sent by publishers. +A content filtering subscription allows to receive only the data of interest for the application. + +In this demo, we'll be highlighting how to create a content filtering subscription and how they work. + +RMW Support +----------- + +Content filtering subscriptions require RMW implementation support. + +.. list-table:: Content-Filtering-Subscription Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + * - rmw_zenoh_cpp + - not supported + +Currently all RMW implementations that support content filtering subscriptions are `DDS `__ based. +That means that the supported filtering expressions and parameters are also dependent on `DDS `__, you can refer to `DDS specification `__ ``Annex B - Syntax for Queries and Filters`` for details. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Temperature filtering demo +-------------------------- + +This demo shows how a content filtering subscription can be used to only receive temperature values that are out of the acceptable temperature range, detecting emergencies. +The content filtering subscription filters out the uninteresting temperature data, so that the subscription callback is not issued. + +ContentFilteringPublisher: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_publisher.cpp + +.. code-block:: c++ + + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp_components/register_node_macro.hpp" + + #include "std_msgs/msg/float32.hpp" + + #include "demo_nodes_cpp/visibility_control.h" + + namespace demo_nodes_cpp + { + // The simulated temperature data starts from -100.0 and ends at 150.0 with a step size of 10.0 + constexpr std::array TEMPERATURE_SETTING {-100.0f, 150.0f, 10.0f}; + + // Create a ContentFilteringPublisher class that subclasses the generic rclcpp::Node base class. + // The main function below will instantiate the class as a ROS node. + class ContentFilteringPublisher final : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit ContentFilteringPublisher(const rclcpp::NodeOptions & options) + : Node("content_filtering_publisher", options) + { + // Create a function for when messages are to be sent. + auto publish_message = + [this]() -> void + { + msg_ = std::make_unique(); + msg_->data = temperature_; + temperature_ += TEMPERATURE_SETTING[2]; + if (temperature_ > TEMPERATURE_SETTING[1]) { + temperature_ = TEMPERATURE_SETTING[0]; + } + RCLCPP_INFO(this->get_logger(), "Publishing: '%f'", msg_->data); + // Put the message into a queue to be processed by the middleware. + // This call is non-blocking. + pub_->publish(std::move(msg_)); + }; + // Create a publisher with a custom Quality of Service profile. + // Uniform initialization is suggested so it can be trivially changed to + // rclcpp::KeepAll{} if the user wishes. + // (rclcpp::KeepLast(7) -> rclcpp::KeepAll() fails to compile) + rclcpp::QoS qos(rclcpp::KeepLast{7}); + pub_ = this->create_publisher("temperature", qos); + + int64_t publish_ms = this->declare_parameter("publish_ms", 1000); + + // Use a timer to schedule periodic message publishing. + timer_ = this->create_wall_timer(std::chrono::milliseconds(publish_ms), publish_message); + } + + private: + float temperature_ = TEMPERATURE_SETTING[0]; + std::unique_ptr msg_; + rclcpp::Publisher::SharedPtr pub_; + rclcpp::TimerBase::SharedPtr timer_; + }; + + } // namespace demo_nodes_cpp + +The content filter is defined in the subscription side, publishers don't need to be configured in any special way to allow content filtering. +The ``ContentFilteringPublisher`` node publishes simulated temperature data starting from -100.0 and ending at 150.0 with a step size of 10.0 every second. + +We can run the demo by running the ``ros2 run demo_nodes_cpp content_filtering_publisher`` executable (don't forget to source the setup file first): + +.. code-block:: console + + $ ros2 run demo_nodes_cpp content_filtering_publisher + [INFO] [1651094594.822753479] [content_filtering_publisher]: Publishing: '-100.000000' + [INFO] [1651094595.822723857] [content_filtering_publisher]: Publishing: '-90.000000' + [INFO] [1651094596.822752996] [content_filtering_publisher]: Publishing: '-80.000000' + [INFO] [1651094597.822752475] [content_filtering_publisher]: Publishing: '-70.000000' + [INFO] [1651094598.822721485] [content_filtering_publisher]: Publishing: '-60.000000' + [INFO] [1651094599.822696188] [content_filtering_publisher]: Publishing: '-50.000000' + [INFO] [1651094600.822699217] [content_filtering_publisher]: Publishing: '-40.000000' + [INFO] [1651094601.822744113] [content_filtering_publisher]: Publishing: '-30.000000' + [INFO] [1651094602.822694805] [content_filtering_publisher]: Publishing: '-20.000000' + [INFO] [1651094603.822735805] [content_filtering_publisher]: Publishing: '-10.000000' + [INFO] [1651094604.822722094] [content_filtering_publisher]: Publishing: '0.000000' + [INFO] [1651094605.822699960] [content_filtering_publisher]: Publishing: '10.000000' + [INFO] [1651094606.822748946] [content_filtering_publisher]: Publishing: '20.000000' + [INFO] [1651094607.822694017] [content_filtering_publisher]: Publishing: '30.000000' + [INFO] [1651094608.822708798] [content_filtering_publisher]: Publishing: '40.000000' + [INFO] [1651094609.822692417] [content_filtering_publisher]: Publishing: '50.000000' + [INFO] [1651094610.822696426] [content_filtering_publisher]: Publishing: '60.000000' + [INFO] [1651094611.822751913] [content_filtering_publisher]: Publishing: '70.000000' + [INFO] [1651094612.822692231] [content_filtering_publisher]: Publishing: '80.000000' + [INFO] [1651094613.822745549] [content_filtering_publisher]: Publishing: '90.000000' + [INFO] [1651094614.822701982] [content_filtering_publisher]: Publishing: '100.000000' + [INFO] [1651094615.822691465] [content_filtering_publisher]: Publishing: '110.000000' + [INFO] [1651094616.822649070] [content_filtering_publisher]: Publishing: '120.000000' + [INFO] [1651094617.822693616] [content_filtering_publisher]: Publishing: '130.000000' + [INFO] [1651094618.822691832] [content_filtering_publisher]: Publishing: '140.000000' + [INFO] [1651094619.822688452] [content_filtering_publisher]: Publishing: '150.000000' + [INFO] [1651094620.822645327] [content_filtering_publisher]: Publishing: '-100.000000' + [INFO] [1651094621.822689219] [content_filtering_publisher]: Publishing: '-90.000000' + [INFO] [1651094622.822694292] [content_filtering_publisher]: Publishing: '-80.000000' + [...] + +ContentFilteringSubscriber: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_subscriber.cpp + +.. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp_components/register_node_macro.hpp" + #include "rcpputils/join.hpp" + + #include "std_msgs/msg/float32.hpp" + + #include "demo_nodes_cpp/visibility_control.h" + + namespace demo_nodes_cpp + { + // Emergency temperature data less than -30 or greater than 100 + constexpr std::array EMERGENCY_TEMPERATURE {-30.0f, 100.0f}; + + // Create a ContentFilteringSubscriber class that subclasses the generic rclcpp::Node base class. + // The main function below will instantiate the class as a ROS node. + class ContentFilteringSubscriber : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit ContentFilteringSubscriber(const rclcpp::NodeOptions & options) + : Node("content_filtering_subscriber", options) + { + // Create a callback function for when messages are received. + auto callback = + [this](const std_msgs::msg::Float32 & msg) -> void + { + if (msg.data < EMERGENCY_TEMPERATURE[0] || msg.data > EMERGENCY_TEMPERATURE[1]) { + RCLCPP_INFO( + this->get_logger(), + "I receive an emergency temperature data: [%f]", msg.data); + } else { + RCLCPP_INFO(this->get_logger(), "I receive a temperature data: [%f]", msg.data); + } + }; + + // Initialize a subscription with a content filter to receive emergency temperature data that + // are less than -30 or greater than 100. + rclcpp::SubscriptionOptions sub_options; + sub_options.content_filter_options.filter_expression = "data < %0 OR data > %1"; + sub_options.content_filter_options.expression_parameters = { + std::to_string(EMERGENCY_TEMPERATURE[0]), + std::to_string(EMERGENCY_TEMPERATURE[1]) + }; + + sub_ = create_subscription("temperature", 10, callback, sub_options); + + if (!sub_->is_cft_enabled()) { + RCLCPP_WARN( + this->get_logger(), "Content filter is not enabled since it's not supported"); + } else { + RCLCPP_INFO( + this->get_logger(), + "subscribed to topic \"%s\" with content filter options \"%s, {%s}\"", + sub_->get_topic_name(), + sub_options.content_filter_options.filter_expression.c_str(), + rcpputils::join(sub_options.content_filter_options.expression_parameters, ", ").c_str()); + } + } + + private: + rclcpp::Subscription::SharedPtr sub_; + }; + + } // namespace demo_nodes_cpp + +To enable content filtering, applications can set the filtering expression and the expression parameters in ``SubscriptionOptions``. +The application can also check if content filtering is enabled on the subscription. + +In this demo, the ``ContentFilteringSubscriber`` node creates a content filtering subscription that receives a message only if the temperature value is less than -30.0 or greater than 100.0. + +As commented before, content filtering subscription support depends on the RMW implementation. +Applications can use the ``is_cft_enabled`` method to check if content filtering is actually enabled on the subscription. + +To test content filtering subscription, let's run it: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp content_filtering_subscriber + [INFO] [1651094590.682660703] [content_filtering_subscriber]: subscribed to topic "/temperature" with content filter options "data < %0 OR data > %1, {-30.000000, 100.000000}" + [INFO] [1651094594.823805294] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] + [INFO] [1651094595.823419993] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] + [INFO] [1651094596.823410859] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] + [INFO] [1651094597.823350377] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] + [INFO] [1651094598.823282657] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] + [INFO] [1651094599.823297857] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] + [INFO] [1651094600.823355597] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] + [INFO] [1651094615.823315377] [content_filtering_subscriber]: I receive an emergency temperature data: [110.000000] + [INFO] [1651094616.823258458] [content_filtering_subscriber]: I receive an emergency temperature data: [120.000000] + [INFO] [1651094617.823323525] [content_filtering_subscriber]: I receive an emergency temperature data: [130.000000] + [INFO] [1651094618.823315527] [content_filtering_subscriber]: I receive an emergency temperature data: [140.000000] + [INFO] [1651094619.823331424] [content_filtering_subscriber]: I receive an emergency temperature data: [150.000000] + [INFO] [1651094620.823271748] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] + [INFO] [1651094621.823343550] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] + [INFO] [1651094622.823286326] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] + [INFO] [1651094623.823371031] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] + [INFO] [1651094624.823333112] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] + [INFO] [1651094625.823266469] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] + [INFO] [1651094626.823284093] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] + +You should see a message showing the content filtering options used and logs for each message received only if the temperature value is less than -30.0 or greater than 100.0. + +If content filtering is not supported by the RMW implementation, the subscription will still be created without content filtering enabled. +We can try that by executing ``RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_publisher``. + +.. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_subscriber + [WARN] [1651096637.893842072] [content_filtering_subscriber]: Content filter is not enabled since it is not supported + [INFO] [1651096641.246043703] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] + [INFO] [1651096642.245833527] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] + [INFO] [1651096643.245743471] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] + [INFO] [1651096644.245833932] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] + [INFO] [1651096645.245916679] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] + [INFO] [1651096646.245861895] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] + [INFO] [1651096647.245946352] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] + [INFO] [1651096648.245934569] [content_filtering_subscriber]: I receive a temperature data: [-30.000000] + [INFO] [1651096649.245877906] [content_filtering_subscriber]: I receive a temperature data: [-20.000000] + [INFO] [1651096650.245939068] [content_filtering_subscriber]: I receive a temperature data: [-10.000000] + [INFO] [1651096651.245911450] [content_filtering_subscriber]: I receive a temperature data: [0.000000] + [INFO] [1651096652.245879830] [content_filtering_subscriber]: I receive a temperature data: [10.000000] + [INFO] [1651096653.245858329] [content_filtering_subscriber]: I receive a temperature data: [20.000000] + [INFO] [1651096654.245916370] [content_filtering_subscriber]: I receive a temperature data: [30.000000] + [INFO] [1651096655.245933741] [content_filtering_subscriber]: I receive a temperature data: [40.000000] + [INFO] [1651096656.245833975] [content_filtering_subscriber]: I receive a temperature data: [50.000000] + [INFO] [1651096657.245971483] [content_filtering_subscriber]: I receive a temperature data: [60.000000] + +You can see the message ``Content filter is not enabled`` because underlying RMW implementation does not support the feature, but the demo still successfully creates the normal subscription to receive all temperature data. + +Related content +--------------- + +- `content filtering examples `__ that covers all interfaces for content filtering subscription. +- `content filtering design PR `__ \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst b/source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst index 2050341ba2e..30d72988dcf 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst +++ b/source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst @@ -1,187 +1,188 @@ -.. redirect-from:: - - Quality-of-Service - Tutorials/Quality-of-Service - -Using quality-of-service settings for lossy networks -==================================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -Please read the documentation page `about QoS settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>` for background information on available support in ROS 2. - -In this demo, we will spawn a node that publishes a camera image and another that subscribes to the image and shows it on the screen. -We will then simulate a lossy network connection between them and show how different quality of service settings handle the bad link. - - -Prerequisites -------------- -This tutorial assumes you have a :doc:`working ROS 2 installation <../../Installation>` and OpenCV. -See the `OpenCV documentation `__ for its installation instructions. -You will also need the ROS package ``image_tools``. - -.. tabs:: - - .. group-tab:: Linux Binaries - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-image-tools - - .. group-tab:: From Source - - Clone and build the demos repo using the branch that matches your installation. - - .. code-block:: console - - $ git clone https://github.com/ros2/demos.git -b {REPOS_FILE_BRANCH} - - -Run the demo ------------- - -Before running the demo, make sure you have a working webcam connected to your computer. - -Once you've installed ROS 2, source your setup file: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . /setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . /setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call /local_setup.bat - -Then run: - -.. code-block:: console - - $ ros2 run image_tools showimage - -Nothing will happen yet. -``showimage`` is a subscriber node that is waiting for a publisher on the ``image`` topic. - -Note: you have to close the ``showimage`` process with ``Ctrl-C`` later. -You can't just close the window. - -In a separate terminal, source the install file and run the publisher node: - -.. code-block:: console - - $ ros2 run image_tools cam2image - -This will publish an image from your webcam. -In case you don't have a camera attached to your computer, there is a commandline option which publishes predefined images. - - -.. code-block:: console - - $ ros2 run image_tools cam2image --ros-args -p burger_mode:=True - [INFO] [1715662452.055277255] [cam2image]: Publishing image #1 - [INFO] [1715662452.119336061] [cam2image]: Publishing image #2 - [INFO] [1715662452.187315139] [cam2image]: Publishing image #3 - ... - -A window will pop up with the title "view" showing your camera feed. -In the first window, you'll see output from the subscriber: - -.. code-block:: console - - [INFO] [1715662452.188906764] [showimage]: Received image #camera_frame - Received image #camera_frame - [INFO] [1715662452.252836919] [showimage]: Received image #camera_frame - Received image #camera_frame - [INFO] [1715662452.320878578] [showimage]: Received image #camera_frame - Received image #camera_frame - ... - -.. note:: - - macOS users: If these examples do not work or you receive an error like ``ddsi_conn_write failed -1`` then you'll need to increase your system wide UDP packet size: - - .. code-block:: console - - $ sudo sysctl -w net.inet.udp.recvspace=209715 - $ sudo sysctl -w net.inet.udp.maxdgram=65500 - - These changes will not persist a reboot. - If you want the changes to persist, add these lines to ``/etc/sysctl.conf`` (create the file if it doesn't exist already): - - .. code-block:: bash - - net.inet.udp.recvspace=209715 - net.inet.udp.maxdgram=65500 - -Command line options -^^^^^^^^^^^^^^^^^^^^ - -In one of your terminals, add a -h flag to the original command: - - -.. code-block:: console - - $ ros2 run image_tools showimage -h - - - -Add network traffic -^^^^^^^^^^^^^^^^^^^ - -.. warning:: - - This section of the demo won't work on RTI's Connext DDS and Fast-DDS. - When running multiple nodes in the same host, those DDS implementations use shared memory along with the loopback interface. - Degrading the loopback interface throughput won't affect shared memory, thus traffic between the two nodes won't be affected. - -.. note:: - - This next section is Linux-specific. - - However, for macOS and Windows you can achieve a similar effect with the utilities "Network Link Conditioner" (part of the xcode tool suite) and `"Clumsy" `_, respectively, but they will not be covered in this tutorial. - -We are going to use the Linux network traffic control utility, ``tc`` (`man page `_) . - -.. code-block:: console - - $ sudo tc qdisc add dev lo root netem loss 5% - -This magical incantation will simulate 5% packet loss over the local loopback device. -If you use a higher resolution of the images (e.g. ``--ros-args -p width:=640 -p height:=480``) you might want to try a lower packet loss rate (e.g. ``1%``). - -Next we start the ``cam2image`` and ``showimage``, and we'll soon notice that both programs seem to have slowed down the rate at which images are transmitted. -This is caused by the behavior of the default QoS settings. -Enforcing reliability on a lossy channel means that the publisher (in this case, ``cam2image``) will resend the network packets until it receives acknowledgement from the consumer (i.e. ``showimage``). - -Let's now try running both programs, but with more suitable settings. -First of all, we'll use the ``-p reliability:=best_effort`` option to enable best effort communication. -The publisher will now just attempt to deliver the network packets, and don't expect acknowledgement from the consumer. -We see now that some of the frames on the ``showimage`` side were dropped, so the frame numbers in the shell running ``showimage`` won't be consecutive anymore: - - -.. image:: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png - :target: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png - :alt: Best effort image transfer - - -When you're done, remember to delete the queueing discipline: - -.. code-block:: console - - $ sudo tc qdisc delete dev lo root netem loss 5% +.. redirect-from:: + + Quality-of-Service + Tutorials/Quality-of-Service + Tutorials/Demos/Quality-of-Service + +Using quality-of-service settings for lossy networks +==================================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +Please read the documentation page `about QoS settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>` for background information on available support in ROS 2. + +In this demo, we will spawn a node that publishes a camera image and another that subscribes to the image and shows it on the screen. +We will then simulate a lossy network connection between them and show how different quality of service settings handle the bad link. + + +Prerequisites +------------- +This tutorial assumes you have a :doc:`working ROS 2 installation <../../../Get-Started/Installation>` and OpenCV. +See the `OpenCV documentation `__ for its installation instructions. +You will also need the ROS package ``image_tools``. + +.. tabs:: + + .. group-tab:: Linux Binaries + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-image-tools + + .. group-tab:: From Source + + Clone and build the demos repo using the branch that matches your installation. + + .. code-block:: console + + $ git clone https://github.com/ros2/demos.git -b {REPOS_FILE_BRANCH} + + +Run the demo +------------ + +Before running the demo, make sure you have a working webcam connected to your computer. + +Once you've installed ROS 2, source your setup file: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . /setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . /setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call /local_setup.bat + +Then run: + +.. code-block:: console + + $ ros2 run image_tools showimage + +Nothing will happen yet. +``showimage`` is a subscriber node that is waiting for a publisher on the ``image`` topic. + +Note: you have to close the ``showimage`` process with ``Ctrl-C`` later. +You can't just close the window. + +In a separate terminal, source the install file and run the publisher node: + +.. code-block:: console + + $ ros2 run image_tools cam2image + +This will publish an image from your webcam. +In case you don't have a camera attached to your computer, there is a commandline option which publishes predefined images. + + +.. code-block:: console + + $ ros2 run image_tools cam2image --ros-args -p burger_mode:=True + [INFO] [1715662452.055277255] [cam2image]: Publishing image #1 + [INFO] [1715662452.119336061] [cam2image]: Publishing image #2 + [INFO] [1715662452.187315139] [cam2image]: Publishing image #3 + ... + +A window will pop up with the title "view" showing your camera feed. +In the first window, you'll see output from the subscriber: + +.. code-block:: console + + [INFO] [1715662452.188906764] [showimage]: Received image #camera_frame + Received image #camera_frame + [INFO] [1715662452.252836919] [showimage]: Received image #camera_frame + Received image #camera_frame + [INFO] [1715662452.320878578] [showimage]: Received image #camera_frame + Received image #camera_frame + ... + +.. note:: + + macOS users: If these examples do not work or you receive an error like ``ddsi_conn_write failed -1`` then you'll need to increase your system wide UDP packet size: + + .. code-block:: console + + $ sudo sysctl -w net.inet.udp.recvspace=209715 + $ sudo sysctl -w net.inet.udp.maxdgram=65500 + + These changes will not persist a reboot. + If you want the changes to persist, add these lines to ``/etc/sysctl.conf`` (create the file if it doesn't exist already): + + .. code-block:: bash + + net.inet.udp.recvspace=209715 + net.inet.udp.maxdgram=65500 + +Command line options +^^^^^^^^^^^^^^^^^^^^ + +In one of your terminals, add a -h flag to the original command: + + +.. code-block:: console + + $ ros2 run image_tools showimage -h + + + +Add network traffic +^^^^^^^^^^^^^^^^^^^ + +.. warning:: + + This section of the demo won't work on RTI's Connext DDS and Fast-DDS. + When running multiple nodes in the same host, those DDS implementations use shared memory along with the loopback interface. + Degrading the loopback interface throughput won't affect shared memory, thus traffic between the two nodes won't be affected. + +.. note:: + + This next section is Linux-specific. + + However, for macOS and Windows you can achieve a similar effect with the utilities "Network Link Conditioner" (part of the xcode tool suite) and `"Clumsy" `_, respectively, but they will not be covered in this tutorial. + +We are going to use the Linux network traffic control utility, ``tc`` (`man page `_) . + +.. code-block:: console + + $ sudo tc qdisc add dev lo root netem loss 5% + +This magical incantation will simulate 5% packet loss over the local loopback device. +If you use a higher resolution of the images (e.g. ``--ros-args -p width:=640 -p height:=480``) you might want to try a lower packet loss rate (e.g. ``1%``). + +Next we start the ``cam2image`` and ``showimage``, and we'll soon notice that both programs seem to have slowed down the rate at which images are transmitted. +This is caused by the behavior of the default QoS settings. +Enforcing reliability on a lossy channel means that the publisher (in this case, ``cam2image``) will resend the network packets until it receives acknowledgement from the consumer (i.e. ``showimage``). + +Let's now try running both programs, but with more suitable settings. +First of all, we'll use the ``-p reliability:=best_effort`` option to enable best effort communication. +The publisher will now just attempt to deliver the network packets, and don't expect acknowledgement from the consumer. +We see now that some of the frames on the ``showimage`` side were dropped, so the frame numbers in the shell running ``showimage`` won't be consecutive anymore: + + +.. image:: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png + :target: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png + :alt: Best effort image transfer + + +When you're done, remember to delete the queueing discipline: + +.. code-block:: console + + $ sudo tc qdisc delete dev lo root netem loss 5% \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst b/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst index 8d677bf2dab..b387f47129c 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst +++ b/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst @@ -1,385 +1,389 @@ -.. _filtered_topic_keys_tutorial: - -Topic Keys Subscription Filtering Tutorial -========================================== - -This tutorial aims to demonstrate how to receive data only from certain topic instances by combining the use of topic keys and topic content filtering. - -.. contents:: - :depth: 2 - :local: - :backlinks: none - -Background ----------- - -In ROS 2, topics are a mean for representing the state of an object. -Keyed topics are special topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. -This allows the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. - -The :doc:`Content Filter Topic <../../Demos/Content-Filtering-Subscription>` facilitates efficient data distribution by allowing the subscription (reader-side) to specify criteria for the types of data they wish to receive. -By defining this criteria, irrelevant data can be filtered out and applications can focus only on the information that is relevant to their needs. -This functionality not only reduces the amount of data transmitted over the network but also minimizes processing overhead on the receiving end, leading to improved system performance and scalability. - -When combined with topic instances, the benefits of the Content Filter are further enhanced. -By associating specific filter criteria with each topic instance, it is possible fine-tune the data selection process and tailor it to their precise requirements. -This granular level of filtering enables applications to optimally manage data while ensuring that they exchange only the information that is pertinent to their individual use cases. - -.. image:: figures/keyed-topics-cft.gif - :align: center - :width: 70% - -RMW Support ------------ - -Keyed topics require RMW implementation support. - -.. list-table:: Keyed Topics Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - -Implementations not supporting the feature will treat keyed topics as standard topics. -The implications are explained throughout the tutorial. -In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. - -Prerequisites -------------- - -* An up-to-date ROS 2 installation and setup. - Either installed in local host, or using Docker images. - -Preparing the demo package --------------------------- - -Lets start by setting up the ROS 2 environment. -For this, there are two possible options: - -#. Running a ROS 2 Docker image. - - .. code-block:: console - - $ docker run -it --rm osrt/ros:{DISTRO}-desktop - -#. Running the tutorial on the local host. - Please, follow the :doc:`installation instructions <../../../Installation>` for details on installing ROS 2. - -Source the following file to setup the ROS 2 environment: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - - -Retrieving the sources -^^^^^^^^^^^^^^^^^^^^^^ - -Create a new workspace and download the demo package sources as indicated below: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg - $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp - $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py - - .. group-tab:: macOS - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg - $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp - $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py - - .. group-tab:: Windows - - .. code-block:: console - - # Create directory structure - $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\msg - $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\src - $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\launch - $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp - - # Download demo package source code - $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt - $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml - $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md - $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg - $ irm -OutFile src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp - $ irm -OutFile src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp - $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py - -The resulting directory structure should be: - -.. code-block:: - - ~/tutorial_ws - ├──src - ├── demo_keys_filtering_cpp - ├── CMakeLists.txt - ├── README.md - ├── launch - │ └── keyed_sensors_launch.py - ├── msg - │ └── KeyedSensorDataMsg.msg - ├── package.xml - └── src - ├── filtered_keyed_controller.cpp - └── filtered_keyed_sensor.cpp - -A brief analysis on the provided files is explained below: - -* *demo_keys_filtering_cpp* : This directory contains the main source code and configuration files for the demonstration. -* ``CMakeLists.txt``: This file is used with CMake to specify build configurations and dependencies. -* ``README.md``: This is a markdown file providing instructions or information about the demonstration. -* *launch*: This directory contains launch configuration files for launching ROS nodes. - - * ``keyed_sensors_launch.py``: This Python script is used to launch the demonstration nodes. - -* *msg*: This directory contains message definition files. - - * KeyedSensorDataMsg.msg: This is the file defining the message structure for keyed sensor data used in the tutorial. - -* ``package.xml``: This is an XML file containing metadata about the ROS package. -* *src*: This directory contains the source code files for the demonstration. - - * ``filtered_keyed_controller.cpp``: This is the source code for a controller node that filters keyed sensor data in reception, being the most relevant lines the ones that define the filter expression and Quality of Service settings: - - .. code-block:: cpp - - // Initialize a subscription with a content filter to receive data from sensors 2 to 4 - rclcpp::SubscriptionOptions sub_options; - sub_options.content_filter_options.filter_expression = - "sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0"; - sub_options.content_filter_options.expression_parameters = { - std::to_string(SENSOR_TRIGGER) - }; - - // Create the subscription with the content filter options - sub_ = create_subscription("/robot/sensors", - rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local(), - callback, - sub_options); - - * ``filtered_keyed_sensor.cpp``: This is the source code for a sensor node that publishes keyed sensor data. - The most relevant lines are the ones that create the publication with a particular Quality of Service settings that enables the controller to late join the application but still receiving the latest update for every instance with the use of topic keys. - - .. code-block:: cpp - - pub_ = this->create_publisher( - "/robot/sensors", - rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local()); - -Generating the IDL files -^^^^^^^^^^^^^^^^^^^^^^^^ - -Generate the corresponding IDL definition from the provided ``KeyedSensorDataMsg.msg`` file, using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm KeyedSensorDataMsg.msg - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm KeyedSensorDataMsg.msg - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp\msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ del KeyedSensorDataMsg.msg - -Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. -Its content should look like the following: - -.. code-block:: idl - - /* KeyedSensorDataMsg.idl */ - module demo_keys_filtering_cpp { - module msg { - struct KeyedSensorDataMsg { - @key int16 sensor_id; - double measurement; - string data; - }; - }; - }; - -Building the demo package -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Once the environment has been setup and the demo package sources are available, the demo package can be built. -Get into the root of the workspace and build it with the following commands: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws - $ colcon build - - -Running the demo ----------------- - -In the demo, different sensors are publishing data to a controller node using a keyed topic as exemplified below: - -.. image:: figures/cft_tutorial_diagram.svg - :align: center - :width: 80% - -Run the demo by executing the following commands in separate terminals: - -.. note:: - - If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. - This can be done by running ``docker exec -it /bin/bash``. - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller - -The resulting output should be similar to the following, in which the controller node is only receiving data from the specified sensors, i.e. sensors which sensor_id is in the range [2, 4]. -In addition, only when the measurement is greater than 60, the controller node will receive data. -That is specified in the filter expression ``sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0``: - -.. image:: figures/filtered_keyed_topic.gif - :align: center - :width: 100% - -Even in a late-joining scenario, the controller node will receive the latest data of the sensors that meet the filtering criteria at the moment it joins the application, which could be crucial depending on the type of the real application. - -Overall, the combination of topic instances with a content filter topic offers significant benefits in terms of data efficiency, scalability, adaptability and resource optimization. -By leveraging these capabilities, ROS 2 applications can efficiently manage and distribute data in complex distributed environments. +.. redirect-from:: + + Tutorials/Advanced/Topic-Keys/Filtered-Topic-Keys-Tutorial + +.. _filtered_topic_keys_tutorial: + +Topic Keys Subscription Filtering Tutorial +========================================== + +This tutorial aims to demonstrate how to receive data only from certain topic instances by combining the use of topic keys and topic content filtering. + +.. contents:: + :depth: 2 + :local: + :backlinks: none + +Background +---------- + +In ROS 2, topics are a mean for representing the state of an object. +Keyed topics are special topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. +This allows the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. + +The :doc:`Content Filter Topic <../Content-Filtering-Subscription>` facilitates efficient data distribution by allowing the subscription (reader-side) to specify criteria for the types of data they wish to receive. +By defining this criteria, irrelevant data can be filtered out and applications can focus only on the information that is relevant to their needs. +This functionality not only reduces the amount of data transmitted over the network but also minimizes processing overhead on the receiving end, leading to improved system performance and scalability. + +When combined with topic instances, the benefits of the Content Filter are further enhanced. +By associating specific filter criteria with each topic instance, it is possible fine-tune the data selection process and tailor it to their precise requirements. +This granular level of filtering enables applications to optimally manage data while ensuring that they exchange only the information that is pertinent to their individual use cases. + +.. image:: figures/keyed-topics-cft.gif + :align: center + :width: 70% + +RMW Support +----------- + +Keyed topics require RMW implementation support. + +.. list-table:: Keyed Topics Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + +Implementations not supporting the feature will treat keyed topics as standard topics. +The implications are explained throughout the tutorial. +In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. + +Prerequisites +------------- + +* An up-to-date ROS 2 installation and setup. + Either installed in local host, or using Docker images. + +Preparing the demo package +-------------------------- + +Lets start by setting up the ROS 2 environment. +For this, there are two possible options: + +#. Running a ROS 2 Docker image. + + .. code-block:: console + + $ docker run -it --rm osrt/ros:{DISTRO}-desktop + +#. Running the tutorial on the local host. + Please, follow the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. + +Source the following file to setup the ROS 2 environment: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + + +Retrieving the sources +^^^^^^^^^^^^^^^^^^^^^^ + +Create a new workspace and download the demo package sources as indicated below: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg + $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp + $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py + + .. group-tab:: macOS + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg + $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp + $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py + + .. group-tab:: Windows + + .. code-block:: console + + # Create directory structure + $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\msg + $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\src + $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\launch + $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp + + # Download demo package source code + $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt + $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml + $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md + $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg + $ irm -OutFile src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp + $ irm -OutFile src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp + $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py + +The resulting directory structure should be: + +.. code-block:: + + ~/tutorial_ws + ├──src + ├── demo_keys_filtering_cpp + ├── CMakeLists.txt + ├── README.md + ├── launch + │ └── keyed_sensors_launch.py + ├── msg + │ └── KeyedSensorDataMsg.msg + ├── package.xml + └── src + ├── filtered_keyed_controller.cpp + └── filtered_keyed_sensor.cpp + +A brief analysis on the provided files is explained below: + +* *demo_keys_filtering_cpp* : This directory contains the main source code and configuration files for the demonstration. +* ``CMakeLists.txt``: This file is used with CMake to specify build configurations and dependencies. +* ``README.md``: This is a markdown file providing instructions or information about the demonstration. +* *launch*: This directory contains launch configuration files for launching ROS nodes. + + * ``keyed_sensors_launch.py``: This Python script is used to launch the demonstration nodes. + +* *msg*: This directory contains message definition files. + + * KeyedSensorDataMsg.msg: This is the file defining the message structure for keyed sensor data used in the tutorial. + +* ``package.xml``: This is an XML file containing metadata about the ROS package. +* *src*: This directory contains the source code files for the demonstration. + + * ``filtered_keyed_controller.cpp``: This is the source code for a controller node that filters keyed sensor data in reception, being the most relevant lines the ones that define the filter expression and Quality of Service settings: + + .. code-block:: cpp + + // Initialize a subscription with a content filter to receive data from sensors 2 to 4 + rclcpp::SubscriptionOptions sub_options; + sub_options.content_filter_options.filter_expression = + "sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0"; + sub_options.content_filter_options.expression_parameters = { + std::to_string(SENSOR_TRIGGER) + }; + + // Create the subscription with the content filter options + sub_ = create_subscription("/robot/sensors", + rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local(), + callback, + sub_options); + + * ``filtered_keyed_sensor.cpp``: This is the source code for a sensor node that publishes keyed sensor data. + The most relevant lines are the ones that create the publication with a particular Quality of Service settings that enables the controller to late join the application but still receiving the latest update for every instance with the use of topic keys. + + .. code-block:: cpp + + pub_ = this->create_publisher( + "/robot/sensors", + rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local()); + +Generating the IDL files +^^^^^^^^^^^^^^^^^^^^^^^^ + +Generate the corresponding IDL definition from the provided ``KeyedSensorDataMsg.msg`` file, using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm KeyedSensorDataMsg.msg + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm KeyedSensorDataMsg.msg + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp\msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ del KeyedSensorDataMsg.msg + +Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. +Its content should look like the following: + +.. code-block:: idl + + /* KeyedSensorDataMsg.idl */ + module demo_keys_filtering_cpp { + module msg { + struct KeyedSensorDataMsg { + @key int16 sensor_id; + double measurement; + string data; + }; + }; + }; + +Building the demo package +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Once the environment has been setup and the demo package sources are available, the demo package can be built. +Get into the root of the workspace and build it with the following commands: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws + $ colcon build + + +Running the demo +---------------- + +In the demo, different sensors are publishing data to a controller node using a keyed topic as exemplified below: + +.. image:: figures/cft_tutorial_diagram.svg + :align: center + :width: 80% + +Run the demo by executing the following commands in separate terminals: + +.. note:: + + If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. + This can be done by running ``docker exec -it /bin/bash``. + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller + +The resulting output should be similar to the following, in which the controller node is only receiving data from the specified sensors, i.e. sensors which sensor_id is in the range [2, 4]. +In addition, only when the measurement is greater than 60, the controller node will receive data. +That is specified in the filter expression ``sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0``: + +.. image:: figures/filtered_keyed_topic.gif + :align: center + :width: 100% + +Even in a late-joining scenario, the controller node will receive the latest data of the sensors that meet the filtering criteria at the moment it joins the application, which could be crucial depending on the type of the real application. + +Overall, the combination of topic instances with a content filter topic offers significant benefits in terms of data efficiency, scalability, adaptability and resource optimization. +By leveraging these capabilities, ROS 2 applications can efficiently manage and distribute data in complex distributed environments. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst b/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst index 7a61fd542f2..8d7aaf8083f 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst +++ b/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst @@ -1,582 +1,586 @@ -.. _topic_keys_tutorial: - -Topic Keys Tutorial -=================== - -This tutorial aims to demonstrate the use of topic keys by simulating a scenario in which multiple sensors are transmitting their readings to a controller that processes them. - -.. contents:: - :depth: 2 - :local: - :backlinks: none - -Background ----------- - -In ROS 2, a :doc:`Topic<../../../Concepts/Basic/About-Topics>` is a communication channel used for publishing and subscribing to updates of object states. -The value of data associated with a topic changes over time and each of these values are known as *data samples*. -Keyed topics refer to topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. - -Unlike standard topics, where each data sample updates the entire object state with every data sample, keyed topics allow the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. - -.. image:: figures/keyed-topics.gif - :align: center - :width: 70% - -RMW Support ------------ - -Keyed topics require RMW implementation support. - -.. list-table:: Keyed Topics Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - -Implementations not supporting the feature will treat keyed topics as standard topics. -The implications are explained throughout the tutorial. -In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. - -Creating custom IDL messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 users can define their own :ref:`custom topic messages` in the ``.msg`` format. -Then, the ROS 2 message generation stack translates it to the DDS native `OMG IDL (Interface Definition Language) `_ message format. - -One of the advantages of defining messages in IDL is the ability to use annotations. -Annotations are metadata to the data structure definition that provide additional information about IDL constructs such as modules, interfaces, operations, attributes, and data types. -They are relevant for code generation, documentation, or other purposes. -Annotations in IDL typically follow the ``@`` symbol and can be applied to various IDL constructs. -The ``@key`` annotation is used to designate a member as key, which is covered in the following section. - -Users can define their own messages in the IDL format directly (following the `ROS 2 interface design documentation `_) or use the ``msg2idl`` tool within the ``rosidl_adapter`` package. - -Creating Keyed Messages -^^^^^^^^^^^^^^^^^^^^^^^ - -Keyed topics exist when one or more fields in the data structure are annotated as keys. -These key fields serve as unique identifiers for topic instances in order to organize and manage the data samples, facilitating efficient access, retrieval, and filtering of data based on the specified key criteria. - -The ``@key`` annotation designates a field as a key for the given topic type, which can have zero or more key fields and can be applied to structure fields of various types: - -* Any primitive, such as booleans, integers, characters, strings or sequences. -* Other existing or defined messages. - If those have defined an inner key member, then those fields will we used as part of the key. - Otherwise, the key will be the concatenation of all the fields. - -In order to specify multiple keys, separate ``@key`` annotations are used. -The following example shows how to define a keyed message using the IDL format: - -.. code-block:: console - - # KeyedMsgName.idl - module package_name { - module msg { - struct KeyedMsgName { - @key long key; - string data; - }; - }; - }; - -.. note:: - - Currently, the only supported message format that can be annotated with ``@key`` is *.idl*. - Neither ``.msg`` nor ``.srv`` files support annotations yet. - -Prerequisites -------------- - -* An up-to-date ROS 2 installation and setup. - Either installed in local host, or using Docker images. - -Preparing the demo package --------------------------- - -Lets start by setting up the environment. -For this, there are two possible options: - -#. Running a ROS 2 Docker image. - - .. code-block:: console - - $ docker run -it --rm osrt/ros:{DISTRO}-desktop - -#. Running the tutorial on the local host. - Please, follow the :doc:`installation instructions <../../../Installation>` for details on installing ROS 2. - -Source the following file to setup the ROS 2 environment: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - - -Retrieving the sources -^^^^^^^^^^^^^^^^^^^^^^ - -In order to retrieve the example demo code, create a new workspace and download the demo package sources as indicated below: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md - $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg - $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp - $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp - $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp - $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp - $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp - $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp - $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py - $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py - - .. group-tab:: macOS - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md - $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg - $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp - $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp - $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp - $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp - $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp - $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp - $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py - $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py - - .. group-tab:: Windows - - .. code-block:: console - - # Create directory structure - $ mkdir C:\tutorial_ws\src\demo_keys_cpp\msg - $ mkdir C:\tutorial_ws\src\demo_keys_cpp\src - $ mkdir C:\tutorial_ws\src\demo_keys_cpp\launch - $ cd C:\tutorial_ws\src\demo_keys_cpp - - # Download demo package source code - $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt - $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml - $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md - $ irm -OutFile msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg - $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg - $ irm -OutFile src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp - $ irm -OutFile src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp - $ irm -OutFile src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp - $ irm -OutFile src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp - $ irm -OutFile src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp - $ irm -OutFile src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp - $ irm -OutFile launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py - $ irm -OutFile launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py - $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py - -Like any other ROS 2 related package, the external dependencies are listed in the ``package.xml``. -The ``CMakeLists.txt`` file defines the different targets to be built and the dependencies between them. -Note that it is built in a component manner meaning that the nodes defined in the source files can be also loaded as composable plugins apart from being executed as standalone nodes. -The *src/* directory contains the core source files for the different nodes that will be executed in the demo. -The launch files for sensors are also provided in the *launch/* directory in which 10 different nodes are launched for each one of the cases that will be later explained. -Finally, the *msg/* directory contains two different IDL message definitions, one with key annotations (sensor_id) and another without it. - -The resulting directory structure should be: - -.. code-block:: - - ~/tutorial_ws - ├──src - ├── demo_keys_cpp - ├── CMakeLists.txt - ├── README.md - ├── launch - │ ├── keyed_sensors_launch.py - │ ├── multiple_topic_sensors_launch.py - │ └── single_topic_sensors_launch.py - ├── msg - │ ├── KeyedSensorDataMsg.msg - │ └── SensorDataMsg.msg - ├── package.xml - └── src - ├── keyed_controller.cpp - ├── keyed_sensor.cpp - ├── multiple_topic_controller.cpp - ├── multiple_topic_sensor.cpp - ├── single_topic_controller.cpp - └── single_topic_sensor.cpp - -Generating the IDL files -^^^^^^^^^^^^^^^^^^^^^^^^ - -Starting from the provided ``.msg`` files, generate the corresponding IDL files using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws\src\demo_keys_cpp\msg - $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ del SensorDataMsg.msg KeyedSensorDataMsg.msg - - -Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. -Its content should look like the following: - -.. code-block:: idl - - /* KeyedSensorDataMsg.idl */ - module demo_keys_cpp { - module msg { - struct KeyedSensorDataMsg { - @key int16 sensor_id; - string data; - }; - }; - }; - -Building the demo package -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Once the environment has been setup and the demo package sources are available, we are ready to build the workspace. -Get into the root of the workspace and build it with the following commands: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws - $ colcon build - -Running the demo ----------------- - -The tutorial demo consists of a controller node that subscribes to the data published by multiple sensors. -Each of the sensors are identified by a *sensor_id* and publish data to the controller at different rates, in particular, the publication period (in seconds) is the *sensor_id* times 1. -Three different valid approaches are used to address the situation: - -* In the first one, multiple sensors are publishing data to the controller using different topics for each sensor and the controller subscribing to each one of them. -* In the second approach, multiple sensors publish data to the controller using a single standalone topic. -* Finally, in the third one, the sensors use a single keyed topic defining a single data instance per unique *sensor_id*. - -In addition, all the publications and subscriptions use the following QoS settings: - -* History QoS: ``KEEP_LAST 1``. -* Reliable communication. -* Transient Local durability. - -This is set this way to recreate late joining of the controller to the application and evaluate the behavior in each of the three different scenarios. -The following diagram depicts the three different scenarios: - -.. image:: figures/tutorial_diagram.svg - :align: center - :width: 90% - -Lets start with the first scenario. -Run the demo by executing the following commands in separate terminals: - -.. note:: - - If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. - This can be done by running ``docker exec -it /bin/bash``. - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_cpp multiple_topic_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_cpp multiple_topic_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 run demo_keys_cpp multiple_topic_controller - -The resulting output should be similar to the following: - -.. image:: figures/multiple_topics.gif - :align: center - :width: 100% - -It is important to note that this initial approach is not the most efficient one, as it entails the creation of multiple topics, publishers, and subscriptions. -Furthermore, apart from being inefficient, it also makes the application more complex, harder to maintain, and resource demanding. -Moreover, as a consequence of creating far more entities than needed, the application incurs in an unnecessary discovery overhead. - -Lets go a step further. -In this second approach a single topic is used in which all the sensors will publish their data (without using a keyed topic). -Run the demo by executing the following commands in separate terminals: - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp single_topic_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp single_topic_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp single_topic_controller - -Which leads to an output similar to the one shown below: - -.. image:: figures/single_topics.gif - :align: center - :width: 100% - - -This second scenario illustrates that using one single topic, a late-joining controller will not recover the state of all the sensors when it joins the application. -This is easily noticeable in the case of sensor with *id* 10; the controller will not receive the latest data published by this sensor until it publishes a new one. -Furthermore, sensors publishing at higher rates (sensors 1~3) can overwrite the data of low rate sensors, causing starvation even in the case of augmenting the history size. -These are severe problems that should be avoided. - -Now, lets move on to the third approach for addressing the problem. -Start, or reuse previous opened terminals and run the following commands: - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp keyed_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp keyed_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp keyed_controller - -The resulting output should be similar to the following: - -.. image:: figures/keyed_topic.gif - :align: center - :width: 100% - -In this final case, the controller is able to successfully recover the latest state of each sensor (data instance) when it joins the application. -In addition, it uses optimum resources (it only requires one topic and one subscription) and guarantees a minimum discovery overhead. -Hence, it is by using topic keys when the reception of the latest status of each instance (sensor) is assured. -This is because the Quality of Service settings are applied per data instance. -For learning how to combine keyed topics with content filter topic, please refer to the :ref:`filtered_topic_keys_tutorial`. +.. redirect-from:: + + Tutorials/Advanced/Topic-Keys/Topic-Keys-Tutorial + +.. _topic_keys_tutorial: + +Topic Keys Tutorial +=================== + +This tutorial aims to demonstrate the use of topic keys by simulating a scenario in which multiple sensors are transmitting their readings to a controller that processes them. + +.. contents:: + :depth: 2 + :local: + :backlinks: none + +Background +---------- + +In ROS 2, a :doc:`Topic <../../../About-Topics>` is a communication channel used for publishing and subscribing to updates of object states. +The value of data associated with a topic changes over time and each of these values are known as *data samples*. +Keyed topics refer to topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. + +Unlike standard topics, where each data sample updates the entire object state with every data sample, keyed topics allow the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. + +.. image:: figures/keyed-topics.gif + :align: center + :width: 70% + +RMW Support +----------- + +Keyed topics require RMW implementation support. + +.. list-table:: Keyed Topics Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + +Implementations not supporting the feature will treat keyed topics as standard topics. +The implications are explained throughout the tutorial. +In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. + +Creating custom IDL messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 users can define their own :ref:`custom topic messages` in the ``.msg`` format. +Then, the ROS 2 message generation stack translates it to the DDS native `OMG IDL (Interface Definition Language) `_ message format. + +One of the advantages of defining messages in IDL is the ability to use annotations. +Annotations are metadata to the data structure definition that provide additional information about IDL constructs such as modules, interfaces, operations, attributes, and data types. +They are relevant for code generation, documentation, or other purposes. +Annotations in IDL typically follow the ``@`` symbol and can be applied to various IDL constructs. +The ``@key`` annotation is used to designate a member as key, which is covered in the following section. + +Users can define their own messages in the IDL format directly (following the `ROS 2 interface design documentation `_) or use the ``msg2idl`` tool within the ``rosidl_adapter`` package. + +Creating Keyed Messages +^^^^^^^^^^^^^^^^^^^^^^^ + +Keyed topics exist when one or more fields in the data structure are annotated as keys. +These key fields serve as unique identifiers for topic instances in order to organize and manage the data samples, facilitating efficient access, retrieval, and filtering of data based on the specified key criteria. + +The ``@key`` annotation designates a field as a key for the given topic type, which can have zero or more key fields and can be applied to structure fields of various types: + +* Any primitive, such as booleans, integers, characters, strings or sequences. +* Other existing or defined messages. + If those have defined an inner key member, then those fields will we used as part of the key. + Otherwise, the key will be the concatenation of all the fields. + +In order to specify multiple keys, separate ``@key`` annotations are used. +The following example shows how to define a keyed message using the IDL format: + +.. code-block:: console + + # KeyedMsgName.idl + module package_name { + module msg { + struct KeyedMsgName { + @key long key; + string data; + }; + }; + }; + +.. note:: + + Currently, the only supported message format that can be annotated with ``@key`` is *.idl*. + Neither ``.msg`` nor ``.srv`` files support annotations yet. + +Prerequisites +------------- + +* An up-to-date ROS 2 installation and setup. + Either installed in local host, or using Docker images. + +Preparing the demo package +-------------------------- + +Lets start by setting up the environment. +For this, there are two possible options: + +#. Running a ROS 2 Docker image. + + .. code-block:: console + + $ docker run -it --rm osrt/ros:{DISTRO}-desktop + +#. Running the tutorial on the local host. + Please, follow the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. + +Source the following file to setup the ROS 2 environment: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + + +Retrieving the sources +^^^^^^^^^^^^^^^^^^^^^^ + +In order to retrieve the example demo code, create a new workspace and download the demo package sources as indicated below: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md + $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg + $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp + $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp + $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp + $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp + $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp + $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp + $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py + $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py + + .. group-tab:: macOS + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md + $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg + $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp + $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp + $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp + $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp + $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp + $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp + $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py + $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py + + .. group-tab:: Windows + + .. code-block:: console + + # Create directory structure + $ mkdir C:\tutorial_ws\src\demo_keys_cpp\msg + $ mkdir C:\tutorial_ws\src\demo_keys_cpp\src + $ mkdir C:\tutorial_ws\src\demo_keys_cpp\launch + $ cd C:\tutorial_ws\src\demo_keys_cpp + + # Download demo package source code + $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt + $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml + $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md + $ irm -OutFile msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg + $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg + $ irm -OutFile src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp + $ irm -OutFile src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp + $ irm -OutFile src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp + $ irm -OutFile src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp + $ irm -OutFile src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp + $ irm -OutFile src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp + $ irm -OutFile launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py + $ irm -OutFile launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py + $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py + +Like any other ROS 2 related package, the external dependencies are listed in the ``package.xml``. +The ``CMakeLists.txt`` file defines the different targets to be built and the dependencies between them. +Note that it is built in a component manner meaning that the nodes defined in the source files can be also loaded as composable plugins apart from being executed as standalone nodes. +The *src/* directory contains the core source files for the different nodes that will be executed in the demo. +The launch files for sensors are also provided in the *launch/* directory in which 10 different nodes are launched for each one of the cases that will be later explained. +Finally, the *msg/* directory contains two different IDL message definitions, one with key annotations (sensor_id) and another without it. + +The resulting directory structure should be: + +.. code-block:: + + ~/tutorial_ws + ├──src + ├── demo_keys_cpp + ├── CMakeLists.txt + ├── README.md + ├── launch + │ ├── keyed_sensors_launch.py + │ ├── multiple_topic_sensors_launch.py + │ └── single_topic_sensors_launch.py + ├── msg + │ ├── KeyedSensorDataMsg.msg + │ └── SensorDataMsg.msg + ├── package.xml + └── src + ├── keyed_controller.cpp + ├── keyed_sensor.cpp + ├── multiple_topic_controller.cpp + ├── multiple_topic_sensor.cpp + ├── single_topic_controller.cpp + └── single_topic_sensor.cpp + +Generating the IDL files +^^^^^^^^^^^^^^^^^^^^^^^^ + +Starting from the provided ``.msg`` files, generate the corresponding IDL files using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws\src\demo_keys_cpp\msg + $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ del SensorDataMsg.msg KeyedSensorDataMsg.msg + + +Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. +Its content should look like the following: + +.. code-block:: idl + + /* KeyedSensorDataMsg.idl */ + module demo_keys_cpp { + module msg { + struct KeyedSensorDataMsg { + @key int16 sensor_id; + string data; + }; + }; + }; + +Building the demo package +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Once the environment has been setup and the demo package sources are available, we are ready to build the workspace. +Get into the root of the workspace and build it with the following commands: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws + $ colcon build + +Running the demo +---------------- + +The tutorial demo consists of a controller node that subscribes to the data published by multiple sensors. +Each of the sensors are identified by a *sensor_id* and publish data to the controller at different rates, in particular, the publication period (in seconds) is the *sensor_id* times 1. +Three different valid approaches are used to address the situation: + +* In the first one, multiple sensors are publishing data to the controller using different topics for each sensor and the controller subscribing to each one of them. +* In the second approach, multiple sensors publish data to the controller using a single standalone topic. +* Finally, in the third one, the sensors use a single keyed topic defining a single data instance per unique *sensor_id*. + +In addition, all the publications and subscriptions use the following QoS settings: + +* History QoS: ``KEEP_LAST 1``. +* Reliable communication. +* Transient Local durability. + +This is set this way to recreate late joining of the controller to the application and evaluate the behavior in each of the three different scenarios. +The following diagram depicts the three different scenarios: + +.. image:: figures/tutorial_diagram.svg + :align: center + :width: 90% + +Lets start with the first scenario. +Run the demo by executing the following commands in separate terminals: + +.. note:: + + If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. + This can be done by running ``docker exec -it /bin/bash``. + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_cpp multiple_topic_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_cpp multiple_topic_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 run demo_keys_cpp multiple_topic_controller + +The resulting output should be similar to the following: + +.. image:: figures/multiple_topics.gif + :align: center + :width: 100% + +It is important to note that this initial approach is not the most efficient one, as it entails the creation of multiple topics, publishers, and subscriptions. +Furthermore, apart from being inefficient, it also makes the application more complex, harder to maintain, and resource demanding. +Moreover, as a consequence of creating far more entities than needed, the application incurs in an unnecessary discovery overhead. + +Lets go a step further. +In this second approach a single topic is used in which all the sensors will publish their data (without using a keyed topic). +Run the demo by executing the following commands in separate terminals: + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp single_topic_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp single_topic_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp single_topic_controller + +Which leads to an output similar to the one shown below: + +.. image:: figures/single_topics.gif + :align: center + :width: 100% + + +This second scenario illustrates that using one single topic, a late-joining controller will not recover the state of all the sensors when it joins the application. +This is easily noticeable in the case of sensor with *id* 10; the controller will not receive the latest data published by this sensor until it publishes a new one. +Furthermore, sensors publishing at higher rates (sensors 1~3) can overwrite the data of low rate sensors, causing starvation even in the case of augmenting the history size. +These are severe problems that should be avoided. + +Now, lets move on to the third approach for addressing the problem. +Start, or reuse previous opened terminals and run the following commands: + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp keyed_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp keyed_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp keyed_controller + +The resulting output should be similar to the following: + +.. image:: figures/keyed_topic.gif + :align: center + :width: 100% + +In this final case, the controller is able to successfully recover the latest state of each sensor (data instance) when it joins the application. +In addition, it uses optimum resources (it only requires one topic and one subscription) and guarantees a minimum discovery overhead. +Hence, it is by using topic keys when the reception of the latest status of each instance (sensor) is assured. +This is because the Quality of Service settings are applied per data instance. +For learning how to combine keyed topics with content filter topic, please refer to the :ref:`filtered_topic_keys_tutorial`. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst b/source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst index 003461bdf64..6a88e1266f6 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst +++ b/source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst @@ -1,93 +1,97 @@ -Wait for acknowledgment -======================= - -**Goal:** Wait for acknowledgment of messages sent by a publisher. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Table of Contents - :depth: 1 - :local: - -Overview --------- - -In Publisher-Subscriber architecture, messages are sent from the publisher to the subscribers, and the publisher does not have any built-in mechanism to confirm that the subscriber has received the messages. -This feature enables the publisher to wait for acknowledgment of messages it sent. -This is useful in scenarios where the publisher needs to ensure that the subscriber has received the message before proceeding with further actions, such as sending more messages or performing other operations. - -RMW Support ------------ - -Wait for acknowledgment requires RMW implementation support. - -.. list-table:: Wait-for-Acknowledgment Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - supported - -The publisher's :ref:`QoS reliability policy ` needs to be ``RELIABLE`` to use the wait for acknowledgment feature, otherwise the publisher will not wait for acknowledgment. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-examples-rclcpp-minimal-publisher`` and ``ros-{DISTRO}-examples-rclcpp-minimal-subscriber`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Running the demo ----------------- - -This demo shows how to use the wait for acknowledgment feature in the publisher to ensure that messages sent by the publisher are acknowledged by all subscriptions. - -https://github.com/ros2/examples/blob/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/member_function_with_wait_for_all_acked.cpp - -The publisher can use the ``wait_for_all_acked`` method to wait for message acknowledgments within a specified timeout before shutdown by the signal. - -We can start the demo by running the ``publisher_wait_for_all_acked`` and ``subscriber_member_function`` executables from the ``examples_rclcpp_minimal_publisher`` package (don't forget to source the setup file first): - -Start the subscriber in one terminal: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function - [INFO] [1743121567.030751270] [minimal_subscriber]: I heard: 'Hello, world! 0' - [INFO] [1743121567.530981660] [minimal_subscriber]: I heard: 'Hello, world! 1' - [INFO] [1743121568.031032935] [minimal_subscriber]: I heard: 'Hello, world! 2' - [INFO] [1743121568.531048458] [minimal_subscriber]: I heard: 'Hello, world! 3' - [INFO] [1743121569.031049351] [minimal_subscriber]: I heard: 'Hello, world! 4' - [INFO] [1743121569.530980327] [minimal_subscriber]: I heard: 'Hello, world! 5' - [INFO] [1743121570.030825871] [minimal_subscriber]: I heard: 'Hello, world! 6' - ... - -Then start the publisher in another terminal: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_publisher publisher_wait_for_all_acked - [INFO] [1743121567.030353553] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 0' - [INFO] [1743121567.530420788] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 1' - [INFO] [1743121568.030461599] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 2' - [INFO] [1743121568.530435646] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 3' - [INFO] [1743121569.030431263] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 4' - [INFO] [1743121569.530447106] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 5' - [INFO] [1743121570.030353934] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 6' - ^C[INFO] [1743121570.344981639] [rclcpp]: signal_handler(signum=2) - [INFO] [1743121570.345398788] [minimal_publisher_with_wait_for_all_acked]: All subscribers acknowledge messages - -When the publisher is terminated (e.g., by pressing :kbd:`Ctrl-C`), it will wait for acknowledgment of all messages sent before shutdown. -If all subscribers acknowledge the messages, the publisher will print a message indicating that all subscribers have acknowledged the messages. -If not, it will print a message indicating that not all subscribers acknowledged the messages within the specified timeout. - -Related content ---------------- - -- `Wait-for-Acknowledgment example with rclpy `__. +.. redirect-from:: + + Tutorials/Demos/Wait-for-Acknowledgment + +Wait for acknowledgment +======================= + +**Goal:** Wait for acknowledgment of messages sent by a publisher. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Table of Contents + :depth: 1 + :local: + +Overview +-------- + +In Publisher-Subscriber architecture, messages are sent from the publisher to the subscribers, and the publisher does not have any built-in mechanism to confirm that the subscriber has received the messages. +This feature enables the publisher to wait for acknowledgment of messages it sent. +This is useful in scenarios where the publisher needs to ensure that the subscriber has received the message before proceeding with further actions, such as sending more messages or performing other operations. + +RMW Support +----------- + +Wait for acknowledgment requires RMW implementation support. + +.. list-table:: Wait-for-Acknowledgment Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - supported + +The publisher's :ref:`QoS reliability policy ` needs to be ``RELIABLE`` to use the wait for acknowledgment feature, otherwise the publisher will not wait for acknowledgment. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-examples-rclcpp-minimal-publisher`` and ``ros-{DISTRO}-examples-rclcpp-minimal-subscriber`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Running the demo +---------------- + +This demo shows how to use the wait for acknowledgment feature in the publisher to ensure that messages sent by the publisher are acknowledged by all subscriptions. + +https://github.com/ros2/examples/blob/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/member_function_with_wait_for_all_acked.cpp + +The publisher can use the ``wait_for_all_acked`` method to wait for message acknowledgments within a specified timeout before shutdown by the signal. + +We can start the demo by running the ``publisher_wait_for_all_acked`` and ``subscriber_member_function`` executables from the ``examples_rclcpp_minimal_publisher`` package (don't forget to source the setup file first): + +Start the subscriber in one terminal: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function + [INFO] [1743121567.030751270] [minimal_subscriber]: I heard: 'Hello, world! 0' + [INFO] [1743121567.530981660] [minimal_subscriber]: I heard: 'Hello, world! 1' + [INFO] [1743121568.031032935] [minimal_subscriber]: I heard: 'Hello, world! 2' + [INFO] [1743121568.531048458] [minimal_subscriber]: I heard: 'Hello, world! 3' + [INFO] [1743121569.031049351] [minimal_subscriber]: I heard: 'Hello, world! 4' + [INFO] [1743121569.530980327] [minimal_subscriber]: I heard: 'Hello, world! 5' + [INFO] [1743121570.030825871] [minimal_subscriber]: I heard: 'Hello, world! 6' + ... + +Then start the publisher in another terminal: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_publisher publisher_wait_for_all_acked + [INFO] [1743121567.030353553] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 0' + [INFO] [1743121567.530420788] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 1' + [INFO] [1743121568.030461599] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 2' + [INFO] [1743121568.530435646] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 3' + [INFO] [1743121569.030431263] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 4' + [INFO] [1743121569.530447106] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 5' + [INFO] [1743121570.030353934] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 6' + ^C[INFO] [1743121570.344981639] [rclcpp]: signal_handler(signum=2) + [INFO] [1743121570.345398788] [minimal_publisher_with_wait_for_all_acked]: All subscribers acknowledge messages + +When the publisher is terminated (e.g., by pressing :kbd:`Ctrl-C`), it will wait for acknowledgment of all messages sent before shutdown. +If all subscribers acknowledge the messages, the publisher will print a message indicating that all subscribers have acknowledged the messages. +If not, it will print a message indicating that not all subscribers acknowledged the messages within the specified timeout. + +Related content +--------------- + +- `Wait-for-Acknowledgment example with rclpy `__. \ No newline at end of file diff --git a/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst b/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst index 8879e4c92c3..8804ea4c21d 100644 --- a/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst +++ b/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst @@ -1,625 +1,625 @@ -.. redirect-from:: - - Contributing/Contributing-To-ROS-2-Documentation - -Contributing to ROS 2 Documentation -=================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Contributions to this site are most welcome. -This page explains how to contribute to ROS 2 Documentation. -Please be sure to read the below sections carefully before contributing. - -The site is built using `Sphinx `_, and more particularly using `Sphinx multiversion `_. - -Branch structure ----------------- - -The source code of documentation is located in the `ROS 2 Documentation GitHub repository `_. -This repository is set up with one branch per ROS 2 distribution to handle differences between the distributions. -If a change is common to all ROS 2 distributions, it should be made to the ``rolling`` branch (and then will be backported as appropriate). -If a change is specific to a particular ROS 2 distribution, it should be made to the respective branch. - -Source structure ----------------- - -The source files for the site are all located under the ``source`` subdirectory. -Templates for various sphinx plugins are located under ``source/_templates``. -The root directory contains configuration and files required to locally build the site for testing. - -Building the site locally -------------------------- - -Start by creating `venv `__ to build the documentation: - -.. code-block:: console - - $ python3 -m venv ros2doc # create venv - $ source ros2doc/bin/activate # activate venv - -And install requirements located in the ``requirements.txt`` file: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ pip install -r requirements.txt -c constraints.txt - - .. group-tab:: macOS - - .. code-block:: console - - $ pip install -r requirements.txt -c constraints.txt - - .. group-tab:: Windows - - .. code-block:: console - - $ python -m pip install -r requirements.txt -c constraints.txt - -In order for Sphinx to be able to generate diagrams, the ``dot`` command must be available. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ sudo apt update ; sudo apt install graphviz - - .. group-tab:: macOS - - .. code-block:: console - - $ brew install graphviz - - .. group-tab:: Windows - - Download an installer from `the Graphviz Download page `__ and install it. - Make sure to allow the installer to add it to the Windows ``%PATH%``, otherwise Sphinx will not be able to find it. - -Building the site for one branch -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build the site for just this branch, type ``make html`` at the top-level of the repository. -This is the recommended way to test out local changes. - -.. code-block:: console - - $ make html - -The build process can take some time. -To see the output, open ``build/html/index.html`` in your browser. - - -Checking / Testing the site -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can run the documentation tests locally (using `doc8 `_) with the following command: - -.. code-block:: console - - $ make test - -You can run the Python documentation tools tests locally (using `pytest `_) with the following command: - -.. code-block:: console - - $ make test-tools - -You can run the documentation linter locally (using `sphinx-lint `_) with the following command: - -.. code-block:: console - - $ make lint - -You can run the documentation spell checker locally (using `codespell `_) with the following command: - -.. code-block:: console - - $ make spellcheck - -.. note:: - - If that detects specific words that need to be ignored, add it to `codespell_whitelist `_ . - -To know more about spelling checks, refer to :ref:`Spelling check ` - -View Site Through Github CI -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For small changes to the ROS 2 Docs you can view your changes as rendered HTML using artifacts generated in our Github Actions. -The "build" action produces the entire ROS Docs as a downloadable Zip file that contains all HTML for `docs.ros.org `_ -This build action is triggered after passing the test action and lint action. - -To download and view your changes first go to your pull request and under the title click the "Checks" tab. -On the left hand side of the checks page, click on the "Test" section under the "tests" section click on "build" dialog. -This will open a menu on the right, where you can click on "Upload document artifacts" and scroll to the bottom to see the download link for the Zipped' HTML files under the heading "Artifact download URL". - -.. image:: ./images/github_action.png - :width: 100% - :alt: Steps to find rendered HTML files on ROS Github action - -Building the site for all branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build the site for all branches, type ``make multiversion`` from the ``rolling`` branch. -This has two drawbacks: - -#. The multiversion plugin doesn't understand how to do incremental builds, so it always rebuilds everything. - This can be slow. - -#. When typing ``make multiversion``, it will always check out exactly the branches listed in the ``conf.py`` file. - That means that local changes will not be shown. - -To show local changes in the multiversion output, you must first commit the changes to a local branch. -Then you must edit the `conf.py `_ file and change the ``smv_branch_whitelist`` variable to point to your branch. - -Checking for broken links -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To check for broken links on the site, run: - -.. code-block:: console - - $ make linkcheck - -This will check the entire site for broken links, and output the results to the screen and ``build/linkcheck``. - -.. _spelling-check: - -Spelling check -^^^^^^^^^^^^^^ - -The ``make spellcheck`` command scans the documentation files and flags any misspellings. -If errors are detected, review the suggestions and update the pull request as necessary. - -Some words, such as technical terms or proper nouns, maybe mistakenly flagged as misspelled. -If you encounter such instances, you can add them to the ignore list to prevent them from being flagged in the future. -To do this, add it to the `codespell_whitelist `_ file as follows: - -.. code-block:: text - - empy - jupyter - lets - ws - -To include custom corrections that ``codespell`` should apply, you can add them to the `codespell_dictionary `_ file as follows: - -.. code-block:: text - - amnet->ament - colcn->colcon - rosabg->rosbag - rosdistroy->rosdistro - -To check the dictionaries, you can run the ``make check-dictionaries`` command. -This will check the blank lines and leading/trailing spaces in the dictionaries. -If it complains about the dictionaries, you can run the ``make sort-dictionaries`` command. -This command will automatically modify the dictionaries if any issues are found. - -Migrating Pages from the ROS Wiki ---------------------------------- - -The first step in migrating a page from the `ROS Wiki `_ to the ROS 2 documentation is to determine if the page needs to be migrated. -Check if the content, or something similar, is available on https://docs.ros.org/en/rolling by searching for related terms. -If it has already been migrated, congratulations! -You are done. -If it hasn't been migrated, then consider whether it is worth keeping. -Pages that you or others find useful, and refer to regularly, are good candidates assuming they have not been superseded by other documentation. -Pages for ROS projects and features that are no longer supported by a current distribution should not be migrated. - -The next step for migrating a ROS Wiki page is to determine the correct location for the migrated page. -Only ROS Wiki pages that cover core ROS concepts belong in the ROS Documentation, these pages should be migrated to a logical location within the ROS documentation. -Package specific documentation should be migrated to the package-level documentation generated in the package's source repository. -Once the package level documentation has been updated it will be visible `as part of the package-level documentation `__. -If you are unsure whether and where to migrate a page, please get in touch via an issue on https://github.com/ros2/ros2_documentation or on https://discourse.openrobotics.org/. - -Once you've determined that a ROS Wiki page is worth migrating, and found an appropriate landing spot in the ROS documentation, the next step in the migration process is to set up the conversion tools necessary to migrate the page. -In most cases the only tools necessary to migrate a single ROS Wiki page to the ROS Docs are the `PanDoc `_ command line tool and a text editor. -PanDoc is supported by most modern operating systems using the installation instruction found on their website. -It is worth noting that the ROS Wiki uses an older wiki technology (MoinMoin), so the markup language used is an obscure dialect of the `MediaWiki `__ format. -We've found that the easiest way to migrate a page from the ROS Wiki is to convert it from HTML into reStructured text using PanDoc. - - -Migrating a Wiki File -^^^^^^^^^^^^^^^^^^^^^ - -#. Clone the appropriate repository. - If you are migrating a page to the official documentation hosted here, then you should clone https://github.com/ros2/ros2_documentation. - -#. Create a new Github branch for your migrated page. - We suggest something like ``pagename-migration``. - -#. Download the appropriate ROS Wiki page to an html file using wget or a similar tool (e.g. ``wget -O urdf.html https://wiki.ros.org/urdf``). - Alternatively you can use your web browser to save the page's HTML. - -#. Next you need to remove the extraneous HTML in the file you downloaded - Using your browser's developer mode, find the name of the first useful HTML element in the Wiki page. - In most cases all of the HTML between the third line of the file, starting with the ```` tag, through the start of the first ``

`` tag can be safely removed. - In the case where there is a table of contents, the first useful tag may be an ``

`` tag. - Similarly, the ROS wiki contains some footer text that starts with ``
`` and ends just above ```` that can also be removed. - -#. Convert your html file by running a PanDoc conversion between HTML and restructured text. - The following command converts an HTML file to the equivalent reStructured text files: ``pandoc -f html -t rst urdf.html > URDF.rst``. - -#. Attempt to build your new documentation using the ``make html`` command. - There may be errors and warnings that you will need to address. - -#. **CAREFULLY** read through the entire page making sure the material is up to date for ROS 2. - Check every single link to make sure it points to the appropriate location on docs.ros.org. - Internal document references must be updated to point to the equivalent ROS 2 material. - Your updated document should not point to the ROS Wiki unless it is absolutely necessary. - This process may require you alter the document considerably, and you may need to pull multiple wiki files. - You should verify that every code sample in the document is working correctly under ROS 2. - -#. Find and download any images that may be in the old document. - The easiest way to do this is to right click in the browser and download all of the images. - Alternatively you can find images by searching for ```` tags in the HTML file. - -#. For each image files downloaded update the image file links to point to the correct image directory for the ROS Docs. - If any of the images require updating, or could be replaced with a `Mermaid `__ chart, please make this change. - Be aware that Mermaid.js is only supported in the core ROS 2 documentation currently. - -#. Once your document is complete add a table of contents to the top of your new rst document using the appropriate Sphinx commands. - This block should replace any existing table of contents from the old ROS Wiki. - -#. Issue your pull request. - Make sure to point to the original ROS Wiki file for reference. - -#. Once your pull request has been accepted please add a note to the top of the page on the original ROS Wiki article pointing to the new documentation page. - -For a real-world example of this process in action, please refer to the ROS 2 Image Processing Pipeline in both `the ROS 2 Docs `__ and in the original `ROS Wiki `__. -The completed documentation page can be found in the `ROS 2 package documentation for image_pipeline `__. - -Building the Site with GitHub Codespaces ----------------------------------------- -First, you need to have a GitHub account (if you don't have one, you can create one for free). -Then, you need to go to the `ROS 2 Documentation GitHub repository `__. -After that, you can open the repository in Codespaces, it can be done just by clicking on the "Code" button on the repository page, then choose "Open with Codespaces" from the dropdown menu. - -.. image:: images/codespaces.png - :width: 100% - :alt: Codespaces creation - -After that, you will be redirected to your Codespaces page, where you can see the progress of the Codespaces creation. -Once it is done, a Visual Studio Code tab will be opened in your browser. -You can open the terminal by clicking on the "Terminal" tab in the top panel or by pressing :kbd:`Ctrl-J`. - -In this terminal, you can run any command you want, for example, you can run the following command to build the site for just this branch: - -.. code-block:: console - - $ make html - -Finally, to view the site, you can click on the "Go Live" button in the right bottom panel and then, it will open the site in a new tab in your browser (you will need to browse to the ``build/html`` folder). - -.. image:: images/live_server.png - :width: 100% - :alt: Live Server - -Building the Site with Devcontainer ------------------------------------ - -`ROS 2 Documentation GitHub repository `__ also supports ``Devcontainer`` development environment with Visual Studio Code. -This will enable you to build the documentation much easier without changing your operating system. - -See :doc:`../../How-To-Guides/Setup-ROS-2-with-VSCode-and-Docker-Container` to install VS Code and Docker before the following procedure. - -Clone repository and start VS Code: - -.. code-block:: console - - $ git clone https://github.com/ros2/ros2_documentation - $ cd ./ros2_documentation - $ code . - -To use ``Devcontainer``, you need to install "Remote Development" Extension within VS Code search in Extensions (CTRL+SHIFT+X) for it. - -And then, use ``View->Command Palette...`` or ``Ctrl+Shift+P`` to open the command palette. -Search for the command ``Dev Containers: Reopen in Container`` and execute it. -This will build your development docker container for you automatically. - -To build the documentation, open a terminal using ``View->Terminal`` or ``Ctrl+Shift+``` and ``New Terminal`` in VS Code. -Inside the terminal, you can build the documentation: - -.. code-block:: console - - $ make html - -.. image:: images/vscode_devcontainer.png - :width: 100% - :alt: VS Code Devcontainer - -Writing pages -------------- - -The ROS 2 documentation website uses the ``reStructuredText`` format, which is the default plaintext markup language used by Sphinx. -This section is a brief introduction to ``reStructuredText`` concepts, syntax, and best practices. -When formatting your ``reStructuredText`` file **please make sure to write only one sentence per line as it makes reviewing and modifying your file much easier.** -Also, be mindful of the use of white space in your file! -The ROS 2 documentation linter will not accept pull requests with trailing white space. -We recommend that you enable automatic white space highlighting and or cleanup if your editor supports it. - -You can refer to `reStructuredText User Documentation `_ for a detailed technical specification. - -Table of Contents -^^^^^^^^^^^^^^^^^ - -There are two types of directives used for the generation of a table of contents, ``.. toctree::`` and ``.. contents::``. -The ``.. toctree::`` is used in top-level pages like ``Tutorials.rst`` to set ordering and visibility of its child pages. -This directive creates both left navigation panel and in-page navigation links to the child pages listed. -It helps readers to understand the structure of separate documentation sections and navigate between pages. - -.. code-block:: rst - - .. toctree:: - :maxdepth: 1 - -The ``.. contents::`` directive is used for the generation of a table of contents for that particular page. -It parses all present headings in a page and builds an in-page nested table of contents. -It helps readers to see an overview of the content and navigate inside a page. - -The ``.. contents::`` directive supports the definition of maximum depth of nested sections. -Using ``:depth: 2`` will only show Sections and Subsections in the table of contents. - -.. code-block:: rst - - .. contents:: Table of Contents - :depth: 2 - :local: - -Headings -^^^^^^^^ - -There are four main Heading types used in the documentation. -Note that the number of symbols has to match the length of the title. - -.. code-block:: rst - - Page Title Header - ================= - - Section Header - -------------- - - 2 Subsection Header - ^^^^^^^^^^^^^^^^^^^ - - 2.4 Subsubsection Header - ~~~~~~~~~~~~~~~~~~~~~~~~ - -We usually use one digit for numbering subsections and two digits (dot separated) for numbering subsubsections in Tutorials and How-To-Guides. - -Lists -^^^^^ - -Stars ``*`` are used for listing unordered items with bullet points and number sign ``#.`` is used for listing numbered items. -Both of them support nested definitions and will render accordingly. - -.. code-block:: rst - - * bullet point - - * bullet point nested - * bullet point nested - - * bullet point - -.. code-block:: rst - - #. first listed item - #. second lited item - -Code Formatting -^^^^^^^^^^^^^^^ - -In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. - -.. code-block:: rst - - In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. - -Code blocks inside a page need to be captured using ``.. code-block::`` `directives `_. -``.. code-block::`` supports code highlighting for syntaxes like ``C++``, ``YAML``, ``console``, ``bash``, and more. -Code inside the directive needs to be indented. - -.. code-block:: rst - - .. code-block:: C++ - - int main(int argc, char** argv) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -Code blocks: ``bash`` vs. ``console`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -``bash`` and ``console`` are similar, but they serve two different purposes. -Choosing the right one is important to ensure that the content is formatted correctly and that the copy button copies the right content. -Below is an explanation of each one; skip to the end of this section for a list of use-cases and corresponding examples. - -``bash`` is meant for scripts, e.g., for bash commands from a script file. -Example result: - -.. code-block:: bash - - export ROS_DOMAIN_ID=42 - ros2 run turtlesim turtlesim_node - -``console`` is meant for commands to be run in a terminal, optionally including their output. -This makes it clear that the given commands need to be run in a terminal. -It also allows separating command lines from output lines using prompt symbols such as ``$`` or ``#``. -Command lines are formatted as bash commands while output lines are formatted as normal text. -The prompt symbol is not selectable, and clicking on the copy button in the upper right-hand corner copies *only* the commands, not the outputs nor the prompt symbols. -This means that, if a ``console`` code block is used without any ``$``, the copy button will not copy any lines. -Example result: - -.. code-block:: console - - $ export ROS_DOMAIN_ID=42 - $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" - [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle - [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - -Compare the above with a ``bash`` ``code-block``: - -.. code-block:: bash - - $ export ROS_DOMAIN_ID=42 - $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" - [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle - [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - -To simplify code blocks, ``bash`` can still be used without ``$`` for commands meant to be run in a terminal if the code block does not include any output lines. -To help choose between ``bash`` and ``console``, see the following list of use-cases and corresponding examples: - -#. Commands meant to be copied into a script file - - * Use ``.. code-block:: bash`` without ``$``: - - .. code-block:: bash - - export ROS_DOMAIN_ID=42 - ros2 run turtlesim turtlesim_node - -#. Commands meant to be run in a terminal: - - * It is highly recommended to use ``.. code-block:: console`` with ``$`` on all command lines for consistency and clarity. - If there is output that needs to be displayed, include it in the same block: - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run turtlesim turtlesim_node - [INFO] [1743878028.269334696] [turtlesim]: Starting turtlesim with node name /turtlesim - [INFO] [1743878028.275096618] [turtlesim]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - - .. note:: - - If some output lines start with ``#``, it is crucial to separate commands from their output because the ``#`` symbol is used to denote a command. - Therefore, place the output in a separate ``.. code-block:: text``. - -Images -^^^^^^ - -Images can be inserted using the ``.. image::`` directive. - -.. code-block:: rst - - .. image:: images/turtlesim_follow1.png - -In this case, the image file (``turtlesim_follow1.png``) is located in the ``images/`` directory relative to the ``.rst`` file that uses the image. - -However, all image files end up in an ``_images/`` directory relative to the root of the docs. -Therefore, when using ``:target:`` to add a hyperlink to the image file, use a relative link going up to the root directory and then down to the ``_images/`` directory. - -.. code-block:: rst - - .. image:: images/turtlesim_follow1.png - :target: ../../_images/turtlesim_follow1.png - -Charts, Graphs, and Diagrams -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ROS 2 Documentation now supports charts, graphs, and diagrams written using `Mermaid Charts. `__ -We prefer that charts, graphs, and diagrams use Mermaid instead of static image files as it allows us to programmatically update and edit these resources as the project evolves. -Full documentation of the `Mermaid graph language syntax can be found on their website. `__ - -References and Links -^^^^^^^^^^^^^^^^^^^^ - -External links -~~~~~~~~~~~~~~ - -The syntax of creating links to external web pages is shown below. - -.. code-block:: rst - - `ROS Docs `_ - -The above link will appear as `ROS Docs `_. -Note the underscore after the final single quote. - -Internal links -~~~~~~~~~~~~~~ - -The ``:doc:`` directive is used to create in-text links to other pages. - -.. code-block:: rst - - :doc:`Quality of Service <../Tutorials/Quality-of-Service>` - -Note that the relative path to the file is used. - -The ``ref`` directive is used to make links to specific parts of a page. -These could be headings, images or code sections inside the current or different page. - -Definition of explicit target right before the desired object is required. -In the example below, the target is defined as ``_talker-listener`` one line before the heading ``Try some examples``. - -.. code-block:: rst - - .. _talker-listener: - - Try some examples - ----------------- - -Now the link from any page in the documentation to that header can be created. - -.. code-block:: rst - - :ref:`talker-listener demo ` - -This link will navigate a reader to the target page with an HTML anchor link ``#talker-listener``. - -Macros -~~~~~~ - -Macros can be used to simplify writing documentation that targets multiple distributions. - -Use a macro by including the macro name in curly braces. -For example, when generating the docs for Rolling on the ``rolling`` branch: - -.. list-table:: - :header-rows: 1 - - * - Macro - - Example - - Becomes (for {DISTRO_TITLE}) - * - \{DISTRO\} - - ros-\{DISTRO\}-pkg - - ros-{DISTRO}-pkg - * - \{DISTRO_TITLE\} - - ROS 2 \{DISTRO_TITLE\} - - ROS 2 {DISTRO_TITLE} - * - \{DISTRO_TITLE_FULL\} - - ROS 2 \{DISTRO_TITLE_FULL\} - - ROS 2 {DISTRO_TITLE_FULL} - * - \{REPOS_FILE_BRANCH\} - - git checkout \{REPOS_FILE_BRANCH\} - - git checkout {REPOS_FILE_BRANCH} - * - \{interface_link(std_msgs/msg/String)\} - - See: \{interface_link(std_msgs/msg/String)\}. - - See: {interface_link(std_msgs/msg/String)}. - * - \{interface(std_msgs/msg/String)\} - - Publish a \{interface(std_msgs/msg/String)\}. - - Publish a {interface(std_msgs/msg/String)}. - * - \{package_link(rclcpp)\} - - See: \{package_link(rclcpp)\}. - - See: {package_link(rclcpp)}. - * - \{package(rclcpp)\} - - Use \{package(rclcpp)\}. - - Use {package(rclcpp)}. - -The same file can be used on multiple branches (i.e., for multiple distros) and the generated content will be distro-specific. +.. redirect-from:: + + Contributing/Contributing-To-ROS-2-Documentation + +Contributing to ROS 2 Documentation +=================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Contributions to this site are most welcome. +This page explains how to contribute to ROS 2 Documentation. +Please be sure to read the below sections carefully before contributing. + +The site is built using `Sphinx `_, and more particularly using `Sphinx multiversion `_. + +Branch structure +---------------- + +The source code of documentation is located in the `ROS 2 Documentation GitHub repository `_. +This repository is set up with one branch per ROS 2 distribution to handle differences between the distributions. +If a change is common to all ROS 2 distributions, it should be made to the ``rolling`` branch (and then will be backported as appropriate). +If a change is specific to a particular ROS 2 distribution, it should be made to the respective branch. + +Source structure +---------------- + +The source files for the site are all located under the ``source`` subdirectory. +Templates for various sphinx plugins are located under ``source/_templates``. +The root directory contains configuration and files required to locally build the site for testing. + +Building the site locally +------------------------- + +Start by creating `venv `__ to build the documentation: + +.. code-block:: console + + $ python3 -m venv ros2doc # create venv + $ source ros2doc/bin/activate # activate venv + +And install requirements located in the ``requirements.txt`` file: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ pip install -r requirements.txt -c constraints.txt + + .. group-tab:: macOS + + .. code-block:: console + + $ pip install -r requirements.txt -c constraints.txt + + .. group-tab:: Windows + + .. code-block:: console + + $ python -m pip install -r requirements.txt -c constraints.txt + +In order for Sphinx to be able to generate diagrams, the ``dot`` command must be available. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ sudo apt update ; sudo apt install graphviz + + .. group-tab:: macOS + + .. code-block:: console + + $ brew install graphviz + + .. group-tab:: Windows + + Download an installer from `the Graphviz Download page `__ and install it. + Make sure to allow the installer to add it to the Windows ``%PATH%``, otherwise Sphinx will not be able to find it. + +Building the site for one branch +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build the site for just this branch, type ``make html`` at the top-level of the repository. +This is the recommended way to test out local changes. + +.. code-block:: console + + $ make html + +The build process can take some time. +To see the output, open ``build/html/index.html`` in your browser. + + +Checking / Testing the site +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can run the documentation tests locally (using `doc8 `_) with the following command: + +.. code-block:: console + + $ make test + +You can run the Python documentation tools tests locally (using `pytest `_) with the following command: + +.. code-block:: console + + $ make test-tools + +You can run the documentation linter locally (using `sphinx-lint `_) with the following command: + +.. code-block:: console + + $ make lint + +You can run the documentation spell checker locally (using `codespell `_) with the following command: + +.. code-block:: console + + $ make spellcheck + +.. note:: + + If that detects specific words that need to be ignored, add it to `codespell_whitelist `_ . + +To know more about spelling checks, refer to :ref:`Spelling check ` + +View Site Through Github CI +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For small changes to the ROS 2 Docs you can view your changes as rendered HTML using artifacts generated in our Github Actions. +The "build" action produces the entire ROS Docs as a downloadable Zip file that contains all HTML for `docs.ros.org `_ +This build action is triggered after passing the test action and lint action. + +To download and view your changes first go to your pull request and under the title click the "Checks" tab. +On the left hand side of the checks page, click on the "Test" section under the "tests" section click on "build" dialog. +This will open a menu on the right, where you can click on "Upload document artifacts" and scroll to the bottom to see the download link for the Zipped' HTML files under the heading "Artifact download URL". + +.. image:: ./images/github_action.png + :width: 100% + :alt: Steps to find rendered HTML files on ROS Github action + +Building the site for all branches +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build the site for all branches, type ``make multiversion`` from the ``rolling`` branch. +This has two drawbacks: + +#. The multiversion plugin doesn't understand how to do incremental builds, so it always rebuilds everything. + This can be slow. + +#. When typing ``make multiversion``, it will always check out exactly the branches listed in the ``conf.py`` file. + That means that local changes will not be shown. + +To show local changes in the multiversion output, you must first commit the changes to a local branch. +Then you must edit the `conf.py `_ file and change the ``smv_branch_whitelist`` variable to point to your branch. + +Checking for broken links +^^^^^^^^^^^^^^^^^^^^^^^^^ + +To check for broken links on the site, run: + +.. code-block:: console + + $ make linkcheck + +This will check the entire site for broken links, and output the results to the screen and ``build/linkcheck``. + +.. _spelling-check: + +Spelling check +^^^^^^^^^^^^^^ + +The ``make spellcheck`` command scans the documentation files and flags any misspellings. +If errors are detected, review the suggestions and update the pull request as necessary. + +Some words, such as technical terms or proper nouns, maybe mistakenly flagged as misspelled. +If you encounter such instances, you can add them to the ignore list to prevent them from being flagged in the future. +To do this, add it to the `codespell_whitelist `_ file as follows: + +.. code-block:: text + + empy + jupyter + lets + ws + +To include custom corrections that ``codespell`` should apply, you can add them to the `codespell_dictionary `_ file as follows: + +.. code-block:: text + + amnet->ament + colcn->colcon + rosabg->rosbag + rosdistroy->rosdistro + +To check the dictionaries, you can run the ``make check-dictionaries`` command. +This will check the blank lines and leading/trailing spaces in the dictionaries. +If it complains about the dictionaries, you can run the ``make sort-dictionaries`` command. +This command will automatically modify the dictionaries if any issues are found. + +Migrating Pages from the ROS Wiki +--------------------------------- + +The first step in migrating a page from the `ROS Wiki `_ to the ROS 2 documentation is to determine if the page needs to be migrated. +Check if the content, or something similar, is available on https://docs.ros.org/en/rolling by searching for related terms. +If it has already been migrated, congratulations! +You are done. +If it hasn't been migrated, then consider whether it is worth keeping. +Pages that you or others find useful, and refer to regularly, are good candidates assuming they have not been superseded by other documentation. +Pages for ROS projects and features that are no longer supported by a current distribution should not be migrated. + +The next step for migrating a ROS Wiki page is to determine the correct location for the migrated page. +Only ROS Wiki pages that cover core ROS concepts belong in the ROS Documentation, these pages should be migrated to a logical location within the ROS documentation. +Package specific documentation should be migrated to the package-level documentation generated in the package's source repository. +Once the package level documentation has been updated it will be visible `as part of the package-level documentation `__. +If you are unsure whether and where to migrate a page, please get in touch via an issue on https://github.com/ros2/ros2_documentation or on https://discourse.openrobotics.org/. + +Once you've determined that a ROS Wiki page is worth migrating, and found an appropriate landing spot in the ROS documentation, the next step in the migration process is to set up the conversion tools necessary to migrate the page. +In most cases the only tools necessary to migrate a single ROS Wiki page to the ROS Docs are the `PanDoc `_ command line tool and a text editor. +PanDoc is supported by most modern operating systems using the installation instruction found on their website. +It is worth noting that the ROS Wiki uses an older wiki technology (MoinMoin), so the markup language used is an obscure dialect of the `MediaWiki `__ format. +We've found that the easiest way to migrate a page from the ROS Wiki is to convert it from HTML into reStructured text using PanDoc. + + +Migrating a Wiki File +^^^^^^^^^^^^^^^^^^^^^ + +#. Clone the appropriate repository. + If you are migrating a page to the official documentation hosted here, then you should clone https://github.com/ros2/ros2_documentation. + +#. Create a new Github branch for your migrated page. + We suggest something like ``pagename-migration``. + +#. Download the appropriate ROS Wiki page to an html file using wget or a similar tool (e.g. ``wget -O urdf.html https://wiki.ros.org/urdf``). + Alternatively you can use your web browser to save the page's HTML. + +#. Next you need to remove the extraneous HTML in the file you downloaded + Using your browser's developer mode, find the name of the first useful HTML element in the Wiki page. + In most cases all of the HTML between the third line of the file, starting with the ```` tag, through the start of the first ``

`` tag can be safely removed. + In the case where there is a table of contents, the first useful tag may be an ``

`` tag. + Similarly, the ROS wiki contains some footer text that starts with ``
`` and ends just above ```` that can also be removed. + +#. Convert your html file by running a PanDoc conversion between HTML and restructured text. + The following command converts an HTML file to the equivalent reStructured text files: ``pandoc -f html -t rst urdf.html > URDF.rst``. + +#. Attempt to build your new documentation using the ``make html`` command. + There may be errors and warnings that you will need to address. + +#. **CAREFULLY** read through the entire page making sure the material is up to date for ROS 2. + Check every single link to make sure it points to the appropriate location on docs.ros.org. + Internal document references must be updated to point to the equivalent ROS 2 material. + Your updated document should not point to the ROS Wiki unless it is absolutely necessary. + This process may require you alter the document considerably, and you may need to pull multiple wiki files. + You should verify that every code sample in the document is working correctly under ROS 2. + +#. Find and download any images that may be in the old document. + The easiest way to do this is to right click in the browser and download all of the images. + Alternatively you can find images by searching for ```` tags in the HTML file. + +#. For each image files downloaded update the image file links to point to the correct image directory for the ROS Docs. + If any of the images require updating, or could be replaced with a `Mermaid `__ chart, please make this change. + Be aware that Mermaid.js is only supported in the core ROS 2 documentation currently. + +#. Once your document is complete add a table of contents to the top of your new rst document using the appropriate Sphinx commands. + This block should replace any existing table of contents from the old ROS Wiki. + +#. Issue your pull request. + Make sure to point to the original ROS Wiki file for reference. + +#. Once your pull request has been accepted please add a note to the top of the page on the original ROS Wiki article pointing to the new documentation page. + +For a real-world example of this process in action, please refer to the ROS 2 Image Processing Pipeline in both `the ROS 2 Docs `__ and in the original `ROS Wiki `__. +The completed documentation page can be found in the `ROS 2 package documentation for image_pipeline `__. + +Building the Site with GitHub Codespaces +---------------------------------------- +First, you need to have a GitHub account (if you don't have one, you can create one for free). +Then, you need to go to the `ROS 2 Documentation GitHub repository `__. +After that, you can open the repository in Codespaces, it can be done just by clicking on the "Code" button on the repository page, then choose "Open with Codespaces" from the dropdown menu. + +.. image:: images/codespaces.png + :width: 100% + :alt: Codespaces creation + +After that, you will be redirected to your Codespaces page, where you can see the progress of the Codespaces creation. +Once it is done, a Visual Studio Code tab will be opened in your browser. +You can open the terminal by clicking on the "Terminal" tab in the top panel or by pressing :kbd:`Ctrl-J`. + +In this terminal, you can run any command you want, for example, you can run the following command to build the site for just this branch: + +.. code-block:: console + + $ make html + +Finally, to view the site, you can click on the "Go Live" button in the right bottom panel and then, it will open the site in a new tab in your browser (you will need to browse to the ``build/html`` folder). + +.. image:: images/live_server.png + :width: 100% + :alt: Live Server + +Building the Site with Devcontainer +----------------------------------- + +`ROS 2 Documentation GitHub repository `__ also supports ``Devcontainer`` development environment with Visual Studio Code. +This will enable you to build the documentation much easier without changing your operating system. + +See :doc:`../../Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container` to install VS Code and Docker before the following procedure. + +Clone repository and start VS Code: + +.. code-block:: console + + $ git clone https://github.com/ros2/ros2_documentation + $ cd ./ros2_documentation + $ code . + +To use ``Devcontainer``, you need to install "Remote Development" Extension within VS Code search in Extensions (CTRL+SHIFT+X) for it. + +And then, use ``View->Command Palette...`` or ``Ctrl+Shift+P`` to open the command palette. +Search for the command ``Dev Containers: Reopen in Container`` and execute it. +This will build your development docker container for you automatically. + +To build the documentation, open a terminal using ``View->Terminal`` or ``Ctrl+Shift+``` and ``New Terminal`` in VS Code. +Inside the terminal, you can build the documentation: + +.. code-block:: console + + $ make html + +.. image:: images/vscode_devcontainer.png + :width: 100% + :alt: VS Code Devcontainer + +Writing pages +------------- + +The ROS 2 documentation website uses the ``reStructuredText`` format, which is the default plaintext markup language used by Sphinx. +This section is a brief introduction to ``reStructuredText`` concepts, syntax, and best practices. +When formatting your ``reStructuredText`` file **please make sure to write only one sentence per line as it makes reviewing and modifying your file much easier.** +Also, be mindful of the use of white space in your file! +The ROS 2 documentation linter will not accept pull requests with trailing white space. +We recommend that you enable automatic white space highlighting and or cleanup if your editor supports it. + +You can refer to `reStructuredText User Documentation `_ for a detailed technical specification. + +Table of Contents +^^^^^^^^^^^^^^^^^ + +There are two types of directives used for the generation of a table of contents, ``.. toctree::`` and ``.. contents::``. +The ``.. toctree::`` is used in top-level pages like ``Tutorials.rst`` to set ordering and visibility of its child pages. +This directive creates both left navigation panel and in-page navigation links to the child pages listed. +It helps readers to understand the structure of separate documentation sections and navigate between pages. + +.. code-block:: rst + + .. toctree:: + :maxdepth: 1 + +The ``.. contents::`` directive is used for the generation of a table of contents for that particular page. +It parses all present headings in a page and builds an in-page nested table of contents. +It helps readers to see an overview of the content and navigate inside a page. + +The ``.. contents::`` directive supports the definition of maximum depth of nested sections. +Using ``:depth: 2`` will only show Sections and Subsections in the table of contents. + +.. code-block:: rst + + .. contents:: Table of Contents + :depth: 2 + :local: + +Headings +^^^^^^^^ + +There are four main Heading types used in the documentation. +Note that the number of symbols has to match the length of the title. + +.. code-block:: rst + + Page Title Header + ================= + + Section Header + -------------- + + 2 Subsection Header + ^^^^^^^^^^^^^^^^^^^ + + 2.4 Subsubsection Header + ~~~~~~~~~~~~~~~~~~~~~~~~ + +We usually use one digit for numbering subsections and two digits (dot separated) for numbering subsubsections in Tutorials and How-To-Guides. + +Lists +^^^^^ + +Stars ``*`` are used for listing unordered items with bullet points and number sign ``#.`` is used for listing numbered items. +Both of them support nested definitions and will render accordingly. + +.. code-block:: rst + + * bullet point + + * bullet point nested + * bullet point nested + + * bullet point + +.. code-block:: rst + + #. first listed item + #. second lited item + +Code Formatting +^^^^^^^^^^^^^^^ + +In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. + +.. code-block:: rst + + In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. + +Code blocks inside a page need to be captured using ``.. code-block::`` `directives `_. +``.. code-block::`` supports code highlighting for syntaxes like ``C++``, ``YAML``, ``console``, ``bash``, and more. +Code inside the directive needs to be indented. + +.. code-block:: rst + + .. code-block:: C++ + + int main(int argc, char** argv) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +Code blocks: ``bash`` vs. ``console`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +``bash`` and ``console`` are similar, but they serve two different purposes. +Choosing the right one is important to ensure that the content is formatted correctly and that the copy button copies the right content. +Below is an explanation of each one; skip to the end of this section for a list of use-cases and corresponding examples. + +``bash`` is meant for scripts, e.g., for bash commands from a script file. +Example result: + +.. code-block:: bash + + export ROS_DOMAIN_ID=42 + ros2 run turtlesim turtlesim_node + +``console`` is meant for commands to be run in a terminal, optionally including their output. +This makes it clear that the given commands need to be run in a terminal. +It also allows separating command lines from output lines using prompt symbols such as ``$`` or ``#``. +Command lines are formatted as bash commands while output lines are formatted as normal text. +The prompt symbol is not selectable, and clicking on the copy button in the upper right-hand corner copies *only* the commands, not the outputs nor the prompt symbols. +This means that, if a ``console`` code block is used without any ``$``, the copy button will not copy any lines. +Example result: + +.. code-block:: console + + $ export ROS_DOMAIN_ID=42 + $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" + [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle + [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + +Compare the above with a ``bash`` ``code-block``: + +.. code-block:: bash + + $ export ROS_DOMAIN_ID=42 + $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" + [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle + [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + +To simplify code blocks, ``bash`` can still be used without ``$`` for commands meant to be run in a terminal if the code block does not include any output lines. +To help choose between ``bash`` and ``console``, see the following list of use-cases and corresponding examples: + +#. Commands meant to be copied into a script file + + * Use ``.. code-block:: bash`` without ``$``: + + .. code-block:: bash + + export ROS_DOMAIN_ID=42 + ros2 run turtlesim turtlesim_node + +#. Commands meant to be run in a terminal: + + * It is highly recommended to use ``.. code-block:: console`` with ``$`` on all command lines for consistency and clarity. + If there is output that needs to be displayed, include it in the same block: + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run turtlesim turtlesim_node + [INFO] [1743878028.269334696] [turtlesim]: Starting turtlesim with node name /turtlesim + [INFO] [1743878028.275096618] [turtlesim]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + + .. note:: + + If some output lines start with ``#``, it is crucial to separate commands from their output because the ``#`` symbol is used to denote a command. + Therefore, place the output in a separate ``.. code-block:: text``. + +Images +^^^^^^ + +Images can be inserted using the ``.. image::`` directive. + +.. code-block:: rst + + .. image:: images/turtlesim_follow1.png + +In this case, the image file (``turtlesim_follow1.png``) is located in the ``images/`` directory relative to the ``.rst`` file that uses the image. + +However, all image files end up in an ``_images/`` directory relative to the root of the docs. +Therefore, when using ``:target:`` to add a hyperlink to the image file, use a relative link going up to the root directory and then down to the ``_images/`` directory. + +.. code-block:: rst + + .. image:: images/turtlesim_follow1.png + :target: ../../_images/turtlesim_follow1.png + +Charts, Graphs, and Diagrams +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ROS 2 Documentation now supports charts, graphs, and diagrams written using `Mermaid Charts. `__ +We prefer that charts, graphs, and diagrams use Mermaid instead of static image files as it allows us to programmatically update and edit these resources as the project evolves. +Full documentation of the `Mermaid graph language syntax can be found on their website. `__ + +References and Links +^^^^^^^^^^^^^^^^^^^^ + +External links +~~~~~~~~~~~~~~ + +The syntax of creating links to external web pages is shown below. + +.. code-block:: rst + + `ROS Docs `_ + +The above link will appear as `ROS Docs `_. +Note the underscore after the final single quote. + +Internal links +~~~~~~~~~~~~~~ + +The ``:doc:`` directive is used to create in-text links to other pages. + +.. code-block:: rst + + :doc:`Quality of Service <../Tutorials/Quality-of-Service>` + +Note that the relative path to the file is used. + +The ``ref`` directive is used to make links to specific parts of a page. +These could be headings, images or code sections inside the current or different page. + +Definition of explicit target right before the desired object is required. +In the example below, the target is defined as ``_talker-listener`` one line before the heading ``Try some examples``. + +.. code-block:: rst + + .. _talker-listener: + + Try some examples + ----------------- + +Now the link from any page in the documentation to that header can be created. + +.. code-block:: rst + + :ref:`talker-listener demo ` + +This link will navigate a reader to the target page with an HTML anchor link ``#talker-listener``. + +Macros +~~~~~~ + +Macros can be used to simplify writing documentation that targets multiple distributions. + +Use a macro by including the macro name in curly braces. +For example, when generating the docs for Rolling on the ``rolling`` branch: + +.. list-table:: + :header-rows: 1 + + * - Macro + - Example + - Becomes (for {DISTRO_TITLE}) + * - \{DISTRO\} + - ros-\{DISTRO\}-pkg + - ros-{DISTRO}-pkg + * - \{DISTRO_TITLE\} + - ROS 2 \{DISTRO_TITLE\} + - ROS 2 {DISTRO_TITLE} + * - \{DISTRO_TITLE_FULL\} + - ROS 2 \{DISTRO_TITLE_FULL\} + - ROS 2 {DISTRO_TITLE_FULL} + * - \{REPOS_FILE_BRANCH\} + - git checkout \{REPOS_FILE_BRANCH\} + - git checkout {REPOS_FILE_BRANCH} + * - \{interface_link(std_msgs/msg/String)\} + - See: \{interface_link(std_msgs/msg/String)\}. + - See: {interface_link(std_msgs/msg/String)}. + * - \{interface(std_msgs/msg/String)\} + - Publish a \{interface(std_msgs/msg/String)\}. + - Publish a {interface(std_msgs/msg/String)}. + * - \{package_link(rclcpp)\} + - See: \{package_link(rclcpp)\}. + - See: {package_link(rclcpp)}. + * - \{package(rclcpp)\} + - Use \{package(rclcpp)\}. + - Use {package(rclcpp)}. + +The same file can be used on multiple branches (i.e., for multiple distros) and the generated content will be distro-specific. diff --git a/source/The-ROS2-Project/Contributing/Developer-Guide.rst b/source/The-ROS2-Project/Contributing/Developer-Guide.rst index a35cef0b5ea..cc4d84902d6 100644 --- a/source/The-ROS2-Project/Contributing/Developer-Guide.rst +++ b/source/The-ROS2-Project/Contributing/Developer-Guide.rst @@ -1,922 +1,922 @@ -.. redirect-from:: - - Developer-Guide - Contributing/Developer-Guide - -ROS 2 developer guide -===================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page defines the practices and policies we employ when developing ROS 2. - -General Principles ------------------- - -Some principles are common to all ROS 2 development: - - -* **Shared ownership**: - Everybody working on ROS 2 should feel ownership over all parts of the system. - The original author of a chunk of code does not have any special permission or obligation to control or maintain that chunk of code. - Everyone is free to propose changes anywhere, to handle any type of ticket, and to review any pull request. -* **Be willing to work on anything**: - As a corollary to shared ownership, everybody should be willing to take on any available task and contribute to any aspect of the system. -* **Ask for help**: - If you run into trouble on something, ask your fellow developers for help, via tickets, comments, or email, as appropriate. - -Quality Practices ------------------ - -Packages can ascribe to different levels of quality based on the development practices they adhere to, as per the guidelines in `REP 2004: Package Quality Categories `_. -The categories are differentiated by their policies on versioning, testing, documentation, and more. - -The following sections are the specific development rules we follow to ensure core packages are of the highest quality ('Level 1'). -We recommend all ROS developers strive to adhere to the following policies to ensure quality across the ROS ecosystem. - -For more specific code recommendations please see :doc:`the Quality Guide `. - -.. _semver: - -Versioning -^^^^^^^^^^ - -We will use the `Semantic Versioning guidelines `__ (``semver``) for versioning. - -We will also adhere to some ROS-specific rules built on top of ``semver's`` full meaning: - -* Major version increments (i.e. breaking changes) should not be made within a released ROS distribution. - - * Patch (interface-preserving) and minor (non-breaking) version increments do not break compatibility, so these sorts of changes *are* allowed within a release. - - * Major ROS releases are the best time to release breaking changes. - If a core package needs multiple breaking changes, they should be merged into their integration branch (e.g. rolling) to allow catching problems in CI quickly, but released together to reduce the number of major releases for ROS users. - - * Though major increments require a new distribution, a new distribution does not necessarily require a major bump (if development and release can happen without breaking API). - -* For compiled code, the ABI is considered part of the public interface. - Any change that requires recompiling dependent code is considered major (breaking). - - * ABI breaking changes *can* be made in a minor version bump *before* a distribution release (getting added to the rolling release). - -* We enforce API stability for core packages in Dashing and Eloquent even though their major version components are ``0``, despite `SemVer's specification `_ regarding initial development. - - * Subsequently, packages should strive to reach a mature state and increase to version ``1.0.0`` so to match ``semver's`` specifications. - -Caveats -~~~~~~~ - -These rules are *best-effort*. -In unlikely, extreme cases, it may be necessary to break API within a major version/distribution. -Whether an unplanned break increments the major or minor version will be assessed on a case-by-case basis. - -For example, consider a situation involving released X-turtle, corresponding to major version ``1.0.0``, and released Y-turtle, corresponding to major version ``2.0.0``. - -If an API-breaking fix is identified to be absolutely necessary in X-turtle, bumping to ``2.0.0`` is obviously not an option because ``2.0.0`` already exists. - -The solutions for handling X-turtle's version in such a case, both non-ideal, are: - -1. Bumping X-turtle's minor version: non-ideal because it violates SemVer's principle that breaking changes must bump the major version. - -2. Bumping X-turtle's major version past Y-turtle (to ``3.0.0``): non-ideal because the older distro's version would become higher than the already-available version of a newer distro, which would invalidate/break version-specific conditional code. - -The developer will have to decide which solution to use, or more importantly, which principle they are willing to break. -We cannot suggest one or the other, but in either case we do require that explicit measures be taken to communicate the disruption and its explanation to users manually (beyond just the version increment). - -If there were no Y-turtle, even though the fix would technically just be a patch, X-turtle would have to bump to ``2.0.0``. -This case adheres to SemVer, but breaks from our own rule that major increments should not be introduced in a released distribution. - -This is why we consider the versioning rules *best-effort*. -As unlikely as the examples above are, it is important to accurately define our versioning system. - -Public API declaration -~~~~~~~~~~~~~~~~~~~~~~ - -According to ``semver``, every package must clearly declare a public API. -We will use the "Public API Declaration" section of the quality declaration of a package to declare what symbols are part of the public API. - -For most C and C++ packages the declaration is any header that it installs. -However, it is acceptable to define a set of symbols which are considered private. -Avoiding private symbols in headers can help with ABI stability, but is not required. - -For other languages like Python, a public API must be explicitly defined, so that it is clear what symbols can be relied on with respect to the versioning guidelines. -The public API can also be extended to build artifacts like configuration variables, CMake config files, etc. as well as executables and command-line options and output. -Any elements of the public API should be clearly stated in the package's documentation. -If something you are using is not explicitly listed as part of the public API in the package's documentation, then you cannot depend on it not changing between minor or patch versions. - -Deprecation strategy -~~~~~~~~~~~~~~~~~~~~ - -Where possible, we will also use the tick-tock deprecation and migration strategy for major version increments. -New deprecations will come in a new distribution release, accompanied by compiler warnings expressing that the functionality is being deprecated. -In the next release, the functionality will be completely removed (no warnings). - -Example of function ``foo`` deprecated and replaced by function ``bar``: - -========= ======================================================== - Version API -========= ======================================================== -X-turtle void foo(); -Y-turtle [[deprecated("use bar()")]] void foo();
void bar(); -Z-turtle void bar(); -========= ======================================================== - -We must not add deprecations after a distribution is released. -Deprecations do not necessarily require a major version bump, though. -A deprecation can be introduced in a minor version bump if the bump happens before the distro is released (similar to ABI breaking changes). - -For example, if X-turtle begins development as ``2.0.0``, a deprecation can be added in ``2.1.0`` before X-turtle is released. - -We will attempt to maintain compatibility across distros as much as possible. -However, like the caveats associated with SemVer, tick-tock or even deprecation in general may be impossible to completely adhere to in certain cases. - -Change control process -^^^^^^^^^^^^^^^^^^^^^^ - -* All changes must go through a pull request. - -* We will enforce the `Developer Certificate of Origin (DCO) `_ on pull requests in ROSCore repositories. - - * It requires all commit messages to contain the ``Signed-off-by`` line with an email address that matches the commit author. - - * You can pass ``-s`` / ``--signoff`` to the ``git commit`` invocation or write the expected message manually (e.g. ``Signed-off-by: Your Name Developer ``). - - * DCO is *not* required for pull requests that only address whitespace removal, typo correction, and other `trivial changes `_. - -* Always run CI jobs for all `tier 1 platforms `_ for every pull request and include links to jobs in the pull request. - (If you don't have access to the Jenkins jobs someone will trigger the jobs for you.) - -* A minimum of 1 approval from a fellow developer who did not author the pull request is required to consider it approved. - Approval is required before merging. - - * Packages may choose to increase this number. - -* Any required changes to documentation (API documentation, feature documentation, release notes, etc.) must be proposed before merging related changes. - -Guidelines for backporting PRs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -When changing an older version of ROS: - -* Make sure the features or fixes are accepted and merged in the rolling branch before opening a PR to backport the changes to older versions. -* When backporting to older versions, also consider backporting to any other :doc:`still supported versions <../../Releases>`, even non-LTS versions. -* If you are backporting a single PR in its entirety, title the backport PR "[Distro] ". -* Link to all PRs whose changes you're backporting from the description of your backport PR. -* Package maintainers typically use `Mergifyio `_ to automatically backport PRs to downstream distributions when needed, however developers can still perform manual backporting operations as described above when necessary. - -Documentation -^^^^^^^^^^^^^ - -All packages should have these documentation elements present in their README or linked to from their README: - -* Description and purpose -* Definition and description of the public API -* Examples -* How to build and install (should reference external tools/workflows) -* How to build and run tests -* How to build documentation -* How to develop (useful for describing things like ``python setup.py develop``) -* License and copyright statements - -Each source file must have a license and copyright statement, checked with an automated linter. - -Each package must have a LICENSE file, typically the Apache 2.0 license, unless the package has an existing permissive license (e.g. rviz uses three-clause BSD). - -Each package should describe itself and its purpose assuming, as much as possible, that the reader has stumbled onto it without previous knowledge of ROS or other related projects. - -Each package should define and describe its public API so that there is a reasonable expectation for users about what is covered by the semantic versioning policy. -Even in C and C++, where the public API can be enforced by API and ABI checking, it is a good opportunity to describe the layout of the code and the function of each part of the code. - -It should be easy to take any package and from that package's documentation understand how to build, run, build and run tests, and build the documentation. -Obviously we should avoid repeating ourselves for common workflows, like building a package in a workspace, but the basic workflows should be either described or referenced. - -Finally, it should include any documentation for developers. -This might include workflows for testing the code using something like ``python setup.py develop``, or it might mean describing how to make use of extension points provided by your package. - -Examples: - -* `capabilities `_ - - * This one gives an example of docs which describe the public API - -* `catkin_tools `_ - - * This is an example of describing an extension point for a package - -API Documentation for ROS Packages -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -API documentation for all released ROS packages can be `found here `__. -We recommend using `index.ros.org `_ to search through available ROS packages to find their documentation. - -If you are a ROS package developer looking for guidance on documenting your package please see :doc:`our "how to" guide on package level documentation <../../How-To-Guides/Documenting-a-ROS-2-Package>`. -The documentation for all released ROS 2 packages is automatically hosted on `docs.ros.org `_. - -Testing -^^^^^^^ - -All packages should have some level of :ref:`system, integration, and/or unit tests.` - -**Unit tests** should always be in the package which is being tested and should make use of tools like ``Mock`` to try and test narrow parts of the codebase in constructed scenarios. -Unit tests should not bring in test dependencies that are not testing tools, e.g. gtest, nosetest, pytest, mock, etc... - -**Integration tests** can test interactions between parts of the code or between parts of the code and the system. -They often test software interfaces in ways that we expect the user to use them. -Like Unit tests, Integration tests should be in the package which is being tested and should not bring in non-tool test dependencies unless absolutely necessary, i.e. all non-tool dependencies should only be allowed under extreme scrutiny so they should be avoided if possible. - -**System tests** are designed to test end-to-end situations between packages and should be in their own packages to avoid bloating or coupling packages and to avoid circular dependencies. - -In general external or cross package test dependencies should be minimized to prevent circular dependencies and tightly coupled test packages. - -All packages should have some unit tests and possibly integration tests, but the degree to which they should have them is based on the package's quality category. -The following subsections apply to 'Level 1' packages: - -Code coverage -~~~~~~~~~~~~~ - -We will provide line coverage, and achieve line coverage above 95%. -If a lower percentage target is justifiable, it must be prominently documented. -We may provide branch coverage, or exclude code from coverage (test code, debug code, etc.). -We require that coverage increase or stay the same before merging a change, but it may be acceptable to make a change that decreases code coverage with proper justification (e.g. deleting code that was previously covered can cause the percentage to drop). - -Performance -~~~~~~~~~~~ - -We strongly recommend performance tests, but recognize they don't make sense for some packages. -If there are performance tests, we will choose to either check each change or before each release or both. -We will also require justification for merging a change or making a release that lowers performance. - -Linters and static analysis -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We will use :doc:`ROS code style ` and enforce it with linters from `ament_lint_common `_. -All linters/static analysis that are part of ``ament_lint_common`` must be used. - -The `ament_lint_auto `_ documentation provides information on running ``ament_lint_common``. - -General Practices ------------------ - -Some practices are common to all ROS 2 development. - -These practices don't affect package quality level as described in `REP 2004 `_, but are still highly recommended for the development process. - -Issues -^^^^^^ - -When filing an issue please make sure to: - -- Include enough information for another person to understand the issue. - In ROS 2, the following points are needed for narrowing down the cause of an issue. - Testing with as many alternatives in each category as feasible will be especially helpful. - - - **The operating system and version.** - Reasoning: ROS 2 supports multiple platforms, and some bugs are specific to particular versions of operating systems/compilers. - - **The installation method.** - Reasoning: Some issues only manifest if ROS 2 has been installed from binary archives or from debs. - This can help us determine if the issue is with the packaging process. - - **The specific version of ROS 2.** - Reasoning: Some bugs may be present in a particular ROS 2 release and later fixed. - It is important to know if your installation includes these fixes. - - **The DDS/RMW implementation being used** (see `this page <../../Concepts/Intermediate/About-Different-Middleware-Vendors>` for how to determine which one). - Reasoning: Communication issues may be specific to the underlying ROS middleware being used. - - **The ROS 2 client library being used.** - Reasoning: This helps us narrow down the layer in the stack at which the issue might be. - -- Include a list of steps to reproduce the issue. -- In case of a bug consider to provide a `short, self contained, correct (compilable), example `__. - Issues are much more likely to be resolved if others can reproduce them easily. - -- Mention troubleshooting steps that have been tried already, including: - - - Upgrading to the latest version of the code, which may include bug fixes that have not been released yet. - See `this section ` and follow the instructions to get the "rolling" branches. - - Trying with a different RMW implementation. - See `this page <../../How-To-Guides/Working-with-multiple-RMW-implementations>` for how to do that. - -Branches -^^^^^^^^ - -.. note:: - These are just guidelines. - It is up to the package maintainer to choose branch names that match their own workflow. - -It is good practice to have **separate branches** in a package's source repository for each ROS distribution it is targeting. -These branches are typically named after the distribution they target. -For example, a ``humble`` branch for development targeted specifically at the Humble distribution. - -Releases are also made from these branches, targeting the appropriate distribution. -Development targeted at a specific ROS distribution can happen on the appropriate branch. -For example: Development commits targeting ``foxy`` are made to the ``foxy`` branch, and package releases for ``foxy`` are made from that same branch. - -.. note:: - This requires the package maintainers to perform backports or forwardports as appropriate to keep all branches up to date with features. - The maintainers must also perform general maintenance (bug fixes, etc.) on all branches from which package releases are still made. - - For example, if a feature is merged into the Rolling-specific branch (e.g. ``rolling`` or ``main``), and that feature is also appropriate - to the Humble distribution (does not break API, etc.), then it is good practice to backport the feature to the Humble-specific branch. - - The maintainers may make releases for those older distributions if there are new features or bug fixes available. - -**What about** ``main`` **and** ``rolling`` **?** - -``main`` typically targets :doc:`Rolling <../../Releases/Release-Rolling-Ridley>` (and so, the next unreleased ROS distribution), though the maintainers may decide to develop and release from a ``rolling`` branch instead. - -Pull requests -^^^^^^^^^^^^^ - -* A pull request should only focus on one change. - Separate changes should go into separate pull requests. - See `GitHub's guide to writing the perfect pull request `__. - -* A patch should be minimal in size and avoid any kind of unnecessary changes. - -* A pull request must contain minimum number of meaningful commits. - - * You can create new commits while the pull request is under review. - -* Before merging a pull request all changes should be squashed into a small number of semantic commits to keep the history clear. - - * But avoid squashing commits while a pull request is under review. - Your reviewers might not notice that you made the change, thereby introducing potential for confusion. - Plus, you're going to squash before merging anyway; there's no benefit to doing it early. - -* Any developer is welcome to review and approve a pull request (see `General Principles`_). - -* When you are working on a change that is not ready for review or to be merged, use a draft pull request. - When that change is ready for review, move the pull request out of the draft state. - Note that if you want early feedback from specific people on a draft pull request, you can @ mention them in the pull request's description or in a comment on the pull request. - -* If your pull request depends on other pull requests, link to each depended on pull request by adding ``- Depends on `` at the top of your pull request's description. - Doing so helps reviewers understand the context of the pull request. - -* When you start reviewing a pull request, comment on the pull request so that other developers know that you're reviewing it. - -* Pull-request review is not read-only, with the reviewer making comments and then waiting for the author to address them. - As a reviewer, feel free to make minor improvements (typos, style issues, etc.) in-place. - As the opener of a pull-request, if you are working in a fork, checking the box to `allow edits from upstream contributors `__ will assist with the aforementioned. - As a reviewer, also feel free to make more substantial improvements, but consider putting them in a separate branch (either mention the new branch in a comment, or open another pull request from the new branch to the original branch). - -* Only maintainers and committers can merge approved pull requests into the mainline. - See the :doc:`current ROS PMC constituents and committers <../Governance>` for the list of people with merge permissions. - -Library versioning -^^^^^^^^^^^^^^^^^^ - -We will version all libraries within a package together. -This means that libraries inherit their version from the package. -This keeps library and package versions from diverging and shares reasoning with the policy of releasing packages which share a repository together. -If you need libraries to have different versions then consider splitting them into different packages. - -Development process -^^^^^^^^^^^^^^^^^^^ - -* The default branch (in most cases the rolling branch) must always build, pass all tests and compile without warnings. - If at any time there is a regression it is the top priority to restore at least the previous state. -* Always build with tests enabled. -* Always run tests locally after changes and before proposing them in a pull request. - Besides using automated tests, also run the modified code path manually to ensure that the patch works as intended. -* Always run CI jobs for all platforms for every pull request and include links to the jobs in the pull request. - -For more details on recommended software development workflow, see `Software Development Lifecycle`_ section. - -Changes to RMW API -^^^^^^^^^^^^^^^^^^ - -When updating `RMW API `__, it is required that RMW implementations for the Tier 1 middleware libraries are updated as well. -For example, a new function ``rmw_foo()`` introduced to the RMW API must be implemented in the following packages (as of ROS Galactic): - -* `rmw_connextdds `__ -* `rmw_cyclonedds `__ -* `rmw_fastrtps `__ - -Updates for non-Tier 1 middleware libraries should also be considered if feasible (e.g. depending on the size of the change). -See `REP-2000 `__ for the list of middleware libraries and their tiers. - -Tracking tasks -^^^^^^^^^^^^^^ - -To help organize work on ROS 2, the core ROS 2 development team uses kanban-style `GitHub project boards `_. - -Not all issues and pull requests are tracked on the project boards, however. -A board usually represents an upcoming release or specific project. -Tickets can be browsed on a per-repo basis by browsing the `ROS 2 repositories' `_ individual issue pages. - -The names and purposes of columns in any given ROS 2 project board vary, but typically follow the same general structure: - -* **To do**: - Issues that are relevant to the project, ready to be assigned -* **In progress**: - Active pull requests on which work is currently in progress -* **In review**: - Pull requests where work is complete and ready for review, and for those currently under active review -* **Done**: - Pull requests and related issues are merged/closed (for informational purposes) - -To request permission to make changes, simply comment on the tickets you're interested in. -Depending on the complexity, it might be useful to describe how you plan to address it. -We will update the status (if you don't have the permission) and you can start working on a pull request. -If you contribute regularly we will likely just grant you permission to manage the labels etc. yourself. - -Package Naming Conventions -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Names play an important role in ROS and following naming conventions simplifies the process of learning and understanding large systems. - -The ROS packages occupy a flat namespace, so naming should be done carefully and consistently. -There is a standard for package naming in `REP-144 `__ - -* Package names should follow common C variable naming conventions: lower case, start with a letter, use underscore separators, e.g. laser_viewer - -* Package names should be specific enough to identify what the package does. - For example, a motion planner is not called planner. - If it implements the wavefront propagation algorithm, it might be called wavefront_planner. - There's obviously tension between making a name specific and keeping it from becoming overly verbose. - - * Using catchall names such as utils should be avoided as they do not scope what goes into the package or what should be outside the package. - -* To check whether a name is taken, consult ``__. - If you'd like your repository included in that list, see the `rosdistro Contributing Guide `__. - -* Our goal is to develop a canonical set of tools for making robots do interesting things. - The package name should tell you what the package does, not where it came from. - It should be possible for us, as a community, to make this work. - An Ubuntu distribution offers approximately 33,000 packages without inserting origin or authorship into names. - -* Prefixing a package name is recommended only when the package is not meant to be used more widely (e.g., packages that are specific to the PR2 robot use the ``pr2_`` prefix). - You might prefix the package name when forking an existing package, but again, the prefix would hopefully communicate what changed, not who changed it. - -* Prefixing a package name with 'ros' is redundant for a ROS package. - This is not recommended except for very core packages. - -Units of Measure and Coordinate System Conventions -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Standard units and coordinate conventions for use in ROS have been formalized in `REP-0103 `__. -All messages should follow these guidelines unless there's a very strong reason which is very clearly documented to avoid confusion. - -Representation of special conditions within distance measurements like "too close" or "too far" in ROS have been formalized in `REP-0117 `__. - -Programming conventions -^^^^^^^^^^^^^^^^^^^^^^^ - -* Defensive programming: ensure that assumptions are held as early as possible. - E.g. check every return code and make sure to at least throw an exception until the case is handled more gracefully. -* All error messages must be directed to ``stderr``. -* Declare variables in the narrowest scope possible. -* Keep group of items (dependencies, imports, includes, etc.) ordered alphabetically. - -C++ specific -~~~~~~~~~~~~ - -* Avoid using direct streaming (``<<``) to ``stdout`` / ``stderr`` to prevent interleaving between multiple threads. -* Avoid using references for ``std::shared_ptr`` since that subverts the reference counting. - If the original instance goes out of scope and the reference is being used it accesses freed memory. - -Filesystem layout -^^^^^^^^^^^^^^^^^ - -The filesystem layout of packages and repositories should follow the same conventions in order to provide a consistent experience for users browsing our source code. - -Package layout -~~~~~~~~~~~~~~ - -* ``src``: contains all C and C++ code - - * Also contains C/C++ headers which are not installed - -* ``include``: contains all C and C++ headers which are installed - - * ````: for all C and C++ installed headers they should be folder namespaced by the package name - -* ````: contains all Python code -* ``test``: contains all automated tests and test data -* ``config``: contains configuration files, e.g. YAML parameters files and RViz config files -* ``doc``: contains all the documentation -* ``launch``: contains all launch files -* ``msg``: contains all ROS Message definitions -* ``srv``: contains all ROS Service definitions -* ``action``: contains all ROS Action definitions -* ``package.xml``: as defined by `REP-0140 `_ (may be updated for prototyping) -* ``CMakeLists.txt``: only ROS packages which use CMake -* ``setup.py``: only ROS packages which use Python code only -* ``README``: can be rendered on GitHub as a landing page for the project - - * This can be as short or detailed as is convenient, but it should at least link to project documentation - * Consider putting a CI or code coverage tag in this README - * It can also be ``.rst`` or anything else that GitHub supports - -* ``CONTRIBUTING``: describes the contribution guidelines - - * This might include license implication, e.g. when using the Apache 2 License. - -* ``LICENSE``: a copy of the license or licenses for this package -* ``CHANGELOG.rst``: `REP-0132 `_ compliant changelog - -Repository layout -~~~~~~~~~~~~~~~~~ - -Each package should be in a subfolder which has the same name as the package. -If a repository contains only a single package it can optionally be in the root of the repository. - -Upstream Packages -^^^^^^^^^^^^^^^^^ - -Packages in Debian and Ubuntu Upstream -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Thanks to diligent effort from Jochen Sprickerhof and Leopold Palomo-Avellaneda, some of the `ROS 2 packages are now available `_ from the main Debian and Ubuntu repositories. -`Here is a short overview of the process from Jochen at ROSCon 2015 `_. -The original ROS packages have been modified to follow Debian guidelines, which includes splitting packages into multiple pieces, changing names in some cases, installing to /usr according to FHS guidelines, and using soversions on shared libraries. - -In addition several of the bootstrap dependencies such as command line tools like ``vcstool`` and ``colcon`` as well as some libraries like ``osrf-pycommon`` and ``ament`` are also packaged upstream. - -Unlike the OSRF-provided ROS packages from http://packages.ros.org, the packages in the upstream repositories are not attached to a specific :doc:`ROS distribution <../../Releases>`. -Rather, they represent a snapshot in time that will be updated periodically within Debian unstable and then latched at various points into downstream Debian and Ubuntu distributions. - -Don't mix the streams -~~~~~~~~~~~~~~~~~~~~~ - -We strongly recommend against mixing ROS packages from upstream Debian/Ubuntu and from http://packages.ros.org on the same system. -In some cases such a mixed system will work correctly, but there can be negative interactions between the two sets of packages. -We're working with Jochen and friends to minimize the chance of problems via documentation and package conflict specifications, but we expect some risks to remain, including some fairly subtle issues. - -As such, we recommend that you choose to either install packages from upstream or from http://packages.ros.org, but not both. -Not only should you not install packages from both at the same time, but if you intend to use the upstream packages then you should not even have the http://packages.ros.org entries in your apt sources (i.e. in any files in ``/etc/apt/sources*``). -Having both of them enabled can cause mixing of packages which overlap by name between the two sources, e.g. ``python3-rospkg``. - -Known Differences -~~~~~~~~~~~~~~~~~ - -As compared to the ROS packages from packages.ros.org, there are some differences in the upstream ROS packages that people should be aware of: - -* The package set is incomplete. -* Packages may have different names and be partitioned differently. - -Developer Workflow ------------------- - -We track open tickets and active PRs related to upcoming releases and larger projects using `GitHub project boards `_. - -The usual workflow is: - -* Discuss design (GitHub ticket on the appropriate repository, and a design PR to https://github.com/ros2/design if needed) -* Write implementation on a feature branch on a fork - - * Please check out the `developer guide ` for guidelines and best practices - -* Write tests -* Enable and run linters -* Run tests locally using ``colcon test`` (see the :doc:`colcon tutorial <../../Tutorials/Beginner-Client-Libraries/Colcon-Tutorial>`) -* Once everything builds locally without warnings and all tests are passing, run CI on your feature branch: - - * Go to ci.ros2.org - * Log in (top right corner) - * Click on the ``ci_launcher`` job - * Click "Build with Parameters" (left column) - * In the first box "CI_BRANCH_TO_TEST" enter your feature branch name - * Hit the ``build`` button - - (if you are not a ROS 2 committer, you don't have access to the CI farm. - In that case, ping the reviewer of your PR to run CI for you) - -* If your use case requires running code coverage: - - * Go to ci.ros2.org - * Log in (top right corner) - * Click on the ``ci_linux_coverage`` job - * Click "Build with Parameters" (left column) - * Be sure of leaving "CI_BUILD_ARGS" and "CI_TEST_ARGS" with the default values - * Hit the ``build`` button - * At the end of the document there are instructions on how to :ref:`interpret the result of the report ` and :ref:`calculate the coverage rate ` - -* If the CI job built without warnings, errors and test failures, post the links of your jobs on your PR or high-level ticket aggregating all your PRs (see example `here `__) - - * Note that the markdown for these badges is in the console output of the ``ci_launcher`` job - -* When the PR has been approved: - - * the person who submitted the PR merges it using "Squash and Merge" option so that we keep a clean history - - * If the commits deserve to keep separated: squash all the nitpick/linters/typo ones together and merge the remaining set - - * Note: each PR should target a specific feature so Squash and Merge should make sense 99% of the time - -* Delete the branch once merged - -Gitconfig Optimization -^^^^^^^^^^^^^^^^^^^^^^ - -To be able to push to repositories you will need to have ssh keys setup on your system. -However our default url schema for repositories is to use https because it's anonymously accessible. -On your system you can use the ``gitconfig`` option ``insteadOf`` to have ``git`` automatically use your ssh key even if the remote is declared as https. - -Add the following to your ``~/.gitconfig`` - -.. code-block:: - - [url "ssh://git@github.com/"] - insteadOf = https://github.com/ - -If you're working on repositories on GitLab or Bitbucket you can do the same thing. - - -Architectural Development Practices ------------------------------------ - -This section describes the ideal lifecycle that should be employed when making large architectural changes to ROS 2. - -Software Development Lifecycle -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This section describes step-by-step how to plan, design, and implement a new feature: - -1. Task Creation -2. Creating the Design Document -3. Design Review -4. Implementation -5. Code Review - -Task creation -~~~~~~~~~~~~~ - -Tasks requiring changes to critical parts of ROS 2 should have design reviews during early stages of the release cycle. -If a design review is happening in the later stages, the changes will be part of a future release. - -* An issue should be created in the appropriate `ros2 repository `__, clearly describing the task being worked on. - - * It should have a clear success criteria and highlight the concrete improvements expected from it. - * If the feature is targeting a ROS release, ensure this is tracked in the ROS release ticket (`example `__). - -Writing the design document -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Design docs must never include confidential information. -Whether or not a design document is required for your change depends on how big the task is. - -1. You are making a small change or fixing a bug: - - * A design document is not required, but an issue should be opened in the appropriate repository to track the work and avoid duplication of efforts. - -2. You are implementing a new feature or would like to contribute to OSRF-owned infrastructure (like Jenkins CI): - - * Design doc is required and should be contributed to `ros2/design `__ to be made accessible on https://design.ros2.org/. - * You should fork the repository and submit a pull request detailing the design. - - Mention the related ros2 issue (for example, ``Design doc for task ros2/ros2#``) in the pull request or the commit message. - Detailed instructions are on the `ROS 2 Contribute `__ page. - Design comments will be made directly on the pull request. - -If the task is planned to be released with a specific version of ROS, this information should be included in the pull request. - -Design document review -~~~~~~~~~~~~~~~~~~~~~~ - -Once the design is ready for review, a pull request should be opened and appropriate reviewers should be assigned. -It is recommended to include project owner(s) - -maintainers of all impacted packages (as defined by ``package.xml`` maintainer field, see `REP-140 `__) - as reviewers. - -* If the design doc is complex or reviewers have conflicting schedules, an optional design review meeting can be set up. - In this case, - - **Before the meeting** - - * Send a meeting invite at least one week in advance - * Meeting duration of one hour is recommended - * Meeting invite should list all decisions to be made during the review (decisions requiring package maintainer approval) - * Meeting required attendees: design pull request reviewers - Meeting optional attendees: all OSRF engineers, if applicable - - **During the meeting** - - * The task owner drives the meeting, presents their ideas and manages discussions to ensure an agreement is reached on time - - **After the meeting** - - * The task owner should send back meeting notes to all attendees - * If minor issues have been raised about the design: - - * The task owner should update the design doc pull request based on the feedback - * Additional review is not required - - * If major issues have been raised about the design: - - * It is acceptable to remove sections for which there is no clear agreement - * The debatable parts of the design can be resubmitted as a separate task in the future - * If removing the debatable parts is not an option, work directly with package owners to reach an agreement - -* Once consensus is reached: - - * Ensure the `ros2/design `__ pull request has been merged, if applicable - * Update and close the GitHub issue associated with this design task - -Implementation -~~~~~~~~~~~~~~ - -Before starting, go through the `Pull requests`_ section for best practices. - -* For each repo to be modified: - - * Modify the code, go to the next step if finished or at regular intervals to backup your work. - * `Self-review `__ your changes using ``git add -i``. - * Create a new signed commit using ``git commit -s``. - - * A pull request should contain minimal semantically meaningful commits (for instance, a large number of 1-line commits is not acceptable). - Create new fixup commits while iterating on feedback, or optionally, amend existing commits using ``git commit --amend`` if you don't want to create a new commit every time. - * Each commit must have a properly written, meaningful, commit message. - More instructions `here `__. - * Moving files must be done in a separate commit, otherwise git may fail to accurately track the file history. - * Either the pull request description or the commit message must contain a reference to the related ros2 issue, so it gets automatically closed when the pull request is merged. - See this `doc `__ for more details. - * Push the new commits. - -Code review -~~~~~~~~~~~ - -Once the change is ready for code review: - -* Open a pull request for each modified repository. - - * Remember to follow `Pull requests`_ best practices. - * `GitHub `__ can be used to create pull requests from the command-line. - * If the task is planned to be released with a specific version of ROS, this information should be included in each pull request. - -* Package owners who reviewed the design document should be mentioned in the pull request. -* Code review SLO: although reviewing pull requests is best-effort, - it is helpful to have reviewers comment on pull requests within a week and - code authors to reply back to comments within a week, so there is no loss of context. -* Iterate on feedback as usual, amend and update the development branch as needed. -* Once the PR is approved, package maintainers will merge the changes in. - - -Build Farm Introduction ------------------------ - -The build farm is located at `ci.ros2.org `__. - -Every night we run nightly jobs which build and run all the tests in various scenarios on various platforms. -Additionally, we test all pull requests against these platforms before merging. - -Check :ref:`the current set of target platforms and architectures `, though it evolves overtime. - -There are several categories of jobs on the buildfarm: - -* manual jobs (triggered manually by developers): - - * ci_linux: build + test the code on Ubuntu - * ci_linux-aarch64: build + test the code on Ubuntu on an ARM 64-bit machine (aarch64) - * ci_linux_coverage: build + test + generation of test coverage - * ci_linux-rhel: build + test the code on Red Hat Enterprise Linux - * ci_windows: build + test the code on Windows - * ci_launcher: trigger all the jobs listed above - -* nightly (run every night): - - * Debug: build + test the code with CMAKE_BUILD_TYPE=Debug - - * nightly_linux_debug - * nightly_linux-aarch64_debug - * nightly_linux-rhel_debug - * nightly_win_deb - - * Release: build + test the code with CMAKE_BUILD_TYPE=Release - - * nightly_linux_release - * nightly_linux-aarch64_release - * nightly_linux-rhel_release - * nightly_win_rel - - * Repeated: build then run each test up to 20 times or until failed (aka flakiness hunter) - - * nightly_linux_repeated - * nightly_linux-aarch64_repeated - * nightly_linux-rhel_repeated - * nightly_win_rep - - * Coverage: - - * nightly_linux_coverage: build + test the code + analyses coverage for c/c++ and python - - * results are exported as a cobertura report - - -* packaging (run every night; result is bundled into an archive): - - * packaging_linux - * packaging_linux-rhel - * packaging_windows - -Two additional build farms support the ROS / ROS 2 ecosystem by providing building of source and -binary packages, continuous integration, testing, and analysis. - -For details, frequently asked questions, and troubleshooting see :doc:`build farms `. - -Note on Coverage runs -^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 packages are organized in a way that the testing code for a given package is not only contained within the package, but could also be present in a different package. -In other words: packages can exercise code belonging to other packages during the testing phase. - -To achieve the coverage rate reached by all code available in the ROS 2 core packages it is recommended to run builds using a fixed set of proposed repositories. -That set is defined in the default parameters of coverage jobs in Jenkins. - - -.. _read-coverage-report: - -How to read the coverage rate from the buildfarm report -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To see the coverage report for a given package: - -* When the ``ci_linux_coverage`` build finishes, click on ``Coverage Report`` -* Scroll down to the ``Coverage Breakdown by Package`` table -* In the table, look at the first column called "Name" - -The coverage reports in the buildfarm include all the packages that were used in the ROS workspace. -The coverage report includes different paths corresponding to the same package: - -* Name entries with the form: ``src.*...*`` - These correspond to the unit test runs available in a package against its own source code -* Name entries with the form: ``build...*`` - These correspond to the unit test runs available in a package against its files generated at building or configuring time -* Name entries with the form: ``install..*`` - These correspond to the system/integration tests coming from testing runs of other packages - -.. _calculate-coverage-rate: - -How to calculate the coverage rate from the buildfarm report -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Get the combined unit coverage rate using the automatic script: - - * From the ci_linux_coverage Jenkins build copy the URL of the build - * Download the `get_coverage_ros2_pkg `__ script - * Execute the script: ``./get_coverage_ros2_pkg.py `` (`README `__) - * Grab the results from the "Combined unit testing" final line in the output of the script - -Alternative: get the combined unit coverage rate from coverage report (require manual calculation): - -* When the ci_linux_coverage build finishes, click on ``Cobertura Coverage Report`` -* Scroll down to the ``Coverage Breakdown by Package`` table -* In the table, under the first column "Name", look for (where is your package under testing): - - * all the directories under the pattern ``src.*...*`` grab the two absolute values in the column "Lines". - * all the directories under the pattern ``build/..*`` grab the two absolute values in the column "Lines". - -* With the previous selection: for each cell, the first value is the lines tested and the second is the total lines of code. - Aggregate all rows for getting the total of the lines tested and the total of lines of code under test. - Divide to get the coverage rate. - -.. _measure-coverage-locally: - -How to measure coverage locally using lcov (Ubuntu) -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To measure coverage on your own machine, install ``lcov``. - -.. code-block:: console - - $ sudo apt install -y lcov - -The rest of this section assumes you are working from your colcon workspace. -Compile in debug with coverage flags. -Feel free to use colcon flags to target specific packages. - -.. code-block:: console - - $ colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} --coverage" -DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} --coverage" - -``lcov`` requires an initial baseline, which you can produce with the following command. -Update the output file location for your needs. - -.. code-block:: console - - $ lcov --no-external --capture --initial --directory . --output-file ~/ros2_base.info - -Run tests for the packages that matter for your coverage measurements. -For example, if measuring ``rclcpp`` also with ``test_rclcpp`` - -.. code-block:: console - - $ colcon test --packages-select rclcpp test_rclcpp - -Capture the lcov results with a similar command this time dropping the ``--initial`` flag. - -.. code-block:: console - - $ lcov --no-external --capture --directory . --output-file ~/ros2.info - -Combine the trace ``.info`` files: - -.. code-block:: console - - $ lcov --add-tracefile ~/ros2_base.info --add-tracefile ~/ros2.info --output-file ~/ros2_coverage.info - -Generate html for easy visualization and annotation of covered lines. - -.. code-block:: console - - $ mkdir -p coverage - $ genhtml ~/ros2_coverage.info --output-directory coverage +.. redirect-from:: + + Developer-Guide + Contributing/Developer-Guide + +ROS 2 developer guide +===================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page defines the practices and policies we employ when developing ROS 2. + +General Principles +------------------ + +Some principles are common to all ROS 2 development: + + +* **Shared ownership**: + Everybody working on ROS 2 should feel ownership over all parts of the system. + The original author of a chunk of code does not have any special permission or obligation to control or maintain that chunk of code. + Everyone is free to propose changes anywhere, to handle any type of ticket, and to review any pull request. +* **Be willing to work on anything**: + As a corollary to shared ownership, everybody should be willing to take on any available task and contribute to any aspect of the system. +* **Ask for help**: + If you run into trouble on something, ask your fellow developers for help, via tickets, comments, or email, as appropriate. + +Quality Practices +----------------- + +Packages can ascribe to different levels of quality based on the development practices they adhere to, as per the guidelines in `REP 2004: Package Quality Categories `_. +The categories are differentiated by their policies on versioning, testing, documentation, and more. + +The following sections are the specific development rules we follow to ensure core packages are of the highest quality ('Level 1'). +We recommend all ROS developers strive to adhere to the following policies to ensure quality across the ROS ecosystem. + +For more specific code recommendations please see :doc:`the Quality Guide `. + +.. _semver: + +Versioning +^^^^^^^^^^ + +We will use the `Semantic Versioning guidelines `__ (``semver``) for versioning. + +We will also adhere to some ROS-specific rules built on top of ``semver's`` full meaning: + +* Major version increments (i.e. breaking changes) should not be made within a released ROS distribution. + + * Patch (interface-preserving) and minor (non-breaking) version increments do not break compatibility, so these sorts of changes *are* allowed within a release. + + * Major ROS releases are the best time to release breaking changes. + If a core package needs multiple breaking changes, they should be merged into their integration branch (e.g. rolling) to allow catching problems in CI quickly, but released together to reduce the number of major releases for ROS users. + + * Though major increments require a new distribution, a new distribution does not necessarily require a major bump (if development and release can happen without breaking API). + +* For compiled code, the ABI is considered part of the public interface. + Any change that requires recompiling dependent code is considered major (breaking). + + * ABI breaking changes *can* be made in a minor version bump *before* a distribution release (getting added to the rolling release). + +* We enforce API stability for core packages in Dashing and Eloquent even though their major version components are ``0``, despite `SemVer's specification `_ regarding initial development. + + * Subsequently, packages should strive to reach a mature state and increase to version ``1.0.0`` so to match ``semver's`` specifications. + +Caveats +~~~~~~~ + +These rules are *best-effort*. +In unlikely, extreme cases, it may be necessary to break API within a major version/distribution. +Whether an unplanned break increments the major or minor version will be assessed on a case-by-case basis. + +For example, consider a situation involving released X-turtle, corresponding to major version ``1.0.0``, and released Y-turtle, corresponding to major version ``2.0.0``. + +If an API-breaking fix is identified to be absolutely necessary in X-turtle, bumping to ``2.0.0`` is obviously not an option because ``2.0.0`` already exists. + +The solutions for handling X-turtle's version in such a case, both non-ideal, are: + +1. Bumping X-turtle's minor version: non-ideal because it violates SemVer's principle that breaking changes must bump the major version. + +2. Bumping X-turtle's major version past Y-turtle (to ``3.0.0``): non-ideal because the older distro's version would become higher than the already-available version of a newer distro, which would invalidate/break version-specific conditional code. + +The developer will have to decide which solution to use, or more importantly, which principle they are willing to break. +We cannot suggest one or the other, but in either case we do require that explicit measures be taken to communicate the disruption and its explanation to users manually (beyond just the version increment). + +If there were no Y-turtle, even though the fix would technically just be a patch, X-turtle would have to bump to ``2.0.0``. +This case adheres to SemVer, but breaks from our own rule that major increments should not be introduced in a released distribution. + +This is why we consider the versioning rules *best-effort*. +As unlikely as the examples above are, it is important to accurately define our versioning system. + +Public API declaration +~~~~~~~~~~~~~~~~~~~~~~ + +According to ``semver``, every package must clearly declare a public API. +We will use the "Public API Declaration" section of the quality declaration of a package to declare what symbols are part of the public API. + +For most C and C++ packages the declaration is any header that it installs. +However, it is acceptable to define a set of symbols which are considered private. +Avoiding private symbols in headers can help with ABI stability, but is not required. + +For other languages like Python, a public API must be explicitly defined, so that it is clear what symbols can be relied on with respect to the versioning guidelines. +The public API can also be extended to build artifacts like configuration variables, CMake config files, etc. as well as executables and command-line options and output. +Any elements of the public API should be clearly stated in the package's documentation. +If something you are using is not explicitly listed as part of the public API in the package's documentation, then you cannot depend on it not changing between minor or patch versions. + +Deprecation strategy +~~~~~~~~~~~~~~~~~~~~ + +Where possible, we will also use the tick-tock deprecation and migration strategy for major version increments. +New deprecations will come in a new distribution release, accompanied by compiler warnings expressing that the functionality is being deprecated. +In the next release, the functionality will be completely removed (no warnings). + +Example of function ``foo`` deprecated and replaced by function ``bar``: + +========= ======================================================== + Version API +========= ======================================================== +X-turtle void foo(); +Y-turtle [[deprecated("use bar()")]] void foo();
void bar(); +Z-turtle void bar(); +========= ======================================================== + +We must not add deprecations after a distribution is released. +Deprecations do not necessarily require a major version bump, though. +A deprecation can be introduced in a minor version bump if the bump happens before the distro is released (similar to ABI breaking changes). + +For example, if X-turtle begins development as ``2.0.0``, a deprecation can be added in ``2.1.0`` before X-turtle is released. + +We will attempt to maintain compatibility across distros as much as possible. +However, like the caveats associated with SemVer, tick-tock or even deprecation in general may be impossible to completely adhere to in certain cases. + +Change control process +^^^^^^^^^^^^^^^^^^^^^^ + +* All changes must go through a pull request. + +* We will enforce the `Developer Certificate of Origin (DCO) `_ on pull requests in ROSCore repositories. + + * It requires all commit messages to contain the ``Signed-off-by`` line with an email address that matches the commit author. + + * You can pass ``-s`` / ``--signoff`` to the ``git commit`` invocation or write the expected message manually (e.g. ``Signed-off-by: Your Name Developer ``). + + * DCO is *not* required for pull requests that only address whitespace removal, typo correction, and other `trivial changes `_. + +* Always run CI jobs for all `tier 1 platforms `_ for every pull request and include links to jobs in the pull request. + (If you don't have access to the Jenkins jobs someone will trigger the jobs for you.) + +* A minimum of 1 approval from a fellow developer who did not author the pull request is required to consider it approved. + Approval is required before merging. + + * Packages may choose to increase this number. + +* Any required changes to documentation (API documentation, feature documentation, release notes, etc.) must be proposed before merging related changes. + +Guidelines for backporting PRs +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When changing an older version of ROS: + +* Make sure the features or fixes are accepted and merged in the rolling branch before opening a PR to backport the changes to older versions. +* When backporting to older versions, also consider backporting to any other :doc:`still supported versions <../../Get-Started/Releases>`, even non-LTS versions. +* If you are backporting a single PR in its entirety, title the backport PR "[Distro] ". +* Link to all PRs whose changes you're backporting from the description of your backport PR. +* Package maintainers typically use `Mergifyio `_ to automatically backport PRs to downstream distributions when needed, however developers can still perform manual backporting operations as described above when necessary. + +Documentation +^^^^^^^^^^^^^ + +All packages should have these documentation elements present in their README or linked to from their README: + +* Description and purpose +* Definition and description of the public API +* Examples +* How to build and install (should reference external tools/workflows) +* How to build and run tests +* How to build documentation +* How to develop (useful for describing things like ``python setup.py develop``) +* License and copyright statements + +Each source file must have a license and copyright statement, checked with an automated linter. + +Each package must have a LICENSE file, typically the Apache 2.0 license, unless the package has an existing permissive license (e.g. rviz uses three-clause BSD). + +Each package should describe itself and its purpose assuming, as much as possible, that the reader has stumbled onto it without previous knowledge of ROS or other related projects. + +Each package should define and describe its public API so that there is a reasonable expectation for users about what is covered by the semantic versioning policy. +Even in C and C++, where the public API can be enforced by API and ABI checking, it is a good opportunity to describe the layout of the code and the function of each part of the code. + +It should be easy to take any package and from that package's documentation understand how to build, run, build and run tests, and build the documentation. +Obviously we should avoid repeating ourselves for common workflows, like building a package in a workspace, but the basic workflows should be either described or referenced. + +Finally, it should include any documentation for developers. +This might include workflows for testing the code using something like ``python setup.py develop``, or it might mean describing how to make use of extension points provided by your package. + +Examples: + +* `capabilities `_ + + * This one gives an example of docs which describe the public API + +* `catkin_tools `_ + + * This is an example of describing an extension point for a package + +API Documentation for ROS Packages +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +API documentation for all released ROS packages can be `found here `__. +We recommend using `index.ros.org `_ to search through available ROS packages to find their documentation. + +If you are a ROS package developer looking for guidance on documenting your package please see :doc:`our "how to" guide on package level documentation <../../Developer-Tools/Build/Documenting-a-ROS-2-Package>`. +The documentation for all released ROS 2 packages is automatically hosted on `docs.ros.org `_. + +Testing +^^^^^^^ + +All packages should have some level of :ref:`system, integration, and/or unit tests.` + +**Unit tests** should always be in the package which is being tested and should make use of tools like ``Mock`` to try and test narrow parts of the codebase in constructed scenarios. +Unit tests should not bring in test dependencies that are not testing tools, e.g. gtest, nosetest, pytest, mock, etc... + +**Integration tests** can test interactions between parts of the code or between parts of the code and the system. +They often test software interfaces in ways that we expect the user to use them. +Like Unit tests, Integration tests should be in the package which is being tested and should not bring in non-tool test dependencies unless absolutely necessary, i.e. all non-tool dependencies should only be allowed under extreme scrutiny so they should be avoided if possible. + +**System tests** are designed to test end-to-end situations between packages and should be in their own packages to avoid bloating or coupling packages and to avoid circular dependencies. + +In general external or cross package test dependencies should be minimized to prevent circular dependencies and tightly coupled test packages. + +All packages should have some unit tests and possibly integration tests, but the degree to which they should have them is based on the package's quality category. +The following subsections apply to 'Level 1' packages: + +Code coverage +~~~~~~~~~~~~~ + +We will provide line coverage, and achieve line coverage above 95%. +If a lower percentage target is justifiable, it must be prominently documented. +We may provide branch coverage, or exclude code from coverage (test code, debug code, etc.). +We require that coverage increase or stay the same before merging a change, but it may be acceptable to make a change that decreases code coverage with proper justification (e.g. deleting code that was previously covered can cause the percentage to drop). + +Performance +~~~~~~~~~~~ + +We strongly recommend performance tests, but recognize they don't make sense for some packages. +If there are performance tests, we will choose to either check each change or before each release or both. +We will also require justification for merging a change or making a release that lowers performance. + +Linters and static analysis +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We will use :doc:`ROS code style ` and enforce it with linters from `ament_lint_common `_. +All linters/static analysis that are part of ``ament_lint_common`` must be used. + +The `ament_lint_auto `_ documentation provides information on running ``ament_lint_common``. + +General Practices +----------------- + +Some practices are common to all ROS 2 development. + +These practices don't affect package quality level as described in `REP 2004 `_, but are still highly recommended for the development process. + +Issues +^^^^^^ + +When filing an issue please make sure to: + +- Include enough information for another person to understand the issue. + In ROS 2, the following points are needed for narrowing down the cause of an issue. + Testing with as many alternatives in each category as feasible will be especially helpful. + + - **The operating system and version.** + Reasoning: ROS 2 supports multiple platforms, and some bugs are specific to particular versions of operating systems/compilers. + - **The installation method.** + Reasoning: Some issues only manifest if ROS 2 has been installed from binary archives or from debs. + This can help us determine if the issue is with the packaging process. + - **The specific version of ROS 2.** + Reasoning: Some bugs may be present in a particular ROS 2 release and later fixed. + It is important to know if your installation includes these fixes. + - **The DDS/RMW implementation being used** (see `this page <../../Concepts/Intermediate/About-Different-Middleware-Vendors>` for how to determine which one). + Reasoning: Communication issues may be specific to the underlying ROS middleware being used. + - **The ROS 2 client library being used.** + Reasoning: This helps us narrow down the layer in the stack at which the issue might be. + +- Include a list of steps to reproduce the issue. +- In case of a bug consider to provide a `short, self contained, correct (compilable), example `__. + Issues are much more likely to be resolved if others can reproduce them easily. + +- Mention troubleshooting steps that have been tried already, including: + + - Upgrading to the latest version of the code, which may include bug fixes that have not been released yet. + See `this section ` and follow the instructions to get the "rolling" branches. + - Trying with a different RMW implementation. + See `this page <../../How-To-Guides/Working-with-multiple-RMW-implementations>` for how to do that. + +Branches +^^^^^^^^ + +.. note:: + These are just guidelines. + It is up to the package maintainer to choose branch names that match their own workflow. + +It is good practice to have **separate branches** in a package's source repository for each ROS distribution it is targeting. +These branches are typically named after the distribution they target. +For example, a ``humble`` branch for development targeted specifically at the Humble distribution. + +Releases are also made from these branches, targeting the appropriate distribution. +Development targeted at a specific ROS distribution can happen on the appropriate branch. +For example: Development commits targeting ``foxy`` are made to the ``foxy`` branch, and package releases for ``foxy`` are made from that same branch. + +.. note:: + This requires the package maintainers to perform backports or forwardports as appropriate to keep all branches up to date with features. + The maintainers must also perform general maintenance (bug fixes, etc.) on all branches from which package releases are still made. + + For example, if a feature is merged into the Rolling-specific branch (e.g. ``rolling`` or ``main``), and that feature is also appropriate + to the Humble distribution (does not break API, etc.), then it is good practice to backport the feature to the Humble-specific branch. + + The maintainers may make releases for those older distributions if there are new features or bug fixes available. + +**What about** ``main`` **and** ``rolling`` **?** + +``main`` typically targets :doc:`Rolling <../../Get-Started/Releases/Release-Rolling-Ridley>` (and so, the next unreleased ROS distribution), though the maintainers may decide to develop and release from a ``rolling`` branch instead. + +Pull requests +^^^^^^^^^^^^^ + +* A pull request should only focus on one change. + Separate changes should go into separate pull requests. + See `GitHub's guide to writing the perfect pull request `__. + +* A patch should be minimal in size and avoid any kind of unnecessary changes. + +* A pull request must contain minimum number of meaningful commits. + + * You can create new commits while the pull request is under review. + +* Before merging a pull request all changes should be squashed into a small number of semantic commits to keep the history clear. + + * But avoid squashing commits while a pull request is under review. + Your reviewers might not notice that you made the change, thereby introducing potential for confusion. + Plus, you're going to squash before merging anyway; there's no benefit to doing it early. + +* Any developer is welcome to review and approve a pull request (see `General Principles`_). + +* When you are working on a change that is not ready for review or to be merged, use a draft pull request. + When that change is ready for review, move the pull request out of the draft state. + Note that if you want early feedback from specific people on a draft pull request, you can @ mention them in the pull request's description or in a comment on the pull request. + +* If your pull request depends on other pull requests, link to each depended on pull request by adding ``- Depends on `` at the top of your pull request's description. + Doing so helps reviewers understand the context of the pull request. + +* When you start reviewing a pull request, comment on the pull request so that other developers know that you're reviewing it. + +* Pull-request review is not read-only, with the reviewer making comments and then waiting for the author to address them. + As a reviewer, feel free to make minor improvements (typos, style issues, etc.) in-place. + As the opener of a pull-request, if you are working in a fork, checking the box to `allow edits from upstream contributors `__ will assist with the aforementioned. + As a reviewer, also feel free to make more substantial improvements, but consider putting them in a separate branch (either mention the new branch in a comment, or open another pull request from the new branch to the original branch). + +* Only maintainers and committers can merge approved pull requests into the mainline. + See the :doc:`current ROS PMC constituents and committers <../Governance>` for the list of people with merge permissions. + +Library versioning +^^^^^^^^^^^^^^^^^^ + +We will version all libraries within a package together. +This means that libraries inherit their version from the package. +This keeps library and package versions from diverging and shares reasoning with the policy of releasing packages which share a repository together. +If you need libraries to have different versions then consider splitting them into different packages. + +Development process +^^^^^^^^^^^^^^^^^^^ + +* The default branch (in most cases the rolling branch) must always build, pass all tests and compile without warnings. + If at any time there is a regression it is the top priority to restore at least the previous state. +* Always build with tests enabled. +* Always run tests locally after changes and before proposing them in a pull request. + Besides using automated tests, also run the modified code path manually to ensure that the patch works as intended. +* Always run CI jobs for all platforms for every pull request and include links to the jobs in the pull request. + +For more details on recommended software development workflow, see `Software Development Lifecycle`_ section. + +Changes to RMW API +^^^^^^^^^^^^^^^^^^ + +When updating `RMW API `__, it is required that RMW implementations for the Tier 1 middleware libraries are updated as well. +For example, a new function ``rmw_foo()`` introduced to the RMW API must be implemented in the following packages (as of ROS Galactic): + +* `rmw_connextdds `__ +* `rmw_cyclonedds `__ +* `rmw_fastrtps `__ + +Updates for non-Tier 1 middleware libraries should also be considered if feasible (e.g. depending on the size of the change). +See `REP-2000 `__ for the list of middleware libraries and their tiers. + +Tracking tasks +^^^^^^^^^^^^^^ + +To help organize work on ROS 2, the core ROS 2 development team uses kanban-style `GitHub project boards `_. + +Not all issues and pull requests are tracked on the project boards, however. +A board usually represents an upcoming release or specific project. +Tickets can be browsed on a per-repo basis by browsing the `ROS 2 repositories' `_ individual issue pages. + +The names and purposes of columns in any given ROS 2 project board vary, but typically follow the same general structure: + +* **To do**: + Issues that are relevant to the project, ready to be assigned +* **In progress**: + Active pull requests on which work is currently in progress +* **In review**: + Pull requests where work is complete and ready for review, and for those currently under active review +* **Done**: + Pull requests and related issues are merged/closed (for informational purposes) + +To request permission to make changes, simply comment on the tickets you're interested in. +Depending on the complexity, it might be useful to describe how you plan to address it. +We will update the status (if you don't have the permission) and you can start working on a pull request. +If you contribute regularly we will likely just grant you permission to manage the labels etc. yourself. + +Package Naming Conventions +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Names play an important role in ROS and following naming conventions simplifies the process of learning and understanding large systems. + +The ROS packages occupy a flat namespace, so naming should be done carefully and consistently. +There is a standard for package naming in `REP-144 `__ + +* Package names should follow common C variable naming conventions: lower case, start with a letter, use underscore separators, e.g. laser_viewer + +* Package names should be specific enough to identify what the package does. + For example, a motion planner is not called planner. + If it implements the wavefront propagation algorithm, it might be called wavefront_planner. + There's obviously tension between making a name specific and keeping it from becoming overly verbose. + + * Using catchall names such as utils should be avoided as they do not scope what goes into the package or what should be outside the package. + +* To check whether a name is taken, consult ``__. + If you'd like your repository included in that list, see the `rosdistro Contributing Guide `__. + +* Our goal is to develop a canonical set of tools for making robots do interesting things. + The package name should tell you what the package does, not where it came from. + It should be possible for us, as a community, to make this work. + An Ubuntu distribution offers approximately 33,000 packages without inserting origin or authorship into names. + +* Prefixing a package name is recommended only when the package is not meant to be used more widely (e.g., packages that are specific to the PR2 robot use the ``pr2_`` prefix). + You might prefix the package name when forking an existing package, but again, the prefix would hopefully communicate what changed, not who changed it. + +* Prefixing a package name with 'ros' is redundant for a ROS package. + This is not recommended except for very core packages. + +Units of Measure and Coordinate System Conventions +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Standard units and coordinate conventions for use in ROS have been formalized in `REP-0103 `__. +All messages should follow these guidelines unless there's a very strong reason which is very clearly documented to avoid confusion. + +Representation of special conditions within distance measurements like "too close" or "too far" in ROS have been formalized in `REP-0117 `__. + +Programming conventions +^^^^^^^^^^^^^^^^^^^^^^^ + +* Defensive programming: ensure that assumptions are held as early as possible. + E.g. check every return code and make sure to at least throw an exception until the case is handled more gracefully. +* All error messages must be directed to ``stderr``. +* Declare variables in the narrowest scope possible. +* Keep group of items (dependencies, imports, includes, etc.) ordered alphabetically. + +C++ specific +~~~~~~~~~~~~ + +* Avoid using direct streaming (``<<``) to ``stdout`` / ``stderr`` to prevent interleaving between multiple threads. +* Avoid using references for ``std::shared_ptr`` since that subverts the reference counting. + If the original instance goes out of scope and the reference is being used it accesses freed memory. + +Filesystem layout +^^^^^^^^^^^^^^^^^ + +The filesystem layout of packages and repositories should follow the same conventions in order to provide a consistent experience for users browsing our source code. + +Package layout +~~~~~~~~~~~~~~ + +* ``src``: contains all C and C++ code + + * Also contains C/C++ headers which are not installed + +* ``include``: contains all C and C++ headers which are installed + + * ````: for all C and C++ installed headers they should be folder namespaced by the package name + +* ````: contains all Python code +* ``test``: contains all automated tests and test data +* ``config``: contains configuration files, e.g. YAML parameters files and RViz config files +* ``doc``: contains all the documentation +* ``launch``: contains all launch files +* ``msg``: contains all ROS Message definitions +* ``srv``: contains all ROS Service definitions +* ``action``: contains all ROS Action definitions +* ``package.xml``: as defined by `REP-0140 `_ (may be updated for prototyping) +* ``CMakeLists.txt``: only ROS packages which use CMake +* ``setup.py``: only ROS packages which use Python code only +* ``README``: can be rendered on GitHub as a landing page for the project + + * This can be as short or detailed as is convenient, but it should at least link to project documentation + * Consider putting a CI or code coverage tag in this README + * It can also be ``.rst`` or anything else that GitHub supports + +* ``CONTRIBUTING``: describes the contribution guidelines + + * This might include license implication, e.g. when using the Apache 2 License. + +* ``LICENSE``: a copy of the license or licenses for this package +* ``CHANGELOG.rst``: `REP-0132 `_ compliant changelog + +Repository layout +~~~~~~~~~~~~~~~~~ + +Each package should be in a subfolder which has the same name as the package. +If a repository contains only a single package it can optionally be in the root of the repository. + +Upstream Packages +^^^^^^^^^^^^^^^^^ + +Packages in Debian and Ubuntu Upstream +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Thanks to diligent effort from Jochen Sprickerhof and Leopold Palomo-Avellaneda, some of the `ROS 2 packages are now available `_ from the main Debian and Ubuntu repositories. +`Here is a short overview of the process from Jochen at ROSCon 2015 `_. +The original ROS packages have been modified to follow Debian guidelines, which includes splitting packages into multiple pieces, changing names in some cases, installing to /usr according to FHS guidelines, and using soversions on shared libraries. + +In addition several of the bootstrap dependencies such as command line tools like ``vcstool`` and ``colcon`` as well as some libraries like ``osrf-pycommon`` and ``ament`` are also packaged upstream. + +Unlike the OSRF-provided ROS packages from http://packages.ros.org, the packages in the upstream repositories are not attached to a specific :doc:`ROS distribution <../../Get-Started/Releases>`. +Rather, they represent a snapshot in time that will be updated periodically within Debian unstable and then latched at various points into downstream Debian and Ubuntu distributions. + +Don't mix the streams +~~~~~~~~~~~~~~~~~~~~~ + +We strongly recommend against mixing ROS packages from upstream Debian/Ubuntu and from http://packages.ros.org on the same system. +In some cases such a mixed system will work correctly, but there can be negative interactions between the two sets of packages. +We're working with Jochen and friends to minimize the chance of problems via documentation and package conflict specifications, but we expect some risks to remain, including some fairly subtle issues. + +As such, we recommend that you choose to either install packages from upstream or from http://packages.ros.org, but not both. +Not only should you not install packages from both at the same time, but if you intend to use the upstream packages then you should not even have the http://packages.ros.org entries in your apt sources (i.e. in any files in ``/etc/apt/sources*``). +Having both of them enabled can cause mixing of packages which overlap by name between the two sources, e.g. ``python3-rospkg``. + +Known Differences +~~~~~~~~~~~~~~~~~ + +As compared to the ROS packages from packages.ros.org, there are some differences in the upstream ROS packages that people should be aware of: + +* The package set is incomplete. +* Packages may have different names and be partitioned differently. + +Developer Workflow +------------------ + +We track open tickets and active PRs related to upcoming releases and larger projects using `GitHub project boards `_. + +The usual workflow is: + +* Discuss design (GitHub ticket on the appropriate repository, and a design PR to https://github.com/ros2/design if needed) +* Write implementation on a feature branch on a fork + + * Please check out the `developer guide ` for guidelines and best practices + +* Write tests +* Enable and run linters +* Run tests locally using ``colcon test`` (see the :doc:`colcon tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>`) +* Once everything builds locally without warnings and all tests are passing, run CI on your feature branch: + + * Go to ci.ros2.org + * Log in (top right corner) + * Click on the ``ci_launcher`` job + * Click "Build with Parameters" (left column) + * In the first box "CI_BRANCH_TO_TEST" enter your feature branch name + * Hit the ``build`` button + + (if you are not a ROS 2 committer, you don't have access to the CI farm. + In that case, ping the reviewer of your PR to run CI for you) + +* If your use case requires running code coverage: + + * Go to ci.ros2.org + * Log in (top right corner) + * Click on the ``ci_linux_coverage`` job + * Click "Build with Parameters" (left column) + * Be sure of leaving "CI_BUILD_ARGS" and "CI_TEST_ARGS" with the default values + * Hit the ``build`` button + * At the end of the document there are instructions on how to :ref:`interpret the result of the report ` and :ref:`calculate the coverage rate ` + +* If the CI job built without warnings, errors and test failures, post the links of your jobs on your PR or high-level ticket aggregating all your PRs (see example `here `__) + + * Note that the markdown for these badges is in the console output of the ``ci_launcher`` job + +* When the PR has been approved: + + * the person who submitted the PR merges it using "Squash and Merge" option so that we keep a clean history + + * If the commits deserve to keep separated: squash all the nitpick/linters/typo ones together and merge the remaining set + + * Note: each PR should target a specific feature so Squash and Merge should make sense 99% of the time + +* Delete the branch once merged + +Gitconfig Optimization +^^^^^^^^^^^^^^^^^^^^^^ + +To be able to push to repositories you will need to have ssh keys setup on your system. +However our default url schema for repositories is to use https because it's anonymously accessible. +On your system you can use the ``gitconfig`` option ``insteadOf`` to have ``git`` automatically use your ssh key even if the remote is declared as https. + +Add the following to your ``~/.gitconfig`` + +.. code-block:: + + [url "ssh://git@github.com/"] + insteadOf = https://github.com/ + +If you're working on repositories on GitLab or Bitbucket you can do the same thing. + + +Architectural Development Practices +----------------------------------- + +This section describes the ideal lifecycle that should be employed when making large architectural changes to ROS 2. + +Software Development Lifecycle +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This section describes step-by-step how to plan, design, and implement a new feature: + +1. Task Creation +2. Creating the Design Document +3. Design Review +4. Implementation +5. Code Review + +Task creation +~~~~~~~~~~~~~ + +Tasks requiring changes to critical parts of ROS 2 should have design reviews during early stages of the release cycle. +If a design review is happening in the later stages, the changes will be part of a future release. + +* An issue should be created in the appropriate `ros2 repository `__, clearly describing the task being worked on. + + * It should have a clear success criteria and highlight the concrete improvements expected from it. + * If the feature is targeting a ROS release, ensure this is tracked in the ROS release ticket (`example `__). + +Writing the design document +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Design docs must never include confidential information. +Whether or not a design document is required for your change depends on how big the task is. + +1. You are making a small change or fixing a bug: + + * A design document is not required, but an issue should be opened in the appropriate repository to track the work and avoid duplication of efforts. + +2. You are implementing a new feature or would like to contribute to OSRF-owned infrastructure (like Jenkins CI): + + * Design doc is required and should be contributed to `ros2/design `__ to be made accessible on https://design.ros2.org/. + * You should fork the repository and submit a pull request detailing the design. + + Mention the related ros2 issue (for example, ``Design doc for task ros2/ros2#``) in the pull request or the commit message. + Detailed instructions are on the `ROS 2 Contribute `__ page. + Design comments will be made directly on the pull request. + +If the task is planned to be released with a specific version of ROS, this information should be included in the pull request. + +Design document review +~~~~~~~~~~~~~~~~~~~~~~ + +Once the design is ready for review, a pull request should be opened and appropriate reviewers should be assigned. +It is recommended to include project owner(s) - +maintainers of all impacted packages (as defined by ``package.xml`` maintainer field, see `REP-140 `__) - as reviewers. + +* If the design doc is complex or reviewers have conflicting schedules, an optional design review meeting can be set up. + In this case, + + **Before the meeting** + + * Send a meeting invite at least one week in advance + * Meeting duration of one hour is recommended + * Meeting invite should list all decisions to be made during the review (decisions requiring package maintainer approval) + * Meeting required attendees: design pull request reviewers + Meeting optional attendees: all OSRF engineers, if applicable + + **During the meeting** + + * The task owner drives the meeting, presents their ideas and manages discussions to ensure an agreement is reached on time + + **After the meeting** + + * The task owner should send back meeting notes to all attendees + * If minor issues have been raised about the design: + + * The task owner should update the design doc pull request based on the feedback + * Additional review is not required + + * If major issues have been raised about the design: + + * It is acceptable to remove sections for which there is no clear agreement + * The debatable parts of the design can be resubmitted as a separate task in the future + * If removing the debatable parts is not an option, work directly with package owners to reach an agreement + +* Once consensus is reached: + + * Ensure the `ros2/design `__ pull request has been merged, if applicable + * Update and close the GitHub issue associated with this design task + +Implementation +~~~~~~~~~~~~~~ + +Before starting, go through the `Pull requests`_ section for best practices. + +* For each repo to be modified: + + * Modify the code, go to the next step if finished or at regular intervals to backup your work. + * `Self-review `__ your changes using ``git add -i``. + * Create a new signed commit using ``git commit -s``. + + * A pull request should contain minimal semantically meaningful commits (for instance, a large number of 1-line commits is not acceptable). + Create new fixup commits while iterating on feedback, or optionally, amend existing commits using ``git commit --amend`` if you don't want to create a new commit every time. + * Each commit must have a properly written, meaningful, commit message. + More instructions `here `__. + * Moving files must be done in a separate commit, otherwise git may fail to accurately track the file history. + * Either the pull request description or the commit message must contain a reference to the related ros2 issue, so it gets automatically closed when the pull request is merged. + See this `doc `__ for more details. + * Push the new commits. + +Code review +~~~~~~~~~~~ + +Once the change is ready for code review: + +* Open a pull request for each modified repository. + + * Remember to follow `Pull requests`_ best practices. + * `GitHub `__ can be used to create pull requests from the command-line. + * If the task is planned to be released with a specific version of ROS, this information should be included in each pull request. + +* Package owners who reviewed the design document should be mentioned in the pull request. +* Code review SLO: although reviewing pull requests is best-effort, + it is helpful to have reviewers comment on pull requests within a week and + code authors to reply back to comments within a week, so there is no loss of context. +* Iterate on feedback as usual, amend and update the development branch as needed. +* Once the PR is approved, package maintainers will merge the changes in. + + +Build Farm Introduction +----------------------- + +The build farm is located at `ci.ros2.org `__. + +Every night we run nightly jobs which build and run all the tests in various scenarios on various platforms. +Additionally, we test all pull requests against these platforms before merging. + +Check :ref:`the current set of target platforms and architectures `, though it evolves overtime. + +There are several categories of jobs on the buildfarm: + +* manual jobs (triggered manually by developers): + + * ci_linux: build + test the code on Ubuntu + * ci_linux-aarch64: build + test the code on Ubuntu on an ARM 64-bit machine (aarch64) + * ci_linux_coverage: build + test + generation of test coverage + * ci_linux-rhel: build + test the code on Red Hat Enterprise Linux + * ci_windows: build + test the code on Windows + * ci_launcher: trigger all the jobs listed above + +* nightly (run every night): + + * Debug: build + test the code with CMAKE_BUILD_TYPE=Debug + + * nightly_linux_debug + * nightly_linux-aarch64_debug + * nightly_linux-rhel_debug + * nightly_win_deb + + * Release: build + test the code with CMAKE_BUILD_TYPE=Release + + * nightly_linux_release + * nightly_linux-aarch64_release + * nightly_linux-rhel_release + * nightly_win_rel + + * Repeated: build then run each test up to 20 times or until failed (aka flakiness hunter) + + * nightly_linux_repeated + * nightly_linux-aarch64_repeated + * nightly_linux-rhel_repeated + * nightly_win_rep + + * Coverage: + + * nightly_linux_coverage: build + test the code + analyses coverage for c/c++ and python + + * results are exported as a cobertura report + + +* packaging (run every night; result is bundled into an archive): + + * packaging_linux + * packaging_linux-rhel + * packaging_windows + +Two additional build farms support the ROS / ROS 2 ecosystem by providing building of source and +binary packages, continuous integration, testing, and analysis. + +For details, frequently asked questions, and troubleshooting see :doc:`build farms `. + +Note on Coverage runs +^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 packages are organized in a way that the testing code for a given package is not only contained within the package, but could also be present in a different package. +In other words: packages can exercise code belonging to other packages during the testing phase. + +To achieve the coverage rate reached by all code available in the ROS 2 core packages it is recommended to run builds using a fixed set of proposed repositories. +That set is defined in the default parameters of coverage jobs in Jenkins. + + +.. _read-coverage-report: + +How to read the coverage rate from the buildfarm report +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To see the coverage report for a given package: + +* When the ``ci_linux_coverage`` build finishes, click on ``Coverage Report`` +* Scroll down to the ``Coverage Breakdown by Package`` table +* In the table, look at the first column called "Name" + +The coverage reports in the buildfarm include all the packages that were used in the ROS workspace. +The coverage report includes different paths corresponding to the same package: + +* Name entries with the form: ``src.*...*`` + These correspond to the unit test runs available in a package against its own source code +* Name entries with the form: ``build...*`` + These correspond to the unit test runs available in a package against its files generated at building or configuring time +* Name entries with the form: ``install..*`` + These correspond to the system/integration tests coming from testing runs of other packages + +.. _calculate-coverage-rate: + +How to calculate the coverage rate from the buildfarm report +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Get the combined unit coverage rate using the automatic script: + + * From the ci_linux_coverage Jenkins build copy the URL of the build + * Download the `get_coverage_ros2_pkg `__ script + * Execute the script: ``./get_coverage_ros2_pkg.py `` (`README `__) + * Grab the results from the "Combined unit testing" final line in the output of the script + +Alternative: get the combined unit coverage rate from coverage report (require manual calculation): + +* When the ci_linux_coverage build finishes, click on ``Cobertura Coverage Report`` +* Scroll down to the ``Coverage Breakdown by Package`` table +* In the table, under the first column "Name", look for (where is your package under testing): + + * all the directories under the pattern ``src.*...*`` grab the two absolute values in the column "Lines". + * all the directories under the pattern ``build/..*`` grab the two absolute values in the column "Lines". + +* With the previous selection: for each cell, the first value is the lines tested and the second is the total lines of code. + Aggregate all rows for getting the total of the lines tested and the total of lines of code under test. + Divide to get the coverage rate. + +.. _measure-coverage-locally: + +How to measure coverage locally using lcov (Ubuntu) +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To measure coverage on your own machine, install ``lcov``. + +.. code-block:: console + + $ sudo apt install -y lcov + +The rest of this section assumes you are working from your colcon workspace. +Compile in debug with coverage flags. +Feel free to use colcon flags to target specific packages. + +.. code-block:: console + + $ colcon build --cmake-args -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} --coverage" -DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} --coverage" + +``lcov`` requires an initial baseline, which you can produce with the following command. +Update the output file location for your needs. + +.. code-block:: console + + $ lcov --no-external --capture --initial --directory . --output-file ~/ros2_base.info + +Run tests for the packages that matter for your coverage measurements. +For example, if measuring ``rclcpp`` also with ``test_rclcpp`` + +.. code-block:: console + + $ colcon test --packages-select rclcpp test_rclcpp + +Capture the lcov results with a similar command this time dropping the ``--initial`` flag. + +.. code-block:: console + + $ lcov --no-external --capture --directory . --output-file ~/ros2.info + +Combine the trace ``.info`` files: + +.. code-block:: console + + $ lcov --add-tracefile ~/ros2_base.info --add-tracefile ~/ros2.info --output-file ~/ros2_coverage.info + +Generate html for easy visualization and annotation of covered lines. + +.. code-block:: console + + $ mkdir -p coverage + $ genhtml ~/ros2_coverage.info --output-directory coverage diff --git a/source/The-ROS2-Project/Features.rst b/source/The-ROS2-Project/Features.rst index 99f5a0ad224..a3492850baa 100644 --- a/source/The-ROS2-Project/Features.rst +++ b/source/The-ROS2-Project/Features.rst @@ -1,104 +1,104 @@ -.. redirect-from:: - - Features - -.. _Features: - -Features Status -=============== - -The features listed below are available in the current ROS 2 release. -Unless otherwise specified, the features are available for all supported platforms (Ubuntu 24.04 (Noble), Windows 10), DDS implementations (eProsima Fast DDS, RTI Connext DDS, and Eclipse Cyclone DDS) and programming language client libraries (C++ and Python). -For planned future development, see the :doc:`Roadmap `. - -.. list-table:: - :header-rows: 1 - - * - Functionality - - Link - - Fine print - * - Discovery, transport and serialization over DDS - - `Article `__ - - - * - Support for :doc:`multiple DDS implementations <../Concepts/Intermediate/About-Different-Middleware-Vendors>`, chosen at runtime - - :doc:`Concept <../Concepts/Intermediate/About-Different-Middleware-Vendors>`, :doc:`How-to Guide <../How-To-Guides/Working-with-multiple-RMW-implementations>` - - Currently Eclipse Cyclone DDS, eProsima Fast DDS, and RTI Connext DDS are fully supported. - * - Common core client library that is wrapped by language-specific libraries - - :doc:`Details <../Concepts/Basic/About-Client-Libraries>` - - - * - Publish/subscribe over topics - - `Sample code `__\ , `Article `__ - - - * - Clients and services - - `Sample code `__ - - - * - Set/retrieve parameters - - `Sample code `__ - - - * - ROS 1 - ROS 2 communication bridge - - `Tutorial `__ - - Available for topics and services, not yet available for actions. - * - Quality of service settings for handling non-ideal networks - - :doc:`Demo <../Tutorials/Demos/Quality-of-Service>` - - - * - Inter- and intra-process communication using the same API - - :doc:`Demo <../Tutorials/Demos/Intra-Process-Communication>` - - Currently only in C++. - * - Composition of node components at compile, link, load, or run time - - :doc:`Demo <../Tutorials/Intermediate/Composition>` - - Currently only in C++. - * - Multiple executors (at level of callback groups) in same node - - `Demo `__ - - Only in C++. - * - Support for nodes with managed lifecycles - - :doc:`Demo <../Tutorials/Demos/Managed-Nodes>` - - Currently only in C++. - * - DDS-Security support - - `Demo `__ - - - * - Command-line introspection tools using an extensible framework - - :doc:`Concept <../Concepts/Basic/About-Command-Line-Tools>` - - - * - Launch system for coordinating multiple nodes - - :doc:`Tutorial <../Tutorials/Intermediate/Launch/Launch-system>` - - - * - Namespace support for nodes and topics - - `Article `__ - - - * - Static remapping of ROS names - - :doc:`How-to Guide <../How-To-Guides/Node-arguments>` - - - * - Demos of an all-ROS 2 mobile robot - - `Demo `__ - - - * - Preliminary support for real-time code - - :doc:`Demo <../Tutorials/Demos/Real-Time-Programming>`, :doc:`demo <../Tutorials/Advanced/Allocator-Template-Tutorial>` - - Linux only. - Not available for Fast RTPS. - * - Preliminary support for "bare-metal" microcontrollers - - `Wiki `__ - - - * - Content filtering subscription - - :doc:`Demo <../Tutorials/Demos/Content-Filtering-Subscription>` - - Currently only in C++. - * - Service Introspection - - :doc:`Demo <../Tutorials/Demos/Service-Introspection>` - - - * - Action Introspection - - :doc:`Demo <../Tutorials/Demos/Action-Introspection>` - - - * - :doc:`Pluggable buffer backends <../Concepts/Intermediate/About-Buffer-Backends>` for ``uint8[]`` fields (e.g. GPU memory transport) - - :doc:`Concept <../Concepts/Intermediate/About-Buffer-Backends>`, :doc:`How-to Guide <../How-To-Guides/Using-Buffer-Backends>`, :doc:`Demo <../Tutorials/Demos/GPU-Buffer-Transport>` - - Experimental. - Currently supported in ``rmw_fastrtps_cpp``. - User-facing backend APIs are C++-only today. - -Besides core features of the platform, the biggest impact of ROS comes from its available packages. -The following are a few high-profile packages which are available in the latest release: - -* `gazebo_ros_pkgs `__ -* `image_transport `__ -* `navigation2 `__ -* `rosbag2 `__ -* `RQt `__ -* `RViz2 `__ +.. redirect-from:: + + Features + +.. _Features: + +Features Status +=============== + +The features listed below are available in the current ROS 2 release. +Unless otherwise specified, the features are available for all supported platforms (Ubuntu 24.04 (Noble), Windows 10), DDS implementations (eProsima Fast DDS, RTI Connext DDS, and Eclipse Cyclone DDS) and programming language client libraries (C++ and Python). +For planned future development, see the :doc:`Roadmap `. + +.. list-table:: + :header-rows: 1 + + * - Functionality + - Link + - Fine print + * - Discovery, transport and serialization over DDS + - `Article `__ + - + * - Support for :doc:`multiple DDS implementations <../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`, chosen at runtime + - :doc:`Concept <../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`, :doc:`How-to Guide <../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` + - Currently Eclipse Cyclone DDS, eProsima Fast DDS, and RTI Connext DDS are fully supported. + * - Common core client library that is wrapped by language-specific libraries + - :doc:`Details <../ROS-Framework/About-Client-Libraries>` + - + * - Publish/subscribe over topics + - `Sample code `__\ , `Article `__ + - + * - Clients and services + - `Sample code `__ + - + * - Set/retrieve parameters + - `Sample code `__ + - + * - ROS 1 - ROS 2 communication bridge + - `Tutorial `__ + - Available for topics and services, not yet available for actions. + * - Quality of service settings for handling non-ideal networks + - :doc:`Demo <../ROS-Framework/topics/Working-with-topics/Quality-of-Service>` + - + * - Inter- and intra-process communication using the same API + - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>` + - Currently only in C++. + * - Composition of node components at compile, link, load, or run time + - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/Composition>` + - Currently only in C++. + * - Multiple executors (at level of callback groups) in same node + - `Demo `__ + - Only in C++. + * - Support for nodes with managed lifecycles + - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/Managed-Nodes>` + - Currently only in C++. + * - DDS-Security support + - `Demo `__ + - + * - Command-line introspection tools using an extensible framework + - :doc:`Concept <../Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools>` + - + * - Launch system for coordinating multiple nodes + - :doc:`Tutorial <../Developer-Tools/Launch/Launch-system>` + - + * - Namespace support for nodes and topics + - `Article `__ + - + * - Static remapping of ROS names + - :doc:`How-to Guide <../Developer-Tools/Introspection-and-analysis/Node-arguments>` + - + * - Demos of an all-ROS 2 mobile robot + - `Demo `__ + - + * - Preliminary support for real-time code + - :doc:`Demo <../Capabilities/Motion-planning/Real-Time-Programming>`, :doc:`demo <../ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial>` + - Linux only. + Not available for Fast RTPS. + * - Preliminary support for "bare-metal" microcontrollers + - `Wiki `__ + - + * - Content filtering subscription + - :doc:`Demo <../ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription>` + - Currently only in C++. + * - Service Introspection + - :doc:`Demo <../Developer-Tools/Introspection-and-analysis/Service-Introspection>` + - + * - Action Introspection + - :doc:`Demo <../ROS-Framework/actions/Working-with-actions/Action-Introspection>` + - + * - :doc:`Pluggable buffer backends <../Concepts/Intermediate/About-Buffer-Backends>` for ``uint8[]`` fields (e.g. GPU memory transport) + - :doc:`Concept <../Concepts/Intermediate/About-Buffer-Backends>`, :doc:`How-to Guide <../How-To-Guides/Using-Buffer-Backends>`, :doc:`Demo <../Tutorials/Demos/GPU-Buffer-Transport>` + - Experimental. + Currently supported in ``rmw_fastrtps_cpp``. + User-facing backend APIs are C++-only today. + +Besides core features of the platform, the biggest impact of ROS comes from its available packages. +The following are a few high-profile packages which are available in the latest release: + +* `gazebo_ros_pkgs `__ +* `image_transport `__ +* `navigation2 `__ +* `rosbag2 `__ +* `RQt `__ +* `RViz2 `__ diff --git a/source/The-ROS2-Project/Platform-EOL-Policy.rst b/source/The-ROS2-Project/Platform-EOL-Policy.rst index 28dfaffb8ea..110ed8f2a9d 100644 --- a/source/The-ROS2-Project/Platform-EOL-Policy.rst +++ b/source/The-ROS2-Project/Platform-EOL-Policy.rst @@ -1,46 +1,46 @@ -.. _PlatformEOLPolicy: - -Platform EOL Policy -=================== - -.. contents:: Table of Contents - :depth: 1 - :local: - -:doc:`ROS distributions <../Releases>` do not support end-of-life (EOL) platforms, even if the ROS distribution is still active. -This page explains: - -* What users of EOL platforms should expect -* What ROS Bosses should do - -Policy ------- - -Every ROS distribution supports certain **platforms**, such as Windows 11 or Ubuntu 24.04. -**Vendors** of these platforms, such as Microsoft or Canonical, decide how long they will support one of their platforms. -When a vendor decides a platform has reached EOL, they usually stop publishing critical bug and security fixes. -To protect ourselves from potentially unpatched security vulnerabilities, we proactively remove all jobs on EOL platforms from the ROS build farm. - -If you are using a platform that is no longer supported by its vendor, you should expect to stop receiving updated ROS packages. -Existing ROS packages will remain available and functional, but they will no longer be updated. -However, ROS Bosses may choose to update packages on an EOL platform in exceptional circumstances. - -For ROS Bosses --------------- - -Before a target platform reaches EOL: - -* Make sure the ROS distribution documentation includes EOL dates for any platform that reaches EOL before the ROS distribution. -* Post an announcement about the platform reaching EOL at least 2 syncs (roughly 60-90 days) beforehand so that package maintainers have time to update their packages. -* Open a `pull request disabling buildfarm jobs for that platform `_ and seek review from the `Infrastructure PMC `_. -* Make one last sync to that platform. - -After a target platform reaches EOL: - -* Update the ROS distribution docs to state the platform will not receive updated ROS packages. -* Announce that the ROS distribution has dropped support for that platform on Discourse. -* Consider making one last release to that platform if: - * You did not already do so prior to EOL, and - * The updates seem unlikely to have regressions, and - * The ROS Buildfarm still has runners for that platform. -* Merge your pull request to disable the buildfarm jobs. +.. _PlatformEOLPolicy: + +Platform EOL Policy +=================== + +.. contents:: Table of Contents + :depth: 1 + :local: + +:doc:`ROS distributions <../Get-Started/Releases>` do not support end-of-life (EOL) platforms, even if the ROS distribution is still active. +This page explains: + +* What users of EOL platforms should expect +* What ROS Bosses should do + +Policy +------ + +Every ROS distribution supports certain **platforms**, such as Windows 11 or Ubuntu 24.04. +**Vendors** of these platforms, such as Microsoft or Canonical, decide how long they will support one of their platforms. +When a vendor decides a platform has reached EOL, they usually stop publishing critical bug and security fixes. +To protect ourselves from potentially unpatched security vulnerabilities, we proactively remove all jobs on EOL platforms from the ROS build farm. + +If you are using a platform that is no longer supported by its vendor, you should expect to stop receiving updated ROS packages. +Existing ROS packages will remain available and functional, but they will no longer be updated. +However, ROS Bosses may choose to update packages on an EOL platform in exceptional circumstances. + +For ROS Bosses +-------------- + +Before a target platform reaches EOL: + +* Make sure the ROS distribution documentation includes EOL dates for any platform that reaches EOL before the ROS distribution. +* Post an announcement about the platform reaching EOL at least 2 syncs (roughly 60-90 days) beforehand so that package maintainers have time to update their packages. +* Open a `pull request disabling buildfarm jobs for that platform `_ and seek review from the `Infrastructure PMC `_. +* Make one last sync to that platform. + +After a target platform reaches EOL: + +* Update the ROS distribution docs to state the platform will not receive updated ROS packages. +* Announce that the ROS distribution has dropped support for that platform on Discourse. +* Consider making one last release to that platform if: + * You did not already do so prior to EOL, and + * The updates seem unlikely to have regressions, and + * The ROS Buildfarm still has runners for that platform. +* Merge your pull request to disable the buildfarm jobs. diff --git a/source/The-ROS2-Project/Roadmap.rst b/source/The-ROS2-Project/Roadmap.rst index 421388f3f48..ef4046d8020 100644 --- a/source/The-ROS2-Project/Roadmap.rst +++ b/source/The-ROS2-Project/Roadmap.rst @@ -1,50 +1,50 @@ -.. redirect-from:: - - Roadmap - -.. _Roadmap: - -Roadmap -======= - -.. contents:: Table of Contents - :depth: 2 - :local: - -This page describes planned work for ROS 2. -The set of planned features and development efforts should provide insight into the overall direction of ROS 2. -If you would like to see other features on the roadmap, please get in touch with us at info@openrobotics.org. - -Lyrical Luth ------------- - -Lyrical Luth is the ROS 2 release expected in May 2026. -See the :doc:`release page <../Releases/Release-Lyrical-Luth>` for a detailed timeline. - -Lyrical Roadmap ---------------- - -The features being worked on are tracked on the `GitHub Project Board `__. -The items in the roadmap are the major features being worked on by the ROS 2 community. -The "Size" is an estimated size of the task, where *Small* means person-days to complete, *Medium* means person-weeks to complete, and *Large* means person-months to complete. - -If you are working on a feature for ROS 2 and would like to have it listed, please open an issue on `ROS 2 Documentation `__. -If you'd like to take on one of these tasks, please :doc:`get in touch with us <../Contact>`. - -Planned releases ----------------- - -Please see the :doc:`Distributions page <../Releases>` for the timeline of and information about future distributions. - -Contributing to ROS 2 ---------------------- - -Looking for something to work on, or just want to help out? -Here are a few resources to get you going. - -1. The :doc:`Contributing ` guide describes how to make a contribution to ROS 2. -2. Check out the list of :doc:`Feature Ideas ` for inspiration. -3. For more information on the design of ROS 2 please see `design.ros2.org `__. -4. The core code for ROS 2 is in the `ros2 GitHub organization `__. -5. The forum discussing ROS 2 design is `Open Robotics Discourse's ROS category `__. -6. Questions should be asked on `Robotics Stack Exchange `__\ , make sure to include at least the ``ros2`` tag and the rosdistro version you are running, e.g. ``{DISTRO}``. +.. redirect-from:: + + Roadmap + +.. _Roadmap: + +Roadmap +======= + +.. contents:: Table of Contents + :depth: 2 + :local: + +This page describes planned work for ROS 2. +The set of planned features and development efforts should provide insight into the overall direction of ROS 2. +If you would like to see other features on the roadmap, please get in touch with us at info@openrobotics.org. + +Lyrical Luth +------------ + +Lyrical Luth is the ROS 2 release expected in May 2026. +See the :doc:`release page <../Get-Started/Releases/Release-Lyrical-Luth>` for a detailed timeline. + +Lyrical Roadmap +--------------- + +The features being worked on are tracked on the `GitHub Project Board `__. +The items in the roadmap are the major features being worked on by the ROS 2 community. +The "Size" is an estimated size of the task, where *Small* means person-days to complete, *Medium* means person-weeks to complete, and *Large* means person-months to complete. + +If you are working on a feature for ROS 2 and would like to have it listed, please open an issue on `ROS 2 Documentation `__. +If you'd like to take on one of these tasks, please :doc:`get in touch with us <../Contact>`. + +Planned releases +---------------- + +Please see the :doc:`Distributions page <../Get-Started/Releases>` for the timeline of and information about future distributions. + +Contributing to ROS 2 +--------------------- + +Looking for something to work on, or just want to help out? +Here are a few resources to get you going. + +1. The :doc:`Contributing ` guide describes how to make a contribution to ROS 2. +2. Check out the list of :doc:`Feature Ideas ` for inspiration. +3. For more information on the design of ROS 2 please see `design.ros2.org `__. +4. The core code for ROS 2 is in the `ros2 GitHub organization `__. +5. The forum discussing ROS 2 design is `Open Robotics Discourse's ROS category `__. +6. Questions should be asked on `Robotics Stack Exchange `__\ , make sure to include at least the ``ros2`` tag and the rosdistro version you are running, e.g. ``{DISTRO}``. diff --git a/source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst b/source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst index d9d561c24db..9b8c96a37fc 100644 --- a/source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst +++ b/source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst @@ -1,114 +1,114 @@ -.. redirect-from:: - - Tutorials/Building-ROS2-Package-with-eclipse-2021-06 - -Building a package with Eclipse 2021-06 -======================================= - -.. contents:: Table of Contents - :depth: 2 - :local: - -You cannot create a ROS 2 package with eclipse, you need to create it with commandline tools. -Follow the :doc:`Create a package <../Beginner-Client-Libraries/Creating-Your-First-ROS2-Package>` tutorial. - -After you created your project, you can edit the source code and build it with eclipse. - -We start eclipse and select a eclipse-workspace. - -.. image:: images/eclipse_work_dir.png - :target: ../../_images/eclipse_work_dir.png - :alt: eclipse_work_dir - -We create a C++ project - -.. image:: images/eclipse_create_c++_project.png - :target: ../../_images/eclipse_create_c++_project.png - :alt: eclipse_create_c++_project - - -.. image:: images/eclipse_c++_project_select_type.png - :target: ../../_images/eclipse_c++_project_select_type.png - :alt: eclipse_c++_project_select_type - -We see that we got C++ includes. - -.. image:: images/eclipse_c++_project_includes.png - :target: ../../_images/eclipse_c++_project_includes.png - :alt: eclipse_c++_project_includes - - -We now import our ROS 2 project. -The code is still in the old place. - -.. image:: images/eclipse_import_project.png - :target: ../../_images/eclipse_import_project.png - :alt: eclipse_import_project - -.. image:: images/eclipse_import_filesystem.png - :target: ../../_images/eclipse_import_filesystem.png - :alt: eclipse_import_filesystem - -Click the Advanced in the Options and check the **Create links in worksapce**. - -.. image:: images/eclipse_import_select_my_package.png - :target: ../../_images/eclipse_import_select_my_package.png - :alt: eclipse_import_select_my_package - - - -We see in the source code that the C++ includes got resolved but not the ROS 2 ones. - -.. image:: images/eclipse_c++_wo_ros_includes.png - :target: ../../_images/eclipse_c++_wo_ros_includes.png - :alt: eclipse_c++_wo_ros_includes - - -.. image:: images/eclipse_c++_path_and_symbols.png - :target: ../../_images/eclipse_c++_path_and_symbols.png - :alt: eclipse_c++_path_and_symbols - -Add include paths of needed packages. -(e.g. **/opt/ros/lyrical/include/rclcpp**, **/opt/ros/lyrical/include/std_msgs**, etc.) - -.. image:: images/eclipse_c++_add_directory_path.png - :target: ../../_images/eclipse_c++_add_directory_path.png - :alt: eclipse_c++_add_directory_path - - -We now see that the ROS 2 includes got resolved too. - -.. image:: images/eclipse_c++_indexer_ok.png - :target: ../../_images/eclipse_c++_indexer_ok.png - :alt: eclipse_c++_indexer_ok - - -Adding Builder colcon, so that we can build with right-click on project and "Build project". - -.. image:: images/eclipse_c++_properties_builders.png - :target: ../../_images/eclipse_c++_properties_builders.png - :alt: eclipse_c++_properties_builders - - -.. image:: images/eclipse_c++_builder_main.png - :target: ../../_images/eclipse_c++_builder_main.png - :alt: eclipse_c++_builder_main - - -With PYTHONPATH you can also build python projects. - -.. image:: images/eclipse_c++_builder_env.png - :target: ../../_images/eclipse_c++_builder_env.png - :alt: eclipse_c++_builder_env - - -.. image:: images/eclipse_c++_properties_builders_with_colcon.png - :target: ../../_images/eclipse_c++_properties_builders_with_colcon.png - :alt: eclipse_c++_properties_builders_with_colcon - - -Right-click on the project and select "Build Project". - -.. image:: images/eclipse_c++_build_project_with_colcon.png - :target: ../../_images/eclipse_c++_build_project_with_colcon.png - :alt: eclipse_c++_build_project_with_colcon +.. redirect-from:: + + Tutorials/Building-ROS2-Package-with-eclipse-2021-06 + +Building a package with Eclipse 2021-06 +======================================= + +.. contents:: Table of Contents + :depth: 2 + :local: + +You cannot create a ROS 2 package with eclipse, you need to create it with commandline tools. +Follow the :doc:`Create a package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` tutorial. + +After you created your project, you can edit the source code and build it with eclipse. + +We start eclipse and select a eclipse-workspace. + +.. image:: images/eclipse_work_dir.png + :target: ../../_images/eclipse_work_dir.png + :alt: eclipse_work_dir + +We create a C++ project + +.. image:: images/eclipse_create_c++_project.png + :target: ../../_images/eclipse_create_c++_project.png + :alt: eclipse_create_c++_project + + +.. image:: images/eclipse_c++_project_select_type.png + :target: ../../_images/eclipse_c++_project_select_type.png + :alt: eclipse_c++_project_select_type + +We see that we got C++ includes. + +.. image:: images/eclipse_c++_project_includes.png + :target: ../../_images/eclipse_c++_project_includes.png + :alt: eclipse_c++_project_includes + + +We now import our ROS 2 project. +The code is still in the old place. + +.. image:: images/eclipse_import_project.png + :target: ../../_images/eclipse_import_project.png + :alt: eclipse_import_project + +.. image:: images/eclipse_import_filesystem.png + :target: ../../_images/eclipse_import_filesystem.png + :alt: eclipse_import_filesystem + +Click the Advanced in the Options and check the **Create links in worksapce**. + +.. image:: images/eclipse_import_select_my_package.png + :target: ../../_images/eclipse_import_select_my_package.png + :alt: eclipse_import_select_my_package + + + +We see in the source code that the C++ includes got resolved but not the ROS 2 ones. + +.. image:: images/eclipse_c++_wo_ros_includes.png + :target: ../../_images/eclipse_c++_wo_ros_includes.png + :alt: eclipse_c++_wo_ros_includes + + +.. image:: images/eclipse_c++_path_and_symbols.png + :target: ../../_images/eclipse_c++_path_and_symbols.png + :alt: eclipse_c++_path_and_symbols + +Add include paths of needed packages. +(e.g. **/opt/ros/lyrical/include/rclcpp**, **/opt/ros/lyrical/include/std_msgs**, etc.) + +.. image:: images/eclipse_c++_add_directory_path.png + :target: ../../_images/eclipse_c++_add_directory_path.png + :alt: eclipse_c++_add_directory_path + + +We now see that the ROS 2 includes got resolved too. + +.. image:: images/eclipse_c++_indexer_ok.png + :target: ../../_images/eclipse_c++_indexer_ok.png + :alt: eclipse_c++_indexer_ok + + +Adding Builder colcon, so that we can build with right-click on project and "Build project". + +.. image:: images/eclipse_c++_properties_builders.png + :target: ../../_images/eclipse_c++_properties_builders.png + :alt: eclipse_c++_properties_builders + + +.. image:: images/eclipse_c++_builder_main.png + :target: ../../_images/eclipse_c++_builder_main.png + :alt: eclipse_c++_builder_main + + +With PYTHONPATH you can also build python projects. + +.. image:: images/eclipse_c++_builder_env.png + :target: ../../_images/eclipse_c++_builder_env.png + :alt: eclipse_c++_builder_env + + +.. image:: images/eclipse_c++_properties_builders_with_colcon.png + :target: ../../_images/eclipse_c++_properties_builders_with_colcon.png + :alt: eclipse_c++_properties_builders_with_colcon + + +Right-click on the project and select "Build Project". + +.. image:: images/eclipse_c++_build_project_with_colcon.png + :target: ../../_images/eclipse_c++_build_project_with_colcon.png + :alt: eclipse_c++_build_project_with_colcon diff --git a/source/index.rst b/source/index.rst index 25bcca04732..a9ccd1b1b1b 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,203 +1,203 @@ -.. redirect-from:: - - Docs-Guide - -ROS 2 Documentation -=================== - -.. toctree:: - :titlesonly: - :maxdepth: 1 - :hidden: - - Get-Started - ROS-Framework - Capabilities - Developer-Tools - Migration-and-Upgrades - Integrations-and-related - The-ROS2-Project - Related-Projects - Contact - Glossary - Citations - - -**The Robot Operating System (ROS) is a set of software libraries and tools for building robot applications.** -From drivers and state-of-the-art algorithms to powerful developer tools, ROS has the open source tools you need for your next robotics project. - -:ref:`Learn more about ROS ` - -Since ROS was started in 2007, a lot has changed in the robotics and ROS community. -The goal of the ROS 2 project is to adapt to these changes, leveraging what is great about ROS 1 and improving what isn't. - -**Are you looking for documentation for a particular ROS package like MoveIt, image_proc, or octomap?** -Please see `ROS Index `__ or check out `this index of per-package documentation `__. - -This site contains the documentation for ROS 2. -If you are looking for ROS 1 documentation, check out the `ROS wiki `__. - -If you use ROS 2 in your work, please see :doc:`Citations ` to cite ROS 2. - -Getting started ---------------- - -* :doc:`Installation ` - - - Instructions to set up ROS 2 for the first time - -* :doc:`Tutorials ` - - - The best place to start for new users! - - Hands-on sample projects that help you build a progression of necessary skills - -* :doc:`How-To-Guides` - - - Quick answers to your "How do I...?" - questions without working through the :doc:`Tutorials ` - -* :doc:`Concepts ` - - - High-level explanations of core ROS 2 concepts covered in the :doc:`Tutorials ` - -* :doc:`Contact ` - - - Answers to your questions or a forum to start a discussion - - -The ROS 2 project ------------------ - -If you're interested in the advancement of the ROS 2 project: - -* :doc:`Contributing ` - - - Best practices and methodology for contributing to ROS 2, as well as instructions for migrating existing ROS 1 content to ROS 2 - -* :doc:`Distributions ` - - - Past, present and future ROS 2 distributions - -* :doc:`Features Status ` - - - Features in the current release - -* :doc:`Feature Ideas ` - - - Ideas for nice-to-have features that are not under active development - -* :doc:`Roadmap ` - - - Planned work for ROS 2 development - -* :doc:`ROSCon Talks ` - - - Presentations by the community on ROS 2 - -* :doc:`Project Governance ` - - - Information about the ROS Technical Steering Committee, Working Groups, and upcoming events - -* :doc:`Marketing ` - - - Downloadable marketing materials - - `Information about the ROS trademark `__ - -* :doc:`Adopters ` - - - Organizations and projects using ROS - -ROS community resources ------------------------ - -If you need help, have an idea, or would like to contribute to the project, please visit our ROS community resources. - -* `Official ROS Zulip Channel for discussion and support `__ (ROS 1, ROS 2) - -* `Robotics Stack Exchange - community Q&A website `__ (ROS 1, ROS 2) - - - See :ref:`Contact Page ` for more information - -* `Open Robotics Discourse `__ (ROS 1, ROS 2) - - - Forum for general discussions and announcements for the ROS community - - See the :ref:`Contact Page ` for more information - -* `ROS Index `__ (ROS 1, ROS 2) - - - Indexed list of all packages (i.e. `Python Package Index (PyPI) `_ for ROS packages) - - See which ROS distributions a package supports - - Link to a package's repository, API documentation, or website - - Inspect a package's license, build type, maintainers, status, and dependencies - - Get more info for a package on `Robotics Stack Exchange `__ - -* `ROS resource status page `__ (ROS 1, ROS 2) - - - Check the current status of ROS resources like Discourse or the ROS build farm. - -* `ROS Infrastructure Project Page `__ (ROS 1, ROS 2) - - - The ROS Infrastructure Project maintains the `ROS Build Farm `__ which builds the binary packages available on `ROS Index `__. - - The ROS Infrastructure Project also develops and maintains tools commonly associated with ROS like `Bloom `__ and `Colcon `__. - -General ROS project resources ------------------------------ - -* `Robotics Enhancement Proposals (REPs) `__ (ROS 1, ROS 2) - - - Proposals for new designs and conventions - -* `ROS Robots `__ (ROS 1, ROS 2) - - - Showcases robots projects from the community - - Instructions on how to contribute a robot - -* `ROS Wiki `__ (ROS 1) - - - ROS 1 documentation and user modifiable content - - Active until at least the last ROS 1 distribution is EOL - -* `ROS.org `__ (ROS 1, ROS 2) - - - ROS 1 and ROS 2 product landing page, with high-level description of ROS and links to other ROS sites - -Events ------- - -* `Official ROS Vimeo Channel `__ (ROS 1, ROS 2) - - - Videos of ROSCon Talks, community and working group meetings, and project demos. - -* `ROSCon website `__ (ROS 1, ROS 2) - - - ROSCon is our annual ROS developer conference. - - This page also lists regional ROS events like ROSConJP and ROSConFr. - -* `Open Source Robotics Foundation official events calendar `__ - - - This calendar is for official OSRF Events and working group meetings. - -* `Open Source Robotics Foundation community calendar `__ - - - This calendar is for unofficial ROS community events. - - `Submit your events here `__. - -Miscellaneous -------------- -* `Purchase official ROS swag `__ - -* ROS on social media - - - `@OpenRoboticsOrg `__ and `@ROSOrg `__ on Twitter - - `Open Robotics on LinkedIn `__ - -* Visit the `Open Source Robotics Foundation website `__ - - - Tax deductible charitable donations to the Open Source Robotics Foundation can be sent via `DonorBox. `__ - -Deprecated ----------- -* `ROS 2 Design `__ - - - Early design decisions behind ROS 2 development - - New design proposals should be submitted via `Robotics Enhancement Proposals (REPs) `__ +.. redirect-from:: + + Docs-Guide + +ROS 2 Documentation +=================== + +.. toctree:: + :titlesonly: + :maxdepth: 1 + :hidden: + + Get-Started + ROS-Framework + Capabilities + Developer-Tools + Migration-and-Upgrades + Integrations-and-related + The-ROS2-Project + Related-Projects + Contact + Glossary + Citations + + +**The Robot Operating System (ROS) is a set of software libraries and tools for building robot applications.** +From drivers and state-of-the-art algorithms to powerful developer tools, ROS has the open source tools you need for your next robotics project. + +:ref:`Learn more about ROS ` + +Since ROS was started in 2007, a lot has changed in the robotics and ROS community. +The goal of the ROS 2 project is to adapt to these changes, leveraging what is great about ROS 1 and improving what isn't. + +**Are you looking for documentation for a particular ROS package like MoveIt, image_proc, or octomap?** +Please see `ROS Index `__ or check out `this index of per-package documentation `__. + +This site contains the documentation for ROS 2. +If you are looking for ROS 1 documentation, check out the `ROS wiki `__. + +If you use ROS 2 in your work, please see :doc:`Citations ` to cite ROS 2. + +Getting started +--------------- + +* :doc:`Installation ` + + - Instructions to set up ROS 2 for the first time + +* :doc:`Tutorials ` + + - The best place to start for new users! + - Hands-on sample projects that help you build a progression of necessary skills + +* :doc:`How-To-Guides` + + - Quick answers to your "How do I...?" + questions without working through the :doc:`Tutorials ` + +* :doc:`Concepts ` + + - High-level explanations of core ROS 2 concepts covered in the :doc:`Tutorials ` + +* :doc:`Contact ` + + - Answers to your questions or a forum to start a discussion + + +The ROS 2 project +----------------- + +If you're interested in the advancement of the ROS 2 project: + +* :doc:`Contributing ` + + - Best practices and methodology for contributing to ROS 2, as well as instructions for migrating existing ROS 1 content to ROS 2 + +* :doc:`Distributions ` + + - Past, present and future ROS 2 distributions + +* :doc:`Features Status ` + + - Features in the current release + +* :doc:`Feature Ideas ` + + - Ideas for nice-to-have features that are not under active development + +* :doc:`Roadmap ` + + - Planned work for ROS 2 development + +* :doc:`ROSCon Talks ` + + - Presentations by the community on ROS 2 + +* :doc:`Project Governance ` + + - Information about the ROS Technical Steering Committee, Working Groups, and upcoming events + +* :doc:`Marketing ` + + - Downloadable marketing materials + - `Information about the ROS trademark `__ + +* :doc:`Adopters ` + + - Organizations and projects using ROS + +ROS community resources +----------------------- + +If you need help, have an idea, or would like to contribute to the project, please visit our ROS community resources. + +* `Official ROS Zulip Channel for discussion and support `__ (ROS 1, ROS 2) + +* `Robotics Stack Exchange - community Q&A website `__ (ROS 1, ROS 2) + + - See :ref:`Contact Page ` for more information + +* `Open Robotics Discourse `__ (ROS 1, ROS 2) + + - Forum for general discussions and announcements for the ROS community + - See the :ref:`Contact Page ` for more information + +* `ROS Index `__ (ROS 1, ROS 2) + + - Indexed list of all packages (i.e. `Python Package Index (PyPI) `_ for ROS packages) + - See which ROS distributions a package supports + - Link to a package's repository, API documentation, or website + - Inspect a package's license, build type, maintainers, status, and dependencies + - Get more info for a package on `Robotics Stack Exchange `__ + +* `ROS resource status page `__ (ROS 1, ROS 2) + + - Check the current status of ROS resources like Discourse or the ROS build farm. + +* `ROS Infrastructure Project Page `__ (ROS 1, ROS 2) + + - The ROS Infrastructure Project maintains the `ROS Build Farm `__ which builds the binary packages available on `ROS Index `__. + - The ROS Infrastructure Project also develops and maintains tools commonly associated with ROS like `Bloom `__ and `Colcon `__. + +General ROS project resources +----------------------------- + +* `Robotics Enhancement Proposals (REPs) `__ (ROS 1, ROS 2) + + - Proposals for new designs and conventions + +* `ROS Robots `__ (ROS 1, ROS 2) + + - Showcases robots projects from the community + - Instructions on how to contribute a robot + +* `ROS Wiki `__ (ROS 1) + + - ROS 1 documentation and user modifiable content + - Active until at least the last ROS 1 distribution is EOL + +* `ROS.org `__ (ROS 1, ROS 2) + + - ROS 1 and ROS 2 product landing page, with high-level description of ROS and links to other ROS sites + +Events +------ + +* `Official ROS Vimeo Channel `__ (ROS 1, ROS 2) + + - Videos of ROSCon Talks, community and working group meetings, and project demos. + +* `ROSCon website `__ (ROS 1, ROS 2) + + - ROSCon is our annual ROS developer conference. + - This page also lists regional ROS events like ROSConJP and ROSConFr. + +* `Open Source Robotics Foundation official events calendar `__ + + - This calendar is for official OSRF Events and working group meetings. + +* `Open Source Robotics Foundation community calendar `__ + + - This calendar is for unofficial ROS community events. + - `Submit your events here `__. + +Miscellaneous +------------- +* `Purchase official ROS swag `__ + +* ROS on social media + + - `@OpenRoboticsOrg `__ and `@ROSOrg `__ on Twitter + - `Open Robotics on LinkedIn `__ + +* Visit the `Open Source Robotics Foundation website `__ + + - Tax deductible charitable donations to the Open Source Robotics Foundation can be sent via `DonorBox. `__ + +Deprecated +---------- +* `ROS 2 Design `__ + + - Early design decisions behind ROS 2 development + - New design proposals should be submitted via `Robotics Enhancement Proposals (REPs) `__ From b0d381da253d9fd36a719b5df34422ba1c7ccc23 Mon Sep 17 00:00:00 2001 From: dmarshant Date: Mon, 25 May 2026 14:52:59 +0100 Subject: [PATCH 10/20] Fixed top-level heading lengths --- source/Capabilities/About-Motion-planning.rst | 2 +- source/Capabilities/About-Perception.rst | 2 +- source/Capabilities/About-Simulation.rst | 2 +- source/Capabilities/About-User-interfaces.rst | 2 +- source/Developer-Tools.rst | 2 +- source/Developer-Tools/About-Build.rst | 2 +- source/Developer-Tools/About-Debugging.rst | 2 +- .../About-introspection-and-analysis.rst | 2 +- .../Developer-Tools/About-visualization.rst | 2 +- .../Build/Documenting-a-ROS-2-Package.rst | 496 +++---- source/Developer-Tools/Launch/Launch-Main.rst | 90 +- source/Get-Started.rst | 2 +- .../Get-Started/Installation/Alternatives.rst | 40 +- .../Working-with-RTI-Connext-DDS.rst | 320 ++--- .../Installation/ROS-2-Mirrors.rst | 246 ++-- source/Integrations-and-related.rst | 2 +- .../MVSim/Defining-Worlds-MVSim.rst | 690 ++++----- .../Simulators/Webots/Installation-Ubuntu.rst | 268 ++-- .../Webots/Installation-Windows.rst | 404 +++--- .../Setting-Up-Simulation-Webots-Basic.rst | 1052 +++++++------- source/Migration-and-Upgrades.rst | 2 +- source/ROS-Framework.rst | 2 +- .../actions/Working-with-actions.rst | 2 +- .../Working-with-Client-Libraries.rst | 2 +- .../interfaces/Working-with-interfaces.rst | 2 +- .../nodes/Working-with-nodes.rst | 2 +- .../parameters/Working-with-parameters.rst | 2 +- .../services/Working-with-services.rst | 2 +- .../topics/Working-with-topics.rst | 2 +- .../Contributing/Build-Farms.rst | 2 +- .../Contributing-To-ROS-2-Documentation.rst | 1250 ++++++++--------- 31 files changed, 2449 insertions(+), 2449 deletions(-) diff --git a/source/Capabilities/About-Motion-planning.rst b/source/Capabilities/About-Motion-planning.rst index 37e763195dd..a620c3a3973 100644 --- a/source/Capabilities/About-Motion-planning.rst +++ b/source/Capabilities/About-Motion-planning.rst @@ -1,5 +1,5 @@ Motion planning -======= +=============== .. toctree:: :maxdepth: 1 diff --git a/source/Capabilities/About-Perception.rst b/source/Capabilities/About-Perception.rst index 760bb1012db..28c32d6323d 100644 --- a/source/Capabilities/About-Perception.rst +++ b/source/Capabilities/About-Perception.rst @@ -1,5 +1,5 @@ Perception -======= +========== .. toctree:: :maxdepth: 1 diff --git a/source/Capabilities/About-Simulation.rst b/source/Capabilities/About-Simulation.rst index 3af7723abe2..b1798aaaf54 100644 --- a/source/Capabilities/About-Simulation.rst +++ b/source/Capabilities/About-Simulation.rst @@ -1,5 +1,5 @@ Simulation -======= +========== .. toctree:: :maxdepth: 1 diff --git a/source/Capabilities/About-User-interfaces.rst b/source/Capabilities/About-User-interfaces.rst index e99a3ba1ab8..d19eab2a596 100644 --- a/source/Capabilities/About-User-interfaces.rst +++ b/source/Capabilities/About-User-interfaces.rst @@ -1,5 +1,5 @@ User interfaces -======= +=============== .. toctree:: :maxdepth: 1 diff --git a/source/Developer-Tools.rst b/source/Developer-Tools.rst index 3ba2a9575e2..07771aed1cb 100644 --- a/source/Developer-Tools.rst +++ b/source/Developer-Tools.rst @@ -1,5 +1,5 @@ Developer Tools -======= +=============== PLACEHOLDER diff --git a/source/Developer-Tools/About-Build.rst b/source/Developer-Tools/About-Build.rst index 959f5ddeedd..c28fd888122 100644 --- a/source/Developer-Tools/About-Build.rst +++ b/source/Developer-Tools/About-Build.rst @@ -1,5 +1,5 @@ Building -======= +======== PLACEHOLDER diff --git a/source/Developer-Tools/About-Debugging.rst b/source/Developer-Tools/About-Debugging.rst index 0cb5e5c9b19..1dd572a3a42 100644 --- a/source/Developer-Tools/About-Debugging.rst +++ b/source/Developer-Tools/About-Debugging.rst @@ -1,5 +1,5 @@ Debugging -======= +========= PLACEHOLDER diff --git a/source/Developer-Tools/About-introspection-and-analysis.rst b/source/Developer-Tools/About-introspection-and-analysis.rst index d8a1a4c8089..73f50a41d7f 100644 --- a/source/Developer-Tools/About-introspection-and-analysis.rst +++ b/source/Developer-Tools/About-introspection-and-analysis.rst @@ -1,5 +1,5 @@ Introspection and analysis -======= +========================== PLACEHOLDER diff --git a/source/Developer-Tools/About-visualization.rst b/source/Developer-Tools/About-visualization.rst index eae816d7693..900d185f9d7 100644 --- a/source/Developer-Tools/About-visualization.rst +++ b/source/Developer-Tools/About-visualization.rst @@ -1,5 +1,5 @@ Visualization -======= +============= PLACEHOLDER diff --git a/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst b/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst index 9af64c99ce8..d68dda360d2 100644 --- a/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst +++ b/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst @@ -1,249 +1,249 @@ -.. redirect-from:: - - How-To-Guides/Documenting-a-ROS-2-Package - -Documenting a ROS 2 package -########################### - -.. contents:: Table of Contents - :depth: 2 - :local: - - -This guide introduces the standard way to create documentation for ROS 2 packages. -For packages with binary releases this also results in the docs being hosted at ``docs.ros.org/en//p//``. -For information on how to contribute to this documentation on docs.ros.org, see :doc:`Contributing to ROS 2 Documentation <../../The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation>`. - -Prerequisites -------------- - -- :doc:`Install ROS <../../Installation>` - -- `Install rosdoc2 `__ - -Package Documentation Overview ------------------------------- - -The type of documentation discussed in this guide is referred to as "package docs" or "API docs". -For ROS packages that have been released on ROS Index, their documentation will be built on the ROS buildfarm, included on docs.ros.org, and visible via the ``API Docs`` button on index.ros.org. - -The tool responsible for generating ROS 2 package docs is `rosdoc2 `__. - -``rosdoc2`` is a convenient wrapper around the commonly used `Sphinx `__ documentation framework. -Sphinx allows freeform written documentation as well as API documentation for python code generated from comments in the code. -The `breathe `__ + `exhale `__ packages allow integration with Doxygen, to include autogenerated C++ API documentation as well. - -``rosdoc2`` creates a default configuration for packages with no documentation or configuration at all, and applies options for a uniform theme and integration with other packages. - -Building Package Docs ---------------------- - -To generate the documentation for a package in HTML format with ``rosdoc2``, run: - -.. code-block:: console - - $ rosdoc2 build --package-path - -The documentation is written to ``docs_output//index.html`` and can be viewed in a browser. - -Configuration -------------- - -There are three configuration locations for ROS package docs: ``rosdoc2.yaml`` for general settings, -``conf.py`` for sphinx settings and the ``Doxyfile`` for doxygen settings. -For all of those, a default is assumed or generated if not present, so none of them is strictly required. -However, it might be necessary to create and modify those once you want to use features such as custom textual documentation pages. - -rosdoc2.yaml -^^^^^^^^^^^^ - -This is the main entrypoint for rosdoc2. -It specifies generic settings, and can be used to control the execution of specific builders (Doxygen and Sphinx) and decides which builders to run. - -``rosdoc2`` provides a multitude of configuration options, which can be adjusted in a config file ``rosdoc2.yaml``. -To generate a default ``rosdoc2.yaml`` which you can then further customize, run: - -.. code-block:: console - - $ rosdoc2 default_config --package-path - -And add ``rosdoc2.yaml`` to the export section in your ``package.xml``: - -.. code-block:: xml - - - - - - rosdoc2.yaml - - - -However, for most packages, the default settings in ``rosdoc2`` will suffice, and no custom config is necessary. -More information about ``rosdoc2.yaml`` can be found in the `rosdoc2 readme `__. - -conf.py, rosdoc2_settings -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The final output of the package docs is (almost) always built by Sphinx. -Each Sphinx project is configured by a ``conf.py`` file in the ``doc`` directory. -If no configuration is present, a default Sphinx project is created and used when building the documentation. -If however a ``conf.py`` Sphinx config is found in the ``doc`` subdirectory of the package, this is used instead. -A custom Sphinx project is required if you want to include a standalone reStructuredText documentation page. -A standalone documentation page can be used to list multiple tutorials and guides; if that's something you want for your package you'll need to create a custom Sphinx project. - -``rosdoc2`` provides additional settings to ``conf.py`` and overrides some. -Information about changes done to the Sphinx settings are logged to the console with a ``[rosdoc2]`` prefix. - -Doxyfile -^^^^^^^^ - -Doxygen is a tool for automatically generating C++ API docs from code comments. -While Doxygen can also generate HTML output directly, in the usual workflow for ROS packages, Doxygen produces machine readable output in XML format which is then consumed by Sphinx and integrated with the rest of the documentation. -Doxygen-only docs are possible by only enabling the Doxygen builder in ``rosdoc2.yaml``, but this is uncommon. - -Customizing Sphinx Documentation --------------------------------- - -Creating a Sphinx Project -^^^^^^^^^^^^^^^^^^^^^^^^^ - -In order to add standalone documentation pages in addition to the automatically generated API docs, a custom Sphinx project is necessary. -This should be created in a subdirectory called ``doc`` in the package directory. -A new Sphinx project can be created by running ``sphinx-quickstart`` in the ``doc`` directory, answering ``no`` to "Separate source and build directories". -The wizard requires entering the project name, author and version, but this can later be removed and will be provided to Sphinx by ``rosdoc2`` from your packages ``package.xml``. -More information about creating a sphinx project can be found on the `Sphinx quickstart page `__, - -Customizing ``index.rst`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``sphinx-quickstart`` wizard creates an ``index.rst`` file, which is the custom landing page for your package, similar to a Github ``README`` file. - -Adding Python API-Docs -^^^^^^^^^^^^^^^^^^^^^^ - -By default ``rosdoc2`` uses the `sphinx-apidoc tool `__ and the `autodoc Sphinx extension `__ to automatically generate documentation for python code. -In order for autodoc to find the Python modules in your package, it must be added to the python search path in ``conf.py``: - -.. code-block:: python - - sys.path.insert(0, os.path.abspath('.')) - -This is because ``rosdoc2`` wraps the custom ``conf.py`` with more configuration from a script which will be placed in the package. -In this case the ``.`` path in ``os.path.abspath`` refers to the package's directory root, not the package's ``doc`` directory due to the interaction between rosdoc2 and ``conf.py``. - -By default, package API docs are already reachable through the "Module Index" link that is present on the landing page. -For the API docs to also appear in the table of contents, simply add a link to the ``modules`` page to your ``index.rst``: - -.. code-block:: rst - - .. toctree:: - :maxdepth: 2 - :caption: Contents: - - Python Modules - -Adding C++ API-Docs -^^^^^^^^^^^^^^^^^^^ - -If you would like to add your automatically generated API docs back to your custom landing page, add the line ``generated/index`` to your documentation page where you would like the API docs to appear: - -.. code-block:: rst - - .. toctree:: - :maxdepth: 2 - - C++ API Docs - -This adds the elements "Class Hierarchy", "File Hierarchy" and "Reference" to the table of contents in the sidebar. -To make those appear under one "C++ API Docs" heading for a less cluttered sidebar, a separate file such as ``cpp_api_docs.rst`` can be added, which links to the generated docs: - -.. code-block:: rst - :caption: cpp_api_docs.rst - - C++ API Docs - ============ - - These are the autogenerated docs for the internal implementation. - - .. toctree:: - :maxdepth: 3 - :caption: Contents: - - generated/index - -Which then also needs to be added in ``index.rst`` to appear in the sidebar: - -.. code-block:: rst - :caption: index.rst - - .. toctree:: - :maxdepth: 2 - :caption: Contents: - - cpp_api_docs - - -Including an existing README.md -------------------------------- - -If your git repository already has an existing ``README.md``, it is possible to reuse this as the landing page for the documentation, without duplicating the contents. -To correctly include a Markdown file in Sphinx while preserving relative links and images, some additional effort is required. - -First, create a proxy-file ``readme_include.md`` next to ``index.rst``. -This is a markdown file which just includes the original README.md, but preserves the relative image paths, which would otherwise break in the next step: - -.. code-block:: markdown - :caption: readme_include.md - - ```{include} ../README.md - :relative-images: - ``` - - -Then, include the contents of this file from ``index.rst`` using ``myst`` to include markdown from rst: - -.. code-block:: rst - :caption: index.rst - - .. include:: readme_include.md - :parser: myst_parser.sphinx_ - - -This also requires adding ``myst_parser`` to the extensions in ``conf.py``: - -.. code-block:: python - :caption: conf.py - - extensions = ["myst_parser"] - - -CI, docs.ros.org ----------------- - -The ROS build farm uses ``rosdoc2`` to build the package documentation hosted at ``docs.ros.org/en//p//``. -To enable this, the repository containing the documentation must be configured in `rosdistro/{DISTRO}/distribution.yaml `__. -This would usually be the package source repository: - -.. code-block:: yaml - - : - doc: - type: git - url: https://github.com//.git - version: main - release: - [...] - -The buildfarm hosts the documentation for every distribution separately, and periodically rebuilds it from the latest commit on the specified branch. -It is not required to tag a new release to update the hosted documentation. -To view the status of your package's documentation build, search for ``doc__`` on ``__. -One job is created for every distribution for which the package is released. -On each job page, you can see when a build was last triggered, as well as the status and logs of each build. - -Further Reading ---------------- - -* `rosdoc2 readme `_ -* `ROS 2 design document on package documentation `_ +.. redirect-from:: + + How-To-Guides/Documenting-a-ROS-2-Package + +Documenting a ROS 2 package +########################### + +.. contents:: Table of Contents + :depth: 2 + :local: + + +This guide introduces the standard way to create documentation for ROS 2 packages. +For packages with binary releases this also results in the docs being hosted at ``docs.ros.org/en//p//``. +For information on how to contribute to this documentation on docs.ros.org, see :doc:`Contributing to ROS 2 Documentation <../../The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation>`. + +Prerequisites +------------- + +- :doc:`Install ROS <../../Installation>` + +- `Install rosdoc2 `__ + +Package Documentation Overview +------------------------------ + +The type of documentation discussed in this guide is referred to as "package docs" or "API docs". +For ROS packages that have been released on ROS Index, their documentation will be built on the ROS buildfarm, included on docs.ros.org, and visible via the ``API Docs`` button on index.ros.org. + +The tool responsible for generating ROS 2 package docs is `rosdoc2 `__. + +``rosdoc2`` is a convenient wrapper around the commonly used `Sphinx `__ documentation framework. +Sphinx allows freeform written documentation as well as API documentation for python code generated from comments in the code. +The `breathe `__ + `exhale `__ packages allow integration with Doxygen, to include autogenerated C++ API documentation as well. + +``rosdoc2`` creates a default configuration for packages with no documentation or configuration at all, and applies options for a uniform theme and integration with other packages. + +Building Package Docs +--------------------- + +To generate the documentation for a package in HTML format with ``rosdoc2``, run: + +.. code-block:: console + + $ rosdoc2 build --package-path + +The documentation is written to ``docs_output//index.html`` and can be viewed in a browser. + +Configuration +------------- + +There are three configuration locations for ROS package docs: ``rosdoc2.yaml`` for general settings, +``conf.py`` for sphinx settings and the ``Doxyfile`` for doxygen settings. +For all of those, a default is assumed or generated if not present, so none of them is strictly required. +However, it might be necessary to create and modify those once you want to use features such as custom textual documentation pages. + +rosdoc2.yaml +^^^^^^^^^^^^ + +This is the main entrypoint for rosdoc2. +It specifies generic settings, and can be used to control the execution of specific builders (Doxygen and Sphinx) and decides which builders to run. + +``rosdoc2`` provides a multitude of configuration options, which can be adjusted in a config file ``rosdoc2.yaml``. +To generate a default ``rosdoc2.yaml`` which you can then further customize, run: + +.. code-block:: console + + $ rosdoc2 default_config --package-path + +And add ``rosdoc2.yaml`` to the export section in your ``package.xml``: + +.. code-block:: xml + + + + + + rosdoc2.yaml + + + +However, for most packages, the default settings in ``rosdoc2`` will suffice, and no custom config is necessary. +More information about ``rosdoc2.yaml`` can be found in the `rosdoc2 readme `__. + +conf.py, rosdoc2_settings +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The final output of the package docs is (almost) always built by Sphinx. +Each Sphinx project is configured by a ``conf.py`` file in the ``doc`` directory. +If no configuration is present, a default Sphinx project is created and used when building the documentation. +If however a ``conf.py`` Sphinx config is found in the ``doc`` subdirectory of the package, this is used instead. +A custom Sphinx project is required if you want to include a standalone reStructuredText documentation page. +A standalone documentation page can be used to list multiple tutorials and guides; if that's something you want for your package you'll need to create a custom Sphinx project. + +``rosdoc2`` provides additional settings to ``conf.py`` and overrides some. +Information about changes done to the Sphinx settings are logged to the console with a ``[rosdoc2]`` prefix. + +Doxyfile +^^^^^^^^ + +Doxygen is a tool for automatically generating C++ API docs from code comments. +While Doxygen can also generate HTML output directly, in the usual workflow for ROS packages, Doxygen produces machine readable output in XML format which is then consumed by Sphinx and integrated with the rest of the documentation. +Doxygen-only docs are possible by only enabling the Doxygen builder in ``rosdoc2.yaml``, but this is uncommon. + +Customizing Sphinx Documentation +-------------------------------- + +Creating a Sphinx Project +^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to add standalone documentation pages in addition to the automatically generated API docs, a custom Sphinx project is necessary. +This should be created in a subdirectory called ``doc`` in the package directory. +A new Sphinx project can be created by running ``sphinx-quickstart`` in the ``doc`` directory, answering ``no`` to "Separate source and build directories". +The wizard requires entering the project name, author and version, but this can later be removed and will be provided to Sphinx by ``rosdoc2`` from your packages ``package.xml``. +More information about creating a sphinx project can be found on the `Sphinx quickstart page `__, + +Customizing ``index.rst`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``sphinx-quickstart`` wizard creates an ``index.rst`` file, which is the custom landing page for your package, similar to a Github ``README`` file. + +Adding Python API-Docs +^^^^^^^^^^^^^^^^^^^^^^ + +By default ``rosdoc2`` uses the `sphinx-apidoc tool `__ and the `autodoc Sphinx extension `__ to automatically generate documentation for python code. +In order for autodoc to find the Python modules in your package, it must be added to the python search path in ``conf.py``: + +.. code-block:: python + + sys.path.insert(0, os.path.abspath('.')) + +This is because ``rosdoc2`` wraps the custom ``conf.py`` with more configuration from a script which will be placed in the package. +In this case the ``.`` path in ``os.path.abspath`` refers to the package's directory root, not the package's ``doc`` directory due to the interaction between rosdoc2 and ``conf.py``. + +By default, package API docs are already reachable through the "Module Index" link that is present on the landing page. +For the API docs to also appear in the table of contents, simply add a link to the ``modules`` page to your ``index.rst``: + +.. code-block:: rst + + .. toctree:: + :maxdepth: 2 + :caption: Contents: + + Python Modules + +Adding C++ API-Docs +^^^^^^^^^^^^^^^^^^^ + +If you would like to add your automatically generated API docs back to your custom landing page, add the line ``generated/index`` to your documentation page where you would like the API docs to appear: + +.. code-block:: rst + + .. toctree:: + :maxdepth: 2 + + C++ API Docs + +This adds the elements "Class Hierarchy", "File Hierarchy" and "Reference" to the table of contents in the sidebar. +To make those appear under one "C++ API Docs" heading for a less cluttered sidebar, a separate file such as ``cpp_api_docs.rst`` can be added, which links to the generated docs: + +.. code-block:: rst + :caption: cpp_api_docs.rst + + C++ API Docs +================ + + These are the autogenerated docs for the internal implementation. + + .. toctree:: + :maxdepth: 3 + :caption: Contents: + + generated/index + +Which then also needs to be added in ``index.rst`` to appear in the sidebar: + +.. code-block:: rst + :caption: index.rst + + .. toctree:: + :maxdepth: 2 + :caption: Contents: + + cpp_api_docs + + +Including an existing README.md +------------------------------- + +If your git repository already has an existing ``README.md``, it is possible to reuse this as the landing page for the documentation, without duplicating the contents. +To correctly include a Markdown file in Sphinx while preserving relative links and images, some additional effort is required. + +First, create a proxy-file ``readme_include.md`` next to ``index.rst``. +This is a markdown file which just includes the original README.md, but preserves the relative image paths, which would otherwise break in the next step: + +.. code-block:: markdown + :caption: readme_include.md + + ```{include} ../README.md + :relative-images: + ``` + + +Then, include the contents of this file from ``index.rst`` using ``myst`` to include markdown from rst: + +.. code-block:: rst + :caption: index.rst + + .. include:: readme_include.md + :parser: myst_parser.sphinx_ + + +This also requires adding ``myst_parser`` to the extensions in ``conf.py``: + +.. code-block:: python + :caption: conf.py + + extensions = ["myst_parser"] + + +CI, docs.ros.org +---------------- + +The ROS build farm uses ``rosdoc2`` to build the package documentation hosted at ``docs.ros.org/en//p//``. +To enable this, the repository containing the documentation must be configured in `rosdistro/{DISTRO}/distribution.yaml `__. +This would usually be the package source repository: + +.. code-block:: yaml + + : + doc: + type: git + url: https://github.com//.git + version: main + release: + [...] + +The buildfarm hosts the documentation for every distribution separately, and periodically rebuilds it from the latest commit on the specified branch. +It is not required to tag a new release to update the hosted documentation. +To view the status of your package's documentation build, search for ``doc__`` on ``__. +One job is created for every distribution for which the package is released. +On each job page, you can see when a build was last triggered, as well as the status and logs of each build. + +Further Reading +--------------- + +* `rosdoc2 readme `_ +* `ROS 2 design document on package documentation `_ * `The ROS 2 cookbook `_ \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Launch-Main.rst b/source/Developer-Tools/Launch/Launch-Main.rst index 2551371f146..c015b3c75d3 100644 --- a/source/Developer-Tools/Launch/Launch-Main.rst +++ b/source/Developer-Tools/Launch/Launch-Main.rst @@ -1,46 +1,46 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Launch-Main - Tutorials/Launch/Launch-Main - Tutorials/Intermediate/Launch/Launch-Main - -.. _LaunchFilesMain: - -Launch files -====== - -ROS 2 Launch files allow you to start up and configure a number of executables containing ROS 2 nodes simultaneously. - -.. toctree:: - :hidden: - - Creating-Launch-Files - Launch-system - Using-Substitutions - Using-Event-Handlers - Using-ROS2-Launch-For-Large-Projects - -#. :doc:`Creating a launch file `. - - Learn how to create a launch file that will start up nodes and their configurations all at once. - -#. :doc:`Launching and monitoring multiple nodes `. - - Get a more advanced overview of how launch files work. - -#. :doc:`Using substitutions `. - - Use substitutions to provide more flexibility when describing reusable launch files. - -#. :doc:`Using event handlers `. - - Use event handlers to monitor the state of processes or to define a complex set of rules that can be used to dynamically modify the launch file. - -#. :doc:`Managing large projects `. - - Structure launch files for large projects so they may be reused as much as possible in different situations. - See usage examples of different launch tools like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. - -.. note:: - +.. redirect-from:: + + Tutorials/Launch-Files/Launch-Main + Tutorials/Launch/Launch-Main + Tutorials/Intermediate/Launch/Launch-Main + +.. _LaunchFilesMain: + +Launch files +============ + +ROS 2 Launch files allow you to start up and configure a number of executables containing ROS 2 nodes simultaneously. + +.. toctree:: + :hidden: + + Creating-Launch-Files + Launch-system + Using-Substitutions + Using-Event-Handlers + Using-ROS2-Launch-For-Large-Projects + +#. :doc:`Creating a launch file `. + + Learn how to create a launch file that will start up nodes and their configurations all at once. + +#. :doc:`Launching and monitoring multiple nodes `. + + Get a more advanced overview of how launch files work. + +#. :doc:`Using substitutions `. + + Use substitutions to provide more flexibility when describing reusable launch files. + +#. :doc:`Using event handlers `. + + Use event handlers to monitor the state of processes or to define a complex set of rules that can be used to dynamically modify the launch file. + +#. :doc:`Managing large projects `. + + Structure launch files for large projects so they may be reused as much as possible in different situations. + See usage examples of different launch tools like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. + +.. note:: + If you are coming from ROS 1, you can use the :doc:`ROS Launch Migration guide <../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files>` to help you migrate your launch files to ROS 2. \ No newline at end of file diff --git a/source/Get-Started.rst b/source/Get-Started.rst index 43c8910382f..1c3651542df 100644 --- a/source/Get-Started.rst +++ b/source/Get-Started.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Get started -============ +=========== PLACEHOLDER diff --git a/source/Get-Started/Installation/Alternatives.rst b/source/Get-Started/Installation/Alternatives.rst index cc79b4db892..9ecd1f873ce 100644 --- a/source/Get-Started/Installation/Alternatives.rst +++ b/source/Get-Started/Installation/Alternatives.rst @@ -1,21 +1,21 @@ -.. redirect-from:: - - Installation/Alternatives - -Advanced installation options -============ - -A list of alternative ways to install ROS 2 – whether it's by building from source or installing a binary. - -.. toctree:: - :maxdepth: 1 - - Alternatives/Ubuntu-Development-Setup - Alternatives/Ubuntu-Development-Setup-Pixi - Alternatives/Ubuntu-Install-Binary - Alternatives/Windows-Development-Setup - Alternatives/RHEL-Development-Setup - Alternatives/RHEL-Install-Binary - Alternatives/macOS-Development-Setup - Alternatives/Latest-Development-Setup +.. redirect-from:: + + Installation/Alternatives + +Advanced installation options +============================= + +A list of alternative ways to install ROS 2 – whether it's by building from source or installing a binary. + +.. toctree:: + :maxdepth: 1 + + Alternatives/Ubuntu-Development-Setup + Alternatives/Ubuntu-Development-Setup-Pixi + Alternatives/Ubuntu-Install-Binary + Alternatives/Windows-Development-Setup + Alternatives/RHEL-Development-Setup + Alternatives/RHEL-Install-Binary + Alternatives/macOS-Development-Setup + Alternatives/Latest-Development-Setup Alternatives/Maintaining-a-Source-Checkout \ No newline at end of file diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst index e9d476b01b1..8842ef6e181 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst @@ -1,161 +1,161 @@ -.. redirect-from:: - - Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS - -RTI Connext DDS -================= - -RTI Connext DDS is trusted in over 2000 of the world's most demanding system designs, distributing critical real-time data with the highest levels of performance, reliability, and security. -It is free-of-charge for prototyping, research, non-commercial and academic use. -Visit the `RTI website `__ for more information and to learn about options for support and commercial licenses. - - -Prerequisites -------------- - -Install RTI Connext DDS -^^^^^^^^^^^^^^^^^^^^^^^ - To build and use ``rmw_connextdds`` requires a version of Connext DDS compatible with the distribution of ROS 2 in use. - Connext DDS is included when installing ``rmw_connextdds`` using apt, or can be installed manually for building from source. - The following table details which Connext DDS versions are installed using ``apt``, and which versions are required for building from source: - - ================== =================== ==================== - ROS 2 Distribution Installed using apt To Build from Source - ================== =================== ==================== - rolling n/a ``7.7.0`` - kilted ``7.3.0`` ``7.3.0`` - jazzy ``6.0.1`` ``6.0.1`` - humble ``6.0.1`` ``6.0.1`` - ================== =================== ==================== - -RTI Connext Pro is available through a variety of channels: - -**ROS 2 apt repositories** - ROS 2 users can install a non-commercial-use version of the RTI Connext DDS libraries from the ROS apt repository using the following command: - - .. tabs:: - - .. group-tab:: v7.7.0 - - .. code-block:: console - - $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.7.0-ros - - .. group-tab:: v7.3.0 - - .. code-block:: console - - $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.3.0-ros - - .. group-tab:: v6.0.1 - - .. code-block:: console - - $ sudo apt update && sudo apt install -q -y rti-connext-dds-6.0.1 - - This package includes the RTI Connext core DDS libraries only; it does not include the full Connext Professional suite of tools and run-time services. - Note that these Connext libraries are automatically installed when installing ``rmw_connextdds`` using apt. - -**Other Installation Options** -The `Connext Robotics Toolkit `__ includes the full suite of Connext tools and infrastructure services. -It provides a single step installation of ROS and Connext using apt. -It is free for prototype development, research, non-commercial and academic use. - -Detailed instructions for building and tuning the RMW and ROS 2 applications for a variety of platforms, and enabling DDS Security are available on the `RTI ROS Community `__ pages. - - -Install rmw_connextdds binary packages --------------------------------------- - -To install the binary packages for ``rmw_connextdds`` and the Connext libraries from the ROS 2 apt repositories, use the following command: - -.. code-block:: console - - $ sudo apt update && sudo apt install -q -y ros-{DISTRO}-rmw-connextdds - - -Building rmw_connextdds from source code ----------------------------------------- - -Building from source code can ensure the RMW is matched to your system and installed correctly. -The following instructions assume a Linux x86_64 build host and target; the `RTI ROS Community `__ -pages have instructions for building for other platforms and targets, including Arm, Windows, and macOS. - -Clone the repository for ``rmw_connextdds`` into your ROS 2 workspace and select the branch that matches the ROS 2 distribution in use: - -.. code-block:: console - - $ mkdir -p ros2_ws/src - $ cd ros2_ws - $ git clone -b {DISTRO} https://github.com/ros2/rmw_connextdds src/rmw_connextdds - -Then, install necessary packages for RTI Connext DDS. - -.. code-block:: console - - $ cd .. - $ rosdep install --from src -i - -Set up the environment to help colcon discover where RTI Connext is installed. -This can be done by manually setting the environment variable ``NDDSHOME`` to the location of the RTI Connext installation, or by using a script that comes with the RTI Connext installation. -For example, for version 7.7.0, you can run the following code to execute the helper script: - -.. code-block:: console - - $ source /opt/rti.com/rti_connext_dds-7.7.0/resource/scripts/rtisetenv_x64Linux4gcc8.5.0.bash - -If the previous command failed, and you can't find the location of the RTI Connext installation, run this to find all Connext installations (and their corresponding helper scripts) in your system: - -.. code-block:: console - - $ find /opt -name rtisetenv*.bash - -.. note:: - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``rtisetenv*.bash``, ``rtisetenv*.sh``, ``rtisetenv*.zsh``, ``rtisetenv*.tcsh``. - -Make sure you have the ROS 2 environment set up: - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Build the RMW using colcon: - -.. code-block:: console - - $ colcon build --symlink-install - -After the build completes successfully, be sure to source the setup file for the workspace: - -.. code-block:: console - - $ source install/setup.bash - - -Use the resulting rmw_connextdds --------------------------------- - -Set the environment variable ``RMW_IMPLEMENTATION`` to tell ROS 2 which RMW to use: - -.. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_connextdds - -See also: :doc:`Working with multiple RMW implementations <../Working-with-multiple-RMW-implementations>` - -Run the talker and listener ---------------------------- - -Now run ``talker`` and ``listener`` to test RTI Connext DDS - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp talker - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash +.. redirect-from:: + + Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS + +RTI Connext DDS +=============== + +RTI Connext DDS is trusted in over 2000 of the world's most demanding system designs, distributing critical real-time data with the highest levels of performance, reliability, and security. +It is free-of-charge for prototyping, research, non-commercial and academic use. +Visit the `RTI website `__ for more information and to learn about options for support and commercial licenses. + + +Prerequisites +------------- + +Install RTI Connext DDS +^^^^^^^^^^^^^^^^^^^^^^^ + To build and use ``rmw_connextdds`` requires a version of Connext DDS compatible with the distribution of ROS 2 in use. + Connext DDS is included when installing ``rmw_connextdds`` using apt, or can be installed manually for building from source. + The following table details which Connext DDS versions are installed using ``apt``, and which versions are required for building from source: + + ================== =================== ==================== + ROS 2 Distribution Installed using apt To Build from Source + ================== =================== ==================== + rolling n/a ``7.7.0`` + kilted ``7.3.0`` ``7.3.0`` + jazzy ``6.0.1`` ``6.0.1`` + humble ``6.0.1`` ``6.0.1`` + ================== =================== ==================== + +RTI Connext Pro is available through a variety of channels: + +**ROS 2 apt repositories** + ROS 2 users can install a non-commercial-use version of the RTI Connext DDS libraries from the ROS apt repository using the following command: + + .. tabs:: + + .. group-tab:: v7.7.0 + + .. code-block:: console + + $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.7.0-ros + + .. group-tab:: v7.3.0 + + .. code-block:: console + + $ sudo apt update && sudo apt install -q -y rti-connext-dds-7.3.0-ros + + .. group-tab:: v6.0.1 + + .. code-block:: console + + $ sudo apt update && sudo apt install -q -y rti-connext-dds-6.0.1 + + This package includes the RTI Connext core DDS libraries only; it does not include the full Connext Professional suite of tools and run-time services. + Note that these Connext libraries are automatically installed when installing ``rmw_connextdds`` using apt. + +**Other Installation Options** +The `Connext Robotics Toolkit `__ includes the full suite of Connext tools and infrastructure services. +It provides a single step installation of ROS and Connext using apt. +It is free for prototype development, research, non-commercial and academic use. + +Detailed instructions for building and tuning the RMW and ROS 2 applications for a variety of platforms, and enabling DDS Security are available on the `RTI ROS Community `__ pages. + + +Install rmw_connextdds binary packages +-------------------------------------- + +To install the binary packages for ``rmw_connextdds`` and the Connext libraries from the ROS 2 apt repositories, use the following command: + +.. code-block:: console + + $ sudo apt update && sudo apt install -q -y ros-{DISTRO}-rmw-connextdds + + +Building rmw_connextdds from source code +---------------------------------------- + +Building from source code can ensure the RMW is matched to your system and installed correctly. +The following instructions assume a Linux x86_64 build host and target; the `RTI ROS Community `__ +pages have instructions for building for other platforms and targets, including Arm, Windows, and macOS. + +Clone the repository for ``rmw_connextdds`` into your ROS 2 workspace and select the branch that matches the ROS 2 distribution in use: + +.. code-block:: console + + $ mkdir -p ros2_ws/src + $ cd ros2_ws + $ git clone -b {DISTRO} https://github.com/ros2/rmw_connextdds src/rmw_connextdds + +Then, install necessary packages for RTI Connext DDS. + +.. code-block:: console + + $ cd .. + $ rosdep install --from src -i + +Set up the environment to help colcon discover where RTI Connext is installed. +This can be done by manually setting the environment variable ``NDDSHOME`` to the location of the RTI Connext installation, or by using a script that comes with the RTI Connext installation. +For example, for version 7.7.0, you can run the following code to execute the helper script: + +.. code-block:: console + + $ source /opt/rti.com/rti_connext_dds-7.7.0/resource/scripts/rtisetenv_x64Linux4gcc8.5.0.bash + +If the previous command failed, and you can't find the location of the RTI Connext installation, run this to find all Connext installations (and their corresponding helper scripts) in your system: + +.. code-block:: console + + $ find /opt -name rtisetenv*.bash + +.. note:: + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``rtisetenv*.bash``, ``rtisetenv*.sh``, ``rtisetenv*.zsh``, ``rtisetenv*.tcsh``. + +Make sure you have the ROS 2 environment set up: + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Build the RMW using colcon: + +.. code-block:: console + + $ colcon build --symlink-install + +After the build completes successfully, be sure to source the setup file for the workspace: + +.. code-block:: console + + $ source install/setup.bash + + +Use the resulting rmw_connextdds +-------------------------------- + +Set the environment variable ``RMW_IMPLEMENTATION`` to tell ROS 2 which RMW to use: + +.. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_connextdds + +See also: :doc:`Working with multiple RMW implementations <../Working-with-multiple-RMW-implementations>` + +Run the talker and listener +--------------------------- + +Now run ``talker`` and ``listener`` to test RTI Connext DDS + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run demo_nodes_cpp talker + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash $ ros2 run demo_nodes_cpp listener \ No newline at end of file diff --git a/source/Get-Started/Installation/ROS-2-Mirrors.rst b/source/Get-Started/Installation/ROS-2-Mirrors.rst index de171811406..ff220a466a6 100644 --- a/source/Get-Started/Installation/ROS-2-Mirrors.rst +++ b/source/Get-Started/Installation/ROS-2-Mirrors.rst @@ -1,124 +1,124 @@ -.. redirect-from:: - - Installation/ROS-2-Mirrors - -======= -Mirrors -======= - -.. contents:: Table of Contents - :depth: 3 - -Docs Mirrors ------------- - -Mirrors of the ROS Docs act as a backup when the `main site `_ is unavailable, and may provide faster access to users who are geographically closer to the mirror. - -Debian/Ubuntu (APT) Repository Mirrors --------------------------------------- - -To use these mirrors, replace the official ROS repository URL with the one listed below in your APT configuration. - -Asia -^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - Tsinghua University (TUNA) - - China - - `https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu/ `_ - * - USTC - - China - - `https://mirrors.ustc.edu.cn/ros2/ubuntu/ `_ - * - Alibaba Cloud (Aliyun) - - China - - `https://mirrors.aliyun.com/ros2/ubuntu/ `_ - * - Qilu University of Technology (QLU) - - China - - `https://mirrors.qlu.edu.cn/ros2/ubuntu/ `_ - -Europe -^^^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - Delft University of Technology - - the Netherlands - - `http://ftp.tudelft.nl/ros2/ubuntu/ `_ - -North America -^^^^^^^^^^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - University of Maryland (UMD) - - USA - - `http://mirror.umd.edu/packages.ros.org/ros2/ubuntu/ `_ - -Oceania -^^^^^^^ - -.. list-table:: - :widths: 30 20 50 - - * - AARNet - - Australia - - `https://mirror.aarnet.edu.au/pub/ros2-packages/ubuntu/ `_ - -South America and Africa -^^^^^^^^^^^^^^^^^^^^^^^^ - -There are currently no officially verified ROS 2 mirrors for these regions. -If you are hosting a mirror in South America or Africa and would like it listed here, please see the **Hosting a Mirror** section below. - -Creating a mirror ------------------ - -If you are maintaining a mirror please join the Mirrors category on discourse.openrobotics.org: `https://discourse.openrobotics.org/c/infrastructure-project/infra-mirrors/ `_ for both feedback and prompt updates. - -Using a Mirror -^^^^^^^^^^^^^^ - -To use a mirror, replace ``packages.ros.org`` with the mirror URL in your ``ros2-latest.list`` file: - -.. code-block:: bash - - # Example for TUNA mirror - sudo sed -i 's|http://packages.ros.org/ros2/ubuntu|https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu|g' /etc/apt/sources.list.d/ros2-latest.list - sudo apt update - -Setting up a Mirror -------------------- - -The ROS infrastructure uses ``rsync`` to distribute packages. -To create a local mirror of the ROS 2 repositories: - -1. **Storage Requirement:** Ensure you have at least 500GB of available disk space. -2. **Sync Command:** Use ``rsync`` to pull from the official OSUOSL endpoints: - -.. code-block:: bash - - # Sync the main ROS 2 repository - rsync -azv rsync.osuosl.org::ros2-main /your/local/path --delete - -3. **Maintenance:** Set up a ``cron`` job to sync every 6-12 hours. - -Adding your mirror to this list -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To be officially listed, your mirror must meet the following requirements: - -* Support **HTTPS**. -* Sync at least once every 24 hours. -* Provide a contact email for infrastructure alerts. - -Once verified, please open a Pull Request against this page or post in the `Mirrors Discourse `_. - -Mirroring docs.ros.org ----------------------- - -Mirroring the documentation site requires specific configuration to prevent search engine fragmentation. +.. redirect-from:: + + Installation/ROS-2-Mirrors + + +Mirrors +======= + +.. contents:: Table of Contents + :depth: 3 + +Docs Mirrors +------------ + +Mirrors of the ROS Docs act as a backup when the `main site `_ is unavailable, and may provide faster access to users who are geographically closer to the mirror. + +Debian/Ubuntu (APT) Repository Mirrors +-------------------------------------- + +To use these mirrors, replace the official ROS repository URL with the one listed below in your APT configuration. + +Asia +^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - Tsinghua University (TUNA) + - China + - `https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu/ `_ + * - USTC + - China + - `https://mirrors.ustc.edu.cn/ros2/ubuntu/ `_ + * - Alibaba Cloud (Aliyun) + - China + - `https://mirrors.aliyun.com/ros2/ubuntu/ `_ + * - Qilu University of Technology (QLU) + - China + - `https://mirrors.qlu.edu.cn/ros2/ubuntu/ `_ + +Europe +^^^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - Delft University of Technology + - the Netherlands + - `http://ftp.tudelft.nl/ros2/ubuntu/ `_ + +North America +^^^^^^^^^^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - University of Maryland (UMD) + - USA + - `http://mirror.umd.edu/packages.ros.org/ros2/ubuntu/ `_ + +Oceania +^^^^^^^ + +.. list-table:: + :widths: 30 20 50 + + * - AARNet + - Australia + - `https://mirror.aarnet.edu.au/pub/ros2-packages/ubuntu/ `_ + +South America and Africa +^^^^^^^^^^^^^^^^^^^^^^^^ + +There are currently no officially verified ROS 2 mirrors for these regions. +If you are hosting a mirror in South America or Africa and would like it listed here, please see the **Hosting a Mirror** section below. + +Creating a mirror +----------------- + +If you are maintaining a mirror please join the Mirrors category on discourse.openrobotics.org: `https://discourse.openrobotics.org/c/infrastructure-project/infra-mirrors/ `_ for both feedback and prompt updates. + +Using a Mirror +^^^^^^^^^^^^^^ + +To use a mirror, replace ``packages.ros.org`` with the mirror URL in your ``ros2-latest.list`` file: + +.. code-block:: bash + + # Example for TUNA mirror + sudo sed -i 's|http://packages.ros.org/ros2/ubuntu|https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu|g' /etc/apt/sources.list.d/ros2-latest.list + sudo apt update + +Setting up a Mirror +------------------- + +The ROS infrastructure uses ``rsync`` to distribute packages. +To create a local mirror of the ROS 2 repositories: + +1. **Storage Requirement:** Ensure you have at least 500GB of available disk space. +2. **Sync Command:** Use ``rsync`` to pull from the official OSUOSL endpoints: + +.. code-block:: bash + + # Sync the main ROS 2 repository + rsync -azv rsync.osuosl.org::ros2-main /your/local/path --delete + +3. **Maintenance:** Set up a ``cron`` job to sync every 6-12 hours. + +Adding your mirror to this list +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To be officially listed, your mirror must meet the following requirements: + +* Support **HTTPS**. +* Sync at least once every 24 hours. +* Provide a contact email for infrastructure alerts. + +Once verified, please open a Pull Request against this page or post in the `Mirrors Discourse `_. + +Mirroring docs.ros.org +---------------------- + +Mirroring the documentation site requires specific configuration to prevent search engine fragmentation. If you are interested in hosting a regional mirror of the documentation, please **contact the infrastructure team** via Discourse before proceeding. \ No newline at end of file diff --git a/source/Integrations-and-related.rst b/source/Integrations-and-related.rst index 42a1e3bb2d1..93c7dc4d3cd 100644 --- a/source/Integrations-and-related.rst +++ b/source/Integrations-and-related.rst @@ -1,6 +1,6 @@ Integrations and related projects -============ +================================= PLACEHOLDER diff --git a/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst index c4085145faf..37b40b22782 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst @@ -1,346 +1,346 @@ -.. redirect-from:: - - Tutorials/Advanced/Simulators/MVSim/Defining-Worlds-MVSim - -Defining worlds, robots, and sensors -===================================== - -**Goal:** Learn the basics of defining MVSim world files, adding vehicles and sensors, and the main features available. - -**Tutorial level:** Advanced - -**Time:** 30 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -MVSim worlds are defined in XML files (``.world.xml``). -A world file describes the environment (ground, walls, obstacles), the vehicles (dynamics model, shape, sensors), -and simulation parameters (physics timestep, GUI options). - -MVSim provides a library of predefined vehicle and sensor definitions that you can reuse in your worlds via XML includes. -You can also define everything from scratch for full control. - -Prerequisites -------------- - -You should have completed the :doc:`Getting-Started-MVSim` tutorial and have MVSim installed. - -Tasks ------ - -1 Minimal world file -^^^^^^^^^^^^^^^^^^^^^^ - -Here is a minimal world file that creates an empty environment with one robot: - -.. code-block:: xml - - - - 5e-3 - - - - 15 - - - - - - - - - 0 0 0 - - - - - - - - - - - - - - - 4.1543 - 1.9118 - 0.0000 - 14.44 - 0.00 - - - - - - 100 5 50 - - - - -Save this as ``my_world.world.xml`` and launch it: - -.. code-block:: console - - $ mvsim launch my_world.world.xml - -2 Using predefined vehicles and sensors -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Instead of defining vehicles from scratch, you can use the predefined definitions that ship with MVSim. -These are XML files in the ``definitions/`` directory of the MVSim package. - -**Available vehicles:** - -- ``turtlebot3_burger.vehicle.xml`` -- TurtleBot3 Burger (differential drive) -- ``jackal.vehicle.xml`` -- Clearpath Jackal UGV (4-wheel differential) -- ``ackermann.vehicle.xml`` -- Generic Ackermann (car-like) vehicle -- ``pickup.vehicle.xml`` -- Pickup truck (Ackermann) -- ``agricobiot2.vehicle.xml`` -- Agricultural robot (Ackermann drivetrain) - -**Available sensors:** - -- ``lidar2d.sensor.xml`` -- Generic 2D laser scanner -- ``rplidar-a2.sensor.xml`` -- RPLidar A2 -- ``velodyne-vlp16.sensor.xml`` -- Velodyne VLP-16 3D LiDAR -- ``ouster-os1.sensor.xml`` -- Ouster OS1 3D LiDAR -- ``helios-32-FOV-70.sensor.xml`` -- Helios 32-beam 3D LiDAR -- ``camera.sensor.xml`` -- RGB camera -- ``rgbd_camera.sensor.xml`` -- Depth camera (RGBD) -- ``imu.sensor.xml`` -- Inertial measurement unit -- ``gnss.sensor.xml`` -- GPS/GNSS receiver - -To use a predefined vehicle with sensors attached, use XML includes: - -.. code-block:: xml - - - 5e-3 - - - 15 - - - - - - - - - - 0 0 170 - 0 0 0 - - - - - - - - - - -10 -10 - -10 10 - 0.0 3.0 - NONE - https://mrpt.github.io/mvsim-models/textures-cgbookcase/wall-bricks-01.png - 2.5 - 2.5 - ${WALL_THICKNESS} - - - - 0.5 - 1.2 - 0.0 - 2.1 - main_entrance - - - - - - -3 World environment elements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -MVSim supports several types of environment elements: - -**Occupancy grid maps** load a grayscale image as a 2D obstacle map, commonly used for indoor navigation testing: - -.. code-block:: xml - - - map.png - 0.05 - - -**Elevation maps** define terrain height from a grayscale heightmap image, useful for outdoor scenarios: - -.. code-block:: xml - - - 1.0 - terrain.png - 0.0 - 5.0 - - -**Textured planes** add visual ground surfaces: - -.. code-block:: xml - - - BACK - -25 25 - -25 25 - 0.0 - asphalt.png - 5.0 - 5.0 - - -**Blocks** are static or dynamic rigid bodies (boxes, custom shapes) that serve as obstacles or manipulable objects: - -.. code-block:: xml - - - - - package://mvsim/models/box.dae - - 3.0 2.0 0 - 20 - - -4 Vehicle dynamics models -^^^^^^^^^^^^^^^^^^^^^^^^^ - -MVSim provides three main dynamics models: - -- **Differential drive** (``class="differential"``): Two-wheeled robots like TurtleBot3. - Controlled via linear and angular velocity. - -- **Ackermann** (``class="ackermann"``): Car-like vehicles with front-wheel steering. - Controlled via linear velocity and steering angle. - -- **Ackermann drivetrain** (``class="ackermann_drivetrain"``): Realistic drivetrain model with - open or Torsen differentials, useful for more accurate vehicle behavior simulation. - -Each vehicle can use different motor controllers: - -- ``twist_pid``: Accepts ``geometry_msgs/msg/Twist`` commands with PID velocity tracking. - This is the most common choice for ROS 2 integration. -- ``twist_ideal``: Instantaneous velocity commands (no dynamics delay). -- ``twist_front_steer_pid``: For Ackermann vehicles controlled via linear velocity and steering angle. -- ``raw``: Direct wheel torque control. - -5 Sensor noise and configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Sensors in MVSim support configurable noise models. -For example, an IMU sensor with noise parameters: - -.. code-block:: xml - - - 0 0 0.5 0 0 0 - 100 - - - - 1e-3 - 1e-4 - 1e-6 - - - - - 1e-2 - 1e-3 - 1e-5 - - - -LiDAR sensors support parameters for range, angular resolution, and noise: - -.. code-block:: xml - - - 0.15 0 0.3 0 0 0 - 10 - 360 - 360 - 20.0 - 0.01 - true - - -6 Additional features -^^^^^^^^^^^^^^^^^^^^^^ - -**Multi-robot simulation:** -MVSim natively supports multiple vehicles in the same world. -Each vehicle gets its own ROS 2 namespace, TF tree, and set of topics. -Robots can detect each other with their sensors and physically interact through collisions. - -**Property regions:** -You can define regions in the world with different physical properties, such as varying friction coefficients -or GPS-denied zones where GNSS sensors stop reporting positions. - -**Animated actors:** -MVSim supports skeletal-animated 3D characters (e.g., pedestrians) that follow waypoint paths, -useful for testing perception and planning in dynamic environments. - -**Joints and articulated vehicles:** -Vehicles can be connected using distance joints (ropes/cables) or revolute joints (hinges), -enabling simulation of trailers, tow ropes, and articulated systems. - -**XML advanced features:** -World files support ```` directives, variable substitution, mathematical expressions, -```` loops, and ```` conditionals, making it possible to procedurally generate complex environments. - -**Headless and faster-than-real-time:** -MVSim can run without a GUI and at configurable simulation speed, -which is useful for automated testing and reinforcement learning workflows. - -Comparison with other simulators --------------------------------- - -MVSim occupies a different niche compared to other simulators: - -**Strengths:** - -- Very lightweight: low CPU and memory usage, fast startup times. -- Focused vehicle dynamics with multiple friction and drivetrain models. -- Simple XML-based world format, easy to get started. -- Native multi-robot support with per-vehicle ROS 2 namespaces. -- Faster-than-real-time simulation for batch testing. -- Procedural world generation via XML loops and conditionals. - -**Limitations:** - -- Physics is 2D (Box2D): no full 3D rigid body dynamics. - Objects do not tip over or fly. - Elevation maps add terrain height but the physics remains fundamentally 2D. -- Sensor simulation is less detailed than full 3D simulators: camera rendering and LiDAR models - are functional but not photorealistic. -- Smaller ecosystem of pre-built models and environments compared to Gazebo. -- Focused on wheeled mobile robots. - -Further resources ------------------ - -- `MVSim documentation `__ -- `MVSim GitHub repository `__ +.. redirect-from:: + + Tutorials/Advanced/Simulators/MVSim/Defining-Worlds-MVSim + +Defining worlds, robots, and sensors +==================================== + +**Goal:** Learn the basics of defining MVSim world files, adding vehicles and sensors, and the main features available. + +**Tutorial level:** Advanced + +**Time:** 30 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +MVSim worlds are defined in XML files (``.world.xml``). +A world file describes the environment (ground, walls, obstacles), the vehicles (dynamics model, shape, sensors), +and simulation parameters (physics timestep, GUI options). + +MVSim provides a library of predefined vehicle and sensor definitions that you can reuse in your worlds via XML includes. +You can also define everything from scratch for full control. + +Prerequisites +------------- + +You should have completed the :doc:`Getting-Started-MVSim` tutorial and have MVSim installed. + +Tasks +----- + +1 Minimal world file +^^^^^^^^^^^^^^^^^^^^^^ + +Here is a minimal world file that creates an empty environment with one robot: + +.. code-block:: xml + + + + 5e-3 + + + + 15 + + + + + + + + + 0 0 0 + + + + + + + + + + + + + + + 4.1543 + 1.9118 + 0.0000 + 14.44 + 0.00 + + + + + + 100 5 50 + + + + +Save this as ``my_world.world.xml`` and launch it: + +.. code-block:: console + + $ mvsim launch my_world.world.xml + +2 Using predefined vehicles and sensors +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Instead of defining vehicles from scratch, you can use the predefined definitions that ship with MVSim. +These are XML files in the ``definitions/`` directory of the MVSim package. + +**Available vehicles:** + +- ``turtlebot3_burger.vehicle.xml`` -- TurtleBot3 Burger (differential drive) +- ``jackal.vehicle.xml`` -- Clearpath Jackal UGV (4-wheel differential) +- ``ackermann.vehicle.xml`` -- Generic Ackermann (car-like) vehicle +- ``pickup.vehicle.xml`` -- Pickup truck (Ackermann) +- ``agricobiot2.vehicle.xml`` -- Agricultural robot (Ackermann drivetrain) + +**Available sensors:** + +- ``lidar2d.sensor.xml`` -- Generic 2D laser scanner +- ``rplidar-a2.sensor.xml`` -- RPLidar A2 +- ``velodyne-vlp16.sensor.xml`` -- Velodyne VLP-16 3D LiDAR +- ``ouster-os1.sensor.xml`` -- Ouster OS1 3D LiDAR +- ``helios-32-FOV-70.sensor.xml`` -- Helios 32-beam 3D LiDAR +- ``camera.sensor.xml`` -- RGB camera +- ``rgbd_camera.sensor.xml`` -- Depth camera (RGBD) +- ``imu.sensor.xml`` -- Inertial measurement unit +- ``gnss.sensor.xml`` -- GPS/GNSS receiver + +To use a predefined vehicle with sensors attached, use XML includes: + +.. code-block:: xml + + + 5e-3 + + + 15 + + + + + + + + + + 0 0 170 + 0 0 0 + + + + + + + + + + -10 -10 + -10 10 + 0.0 3.0 + NONE + https://mrpt.github.io/mvsim-models/textures-cgbookcase/wall-bricks-01.png + 2.5 + 2.5 + ${WALL_THICKNESS} + + + + 0.5 + 1.2 + 0.0 + 2.1 + main_entrance + + + + + + +3 World environment elements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +MVSim supports several types of environment elements: + +**Occupancy grid maps** load a grayscale image as a 2D obstacle map, commonly used for indoor navigation testing: + +.. code-block:: xml + + + map.png + 0.05 + + +**Elevation maps** define terrain height from a grayscale heightmap image, useful for outdoor scenarios: + +.. code-block:: xml + + + 1.0 + terrain.png + 0.0 + 5.0 + + +**Textured planes** add visual ground surfaces: + +.. code-block:: xml + + + BACK + -25 25 + -25 25 + 0.0 + asphalt.png + 5.0 + 5.0 + + +**Blocks** are static or dynamic rigid bodies (boxes, custom shapes) that serve as obstacles or manipulable objects: + +.. code-block:: xml + + + + + package://mvsim/models/box.dae + + 3.0 2.0 0 + 20 + + +4 Vehicle dynamics models +^^^^^^^^^^^^^^^^^^^^^^^^^ + +MVSim provides three main dynamics models: + +- **Differential drive** (``class="differential"``): Two-wheeled robots like TurtleBot3. + Controlled via linear and angular velocity. + +- **Ackermann** (``class="ackermann"``): Car-like vehicles with front-wheel steering. + Controlled via linear velocity and steering angle. + +- **Ackermann drivetrain** (``class="ackermann_drivetrain"``): Realistic drivetrain model with + open or Torsen differentials, useful for more accurate vehicle behavior simulation. + +Each vehicle can use different motor controllers: + +- ``twist_pid``: Accepts ``geometry_msgs/msg/Twist`` commands with PID velocity tracking. + This is the most common choice for ROS 2 integration. +- ``twist_ideal``: Instantaneous velocity commands (no dynamics delay). +- ``twist_front_steer_pid``: For Ackermann vehicles controlled via linear velocity and steering angle. +- ``raw``: Direct wheel torque control. + +5 Sensor noise and configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Sensors in MVSim support configurable noise models. +For example, an IMU sensor with noise parameters: + +.. code-block:: xml + + + 0 0 0.5 0 0 0 + 100 + + + + 1e-3 + 1e-4 + 1e-6 + + + + + 1e-2 + 1e-3 + 1e-5 + + + +LiDAR sensors support parameters for range, angular resolution, and noise: + +.. code-block:: xml + + + 0.15 0 0.3 0 0 0 + 10 + 360 + 360 + 20.0 + 0.01 + true + + +6 Additional features +^^^^^^^^^^^^^^^^^^^^^^ + +**Multi-robot simulation:** +MVSim natively supports multiple vehicles in the same world. +Each vehicle gets its own ROS 2 namespace, TF tree, and set of topics. +Robots can detect each other with their sensors and physically interact through collisions. + +**Property regions:** +You can define regions in the world with different physical properties, such as varying friction coefficients +or GPS-denied zones where GNSS sensors stop reporting positions. + +**Animated actors:** +MVSim supports skeletal-animated 3D characters (e.g., pedestrians) that follow waypoint paths, +useful for testing perception and planning in dynamic environments. + +**Joints and articulated vehicles:** +Vehicles can be connected using distance joints (ropes/cables) or revolute joints (hinges), +enabling simulation of trailers, tow ropes, and articulated systems. + +**XML advanced features:** +World files support ```` directives, variable substitution, mathematical expressions, +```` loops, and ```` conditionals, making it possible to procedurally generate complex environments. + +**Headless and faster-than-real-time:** +MVSim can run without a GUI and at configurable simulation speed, +which is useful for automated testing and reinforcement learning workflows. + +Comparison with other simulators +-------------------------------- + +MVSim occupies a different niche compared to other simulators: + +**Strengths:** + +- Very lightweight: low CPU and memory usage, fast startup times. +- Focused vehicle dynamics with multiple friction and drivetrain models. +- Simple XML-based world format, easy to get started. +- Native multi-robot support with per-vehicle ROS 2 namespaces. +- Faster-than-real-time simulation for batch testing. +- Procedural world generation via XML loops and conditionals. + +**Limitations:** + +- Physics is 2D (Box2D): no full 3D rigid body dynamics. + Objects do not tip over or fly. + Elevation maps add terrain height but the physics remains fundamentally 2D. +- Sensor simulation is less detailed than full 3D simulators: camera rendering and LiDAR models + are functional but not photorealistic. +- Smaller ecosystem of pre-built models and environments compared to Gazebo. +- Focused on wheeled mobile robots. + +Further resources +----------------- + +- `MVSim documentation `__ +- `MVSim GitHub repository `__ - `MVSim paper (SoftwareX) `__ \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst b/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst index 490e18763e2..4a0ed18abc1 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst @@ -1,135 +1,135 @@ -.. redirect-from:: - - Tutorials/Advanced/Simulators/Webots/Installation-Ubuntu - -Installation (Ubuntu) -====================================== - -**Goal:** Install the ``webots_ros2`` package and run simulation examples on Ubuntu. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, including ``webots_ros2_driver``, which allows you to start Webots and communicate with it. -This interface is used in most of the following tutorials, so it is required to install it beforehand. -Other sub-packages are mainly examples that show multiple possible implementations using the interface. -In this tutorial, you are going to install the package and learn how to run one of these examples. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. -In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. - -The Webots software should be installed in order to use the ``webots_ros2`` interface. -You can follow the `installation procedure `_ or `build it from sources `_. - -Alternatively, you can also let ``webots_ros2`` download and install Webots automatically. -This option appears when you launch an example of the package and no Webots installation is found. - -Multiple Installations of Webots -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have installed different versions of Webots on your computer, ``webots_ros2`` will look for Webots at the following locations (in this order): - -1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -3. If none of these variables is set, ``webots_ros2`` will look for Webots in the default installation paths for a compatible version: ``/usr/local/webots`` and ``/snap/webots/current/usr/share/webots``. -4. If Webots couldn't be found, ``webots_ros2`` will show a window offering the automatic installation of the latest compatible version of Webots. - -Tasks ------ - -1 Install ``webots_ros2`` -^^^^^^^^^^^^^^^^^^^^^^^^^ -You can either install the official released package, or install it from the latest up-to-date sources from `Github `_. - -.. tabs:: - - .. group-tab:: Install ``webots_ros2`` distributed package - - Run the following command in a terminal. - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-webots-ros2 - - .. group-tab:: Install ``webots_ros2`` from sources - - Create a ROS 2 workspace with its ``src`` directory. - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - - Source the ROS 2 environment. - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Retrieve the sources from Github. - - .. code-block:: console - - $ cd ~/ros2_ws - $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 - - Install the package dependencies. - - .. code-block:: console - - $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions - $ sudo rosdep init && rosdep update - $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} - - Build the package using ``colcon``. - - .. code-block:: console - - $ colcon build - - Source this workspace. - - .. code-block:: console - - $ source install/local_setup.bash - -2 Launch the ``webots_ros2_universal_robot`` example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following instructions explain how to start a provided example. - -First source the ROS 2 environment, if not done already. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation. - -.. code-block:: console - - $ export WEBOTS_HOME=/usr/local/webots - -If installed from sources, source your ROS 2 workspace, if not done already. - -.. code-block:: console - - $ cd ~/ros2_ws - $ source install/local_setup.bash - -Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). - -.. code-block:: console - +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Installation-Ubuntu + +Installation (Ubuntu) +===================== + +**Goal:** Install the ``webots_ros2`` package and run simulation examples on Ubuntu. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, including ``webots_ros2_driver``, which allows you to start Webots and communicate with it. +This interface is used in most of the following tutorials, so it is required to install it beforehand. +Other sub-packages are mainly examples that show multiple possible implementations using the interface. +In this tutorial, you are going to install the package and learn how to run one of these examples. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. + +The Webots software should be installed in order to use the ``webots_ros2`` interface. +You can follow the `installation procedure `_ or `build it from sources `_. + +Alternatively, you can also let ``webots_ros2`` download and install Webots automatically. +This option appears when you launch an example of the package and no Webots installation is found. + +Multiple Installations of Webots +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have installed different versions of Webots on your computer, ``webots_ros2`` will look for Webots at the following locations (in this order): + +1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +3. If none of these variables is set, ``webots_ros2`` will look for Webots in the default installation paths for a compatible version: ``/usr/local/webots`` and ``/snap/webots/current/usr/share/webots``. +4. If Webots couldn't be found, ``webots_ros2`` will show a window offering the automatic installation of the latest compatible version of Webots. + +Tasks +----- + +1 Install ``webots_ros2`` +^^^^^^^^^^^^^^^^^^^^^^^^^ +You can either install the official released package, or install it from the latest up-to-date sources from `Github `_. + +.. tabs:: + + .. group-tab:: Install ``webots_ros2`` distributed package + + Run the following command in a terminal. + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-webots-ros2 + + .. group-tab:: Install ``webots_ros2`` from sources + + Create a ROS 2 workspace with its ``src`` directory. + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + + Source the ROS 2 environment. + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Retrieve the sources from Github. + + .. code-block:: console + + $ cd ~/ros2_ws + $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 + + Install the package dependencies. + + .. code-block:: console + + $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions + $ sudo rosdep init && rosdep update + $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} + + Build the package using ``colcon``. + + .. code-block:: console + + $ colcon build + + Source this workspace. + + .. code-block:: console + + $ source install/local_setup.bash + +2 Launch the ``webots_ros2_universal_robot`` example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following instructions explain how to start a provided example. + +First source the ROS 2 environment, if not done already. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation. + +.. code-block:: console + + $ export WEBOTS_HOME=/usr/local/webots + +If installed from sources, source your ROS 2 workspace, if not done already. + +.. code-block:: console + + $ cd ~/ros2_ws + $ source install/local_setup.bash + +Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). + +.. code-block:: console + $ ros2 launch webots_ros2_universal_robot multirobot_launch.py \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst b/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst index 94feb0b08cf..7ec8aacb081 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst @@ -1,203 +1,203 @@ -.. redirect-from:: - - Tutorials/Advanced/Simulators/Webots/Installation-Windows - -Installation (Windows) -====================================== - -**Goal:** Install the ``webots_ros2`` package and run simulation examples on Windows. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, including ``webots_ros2_driver``, which allows ROS nodes to communicate with Webots. -Other sub-packages are mainly examples that show multiple possible implementations using the interface. -In this tutorial, you are going to install the package and learn how to run one of these examples. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. -In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. - -Webots is a prerequisite to use the ``webots_ros2`` package. -You can follow the `installation procedure `_ or `build it from sources `_. - -Alternatively, you can also let ``webots_ros2`` download Webots automatically. -This option appears when you launch an example of the package and no Webots installation is found. - -Multiple Installations of Webots -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If you have more than one installation of Webots, ROS 2 will look for Webots at the following locations (in this order): - -1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. -3. If none of the previous points is set/installed ROS 2 will look for Webots in the default installation paths for a compatible version: ``C:\Program Files\Webots``. -4. If Webots couldn't be found, ``webots_ros2`` will show a window and offer automatic Webots installation of the last compatible version. - -Tasks ------ - -1 Install WSL2 -^^^^^^^^^^^^^^^ - -On Windows, WSL (Windows Subsystem for Linux) improves the user experience with ROS 2 compared to native Windows installation, as it runs on a Linux platform. -Install WSL with an Ubuntu version which is compatible with your ROS distribution and upgrade to WSL2 following the `official Microsoft tutorial `_. - -2 Install ROS 2 in WSL -^^^^^^^^^^^^^^^^^^^^^^ - -Install ROS 2 inside Ubuntu WSL, following :doc:`../../../Get-Started/Installation/Ubuntu-Install-Debs`. - -3 Install ``webots_ros2`` -^^^^^^^^^^^^^^^^^^^^^^^^^ -You can then either install ``webots_ros2`` from the official released package, or install it from the latest up-to-date sources from `Github `_. - -The following commands must be run inside the WSL environment. - -.. tabs:: - - .. group-tab:: Install ``webots_ros2`` distributed package - - Run the following command in a terminal. - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-webots-ros2 - - .. group-tab:: Install ``webots_ros2`` from sources - - Create a ROS 2 workspace with its ``src`` directory. - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - - Source the ROS 2 environment. - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Retrieve the sources from Github. - - .. code-block:: console - - $ cd ~/ros2_ws - $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 - - Install the package dependencies. - - .. code-block:: console - - $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions - $ sudo rosdep init && rosdep update - $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} - - Build the package using ``colcon``. - - .. code-block:: console - - $ colcon build - - Source this workspace. - - .. code-block:: console - - $ source install/local_setup.bash - - -4 Launch the ``webots_ros2_universal_robot`` example -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -WSL doesn't support hardware acceleration (yet). -Therefore, Webots should be started on Windows, while the ROS part is running inside WSL. -To do so, the following commands must be run inside the WSL environment. - -First source the ROS 2 environment, if not done already. - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - -Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation (e.g. ``C:\Program Files\Webots``). -Use the mount point "/mnt" to refer to a path on native Windows. - -.. code-block:: console - - $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots - -If installed from sources, source your ROS 2 workspace, if not done already. - -.. code-block:: console - - $ cd ~/ros2_ws - $ source install/local_setup.bash - -Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). - -.. code-block:: console - - $ ros2 launch webots_ros2_universal_robot multirobot_launch.py - - -5 RViz troubleshooting -^^^^^^^^^^^^^^^^^^^^^^ - -With recent versions of WSL2, RViz should work out of the box. - -You can check if it works correctly by running any example that uses RViz, for example: - -.. code-block:: console - - $ sudo apt install ros-{DISTRO}-slam-toolbox - $ ros2 launch webots_ros2_tiago robot_launch.py rviz:=true slam:=true - -The Tiago robot can be controlled using: - -.. code-block:: console - - $ ros2 run teleop_twist_keyboard teleop_twist_keyboard - -With older WSL versions, RViz2 may not work directly, as no display is available. -To use RViz, you can either upgrade WSL or enable X11 forwarding. - -.. tabs:: - .. group-tab:: Upgrade WSL - - In a Windows shell: - - .. code-block:: console - - $ wsl --update - - .. group-tab:: Enable X11 forwarding - - For older versions of WSL, the following steps can be followed: - - 1. Install `VcXsrv `_. - 2. Launch VcXsrv. - You can leave most of the parameters default, except the ``Extra settings`` page, where you must set ``Clipboard``, ``Primary Selection`` and ``Disable access control`` and unset ``Native opengl``. - 3. You can save the configuration for future launches. - 4. Click on ``Finish``, you will see that the X11 server is running in the icon tray. - 5. In your WSL environment, export the ``DISPLAY`` variable. - - .. code-block:: console - - $ export DISPLAY=$(ip route list default | awk '{print }'):0 - - You can add this to your ``.bashrc``, so that it is set for every future WSL environment. - - .. code-block:: console - +.. redirect-from:: + + Tutorials/Advanced/Simulators/Webots/Installation-Windows + +Installation (Windows) +====================== + +**Goal:** Install the ``webots_ros2`` package and run simulation examples on Windows. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, including ``webots_ros2_driver``, which allows ROS nodes to communicate with Webots. +Other sub-packages are mainly examples that show multiple possible implementations using the interface. +In this tutorial, you are going to install the package and learn how to run one of these examples. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` and :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` are useful prerequisites. + +Webots is a prerequisite to use the ``webots_ros2`` package. +You can follow the `installation procedure `_ or `build it from sources `_. + +Alternatively, you can also let ``webots_ros2`` download Webots automatically. +This option appears when you launch an example of the package and no Webots installation is found. + +Multiple Installations of Webots +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If you have more than one installation of Webots, ROS 2 will look for Webots at the following locations (in this order): + +1. If the ``ROS2_WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +2. If the ``WEBOTS_HOME`` environment variable is set, ROS 2 will use the Webots in this folder, regardless of its version. +3. If none of the previous points is set/installed ROS 2 will look for Webots in the default installation paths for a compatible version: ``C:\Program Files\Webots``. +4. If Webots couldn't be found, ``webots_ros2`` will show a window and offer automatic Webots installation of the last compatible version. + +Tasks +----- + +1 Install WSL2 +^^^^^^^^^^^^^^^ + +On Windows, WSL (Windows Subsystem for Linux) improves the user experience with ROS 2 compared to native Windows installation, as it runs on a Linux platform. +Install WSL with an Ubuntu version which is compatible with your ROS distribution and upgrade to WSL2 following the `official Microsoft tutorial `_. + +2 Install ROS 2 in WSL +^^^^^^^^^^^^^^^^^^^^^^ + +Install ROS 2 inside Ubuntu WSL, following :doc:`../../../Get-Started/Installation/Ubuntu-Install-Debs`. + +3 Install ``webots_ros2`` +^^^^^^^^^^^^^^^^^^^^^^^^^ +You can then either install ``webots_ros2`` from the official released package, or install it from the latest up-to-date sources from `Github `_. + +The following commands must be run inside the WSL environment. + +.. tabs:: + + .. group-tab:: Install ``webots_ros2`` distributed package + + Run the following command in a terminal. + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-webots-ros2 + + .. group-tab:: Install ``webots_ros2`` from sources + + Create a ROS 2 workspace with its ``src`` directory. + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + + Source the ROS 2 environment. + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Retrieve the sources from Github. + + .. code-block:: console + + $ cd ~/ros2_ws + $ git clone --recurse-submodules https://github.com/cyberbotics/webots_ros2.git src/webots_ros2 + + Install the package dependencies. + + .. code-block:: console + + $ sudo apt install python3-pip python3-rosdep python3-colcon-common-extensions + $ sudo rosdep init && rosdep update + $ rosdep install --from-paths src --ignore-src --rosdistro {DISTRO} + + Build the package using ``colcon``. + + .. code-block:: console + + $ colcon build + + Source this workspace. + + .. code-block:: console + + $ source install/local_setup.bash + + +4 Launch the ``webots_ros2_universal_robot`` example +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +WSL doesn't support hardware acceleration (yet). +Therefore, Webots should be started on Windows, while the ROS part is running inside WSL. +To do so, the following commands must be run inside the WSL environment. + +First source the ROS 2 environment, if not done already. + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + +Setting the ``WEBOTS_HOME`` environment variable allows you to start a specific Webots installation (e.g. ``C:\Program Files\Webots``). +Use the mount point "/mnt" to refer to a path on native Windows. + +.. code-block:: console + + $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots + +If installed from sources, source your ROS 2 workspace, if not done already. + +.. code-block:: console + + $ cd ~/ros2_ws + $ source install/local_setup.bash + +Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universal_robot``). + +.. code-block:: console + + $ ros2 launch webots_ros2_universal_robot multirobot_launch.py + + +5 RViz troubleshooting +^^^^^^^^^^^^^^^^^^^^^^ + +With recent versions of WSL2, RViz should work out of the box. + +You can check if it works correctly by running any example that uses RViz, for example: + +.. code-block:: console + + $ sudo apt install ros-{DISTRO}-slam-toolbox + $ ros2 launch webots_ros2_tiago robot_launch.py rviz:=true slam:=true + +The Tiago robot can be controlled using: + +.. code-block:: console + + $ ros2 run teleop_twist_keyboard teleop_twist_keyboard + +With older WSL versions, RViz2 may not work directly, as no display is available. +To use RViz, you can either upgrade WSL or enable X11 forwarding. + +.. tabs:: + .. group-tab:: Upgrade WSL + + In a Windows shell: + + .. code-block:: console + + $ wsl --update + + .. group-tab:: Enable X11 forwarding + + For older versions of WSL, the following steps can be followed: + + 1. Install `VcXsrv `_. + 2. Launch VcXsrv. + You can leave most of the parameters default, except the ``Extra settings`` page, where you must set ``Clipboard``, ``Primary Selection`` and ``Disable access control`` and unset ``Native opengl``. + 3. You can save the configuration for future launches. + 4. Click on ``Finish``, you will see that the X11 server is running in the icon tray. + 5. In your WSL environment, export the ``DISPLAY`` variable. + + .. code-block:: console + + $ export DISPLAY=$(ip route list default | awk '{print }'):0 + + You can add this to your ``.bashrc``, so that it is set for every future WSL environment. + + .. code-block:: console + $ echo "export DISPLAY=$(ip route list default | awk '{print }'):0" >> ~/.bashrc \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst index 71a2dd4bff5..7d4845c6243 100644 --- a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst +++ b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst @@ -1,527 +1,527 @@ -.. redirect-from:: - - Tutorials/Simulators/Webots/Setting-up-a-Robot-Simulation-Webots - Tutorials/Advanced/Simulators/Webots - Tutorials/Advanced/Simulators/Webots/Setting-Up-Simulation-Webots-Basic - -Setting up a robot simulation (Basic) -====================================== - -**Goal:** Setup a robot simulation and control it from ROS 2. - -**Tutorial level:** Advanced - -**Time:** 30 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial, you are going to use the Webots robot simulator to set-up and run a very simple ROS 2 simulation scenario. - -The ``webots_ros2`` package provides an interface between ROS 2 and Webots. -It includes several sub-packages, but in this tutorial, you are going to use only the ``webots_ros2_driver`` sub-package to implement a Python or C++ plugin controlling a simulated robot. -Some other sub-packages contain demos with different robots such as the TurtleBot3. -They are documented in the `Webots ROS 2 examples `_ page. - -Prerequisites -------------- - -It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. -In particular, :doc:`../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim`, :doc:`../../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` and :doc:`../../../Developer-Tools/Launch/Creating-Launch-Files` are useful prerequisites. - -.. tabs:: - - .. group-tab:: Linux - - The Linux and ROS commands of this tutorial can be run in a standard Linux terminal. - The following page :doc:`Installation-Ubuntu` explains how to install the ``webots_ros2`` package on Linux. - - .. group-tab:: Windows - - The Linux and ROS commands of this tutorial must be run in a WSL (Windows Subsystem for Linux) environment. - The following page :doc:`Installation-Windows` explains how to install the ``webots_ros2`` package on Windows. - - .. group-tab:: macOS - - The Linux and ROS commands of this tutorial must be run in a pre-configured Linux Virtual Machine (VM). - The following page :doc:`Installation-MacOS` explains how to install the ``webots_ros2`` package on macOS. - -This tutorial is compatible with version 2023.1.0 of ``webots_ros2`` and Webots R2023b, as well as upcoming versions. - -Tasks ------ - -1 Create the package structure -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's organize the code in a custom ROS 2 package. -Create a new package named ``my_package`` from the ``src`` folder of your ROS 2 workspace. -Change the current directory of your terminal to ``ros2_ws/src`` and run: - -.. tabs:: - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 --node-name my_robot_driver my_package --dependencies rclpy geometry_msgs webots_ros2_driver - - The ``--node-name my_robot_driver`` option will create a ``my_robot_driver.py`` template Python plugin in the ``my_package`` subfolder that you will modify later. - The ``--dependencies rclpy geometry_msgs webots_ros2_driver`` option specifies the packages needed by the ``my_robot_driver.py`` plugin in the ``package.xml`` file. - - Let's add a ``launch`` and a ``worlds`` folder inside the ``my_package`` folder. - - .. code-block:: console - - $ cd my_package - $ mkdir launch - $ mkdir worlds - - You should end up with the following folder structure: - - .. code-block:: console - - src/ - └── my_package/ - ├── launch/ - ├── my_package/ - │ ├── __init__.py - │ └── my_robot_driver.py - ├── resource/ - │ └── my_package - ├── test/ - │ ├── test_copyright.py - │ ├── test_flake8.py - │ └── test_pep257.py - ├── worlds/ - ├── package.xml - ├── setup.cfg - └── setup.py - - .. group-tab:: C++ - - .. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --node-name MyRobotDriver my_package --dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib - - The ``--node-name MyRobotDriver`` option will create a ``MyRobotDriver.cpp`` template C++ plugin in the ``my_package/src`` subfolder that you will modify later. - The ``--dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib`` option specifies the packages needed by the ``MyRobotDriver`` plugin in the ``package.xml`` file. - - - Let's add a ``launch``, a ``worlds`` and a ``resource`` folder inside the ``my_package`` folder. - - .. code-block:: console - - $ cd my_package - $ mkdir launch - $ mkdir worlds - $ mkdir resource - - Two additional files must be created: the header file for ``MyRobotDriver`` and the ``my_robot_driver.xml`` pluginlib description file. - - .. code-block:: console - - $ touch my_robot_driver.xml - $ touch include/my_package/MyRobotDriver.hpp - - You should end up with the following folder structure: - - .. code-block:: console - - src/ - └── my_package/ - ├── include/ - │ └── my_package/ - │ └── MyRobotDriver.hpp - ├── launch/ - ├── resource/ - ├── src/ - │ └── MyRobotDriver.cpp - ├── worlds/ - ├── CMakeList.txt - ├── my_robot_driver.xml - └── package.xml - -2 Setup the simulation world -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You will need a world file containing a robot to launch your simulation. -:download:`Download this world file ` and move it inside ``my_package/worlds/``. - -This is actually a fairly simple text file you can visualize in a text editor. -A simple robot is already included in this ``my_world.wbt`` world file. - -.. note:: - - In case you want to learn how to create your own robot model in Webots, you can check this `tutorial `_. - -3 Edit the ``my_robot_driver`` plugin -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``webots_ros2_driver`` sub-package automatically creates a ROS 2 interface for most sensors. -More details on existing device interfaces and how to configure them is given in the second part of the tutorial: :doc:`Setting-Up-Simulation-Webots-Advanced`. -In this task, you will extend this interface by creating your own custom plugin. -This custom plugin is a ROS node equivalent to a robot controller. -You can use it to access the `Webots robot API `_ and create your own topics and services to control your robot. - -.. note:: - - The purpose of this tutorial is to show a basic example with a minimum number of dependencies. - However, you could avoid the use of this plugin by using another ``webots_ros2`` sub-package named ``webots_ros2_control``, introducing a new dependency. - This other sub-package creates an interface with the ``ros2_control`` package that facilitates the control of a differential wheeled robot. - - -.. tabs:: - - .. group-tab:: Python - - Open ``my_package/my_package/my_robot_driver.py`` in your favorite editor and replace its contents with the following: - - .. literalinclude:: Code/my_robot_driver.py - :language: python - - As you can see, the ``MyRobotDriver`` class implements three methods. - - The first method, named ``init(self, ...)``, is actually the ROS node counterpart of the Python ``__init__(self, ...)`` constructor. - The ``init`` method always takes two arguments: - - - The ``webots_node`` argument contains a reference on the Webots instance. - - The ``properties`` argument is a dictionary created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows you to pass parameters to the controller. - - The robot instance from the simulation ``self.__robot`` can be used to access the `Webots robot API `_. - Then, it gets the two motor instances and initializes them with a target position and a target velocity. - Finally a ROS node is created and a callback method is registered for a ROS topic named ``/cmd_vel`` that will handle ``Twist`` messages. - - .. literalinclude:: Code/my_robot_driver.py - :language: python - :dedent: 4 - :lines: 8-24 - - Then comes the implementation of the ``__cmd_vel_callback(self, twist)`` callback private method that will be called for each ``Twist`` message received on the ``/cmd_vel`` topic and will save it in the ``self.__target_twist`` member variable. - - .. literalinclude:: Code/my_robot_driver.py - :language: python - :dedent: 4 - :lines: 26-27 - - Finally, the ``step(self)`` method is called at every time step of the simulation. - The call to ``rclpy.spin_once()`` is needed to keep the ROS node running smoothly. - At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``self.__target_twist``. - As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. - This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. - - .. literalinclude:: Code/my_robot_driver.py - :language: python - :dedent: 4 - :lines: 29-39 - - .. group-tab:: C++ - - Open ``my_package/include/my_package/MyRobotDriver.hpp`` in your favorite editor and replace its contents with the following: - - .. literalinclude:: Code/MyRobotDriver.hpp - :language: cpp - - The class ``MyRobotDriver`` is defined, which inherits from the ``webots_ros2_driver::PluginInterface`` class. - The plugin has to override ``step(...)`` and ``init(...)`` functions. - More details are given in the ``MyRobotDriver.cpp`` file. - Several helper methods, callbacks and member variables that will be used internally by the plugin are declared privately. - - Then, open ``my_package/src/MyRobotDriver.cpp`` in your favorite editor and replace its contents with the following: - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - - The ``MyRobotDriver::init`` method is executed once the plugin is loaded by the ``webots_ros2_driver`` package. - It takes two arguments: - - * A pointer to the ``WebotsNode`` defined by ``webots_ros2_driver``, which allows to access the ROS 2 node functions. - * The ``parameters`` argument is an unordered map of strings, created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows to pass parameters to the controller. - It is not used in this example. - - It initializes the plugin by setting up the robot motors, setting their positions and velocities, and subscribing to the ``/cmd_vel`` topic. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 13-33 - - The subscription callback is declared as a lambda function, that will be called for each Twist message received on the ``/cmd_vel`` topic and will save it in the ``cmd_vel_msg`` member variable. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 28-31 - - The ``step()`` method is called at every time step of the simulation. - At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``cmd_vel_msg``. - As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. - This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 35-48 - - The final lines of the file define the end of the ``my_robot_driver`` namespace and include a macro to export the ``MyRobotDriver`` class as a plugin using the ``PLUGINLIB_EXPORT_CLASS`` macro. - This allows the plugin to be loaded by the Webots ROS2 driver at runtime. - - .. literalinclude:: Code/MyRobotDriver.cpp - :language: cpp - :lines: 51-53 - - .. note:: - - While the plugin is implemented in C++, the C API must be used to interact with the Webots controller library. - -.. _4 Create the my_robot.urdf file: - -4 Create the ``my_robot.urdf`` file -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You now have to create a URDF file to declare the ``MyRobotDriver`` plugin. -This will allow the ``webots_ros2_driver`` ROS node to launch the plugin and connect it to the target robot. - -In the ``my_package/resource`` folder create a text file named ``my_robot.urdf`` with this content: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: Code/my_robot_python.urdf - :language: xml - - The ``type`` attribute specifies the path to the class given by the hierarchical structure of files. - ``webots_ros2_driver`` is responsible for loading the class based on the specified package and modules. - - .. group-tab:: C++ - - .. literalinclude:: Code/my_robot_cpp.urdf - :language: xml - - The ``type`` attribute specifies the namespace and class name to load. - ``pluginlib`` is responsible for loading the class based on the specified information. - -.. note:: - - This simple URDF file doesn't contain any link or joint information about the robot as it is not needed in this tutorial. - However, URDF files usually contain much more information as explained in the :doc:`../../../Capabilities/Simulation/URDF/URDF-Main` tutorial. - -.. note:: - - Here the plugin does not take any input parameter, but this can be achieved with a tag containing the parameter name. - - .. tabs:: - - .. group-tab:: Python - - .. code-block:: xml - - - someValue - - - .. group-tab:: C++ - - .. code-block:: xml - - - someValue - - - - This is namely used to pass parameters to existing Webots device plugins (see :doc:`Setting-Up-Simulation-Webots-Advanced`). - -5 Create the launch file -^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's create the launch file to easily launch the simulation and the ROS controller with a single command. -In the ``my_package/launch`` folder create a new text file named ``robot_launch.py`` with this code: - -.. literalinclude:: Code/robot_launch.py - :language: python - -The ``WebotsLauncher`` object is a custom action that allows you to start a Webots simulation instance. -You have to specify in the constructor which world file the simulator will open. - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 4 - :lines: 13-15 - -Then, the ROS node interacting with the simulated robot is created. -This node, named ``WebotsController``, is located in the ``webots_ros2_driver`` package. - -.. tabs:: - - .. group-tab:: Linux - - The node will be able to communicate with the simulated robot by using a custom protocol based on IPC and shared memory. - - .. group-tab:: Windows - - The node (in WSL) will be able to communicate with the simulated robot (in Webots on native Windows) through a TCP connection. - - .. group-tab:: macOS - - The node (in the docker container) will be able to communicate with the simulated robot (in Webots on native macOS) through a TCP connection. - - -In your case, you need to run a single instance of this node, because you have a single robot in the simulation. -But if you had more robots in the simulation, you would have to run one instance of this node per robot. -The ``robot_name`` parameter is used to define the name of the robot the driver should connect to. -The ``robot_description`` parameter holds the path to the URDF file which refers to the ``MyRobotDriver`` plugin. -You can see the ``WebotsController`` node as the interface that connects your controller plugin to the target robot. - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 4 - :lines: 17-22 - -After that, the two nodes are set to be launched in the ``LaunchDescription`` constructor: - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 4 - :lines: 24-26 - -Finally, an optional part is added in order to shutdown all the nodes once Webots terminates (e.g. when it gets closed from the graphical user interface). - -.. literalinclude:: Code/robot_launch.py - :language: python - :dedent: 8 - :lines: 27-32 - -.. note:: - - More details on ``WebotsController`` and ``WebotsLauncher`` arguments can be found `on the nodes reference page `_. - -6 Edit additional files -^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Python - - Before you can start the launch file, you have to modify the ``setup.py`` file to include the extra files you added. - Open ``my_package/setup.py`` and replace its contents with: - - .. literalinclude:: Code/setup.py - :language: python - - This sets-up the package and adds in the ``data_files`` variable the newly added files: ``my_world.wbt``, ``my_robot.urdf`` and ``robot_launch.py``. - - .. group-tab:: C++ - - Before you can start the launch file, you have to modify ``CMakeLists.txt`` and ``my_robot_driver.xml`` files: - - * ``CMakeLists.txt`` defines the compilation rules of your plugin. - * ``my_robot_driver.xml`` is necessary for the pluginlib to find your Webots ROS 2 plugin. - - Open ``my_package/my_robot_driver.xml`` and replace its contents with: - - .. literalinclude:: Code/my_robot_driver.xml - :language: xml - - Open ``my_package/CMakeLists.txt`` and replace its contents with: - - .. literalinclude:: Code/CMakeLists.txt - :language: cmake - - The CMakeLists.txt exports the plugin configuration file with the ``pluginlib_export_plugin_description_file()``, defines a shared library of the C++ plugin ``src/MyRobotDriver.cpp``, and sets the include and library dependencies using ``target_link_libraries()``. - - The file then installs the library, the directories ``launch``, ``resource``, and ``worlds`` to the ``share/my_package`` directory. - Finally, it exports the include directories and libraries using ``ament_export_include_directories()`` and ``ament_export_libraries()``, respectively, and declares the package using ``ament_package()``. - - -7 Test the code -^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Linux - - From a terminal in your ROS 2 workspace run: - - .. code-block:: console - - $ colcon build - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - This will launch the simulation. - Webots will be automatically installed on the first run in case it was not already installed. - - .. group-tab:: Windows - - From a terminal in your WSL ROS 2 workspace run: - - .. code-block:: console - - $ colcon build - $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - Be sure to use the ``/mnt`` prefix in front of your path to the Webots installation folder to access the Windows file system from WSL. - - This will launch the simulation. - Webots will be automatically installed on the first run in case it was not already installed. - - .. group-tab:: macOS - - On macOS, a local server must be started on the host to start Webots from the VM. - The local server can be downloaded `on the webots-server repository `_. - - In a terminal of the host machine (not in the VM), specify the Webots installation folder (e.g. ``/Applications/Webots.app``) and start the server using the following commands: - - .. code-block:: console - - $ export WEBOTS_HOME=/Applications/Webots.app - $ python3 local_simulation_server.py - - From a terminal in the Linux VM in your ROS 2 workspace, build and launch your custom package with: - - .. code-block:: console - - $ colcon build - $ source install/local_setup.bash - $ ros2 launch my_package robot_launch.py - - -.. note:: - - If you want to install Webots manually, you can download it `here `_. - - -Then, open a second terminal and send a command with: - -.. code-block:: console - - $ ros2 topic pub /cmd_vel geometry_msgs/Twist "linear: { x: 0.1 }" - -The robot is now moving forward. - -.. image:: Image/Robot_moving_forward.png - -At this point, the robot is able to blindly follow your motor commands. -But it will eventually bump into the wall as you order it to move forwards. - -.. image:: Image/Robot_colliding_wall.png - -Close the Webots window, this should also shutdown your ROS nodes started from the launcher. -Close also the topic command with ``Ctrl+C`` in the second terminal. - -Summary -------- - -In this tutorial, you set-up a realistic robot simulation with Webots and implemented a custom plugin to control the motors of the robot. - -Next steps ----------- - -To improve the simulation, the robot's sensors can be used to detect obstacles and avoid them. -The second part of the tutorial shows how to implement such behaviour: - +.. redirect-from:: + + Tutorials/Simulators/Webots/Setting-up-a-Robot-Simulation-Webots + Tutorials/Advanced/Simulators/Webots + Tutorials/Advanced/Simulators/Webots/Setting-Up-Simulation-Webots-Basic + +Setting up a robot simulation (Basic) +===================================== + +**Goal:** Setup a robot simulation and control it from ROS 2. + +**Tutorial level:** Advanced + +**Time:** 30 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial, you are going to use the Webots robot simulator to set-up and run a very simple ROS 2 simulation scenario. + +The ``webots_ros2`` package provides an interface between ROS 2 and Webots. +It includes several sub-packages, but in this tutorial, you are going to use only the ``webots_ros2_driver`` sub-package to implement a Python or C++ plugin controlling a simulated robot. +Some other sub-packages contain demos with different robots such as the TurtleBot3. +They are documented in the `Webots ROS 2 examples `_ page. + +Prerequisites +------------- + +It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. +In particular, :doc:`../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim`, :doc:`../../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` and :doc:`../../../Developer-Tools/Launch/Creating-Launch-Files` are useful prerequisites. + +.. tabs:: + + .. group-tab:: Linux + + The Linux and ROS commands of this tutorial can be run in a standard Linux terminal. + The following page :doc:`Installation-Ubuntu` explains how to install the ``webots_ros2`` package on Linux. + + .. group-tab:: Windows + + The Linux and ROS commands of this tutorial must be run in a WSL (Windows Subsystem for Linux) environment. + The following page :doc:`Installation-Windows` explains how to install the ``webots_ros2`` package on Windows. + + .. group-tab:: macOS + + The Linux and ROS commands of this tutorial must be run in a pre-configured Linux Virtual Machine (VM). + The following page :doc:`Installation-MacOS` explains how to install the ``webots_ros2`` package on macOS. + +This tutorial is compatible with version 2023.1.0 of ``webots_ros2`` and Webots R2023b, as well as upcoming versions. + +Tasks +----- + +1 Create the package structure +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's organize the code in a custom ROS 2 package. +Create a new package named ``my_package`` from the ``src`` folder of your ROS 2 workspace. +Change the current directory of your terminal to ``ros2_ws/src`` and run: + +.. tabs:: + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 --node-name my_robot_driver my_package --dependencies rclpy geometry_msgs webots_ros2_driver + + The ``--node-name my_robot_driver`` option will create a ``my_robot_driver.py`` template Python plugin in the ``my_package`` subfolder that you will modify later. + The ``--dependencies rclpy geometry_msgs webots_ros2_driver`` option specifies the packages needed by the ``my_robot_driver.py`` plugin in the ``package.xml`` file. + + Let's add a ``launch`` and a ``worlds`` folder inside the ``my_package`` folder. + + .. code-block:: console + + $ cd my_package + $ mkdir launch + $ mkdir worlds + + You should end up with the following folder structure: + + .. code-block:: console + + src/ + └── my_package/ + ├── launch/ + ├── my_package/ + │ ├── __init__.py + │ └── my_robot_driver.py + ├── resource/ + │ └── my_package + ├── test/ + │ ├── test_copyright.py + │ ├── test_flake8.py + │ └── test_pep257.py + ├── worlds/ + ├── package.xml + ├── setup.cfg + └── setup.py + + .. group-tab:: C++ + + .. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --node-name MyRobotDriver my_package --dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib + + The ``--node-name MyRobotDriver`` option will create a ``MyRobotDriver.cpp`` template C++ plugin in the ``my_package/src`` subfolder that you will modify later. + The ``--dependencies rclcpp geometry_msgs webots_ros2_driver pluginlib`` option specifies the packages needed by the ``MyRobotDriver`` plugin in the ``package.xml`` file. + + + Let's add a ``launch``, a ``worlds`` and a ``resource`` folder inside the ``my_package`` folder. + + .. code-block:: console + + $ cd my_package + $ mkdir launch + $ mkdir worlds + $ mkdir resource + + Two additional files must be created: the header file for ``MyRobotDriver`` and the ``my_robot_driver.xml`` pluginlib description file. + + .. code-block:: console + + $ touch my_robot_driver.xml + $ touch include/my_package/MyRobotDriver.hpp + + You should end up with the following folder structure: + + .. code-block:: console + + src/ + └── my_package/ + ├── include/ + │ └── my_package/ + │ └── MyRobotDriver.hpp + ├── launch/ + ├── resource/ + ├── src/ + │ └── MyRobotDriver.cpp + ├── worlds/ + ├── CMakeList.txt + ├── my_robot_driver.xml + └── package.xml + +2 Setup the simulation world +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You will need a world file containing a robot to launch your simulation. +:download:`Download this world file ` and move it inside ``my_package/worlds/``. + +This is actually a fairly simple text file you can visualize in a text editor. +A simple robot is already included in this ``my_world.wbt`` world file. + +.. note:: + + In case you want to learn how to create your own robot model in Webots, you can check this `tutorial `_. + +3 Edit the ``my_robot_driver`` plugin +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``webots_ros2_driver`` sub-package automatically creates a ROS 2 interface for most sensors. +More details on existing device interfaces and how to configure them is given in the second part of the tutorial: :doc:`Setting-Up-Simulation-Webots-Advanced`. +In this task, you will extend this interface by creating your own custom plugin. +This custom plugin is a ROS node equivalent to a robot controller. +You can use it to access the `Webots robot API `_ and create your own topics and services to control your robot. + +.. note:: + + The purpose of this tutorial is to show a basic example with a minimum number of dependencies. + However, you could avoid the use of this plugin by using another ``webots_ros2`` sub-package named ``webots_ros2_control``, introducing a new dependency. + This other sub-package creates an interface with the ``ros2_control`` package that facilitates the control of a differential wheeled robot. + + +.. tabs:: + + .. group-tab:: Python + + Open ``my_package/my_package/my_robot_driver.py`` in your favorite editor and replace its contents with the following: + + .. literalinclude:: Code/my_robot_driver.py + :language: python + + As you can see, the ``MyRobotDriver`` class implements three methods. + + The first method, named ``init(self, ...)``, is actually the ROS node counterpart of the Python ``__init__(self, ...)`` constructor. + The ``init`` method always takes two arguments: + + - The ``webots_node`` argument contains a reference on the Webots instance. + - The ``properties`` argument is a dictionary created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows you to pass parameters to the controller. + + The robot instance from the simulation ``self.__robot`` can be used to access the `Webots robot API `_. + Then, it gets the two motor instances and initializes them with a target position and a target velocity. + Finally a ROS node is created and a callback method is registered for a ROS topic named ``/cmd_vel`` that will handle ``Twist`` messages. + + .. literalinclude:: Code/my_robot_driver.py + :language: python + :dedent: 4 + :lines: 8-24 + + Then comes the implementation of the ``__cmd_vel_callback(self, twist)`` callback private method that will be called for each ``Twist`` message received on the ``/cmd_vel`` topic and will save it in the ``self.__target_twist`` member variable. + + .. literalinclude:: Code/my_robot_driver.py + :language: python + :dedent: 4 + :lines: 26-27 + + Finally, the ``step(self)`` method is called at every time step of the simulation. + The call to ``rclpy.spin_once()`` is needed to keep the ROS node running smoothly. + At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``self.__target_twist``. + As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. + This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. + + .. literalinclude:: Code/my_robot_driver.py + :language: python + :dedent: 4 + :lines: 29-39 + + .. group-tab:: C++ + + Open ``my_package/include/my_package/MyRobotDriver.hpp`` in your favorite editor and replace its contents with the following: + + .. literalinclude:: Code/MyRobotDriver.hpp + :language: cpp + + The class ``MyRobotDriver`` is defined, which inherits from the ``webots_ros2_driver::PluginInterface`` class. + The plugin has to override ``step(...)`` and ``init(...)`` functions. + More details are given in the ``MyRobotDriver.cpp`` file. + Several helper methods, callbacks and member variables that will be used internally by the plugin are declared privately. + + Then, open ``my_package/src/MyRobotDriver.cpp`` in your favorite editor and replace its contents with the following: + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + + The ``MyRobotDriver::init`` method is executed once the plugin is loaded by the ``webots_ros2_driver`` package. + It takes two arguments: + + * A pointer to the ``WebotsNode`` defined by ``webots_ros2_driver``, which allows to access the ROS 2 node functions. + * The ``parameters`` argument is an unordered map of strings, created from the XML tags given in the URDF files (:ref:`4 Create the my_robot.urdf file`) and allows to pass parameters to the controller. + It is not used in this example. + + It initializes the plugin by setting up the robot motors, setting their positions and velocities, and subscribing to the ``/cmd_vel`` topic. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 13-33 + + The subscription callback is declared as a lambda function, that will be called for each Twist message received on the ``/cmd_vel`` topic and will save it in the ``cmd_vel_msg`` member variable. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 28-31 + + The ``step()`` method is called at every time step of the simulation. + At each time step, the method will retrieve the desired ``forward_speed`` and ``angular_speed`` from ``cmd_vel_msg``. + As the motors are controlled with angular velocities, the method will then convert the ``forward_speed`` and ``angular_speed`` into individual commands for each wheel. + This conversion depends on the structure of the robot, more specifically on the radius of the wheel and the distance between them. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 35-48 + + The final lines of the file define the end of the ``my_robot_driver`` namespace and include a macro to export the ``MyRobotDriver`` class as a plugin using the ``PLUGINLIB_EXPORT_CLASS`` macro. + This allows the plugin to be loaded by the Webots ROS2 driver at runtime. + + .. literalinclude:: Code/MyRobotDriver.cpp + :language: cpp + :lines: 51-53 + + .. note:: + + While the plugin is implemented in C++, the C API must be used to interact with the Webots controller library. + +.. _4 Create the my_robot.urdf file: + +4 Create the ``my_robot.urdf`` file +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You now have to create a URDF file to declare the ``MyRobotDriver`` plugin. +This will allow the ``webots_ros2_driver`` ROS node to launch the plugin and connect it to the target robot. + +In the ``my_package/resource`` folder create a text file named ``my_robot.urdf`` with this content: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: Code/my_robot_python.urdf + :language: xml + + The ``type`` attribute specifies the path to the class given by the hierarchical structure of files. + ``webots_ros2_driver`` is responsible for loading the class based on the specified package and modules. + + .. group-tab:: C++ + + .. literalinclude:: Code/my_robot_cpp.urdf + :language: xml + + The ``type`` attribute specifies the namespace and class name to load. + ``pluginlib`` is responsible for loading the class based on the specified information. + +.. note:: + + This simple URDF file doesn't contain any link or joint information about the robot as it is not needed in this tutorial. + However, URDF files usually contain much more information as explained in the :doc:`../../../Capabilities/Simulation/URDF/URDF-Main` tutorial. + +.. note:: + + Here the plugin does not take any input parameter, but this can be achieved with a tag containing the parameter name. + + .. tabs:: + + .. group-tab:: Python + + .. code-block:: xml + + + someValue + + + .. group-tab:: C++ + + .. code-block:: xml + + + someValue + + + + This is namely used to pass parameters to existing Webots device plugins (see :doc:`Setting-Up-Simulation-Webots-Advanced`). + +5 Create the launch file +^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's create the launch file to easily launch the simulation and the ROS controller with a single command. +In the ``my_package/launch`` folder create a new text file named ``robot_launch.py`` with this code: + +.. literalinclude:: Code/robot_launch.py + :language: python + +The ``WebotsLauncher`` object is a custom action that allows you to start a Webots simulation instance. +You have to specify in the constructor which world file the simulator will open. + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 4 + :lines: 13-15 + +Then, the ROS node interacting with the simulated robot is created. +This node, named ``WebotsController``, is located in the ``webots_ros2_driver`` package. + +.. tabs:: + + .. group-tab:: Linux + + The node will be able to communicate with the simulated robot by using a custom protocol based on IPC and shared memory. + + .. group-tab:: Windows + + The node (in WSL) will be able to communicate with the simulated robot (in Webots on native Windows) through a TCP connection. + + .. group-tab:: macOS + + The node (in the docker container) will be able to communicate with the simulated robot (in Webots on native macOS) through a TCP connection. + + +In your case, you need to run a single instance of this node, because you have a single robot in the simulation. +But if you had more robots in the simulation, you would have to run one instance of this node per robot. +The ``robot_name`` parameter is used to define the name of the robot the driver should connect to. +The ``robot_description`` parameter holds the path to the URDF file which refers to the ``MyRobotDriver`` plugin. +You can see the ``WebotsController`` node as the interface that connects your controller plugin to the target robot. + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 4 + :lines: 17-22 + +After that, the two nodes are set to be launched in the ``LaunchDescription`` constructor: + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 4 + :lines: 24-26 + +Finally, an optional part is added in order to shutdown all the nodes once Webots terminates (e.g. when it gets closed from the graphical user interface). + +.. literalinclude:: Code/robot_launch.py + :language: python + :dedent: 8 + :lines: 27-32 + +.. note:: + + More details on ``WebotsController`` and ``WebotsLauncher`` arguments can be found `on the nodes reference page `_. + +6 Edit additional files +^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Python + + Before you can start the launch file, you have to modify the ``setup.py`` file to include the extra files you added. + Open ``my_package/setup.py`` and replace its contents with: + + .. literalinclude:: Code/setup.py + :language: python + + This sets-up the package and adds in the ``data_files`` variable the newly added files: ``my_world.wbt``, ``my_robot.urdf`` and ``robot_launch.py``. + + .. group-tab:: C++ + + Before you can start the launch file, you have to modify ``CMakeLists.txt`` and ``my_robot_driver.xml`` files: + + * ``CMakeLists.txt`` defines the compilation rules of your plugin. + * ``my_robot_driver.xml`` is necessary for the pluginlib to find your Webots ROS 2 plugin. + + Open ``my_package/my_robot_driver.xml`` and replace its contents with: + + .. literalinclude:: Code/my_robot_driver.xml + :language: xml + + Open ``my_package/CMakeLists.txt`` and replace its contents with: + + .. literalinclude:: Code/CMakeLists.txt + :language: cmake + + The CMakeLists.txt exports the plugin configuration file with the ``pluginlib_export_plugin_description_file()``, defines a shared library of the C++ plugin ``src/MyRobotDriver.cpp``, and sets the include and library dependencies using ``target_link_libraries()``. + + The file then installs the library, the directories ``launch``, ``resource``, and ``worlds`` to the ``share/my_package`` directory. + Finally, it exports the include directories and libraries using ``ament_export_include_directories()`` and ``ament_export_libraries()``, respectively, and declares the package using ``ament_package()``. + + +7 Test the code +^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Linux + + From a terminal in your ROS 2 workspace run: + + .. code-block:: console + + $ colcon build + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + This will launch the simulation. + Webots will be automatically installed on the first run in case it was not already installed. + + .. group-tab:: Windows + + From a terminal in your WSL ROS 2 workspace run: + + .. code-block:: console + + $ colcon build + $ export WEBOTS_HOME=/mnt/c/Program\ Files/Webots + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + Be sure to use the ``/mnt`` prefix in front of your path to the Webots installation folder to access the Windows file system from WSL. + + This will launch the simulation. + Webots will be automatically installed on the first run in case it was not already installed. + + .. group-tab:: macOS + + On macOS, a local server must be started on the host to start Webots from the VM. + The local server can be downloaded `on the webots-server repository `_. + + In a terminal of the host machine (not in the VM), specify the Webots installation folder (e.g. ``/Applications/Webots.app``) and start the server using the following commands: + + .. code-block:: console + + $ export WEBOTS_HOME=/Applications/Webots.app + $ python3 local_simulation_server.py + + From a terminal in the Linux VM in your ROS 2 workspace, build and launch your custom package with: + + .. code-block:: console + + $ colcon build + $ source install/local_setup.bash + $ ros2 launch my_package robot_launch.py + + +.. note:: + + If you want to install Webots manually, you can download it `here `_. + + +Then, open a second terminal and send a command with: + +.. code-block:: console + + $ ros2 topic pub /cmd_vel geometry_msgs/Twist "linear: { x: 0.1 }" + +The robot is now moving forward. + +.. image:: Image/Robot_moving_forward.png + +At this point, the robot is able to blindly follow your motor commands. +But it will eventually bump into the wall as you order it to move forwards. + +.. image:: Image/Robot_colliding_wall.png + +Close the Webots window, this should also shutdown your ROS nodes started from the launcher. +Close also the topic command with ``Ctrl+C`` in the second terminal. + +Summary +------- + +In this tutorial, you set-up a realistic robot simulation with Webots and implemented a custom plugin to control the motors of the robot. + +Next steps +---------- + +To improve the simulation, the robot's sensors can be used to detect obstacles and avoid them. +The second part of the tutorial shows how to implement such behaviour: + * :doc:`Setting-Up-Simulation-Webots-Advanced`. \ No newline at end of file diff --git a/source/Migration-and-Upgrades.rst b/source/Migration-and-Upgrades.rst index f103053af39..49de56d141c 100644 --- a/source/Migration-and-Upgrades.rst +++ b/source/Migration-and-Upgrades.rst @@ -1,5 +1,5 @@ Migration and Upgrades -===================== +====================== PLACEHOLDER diff --git a/source/ROS-Framework.rst b/source/ROS-Framework.rst index b9e421db7ef..4e5a0b3ba20 100644 --- a/source/ROS-Framework.rst +++ b/source/ROS-Framework.rst @@ -2,7 +2,7 @@ .. _RollingInstall: ROS framework -============ +============= PLACEHOLDER diff --git a/source/ROS-Framework/actions/Working-with-actions.rst b/source/ROS-Framework/actions/Working-with-actions.rst index 3a4f34aa0b0..0d7fa486e43 100644 --- a/source/ROS-Framework/actions/Working-with-actions.rst +++ b/source/ROS-Framework/actions/Working-with-actions.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Working with actions -============ +==================== PLACEHOLDER diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst index 2914d99fda0..844f631359d 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst @@ -1,5 +1,5 @@ Working with Client libraries -========================== +============================= .. toctree:: :maxdepth: 1 diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces.rst b/source/ROS-Framework/interfaces/Working-with-interfaces.rst index 00aa195baa2..50d5b68654d 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Working with interfaces -============ +======================= PLACEHOLDER diff --git a/source/ROS-Framework/nodes/Working-with-nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes.rst index c290db4262c..60d303399bb 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Working with nodes -============ +================== PLACEHOLDER diff --git a/source/ROS-Framework/parameters/Working-with-parameters.rst b/source/ROS-Framework/parameters/Working-with-parameters.rst index 8427a8ab026..3f8658dbb8b 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Working with parameters -============ +======================= PLACEHOLDER diff --git a/source/ROS-Framework/services/Working-with-services.rst b/source/ROS-Framework/services/Working-with-services.rst index 3e4ab6c0a3f..b1078092aa3 100644 --- a/source/ROS-Framework/services/Working-with-services.rst +++ b/source/ROS-Framework/services/Working-with-services.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Working with services -============ +===================== PLACEHOLDER diff --git a/source/ROS-Framework/topics/Working-with-topics.rst b/source/ROS-Framework/topics/Working-with-topics.rst index eb34ebe4a11..ced5bba482c 100644 --- a/source/ROS-Framework/topics/Working-with-topics.rst +++ b/source/ROS-Framework/topics/Working-with-topics.rst @@ -2,7 +2,7 @@ .. _RollingInstall: Working with topics -============ +=================== PLACEHOLDER diff --git a/source/The-ROS2-Project/Contributing/Build-Farms.rst b/source/The-ROS2-Project/Contributing/Build-Farms.rst index d6c74afbc18..67d2412c70e 100644 --- a/source/The-ROS2-Project/Contributing/Build-Farms.rst +++ b/source/The-ROS2-Project/Contributing/Build-Farms.rst @@ -4,7 +4,7 @@ .. _BuildFarms: -=============== + ROS Build Farms =============== diff --git a/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst b/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst index 8804ea4c21d..d041b95df4d 100644 --- a/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst +++ b/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst @@ -1,625 +1,625 @@ -.. redirect-from:: - - Contributing/Contributing-To-ROS-2-Documentation - -Contributing to ROS 2 Documentation -=================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Contributions to this site are most welcome. -This page explains how to contribute to ROS 2 Documentation. -Please be sure to read the below sections carefully before contributing. - -The site is built using `Sphinx `_, and more particularly using `Sphinx multiversion `_. - -Branch structure ----------------- - -The source code of documentation is located in the `ROS 2 Documentation GitHub repository `_. -This repository is set up with one branch per ROS 2 distribution to handle differences between the distributions. -If a change is common to all ROS 2 distributions, it should be made to the ``rolling`` branch (and then will be backported as appropriate). -If a change is specific to a particular ROS 2 distribution, it should be made to the respective branch. - -Source structure ----------------- - -The source files for the site are all located under the ``source`` subdirectory. -Templates for various sphinx plugins are located under ``source/_templates``. -The root directory contains configuration and files required to locally build the site for testing. - -Building the site locally -------------------------- - -Start by creating `venv `__ to build the documentation: - -.. code-block:: console - - $ python3 -m venv ros2doc # create venv - $ source ros2doc/bin/activate # activate venv - -And install requirements located in the ``requirements.txt`` file: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ pip install -r requirements.txt -c constraints.txt - - .. group-tab:: macOS - - .. code-block:: console - - $ pip install -r requirements.txt -c constraints.txt - - .. group-tab:: Windows - - .. code-block:: console - - $ python -m pip install -r requirements.txt -c constraints.txt - -In order for Sphinx to be able to generate diagrams, the ``dot`` command must be available. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ sudo apt update ; sudo apt install graphviz - - .. group-tab:: macOS - - .. code-block:: console - - $ brew install graphviz - - .. group-tab:: Windows - - Download an installer from `the Graphviz Download page `__ and install it. - Make sure to allow the installer to add it to the Windows ``%PATH%``, otherwise Sphinx will not be able to find it. - -Building the site for one branch -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build the site for just this branch, type ``make html`` at the top-level of the repository. -This is the recommended way to test out local changes. - -.. code-block:: console - - $ make html - -The build process can take some time. -To see the output, open ``build/html/index.html`` in your browser. - - -Checking / Testing the site -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You can run the documentation tests locally (using `doc8 `_) with the following command: - -.. code-block:: console - - $ make test - -You can run the Python documentation tools tests locally (using `pytest `_) with the following command: - -.. code-block:: console - - $ make test-tools - -You can run the documentation linter locally (using `sphinx-lint `_) with the following command: - -.. code-block:: console - - $ make lint - -You can run the documentation spell checker locally (using `codespell `_) with the following command: - -.. code-block:: console - - $ make spellcheck - -.. note:: - - If that detects specific words that need to be ignored, add it to `codespell_whitelist `_ . - -To know more about spelling checks, refer to :ref:`Spelling check ` - -View Site Through Github CI -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For small changes to the ROS 2 Docs you can view your changes as rendered HTML using artifacts generated in our Github Actions. -The "build" action produces the entire ROS Docs as a downloadable Zip file that contains all HTML for `docs.ros.org `_ -This build action is triggered after passing the test action and lint action. - -To download and view your changes first go to your pull request and under the title click the "Checks" tab. -On the left hand side of the checks page, click on the "Test" section under the "tests" section click on "build" dialog. -This will open a menu on the right, where you can click on "Upload document artifacts" and scroll to the bottom to see the download link for the Zipped' HTML files under the heading "Artifact download URL". - -.. image:: ./images/github_action.png - :width: 100% - :alt: Steps to find rendered HTML files on ROS Github action - -Building the site for all branches -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To build the site for all branches, type ``make multiversion`` from the ``rolling`` branch. -This has two drawbacks: - -#. The multiversion plugin doesn't understand how to do incremental builds, so it always rebuilds everything. - This can be slow. - -#. When typing ``make multiversion``, it will always check out exactly the branches listed in the ``conf.py`` file. - That means that local changes will not be shown. - -To show local changes in the multiversion output, you must first commit the changes to a local branch. -Then you must edit the `conf.py `_ file and change the ``smv_branch_whitelist`` variable to point to your branch. - -Checking for broken links -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To check for broken links on the site, run: - -.. code-block:: console - - $ make linkcheck - -This will check the entire site for broken links, and output the results to the screen and ``build/linkcheck``. - -.. _spelling-check: - -Spelling check -^^^^^^^^^^^^^^ - -The ``make spellcheck`` command scans the documentation files and flags any misspellings. -If errors are detected, review the suggestions and update the pull request as necessary. - -Some words, such as technical terms or proper nouns, maybe mistakenly flagged as misspelled. -If you encounter such instances, you can add them to the ignore list to prevent them from being flagged in the future. -To do this, add it to the `codespell_whitelist `_ file as follows: - -.. code-block:: text - - empy - jupyter - lets - ws - -To include custom corrections that ``codespell`` should apply, you can add them to the `codespell_dictionary `_ file as follows: - -.. code-block:: text - - amnet->ament - colcn->colcon - rosabg->rosbag - rosdistroy->rosdistro - -To check the dictionaries, you can run the ``make check-dictionaries`` command. -This will check the blank lines and leading/trailing spaces in the dictionaries. -If it complains about the dictionaries, you can run the ``make sort-dictionaries`` command. -This command will automatically modify the dictionaries if any issues are found. - -Migrating Pages from the ROS Wiki ---------------------------------- - -The first step in migrating a page from the `ROS Wiki `_ to the ROS 2 documentation is to determine if the page needs to be migrated. -Check if the content, or something similar, is available on https://docs.ros.org/en/rolling by searching for related terms. -If it has already been migrated, congratulations! -You are done. -If it hasn't been migrated, then consider whether it is worth keeping. -Pages that you or others find useful, and refer to regularly, are good candidates assuming they have not been superseded by other documentation. -Pages for ROS projects and features that are no longer supported by a current distribution should not be migrated. - -The next step for migrating a ROS Wiki page is to determine the correct location for the migrated page. -Only ROS Wiki pages that cover core ROS concepts belong in the ROS Documentation, these pages should be migrated to a logical location within the ROS documentation. -Package specific documentation should be migrated to the package-level documentation generated in the package's source repository. -Once the package level documentation has been updated it will be visible `as part of the package-level documentation `__. -If you are unsure whether and where to migrate a page, please get in touch via an issue on https://github.com/ros2/ros2_documentation or on https://discourse.openrobotics.org/. - -Once you've determined that a ROS Wiki page is worth migrating, and found an appropriate landing spot in the ROS documentation, the next step in the migration process is to set up the conversion tools necessary to migrate the page. -In most cases the only tools necessary to migrate a single ROS Wiki page to the ROS Docs are the `PanDoc `_ command line tool and a text editor. -PanDoc is supported by most modern operating systems using the installation instruction found on their website. -It is worth noting that the ROS Wiki uses an older wiki technology (MoinMoin), so the markup language used is an obscure dialect of the `MediaWiki `__ format. -We've found that the easiest way to migrate a page from the ROS Wiki is to convert it from HTML into reStructured text using PanDoc. - - -Migrating a Wiki File -^^^^^^^^^^^^^^^^^^^^^ - -#. Clone the appropriate repository. - If you are migrating a page to the official documentation hosted here, then you should clone https://github.com/ros2/ros2_documentation. - -#. Create a new Github branch for your migrated page. - We suggest something like ``pagename-migration``. - -#. Download the appropriate ROS Wiki page to an html file using wget or a similar tool (e.g. ``wget -O urdf.html https://wiki.ros.org/urdf``). - Alternatively you can use your web browser to save the page's HTML. - -#. Next you need to remove the extraneous HTML in the file you downloaded - Using your browser's developer mode, find the name of the first useful HTML element in the Wiki page. - In most cases all of the HTML between the third line of the file, starting with the ```` tag, through the start of the first ``

`` tag can be safely removed. - In the case where there is a table of contents, the first useful tag may be an ``

`` tag. - Similarly, the ROS wiki contains some footer text that starts with ``
`` and ends just above ```` that can also be removed. - -#. Convert your html file by running a PanDoc conversion between HTML and restructured text. - The following command converts an HTML file to the equivalent reStructured text files: ``pandoc -f html -t rst urdf.html > URDF.rst``. - -#. Attempt to build your new documentation using the ``make html`` command. - There may be errors and warnings that you will need to address. - -#. **CAREFULLY** read through the entire page making sure the material is up to date for ROS 2. - Check every single link to make sure it points to the appropriate location on docs.ros.org. - Internal document references must be updated to point to the equivalent ROS 2 material. - Your updated document should not point to the ROS Wiki unless it is absolutely necessary. - This process may require you alter the document considerably, and you may need to pull multiple wiki files. - You should verify that every code sample in the document is working correctly under ROS 2. - -#. Find and download any images that may be in the old document. - The easiest way to do this is to right click in the browser and download all of the images. - Alternatively you can find images by searching for ```` tags in the HTML file. - -#. For each image files downloaded update the image file links to point to the correct image directory for the ROS Docs. - If any of the images require updating, or could be replaced with a `Mermaid `__ chart, please make this change. - Be aware that Mermaid.js is only supported in the core ROS 2 documentation currently. - -#. Once your document is complete add a table of contents to the top of your new rst document using the appropriate Sphinx commands. - This block should replace any existing table of contents from the old ROS Wiki. - -#. Issue your pull request. - Make sure to point to the original ROS Wiki file for reference. - -#. Once your pull request has been accepted please add a note to the top of the page on the original ROS Wiki article pointing to the new documentation page. - -For a real-world example of this process in action, please refer to the ROS 2 Image Processing Pipeline in both `the ROS 2 Docs `__ and in the original `ROS Wiki `__. -The completed documentation page can be found in the `ROS 2 package documentation for image_pipeline `__. - -Building the Site with GitHub Codespaces ----------------------------------------- -First, you need to have a GitHub account (if you don't have one, you can create one for free). -Then, you need to go to the `ROS 2 Documentation GitHub repository `__. -After that, you can open the repository in Codespaces, it can be done just by clicking on the "Code" button on the repository page, then choose "Open with Codespaces" from the dropdown menu. - -.. image:: images/codespaces.png - :width: 100% - :alt: Codespaces creation - -After that, you will be redirected to your Codespaces page, where you can see the progress of the Codespaces creation. -Once it is done, a Visual Studio Code tab will be opened in your browser. -You can open the terminal by clicking on the "Terminal" tab in the top panel or by pressing :kbd:`Ctrl-J`. - -In this terminal, you can run any command you want, for example, you can run the following command to build the site for just this branch: - -.. code-block:: console - - $ make html - -Finally, to view the site, you can click on the "Go Live" button in the right bottom panel and then, it will open the site in a new tab in your browser (you will need to browse to the ``build/html`` folder). - -.. image:: images/live_server.png - :width: 100% - :alt: Live Server - -Building the Site with Devcontainer ------------------------------------ - -`ROS 2 Documentation GitHub repository `__ also supports ``Devcontainer`` development environment with Visual Studio Code. -This will enable you to build the documentation much easier without changing your operating system. - -See :doc:`../../Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container` to install VS Code and Docker before the following procedure. - -Clone repository and start VS Code: - -.. code-block:: console - - $ git clone https://github.com/ros2/ros2_documentation - $ cd ./ros2_documentation - $ code . - -To use ``Devcontainer``, you need to install "Remote Development" Extension within VS Code search in Extensions (CTRL+SHIFT+X) for it. - -And then, use ``View->Command Palette...`` or ``Ctrl+Shift+P`` to open the command palette. -Search for the command ``Dev Containers: Reopen in Container`` and execute it. -This will build your development docker container for you automatically. - -To build the documentation, open a terminal using ``View->Terminal`` or ``Ctrl+Shift+``` and ``New Terminal`` in VS Code. -Inside the terminal, you can build the documentation: - -.. code-block:: console - - $ make html - -.. image:: images/vscode_devcontainer.png - :width: 100% - :alt: VS Code Devcontainer - -Writing pages -------------- - -The ROS 2 documentation website uses the ``reStructuredText`` format, which is the default plaintext markup language used by Sphinx. -This section is a brief introduction to ``reStructuredText`` concepts, syntax, and best practices. -When formatting your ``reStructuredText`` file **please make sure to write only one sentence per line as it makes reviewing and modifying your file much easier.** -Also, be mindful of the use of white space in your file! -The ROS 2 documentation linter will not accept pull requests with trailing white space. -We recommend that you enable automatic white space highlighting and or cleanup if your editor supports it. - -You can refer to `reStructuredText User Documentation `_ for a detailed technical specification. - -Table of Contents -^^^^^^^^^^^^^^^^^ - -There are two types of directives used for the generation of a table of contents, ``.. toctree::`` and ``.. contents::``. -The ``.. toctree::`` is used in top-level pages like ``Tutorials.rst`` to set ordering and visibility of its child pages. -This directive creates both left navigation panel and in-page navigation links to the child pages listed. -It helps readers to understand the structure of separate documentation sections and navigate between pages. - -.. code-block:: rst - - .. toctree:: - :maxdepth: 1 - -The ``.. contents::`` directive is used for the generation of a table of contents for that particular page. -It parses all present headings in a page and builds an in-page nested table of contents. -It helps readers to see an overview of the content and navigate inside a page. - -The ``.. contents::`` directive supports the definition of maximum depth of nested sections. -Using ``:depth: 2`` will only show Sections and Subsections in the table of contents. - -.. code-block:: rst - - .. contents:: Table of Contents - :depth: 2 - :local: - -Headings -^^^^^^^^ - -There are four main Heading types used in the documentation. -Note that the number of symbols has to match the length of the title. - -.. code-block:: rst - - Page Title Header - ================= - - Section Header - -------------- - - 2 Subsection Header - ^^^^^^^^^^^^^^^^^^^ - - 2.4 Subsubsection Header - ~~~~~~~~~~~~~~~~~~~~~~~~ - -We usually use one digit for numbering subsections and two digits (dot separated) for numbering subsubsections in Tutorials and How-To-Guides. - -Lists -^^^^^ - -Stars ``*`` are used for listing unordered items with bullet points and number sign ``#.`` is used for listing numbered items. -Both of them support nested definitions and will render accordingly. - -.. code-block:: rst - - * bullet point - - * bullet point nested - * bullet point nested - - * bullet point - -.. code-block:: rst - - #. first listed item - #. second lited item - -Code Formatting -^^^^^^^^^^^^^^^ - -In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. - -.. code-block:: rst - - In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. - -Code blocks inside a page need to be captured using ``.. code-block::`` `directives `_. -``.. code-block::`` supports code highlighting for syntaxes like ``C++``, ``YAML``, ``console``, ``bash``, and more. -Code inside the directive needs to be indented. - -.. code-block:: rst - - .. code-block:: C++ - - int main(int argc, char** argv) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -Code blocks: ``bash`` vs. ``console`` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -``bash`` and ``console`` are similar, but they serve two different purposes. -Choosing the right one is important to ensure that the content is formatted correctly and that the copy button copies the right content. -Below is an explanation of each one; skip to the end of this section for a list of use-cases and corresponding examples. - -``bash`` is meant for scripts, e.g., for bash commands from a script file. -Example result: - -.. code-block:: bash - - export ROS_DOMAIN_ID=42 - ros2 run turtlesim turtlesim_node - -``console`` is meant for commands to be run in a terminal, optionally including their output. -This makes it clear that the given commands need to be run in a terminal. -It also allows separating command lines from output lines using prompt symbols such as ``$`` or ``#``. -Command lines are formatted as bash commands while output lines are formatted as normal text. -The prompt symbol is not selectable, and clicking on the copy button in the upper right-hand corner copies *only* the commands, not the outputs nor the prompt symbols. -This means that, if a ``console`` code block is used without any ``$``, the copy button will not copy any lines. -Example result: - -.. code-block:: console - - $ export ROS_DOMAIN_ID=42 - $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" - [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle - [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - -Compare the above with a ``bash`` ``code-block``: - -.. code-block:: bash - - $ export ROS_DOMAIN_ID=42 - $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" - [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle - [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - -To simplify code blocks, ``bash`` can still be used without ``$`` for commands meant to be run in a terminal if the code block does not include any output lines. -To help choose between ``bash`` and ``console``, see the following list of use-cases and corresponding examples: - -#. Commands meant to be copied into a script file - - * Use ``.. code-block:: bash`` without ``$``: - - .. code-block:: bash - - export ROS_DOMAIN_ID=42 - ros2 run turtlesim turtlesim_node - -#. Commands meant to be run in a terminal: - - * It is highly recommended to use ``.. code-block:: console`` with ``$`` on all command lines for consistency and clarity. - If there is output that needs to be displayed, include it in the same block: - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run turtlesim turtlesim_node - [INFO] [1743878028.269334696] [turtlesim]: Starting turtlesim with node name /turtlesim - [INFO] [1743878028.275096618] [turtlesim]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] - - .. note:: - - If some output lines start with ``#``, it is crucial to separate commands from their output because the ``#`` symbol is used to denote a command. - Therefore, place the output in a separate ``.. code-block:: text``. - -Images -^^^^^^ - -Images can be inserted using the ``.. image::`` directive. - -.. code-block:: rst - - .. image:: images/turtlesim_follow1.png - -In this case, the image file (``turtlesim_follow1.png``) is located in the ``images/`` directory relative to the ``.rst`` file that uses the image. - -However, all image files end up in an ``_images/`` directory relative to the root of the docs. -Therefore, when using ``:target:`` to add a hyperlink to the image file, use a relative link going up to the root directory and then down to the ``_images/`` directory. - -.. code-block:: rst - - .. image:: images/turtlesim_follow1.png - :target: ../../_images/turtlesim_follow1.png - -Charts, Graphs, and Diagrams -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ROS 2 Documentation now supports charts, graphs, and diagrams written using `Mermaid Charts. `__ -We prefer that charts, graphs, and diagrams use Mermaid instead of static image files as it allows us to programmatically update and edit these resources as the project evolves. -Full documentation of the `Mermaid graph language syntax can be found on their website. `__ - -References and Links -^^^^^^^^^^^^^^^^^^^^ - -External links -~~~~~~~~~~~~~~ - -The syntax of creating links to external web pages is shown below. - -.. code-block:: rst - - `ROS Docs `_ - -The above link will appear as `ROS Docs `_. -Note the underscore after the final single quote. - -Internal links -~~~~~~~~~~~~~~ - -The ``:doc:`` directive is used to create in-text links to other pages. - -.. code-block:: rst - - :doc:`Quality of Service <../Tutorials/Quality-of-Service>` - -Note that the relative path to the file is used. - -The ``ref`` directive is used to make links to specific parts of a page. -These could be headings, images or code sections inside the current or different page. - -Definition of explicit target right before the desired object is required. -In the example below, the target is defined as ``_talker-listener`` one line before the heading ``Try some examples``. - -.. code-block:: rst - - .. _talker-listener: - - Try some examples - ----------------- - -Now the link from any page in the documentation to that header can be created. - -.. code-block:: rst - - :ref:`talker-listener demo ` - -This link will navigate a reader to the target page with an HTML anchor link ``#talker-listener``. - -Macros -~~~~~~ - -Macros can be used to simplify writing documentation that targets multiple distributions. - -Use a macro by including the macro name in curly braces. -For example, when generating the docs for Rolling on the ``rolling`` branch: - -.. list-table:: - :header-rows: 1 - - * - Macro - - Example - - Becomes (for {DISTRO_TITLE}) - * - \{DISTRO\} - - ros-\{DISTRO\}-pkg - - ros-{DISTRO}-pkg - * - \{DISTRO_TITLE\} - - ROS 2 \{DISTRO_TITLE\} - - ROS 2 {DISTRO_TITLE} - * - \{DISTRO_TITLE_FULL\} - - ROS 2 \{DISTRO_TITLE_FULL\} - - ROS 2 {DISTRO_TITLE_FULL} - * - \{REPOS_FILE_BRANCH\} - - git checkout \{REPOS_FILE_BRANCH\} - - git checkout {REPOS_FILE_BRANCH} - * - \{interface_link(std_msgs/msg/String)\} - - See: \{interface_link(std_msgs/msg/String)\}. - - See: {interface_link(std_msgs/msg/String)}. - * - \{interface(std_msgs/msg/String)\} - - Publish a \{interface(std_msgs/msg/String)\}. - - Publish a {interface(std_msgs/msg/String)}. - * - \{package_link(rclcpp)\} - - See: \{package_link(rclcpp)\}. - - See: {package_link(rclcpp)}. - * - \{package(rclcpp)\} - - Use \{package(rclcpp)\}. - - Use {package(rclcpp)}. - -The same file can be used on multiple branches (i.e., for multiple distros) and the generated content will be distro-specific. +.. redirect-from:: + + Contributing/Contributing-To-ROS-2-Documentation + +Contributing to ROS 2 Documentation +=================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Contributions to this site are most welcome. +This page explains how to contribute to ROS 2 Documentation. +Please be sure to read the below sections carefully before contributing. + +The site is built using `Sphinx `_, and more particularly using `Sphinx multiversion `_. + +Branch structure +---------------- + +The source code of documentation is located in the `ROS 2 Documentation GitHub repository `_. +This repository is set up with one branch per ROS 2 distribution to handle differences between the distributions. +If a change is common to all ROS 2 distributions, it should be made to the ``rolling`` branch (and then will be backported as appropriate). +If a change is specific to a particular ROS 2 distribution, it should be made to the respective branch. + +Source structure +---------------- + +The source files for the site are all located under the ``source`` subdirectory. +Templates for various sphinx plugins are located under ``source/_templates``. +The root directory contains configuration and files required to locally build the site for testing. + +Building the site locally +------------------------- + +Start by creating `venv `__ to build the documentation: + +.. code-block:: console + + $ python3 -m venv ros2doc # create venv + $ source ros2doc/bin/activate # activate venv + +And install requirements located in the ``requirements.txt`` file: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ pip install -r requirements.txt -c constraints.txt + + .. group-tab:: macOS + + .. code-block:: console + + $ pip install -r requirements.txt -c constraints.txt + + .. group-tab:: Windows + + .. code-block:: console + + $ python -m pip install -r requirements.txt -c constraints.txt + +In order for Sphinx to be able to generate diagrams, the ``dot`` command must be available. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ sudo apt update ; sudo apt install graphviz + + .. group-tab:: macOS + + .. code-block:: console + + $ brew install graphviz + + .. group-tab:: Windows + + Download an installer from `the Graphviz Download page `__ and install it. + Make sure to allow the installer to add it to the Windows ``%PATH%``, otherwise Sphinx will not be able to find it. + +Building the site for one branch +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build the site for just this branch, type ``make html`` at the top-level of the repository. +This is the recommended way to test out local changes. + +.. code-block:: console + + $ make html + +The build process can take some time. +To see the output, open ``build/html/index.html`` in your browser. + + +Checking / Testing the site +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You can run the documentation tests locally (using `doc8 `_) with the following command: + +.. code-block:: console + + $ make test + +You can run the Python documentation tools tests locally (using `pytest `_) with the following command: + +.. code-block:: console + + $ make test-tools + +You can run the documentation linter locally (using `sphinx-lint `_) with the following command: + +.. code-block:: console + + $ make lint + +You can run the documentation spell checker locally (using `codespell `_) with the following command: + +.. code-block:: console + + $ make spellcheck + +.. note:: + + If that detects specific words that need to be ignored, add it to `codespell_whitelist `_ . + +To know more about spelling checks, refer to :ref:`Spelling check ` + +View Site Through Github CI +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For small changes to the ROS 2 Docs you can view your changes as rendered HTML using artifacts generated in our Github Actions. +The "build" action produces the entire ROS Docs as a downloadable Zip file that contains all HTML for `docs.ros.org `_ +This build action is triggered after passing the test action and lint action. + +To download and view your changes first go to your pull request and under the title click the "Checks" tab. +On the left hand side of the checks page, click on the "Test" section under the "tests" section click on "build" dialog. +This will open a menu on the right, where you can click on "Upload document artifacts" and scroll to the bottom to see the download link for the Zipped' HTML files under the heading "Artifact download URL". + +.. image:: ./images/github_action.png + :width: 100% + :alt: Steps to find rendered HTML files on ROS Github action + +Building the site for all branches +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To build the site for all branches, type ``make multiversion`` from the ``rolling`` branch. +This has two drawbacks: + +#. The multiversion plugin doesn't understand how to do incremental builds, so it always rebuilds everything. + This can be slow. + +#. When typing ``make multiversion``, it will always check out exactly the branches listed in the ``conf.py`` file. + That means that local changes will not be shown. + +To show local changes in the multiversion output, you must first commit the changes to a local branch. +Then you must edit the `conf.py `_ file and change the ``smv_branch_whitelist`` variable to point to your branch. + +Checking for broken links +^^^^^^^^^^^^^^^^^^^^^^^^^ + +To check for broken links on the site, run: + +.. code-block:: console + + $ make linkcheck + +This will check the entire site for broken links, and output the results to the screen and ``build/linkcheck``. + +.. _spelling-check: + +Spelling check +^^^^^^^^^^^^^^ + +The ``make spellcheck`` command scans the documentation files and flags any misspellings. +If errors are detected, review the suggestions and update the pull request as necessary. + +Some words, such as technical terms or proper nouns, maybe mistakenly flagged as misspelled. +If you encounter such instances, you can add them to the ignore list to prevent them from being flagged in the future. +To do this, add it to the `codespell_whitelist `_ file as follows: + +.. code-block:: text + + empy + jupyter + lets + ws + +To include custom corrections that ``codespell`` should apply, you can add them to the `codespell_dictionary `_ file as follows: + +.. code-block:: text + + amnet->ament + colcn->colcon + rosabg->rosbag + rosdistroy->rosdistro + +To check the dictionaries, you can run the ``make check-dictionaries`` command. +This will check the blank lines and leading/trailing spaces in the dictionaries. +If it complains about the dictionaries, you can run the ``make sort-dictionaries`` command. +This command will automatically modify the dictionaries if any issues are found. + +Migrating Pages from the ROS Wiki +--------------------------------- + +The first step in migrating a page from the `ROS Wiki `_ to the ROS 2 documentation is to determine if the page needs to be migrated. +Check if the content, or something similar, is available on https://docs.ros.org/en/rolling by searching for related terms. +If it has already been migrated, congratulations! +You are done. +If it hasn't been migrated, then consider whether it is worth keeping. +Pages that you or others find useful, and refer to regularly, are good candidates assuming they have not been superseded by other documentation. +Pages for ROS projects and features that are no longer supported by a current distribution should not be migrated. + +The next step for migrating a ROS Wiki page is to determine the correct location for the migrated page. +Only ROS Wiki pages that cover core ROS concepts belong in the ROS Documentation, these pages should be migrated to a logical location within the ROS documentation. +Package specific documentation should be migrated to the package-level documentation generated in the package's source repository. +Once the package level documentation has been updated it will be visible `as part of the package-level documentation `__. +If you are unsure whether and where to migrate a page, please get in touch via an issue on https://github.com/ros2/ros2_documentation or on https://discourse.openrobotics.org/. + +Once you've determined that a ROS Wiki page is worth migrating, and found an appropriate landing spot in the ROS documentation, the next step in the migration process is to set up the conversion tools necessary to migrate the page. +In most cases the only tools necessary to migrate a single ROS Wiki page to the ROS Docs are the `PanDoc `_ command line tool and a text editor. +PanDoc is supported by most modern operating systems using the installation instruction found on their website. +It is worth noting that the ROS Wiki uses an older wiki technology (MoinMoin), so the markup language used is an obscure dialect of the `MediaWiki `__ format. +We've found that the easiest way to migrate a page from the ROS Wiki is to convert it from HTML into reStructured text using PanDoc. + + +Migrating a Wiki File +^^^^^^^^^^^^^^^^^^^^^ + +#. Clone the appropriate repository. + If you are migrating a page to the official documentation hosted here, then you should clone https://github.com/ros2/ros2_documentation. + +#. Create a new Github branch for your migrated page. + We suggest something like ``pagename-migration``. + +#. Download the appropriate ROS Wiki page to an html file using wget or a similar tool (e.g. ``wget -O urdf.html https://wiki.ros.org/urdf``). + Alternatively you can use your web browser to save the page's HTML. + +#. Next you need to remove the extraneous HTML in the file you downloaded + Using your browser's developer mode, find the name of the first useful HTML element in the Wiki page. + In most cases all of the HTML between the third line of the file, starting with the ```` tag, through the start of the first ``

`` tag can be safely removed. + In the case where there is a table of contents, the first useful tag may be an ``

`` tag. + Similarly, the ROS wiki contains some footer text that starts with ``
`` and ends just above ```` that can also be removed. + +#. Convert your html file by running a PanDoc conversion between HTML and restructured text. + The following command converts an HTML file to the equivalent reStructured text files: ``pandoc -f html -t rst urdf.html > URDF.rst``. + +#. Attempt to build your new documentation using the ``make html`` command. + There may be errors and warnings that you will need to address. + +#. **CAREFULLY** read through the entire page making sure the material is up to date for ROS 2. + Check every single link to make sure it points to the appropriate location on docs.ros.org. + Internal document references must be updated to point to the equivalent ROS 2 material. + Your updated document should not point to the ROS Wiki unless it is absolutely necessary. + This process may require you alter the document considerably, and you may need to pull multiple wiki files. + You should verify that every code sample in the document is working correctly under ROS 2. + +#. Find and download any images that may be in the old document. + The easiest way to do this is to right click in the browser and download all of the images. + Alternatively you can find images by searching for ```` tags in the HTML file. + +#. For each image files downloaded update the image file links to point to the correct image directory for the ROS Docs. + If any of the images require updating, or could be replaced with a `Mermaid `__ chart, please make this change. + Be aware that Mermaid.js is only supported in the core ROS 2 documentation currently. + +#. Once your document is complete add a table of contents to the top of your new rst document using the appropriate Sphinx commands. + This block should replace any existing table of contents from the old ROS Wiki. + +#. Issue your pull request. + Make sure to point to the original ROS Wiki file for reference. + +#. Once your pull request has been accepted please add a note to the top of the page on the original ROS Wiki article pointing to the new documentation page. + +For a real-world example of this process in action, please refer to the ROS 2 Image Processing Pipeline in both `the ROS 2 Docs `__ and in the original `ROS Wiki `__. +The completed documentation page can be found in the `ROS 2 package documentation for image_pipeline `__. + +Building the Site with GitHub Codespaces +---------------------------------------- +First, you need to have a GitHub account (if you don't have one, you can create one for free). +Then, you need to go to the `ROS 2 Documentation GitHub repository `__. +After that, you can open the repository in Codespaces, it can be done just by clicking on the "Code" button on the repository page, then choose "Open with Codespaces" from the dropdown menu. + +.. image:: images/codespaces.png + :width: 100% + :alt: Codespaces creation + +After that, you will be redirected to your Codespaces page, where you can see the progress of the Codespaces creation. +Once it is done, a Visual Studio Code tab will be opened in your browser. +You can open the terminal by clicking on the "Terminal" tab in the top panel or by pressing :kbd:`Ctrl-J`. + +In this terminal, you can run any command you want, for example, you can run the following command to build the site for just this branch: + +.. code-block:: console + + $ make html + +Finally, to view the site, you can click on the "Go Live" button in the right bottom panel and then, it will open the site in a new tab in your browser (you will need to browse to the ``build/html`` folder). + +.. image:: images/live_server.png + :width: 100% + :alt: Live Server + +Building the Site with Devcontainer +----------------------------------- + +`ROS 2 Documentation GitHub repository `__ also supports ``Devcontainer`` development environment with Visual Studio Code. +This will enable you to build the documentation much easier without changing your operating system. + +See :doc:`../../Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container` to install VS Code and Docker before the following procedure. + +Clone repository and start VS Code: + +.. code-block:: console + + $ git clone https://github.com/ros2/ros2_documentation + $ cd ./ros2_documentation + $ code . + +To use ``Devcontainer``, you need to install "Remote Development" Extension within VS Code search in Extensions (CTRL+SHIFT+X) for it. + +And then, use ``View->Command Palette...`` or ``Ctrl+Shift+P`` to open the command palette. +Search for the command ``Dev Containers: Reopen in Container`` and execute it. +This will build your development docker container for you automatically. + +To build the documentation, open a terminal using ``View->Terminal`` or ``Ctrl+Shift+``` and ``New Terminal`` in VS Code. +Inside the terminal, you can build the documentation: + +.. code-block:: console + + $ make html + +.. image:: images/vscode_devcontainer.png + :width: 100% + :alt: VS Code Devcontainer + +Writing pages +------------- + +The ROS 2 documentation website uses the ``reStructuredText`` format, which is the default plaintext markup language used by Sphinx. +This section is a brief introduction to ``reStructuredText`` concepts, syntax, and best practices. +When formatting your ``reStructuredText`` file **please make sure to write only one sentence per line as it makes reviewing and modifying your file much easier.** +Also, be mindful of the use of white space in your file! +The ROS 2 documentation linter will not accept pull requests with trailing white space. +We recommend that you enable automatic white space highlighting and or cleanup if your editor supports it. + +You can refer to `reStructuredText User Documentation `_ for a detailed technical specification. + +Table of Contents +^^^^^^^^^^^^^^^^^ + +There are two types of directives used for the generation of a table of contents, ``.. toctree::`` and ``.. contents::``. +The ``.. toctree::`` is used in top-level pages like ``Tutorials.rst`` to set ordering and visibility of its child pages. +This directive creates both left navigation panel and in-page navigation links to the child pages listed. +It helps readers to understand the structure of separate documentation sections and navigate between pages. + +.. code-block:: rst + + .. toctree:: + :maxdepth: 1 + +The ``.. contents::`` directive is used for the generation of a table of contents for that particular page. +It parses all present headings in a page and builds an in-page nested table of contents. +It helps readers to see an overview of the content and navigate inside a page. + +The ``.. contents::`` directive supports the definition of maximum depth of nested sections. +Using ``:depth: 2`` will only show Sections and Subsections in the table of contents. + +.. code-block:: rst + + .. contents:: Table of Contents + :depth: 2 + :local: + +Headings +^^^^^^^^ + +There are four main Heading types used in the documentation. +Note that the number of symbols has to match the length of the title. + +.. code-block:: rst + + Page Title Header + ================= + + Section Header + -------------- + + 2 Subsection Header + ^^^^^^^^^^^^^^^^^^^ + + 2.4 Subsubsection Header + ~~~~~~~~~~~~~~~~~~~~~~~~ + +We usually use one digit for numbering subsections and two digits (dot separated) for numbering subsubsections in Tutorials and How-To-Guides. + +Lists +^^^^^ + +Stars ``*`` are used for listing unordered items with bullet points and number sign ``#.`` is used for listing numbered items. +Both of them support nested definitions and will render accordingly. + +.. code-block:: rst + + * bullet point + + * bullet point nested + * bullet point nested + + * bullet point + +.. code-block:: rst + + #. first listed item + #. second lited item + +Code Formatting +^^^^^^^^^^^^^^^ + +In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. + +.. code-block:: rst + + In-text code can be formatted using ``backticks`` for showing ``highlighted`` code. + +Code blocks inside a page need to be captured using ``.. code-block::`` `directives `_. +``.. code-block::`` supports code highlighting for syntaxes like ``C++``, ``YAML``, ``console``, ``bash``, and more. +Code inside the directive needs to be indented. + +.. code-block:: rst + + .. code-block:: C++ + + int main(int argc, char** argv) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +Code blocks: ``bash`` vs. ``console`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +``bash`` and ``console`` are similar, but they serve two different purposes. +Choosing the right one is important to ensure that the content is formatted correctly and that the copy button copies the right content. +Below is an explanation of each one; skip to the end of this section for a list of use-cases and corresponding examples. + +``bash`` is meant for scripts, e.g., for bash commands from a script file. +Example result: + +.. code-block:: bash + + export ROS_DOMAIN_ID=42 + ros2 run turtlesim turtlesim_node + +``console`` is meant for commands to be run in a terminal, optionally including their output. +This makes it clear that the given commands need to be run in a terminal. +It also allows separating command lines from output lines using prompt symbols such as ``$`` or ``#``. +Command lines are formatted as bash commands while output lines are formatted as normal text. +The prompt symbol is not selectable, and clicking on the copy button in the upper right-hand corner copies *only* the commands, not the outputs nor the prompt symbols. +This means that, if a ``console`` code block is used without any ``$``, the copy button will not copy any lines. +Example result: + +.. code-block:: console + + $ export ROS_DOMAIN_ID=42 + $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" + [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle + [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + +Compare the above with a ``bash`` ``code-block``: + +.. code-block:: bash + + $ export ROS_DOMAIN_ID=42 + $ ros2 run turtlesim turtlesim_node --ros-args --remap "__node:=my_turtle" + [INFO] [1742150439.022947971] [my_turtle]: Starting turtlesim with node name /my_turtle + [INFO] [1742150439.026043867] [my_turtle]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + +To simplify code blocks, ``bash`` can still be used without ``$`` for commands meant to be run in a terminal if the code block does not include any output lines. +To help choose between ``bash`` and ``console``, see the following list of use-cases and corresponding examples: + +#. Commands meant to be copied into a script file + + * Use ``.. code-block:: bash`` without ``$``: + + .. code-block:: bash + + export ROS_DOMAIN_ID=42 + ros2 run turtlesim turtlesim_node + +#. Commands meant to be run in a terminal: + + * It is highly recommended to use ``.. code-block:: console`` with ``$`` on all command lines for consistency and clarity. + If there is output that needs to be displayed, include it in the same block: + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run turtlesim turtlesim_node + [INFO] [1743878028.269334696] [turtlesim]: Starting turtlesim with node name /turtlesim + [INFO] [1743878028.275096618] [turtlesim]: Spawning turtle [turtle1] at x=[5.544445], y=[5.544445], theta=[0.000000] + + .. note:: + + If some output lines start with ``#``, it is crucial to separate commands from their output because the ``#`` symbol is used to denote a command. + Therefore, place the output in a separate ``.. code-block:: text``. + +Images +^^^^^^ + +Images can be inserted using the ``.. image::`` directive. + +.. code-block:: rst + + .. image:: images/turtlesim_follow1.png + +In this case, the image file (``turtlesim_follow1.png``) is located in the ``images/`` directory relative to the ``.rst`` file that uses the image. + +However, all image files end up in an ``_images/`` directory relative to the root of the docs. +Therefore, when using ``:target:`` to add a hyperlink to the image file, use a relative link going up to the root directory and then down to the ``_images/`` directory. + +.. code-block:: rst + + .. image:: images/turtlesim_follow1.png + :target: ../../_images/turtlesim_follow1.png + +Charts, Graphs, and Diagrams +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ROS 2 Documentation now supports charts, graphs, and diagrams written using `Mermaid Charts. `__ +We prefer that charts, graphs, and diagrams use Mermaid instead of static image files as it allows us to programmatically update and edit these resources as the project evolves. +Full documentation of the `Mermaid graph language syntax can be found on their website. `__ + +References and Links +^^^^^^^^^^^^^^^^^^^^ + +External links +~~~~~~~~~~~~~~ + +The syntax of creating links to external web pages is shown below. + +.. code-block:: rst + + `ROS Docs `_ + +The above link will appear as `ROS Docs `_. +Note the underscore after the final single quote. + +Internal links +~~~~~~~~~~~~~~ + +The ``:doc:`` directive is used to create in-text links to other pages. + +.. code-block:: rst + + :doc:`Quality of Service <../Tutorials/Quality-of-Service>` + +Note that the relative path to the file is used. + +The ``ref`` directive is used to make links to specific parts of a page. +These could be headings, images or code sections inside the current or different page. + +Definition of explicit target right before the desired object is required. +In the example below, the target is defined as ``_talker-listener`` one line before the heading ``Try some examples``. + +.. code-block:: rst + + .. _talker-listener: + + Try some examples + ----------------- + +Now the link from any page in the documentation to that header can be created. + +.. code-block:: rst + + :ref:`talker-listener demo ` + +This link will navigate a reader to the target page with an HTML anchor link ``#talker-listener``. + +Macros +~~~~~~ + +Macros can be used to simplify writing documentation that targets multiple distributions. + +Use a macro by including the macro name in curly braces. +For example, when generating the docs for Rolling on the ``rolling`` branch: + +.. list-table:: + :header-rows: 1 + + * - Macro + - Example + - Becomes (for {DISTRO_TITLE}) + * - \{DISTRO\} + - ros-\{DISTRO\}-pkg + - ros-{DISTRO}-pkg + * - \{DISTRO_TITLE\} + - ROS 2 \{DISTRO_TITLE\} + - ROS 2 {DISTRO_TITLE} + * - \{DISTRO_TITLE_FULL\} + - ROS 2 \{DISTRO_TITLE_FULL\} + - ROS 2 {DISTRO_TITLE_FULL} + * - \{REPOS_FILE_BRANCH\} + - git checkout \{REPOS_FILE_BRANCH\} + - git checkout {REPOS_FILE_BRANCH} + * - \{interface_link(std_msgs/msg/String)\} + - See: \{interface_link(std_msgs/msg/String)\}. + - See: {interface_link(std_msgs/msg/String)}. + * - \{interface(std_msgs/msg/String)\} + - Publish a \{interface(std_msgs/msg/String)\}. + - Publish a {interface(std_msgs/msg/String)}. + * - \{package_link(rclcpp)\} + - See: \{package_link(rclcpp)\}. + - See: {package_link(rclcpp)}. + * - \{package(rclcpp)\} + - Use \{package(rclcpp)\}. + - Use {package(rclcpp)}. + +The same file can be used on multiple branches (i.e., for multiple distros) and the generated content will be distro-specific. From 47bcb2877c6b7801206a363e8d11685290704795 Mon Sep 17 00:00:00 2001 From: dmarshant Date: Tue, 26 May 2026 14:32:25 +0100 Subject: [PATCH 11/20] Remove redundant topics; fixed broken links --- source/Concepts.rst | 17 ----------- source/Get-Started.rst | 1 + .../Interfaces-Topics-Services-Actions.rst | 6 +--- source/Tutorials.rst | 26 ----------------- source/Tutorials/Advanced.rst | 26 ----------------- source/Tutorials/Demos.rst | 29 ------------------- source/Tutorials/Intermediate.rst | 22 -------------- source/Tutorials/Miscellaneous.rst | 10 ------- source/index.rst | 10 +++---- 9 files changed, 7 insertions(+), 140 deletions(-) delete mode 100644 source/Concepts.rst delete mode 100644 source/Tutorials.rst delete mode 100644 source/Tutorials/Advanced.rst delete mode 100644 source/Tutorials/Demos.rst delete mode 100644 source/Tutorials/Intermediate.rst delete mode 100644 source/Tutorials/Miscellaneous.rst diff --git a/source/Concepts.rst b/source/Concepts.rst deleted file mode 100644 index d2283ba2da2..00000000000 --- a/source/Concepts.rst +++ /dev/null @@ -1,17 +0,0 @@ -Concepts -======== - -Conceptual overviews provide relatively high-level, general background information about key aspects of ROS 2. - -.. toctree:: - :maxdepth: 1 - - Concepts/Basic - Concepts/Intermediate - Concepts/Advanced - - -Related Content -^^^^^^^^^^^^^^^ - -:doc:`See the ROS 2 citations ` for more explanation of concepts and citable resources. diff --git a/source/Get-Started.rst b/source/Get-Started.rst index 1c3651542df..4f12e86c94a 100644 --- a/source/Get-Started.rst +++ b/source/Get-Started.rst @@ -12,5 +12,6 @@ PLACEHOLDER Get-Started/About-ROS Get-Started/Installation Get-Started/Releases + Get-Started/First-Steps Get-Started/Configuring-ROS2-Environment Get-Started/Introducing-Turtlesim/Introducing-Turtlesim \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst b/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst index dddf9a89415..bded41a9047 100644 --- a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst +++ b/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst @@ -1,7 +1,3 @@ -.. redirect-from:: - - How-To-Guides/Topics-Services-Actions - .. _interfaces-topics-services-actions: Interfaces (topics, services, actions) @@ -78,7 +74,7 @@ This gives you a clear view of timing patterns, delays, and irregularities, maki The default interval is 1 second. The default statistics topic is ``/statistics``. -:doc:`Learn how to enable topic statistics ` +:doc:`Learn how to enable topic statistics <../../Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial>` Services -------- diff --git a/source/Tutorials.rst b/source/Tutorials.rst deleted file mode 100644 index e9516a52be6..00000000000 --- a/source/Tutorials.rst +++ /dev/null @@ -1,26 +0,0 @@ -.. _Tutorials: - -Tutorials -========= - -The tutorials are a collection of step-by-step instructions meant to steadily build skills in ROS 2. - -The best way to approach the tutorials is to walk through them for the first time in order, as they build off of each other and are not meant to be comprehensive documentation. - -For quick solutions to more specific questions, see the :doc:`How-To-Guides`. - -.. toctree:: - :maxdepth: 2 - - First-Steps - Tutorials/Beginner-CLI-Tools - Tutorials/Beginner-Client-Libraries - Tutorials/Intermediate - Tutorials/Advanced - Tutorials/Demos - Tutorials/Miscellaneous - -Examples --------- - -* `Python and C++ minimal examples `__. diff --git a/source/Tutorials/Advanced.rst b/source/Tutorials/Advanced.rst deleted file mode 100644 index a200b872483..00000000000 --- a/source/Tutorials/Advanced.rst +++ /dev/null @@ -1,26 +0,0 @@ -Advanced -======== - -.. toctree:: - :maxdepth: 1 - - Advanced/Supplementing-Custom-Rosdep-Keys - Advanced/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial - Advanced/Topic-Keys/Topic-Keys-Tutorial - Advanced/Topic-Keys/Filtered-Topic-Keys-Tutorial - Advanced/Discovery-Server/Discovery-Server - Advanced/Allocator-Template-Tutorial - Advanced/Ament-Lint-For-Clean-Code - Advanced/FastDDS-Configuration - Advanced/Improved-Dynamic-Discovery - Advanced/Recording-A-Bag-From-Your-Own-Node-CPP - Advanced/Recording-A-Bag-From-Your-Own-Node-Py - Advanced/Reading-From-A-Bag-File-CPP - Advanced/Reading-From-A-Bag-File-Python - Advanced/Create-An-Rqtbag-Plugin - Advanced/ROS2-Tracing-Trace-and-Analyze - Advanced/Creating-An-RMW-Implementation - Advanced/Writing-a-Buffer-Backend - Advanced/Writing-a-Buffer-Compatible-Conversions-Package - Advanced/Simulators/Simulation-Main - Advanced/Security/Security-Main diff --git a/source/Tutorials/Demos.rst b/source/Tutorials/Demos.rst deleted file mode 100644 index ecaaa851c71..00000000000 --- a/source/Tutorials/Demos.rst +++ /dev/null @@ -1,29 +0,0 @@ -Demos -===== - -.. toctree:: - :maxdepth: 1 - - Demos/Quality-of-Service - Demos/Managed-Nodes - Demos/Intra-Process-Communication - Demos/GPU-Buffer-Transport - Demos/Real-Time-Programming - Demos/dummy-robot-demo - Demos/Logging-and-logger-configuration - Demos/Content-Filtering-Subscription - Demos/Service-Introspection - Demos/Action-Introspection - Demos/Wait-for-Acknowledgment - -External resources ------------------- - -* `Bridging communication between ROS 1 and ROS 2 `__ -* `Motion planning for a MoveIt 2 arm `__ -* Using Turtlebot 3 (community-contributed) - - - `Getting started `__ - - `Simulating `__ - - `Navigating in simulation `__ - - `Learning SLAM in simulation `__ diff --git a/source/Tutorials/Intermediate.rst b/source/Tutorials/Intermediate.rst deleted file mode 100644 index 2304c51c5ff..00000000000 --- a/source/Tutorials/Intermediate.rst +++ /dev/null @@ -1,22 +0,0 @@ -Intermediate -============ - -.. toctree:: - :maxdepth: 1 - - Intermediate/Rosdep - Intermediate/Creating-an-Action - Intermediate/Writing-an-Action-Server-Client/Cpp - Intermediate/Writing-an-Action-Server-Client/Py - Intermediate/Writing-An-Async-Node-With-Asyncio-Python - Intermediate/Writing-a-Composable-Node - Intermediate/Composition - Intermediate/Using-Node-Interfaces-Template-Class - Intermediate/Publishing-Messages-Using-YAML-Files - Intermediate/Monitoring-For-Parameter-Changes-CPP - Intermediate/Monitoring-For-Parameter-Changes-Python - Intermediate/Launch/Launch-Main - Intermediate/Tf2/Tf2-Main - Intermediate/Testing/Testing-Main - Intermediate/URDF/URDF-Main - Intermediate/RViz/RViz-Main diff --git a/source/Tutorials/Miscellaneous.rst b/source/Tutorials/Miscellaneous.rst deleted file mode 100644 index 750b2d13a2c..00000000000 --- a/source/Tutorials/Miscellaneous.rst +++ /dev/null @@ -1,10 +0,0 @@ -Miscellaneous -============= - -.. toctree:: - :maxdepth: 1 - - Miscellaneous/Deploying-ROS-2-on-IBM-Cloud - Miscellaneous/Eclipse-Oxygen-with-ROS-2-and-rviz2 - Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2 - Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06 diff --git a/source/index.rst b/source/index.rst index a9ccd1b1b1b..1af6d22b8d4 100644 --- a/source/index.rst +++ b/source/index.rst @@ -46,17 +46,17 @@ Getting started - Instructions to set up ROS 2 for the first time -* :doc:`Tutorials ` +* :doc:`First-Steps` - The best place to start for new users! - Hands-on sample projects that help you build a progression of necessary skills -* :doc:`How-To-Guides` +* :doc:`Developer-Tools` - Quick answers to your "How do I...?" - questions without working through the :doc:`Tutorials ` + questions without working through the tutorials -* :doc:`Concepts ` +* :doc:`Capabilities ` - High-level explanations of core ROS 2 concepts covered in the :doc:`Tutorials ` @@ -65,7 +65,7 @@ Getting started - Answers to your questions or a forum to start a discussion -The ROS 2 project +The ROS 2 Community ----------------- If you're interested in the advancement of the ROS 2 project: From ad9a34edefb78f880e7eafc80c9c807434f23058 Mon Sep 17 00:00:00 2001 From: dmarshant Date: Wed, 27 May 2026 12:14:29 +0100 Subject: [PATCH 12/20] Fixing broken cross references following restructuring --- source/Capabilities.rst | 3 +- source/Developer-Tools/About-Build.rst | 24 +- source/Developer-Tools/About-Debugging.rst | 2 +- .../Deployment-Guidelines.rst | 6 +- .../Build/Developing-a-ROS-2-Package.rst | 2 +- .../Build/Documenting-a-ROS-2-Package.rst | 496 +++++++++--------- .../Eclipse-Oxygen-with-ROS-2-and-rviz2.rst | 1 - .../images/eclipse-oxygen-01.png | Bin .../images/eclipse-oxygen-02.png | Bin .../images/eclipse-oxygen-03.png | Bin .../images/eclipse-oxygen-04.png | Bin .../images/eclipse-oxygen-05.png | Bin .../images/eclipse-oxygen-06.png | Bin .../images/eclipse-oxygen-07.png | Bin .../images/eclipse-oxygen-08.png | Bin .../images/eclipse-oxygen-09.png | Bin .../images/eclipse-oxygen-10.png | Bin .../images/eclipse-oxygen-11.png | Bin .../images/eclipse-oxygen-12.png | Bin .../images/eclipse-oxygen-13.png | Bin .../images/eclipse-oxygen-14.png | Bin .../images/eclipse-oxygen-15.png | Bin .../images/eclipse-oxygen-16.png | Bin .../images/eclipse-oxygen-17.png | Bin .../images/eclipse-oxygen-18.png | Bin .../images/eclipse-oxygen-19.png | Bin .../images/eclipse-oxygen-20.png | Bin .../images/eclipse-oxygen-21.png | Bin .../images/eclipse-oxygen-22.png | Bin .../images/eclipse-oxygen-23.png | Bin .../images/eclipse-oxygen-24.png | Bin .../images/eclipse-oxygen-25.png | Bin .../images/eclipse-oxygen-26.png | Bin .../images/eclipse-oxygen-27.png | Bin .../images/eclipse-oxygen-28.png | Bin .../images/eclipse-oxygen-29.png | Bin .../images/eclipse-oxygen-30.png | Bin .../images/eclipse-oxygen-31.png | Bin .../images/eclipse-oxygen-32.png | Bin .../images/eclipse-oxygen-33.png | Bin .../images/eclipse-oxygen-34.png | Bin .../images/eclipse-oxygen-35.png | Bin .../Build/Releasing/_Next-Steps.rst | 2 +- source/Developer-Tools/Build/The-Keystore.rst | 2 +- .../Using-Xacro-to-Clean-Up-a-URDF-File.rst | 0 .../launch/urdf_display_launch.py | 0 .../Debugging-Tf2-Problems.rst | 10 +- .../launch/start_tf2_debug_demo_launch.py | 0 .../launch/start_tf2_debug_demo_launch.xml | 0 .../launch/start_tf2_debug_demo_launch.yaml | 0 .../Debugging/Getting-Backtraces-in-ROS-2.rst | 2 +- .../Developer-Tools/Debugging/ROS-2-IDEs.rst | 2 +- .../Security/Security-on-Two.rst | 2 +- .../Launch/Launch-file-different-formats.rst | 2 +- source/Developer-Tools/Testing/Testing.rst | 4 +- source/Get-Started.rst | 7 +- .../Get-Started/{ => About-ROS}/About-ROS.rst | 2 +- .../About-ROS}/images/ROS-ecosystem.gif | Bin source/Get-Started/Installation.rst | 2 +- source/Get-Started/Releases.rst | 16 +- source/Integrations-and-related.rst | 2 +- .../MVSim/Getting-Started-MVSim.rst | 2 +- .../Migrating-Launch-Files.rst | 4 +- source/ROS-Framework.rst | 3 +- .../ROS-Framework/About-Client-Libraries.rst | 2 +- source/ROS-Framework/About-Nodes.rst | 2 +- .../actions/Working-with-actions.rst | 3 +- .../Action-Introspection.rst | 2 +- .../About-Executors/About-Executors.rst | 4 +- .../About-Internal-Interfaces.rst | 6 +- .../ROS Client Library API Stack.graffle | Bin .../images/ros_client_library_api_stack.png | Bin .../images/ros_idl_api_stack_dynamic.png | Bin .../images/ros_idl_api_stack_static.png | Bin .../Working-with-Client-Libraries.rst | 8 +- .../Configure-ZeroCopy-loaned-messages.rst | 2 +- .../Tf2/Tf2-Main.rst | 4 +- ...Writing-A-Simple-Py-Service-And-Client.rst | 2 +- .../interfaces/About-Tf2/About-Tf2.rst | 2 +- .../Interfaces-Topics-Services-Actions.rst | 2 +- .../interfaces/Working-with-interfaces.rst | 3 +- .../nodes/About-Logging/About-Logging.rst | 4 +- .../nodes/Working-with-nodes.rst | 3 +- .../parameters/Working-with-parameters.rst | 3 +- .../services/Working-with-services.rst | 3 +- .../topics/Working-with-topics.rst | 3 +- source/The-ROS2-Project/Contributing.rst | 232 ++++---- source/Tutorials/Beginner-CLI-Tools.rst | 16 - source/index.rst | 4 +- 89 files changed, 440 insertions(+), 468 deletions(-) rename source/Developer-Tools/Build/{ => Eclipse-Oxygen-with-ROS-2-and-rviz2}/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst (96%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-01.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-02.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-03.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-04.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-05.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-06.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-07.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-08.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-09.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-10.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-11.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-12.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-13.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-14.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-15.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-16.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-17.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-18.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-19.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-20.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-21.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-22.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-23.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-24.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-25.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-26.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-27.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-28.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-29.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-30.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-31.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-32.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-33.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-34.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2}/images/eclipse-oxygen-35.png (100%) rename source/Developer-Tools/Build/{ => Using-Xacro-to-Clean-Up-a-URDF-File}/Using-Xacro-to-Clean-Up-a-URDF-File.rst (100%) rename source/{Capabilities/Simulation/URDF => Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File}/launch/urdf_display_launch.py (100%) rename source/Developer-Tools/Debugging/{ => Debugging-Tf2-Problems}/Debugging-Tf2-Problems.rst (91%) rename source/{ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2 => Developer-Tools/Debugging/Debugging-Tf2-Problems}/launch/start_tf2_debug_demo_launch.py (100%) rename source/{ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2 => Developer-Tools/Debugging/Debugging-Tf2-Problems}/launch/start_tf2_debug_demo_launch.xml (100%) rename source/{ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2 => Developer-Tools/Debugging/Debugging-Tf2-Problems}/launch/start_tf2_debug_demo_launch.yaml (100%) rename source/Get-Started/{ => About-ROS}/About-ROS.rst (97%) rename source/{ => Get-Started/About-ROS}/images/ROS-ecosystem.gif (100%) rename source/ROS-Framework/client-libraries/{Working-with-Client-Libraries => }/About-Internal-Interfaces/About-Internal-Interfaces.rst (97%) rename source/ROS-Framework/client-libraries/{Working-with-Client-Libraries => }/About-Internal-Interfaces/images/ROS Client Library API Stack.graffle (100%) rename source/ROS-Framework/client-libraries/{Working-with-Client-Libraries => }/About-Internal-Interfaces/images/ros_client_library_api_stack.png (100%) rename source/ROS-Framework/client-libraries/{Working-with-Client-Libraries => }/About-Internal-Interfaces/images/ros_idl_api_stack_dynamic.png (100%) rename source/ROS-Framework/client-libraries/{Working-with-Client-Libraries => }/About-Internal-Interfaces/images/ros_idl_api_stack_static.png (100%) delete mode 100644 source/Tutorials/Beginner-CLI-Tools.rst diff --git a/source/Capabilities.rst b/source/Capabilities.rst index 1d6a2dc9013..7b6dd2f77ec 100644 --- a/source/Capabilities.rst +++ b/source/Capabilities.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Capabilities ============ diff --git a/source/Developer-Tools/About-Build.rst b/source/Developer-Tools/About-Build.rst index c28fd888122..fc3b195787a 100644 --- a/source/Developer-Tools/About-Build.rst +++ b/source/Developer-Tools/About-Build.rst @@ -10,26 +10,26 @@ PLACEHOLDER Build/About-Build-System Build/Deployment-Guidelines/Deployment-Guidelines Build/The-Keystore - Build/Using-Xacro-to-Clean-Up-a-URDF-File - Build/Supplementing-Custom-Rosdep-Keystore - Build-Ament-Lint-For-Clean-Code - Build-Eclipse-Oxygen-with-ROS-2-and-rviz2 + Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File + Build/Supplementing-Custom-Rosdep-Keys + Build/Ament-Lint-For-Clean-Code + Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2 Build/Ament-CMake-Documentation Build/Ament-CMake-Python-Documentation Build/Building-a-Custom-Deb-Package - Build/Cross-Compilation + Build/Cross-compilation Build/Run-2-nodes-in-single-or-separate-docker-containers Build/Setup-ROS-2-with-VSCode-and-Docker-Container - Build/Core-maintainer-Guide + Build/Core-maintainer-guide Build/DDS-tuning Build/Using-Variants Build/Package-Docs Build/Using-Python-Packages Build/Developing-a-ROS-2-Package Build/Documenting-a-ROS-2-Package - Build/Release/Index-Your-Packages - Build/Release/Release-Team-Repository - Build/Release/First-Time-Release - Build/Release/Releasing-a-Package - Build/Release/Release-Track - Build/Release/Subsequent-Releases \ No newline at end of file + Build/Releasing/Index-Your-Packages + Build/Releasing/Release-Team-Repository + Build/Releasing/First-Time-Release + Build/Releasing/Releasing-a-Package + Build/Releasing/Release-Track + Build/Releasing/Subsequent-Releases \ No newline at end of file diff --git a/source/Developer-Tools/About-Debugging.rst b/source/Developer-Tools/About-Debugging.rst index 1dd572a3a42..e2ccff6bbd1 100644 --- a/source/Developer-Tools/About-Debugging.rst +++ b/source/Developer-Tools/About-Debugging.rst @@ -6,7 +6,7 @@ PLACEHOLDER .. toctree:: :maxdepth: 3 - Debugging/Debugging-Tf2-Problems + Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems Debugging/ROS-2-IDEs Debugging/Getting-Backtraces-in-ROS-2 Debugging/Building-ROS-2-with-Tracing \ No newline at end of file diff --git a/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst b/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst index b71475c7405..5bc161486a2 100644 --- a/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst +++ b/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst @@ -37,9 +37,9 @@ Prerequisites * (Recommended) Previous security tutorials completion. In particular: - * :doc:`Introducing-ros2-security` - * :doc:`The-Keystore` - * :doc:`Access-Controls` + * :doc:`../../Introspection-and-analysis/Security/Introducing-ros2-security` + * :doc:`../The-Keystore` + * :doc:`../../Introspection-and-analysis/Security/Access-Controls` General Guidelines ------------------ diff --git a/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst b/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst index 82b195d4055..3a6090a3eaa 100644 --- a/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst +++ b/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst @@ -18,7 +18,7 @@ It is intended for developers who want to learn how to create custom packages in Prerequisites ------------- -- :doc:`Install ROS <../../Installation>` +- :doc:`Install ROS <../../Get-Started/Installation>` - `Install colcon `__ diff --git a/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst b/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst index d68dda360d2..0df8c85d055 100644 --- a/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst +++ b/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst @@ -1,249 +1,249 @@ -.. redirect-from:: - - How-To-Guides/Documenting-a-ROS-2-Package - -Documenting a ROS 2 package -########################### - -.. contents:: Table of Contents - :depth: 2 - :local: - - -This guide introduces the standard way to create documentation for ROS 2 packages. -For packages with binary releases this also results in the docs being hosted at ``docs.ros.org/en//p//``. -For information on how to contribute to this documentation on docs.ros.org, see :doc:`Contributing to ROS 2 Documentation <../../The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation>`. - -Prerequisites -------------- - -- :doc:`Install ROS <../../Installation>` - -- `Install rosdoc2 `__ - -Package Documentation Overview ------------------------------- - -The type of documentation discussed in this guide is referred to as "package docs" or "API docs". -For ROS packages that have been released on ROS Index, their documentation will be built on the ROS buildfarm, included on docs.ros.org, and visible via the ``API Docs`` button on index.ros.org. - -The tool responsible for generating ROS 2 package docs is `rosdoc2 `__. - -``rosdoc2`` is a convenient wrapper around the commonly used `Sphinx `__ documentation framework. -Sphinx allows freeform written documentation as well as API documentation for python code generated from comments in the code. -The `breathe `__ + `exhale `__ packages allow integration with Doxygen, to include autogenerated C++ API documentation as well. - -``rosdoc2`` creates a default configuration for packages with no documentation or configuration at all, and applies options for a uniform theme and integration with other packages. - -Building Package Docs ---------------------- - -To generate the documentation for a package in HTML format with ``rosdoc2``, run: - -.. code-block:: console - - $ rosdoc2 build --package-path - -The documentation is written to ``docs_output//index.html`` and can be viewed in a browser. - -Configuration -------------- - -There are three configuration locations for ROS package docs: ``rosdoc2.yaml`` for general settings, -``conf.py`` for sphinx settings and the ``Doxyfile`` for doxygen settings. -For all of those, a default is assumed or generated if not present, so none of them is strictly required. -However, it might be necessary to create and modify those once you want to use features such as custom textual documentation pages. - -rosdoc2.yaml -^^^^^^^^^^^^ - -This is the main entrypoint for rosdoc2. -It specifies generic settings, and can be used to control the execution of specific builders (Doxygen and Sphinx) and decides which builders to run. - -``rosdoc2`` provides a multitude of configuration options, which can be adjusted in a config file ``rosdoc2.yaml``. -To generate a default ``rosdoc2.yaml`` which you can then further customize, run: - -.. code-block:: console - - $ rosdoc2 default_config --package-path - -And add ``rosdoc2.yaml`` to the export section in your ``package.xml``: - -.. code-block:: xml - - - - - - rosdoc2.yaml - - - -However, for most packages, the default settings in ``rosdoc2`` will suffice, and no custom config is necessary. -More information about ``rosdoc2.yaml`` can be found in the `rosdoc2 readme `__. - -conf.py, rosdoc2_settings -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The final output of the package docs is (almost) always built by Sphinx. -Each Sphinx project is configured by a ``conf.py`` file in the ``doc`` directory. -If no configuration is present, a default Sphinx project is created and used when building the documentation. -If however a ``conf.py`` Sphinx config is found in the ``doc`` subdirectory of the package, this is used instead. -A custom Sphinx project is required if you want to include a standalone reStructuredText documentation page. -A standalone documentation page can be used to list multiple tutorials and guides; if that's something you want for your package you'll need to create a custom Sphinx project. - -``rosdoc2`` provides additional settings to ``conf.py`` and overrides some. -Information about changes done to the Sphinx settings are logged to the console with a ``[rosdoc2]`` prefix. - -Doxyfile -^^^^^^^^ - -Doxygen is a tool for automatically generating C++ API docs from code comments. -While Doxygen can also generate HTML output directly, in the usual workflow for ROS packages, Doxygen produces machine readable output in XML format which is then consumed by Sphinx and integrated with the rest of the documentation. -Doxygen-only docs are possible by only enabling the Doxygen builder in ``rosdoc2.yaml``, but this is uncommon. - -Customizing Sphinx Documentation --------------------------------- - -Creating a Sphinx Project -^^^^^^^^^^^^^^^^^^^^^^^^^ - -In order to add standalone documentation pages in addition to the automatically generated API docs, a custom Sphinx project is necessary. -This should be created in a subdirectory called ``doc`` in the package directory. -A new Sphinx project can be created by running ``sphinx-quickstart`` in the ``doc`` directory, answering ``no`` to "Separate source and build directories". -The wizard requires entering the project name, author and version, but this can later be removed and will be provided to Sphinx by ``rosdoc2`` from your packages ``package.xml``. -More information about creating a sphinx project can be found on the `Sphinx quickstart page `__, - -Customizing ``index.rst`` -^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ``sphinx-quickstart`` wizard creates an ``index.rst`` file, which is the custom landing page for your package, similar to a Github ``README`` file. - -Adding Python API-Docs -^^^^^^^^^^^^^^^^^^^^^^ - -By default ``rosdoc2`` uses the `sphinx-apidoc tool `__ and the `autodoc Sphinx extension `__ to automatically generate documentation for python code. -In order for autodoc to find the Python modules in your package, it must be added to the python search path in ``conf.py``: - -.. code-block:: python - - sys.path.insert(0, os.path.abspath('.')) - -This is because ``rosdoc2`` wraps the custom ``conf.py`` with more configuration from a script which will be placed in the package. -In this case the ``.`` path in ``os.path.abspath`` refers to the package's directory root, not the package's ``doc`` directory due to the interaction between rosdoc2 and ``conf.py``. - -By default, package API docs are already reachable through the "Module Index" link that is present on the landing page. -For the API docs to also appear in the table of contents, simply add a link to the ``modules`` page to your ``index.rst``: - -.. code-block:: rst - - .. toctree:: - :maxdepth: 2 - :caption: Contents: - - Python Modules - -Adding C++ API-Docs -^^^^^^^^^^^^^^^^^^^ - -If you would like to add your automatically generated API docs back to your custom landing page, add the line ``generated/index`` to your documentation page where you would like the API docs to appear: - -.. code-block:: rst - - .. toctree:: - :maxdepth: 2 - - C++ API Docs - -This adds the elements "Class Hierarchy", "File Hierarchy" and "Reference" to the table of contents in the sidebar. -To make those appear under one "C++ API Docs" heading for a less cluttered sidebar, a separate file such as ``cpp_api_docs.rst`` can be added, which links to the generated docs: - -.. code-block:: rst - :caption: cpp_api_docs.rst - - C++ API Docs -================ - - These are the autogenerated docs for the internal implementation. - - .. toctree:: - :maxdepth: 3 - :caption: Contents: - - generated/index - -Which then also needs to be added in ``index.rst`` to appear in the sidebar: - -.. code-block:: rst - :caption: index.rst - - .. toctree:: - :maxdepth: 2 - :caption: Contents: - - cpp_api_docs - - -Including an existing README.md -------------------------------- - -If your git repository already has an existing ``README.md``, it is possible to reuse this as the landing page for the documentation, without duplicating the contents. -To correctly include a Markdown file in Sphinx while preserving relative links and images, some additional effort is required. - -First, create a proxy-file ``readme_include.md`` next to ``index.rst``. -This is a markdown file which just includes the original README.md, but preserves the relative image paths, which would otherwise break in the next step: - -.. code-block:: markdown - :caption: readme_include.md - - ```{include} ../README.md - :relative-images: - ``` - - -Then, include the contents of this file from ``index.rst`` using ``myst`` to include markdown from rst: - -.. code-block:: rst - :caption: index.rst - - .. include:: readme_include.md - :parser: myst_parser.sphinx_ - - -This also requires adding ``myst_parser`` to the extensions in ``conf.py``: - -.. code-block:: python - :caption: conf.py - - extensions = ["myst_parser"] - - -CI, docs.ros.org ----------------- - -The ROS build farm uses ``rosdoc2`` to build the package documentation hosted at ``docs.ros.org/en//p//``. -To enable this, the repository containing the documentation must be configured in `rosdistro/{DISTRO}/distribution.yaml `__. -This would usually be the package source repository: - -.. code-block:: yaml - - : - doc: - type: git - url: https://github.com//.git - version: main - release: - [...] - -The buildfarm hosts the documentation for every distribution separately, and periodically rebuilds it from the latest commit on the specified branch. -It is not required to tag a new release to update the hosted documentation. -To view the status of your package's documentation build, search for ``doc__`` on ``__. -One job is created for every distribution for which the package is released. -On each job page, you can see when a build was last triggered, as well as the status and logs of each build. - -Further Reading ---------------- - -* `rosdoc2 readme `_ -* `ROS 2 design document on package documentation `_ +.. redirect-from:: + + How-To-Guides/Documenting-a-ROS-2-Package + +Documenting a ROS 2 package +########################### + +.. contents:: Table of Contents + :depth: 2 + :local: + + +This guide introduces the standard way to create documentation for ROS 2 packages. +For packages with binary releases this also results in the docs being hosted at ``docs.ros.org/en//p//``. +For information on how to contribute to this documentation on docs.ros.org, see :doc:`Contributing to ROS 2 Documentation <../../The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation>`. + +Prerequisites +------------- + +- :doc:`Install ROS <../../Get-Started/Installation>` + +- `Install rosdoc2 `__ + +Package Documentation Overview +------------------------------ + +The type of documentation discussed in this guide is referred to as "package docs" or "API docs". +For ROS packages that have been released on ROS Index, their documentation will be built on the ROS buildfarm, included on docs.ros.org, and visible via the ``API Docs`` button on index.ros.org. + +The tool responsible for generating ROS 2 package docs is `rosdoc2 `__. + +``rosdoc2`` is a convenient wrapper around the commonly used `Sphinx `__ documentation framework. +Sphinx allows freeform written documentation as well as API documentation for python code generated from comments in the code. +The `breathe `__ + `exhale `__ packages allow integration with Doxygen, to include autogenerated C++ API documentation as well. + +``rosdoc2`` creates a default configuration for packages with no documentation or configuration at all, and applies options for a uniform theme and integration with other packages. + +Building Package Docs +--------------------- + +To generate the documentation for a package in HTML format with ``rosdoc2``, run: + +.. code-block:: console + + $ rosdoc2 build --package-path + +The documentation is written to ``docs_output//index.html`` and can be viewed in a browser. + +Configuration +------------- + +There are three configuration locations for ROS package docs: ``rosdoc2.yaml`` for general settings, +``conf.py`` for sphinx settings and the ``Doxyfile`` for doxygen settings. +For all of those, a default is assumed or generated if not present, so none of them is strictly required. +However, it might be necessary to create and modify those once you want to use features such as custom textual documentation pages. + +rosdoc2.yaml +^^^^^^^^^^^^ + +This is the main entrypoint for rosdoc2. +It specifies generic settings, and can be used to control the execution of specific builders (Doxygen and Sphinx) and decides which builders to run. + +``rosdoc2`` provides a multitude of configuration options, which can be adjusted in a config file ``rosdoc2.yaml``. +To generate a default ``rosdoc2.yaml`` which you can then further customize, run: + +.. code-block:: console + + $ rosdoc2 default_config --package-path + +And add ``rosdoc2.yaml`` to the export section in your ``package.xml``: + +.. code-block:: xml + + + + + + rosdoc2.yaml + + + +However, for most packages, the default settings in ``rosdoc2`` will suffice, and no custom config is necessary. +More information about ``rosdoc2.yaml`` can be found in the `rosdoc2 readme `__. + +conf.py, rosdoc2_settings +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The final output of the package docs is (almost) always built by Sphinx. +Each Sphinx project is configured by a ``conf.py`` file in the ``doc`` directory. +If no configuration is present, a default Sphinx project is created and used when building the documentation. +If however a ``conf.py`` Sphinx config is found in the ``doc`` subdirectory of the package, this is used instead. +A custom Sphinx project is required if you want to include a standalone reStructuredText documentation page. +A standalone documentation page can be used to list multiple tutorials and guides; if that's something you want for your package you'll need to create a custom Sphinx project. + +``rosdoc2`` provides additional settings to ``conf.py`` and overrides some. +Information about changes done to the Sphinx settings are logged to the console with a ``[rosdoc2]`` prefix. + +Doxyfile +^^^^^^^^ + +Doxygen is a tool for automatically generating C++ API docs from code comments. +While Doxygen can also generate HTML output directly, in the usual workflow for ROS packages, Doxygen produces machine readable output in XML format which is then consumed by Sphinx and integrated with the rest of the documentation. +Doxygen-only docs are possible by only enabling the Doxygen builder in ``rosdoc2.yaml``, but this is uncommon. + +Customizing Sphinx Documentation +-------------------------------- + +Creating a Sphinx Project +^^^^^^^^^^^^^^^^^^^^^^^^^ + +In order to add standalone documentation pages in addition to the automatically generated API docs, a custom Sphinx project is necessary. +This should be created in a subdirectory called ``doc`` in the package directory. +A new Sphinx project can be created by running ``sphinx-quickstart`` in the ``doc`` directory, answering ``no`` to "Separate source and build directories". +The wizard requires entering the project name, author and version, but this can later be removed and will be provided to Sphinx by ``rosdoc2`` from your packages ``package.xml``. +More information about creating a sphinx project can be found on the `Sphinx quickstart page `__, + +Customizing ``index.rst`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ``sphinx-quickstart`` wizard creates an ``index.rst`` file, which is the custom landing page for your package, similar to a Github ``README`` file. + +Adding Python API-Docs +^^^^^^^^^^^^^^^^^^^^^^ + +By default ``rosdoc2`` uses the `sphinx-apidoc tool `__ and the `autodoc Sphinx extension `__ to automatically generate documentation for python code. +In order for autodoc to find the Python modules in your package, it must be added to the python search path in ``conf.py``: + +.. code-block:: python + + sys.path.insert(0, os.path.abspath('.')) + +This is because ``rosdoc2`` wraps the custom ``conf.py`` with more configuration from a script which will be placed in the package. +In this case the ``.`` path in ``os.path.abspath`` refers to the package's directory root, not the package's ``doc`` directory due to the interaction between rosdoc2 and ``conf.py``. + +By default, package API docs are already reachable through the "Module Index" link that is present on the landing page. +For the API docs to also appear in the table of contents, simply add a link to the ``modules`` page to your ``index.rst``: + +.. code-block:: rst + + .. toctree:: + :maxdepth: 2 + :caption: Contents: + + Python Modules + +Adding C++ API-Docs +^^^^^^^^^^^^^^^^^^^ + +If you would like to add your automatically generated API docs back to your custom landing page, add the line ``generated/index`` to your documentation page where you would like the API docs to appear: + +.. code-block:: rst + + .. toctree:: + :maxdepth: 2 + + C++ API Docs + +This adds the elements "Class Hierarchy", "File Hierarchy" and "Reference" to the table of contents in the sidebar. +To make those appear under one "C++ API Docs" heading for a less cluttered sidebar, a separate file such as ``cpp_api_docs.rst`` can be added, which links to the generated docs: + +.. code-block:: rst + :caption: cpp_api_docs.rst + + C++ API Docs + ============ + + These are the autogenerated docs for the internal implementation. + + .. toctree:: + :maxdepth: 3 + :caption: Contents: + + generated/index + +Which then also needs to be added in ``index.rst`` to appear in the sidebar: + +.. code-block:: rst + :caption: index.rst + + .. toctree:: + :maxdepth: 2 + :caption: Contents: + + cpp_api_docs + + +Including an existing README.md +------------------------------- + +If your git repository already has an existing ``README.md``, it is possible to reuse this as the landing page for the documentation, without duplicating the contents. +To correctly include a Markdown file in Sphinx while preserving relative links and images, some additional effort is required. + +First, create a proxy-file ``readme_include.md`` next to ``index.rst``. +This is a markdown file which just includes the original README.md, but preserves the relative image paths, which would otherwise break in the next step: + +.. code-block:: markdown + :caption: readme_include.md + + ```{include} ../README.md + :relative-images: + ``` + + +Then, include the contents of this file from ``index.rst`` using ``myst`` to include markdown from rst: + +.. code-block:: rst + :caption: index.rst + + .. include:: readme_include.md + :parser: myst_parser.sphinx_ + + +This also requires adding ``myst_parser`` to the extensions in ``conf.py``: + +.. code-block:: python + :caption: conf.py + + extensions = ["myst_parser"] + + +CI, docs.ros.org +---------------- + +The ROS build farm uses ``rosdoc2`` to build the package documentation hosted at ``docs.ros.org/en//p//``. +To enable this, the repository containing the documentation must be configured in `rosdistro/{DISTRO}/distribution.yaml `__. +This would usually be the package source repository: + +.. code-block:: yaml + + : + doc: + type: git + url: https://github.com//.git + version: main + release: + [...] + +The buildfarm hosts the documentation for every distribution separately, and periodically rebuilds it from the latest commit on the specified branch. +It is not required to tag a new release to update the hosted documentation. +To view the status of your package's documentation build, search for ``doc__`` on ``__. +One job is created for every distribution for which the package is released. +On each job page, you can see when a build was last triggered, as well as the status and logs of each build. + +Further Reading +--------------- + +* `rosdoc2 readme `_ +* `ROS 2 design document on package documentation `_ * `The ROS 2 cookbook `_ \ No newline at end of file diff --git a/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst similarity index 96% rename from source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst index a8d99c940bd..4f931b92747 100644 --- a/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst +++ b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst @@ -22,7 +22,6 @@ HINT: We use nested projects and one Eclipse Workspace for each ROS-2 package. .. image:: images/eclipse-oxygen-01.png - Create a C++ Project. .. image:: images/eclipse-oxygen-02.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-01.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-01.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-01.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-01.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-02.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-02.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-02.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-02.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-03.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-03.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-03.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-03.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-04.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-04.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-04.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-04.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-05.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-05.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-05.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-05.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-06.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-06.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-06.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-06.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-07.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-07.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-07.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-07.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-08.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-08.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-08.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-08.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-09.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-09.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-09.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-09.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-10.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-10.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-10.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-10.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-11.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-11.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-11.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-11.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-12.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-12.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-12.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-12.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-13.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-13.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-13.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-13.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-14.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-14.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-14.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-14.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-15.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-15.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-15.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-15.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-16.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-16.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-16.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-16.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-17.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-17.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-17.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-17.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-18.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-18.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-18.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-18.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-19.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-19.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-19.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-19.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-20.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-20.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-20.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-20.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-21.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-21.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-21.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-21.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-22.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-22.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-22.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-22.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-23.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-23.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-23.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-23.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-24.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-24.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-24.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-24.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-25.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-25.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-25.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-25.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-26.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-26.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-26.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-26.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-27.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-27.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-27.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-27.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-28.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-28.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-28.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-28.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-29.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-29.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-29.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-29.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-30.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-30.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-30.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-30.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-31.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-31.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-31.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-31.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-32.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-32.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-32.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-32.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-33.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-33.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-33.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-33.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-34.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-34.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-34.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-34.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse-oxygen-35.png b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-35.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse-oxygen-35.png rename to source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/images/eclipse-oxygen-35.png diff --git a/source/Developer-Tools/Build/Releasing/_Next-Steps.rst b/source/Developer-Tools/Build/Releasing/_Next-Steps.rst index 33c1071cef0..054e1a83a5e 100644 --- a/source/Developer-Tools/Build/Releasing/_Next-Steps.rst +++ b/source/Developer-Tools/Build/Releasing/_Next-Steps.rst @@ -3,7 +3,7 @@ How-To-Guides/Releasing/_Next-Steps Once your pull request has been submitted, usually within one or two days, one of the maintainers of rosdistro will review and merge your Pull Request. -If your package build is successful, in 24-48 hours your packages will become available in the **ros-testing** repository, where you can :doc:`test your pre-release binaries <../../../Installation/Testing>`. +If your package build is successful, in 24-48 hours your packages will become available in the **ros-testing** repository, where you can :doc:`test your pre-release binaries <../../Testing/Testing>`. Approximately every two to four weeks, the distribution's release manager manually synchronizes the contents of ros-testing into the main ROS repository. This is when your packages actually become available to the rest of the ROS community. diff --git a/source/Developer-Tools/Build/The-Keystore.rst b/source/Developer-Tools/Build/The-Keystore.rst index 480c3e269f6..b257bf38779 100644 --- a/source/Developer-Tools/Build/The-Keystore.rst +++ b/source/Developer-Tools/Build/The-Keystore.rst @@ -22,7 +22,7 @@ Understanding the security keystore Background ---------- -Before proceeding ensure you have completed the :doc:`Introducing-ros2-security` tutorial. +Before proceeding ensure you have completed the :doc:`../Introspection-and-analysis/Security/Introducing-ros2-security` tutorial. The ``sros2`` package can be used to create keys, certificates and policies necessary to enable ROS 2 security. However, the security configuration is extremely flexible. diff --git a/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File.rst b/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File.rst similarity index 100% rename from source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File.rst rename to source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File.rst diff --git a/source/Capabilities/Simulation/URDF/launch/urdf_display_launch.py b/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/launch/urdf_display_launch.py similarity index 100% rename from source/Capabilities/Simulation/URDF/launch/urdf_display_launch.py rename to source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/launch/urdf_display_launch.py diff --git a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst similarity index 91% rename from source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst rename to source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst index 0905580285f..b9ec87e8b46 100644 --- a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems.rst +++ b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst @@ -23,7 +23,7 @@ Background This tutorial walks you through the steps to debug a typical tf2 problem. It will also use many of the tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames``. -This tutorial assumes you have completed the :doc:`learning tf2 <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` tutorials. +This tutorial assumes you have completed the :doc:`learning tf2 <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` tutorials. Debugging example ----------------- @@ -35,7 +35,7 @@ For this tutorial we will set up a demo application that has a number of problem The goal of this tutorial is to apply a systematic approach to find and tackle these problems. First, let's create the source file. -Go to the ``learning_tf2_cpp`` package we created in :doc:`tf2 tutorials <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>`. +Go to the ``learning_tf2_cpp`` package we created in :doc:`tf2 tutorials <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>`. Inside the ``src`` directory make a copy of the source file ``turtle_tf2_listener.cpp`` and rename it to ``turtle_tf2_listener_debug.cpp``. Open the file using your preferred text editor, and change line 65 from @@ -177,7 +177,7 @@ If you like to get a graphical representation of this, use ``view_frames`` tool. Open the generated ``frames.pdf`` file to see the following output: -.. image:: images/turtlesim_frames.png +.. image:: ../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_frames.png So obviously the problem is that we are requesting transform from frame ``turtle3``, which does not exist. To fix this bug, just replace ``turtle3`` with ``turtle2`` in line 65. @@ -278,7 +278,7 @@ Stop the demo, build and run: And you should finally see the turtle move! -.. image:: images/turtlesim_follow1.png +.. image:: ../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_follow1.png That last fix we made is not really what you want to do, it was just to make sure that was our problem. The real fix would look like this: @@ -301,7 +301,7 @@ Or like this: tf2::TimePoint()); } catch (const tf2::TransformException & ex) { -You can learn more about timeouts in the :doc:`Using time <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp>` tutorial, and use them as below: +You can learn more about timeouts in the :doc:`Using time <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp>` tutorial, and use them as below: .. code-block:: C++ diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/launch/start_tf2_debug_demo_launch.py b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/launch/start_tf2_debug_demo_launch.py similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/launch/start_tf2_debug_demo_launch.py rename to source/Developer-Tools/Debugging/Debugging-Tf2-Problems/launch/start_tf2_debug_demo_launch.py diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/launch/start_tf2_debug_demo_launch.xml b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/launch/start_tf2_debug_demo_launch.xml similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/launch/start_tf2_debug_demo_launch.xml rename to source/Developer-Tools/Debugging/Debugging-Tf2-Problems/launch/start_tf2_debug_demo_launch.xml diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/launch/start_tf2_debug_demo_launch.yaml b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/launch/start_tf2_debug_demo_launch.yaml similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/launch/start_tf2_debug_demo_launch.yaml rename to source/Developer-Tools/Debugging/Debugging-Tf2-Problems/launch/start_tf2_debug_demo_launch.yaml diff --git a/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst b/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst index adfe1a01a96..5ebd708aee3 100644 --- a/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst +++ b/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst @@ -308,7 +308,7 @@ Alternatively, if your node of interest is being launched in these files directl In this case you may need to remap or provide parameter files to this node if it was previously provided by the launch file. Using ``--ros-args`` you can give it the path to the new parameters file, remaps, or names. - See :doc:`this tutorial <../../How-To-Guides/Node-arguments>` for the commandline arguments required. + See :doc:`this tutorial <../Introspection-and-analysis/Node-arguments>` for the commandline arguments required. We understand this can be a pain, so it might encourage you to rather have each node possible as a separately included launch file to make debugging easier. An example set of arguments might be ``--ros-args -r __node:= --params-file /absolute/path/to/params.yaml`` (as a template). diff --git a/source/Developer-Tools/Debugging/ROS-2-IDEs.rst b/source/Developer-Tools/Debugging/ROS-2-IDEs.rst index d25c6b9f171..5c1f257622c 100644 --- a/source/Developer-Tools/Debugging/ROS-2-IDEs.rst +++ b/source/Developer-Tools/Debugging/ROS-2-IDEs.rst @@ -136,7 +136,7 @@ An example of ``launch.json`` could be: Instead you could also create a configuration for attaching to a running process, under "Attach using Process Id". -See :doc:`Setup ROS 2 with VSCode and Docker` for full instructions on how to use VSCode, in combination with Docker. +See :doc:`Setup ROS 2 with VSCode and Docker <../Build/Setup-ROS-2-with-VSCode-and-Docker-Container>` for full instructions on how to use VSCode, in combination with Docker. PyCharm diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst index 392e1cc2a00..59877e76d28 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst @@ -95,7 +95,7 @@ Since the keys are just text files, we can use ``scp`` to copy them. .. warning:: Note that in this case the entire keystore is shared across the different machines which may not be the desired behavior, as it may result in a security risk. - Please refer to :doc:`Deployment-Guidelines` for more information in this regard. + Please refer to :doc:`../../Build/Deployment-Guidelines/Deployment-Guidelines` for more information in this regard. That will be very quick, since it's just copying some very small text files. Now, we're ready to run a multi-machine talker/listener demo! diff --git a/source/Developer-Tools/Launch/Launch-file-different-formats.rst b/source/Developer-Tools/Launch/Launch-file-different-formats.rst index 38389aac21d..a34713c7e76 100644 --- a/source/Developer-Tools/Launch/Launch-file-different-formats.rst +++ b/source/Developer-Tools/Launch/Launch-file-different-formats.rst @@ -97,7 +97,7 @@ XML, YAML, or Python: Which should I use? .. note:: Launch files in ROS 1 were written in XML, so XML may be the most familiar to people coming from ROS 1. - To see what's changed, you can visit :doc:`Migrating-from-ROS1/Migrating-Launch-Files`. + To see what's changed, you can visit :doc:`../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files`. For most applications the choice of which ROS 2 launch format comes down to developer preference. However, if your launch file requires flexibility that you cannot achieve with XML or YAML, you can use Python to write your launch file. diff --git a/source/Developer-Tools/Testing/Testing.rst b/source/Developer-Tools/Testing/Testing.rst index 96a710c58a7..6b0dfab848e 100644 --- a/source/Developer-Tools/Testing/Testing.rst +++ b/source/Developer-Tools/Testing/Testing.rst @@ -68,7 +68,7 @@ RHEL testing repository For RHEL you can install binary packages from the **ros-testing** repository, by enabling the testing repository on the source configuration: -1. Make sure you have a working ROS 2 installation for rpm packages (see the :doc:`RHEL installation instructions `). +1. Make sure you have a working ROS 2 installation for rpm packages (see the :doc:`RHEL installation instructions <../../Get-Started/Installation/RHEL-Install-RPMs>`). 2. Enable testing and disable main repository: @@ -111,7 +111,7 @@ Binary archives For core packages, we run nightly packaging jobs for Ubuntu Linux, RHEL, and Windows. These packaging jobs produce archives with pre-built binaries that can be downloaded and extracted to your filesystem. -1. Make sure you have all dependencies installed according to the :doc:`latest development setup ` for your platform. +1. Make sure you have all dependencies installed according to the :doc:`latest development setup <../../Get-Started/Installation/Alternatives/Latest-Development-Setup>` for your platform. 2. Go to https://ci.ros2.org/view/packaging/ and select a packaging job from the list corresponding to your platform. diff --git a/source/Get-Started.rst b/source/Get-Started.rst index 4f12e86c94a..a69fd219865 100644 --- a/source/Get-Started.rst +++ b/source/Get-Started.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Get started =========== @@ -9,9 +8,9 @@ PLACEHOLDER .. toctree:: :maxdepth: 3 - Get-Started/About-ROS + Get-Started/About-ROS/About-ROS Get-Started/Installation Get-Started/Releases - Get-Started/First-Steps + First-Steps Get-Started/Configuring-ROS2-Environment Get-Started/Introducing-Turtlesim/Introducing-Turtlesim \ No newline at end of file diff --git a/source/Get-Started/About-ROS.rst b/source/Get-Started/About-ROS/About-ROS.rst similarity index 97% rename from source/Get-Started/About-ROS.rst rename to source/Get-Started/About-ROS/About-ROS.rst index c84ac3674c7..564c2102716 100644 --- a/source/Get-Started/About-ROS.rst +++ b/source/Get-Started/About-ROS/About-ROS.rst @@ -141,4 +141,4 @@ ROS on macOS is supported by the community, and we do not recommended it for new Ubuntu support depends on the ROS distribution, with each distribution requiring a specific Ubuntu LTS (long-term support) release. Other platforms may require building from source or using containers. -:doc:`See full details of currently supported platforms and support tiers ` \ No newline at end of file +:doc:`See full details of currently supported platforms and support tiers <../Releases/Release-Rolling-Ridley>` \ No newline at end of file diff --git a/source/images/ROS-ecosystem.gif b/source/Get-Started/About-ROS/images/ROS-ecosystem.gif similarity index 100% rename from source/images/ROS-ecosystem.gif rename to source/Get-Started/About-ROS/images/ROS-ecosystem.gif diff --git a/source/Get-Started/Installation.rst b/source/Get-Started/Installation.rst index 5d1ccd8415b..8a7af2edc9d 100644 --- a/source/Get-Started/Installation.rst +++ b/source/Get-Started/Installation.rst @@ -19,7 +19,7 @@ Options for installing ROS 2 {DISTRO_TITLE_FULL}: Installation/Alternatives Installation/RMW-Implementations Installation/ROS-2-Mirrors - Installation/Installation-on-Raspberry-Pi + Installation/Installing-on-Raspberry-Pi Installation/Installation-Troubleshooting .. _binary-package-platforms: diff --git a/source/Get-Started/Releases.rst b/source/Get-Started/Releases.rst index 119b27ad4f0..66491011951 100644 --- a/source/Get-Started/Releases.rst +++ b/source/Get-Started/Releases.rst @@ -27,13 +27,13 @@ Rows in the table marked in blue are the currently supported distributions. .. toctree:: :hidden: - Get-Started/Releases/Release-Process - Get-Started/Releases/Release-Kilted-Kaiju - Get-Started/Releases/Release-Jazzy-Jalisco - Get-Started/Releases/Release-Humble-Hawksbill - Get-Started/Releases/Release-Rolling-Ridley - Get-Started/Releases/Development - Get-Started/Releases/End-of-Life + Releases/Release-Process + Releases/Release-Kilted-Kaiju + Releases/Release-Jazzy-Jalisco + Releases/Release-Humble-Hawksbill + Releases/Release-Rolling-Ridley + Releases/Development + Releases/End-of-Life .. raw:: html @@ -228,7 +228,7 @@ As the name implies, Rolling is continuously updated and **can have in-place upd We recommend that most people use the most recent stable distribution instead (see :ref:`list_of_distributions`). Packages released into the Rolling distribution will be automatically released into future stable distributions of ROS 2. -:doc:`Releasing a ROS 2 package <../How-To-Guides/Releasing/Releasing-a-Package>` into the Rolling distribution follows the same procedures as all other ROS 2 distributions. +:doc:`Releasing a ROS 2 package <../Developer-Tools/Build/Releasing/Releasing-a-Package>` into the Rolling distribution follows the same procedures as all other ROS 2 distributions. Cross-Distribution Communications --------------------------------- diff --git a/source/Integrations-and-related.rst b/source/Integrations-and-related.rst index 93c7dc4d3cd..332a61fb262 100644 --- a/source/Integrations-and-related.rst +++ b/source/Integrations-and-related.rst @@ -9,5 +9,5 @@ PLACEHOLDER :glob: Integrations-and-related/Simulators/Simulation-Main - Integrations-and-related/Deploying-ROS-2-on-IMB-Cloud + Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud Integrations-and-related/Related-Projects diff --git a/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst index d34f237f423..419f91b3ba7 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst @@ -29,7 +29,7 @@ or as a ROS 2 node that publishes sensor data and accepts velocity commands thro Prerequisites ------------- -You should have MVSim installed following the :doc:`Installation-Ubuntu` tutorial. +You should have MVSim installed following the :doc:`../Webots/Installation-Ubuntu` tutorial. Tasks ----- diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst index d5baa0bcd9f..a819996a99b 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst @@ -23,7 +23,7 @@ This guide describes how to write ROS 2 XML launch files for an easy migration f Background ---------- -A description of the ROS 2 launch system can be found in :doc:`Launch System tutorial <../../../Tutorials/Intermediate/Launch/Launch-system>`. +A description of the ROS 2 launch system can be found in :doc:`Launch System tutorial <../../Developer-Tools/Launch/Launch-system>`. Migrating tags @@ -244,7 +244,7 @@ Assuming the above launch configuration is in a file named ``mylaunch.xml``, a d $ ros2 launch mylaunch.xml topic_name:=custom_topic_name -There is some additional information about passing command-line arguments in :doc:`Using Substitutions <../../../Tutorials/Intermediate/Launch/Using-Substitutions>`. +There is some additional information about passing command-line arguments in :doc:`Using Substitutions <../../Developer-Tools/Launch/Using-Substitutions>`. env ^^^ diff --git a/source/ROS-Framework.rst b/source/ROS-Framework.rst index 4e5a0b3ba20..ff77d5a0a6a 100644 --- a/source/ROS-Framework.rst +++ b/source/ROS-Framework.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + ROS framework ============= diff --git a/source/ROS-Framework/About-Client-Libraries.rst b/source/ROS-Framework/About-Client-Libraries.rst index bddbd764dee..c3e5bed4050 100644 --- a/source/ROS-Framework/About-Client-Libraries.rst +++ b/source/ROS-Framework/About-Client-Libraries.rst @@ -15,7 +15,7 @@ Client libraries client-libraries/About-Different-Middleware-Vendors client-libraries/About-Executors/About-Executors - client-libraries/About-Client-Interfaces + client-libraries/About-Internal-Interfaces/About-Internal-Interfaces client-libraries/About-Middleware-Implementations client-libraries/Working-with-Client-Libraries diff --git a/source/ROS-Framework/About-Nodes.rst b/source/ROS-Framework/About-Nodes.rst index 35dd3f47c09..117b84ba1a7 100644 --- a/source/ROS-Framework/About-Nodes.rst +++ b/source/ROS-Framework/About-Nodes.rst @@ -29,4 +29,4 @@ Nodes can provide configurable :doc:`parameters ` to change be Nodes are often a complex combination of publishers, subscribers, service servers, service clients, action servers, and action clients, all at the same time. -Connections between nodes are established through a distributed :doc:`discovery ` process. +Connections between nodes are established through a distributed :doc:`discovery ` process. diff --git a/source/ROS-Framework/actions/Working-with-actions.rst b/source/ROS-Framework/actions/Working-with-actions.rst index 0d7fa486e43..788ae57978b 100644 --- a/source/ROS-Framework/actions/Working-with-actions.rst +++ b/source/ROS-Framework/actions/Working-with-actions.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Working with actions ==================== diff --git a/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst b/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst index 03a5d03b5f6..ce7f33300f4 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst +++ b/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst @@ -21,7 +21,7 @@ Overview ROS 2 applications usually consist of actions to execute specific long-running procedures or work in remote nodes. It is possible to introspect action data communication with action introspection. -ROS 2 actions are built on topics and services, so action introspection is based on :doc:`Service Introspection `. +ROS 2 actions are built on topics and services, so action introspection is based on :doc:`Service Introspection <../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>`. In this demo, we'll be highlighting how to configure action introspection state for an action client and an action server and monitor action communication with ``ros2 action echo``. diff --git a/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst b/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst index bd3e150d6cc..3a73442fded 100644 --- a/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst +++ b/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst @@ -56,7 +56,7 @@ In order not to counteract the QoS settings of the middleware, an incoming messa A *wait set* is used to inform the Executor about available messages on the middleware layer, with one binary flag per queue. The *wait set* is also used to detect when timers expire. -.. image:: ../images/executors_basic_principle.png +.. image:: images/executors_basic_principle.png The Single-Threaded Executor is also used by the container process for :doc:`components <../../nodes/About-Composition>`, i.e. in all cases where nodes are created and executed without an explicit main function. @@ -196,7 +196,7 @@ In detail, it only reports whether there are any messages for a certain topic or The Executor uses this information to process the messages (including services and actions) in a round-robin fashion - but not in FIFO order. The following flow diagram visualizes this scheduling semantics. -.. image:: ../images/executors_scheduling_semantics.png +.. image:: images/executors_scheduling_semantics.png This semantics was first described in a `paper by Casini et al. at ECRTS 2019 `_. (Note: The paper also explains that timer events are prioritized over all other messages. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst similarity index 97% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst rename to source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst index c8dfec3beca..cb7c08f724b 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst @@ -27,7 +27,7 @@ The underlying middleware used for ROS 2 is either a DDS or RTPS implementation, The ``rcl`` |API| is a slightly higher level |API| which is used to implement the |client libraries| and does not touch the middleware implementation directly, but rather does so through the ROS middleware interface (``rmw`` |API|) abstraction. -.. figure:: ../images/ros_client_library_api_stack.png +.. figure:: images/ros_client_library_api_stack.png :alt: ros2 software stack As the diagram shows, these |APIs| are stacked such that the typical ROS user will use the |client library| |API|, e.g. ``rclcpp``, to implement their code (executable or library). @@ -51,7 +51,7 @@ Type Specific Interfaces All along the way there are some parts of the |APIs| that are necessarily specific to the message types being exchanged, e.g. publishing a message or subscribing to a topic, and therefore require generated code for each message type. The following diagram layouts the path from user defined ``rosidl`` files, e.g. ``.msg`` files, to the type specific code used by the user and system to perform type specific functions: -.. figure:: ../images/ros_idl_api_stack_static.png +.. figure:: images/ros_idl_api_stack_static.png :alt: ros2 idl static type support stack Figure: flow chart of "static" type support generation, from ``rosidl`` files to user facing code. @@ -97,7 +97,7 @@ In order to accomplish this, this generic function needs some meta information a Then to publish a message, you call a generic publish function and pass a message to be published along with a structure which contains the necessary meta data about the message type. This is referred to as "dynamic" type support, as opposed to "static" type support which requires generated versions of a function for each type. -.. figure:: ../images/ros_idl_api_stack_dynamic.png +.. figure:: images/ros_idl_api_stack_dynamic.png :alt: ros2 idl dynamic type support stack Figure: flow chart of "dynamic" type support generation, from ``rosidl`` files to user facing code. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ROS Client Library API Stack.graffle b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ROS Client Library API Stack.graffle similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ROS Client Library API Stack.graffle rename to source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ROS Client Library API Stack.graffle diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ros_client_library_api_stack.png b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ros_client_library_api_stack.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ros_client_library_api_stack.png rename to source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ros_client_library_api_stack.png diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ros_idl_api_stack_dynamic.png b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ros_idl_api_stack_dynamic.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ros_idl_api_stack_dynamic.png rename to source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ros_idl_api_stack_dynamic.png diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ros_idl_api_stack_static.png b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ros_idl_api_stack_static.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/About-Internal-Interfaces/images/ros_idl_api_stack_static.png rename to source/ROS-Framework/client-libraries/About-Internal-Interfaces/images/ros_idl_api_stack_static.png diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst index 844f631359d..255b1d0c67e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst @@ -20,10 +20,10 @@ Working with Client libraries Working-with-Client-Libraries/Rosdep Working-with-Client-Libraries/Tf2/Tf2-Main Working-with-Client-Libraries/Allocator-Template-Tutorial + Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py - Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Cpp - Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py - Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Cpp + Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP + Working-with-Client-Libraries/Reading-From-A-Bag-File-Python Working-with-Client-Libraries/Creating-An-RMW-Implementation - Working-with-Client-Libraries/Config-ZeroCopy-loaned-messages + Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst index 925a819732a..9d6fd5294ab 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst @@ -44,7 +44,7 @@ Loaned messages require RMW implementation support. Installing the demo ------------------- -See the :doc:`installation instructions <../../Installation>` for details on installing ROS 2. +See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst index 5e36494b165..6621207cd0d 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst @@ -19,7 +19,6 @@ If you want to learn both C++ and Python, you should go through the tutorials on .. toctree:: :hidden: - Introduction-To-Tf2 Writing-A-Tf2-Static-Broadcaster-Py Writing-A-Tf2-Static-Broadcaster-Cpp Writing-A-Tf2-Broadcaster-Py @@ -30,7 +29,6 @@ If you want to learn both C++ and Python, you should go through the tutorials on Adding-A-Frame-Cpp Learning-About-Tf2-And-Time-Cpp Time-Travel-With-Tf2-Cpp - Quaternion-Fundamentals Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter Workspace setup @@ -79,7 +77,7 @@ Debugging tf2 This tutorial teaches you basics of quaternion usage in ROS 2. -#. :doc:`Debugging tf2 problems <../../../../Developer-Tools/Debugging/Debugging-Tf2-Problems>`. +#. :doc:`Debugging tf2 problems <../../../../Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems>`. This tutorial teaches you about a systematic approach for debugging tf2 related problems. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst index 3aef7151fc2..689a10cea43 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst @@ -277,7 +277,7 @@ Finally we have the ``main`` method, which constructs a ``MinimalClientAsync`` o .. warning:: Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. - For more details see the :doc:`sync deadlock article <../../../How-To-Guides/Sync-Vs-Async>`. + For more details see the :doc:`sync deadlock article <../../services/Working-with-services/Sync-Vs-Async>`. 3.2 Add an entry point ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst index a8b98553b34..ffd80def8d6 100644 --- a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst +++ b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst @@ -15,7 +15,7 @@ Overview tf2 is the transform library, which lets the user keep track of multiple coordinate frames over time. tf2 maintains the relationship between coordinate frames in a tree structure buffered in time and lets the user transform points, vectors, etc. between any two coordinate frames at any desired point in time. -.. image:: ../images/ros2_tf2_frames.png +.. image:: images/ros2_tf2_frames.png Properties of tf2 ----------------- diff --git a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst b/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst index bded41a9047..dceae30b2ab 100644 --- a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst +++ b/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst @@ -32,7 +32,7 @@ ROS nodes typically communicate through the following three types of interfaces: For consistent communication, each interface uses definitions provided in ``.msg``, ``.srv``, or ``.action`` files. -:doc:`Learn more about nodes ` +:doc:`Learn more about nodes <../About-Nodes>` Topics ------ diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces.rst b/source/ROS-Framework/interfaces/Working-with-interfaces.rst index 50d5b68654d..f07003c8ed0 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Working with interfaces ======================= diff --git a/source/ROS-Framework/nodes/About-Logging/About-Logging.rst b/source/ROS-Framework/nodes/About-Logging/About-Logging.rst index 0b5c3027d34..d2da959a9c7 100644 --- a/source/ROS-Framework/nodes/About-Logging/About-Logging.rst +++ b/source/ROS-Framework/nodes/About-Logging/About-Logging.rst @@ -184,7 +184,7 @@ Logging subsystem design The image below shows the main pieces to the logging subsystem and how they interact. Note that ``rcl`` can link to logging implementations either through the ``rcl_logging_implementation`` abstraction layer (for runtime dynamic loading, the default) or directly to a specific implementation like ``rcl_logging_spdlog`` (for static linking). -.. figure:: ../images/ros2_logging_architecture.png +.. figure:: images/ros2_logging_architecture.png :alt: ROS 2 logging architecture :width: 550px :align: center @@ -204,7 +204,7 @@ rcl_logging_implementation ``rcl_logging_implementation`` is a package that enables runtime dynamic loading of logging backends in ROS 2, similar to how ``rmw_implementation`` works for middleware selection. This abstraction layer allows users to switch between different logging implementations (such as ``rcl_logging_spdlog`` and ``rcl_logging_noop``) without rebuilding RCL or application code. -.. figure:: ../images/rcl_logging_implementation.png +.. figure:: images/rcl_logging_implementation.png :alt: rcl_logging_implementation architecture :width: 550px :align: center diff --git a/source/ROS-Framework/nodes/Working-with-nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes.rst index 60d303399bb..a0552bd1560 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Working with nodes ================== diff --git a/source/ROS-Framework/parameters/Working-with-parameters.rst b/source/ROS-Framework/parameters/Working-with-parameters.rst index 3f8658dbb8b..7b1a8828ea1 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Working with parameters ======================= diff --git a/source/ROS-Framework/services/Working-with-services.rst b/source/ROS-Framework/services/Working-with-services.rst index b1078092aa3..141bc123dfd 100644 --- a/source/ROS-Framework/services/Working-with-services.rst +++ b/source/ROS-Framework/services/Working-with-services.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Working with services ===================== diff --git a/source/ROS-Framework/topics/Working-with-topics.rst b/source/ROS-Framework/topics/Working-with-topics.rst index ced5bba482c..59e3a3e51d6 100644 --- a/source/ROS-Framework/topics/Working-with-topics.rst +++ b/source/ROS-Framework/topics/Working-with-topics.rst @@ -1,5 +1,4 @@ -.. _InstallationGuide: -.. _RollingInstall: + Working with topics =================== diff --git a/source/The-ROS2-Project/Contributing.rst b/source/The-ROS2-Project/Contributing.rst index e775d07cc8f..9b5f76f1597 100644 --- a/source/The-ROS2-Project/Contributing.rst +++ b/source/The-ROS2-Project/Contributing.rst @@ -1,116 +1,116 @@ -.. redirect-from:: - - Contributing - -.. _Contributing: - -Contributing -============ - -.. contents:: Table of Contents - :depth: 1 - :local: - -A few things to remember before you start contributing to the ROS 2 project. - -Tenets ------- - -* Respect what came before - - ROS has been around for more than a decade and is used by developers and across the world. - Keep a humble attitude and an open mindset while contributing. - -* Engage Open Robotics as early as possible - - * Open Robotics acts as a gate-keeper and advocate for the ROS community. - Rely on their expertise and technical judgement from the design phase. - * Start discussions with Open Robotics and the community early. - Long time ROS contributors may have a clearer vision of the bigger picture. - If you implement a feature and send a pull request without discussing with the community first, you are taking the risk of it being rejected, or you may be asked to largely rethink your design. - * Opening issues or using Discourse to socialize an idea before starting the implementation is generally preferable. - -* Adopt community best-practices whenever possible instead of ad-hoc processes - - Think about your end-user's experience when developing and contributing. - Avoid using non-standard tools or libraries that may not be accessible to everyone. - -* Think about the community as a whole - - Think about the bigger picture. - There are developers building different robots with different constraints. - ROS needs to accommodate requirements of the whole community. - -There are a number of ways you can contribute to the ROS 2 project. - -Discussions and support ------------------------ - -Some of the easiest ways to contribute to ROS 2 involve engaging in community discussions and support. -You can find more information on how to pitch in on the :doc:`Contact <../../Contact>` page. - -Contributing code ------------------ - -Setting up your development environment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To get started, you'll want to install from source; follow :ref:`the source installation instructions ` for your platform. - -Development Guides -^^^^^^^^^^^^^^^^^^ - -.. toctree:: - :titlesonly: - :maxdepth: 1 - - Contributing/Developer-Guide - Contributing/Code-Style-Language-Versions - Contributing/Quality-Guide - Contributing/Build-Farms - Contributing/Windows-Tips-and-Tricks - Contributing/Contributing-To-ROS-2-Documentation - -What to work on -^^^^^^^^^^^^^^^ - -We have identified a number of tasks that could be worked on by community members: they can be listed by `searching across the ROS 2 repositories for issues labeled as "help wanted" `__. -If you see something on that list that you would like to work on, please comment on the item to let others know that you are looking into it. - -We also have a label for issues that we think should be more accessible for first-time contributors, `labeled "good first issue" `__. -If you are interested in contributing to the ROS 2 project, we encourage you to take a look at those issues first. -If you'd like to cast a wider net, we welcome contributions on any open issue (or others that you might propose), particularly tasks that have a milestone signifying they're targeted for the next ROS 2 release (the milestone will be the next release's e.g. 'crystal'). - -If you have some code to contribute that fixes a bug or improves documentation, please submit it as a pull request to the relevant repository. -For larger changes, it is a good idea to discuss the proposal `on the ROS 2 forum `__ before you start to work on it so that you can identify if someone else is already working on something similar. -If your proposal involves changes to the APIs, it is especially recommended that you discuss the approach before starting work. - -Submitting your code changes -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Code contributions should be made via pull requests to `the appropriate ros2 repositories `__. - -We ask all contributors to follow the practices explained in :doc:`the developer guide `. - -Please be sure to :ref:`run tests ` for your code changes because most packages have tests that check that the code complies with our style guidelines. - -Becoming a core maintainer -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The ROS 2 maintainers ensure that the project is generally making progress. -The responsibilities of the maintainers include: - -* Reviewing incoming code contributions for style, quality, and overall fit into the goals of the repository/ROS 2. -* Ensuring that CI continues to stay green. -* Merging pull requests that meet the quality and CI standards above. -* Addressing issues opened up by users. - -Each repository in the `ros2 `__ and `ament `__ organizations has a separate set of maintainers. -Becoming a maintainer of one or more of those repositories is an invitation-only process, and generally involves the following steps: - -* Within the last year, have a substantial number of code contributions to the repository. -* Within the last year, do a substantial number of reviews on incoming pull requests to the repository. - -Approximately every 3 months, the ROS 2 team will review the contributions in all of the repositories and send out invitations to new maintainers. -Once the invitation is accepted, the new maintainer will be asked to go through a short training process on the mechanisms and policies of the ROS 2 repositories. -After that training process is completed, the new maintainer will be given write access to the appropriate repositories. +.. redirect-from:: + + Contributing + +.. _Contributing: + +Contributing +============ + +.. contents:: Table of Contents + :depth: 1 + :local: + +A few things to remember before you start contributing to the ROS 2 project. + +Tenets +------ + +* Respect what came before + + ROS has been around for more than a decade and is used by developers and across the world. + Keep a humble attitude and an open mindset while contributing. + +* Engage Open Robotics as early as possible + + * Open Robotics acts as a gate-keeper and advocate for the ROS community. + Rely on their expertise and technical judgement from the design phase. + * Start discussions with Open Robotics and the community early. + Long time ROS contributors may have a clearer vision of the bigger picture. + If you implement a feature and send a pull request without discussing with the community first, you are taking the risk of it being rejected, or you may be asked to largely rethink your design. + * Opening issues or using Discourse to socialize an idea before starting the implementation is generally preferable. + +* Adopt community best-practices whenever possible instead of ad-hoc processes + + Think about your end-user's experience when developing and contributing. + Avoid using non-standard tools or libraries that may not be accessible to everyone. + +* Think about the community as a whole + + Think about the bigger picture. + There are developers building different robots with different constraints. + ROS needs to accommodate requirements of the whole community. + +There are a number of ways you can contribute to the ROS 2 project. + +Discussions and support +----------------------- + +Some of the easiest ways to contribute to ROS 2 involve engaging in community discussions and support. +You can find more information on how to pitch in on the :doc:`Contact <../Contact>` page. + +Contributing code +----------------- + +Setting up your development environment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To get started, you'll want to install from source; follow :ref:`the source installation instructions ` for your platform. + +Development Guides +^^^^^^^^^^^^^^^^^^ + +.. toctree:: + :titlesonly: + :maxdepth: 1 + + Contributing/Developer-Guide + Contributing/Code-Style-Language-Versions + Contributing/Quality-Guide + Contributing/Build-Farms + Contributing/Windows-Tips-and-Tricks + Contributing/Contributing-To-ROS-2-Documentation + +What to work on +^^^^^^^^^^^^^^^ + +We have identified a number of tasks that could be worked on by community members: they can be listed by `searching across the ROS 2 repositories for issues labeled as "help wanted" `__. +If you see something on that list that you would like to work on, please comment on the item to let others know that you are looking into it. + +We also have a label for issues that we think should be more accessible for first-time contributors, `labeled "good first issue" `__. +If you are interested in contributing to the ROS 2 project, we encourage you to take a look at those issues first. +If you'd like to cast a wider net, we welcome contributions on any open issue (or others that you might propose), particularly tasks that have a milestone signifying they're targeted for the next ROS 2 release (the milestone will be the next release's e.g. 'crystal'). + +If you have some code to contribute that fixes a bug or improves documentation, please submit it as a pull request to the relevant repository. +For larger changes, it is a good idea to discuss the proposal `on the ROS 2 forum `__ before you start to work on it so that you can identify if someone else is already working on something similar. +If your proposal involves changes to the APIs, it is especially recommended that you discuss the approach before starting work. + +Submitting your code changes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Code contributions should be made via pull requests to `the appropriate ros2 repositories `__. + +We ask all contributors to follow the practices explained in :doc:`the developer guide `. + +Please be sure to :ref:`run tests ` for your code changes because most packages have tests that check that the code complies with our style guidelines. + +Becoming a core maintainer +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The ROS 2 maintainers ensure that the project is generally making progress. +The responsibilities of the maintainers include: + +* Reviewing incoming code contributions for style, quality, and overall fit into the goals of the repository/ROS 2. +* Ensuring that CI continues to stay green. +* Merging pull requests that meet the quality and CI standards above. +* Addressing issues opened up by users. + +Each repository in the `ros2 `__ and `ament `__ organizations has a separate set of maintainers. +Becoming a maintainer of one or more of those repositories is an invitation-only process, and generally involves the following steps: + +* Within the last year, have a substantial number of code contributions to the repository. +* Within the last year, do a substantial number of reviews on incoming pull requests to the repository. + +Approximately every 3 months, the ROS 2 team will review the contributions in all of the repositories and send out invitations to new maintainers. +Once the invitation is accepted, the new maintainer will be asked to go through a short training process on the mechanisms and policies of the ROS 2 repositories. +After that training process is completed, the new maintainer will be given write access to the appropriate repositories. diff --git a/source/Tutorials/Beginner-CLI-Tools.rst b/source/Tutorials/Beginner-CLI-Tools.rst deleted file mode 100644 index f46e1becb44..00000000000 --- a/source/Tutorials/Beginner-CLI-Tools.rst +++ /dev/null @@ -1,16 +0,0 @@ -Beginner: CLI tools -=================== - -.. toctree:: - :maxdepth: 1 - - Beginner-CLI-Tools/Configuring-ROS2-Environment - Beginner-CLI-Tools/Introducing-Turtlesim/Introducing-Turtlesim - Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes - Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics - Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services - Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters - Beginner-CLI-Tools/Understanding-ROS2-Actions/Understanding-ROS2-Actions - Beginner-CLI-Tools/Using-Rqt-Console/Using-Rqt-Console - Beginner-CLI-Tools/Launching-Multiple-Nodes/Launching-Multiple-Nodes - Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data diff --git a/source/index.rst b/source/index.rst index 1af6d22b8d4..335c175e009 100644 --- a/source/index.rst +++ b/source/index.rst @@ -17,7 +17,7 @@ ROS 2 Documentation Migration-and-Upgrades Integrations-and-related The-ROS2-Project - Related-Projects + Integrations-and-related Contact Glossary Citations @@ -58,7 +58,7 @@ Getting started * :doc:`Capabilities ` - - High-level explanations of core ROS 2 concepts covered in the :doc:`Tutorials ` + - High-level explanations of core ROS 2 concepts * :doc:`Contact ` From 7419fd76d9549df60ae0bead17852bd93a161828 Mon Sep 17 00:00:00 2001 From: dmarshant Date: Wed, 27 May 2026 14:57:32 +0100 Subject: [PATCH 13/20] Fixed remaining broken cross references --- source/Developer-Tools/About-Build.rst | 7 ++----- .../Building-ROS2-Package-with-eclipse-2021-06.rst | 2 +- .../images/eclipse_c++_add_directory_path.png | Bin .../eclipse_c++_build_project_with_colcon.png | Bin .../images/eclipse_c++_builder_env.png | Bin .../images/eclipse_c++_builder_main.png | Bin .../images/eclipse_c++_indexer_ok.png | Bin .../images/eclipse_c++_path_and_symbols.png | Bin .../images/eclipse_c++_project_includes.png | Bin .../images/eclipse_c++_project_select_type.png | Bin .../images/eclipse_c++_properties_builders.png | Bin .../eclipse_c++_properties_builders_with_colcon.png | Bin .../images/eclipse_c++_wo_ros_includes.png | Bin .../images/eclipse_create_c++_project.png | Bin .../images/eclipse_import_filesystem.png | Bin .../images/eclipse_import_project.png | Bin .../images/eclipse_import_select_my_package.png | Bin .../images/eclipse_preferences_wo_paths_select.png | Bin .../images/eclipse_project_explorer.png | Bin .../images/eclipse_project_natures_c++_select.png | Bin .../eclipse_project_natures_c_nature_select.png | Bin .../images/eclipse_project_natures_warning.png | Bin .../images/eclipse_properties_project_natures.png | Bin .../eclipse_right_click_menu_with_indexer.png | Bin .../images/eclipse_right_click_menu_wo_indexer.png | Bin .../images/eclipse_subpub_code_insert.png | Bin .../images/eclipse_work_dir.png | Bin .../images/tree_dev_ws.png | Bin ...uilding-Realtime-rt_preempt-kernel-for-ROS-2.rst | 0 .../images/realtime-kernel-patch-version.png | Bin .../Debugging-Tf2-Problems.rst | 4 ++-- .../Working-with-Client-Libraries.rst | 3 +-- .../Tf2/Adding-A-Frame-Cpp.rst | 2 +- .../Tf2/Adding-A-Frame-Py.rst | 2 +- .../Working-with-Client-Libraries/Tf2/Tf2-Main.rst | 2 +- .../Interfaces-Topics-Services-Actions.rst | 12 ------------ .../interfaces/Working-with-interfaces.rst | 3 +-- .../Introduction-To-Tf2.rst | 0 .../images/turtlesim_follow1.png | Bin .../images/turtlesim_follow2.png | Bin .../images/turtlesim_frames.png | Bin .../Introduction-To-Tf2}/images/turtlesim_rviz.png | Bin source/ROS-Framework/topics/Working-with-topics.rst | 1 + source/index.rst | 3 +-- 44 files changed, 12 insertions(+), 29 deletions(-) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/Building-ROS2-Package-with-eclipse-2021-06.rst (93%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_add_directory_path.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_build_project_with_colcon.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_builder_env.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_builder_main.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_indexer_ok.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_path_and_symbols.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_project_includes.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_project_select_type.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_properties_builders.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_properties_builders_with_colcon.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_c++_wo_ros_includes.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_create_c++_project.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_import_filesystem.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_import_project.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_import_select_my_package.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_preferences_wo_paths_select.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_project_explorer.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_project_natures_c++_select.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_project_natures_c_nature_select.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_project_natures_warning.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_properties_project_natures.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_right_click_menu_with_indexer.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_right_click_menu_wo_indexer.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_subpub_code_insert.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/eclipse_work_dir.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06}/images/tree_dev_ws.png (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-Realtime-rt_preempt-kernel-for-ROS-2}/Building-Realtime-rt_preempt-kernel-for-ROS-2.rst (100%) rename source/{Tutorials/Miscellaneous => Developer-Tools/Build/Building-Realtime-rt_preempt-kernel-for-ROS-2}/images/realtime-kernel-patch-version.png (100%) rename source/ROS-Framework/interfaces/Working-with-interfaces/{ => Introduction-To-Tf2}/Introduction-To-Tf2.rst (100%) rename source/ROS-Framework/{client-libraries/Working-with-Client-Libraries/Tf2 => interfaces/Working-with-interfaces/Introduction-To-Tf2}/images/turtlesim_follow1.png (100%) rename source/ROS-Framework/{client-libraries/Working-with-Client-Libraries/Tf2 => interfaces/Working-with-interfaces/Introduction-To-Tf2}/images/turtlesim_follow2.png (100%) rename source/ROS-Framework/{client-libraries/Working-with-Client-Libraries/Tf2 => interfaces/Working-with-interfaces/Introduction-To-Tf2}/images/turtlesim_frames.png (100%) rename source/ROS-Framework/{client-libraries/Working-with-Client-Libraries/Tf2 => interfaces/Working-with-interfaces/Introduction-To-Tf2}/images/turtlesim_rviz.png (100%) diff --git a/source/Developer-Tools/About-Build.rst b/source/Developer-Tools/About-Build.rst index fc3b195787a..52e2b48287e 100644 --- a/source/Developer-Tools/About-Build.rst +++ b/source/Developer-Tools/About-Build.rst @@ -27,9 +27,6 @@ PLACEHOLDER Build/Using-Python-Packages Build/Developing-a-ROS-2-Package Build/Documenting-a-ROS-2-Package - Build/Releasing/Index-Your-Packages - Build/Releasing/Release-Team-Repository - Build/Releasing/First-Time-Release Build/Releasing/Releasing-a-Package - Build/Releasing/Release-Track - Build/Releasing/Subsequent-Releases \ No newline at end of file + Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/Building-Realtime-rt_preempt-kernel-for-ROS-2 + Build/Building-ROS2-Package-with-eclipse-2021-06/Building-ROS2-Package-with-eclipse-2021-06 diff --git a/source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/Building-ROS2-Package-with-eclipse-2021-06.rst similarity index 93% rename from source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/Building-ROS2-Package-with-eclipse-2021-06.rst index 9b8c96a37fc..69c807528ba 100644 --- a/source/Tutorials/Miscellaneous/Building-ROS2-Package-with-eclipse-2021-06.rst +++ b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/Building-ROS2-Package-with-eclipse-2021-06.rst @@ -10,7 +10,7 @@ Building a package with Eclipse 2021-06 :local: You cannot create a ROS 2 package with eclipse, you need to create it with commandline tools. -Follow the :doc:`Create a package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` tutorial. +Follow the :doc:`Create a package <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` tutorial. After you created your project, you can edit the source code and build it with eclipse. diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_add_directory_path.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_add_directory_path.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_add_directory_path.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_add_directory_path.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_build_project_with_colcon.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_build_project_with_colcon.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_build_project_with_colcon.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_build_project_with_colcon.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_builder_env.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_builder_env.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_builder_env.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_builder_env.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_builder_main.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_builder_main.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_builder_main.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_builder_main.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_indexer_ok.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_indexer_ok.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_indexer_ok.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_indexer_ok.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_path_and_symbols.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_path_and_symbols.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_path_and_symbols.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_path_and_symbols.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_project_includes.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_project_includes.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_project_includes.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_project_includes.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_project_select_type.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_project_select_type.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_project_select_type.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_project_select_type.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_properties_builders.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_properties_builders.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_properties_builders.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_properties_builders.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_properties_builders_with_colcon.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_properties_builders_with_colcon.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_properties_builders_with_colcon.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_properties_builders_with_colcon.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_c++_wo_ros_includes.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_wo_ros_includes.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_c++_wo_ros_includes.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_c++_wo_ros_includes.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_create_c++_project.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_create_c++_project.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_create_c++_project.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_create_c++_project.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_import_filesystem.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_import_filesystem.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_import_filesystem.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_import_filesystem.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_import_project.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_import_project.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_import_project.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_import_project.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_import_select_my_package.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_import_select_my_package.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_import_select_my_package.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_import_select_my_package.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_preferences_wo_paths_select.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_preferences_wo_paths_select.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_preferences_wo_paths_select.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_preferences_wo_paths_select.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_project_explorer.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_explorer.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_project_explorer.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_explorer.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_project_natures_c++_select.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_natures_c++_select.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_project_natures_c++_select.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_natures_c++_select.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_project_natures_c_nature_select.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_natures_c_nature_select.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_project_natures_c_nature_select.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_natures_c_nature_select.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_project_natures_warning.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_natures_warning.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_project_natures_warning.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_project_natures_warning.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_properties_project_natures.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_properties_project_natures.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_properties_project_natures.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_properties_project_natures.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_right_click_menu_with_indexer.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_right_click_menu_with_indexer.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_right_click_menu_with_indexer.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_right_click_menu_with_indexer.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_right_click_menu_wo_indexer.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_right_click_menu_wo_indexer.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_right_click_menu_wo_indexer.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_right_click_menu_wo_indexer.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_subpub_code_insert.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_subpub_code_insert.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_subpub_code_insert.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_subpub_code_insert.png diff --git a/source/Tutorials/Miscellaneous/images/eclipse_work_dir.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_work_dir.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/eclipse_work_dir.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/eclipse_work_dir.png diff --git a/source/Tutorials/Miscellaneous/images/tree_dev_ws.png b/source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/tree_dev_ws.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/tree_dev_ws.png rename to source/Developer-Tools/Build/Building-ROS2-Package-with-eclipse-2021-06/images/tree_dev_ws.png diff --git a/source/Tutorials/Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2.rst b/source/Developer-Tools/Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/Building-Realtime-rt_preempt-kernel-for-ROS-2.rst similarity index 100% rename from source/Tutorials/Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2.rst rename to source/Developer-Tools/Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/Building-Realtime-rt_preempt-kernel-for-ROS-2.rst diff --git a/source/Tutorials/Miscellaneous/images/realtime-kernel-patch-version.png b/source/Developer-Tools/Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/images/realtime-kernel-patch-version.png similarity index 100% rename from source/Tutorials/Miscellaneous/images/realtime-kernel-patch-version.png rename to source/Developer-Tools/Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/images/realtime-kernel-patch-version.png diff --git a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst index b9ec87e8b46..b52739b6aba 100644 --- a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst +++ b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst @@ -177,7 +177,7 @@ If you like to get a graphical representation of this, use ``view_frames`` tool. Open the generated ``frames.pdf`` file to see the following output: -.. image:: ../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_frames.png +.. image:: ../../../ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_frames.png So obviously the problem is that we are requesting transform from frame ``turtle3``, which does not exist. To fix this bug, just replace ``turtle3`` with ``turtle2`` in line 65. @@ -278,7 +278,7 @@ Stop the demo, build and run: And you should finally see the turtle move! -.. image:: ../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_follow1.png +.. image:: ../../../ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_follow1.png That last fix we made is not really what you want to do, it was just to make sure that was our problem. The real fix would look like this: diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst index 255b1d0c67e..947cc9ae971 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst @@ -25,5 +25,4 @@ Working with Client libraries Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP Working-with-Client-Libraries/Reading-From-A-Bag-File-Python Working-with-Client-Libraries/Creating-An-RMW-Implementation - Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages - Working-with-Client-Libraries/About-Internal-Interfaces/About-Internal-Interfaces \ No newline at end of file + Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst index 40a7997b16e..523b62d8f2e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst @@ -37,7 +37,7 @@ Currently, our tf2 tree contains three frames: ``world``, ``turtle1`` and ``turt The two turtle frames are children of the ``world`` frame. If we want to add a new frame to tf2, one of the three existing frames needs to be the parent frame, and the new one will become its child frame. -.. image:: images/turtlesim_frames.png +.. image:: ../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_frames.png Tasks ----- diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst index 48a764eb240..5999c92c594 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst @@ -37,7 +37,7 @@ Currently, our tf2 tree contains three frames: ``world``, ``turtle1`` and ``turt The two turtle frames are children of the ``world`` frame. If we want to add a new frame to tf2, one of the three existing frames needs to be the parent frame, and the new one will become its child frame. -.. image:: images/turtlesim_frames.png +.. image:: ../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_frames.png Tasks ----- diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst index 6621207cd0d..20d2911cecc 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst @@ -39,7 +39,7 @@ If you have not yet created a workspace in which to complete the tutorials, :doc Learning tf2 ------------ -#. :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>`. +#. :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>`. This tutorial will give you a good idea of what tf2 can do for you. It shows off some of the tf2 power in a multi-robot example using turtlesim. diff --git a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst b/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst index dceae30b2ab..15ae07e5b71 100644 --- a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst +++ b/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst @@ -9,18 +9,6 @@ With this information, you'll be able to select the right interfaces for your pu **Area: ROS-framework | Content-type: concept | Experience: beginner** -.. contents:: Table of Contents - :depth: 2 - :local: - -.. toctree:: - :hidden: - - About-Interfaces - About-Topics - About-Services - About-Actions - Summary ------- diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces.rst b/source/ROS-Framework/interfaces/Working-with-interfaces.rst index f07003c8ed0..e157da5265f 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces.rst @@ -8,7 +8,6 @@ PLACEHOLDER .. toctree:: :maxdepth: 1 - Working-with-interfaces/Topics-Services-Actions Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data - Working-with-interfaces/Introduction-To-Tf2 + Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2 Working-with-interfaces/Quaternion-Fundamentals diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst similarity index 100% rename from source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2.rst rename to source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_follow1.png b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_follow1.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_follow1.png rename to source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_follow1.png diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_follow2.png b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_follow2.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_follow2.png rename to source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_follow2.png diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_frames.png b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_frames.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_frames.png rename to source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_frames.png diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_rviz.png b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_rviz.png similarity index 100% rename from source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/images/turtlesim_rviz.png rename to source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/images/turtlesim_rviz.png diff --git a/source/ROS-Framework/topics/Working-with-topics.rst b/source/ROS-Framework/topics/Working-with-topics.rst index 59e3a3e51d6..02429afec16 100644 --- a/source/ROS-Framework/topics/Working-with-topics.rst +++ b/source/ROS-Framework/topics/Working-with-topics.rst @@ -10,5 +10,6 @@ PLACEHOLDER Working-with-topics/Topic-Keys/Topic-Keys-Tutorial Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial + Working-with-topics/Content-Filtering-Subscription Working-with-topics/Quality-of-Service Working-with-topics/Wait-for-Acknowledgment \ No newline at end of file diff --git a/source/index.rst b/source/index.rst index 335c175e009..7f632dca1a3 100644 --- a/source/index.rst +++ b/source/index.rst @@ -17,7 +17,6 @@ ROS 2 Documentation Migration-and-Upgrades Integrations-and-related The-ROS2-Project - Integrations-and-related Contact Glossary Citations @@ -66,7 +65,7 @@ Getting started The ROS 2 Community ------------------ +------------------- If you're interested in the advancement of the ROS 2 project: From 1cfa4709fd313017d0250827e43a84eb6b187bb6 Mon Sep 17 00:00:00 2001 From: Denise Marshall Date: Tue, 2 Jun 2026 13:36:47 +0000 Subject: [PATCH 14/20] Align TOC with About-ROS topic --- source/Capabilities.rst | 6 +- ...-interfaces.rst => About-Manipulation.rst} | 4 +- ...d-Collision-Properties-to-a-URDF-Model.rst | 296 +-- ...ilding-a-Movable-Robot-Model-with-URDF.rst | 244 +-- ...ual-Robot-Model-with-URDF-from-Scratch.rst | 1154 ++++++------ .../Intermediate/About-Buffer-Backends.rst | 6 +- source/Developer-Tools.rst | 14 +- source/Developer-Tools/About-Build.rst | 1 - .../About-package-documentation.rst | 10 + source/Developer-Tools/Build/Package-Docs.rst | 80 +- .../FastDDS-Configuration.rst | 1604 ++++++++--------- .../Publishing-Messages-Using-YAML-Files.rst | 228 +-- .../Topic-Statistics-Tutorial.rst | 632 +++---- .../ROS2-Tracing-Trace-and-Analyze.rst | 396 ++-- .../Using-ROS2-Launch-For-Large-Projects.rst | 1100 +++++------ .../Documenting-a-ROS-2-Package.rst | 0 ...oS-Policies-For-Recording-And-Playback.rst | 222 +-- source/First-Steps.rst | 24 +- .../Ubuntu-Development-Setup-Pixi.rst | 2 +- .../Installation/Ubuntu-Install-Debs.rst | 12 +- .../Releases/Release-Kilted-Kaiju.rst | 1116 ++++++------ .../Releases/Release-Lyrical-Luth.rst | 6 +- .../Releases/lyrical/supported-platforms.rst | 4 +- .../Releases/makoa/supported-platforms.rst | 2 +- .../How-To-Guides/Using-Buffer-Backends.rst | 6 +- .../Related-Projects.rst | 104 +- .../Simulators/MVSim/Installation-Ubuntu.rst | 4 +- .../Setting-Up-Simulation-Webots-Basic.rst | 2 +- .../Migrating-CPP-Package-Example.rst | 884 ++++----- .../Migrating-Interfaces.rst | 108 +- .../Migrating-Package-XML.rst | 270 +-- .../Migrating-Python-Packages.rst | 356 ++-- source/ROS-Framework.rst | 5 +- source/ROS-Framework/About-Nodes.rst | 64 +- .../Interfaces-Topics-Services-Actions.rst | 26 +- .../About-Internal-Interfaces.rst | 480 ++--- .../Creating-An-RMW-Implementation.rst | 968 +++++----- .../Custom-ROS2-Interfaces.rst | 1598 ++++++++-------- ...ingle-Package-Define-And-Use-Interface.rst | 942 +++++----- .../Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst | 986 +++++----- .../Tf2/Writing-A-Tf2-Broadcaster-Py.rst | 1022 +++++------ .../Tf2/Writing-A-Tf2-Listener-Cpp.rst | 830 ++++----- .../Tf2/Writing-A-Tf2-Listener-Py.rst | 738 ++++---- .../Writing-A-Tf2-Static-Broadcaster-Cpp.rst | 878 ++++----- .../Writing-A-Tf2-Static-Broadcaster-Py.rst | 916 +++++----- ...-A-Simple-Cpp-Publisher-And-Subscriber.rst | 1072 +++++------ ...riting-A-Simple-Cpp-Service-And-Client.rst | 818 ++++----- ...g-A-Simple-Py-Publisher-And-Subscriber.rst | 1030 +++++------ ...Writing-A-Simple-Py-Service-And-Client.rst | 790 ++++---- .../{ => interfaces}/About-Actions.rst | 0 .../{ => interfaces}/About-Interfaces.rst | 629 ++++--- .../{ => interfaces}/About-Services.rst | 0 .../interfaces/About-Tf2/About-Tf2.rst | 320 ++-- .../{ => interfaces}/About-Topics.rst | 0 .../interfaces/Topics-Services-Actions.rst | 78 +- .../Introduction-To-Tf2.rst | 344 ++-- .../Recording-And-Playing-Back-Data.rst | 1476 +++++++-------- .../actions/Working-with-actions.rst | 0 .../Action-Introspection.rst | 690 +++---- .../Creating-an-Action.rst | 444 ++--- .../Understanding-ROS2-Actions.rst | 848 ++++----- .../images/Action-SingleActionClient.gif | Bin .../Writing-an-Action-Server-Client/Cpp.rst | 796 ++++---- .../Writing-an-Action-Server-Client/Py.rst | 0 .../scripts/client.cpp | 0 .../scripts/client_0.py | 0 .../scripts/client_1.py | 0 .../scripts/client_2.py | 0 .../scripts/server.cpp | 0 .../scripts/server_0.py | 0 .../scripts/server_1.py | 0 .../scripts/server_2.py | 0 .../scripts/server_3.py | 0 .../services/Working-with-services.rst | 0 .../Working-with-services/Sync-Vs-Async.rst | 300 +-- .../Understanding-ROS2-Services.rst | 830 ++++----- .../images/Service-MultipleServiceClient.gif | Bin .../images/Service-SingleServiceClient.gif | Bin .../images/clear.png | Bin .../images/spawn.png | Bin .../About-Quality-of-Service-Settings.rst | 0 .../topics/About-Topic-Statistics.rst | 0 .../Understanding-ROS2-Topics.rst | 1098 +++++------ ...MultiplePublisherandMultipleSubscriber.gif | Bin ...pic-SinglePublisherandSingleSubscriber.gif | Bin .../images/debug.png | Bin .../images/pub_once.png | Bin .../images/pub_stream.png | Bin .../images/rqt_graph.png | Bin .../images/rqt_graph2.png | Bin .../images/rqt_graph3.png | Bin .../images/unhide.png | Bin .../topics/Working-with-topics.rst | 0 .../Content-Filtering-Subscription.rst | 622 +++---- .../Quality-of-Service.rst | 374 ++-- .../Filtered-Topic-Keys-Tutorial.rst | 776 ++++---- .../Topic-Keys/Topic-Keys-Tutorial.rst | 1170 ++++++------ .../figures/cft_tutorial_diagram.svg | 0 .../figures/filtered_keyed_topic.gif | Bin .../Topic-Keys/figures/keyed-topics-cft.gif | Bin .../Topic-Keys/figures/keyed-topics.gif | Bin .../Topic-Keys/figures/keyed_topic.gif | Bin .../Topic-Keys/figures/multiple_topics.gif | Bin .../Topic-Keys/figures/single_topics.gif | Bin .../Topic-Keys/figures/tutorial_diagram.svg | 0 .../Topic-Keys/resources/Basic/CMakeLists.txt | 0 .../Topic-Keys/resources/Basic/README.md | 0 .../Basic/launch/keyed_sensors_launch.py | 0 .../launch/multiple_topic_sensors_launch.py | 0 .../launch/single_topic_sensors_launch.py | 0 .../Basic/msg/KeyedSensorDataMsg.msg | 0 .../resources/Basic/msg/SensorDataMsg.msg | 0 .../Topic-Keys/resources/Basic/package.xml | 0 .../resources/Basic/src/keyed_controller.cpp | 0 .../resources/Basic/src/keyed_sensor.cpp | 0 .../Basic/src/multiple_topic_controller.cpp | 0 .../Basic/src/multiple_topic_sensor.cpp | 0 .../Basic/src/single_topic_controller.cpp | 0 .../Basic/src/single_topic_sensor.cpp | 0 .../resources/Filtered/CMakeLists.txt | 0 .../Topic-Keys/resources/Filtered/README.md | 0 .../Filtered/launch/keyed_sensors_launch.py | 0 .../Filtered/msg/KeyedSensorDataMsg.msg | 0 .../Topic-Keys/resources/Filtered/package.xml | 0 .../src/filtered_keyed_controller.cpp | 0 .../Filtered/src/filtered_keyed_sensor.cpp | 0 .../Wait-for-Acknowledgment.rst | 192 +- .../ROS-Framework/nodes/About-Discovery.rst | 48 +- .../Understanding-ROS2-Nodes.rst | 392 ++-- .../Using-Rqt-Console/Using-Rqt-Console.rst | 264 +-- .../Understanding-ROS2-Parameters.rst | 504 +++--- source/The-ROS2-Project.rst | 4 +- .../Contributing-To-ROS-2-Documentation.rst | 2 +- .../Contributing/Developer-Guide.rst | 2 +- source/The-ROS2-Project/Features.rst | 208 +-- .../Advanced/Writing-a-Buffer-Backend.rst | 2 +- .../Tutorials/Demos/GPU-Buffer-Transport.rst | 2 +- ...ting-An-Async-Node-With-Asyncio-Python.rst | 6 +- 138 files changed, 17252 insertions(+), 17229 deletions(-) rename source/Capabilities/{About-User-interfaces.rst => About-Manipulation.rst} (80%) create mode 100644 source/Developer-Tools/About-package-documentation.rst rename source/Developer-Tools/{Build => Package-documentation}/Documenting-a-ROS-2-Package.rst (100%) rename source/ROS-Framework/{interfaces => }/Interfaces-Topics-Services-Actions.rst (87%) rename source/ROS-Framework/{ => interfaces}/About-Actions.rst (100%) rename source/ROS-Framework/{ => interfaces}/About-Interfaces.rst (94%) rename source/ROS-Framework/{ => interfaces}/About-Services.rst (100%) rename source/ROS-Framework/{ => interfaces}/About-Topics.rst (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions.rst (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Action-Introspection.rst (95%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Creating-an-Action.rst (90%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst (93%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Understanding-ROS2-Actions/images/Action-SingleActionClient.gif (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst (95%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client.cpp (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_0.py (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_1.py (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_2.py (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server.cpp (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_0.py (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_1.py (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_2.py (100%) rename source/ROS-Framework/{ => interfaces}/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_3.py (100%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services.rst (100%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services/Sync-Vs-Async.rst (92%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst (91%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services/Understanding-ROS2-Services/images/Service-MultipleServiceClient.gif (100%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services/Understanding-ROS2-Services/images/Service-SingleServiceClient.gif (100%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services/Understanding-ROS2-Services/images/clear.png (100%) rename source/ROS-Framework/{ => interfaces}/services/Working-with-services/Understanding-ROS2-Services/images/spawn.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/About-Quality-of-Service-Settings.rst (100%) rename source/ROS-Framework/{ => interfaces}/topics/About-Topic-Statistics.rst (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst (93%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/Topic-MultiplePublisherandMultipleSubscriber.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/Topic-SinglePublisherandSingleSubscriber.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/debug.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/pub_once.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/pub_stream.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/rqt_graph.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/rqt_graph2.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/rqt_graph3.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Understanding-ROS2-Topics/images/unhide.png (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics.rst (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Content-Filtering-Subscription.rst (97%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Quality-of-Service.rst (96%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst (97%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst (97%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/cft_tutorial_diagram.svg (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/filtered_keyed_topic.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/keyed-topics-cft.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/keyed-topics.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/keyed_topic.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/multiple_topics.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/single_topics.gif (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/figures/tutorial_diagram.svg (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/CMakeLists.txt (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/README.md (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/package.xml (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_controller.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_sensor.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_controller.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/CMakeLists.txt (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/README.md (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/package.xml (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp (100%) rename source/ROS-Framework/{ => interfaces}/topics/Working-with-topics/Wait-for-Acknowledgment.rst (95%) diff --git a/source/Capabilities.rst b/source/Capabilities.rst index 7b6dd2f77ec..f986b2fc4c4 100644 --- a/source/Capabilities.rst +++ b/source/Capabilities.rst @@ -9,8 +9,8 @@ PLACEHOLDER :hidden: :glob: + Capabilities/About-Simulation Capabilities/About-Motion-planning - Capabilities/About-Perception Capabilities/About-Navigation - Capabilities/About-User-interfaces - Capabilities/About-Simulation + Capabilities/About-Manipulation + Capabilities/About-Perception \ No newline at end of file diff --git a/source/Capabilities/About-User-interfaces.rst b/source/Capabilities/About-Manipulation.rst similarity index 80% rename from source/Capabilities/About-User-interfaces.rst rename to source/Capabilities/About-Manipulation.rst index d19eab2a596..101f58da71b 100644 --- a/source/Capabilities/About-User-interfaces.rst +++ b/source/Capabilities/About-Manipulation.rst @@ -1,5 +1,5 @@ -User interfaces -=============== +Manipulation +============ .. toctree:: :maxdepth: 1 diff --git a/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst b/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst index a8a5e5714eb..7448d90cb4a 100644 --- a/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst +++ b/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst @@ -1,148 +1,148 @@ -.. redirect-from:: - - Tutorials/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model - Tutorials/Intermediate/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model - -.. _URDFProperties: - -Adding physical and collision properties -======================================== - -**Goal:** Learn how to add collision and inertial properties to links, and how to add joint dynamics to joints. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -In this tutorial, we'll look at how to add some basic physical properties to your URDF model and how to specify its collision properties. - -Collision ---------- - -So far, we've only specified our links with a single sub-element, ``visual``, which defines (not surprisingly) what the robot looks like. -However, in order to get collision detection to work or to simulate the robot, we need to define a ``collision`` element as well. -`Here is the new urdf `_ with collision and physical properties. - -Here is the code for our new base link. - -.. code-block:: xml - - - - - - - - - - - - - - - - - -* The collision element is a direct subelement of the link object, at the same level as the visual tag. -* The collision element defines its shape the same way the visual element does, with a geometry tag. - The format for the geometry tag is exactly the same here as with the visual. -* You can also specify an origin in the same way as a subelement of the collision tag (as with the visual). - -In many cases, you'll want the collision geometry and origin to be exactly the same as the visual geometry and origin. -However, there are two main cases where you wouldn't: - - * **Quicker Processing** Doing collision detection for two meshes is a lot more computational complex than for two simple geometries. - Hence, you may want to replace the meshes with simpler geometries in the collision element. - * **Safe Zones** You may want to restrict movement close to sensitive equipment. - For instance, if we didn't want anything to collide with R2D2's head, we might define the collision geometry to be a cylinder encasing his head to prevent anything from getting too close to his head. - -Physical Properties -------------------- -In order to get your model to simulate properly, you need to define several physical properties of your robot, i.e. the properties that a physics engine like Gazebo would need. - -Inertia -^^^^^^^ -Every link element being simulated needs an inertial tag. -Here is a simple one. - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - -* This element is also a subelement of the link object. -* The mass is defined in kilograms. -* The 3x3 rotational inertia matrix is specified with the inertia element. - Since this is symmetrical, it can be represented by only 6 elements, as such. - - +---------+---------+---------+ - | **ixx** | **ixy** | **ixz** | - +---------+---------+---------+ - | ixy | **iyy** | **iyz** | - +---------+---------+---------+ - | ixz | iyz | **izz** | - +---------+---------+---------+ - -* This information can be provided to you by modeling programs such as MeshLab. - The inertia of geometric primitives (cylinder, box, sphere) can be computed using Wikipedia's `list of moment of inertia tensors `_ (and is used in the above example). -* The inertia tensor depends on both the mass and the distribution of mass of the object. - A good first approximation is to assume equal distribution of mass in the volume of the object and compute the inertia tensor based on the object's shape, as outlined above. -* If unsure what to put, a matrix with ixx/iyy/izz=1e-3 or smaller is often a reasonable default for a mid-sized link (it corresponds to a box of 0.1 m side length with a mass of 0.6 kg). - The identity matrix is a particularly bad choice, since it is often much too high. - (it corresponds to a box of 0.1 m side length with a mass of 600 kg!) -* You can also specify an origin tag to specify the center of gravity and the inertial reference frame (relative to the link's reference frame). -* When using realtime controllers, inertia elements of zero (or almost zero) can cause the robot model to collapse without warning, and all links will appear with their origins coinciding with the world origin. - -Contact Coefficients -^^^^^^^^^^^^^^^^^^^^ -You can also define how the links behave when they are in contact with one another. -This is done with a subelement of the collision tag called contact_coefficients. -There are three attributes to specify: - - * mu - `Friction coefficient `_ - * kp - `Stiffness coefficient `_ - * kd - `Dampening coefficient `_ - -Joint Dynamics -^^^^^^^^^^^^^^ -How the joint moves is defined by the dynamics tag for the joint. -There are two attributes here: - - * ``friction`` - The physical static friction. - For prismatic joints, the units are Newtons. - For revolving joints, the units are Newton meters. - * ``damping`` - The physical damping value. - For prismatic joints, the units are Newton seconds per meter. - For revolving joints, Newton meter seconds per radian. - -If not specified, these coefficients default to zero. - -Other Tags ----------- -In the realm of pure URDF (i.e. excluding Gazebo-specific tags), there are two remaining tags to help define the joints: calibration and safety controller. -Check out the `spec `_, as they are not included in this tutorial. - -Next Steps ----------- -Reduce the amount of code and annoying math you have to do by :doc:`using xacro <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File>`. \ No newline at end of file +.. redirect-from:: + + Tutorials/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model + Tutorials/Intermediate/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model + +.. _URDFProperties: + +Adding physical and collision properties +======================================== + +**Goal:** Learn how to add collision and inertial properties to links, and how to add joint dynamics to joints. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +In this tutorial, we'll look at how to add some basic physical properties to your URDF model and how to specify its collision properties. + +Collision +--------- + +So far, we've only specified our links with a single sub-element, ``visual``, which defines (not surprisingly) what the robot looks like. +However, in order to get collision detection to work or to simulate the robot, we need to define a ``collision`` element as well. +`Here is the new urdf `_ with collision and physical properties. + +Here is the code for our new base link. + +.. code-block:: xml + + + + + + + + + + + + + + + + + +* The collision element is a direct subelement of the link object, at the same level as the visual tag. +* The collision element defines its shape the same way the visual element does, with a geometry tag. + The format for the geometry tag is exactly the same here as with the visual. +* You can also specify an origin in the same way as a subelement of the collision tag (as with the visual). + +In many cases, you'll want the collision geometry and origin to be exactly the same as the visual geometry and origin. +However, there are two main cases where you wouldn't: + + * **Quicker Processing** Doing collision detection for two meshes is a lot more computational complex than for two simple geometries. + Hence, you may want to replace the meshes with simpler geometries in the collision element. + * **Safe Zones** You may want to restrict movement close to sensitive equipment. + For instance, if we didn't want anything to collide with R2D2's head, we might define the collision geometry to be a cylinder encasing his head to prevent anything from getting too close to his head. + +Physical Properties +------------------- +In order to get your model to simulate properly, you need to define several physical properties of your robot, i.e. the properties that a physics engine like Gazebo would need. + +Inertia +^^^^^^^ +Every link element being simulated needs an inertial tag. +Here is a simple one. + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + +* This element is also a subelement of the link object. +* The mass is defined in kilograms. +* The 3x3 rotational inertia matrix is specified with the inertia element. + Since this is symmetrical, it can be represented by only 6 elements, as such. + + +---------+---------+---------+ + | **ixx** | **ixy** | **ixz** | + +---------+---------+---------+ + | ixy | **iyy** | **iyz** | + +---------+---------+---------+ + | ixz | iyz | **izz** | + +---------+---------+---------+ + +* This information can be provided to you by modeling programs such as MeshLab. + The inertia of geometric primitives (cylinder, box, sphere) can be computed using Wikipedia's `list of moment of inertia tensors `_ (and is used in the above example). +* The inertia tensor depends on both the mass and the distribution of mass of the object. + A good first approximation is to assume equal distribution of mass in the volume of the object and compute the inertia tensor based on the object's shape, as outlined above. +* If unsure what to put, a matrix with ixx/iyy/izz=1e-3 or smaller is often a reasonable default for a mid-sized link (it corresponds to a box of 0.1 m side length with a mass of 0.6 kg). + The identity matrix is a particularly bad choice, since it is often much too high. + (it corresponds to a box of 0.1 m side length with a mass of 600 kg!) +* You can also specify an origin tag to specify the center of gravity and the inertial reference frame (relative to the link's reference frame). +* When using realtime controllers, inertia elements of zero (or almost zero) can cause the robot model to collapse without warning, and all links will appear with their origins coinciding with the world origin. + +Contact Coefficients +^^^^^^^^^^^^^^^^^^^^ +You can also define how the links behave when they are in contact with one another. +This is done with a subelement of the collision tag called contact_coefficients. +There are three attributes to specify: + + * mu - `Friction coefficient `_ + * kp - `Stiffness coefficient `_ + * kd - `Dampening coefficient `_ + +Joint Dynamics +^^^^^^^^^^^^^^ +How the joint moves is defined by the dynamics tag for the joint. +There are two attributes here: + + * ``friction`` - The physical static friction. + For prismatic joints, the units are Newtons. + For revolving joints, the units are Newton meters. + * ``damping`` - The physical damping value. + For prismatic joints, the units are Newton seconds per meter. + For revolving joints, Newton meter seconds per radian. + +If not specified, these coefficients default to zero. + +Other Tags +---------- +In the realm of pure URDF (i.e. excluding Gazebo-specific tags), there are two remaining tags to help define the joints: calibration and safety controller. +Check out the `spec `_, as they are not included in this tutorial. + +Next Steps +---------- +Reduce the amount of code and annoying math you have to do by :doc:`using xacro <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`. \ No newline at end of file diff --git a/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst b/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst index da11174d3d3..5feeb429540 100644 --- a/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst +++ b/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst @@ -1,122 +1,122 @@ -.. redirect-from:: - - Tutorials/URDF/Building-a-Movable-Robot-Model-with-URDF - Tutorials/Intermediate/URDF/Building-a-Movable-Robot-Model-with-URDF - -.. _MoveableURDF: - -Building a movable robot model -============================== - -**Goal:** Learn how to define movable joints in URDF. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -In this tutorial, we're going to revise the R2D2 model we made in the :doc:`previous tutorial ` so that it has movable joints. -In the previous model, all of the joints were fixed. -Now we'll explore three other important types of joints: continuous, revolute and prismatic. - -Make sure you have installed all prerequisites before continuing. -See the :doc:`previous tutorial ` for information on what is required. - -Again, all of the robot models mentioned in this tutorial can be found in the `urdf_tutorial `_ package. - -`Here is the new urdf `_ with flexible joints. -You can compare it to the previous version to see everything that has changed, but we're just going to focus on three example joints. - -To visualize and control this model, run the same command as the last tutorial: - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/06-flexible.urdf - -However now this will also pop up a GUI that allows you to control the values of all the non-fixed joints. -Play with the model some and see how it moves. -Then, we can take a look at how we accomplished this. - -.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/flexible.png - :width: 800 - :alt: Screenshot of Flexible Model - -The Head --------- - -.. code-block:: xml - - - - - - - - -The connection between the body and the head is a continuous joint, meaning that it can take on any angle from negative infinity to positive infinity. -The wheels are also modeled like this, so that they can roll in both directions forever. - -The only additional information we have to add is the axis of rotation, here specified by an xyz triplet, which specifies a vector around which the head will rotate. -Since we want it to go around the z axis, we specify the vector "0 0 1". - -The Gripper ------------ - -.. code-block:: xml - - - - - - - - - -Both the right and the left gripper joints are modeled as revolute joints. -This means that they rotate in the same way that the continuous joints do, but they have strict limits. -Hence, we must include the limit tag specifying the upper and lower limits of the joint (in radians). -We also must specify a maximum velocity and effort for this joint but the actual values don't matter for our purposes here. - -The Gripper Arm ---------------- - -.. code-block:: xml - - - - - - - - -The gripper arm is a different kind of joint, namely a prismatic joint. -This means that it moves along an axis, not around it. -This translational movement is what allows our robot model to extend and retract its gripper arm. - -The limits of the prismatic arm are specified in the same way as a revolute joint, except that the units are meters, not radians. - -Other Types of Joints ---------------------- - -There are two other kinds of joints that move around in space. -Whereas the prismatic joint can only move along one dimension, a planar joint can move around in a plane, or two dimensions. -Furthermore, a floating joint is unconstrained, and can move around in any of the three dimensions. -These joints cannot be specified by just one number, and therefore aren't included in this tutorial. - -Specifying the Pose -------------------- - -As you move the sliders around in the GUI, the model moves in Rviz. -How is this done? -First the `GUI `_ parses the URDF and finds all the non-fixed joints and their limits. -Then, it uses the values of the sliders to publish `sensor_msgs/msg/JointState `_ messages. -Those are then used by `robot_state_publisher `_ to calculate all of transforms between the different parts. -The resulting transform tree is then used to display all of the shapes in Rviz. - -Next steps ----------- - -Now that you have a visibly functional model, you can :doc:`add in some physical properties `, or :doc:`start using xacro to simplify your code <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File>`. \ No newline at end of file +.. redirect-from:: + + Tutorials/URDF/Building-a-Movable-Robot-Model-with-URDF + Tutorials/Intermediate/URDF/Building-a-Movable-Robot-Model-with-URDF + +.. _MoveableURDF: + +Building a movable robot model +============================== + +**Goal:** Learn how to define movable joints in URDF. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +In this tutorial, we're going to revise the R2D2 model we made in the :doc:`previous tutorial ` so that it has movable joints. +In the previous model, all of the joints were fixed. +Now we'll explore three other important types of joints: continuous, revolute and prismatic. + +Make sure you have installed all prerequisites before continuing. +See the :doc:`previous tutorial ` for information on what is required. + +Again, all of the robot models mentioned in this tutorial can be found in the `urdf_tutorial `_ package. + +`Here is the new urdf `_ with flexible joints. +You can compare it to the previous version to see everything that has changed, but we're just going to focus on three example joints. + +To visualize and control this model, run the same command as the last tutorial: + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/06-flexible.urdf + +However now this will also pop up a GUI that allows you to control the values of all the non-fixed joints. +Play with the model some and see how it moves. +Then, we can take a look at how we accomplished this. + +.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/flexible.png + :width: 800 + :alt: Screenshot of Flexible Model + +The Head +-------- + +.. code-block:: xml + + + + + + + + +The connection between the body and the head is a continuous joint, meaning that it can take on any angle from negative infinity to positive infinity. +The wheels are also modeled like this, so that they can roll in both directions forever. + +The only additional information we have to add is the axis of rotation, here specified by an xyz triplet, which specifies a vector around which the head will rotate. +Since we want it to go around the z axis, we specify the vector "0 0 1". + +The Gripper +----------- + +.. code-block:: xml + + + + + + + + + +Both the right and the left gripper joints are modeled as revolute joints. +This means that they rotate in the same way that the continuous joints do, but they have strict limits. +Hence, we must include the limit tag specifying the upper and lower limits of the joint (in radians). +We also must specify a maximum velocity and effort for this joint but the actual values don't matter for our purposes here. + +The Gripper Arm +--------------- + +.. code-block:: xml + + + + + + + + +The gripper arm is a different kind of joint, namely a prismatic joint. +This means that it moves along an axis, not around it. +This translational movement is what allows our robot model to extend and retract its gripper arm. + +The limits of the prismatic arm are specified in the same way as a revolute joint, except that the units are meters, not radians. + +Other Types of Joints +--------------------- + +There are two other kinds of joints that move around in space. +Whereas the prismatic joint can only move along one dimension, a planar joint can move around in a plane, or two dimensions. +Furthermore, a floating joint is unconstrained, and can move around in any of the three dimensions. +These joints cannot be specified by just one number, and therefore aren't included in this tutorial. + +Specifying the Pose +------------------- + +As you move the sliders around in the GUI, the model moves in Rviz. +How is this done? +First the `GUI `_ parses the URDF and finds all the non-fixed joints and their limits. +Then, it uses the values of the sliders to publish `sensor_msgs/msg/JointState `_ messages. +Those are then used by `robot_state_publisher `_ to calculate all of transforms between the different parts. +The resulting transform tree is then used to display all of the shapes in Rviz. + +Next steps +---------- + +Now that you have a visibly functional model, you can :doc:`add in some physical properties `, or :doc:`start using xacro to simplify your code <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`. \ No newline at end of file diff --git a/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst b/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst index cf733713260..6f644f29c65 100644 --- a/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst +++ b/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst @@ -1,578 +1,578 @@ -.. redirect-from:: - - Tutorials/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch - Tutorials/Intermediate/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch - -.. _BuildingURDF: - -Building a visual robot model from scratch -========================================== - -**Goal:** Learn how to build a visual model of a robot that you can view in Rviz - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -.. note:: This tutorial assumes you know how to write well-formatted XML code - -In this tutorial, we're going to build a visual model of a robot that vaguely looks like R2D2. -In later tutorials, you'll learn how to :doc:`articulate the model `, :doc:`add in some physical properties `, and :doc:`generate neater code with xacro <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File>`, but for now, we're going to focus on getting the visual geometry correct. - -Before continuing, make sure you have the `joint_state_publisher `_ package installed. -If you installed `urdf_tutorial `_ binaries, this should already be the case. -If not, please update your installation to include that package (use ``rosdep`` to check). - -All of the robot models mentioned in this tutorial (and the source files) can be found in the `urdf_tutorial `_ package. - -One Shape ---------- - -First, we're just going to explore one simple shape. -Here's about as simple as a urdf as you can make. -`[Source: 01-myfirst.urdf] `_ - -.. code-block:: xml - - - - - - - - - - - - -To translate the XML into English, this is a robot with the name ``myfirst``, that contains only one link (a.k.a. part), whose visual component is just a cylinder 0.6 meters long with a 0.2 meter radius. -This may seem like a lot of enclosing tags for a simple "hello world" type example. - -To examine the model, launch the ``display.launch.py`` file: - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/01-myfirst.urdf - -This does three things: - - * Loads the specified model and saves it as a parameter for the ``robot_state_publisher`` node. - * Runs nodes to publish `sensor_msgs/msg/JointState `_ and transforms (more on these later) - * Starts Rviz with a configuration file - -After launching ``display.launch.py``, you should end up with RViz showing you the following: - -.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/myfirst.png - :width: 800 - :alt: my first image - -Things to note: - * The fixed frame is the transform frame where the center of the grid is located. - Here, it's a frame defined by our one link, base_link. - * The visual element (the cylinder) has its origin at the center of its geometry as a default. - Hence, half the cylinder is below the grid. - -Multiple Shapes ---------------- - -Now let's look at how to add multiple shapes/links. -If we just add more link elements to the urdf, the parser won't know where to put them. -So, we have to add joints. -Joint elements can refer to both flexible and inflexible joints. -We'll start with inflexible, or fixed joints. -`[Source: 02-multipleshapes.urdf] `_ - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - - - -* Note how we defined a 0.6m x 0.1m x 0.2m box -* The joint is defined in terms of a parent and a child. - URDF is ultimately a tree structure with one root link. - This means that the leg's position is dependent on the base_link's position. - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/02-multipleshapes.urdf - -.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/multipleshapes.png - :width: 800 - :alt: Multiple Shapes - -Both of the shapes overlap with each other, because they share the same origin. -If we want them not to overlap we must define more origins. - -Origins -------- - -R2D2's leg attaches to the top half of his torso, on the side. -So that's where we specify the origin of the JOINT to be. -Also, it doesn't attach to the middle of the leg, it attaches to the upper part, so we must offset the origin for the leg as well. -We also rotate the leg so it is upright. -`[Source: 03-origins.urdf] `_ - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* Let's start by examining the joint's origin. - It is defined in terms of the parent's reference frame. - So we are -0.22 meters in the y direction (to our left, but to the right relative to the axes) and 0.25 meters in the z direction (up). - This means that the origin for the child link will be up and to the right, regardless of the child link's visual origin tag. - Since we didn't specify a rpy (roll pitch yaw) attribute, the child frame will be default have the same orientation as the parent frame. -* Now, looking at the leg's visual origin, it has both a xyz and rpy offset. - This defines where the center of the visual element should be, relative to its origin. - Since we want the leg to attach at the top, we offset the origin down by setting the z offset to be -0.3 meters. - And since we want the long part of the leg to be parallel to the z axis, we rotate the visual part PI/2 around the Y axis. - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/03-origins.urdf - -.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/origins.png - :width: 800 - :alt: Origins Screenshot - -* The launch file runs packages that will create TF frames for each link in your model based on your URDF. - Rviz uses this information to figure out where to display each shape. -* If a TF frame does not exist for a given URDF link, then it will be placed at the origin in white - (`related question `_). - -Material Girl -------------- - -"Alright," I hear you say. -"That's very cute, but not everyone owns a B21. -My robot and R2D2 are not red!" -That's a good point. -Let's take a look at the material tag. -`[Source: 04-materials.urdf] `_ - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -* The body is now blue. - We've defined a new material called "blue", with the red, green, blue and alpha channels defined as 0,0,0.8 and 1 respectively. - All of the values can be in the range [0,1]. - This material is then referenced by the base_link's visual element. - The white material is defined similarly. -* You could also define the material tag from within the visual element, and even reference it in other links. - No one will even complain if you redefine it though. -* You can also use a texture to specify an image file to be used for coloring the object - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/04-materials.urdf - -.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/materials.png - :width: 800 - :alt: Materials Screenshot - -Finishing the Model -------------------- - -Now we finish the model off with a few more shapes: feet, wheels, and head. -Most notably, we add a sphere and some meshes. -We'll also add few other pieces that we'll use later. -`[Source: 05-visual.urdf] `_ - -.. code-block:: xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -.. code-block:: console - - $ ros2 launch urdf_tutorial display.launch.py model:=urdf/05-visual.urdf - -.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/visual.png - :width: 800 - :alt: Visual Screenshot - -How to add the sphere should be fairly self explanatory: - -.. code-block:: xml - - - - - - - - - - -The meshes here were borrowed from the PR2. -They are separate files which you have to specify the path for. -You should use the ``package://NAME_OF_PACKAGE/path`` notation. -The meshes for this tutorial are located within the ``urdf_tutorial`` package, in a folder called meshes. - -.. code-block:: xml - - - - - - - - - - -* The meshes can be imported in a number of different formats. - STL is fairly common, but the engine also supports DAE, which can have its own color data, meaning you don't have to specify the color/material. - Often these are in separate files. - These meshes reference the ``.tif`` files also in the meshes folder. -* Meshes can also be sized using relative scaling parameters or a bounding box size. -* We could have also referred to meshes in a completely different package. - -There you have it. -A R2D2-like URDF model. +.. redirect-from:: + + Tutorials/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch + Tutorials/Intermediate/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch + +.. _BuildingURDF: + +Building a visual robot model from scratch +========================================== + +**Goal:** Learn how to build a visual model of a robot that you can view in Rviz + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +.. note:: This tutorial assumes you know how to write well-formatted XML code + +In this tutorial, we're going to build a visual model of a robot that vaguely looks like R2D2. +In later tutorials, you'll learn how to :doc:`articulate the model `, :doc:`add in some physical properties `, and :doc:`generate neater code with xacro <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`, but for now, we're going to focus on getting the visual geometry correct. + +Before continuing, make sure you have the `joint_state_publisher `_ package installed. +If you installed `urdf_tutorial `_ binaries, this should already be the case. +If not, please update your installation to include that package (use ``rosdep`` to check). + +All of the robot models mentioned in this tutorial (and the source files) can be found in the `urdf_tutorial `_ package. + +One Shape +--------- + +First, we're just going to explore one simple shape. +Here's about as simple as a urdf as you can make. +`[Source: 01-myfirst.urdf] `_ + +.. code-block:: xml + + + + + + + + + + + + +To translate the XML into English, this is a robot with the name ``myfirst``, that contains only one link (a.k.a. part), whose visual component is just a cylinder 0.6 meters long with a 0.2 meter radius. +This may seem like a lot of enclosing tags for a simple "hello world" type example. + +To examine the model, launch the ``display.launch.py`` file: + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/01-myfirst.urdf + +This does three things: + + * Loads the specified model and saves it as a parameter for the ``robot_state_publisher`` node. + * Runs nodes to publish `sensor_msgs/msg/JointState `_ and transforms (more on these later) + * Starts Rviz with a configuration file + +After launching ``display.launch.py``, you should end up with RViz showing you the following: + +.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/myfirst.png + :width: 800 + :alt: my first image + +Things to note: + * The fixed frame is the transform frame where the center of the grid is located. + Here, it's a frame defined by our one link, base_link. + * The visual element (the cylinder) has its origin at the center of its geometry as a default. + Hence, half the cylinder is below the grid. + +Multiple Shapes +--------------- + +Now let's look at how to add multiple shapes/links. +If we just add more link elements to the urdf, the parser won't know where to put them. +So, we have to add joints. +Joint elements can refer to both flexible and inflexible joints. +We'll start with inflexible, or fixed joints. +`[Source: 02-multipleshapes.urdf] `_ + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + +* Note how we defined a 0.6m x 0.1m x 0.2m box +* The joint is defined in terms of a parent and a child. + URDF is ultimately a tree structure with one root link. + This means that the leg's position is dependent on the base_link's position. + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/02-multipleshapes.urdf + +.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/multipleshapes.png + :width: 800 + :alt: Multiple Shapes + +Both of the shapes overlap with each other, because they share the same origin. +If we want them not to overlap we must define more origins. + +Origins +------- + +R2D2's leg attaches to the top half of his torso, on the side. +So that's where we specify the origin of the JOINT to be. +Also, it doesn't attach to the middle of the leg, it attaches to the upper part, so we must offset the origin for the leg as well. +We also rotate the leg so it is upright. +`[Source: 03-origins.urdf] `_ + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + +* Let's start by examining the joint's origin. + It is defined in terms of the parent's reference frame. + So we are -0.22 meters in the y direction (to our left, but to the right relative to the axes) and 0.25 meters in the z direction (up). + This means that the origin for the child link will be up and to the right, regardless of the child link's visual origin tag. + Since we didn't specify a rpy (roll pitch yaw) attribute, the child frame will be default have the same orientation as the parent frame. +* Now, looking at the leg's visual origin, it has both a xyz and rpy offset. + This defines where the center of the visual element should be, relative to its origin. + Since we want the leg to attach at the top, we offset the origin down by setting the z offset to be -0.3 meters. + And since we want the long part of the leg to be parallel to the z axis, we rotate the visual part PI/2 around the Y axis. + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/03-origins.urdf + +.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/origins.png + :width: 800 + :alt: Origins Screenshot + +* The launch file runs packages that will create TF frames for each link in your model based on your URDF. + Rviz uses this information to figure out where to display each shape. +* If a TF frame does not exist for a given URDF link, then it will be placed at the origin in white + (`related question `_). + +Material Girl +------------- + +"Alright," I hear you say. +"That's very cute, but not everyone owns a B21. +My robot and R2D2 are not red!" +That's a good point. +Let's take a look at the material tag. +`[Source: 04-materials.urdf] `_ + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +* The body is now blue. + We've defined a new material called "blue", with the red, green, blue and alpha channels defined as 0,0,0.8 and 1 respectively. + All of the values can be in the range [0,1]. + This material is then referenced by the base_link's visual element. + The white material is defined similarly. +* You could also define the material tag from within the visual element, and even reference it in other links. + No one will even complain if you redefine it though. +* You can also use a texture to specify an image file to be used for coloring the object + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/04-materials.urdf + +.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/materials.png + :width: 800 + :alt: Materials Screenshot + +Finishing the Model +------------------- + +Now we finish the model off with a few more shapes: feet, wheels, and head. +Most notably, we add a sphere and some meshes. +We'll also add few other pieces that we'll use later. +`[Source: 05-visual.urdf] `_ + +.. code-block:: xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +.. code-block:: console + + $ ros2 launch urdf_tutorial display.launch.py model:=urdf/05-visual.urdf + +.. image:: https://raw.githubusercontent.com/ros/urdf_tutorial/ros2/images/visual.png + :width: 800 + :alt: Visual Screenshot + +How to add the sphere should be fairly self explanatory: + +.. code-block:: xml + + + + + + + + + + +The meshes here were borrowed from the PR2. +They are separate files which you have to specify the path for. +You should use the ``package://NAME_OF_PACKAGE/path`` notation. +The meshes for this tutorial are located within the ``urdf_tutorial`` package, in a folder called meshes. + +.. code-block:: xml + + + + + + + + + + +* The meshes can be imported in a number of different formats. + STL is fairly common, but the engine also supports DAE, which can have its own color data, meaning you don't have to specify the color/material. + Often these are in separate files. + These meshes reference the ``.tif`` files also in the meshes folder. +* Meshes can also be sized using relative scaling parameters or a bounding box size. +* We could have also referred to meshes in a completely different package. + +There you have it. +A R2D2-like URDF model. Now you can continue on to the next step, :doc:`making it move `. \ No newline at end of file diff --git a/source/Concepts/Intermediate/About-Buffer-Backends.rst b/source/Concepts/Intermediate/About-Buffer-Backends.rst index 9b8bfbe6ccd..2c73ab5de40 100644 --- a/source/Concepts/Intermediate/About-Buffer-Backends.rst +++ b/source/Concepts/Intermediate/About-Buffer-Backends.rst @@ -26,10 +26,10 @@ Why a new type is needed ROS 2 messages already have two complementary mechanisms for reducing copies: -* :doc:`Intra-process communication <../../Tutorials/Demos/Intra-Process-Communication>` +* :doc:`Intra-process communication <../../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>` avoids copies between publishers and subscriptions in the same process by passing ``std::unique_ptr`` ownership. -* :doc:`Loaned messages <../../How-To-Guides/Configure-ZeroCopy-loaned-messages>` +* :doc:`Loaned messages <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages>` let the RMW manage message memory to enable shared-memory transport between processes, for message types the underlying middleware can lay out. @@ -168,7 +168,7 @@ Relationship to other ROS 2 mechanisms * ``rosidl::Buffer`` is orthogonal to :doc:`intra-process communication <../../Tutorials/Demos/Intra-Process-Communication>` and to - :doc:`loaned messages <../../How-To-Guides/Configure-ZeroCopy-loaned-messages>`. + :doc:`loaned messages <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages>`. A backend may implement either, both, or neither for a given pub/sub pair; the decision lives entirely inside the backend. * Whether a given publisher/subscriber pair can actually use a non-CPU diff --git a/source/Developer-Tools.rst b/source/Developer-Tools.rst index 07771aed1cb..613669aa6f2 100644 --- a/source/Developer-Tools.rst +++ b/source/Developer-Tools.rst @@ -8,8 +8,18 @@ PLACEHOLDER :maxdepth: 3 Developer-Tools/About-introspection-and-analysis + Developer-Tools/About-Debugging + Developer-Tools/About-Build Developer-Tools/About-visualization + Developer-Tools/About-package-documentation Developer-Tools/About-Launch Developer-Tools/About-testing - Developer-Tools/About-Debugging - Developer-Tools/About-Build \ No newline at end of file + + +* Introspection +* Analysis +* Node management +* Debugging +* Builds +* Visualization +* Package documentation \ No newline at end of file diff --git a/source/Developer-Tools/About-Build.rst b/source/Developer-Tools/About-Build.rst index 52e2b48287e..28d4b6bbece 100644 --- a/source/Developer-Tools/About-Build.rst +++ b/source/Developer-Tools/About-Build.rst @@ -26,7 +26,6 @@ PLACEHOLDER Build/Package-Docs Build/Using-Python-Packages Build/Developing-a-ROS-2-Package - Build/Documenting-a-ROS-2-Package Build/Releasing/Releasing-a-Package Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/Building-Realtime-rt_preempt-kernel-for-ROS-2 Build/Building-ROS2-Package-with-eclipse-2021-06/Building-ROS2-Package-with-eclipse-2021-06 diff --git a/source/Developer-Tools/About-package-documentation.rst b/source/Developer-Tools/About-package-documentation.rst new file mode 100644 index 00000000000..27dfb22b13f --- /dev/null +++ b/source/Developer-Tools/About-package-documentation.rst @@ -0,0 +1,10 @@ +Package documentation +===================== + + +PLACEHOLDER + +.. toctree:: + :maxdepth: 3 + + Package-documentation/Documenting-a-ROS-2-Package \ No newline at end of file diff --git a/source/Developer-Tools/Build/Package-Docs.rst b/source/Developer-Tools/Build/Package-Docs.rst index c872c20cc2f..ab998e2e8e2 100644 --- a/source/Developer-Tools/Build/Package-Docs.rst +++ b/source/Developer-Tools/Build/Package-Docs.rst @@ -1,40 +1,40 @@ -.. redirect-from:: - - Package-Docs -Package Docs -============ - -ROS package documentation, that is to say documentation for specific packages you install via apt or some other tool, can be found in multiple places. -Here is a brief list of where to look for specific ROS package documentation. - - -* Most ROS 2 packages have their package level documentation `included in this index page `__. -* All ROS 2 package's documentation is hosted alongside its information on the `ROS Index `_. - Searching for packages on ROS Index will yield their information such as released distributions, ``README.md`` files, URLs, and other important metadata. - -Larger Packages ---------------- - -Larger packages like MoveIt, Nav2, and microROS, are given their own domain or subdomain on ros.org. -Here is a short list. - -* `MoveIt `__ -* `Navigation2 `__ -* `Control `__ -* `microROS (embedded systems) `__ - -API Documentation ------------------ - -You can find the API level documentation for the ROS client libraries in the {DISTRO_TITLE} distribution using the links below: - -* `rclcpp - C++ client library `_ -* `rclcpp_lifecycle - C++ lifecycle library `_ -* `rclcpp_components - C++ components library `_ -* `rclcpp_action - C++ actions library `_ - -Adding Your Package to docs.ros.org ------------------------------------ - -All released ROS 2 packages are automatically added to docs.ros.org and `ROS Index `_. -If you would like to enable or configure your own package please see: :doc:`Documenting-a-ROS-2-Package`. \ No newline at end of file +.. redirect-from:: + + Package-Docs +Package Docs +============ + +ROS package documentation, that is to say documentation for specific packages you install via apt or some other tool, can be found in multiple places. +Here is a brief list of where to look for specific ROS package documentation. + + +* Most ROS 2 packages have their package level documentation `included in this index page `__. +* All ROS 2 package's documentation is hosted alongside its information on the `ROS Index `_. + Searching for packages on ROS Index will yield their information such as released distributions, ``README.md`` files, URLs, and other important metadata. + +Larger Packages +--------------- + +Larger packages like MoveIt, Nav2, and microROS, are given their own domain or subdomain on ros.org. +Here is a short list. + +* `MoveIt `__ +* `Navigation2 `__ +* `Control `__ +* `microROS (embedded systems) `__ + +API Documentation +----------------- + +You can find the API level documentation for the ROS client libraries in the {DISTRO_TITLE} distribution using the links below: + +* `rclcpp - C++ client library `_ +* `rclcpp_lifecycle - C++ lifecycle library `_ +* `rclcpp_components - C++ components library `_ +* `rclcpp_action - C++ actions library `_ + +Adding Your Package to docs.ros.org +----------------------------------- + +All released ROS 2 packages are automatically added to docs.ros.org and `ROS Index `_. +If you would like to enable or configure your own package please see: :doc:`../Package-documentation/Documenting-a-ROS-2-Package`. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst b/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst index 3b109e00d73..66ec3db77f1 100644 --- a/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst +++ b/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst @@ -1,803 +1,803 @@ -.. redirect-from:: - - FastDDS-Configuration - Tutorials/FastDDS-Configuration/FastDDS-Configuration - Tutorials/Advanced/FastDDS-Configuration - -Unlocking the potential of Fast DDS middleware [community-contributed] -====================================================================== - -**Goal:** This tutorial will show how to use the extended configuration capabilities of Fast DDS in ROS 2. - -**Tutorial level:** Advanced - -**Time:** 20 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -The interface between the ROS 2 stack and *Fast DDS* is provided by the ROS 2 middleware implementation `rmw_fastrtps `_. -This implementation is available in all ROS 2 distributions, both from binaries and from sources. - -ROS 2 RMW only allows for the configuration of certain middleware QoS -(see :doc:`ROS 2 QoS policies <../../ROS-Framework/topics/About-Quality-of-Service-Settings>`). -However, ``rmw_fastrtps`` offers extended configuration capabilities to take full advantage of the features in *Fast DDS*. -This tutorial will guide you through a series of examples explaining how to use XML files to unlock this extended configuration. - -In order to get more information about using *Fast DDS* on ROS 2, please check the `following documentation `__. - - -Prerequisites -------------- - -This tutorial assumes that you know how to :doc:`create a package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`. -It also assumes you know how to write a :doc:`simple publisher and subscriber <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` and a :doc:`simple service and client <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`. -Although the examples are implemented in C++, the same concepts apply to Python packages. - - -Mixing synchronous and asynchronous publications in the same node ------------------------------------------------------------------ - -In this first example, a node with two publishers, one of them with synchronous publication mode and the other one with asynchronous publication mode, will be created. - -``rmw_fastrtps`` uses synchronous publication mode by default. - -With synchronous publication mode the data is sent directly within the context of the user thread. -This entails that any blocking call occurring during the write operation would block the user thread, thus preventing the application from continuing its operation. -However, this mode typically yields higher throughput rates at lower latencies, since there is no notification nor context switching between threads. - -On the other hand, with asynchronous publication mode, each time the publisher invokes the write operation, the data is copied into a queue, -a background thread (asynchronous thread) is notified about the addition to the queue, and control of the thread is returned to the user before the data is actually sent. -The background thread is in charge of consuming the queue and sending the data to every matched reader. - -Create the node with the publishers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -First, create a new package named ``sync_async_node_example_cpp`` on a new workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ md \ros2_ws\src - $ cd \ros2_ws\src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp - - -Then, add a file named ``src/sync_async_writer.cpp`` to the package, with the following content. -Note that the synchronous publisher will be publishing on topic ``sync_topic``, while the asynchronous one will be publishing on topic ``async_topic``. - -.. code-block:: C++ - - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - - class SyncAsyncPublisher : public rclcpp::Node - { - public: - SyncAsyncPublisher() - : Node("sync_async_publisher"), count_(0) - { - // Create the synchronous publisher on topic 'sync_topic' - sync_publisher_ = this->create_publisher("sync_topic", 10); - - // Create the asynchronous publisher on topic 'async_topic' - async_publisher_ = this->create_publisher("async_topic", 10); - - // Actions to run every time the timer expires - auto timer_callback = [this](){ - - // Create a new message to be sent - auto sync_message = std_msgs::msg::String(); - sync_message.data = "SYNC: Hello, world! " + std::to_string(count_); - - // Log the message to the console to show progress - RCLCPP_INFO(this->get_logger(), "Synchronously publishing: '%s'", sync_message.data.c_str()); - - // Publish the message using the synchronous publisher - sync_publisher_->publish(sync_message); - - // Create a new message to be sent - auto async_message = std_msgs::msg::String(); - async_message.data = "ASYNC: Hello, world! " + std::to_string(count_); - - // Log the message to the console to show progress - RCLCPP_INFO(this->get_logger(), "Asynchronously publishing: '%s'", async_message.data.c_str()); - - // Publish the message using the asynchronous publisher - async_publisher_->publish(async_message); - - // Prepare the count for the next message - count_++; - }; - - // This timer will trigger the publication of new data every half a second - timer_ = this->create_wall_timer(500ms, timer_callback); - } - - private: - // This timer will trigger the publication of new data every half a second - rclcpp::TimerBase::SharedPtr timer_; - - // A publisher that publishes asynchronously - rclcpp::Publisher::SharedPtr async_publisher_; - - // A publisher that publishes synchronously - rclcpp::Publisher::SharedPtr sync_publisher_; - - // Number of messages sent so far - size_t count_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -Now open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncWriter`` so you can run your node using ``ros2 run``: - -.. code-block:: cmake - - add_executable(SyncAsyncWriter src/sync_async_writer.cpp) - target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: cmake - - install(TARGETS - SyncAsyncWriter - DESTINATION lib/${PROJECT_NAME}) - -You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(sync_async_node_example_cpp) - - # Default to C++14 - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 14) - endif() - - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - - add_executable(SyncAsyncWriter src/sync_async_writer.cpp) - target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - SyncAsyncWriter - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - -If this node is built and run now, both publishers will behave the same, publishing asynchronously in both topics, because this is the default publication mode. -The default publication mode configuration can be changed in runtime during the node launching, using an XML file. - -Create the XML file with the profile configuration -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Create a file with name ``SyncAsync.xml`` and the following content: - -.. code-block:: XML - - - - - - - DYNAMIC - - - - - DYNAMIC - - - - - DYNAMIC - - - SYNCHRONOUS - - - - - - - DYNAMIC - - - ASYNCHRONOUS - - - - - - -Note that several profiles for publisher and subscriber are defined. -Two default profiles which are defined setting the ``is_default_profile`` to ``true``, and two profiles with names that coincide with those of the previously defined topics: ``sync_topic`` and another one for ``async_topic``. -These last two profiles set the publication mode to ``SYNCHRONOUS`` or ``ASYNCHRONOUS`` accordingly. -Note also that all profiles specify a ``historyMemoryPolicy`` value, which is needed for the example to work, and the reason will be explained later on this tutorial. - -Execute the publisher node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -You will need to export the following environment variables for the XML to be loaded: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: macOS - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - -Finally, ensure you have sourced your setup files and run the node: - -.. code-block:: console - - $ source install/setup.bash - $ ros2 run sync_async_node_example_cpp SyncAsyncWriter - [INFO] [1612972049.994630332] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 0' - [INFO] [1612972049.995097767] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 0' - [INFO] [1612972050.494478706] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 1' - [INFO] [1612972050.494664334] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 1' - [INFO] [1612972050.994368474] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 2' - [INFO] [1612972050.994549851] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 2' - -Now you have a synchronous publisher and an asynchronous publisher running inside the same node. - - -Create a node with the subscribers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Next, a new node with the subscribers that will listen to the ``sync_topic`` and ``async_topic`` publications is going to be created. -In a new source file named ``src/sync_async_reader.cpp`` write the following content: - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - class SyncAsyncSubscriber : public rclcpp::Node - { - public: - - SyncAsyncSubscriber() - : Node("sync_async_subscriber") - { - // Lambda function to run every time a new message is received - auto topic_callback = [this](const std_msgs::msg::String & msg){ - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); - }; - - // Create the synchronous subscriber on topic 'sync_topic' - // and tie it to the topic_callback - sync_subscription_ = this->create_subscription( - "sync_topic", 10, topic_callback); - - // Create the asynchronous subscriber on topic 'async_topic' - // and tie it to the topic_callback - async_subscription_ = this->create_subscription( - "async_topic", 10, topic_callback); - } - - private: - - // A subscriber that listens to topic 'sync_topic' - rclcpp::Subscription::SharedPtr sync_subscription_; - - // A subscriber that listens to topic 'async_topic' - rclcpp::Subscription::SharedPtr async_subscription_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - -Open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncReader`` under the previous ``SyncAsyncWriter``: - -.. code-block:: cmake - - add_executable(SyncAsyncReader src/sync_async_reader.cpp) - target_link_libraries(SyncAsyncReader PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - SyncAsyncReader - DESTINATION lib/${PROJECT_NAME}) - - -Execute the subscriber node -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -With the publisher node running in one terminal, open another one and export the required environment variables for the XML to be loaded: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: macOS - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml - -Finally, ensure you have sourced your setup files and run the node: - -.. code-block:: console - - $ source install/setup.bash - $ ros2 run sync_async_node_example_cpp SyncAsyncReader - [INFO] [1612972054.495429090] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 10' - [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' - [INFO] [1612972055.495453494] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 11' - [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' - [INFO] [1612972056.495534818] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 12' - [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' - - -Analysis of the example -^^^^^^^^^^^^^^^^^^^^^^^ - -Configuration profiles XML -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The XML file defines several configurations for publishers and subscribers. -You can have a default publisher configuration profile and several topic-specific publisher profiles. -The only requirement is that all publisher profiles have a different name and that there is only a single default profile. -The same goes for subscribers. - -In order to define a configuration for a specific topic, just name the profile after the the ROS 2 topic name (like ``/sync_topic`` and ``/async_topic`` in the example), -and ``rmw_fastrtps`` will apply this profile to all publishers and subscribers for that topic. -The default configuration profile is identified by the attribute ``is_default_profile`` set to ``true``, and acts as a fallback profile when there is no other one with a name matching the topic name. - -The environment variable ``FASTDDS_DEFAULT_PROFILES_FILE`` is used to inform *Fast DDS* the path to the XML file with the configuration profiles to load. - -RMW_FASTRTPS_USE_QOS_FROM_XML -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Among all the configurable attributes, ``rmw_fastrtps`` treats ``publishMode`` and ``historyMemoryPolicy`` differently. -By default, these values are set to ``ASYNCHRONOUS`` and ``PREALLOCATED_WITH_REALLOC`` within the ``rmw_fastrtps`` implementation, and the values set on the XML file are ignored. -In order to use the values in the XML file, the environment variable ``RMW_FASTRTPS_USE_QOS_FROM_XML`` must be set to ``1``. - -However, this entails **another caveat**: If ``RMW_FASTRTPS_USE_QOS_FROM_XML`` is set, but the XML file does not define -``publishMode`` or ``historyMemoryPolicy``, these attributes take the *Fast DDS* default value instead of the ``rmw_fastrtps`` default value. -This is important, especially for ``historyMemoryPolicy``, because the *Fast DDS* default value is ``PREALLOCATED`` which does not work with ROS2 topic data types. -Therefore, in the example, a valid value for this policy has been explicitly set (``DYNAMIC``). - - -Prioritization of rmw_qos_profile_t -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -ROS 2 QoS contained in `rmw_qos_profile_t `_ are always honored, unless set to ``*_SYSTEM_DEFAULT``. -In that case, XML values (or *Fast DDS* default values in the absence of XML ones) are applied. -This means that if any QoS in ``rmw_qos_profile_t`` is set to something other than ``*_SYSTEM_DEFAULT``, the corresponding value in the XML is ignored. - - -Using other FastDDS capabilities with XML ------------------------------------------ - -Although we have created a node with two publishers with different configuration, it is not easy to check that they are behaving differently. -Now that the basics of XML profiles have been covered, let us use them to configure something which has some visual effect on the nodes. -Specifically, a maximum number of matching subscribers on one of the publishers and a partition definition on the other will be set. -Note that these are only very simple examples among all the configuration attributes that can be tuned on ``rmw_fastrtps`` through XML files. -Please refer to `*Fast DDS* documentation `__ to see the whole list of attributes that can be configured through XML files. - -Limiting the number of matching subscribers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Add a maximum number of matched subscribers to the ``/async_topic`` publisher profile. -It should look like this: - -.. code-block:: XML - - - - DYNAMIC - - - ASYNCHRONOUS - - - - 0 - 1 - 1 - - - -The number of matching subscribers is being limited to one. - -Now open three terminals and do not forget to source the setup files and to set the required environment variables. -On the first terminal run the publisher node, and the subscriber node on the other two. -You should see that only the first subscriber node receives the messages from both topics. -The second one could not complete the matching process in the ``/async_topic`` because the publisher prevented it, as it had already reached its maximum of matched publishers. -Consequently, only the messages from the ``/sync_topic`` are going to be received in this third terminal: - -.. code-block:: console - - [INFO] [1613127657.088860890] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 18' - [INFO] [1613127657.588896594] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 19' - [INFO] [1613127658.088849401] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 20' - - -Using partitions within the topic -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The partitions feature can be used to control which publishers and subscribers exchange information within the same topic. - -Partitions introduce a logical entity isolation level concept inside the physical isolation induced by a Domain ID. -For a publisher to communicate with a subscriber, they have to belong at least to one common partition. -Partitions represent another level to separate publishers and subscribers beyond domain and topic. -Unlike domain and topic, an endpoint can belong to several partitions at the same time. -For certain data to be shared over different domains or topics, there must be a different publisher for each, sharing its own history of changes. -However, a single publisher can share the same data sample over different partitions using a single topic data change, thus reducing network overload. - -Let us change the ``/sync_topic`` publisher to partition ``part1`` and create a new ``/sync_topic`` subscriber which uses partition ``part2``. -Their profiles should now look like this: - -.. code-block:: XML - - - - DYNAMIC - - - SYNCHRONOUS - - - - part1 - - - - - - - - DYNAMIC - - - - part2 - - - - - -Open two terminals. -Do not forget to source the setup files and to set the required environment variables. -On the first terminal run the publisher node, and the subscriber node on the other one. -You should see that only the ``/async_topic`` messages are reaching the subscriber. -The ``/sync_topic`` subscriber is not receiving the data as it is in a different partition from the corresponding publisher. - -.. code-block:: console - - [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' - [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' - [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' - - -Configuring a service and a client ----------------------------------- - -Services and clients have a publisher and a subscriber each, that communicate through two different topics. -For example, for a service named ``ping`` there is: - -* A service subscriber listening to requests on ``/rq/ping``. -* A service publisher sending responses on ``/rr/ping``. -* A client publisher sending requests on ``/rq/ping``. -* A client subscriber listening to responses on ``/rr/ping``. - -Although you can use these topic names to set the configuration profiles on the XML, sometimes you may wish to apply the same profile to all services or clients on a node. -Instead of copying the same profile with all topic names generated for all services, you can just create a publisher and subscriber profile pair named ``service``. -The same can be done for clients creating a pair named ``client``. - - -Create the nodes with the service and client -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Start creating the node with the service. -Add a new source file named ``src/ping_service.cpp`` on your package with the following content: - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - #include "example_interfaces/srv/trigger.hpp" - - /** - * Service action: responds with success=true and prints the request on the console - */ - void ping(const std::shared_ptr request, - std::shared_ptr response) - { - // The request data is unused - (void) request; - - // Build the response - response->success = true; - - // Log to the console - RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Incoming request"); - RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Sending back response"); - } - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - // Create the node and the service - std::shared_ptr node = rclcpp::Node::make_shared("ping_server"); - rclcpp::Service::SharedPtr service = - node->create_service("ping", &ping); - - // Log that the service is ready - RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Ready to serve."); - - // run the node - rclcpp::spin(node); - rclcpp::shutdown(); - } - -Create the client in a file named ``src/ping_client.cpp`` with the following content: - -.. code-block:: C++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "example_interfaces/srv/trigger.hpp" - - using namespace std::chrono_literals; - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - // Create the node and the client - std::shared_ptr node = rclcpp::Node::make_shared("ping_client"); - rclcpp::Client::SharedPtr client = - node->create_client("ping"); - - // Create a request - auto request = std::make_shared(); - - // Wait for the service to be available - while (!client->wait_for_service(1s)) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Interrupted while waiting for the service. Exiting."); - return 0; - } - RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Service not available, waiting again..."); - } - - // Now that the service is available, send the request - RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Sending request"); - auto result = client->async_send_request(request); - - // Wait for the result and log it to the console - if (rclcpp::spin_until_future_complete(node, result) == - rclcpp::FutureReturnCode::SUCCESS) - { - RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Response received"); - } else { - RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Failed to call service ping"); - } - - rclcpp::shutdown(); - return 0; - } - -Open the ``CMakeLists.txt`` file and add two new executables ``ping_service`` and ``ping_client``: - -.. code-block:: cmake - - find_package(example_interfaces REQUIRED) - - add_executable(ping_service src/ping_service.cpp) - target_link_libraries(ping_service PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) - - add_executable(ping_client src/ping_client.cpp) - target_link_libraries(ping_client PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) - - install(TARGETS - ping_service - DESTINATION lib/${PROJECT_NAME}) - - install(TARGETS - ping_client - DESTINATION lib/${PROJECT_NAME}) - -Finally, build the package. - - -Create the XML profiles for the service and client -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Create a file with name ``ping.xml`` with the following content: - -.. code-block:: XML - - - - - - - DYNAMIC - - - - - DYNAMIC - - - - - DYNAMIC - - - SYNCHRONOUS - - - - - - - DYNAMIC - - - ASYNCHRONOUS - - - - - - - -This configuration file sets the publication mode to ``SYNCHRONOUS`` on the service and to ``ASYNCHRONOUS`` on the client. -Note that we are only defining the publisher profiles for both the service and the client, but subscriber profiles could be provided too. - - -Execute the nodes -^^^^^^^^^^^^^^^^^ - -Open two terminals and source the setup files on each one. -Then set the required environment variables for the XML to be loaded: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml - - .. group-tab:: macOS - - .. code-block:: console - - $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml - - .. group-tab:: Windows - - .. code-block:: console - - $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp - $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 - $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml - - -On the first terminal run the service node. -You should see the service waiting for requests: - -.. code-block:: console - - $ ros2 run sync_async_node_example_cpp ping_service - [INFO] [1612977403.805799037] [ping_server]: Ready to serve. - -On the second terminal, run the client node. -You should see the client sending the request and receiving the response: - - -.. code-block:: console - - $ ros2 run sync_async_node_example_cpp ping_client - [INFO] [1612977404.805799037] [ping_client]: Sending request - [INFO] [1612977404.825473835] [ping_client]: Response received - -At the same time, the output in the server console has been updated: - -.. code-block:: console - - [INFO] [1612977403.805799037] [ping_server]: Ready to serve. - [INFO] [1612977404.807314904] [ping_server]: Incoming request +.. redirect-from:: + + FastDDS-Configuration + Tutorials/FastDDS-Configuration/FastDDS-Configuration + Tutorials/Advanced/FastDDS-Configuration + +Unlocking the potential of Fast DDS middleware [community-contributed] +====================================================================== + +**Goal:** This tutorial will show how to use the extended configuration capabilities of Fast DDS in ROS 2. + +**Tutorial level:** Advanced + +**Time:** 20 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +The interface between the ROS 2 stack and *Fast DDS* is provided by the ROS 2 middleware implementation `rmw_fastrtps `_. +This implementation is available in all ROS 2 distributions, both from binaries and from sources. + +ROS 2 RMW only allows for the configuration of certain middleware QoS +(see :doc:`ROS 2 QoS policies <../../ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings>`). +However, ``rmw_fastrtps`` offers extended configuration capabilities to take full advantage of the features in *Fast DDS*. +This tutorial will guide you through a series of examples explaining how to use XML files to unlock this extended configuration. + +In order to get more information about using *Fast DDS* on ROS 2, please check the `following documentation `__. + + +Prerequisites +------------- + +This tutorial assumes that you know how to :doc:`create a package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`. +It also assumes you know how to write a :doc:`simple publisher and subscriber <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` and a :doc:`simple service and client <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`. +Although the examples are implemented in C++, the same concepts apply to Python packages. + + +Mixing synchronous and asynchronous publications in the same node +----------------------------------------------------------------- + +In this first example, a node with two publishers, one of them with synchronous publication mode and the other one with asynchronous publication mode, will be created. + +``rmw_fastrtps`` uses synchronous publication mode by default. + +With synchronous publication mode the data is sent directly within the context of the user thread. +This entails that any blocking call occurring during the write operation would block the user thread, thus preventing the application from continuing its operation. +However, this mode typically yields higher throughput rates at lower latencies, since there is no notification nor context switching between threads. + +On the other hand, with asynchronous publication mode, each time the publisher invokes the write operation, the data is copied into a queue, +a background thread (asynchronous thread) is notified about the addition to the queue, and control of the thread is returned to the user before the data is actually sent. +The background thread is in charge of consuming the queue and sending the data to every matched reader. + +Create the node with the publishers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +First, create a new package named ``sync_async_node_example_cpp`` on a new workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ md \ros2_ws\src + $ cd \ros2_ws\src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies rclcpp std_msgs -- sync_async_node_example_cpp + + +Then, add a file named ``src/sync_async_writer.cpp`` to the package, with the following content. +Note that the synchronous publisher will be publishing on topic ``sync_topic``, while the asynchronous one will be publishing on topic ``async_topic``. + +.. code-block:: C++ + + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + + class SyncAsyncPublisher : public rclcpp::Node + { + public: + SyncAsyncPublisher() + : Node("sync_async_publisher"), count_(0) + { + // Create the synchronous publisher on topic 'sync_topic' + sync_publisher_ = this->create_publisher("sync_topic", 10); + + // Create the asynchronous publisher on topic 'async_topic' + async_publisher_ = this->create_publisher("async_topic", 10); + + // Actions to run every time the timer expires + auto timer_callback = [this](){ + + // Create a new message to be sent + auto sync_message = std_msgs::msg::String(); + sync_message.data = "SYNC: Hello, world! " + std::to_string(count_); + + // Log the message to the console to show progress + RCLCPP_INFO(this->get_logger(), "Synchronously publishing: '%s'", sync_message.data.c_str()); + + // Publish the message using the synchronous publisher + sync_publisher_->publish(sync_message); + + // Create a new message to be sent + auto async_message = std_msgs::msg::String(); + async_message.data = "ASYNC: Hello, world! " + std::to_string(count_); + + // Log the message to the console to show progress + RCLCPP_INFO(this->get_logger(), "Asynchronously publishing: '%s'", async_message.data.c_str()); + + // Publish the message using the asynchronous publisher + async_publisher_->publish(async_message); + + // Prepare the count for the next message + count_++; + }; + + // This timer will trigger the publication of new data every half a second + timer_ = this->create_wall_timer(500ms, timer_callback); + } + + private: + // This timer will trigger the publication of new data every half a second + rclcpp::TimerBase::SharedPtr timer_; + + // A publisher that publishes asynchronously + rclcpp::Publisher::SharedPtr async_publisher_; + + // A publisher that publishes synchronously + rclcpp::Publisher::SharedPtr sync_publisher_; + + // Number of messages sent so far + size_t count_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +Now open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncWriter`` so you can run your node using ``ros2 run``: + +.. code-block:: cmake + + add_executable(SyncAsyncWriter src/sync_async_writer.cpp) + target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: cmake + + install(TARGETS + SyncAsyncWriter + DESTINATION lib/${PROJECT_NAME}) + +You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(sync_async_node_example_cpp) + + # Default to C++14 + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 14) + endif() + + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + + add_executable(SyncAsyncWriter src/sync_async_writer.cpp) + target_link_libraries(SyncAsyncWriter PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + SyncAsyncWriter + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + +If this node is built and run now, both publishers will behave the same, publishing asynchronously in both topics, because this is the default publication mode. +The default publication mode configuration can be changed in runtime during the node launching, using an XML file. + +Create the XML file with the profile configuration +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Create a file with name ``SyncAsync.xml`` and the following content: + +.. code-block:: XML + + + + + + + DYNAMIC + + + + + DYNAMIC + + + + + DYNAMIC + + + SYNCHRONOUS + + + + + + + DYNAMIC + + + ASYNCHRONOUS + + + + + + +Note that several profiles for publisher and subscriber are defined. +Two default profiles which are defined setting the ``is_default_profile`` to ``true``, and two profiles with names that coincide with those of the previously defined topics: ``sync_topic`` and another one for ``async_topic``. +These last two profiles set the publication mode to ``SYNCHRONOUS`` or ``ASYNCHRONOUS`` accordingly. +Note also that all profiles specify a ``historyMemoryPolicy`` value, which is needed for the example to work, and the reason will be explained later on this tutorial. + +Execute the publisher node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +You will need to export the following environment variables for the XML to be loaded: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: macOS + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + +Finally, ensure you have sourced your setup files and run the node: + +.. code-block:: console + + $ source install/setup.bash + $ ros2 run sync_async_node_example_cpp SyncAsyncWriter + [INFO] [1612972049.994630332] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 0' + [INFO] [1612972049.995097767] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 0' + [INFO] [1612972050.494478706] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 1' + [INFO] [1612972050.494664334] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 1' + [INFO] [1612972050.994368474] [sync_async_publisher]: Synchronously publishing: 'SYNC: Hello, world! 2' + [INFO] [1612972050.994549851] [sync_async_publisher]: Asynchronously publishing: 'ASYNC: Hello, world! 2' + +Now you have a synchronous publisher and an asynchronous publisher running inside the same node. + + +Create a node with the subscribers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Next, a new node with the subscribers that will listen to the ``sync_topic`` and ``async_topic`` publications is going to be created. +In a new source file named ``src/sync_async_reader.cpp`` write the following content: + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + class SyncAsyncSubscriber : public rclcpp::Node + { + public: + + SyncAsyncSubscriber() + : Node("sync_async_subscriber") + { + // Lambda function to run every time a new message is received + auto topic_callback = [this](const std_msgs::msg::String & msg){ + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); + }; + + // Create the synchronous subscriber on topic 'sync_topic' + // and tie it to the topic_callback + sync_subscription_ = this->create_subscription( + "sync_topic", 10, topic_callback); + + // Create the asynchronous subscriber on topic 'async_topic' + // and tie it to the topic_callback + async_subscription_ = this->create_subscription( + "async_topic", 10, topic_callback); + } + + private: + + // A subscriber that listens to topic 'sync_topic' + rclcpp::Subscription::SharedPtr sync_subscription_; + + // A subscriber that listens to topic 'async_topic' + rclcpp::Subscription::SharedPtr async_subscription_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + +Open the ``CMakeLists.txt`` file and add a new executable and name it ``SyncAsyncReader`` under the previous ``SyncAsyncWriter``: + +.. code-block:: cmake + + add_executable(SyncAsyncReader src/sync_async_reader.cpp) + target_link_libraries(SyncAsyncReader PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + SyncAsyncReader + DESTINATION lib/${PROJECT_NAME}) + + +Execute the subscriber node +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +With the publisher node running in one terminal, open another one and export the required environment variables for the XML to be loaded: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: macOS + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/SyncAsync.xml + +Finally, ensure you have sourced your setup files and run the node: + +.. code-block:: console + + $ source install/setup.bash + $ ros2 run sync_async_node_example_cpp SyncAsyncReader + [INFO] [1612972054.495429090] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 10' + [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' + [INFO] [1612972055.495453494] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 11' + [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' + [INFO] [1612972056.495534818] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 12' + [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' + + +Analysis of the example +^^^^^^^^^^^^^^^^^^^^^^^ + +Configuration profiles XML +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The XML file defines several configurations for publishers and subscribers. +You can have a default publisher configuration profile and several topic-specific publisher profiles. +The only requirement is that all publisher profiles have a different name and that there is only a single default profile. +The same goes for subscribers. + +In order to define a configuration for a specific topic, just name the profile after the the ROS 2 topic name (like ``/sync_topic`` and ``/async_topic`` in the example), +and ``rmw_fastrtps`` will apply this profile to all publishers and subscribers for that topic. +The default configuration profile is identified by the attribute ``is_default_profile`` set to ``true``, and acts as a fallback profile when there is no other one with a name matching the topic name. + +The environment variable ``FASTDDS_DEFAULT_PROFILES_FILE`` is used to inform *Fast DDS* the path to the XML file with the configuration profiles to load. + +RMW_FASTRTPS_USE_QOS_FROM_XML +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Among all the configurable attributes, ``rmw_fastrtps`` treats ``publishMode`` and ``historyMemoryPolicy`` differently. +By default, these values are set to ``ASYNCHRONOUS`` and ``PREALLOCATED_WITH_REALLOC`` within the ``rmw_fastrtps`` implementation, and the values set on the XML file are ignored. +In order to use the values in the XML file, the environment variable ``RMW_FASTRTPS_USE_QOS_FROM_XML`` must be set to ``1``. + +However, this entails **another caveat**: If ``RMW_FASTRTPS_USE_QOS_FROM_XML`` is set, but the XML file does not define +``publishMode`` or ``historyMemoryPolicy``, these attributes take the *Fast DDS* default value instead of the ``rmw_fastrtps`` default value. +This is important, especially for ``historyMemoryPolicy``, because the *Fast DDS* default value is ``PREALLOCATED`` which does not work with ROS2 topic data types. +Therefore, in the example, a valid value for this policy has been explicitly set (``DYNAMIC``). + + +Prioritization of rmw_qos_profile_t +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ROS 2 QoS contained in `rmw_qos_profile_t `_ are always honored, unless set to ``*_SYSTEM_DEFAULT``. +In that case, XML values (or *Fast DDS* default values in the absence of XML ones) are applied. +This means that if any QoS in ``rmw_qos_profile_t`` is set to something other than ``*_SYSTEM_DEFAULT``, the corresponding value in the XML is ignored. + + +Using other FastDDS capabilities with XML +----------------------------------------- + +Although we have created a node with two publishers with different configuration, it is not easy to check that they are behaving differently. +Now that the basics of XML profiles have been covered, let us use them to configure something which has some visual effect on the nodes. +Specifically, a maximum number of matching subscribers on one of the publishers and a partition definition on the other will be set. +Note that these are only very simple examples among all the configuration attributes that can be tuned on ``rmw_fastrtps`` through XML files. +Please refer to `*Fast DDS* documentation `__ to see the whole list of attributes that can be configured through XML files. + +Limiting the number of matching subscribers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Add a maximum number of matched subscribers to the ``/async_topic`` publisher profile. +It should look like this: + +.. code-block:: XML + + + + DYNAMIC + + + ASYNCHRONOUS + + + + 0 + 1 + 1 + + + +The number of matching subscribers is being limited to one. + +Now open three terminals and do not forget to source the setup files and to set the required environment variables. +On the first terminal run the publisher node, and the subscriber node on the other two. +You should see that only the first subscriber node receives the messages from both topics. +The second one could not complete the matching process in the ``/async_topic`` because the publisher prevented it, as it had already reached its maximum of matched publishers. +Consequently, only the messages from the ``/sync_topic`` are going to be received in this third terminal: + +.. code-block:: console + + [INFO] [1613127657.088860890] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 18' + [INFO] [1613127657.588896594] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 19' + [INFO] [1613127658.088849401] [sync_async_subscriber]: I heard: 'SYNC: Hello, world! 20' + + +Using partitions within the topic +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The partitions feature can be used to control which publishers and subscribers exchange information within the same topic. + +Partitions introduce a logical entity isolation level concept inside the physical isolation induced by a Domain ID. +For a publisher to communicate with a subscriber, they have to belong at least to one common partition. +Partitions represent another level to separate publishers and subscribers beyond domain and topic. +Unlike domain and topic, an endpoint can belong to several partitions at the same time. +For certain data to be shared over different domains or topics, there must be a different publisher for each, sharing its own history of changes. +However, a single publisher can share the same data sample over different partitions using a single topic data change, thus reducing network overload. + +Let us change the ``/sync_topic`` publisher to partition ``part1`` and create a new ``/sync_topic`` subscriber which uses partition ``part2``. +Their profiles should now look like this: + +.. code-block:: XML + + + + DYNAMIC + + + SYNCHRONOUS + + + + part1 + + + + + + + + DYNAMIC + + + + part2 + + + + + +Open two terminals. +Do not forget to source the setup files and to set the required environment variables. +On the first terminal run the publisher node, and the subscriber node on the other one. +You should see that only the ``/async_topic`` messages are reaching the subscriber. +The ``/sync_topic`` subscriber is not receiving the data as it is in a different partition from the corresponding publisher. + +.. code-block:: console + + [INFO] [1612972054.995410057] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 10' + [INFO] [1612972055.995396561] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 11' + [INFO] [1612972056.995473953] [sync_async_subscriber]: I heard: 'ASYNC: Hello, world! 12' + + +Configuring a service and a client +---------------------------------- + +Services and clients have a publisher and a subscriber each, that communicate through two different topics. +For example, for a service named ``ping`` there is: + +* A service subscriber listening to requests on ``/rq/ping``. +* A service publisher sending responses on ``/rr/ping``. +* A client publisher sending requests on ``/rq/ping``. +* A client subscriber listening to responses on ``/rr/ping``. + +Although you can use these topic names to set the configuration profiles on the XML, sometimes you may wish to apply the same profile to all services or clients on a node. +Instead of copying the same profile with all topic names generated for all services, you can just create a publisher and subscriber profile pair named ``service``. +The same can be done for clients creating a pair named ``client``. + + +Create the nodes with the service and client +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Start creating the node with the service. +Add a new source file named ``src/ping_service.cpp`` on your package with the following content: + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + #include "example_interfaces/srv/trigger.hpp" + + /** + * Service action: responds with success=true and prints the request on the console + */ + void ping(const std::shared_ptr request, + std::shared_ptr response) + { + // The request data is unused + (void) request; + + // Build the response + response->success = true; + + // Log to the console + RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Incoming request"); + RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Sending back response"); + } + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + // Create the node and the service + std::shared_ptr node = rclcpp::Node::make_shared("ping_server"); + rclcpp::Service::SharedPtr service = + node->create_service("ping", &ping); + + // Log that the service is ready + RCLCPP_INFO(rclcpp::get_logger("ping_server"), "Ready to serve."); + + // run the node + rclcpp::spin(node); + rclcpp::shutdown(); + } + +Create the client in a file named ``src/ping_client.cpp`` with the following content: + +.. code-block:: C++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "example_interfaces/srv/trigger.hpp" + + using namespace std::chrono_literals; + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + // Create the node and the client + std::shared_ptr node = rclcpp::Node::make_shared("ping_client"); + rclcpp::Client::SharedPtr client = + node->create_client("ping"); + + // Create a request + auto request = std::make_shared(); + + // Wait for the service to be available + while (!client->wait_for_service(1s)) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Interrupted while waiting for the service. Exiting."); + return 0; + } + RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Service not available, waiting again..."); + } + + // Now that the service is available, send the request + RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Sending request"); + auto result = client->async_send_request(request); + + // Wait for the result and log it to the console + if (rclcpp::spin_until_future_complete(node, result) == + rclcpp::FutureReturnCode::SUCCESS) + { + RCLCPP_INFO(rclcpp::get_logger("ping_client"), "Response received"); + } else { + RCLCPP_ERROR(rclcpp::get_logger("ping_client"), "Failed to call service ping"); + } + + rclcpp::shutdown(); + return 0; + } + +Open the ``CMakeLists.txt`` file and add two new executables ``ping_service`` and ``ping_client``: + +.. code-block:: cmake + + find_package(example_interfaces REQUIRED) + + add_executable(ping_service src/ping_service.cpp) + target_link_libraries(ping_service PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) + + add_executable(ping_client src/ping_client.cpp) + target_link_libraries(ping_client PUBLIC example_interfaces::example_interfaces rclcpp::rclcpp) + + install(TARGETS + ping_service + DESTINATION lib/${PROJECT_NAME}) + + install(TARGETS + ping_client + DESTINATION lib/${PROJECT_NAME}) + +Finally, build the package. + + +Create the XML profiles for the service and client +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Create a file with name ``ping.xml`` with the following content: + +.. code-block:: XML + + + + + + + DYNAMIC + + + + + DYNAMIC + + + + + DYNAMIC + + + SYNCHRONOUS + + + + + + + DYNAMIC + + + ASYNCHRONOUS + + + + + + + +This configuration file sets the publication mode to ``SYNCHRONOUS`` on the service and to ``ASYNCHRONOUS`` on the client. +Note that we are only defining the publisher profiles for both the service and the client, but subscriber profiles could be provided too. + + +Execute the nodes +^^^^^^^^^^^^^^^^^ + +Open two terminals and source the setup files on each one. +Then set the required environment variables for the XML to be loaded: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml + + .. group-tab:: macOS + + .. code-block:: console + + $ export RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ export RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ export FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml + + .. group-tab:: Windows + + .. code-block:: console + + $ SET RMW_IMPLEMENTATION=rmw_fastrtps_cpp + $ SET RMW_FASTRTPS_USE_QOS_FROM_XML=1 + $ SET FASTDDS_DEFAULT_PROFILES_FILE=path/to/ping.xml + + +On the first terminal run the service node. +You should see the service waiting for requests: + +.. code-block:: console + + $ ros2 run sync_async_node_example_cpp ping_service + [INFO] [1612977403.805799037] [ping_server]: Ready to serve. + +On the second terminal, run the client node. +You should see the client sending the request and receiving the response: + + +.. code-block:: console + + $ ros2 run sync_async_node_example_cpp ping_client + [INFO] [1612977404.805799037] [ping_client]: Sending request + [INFO] [1612977404.825473835] [ping_client]: Response received + +At the same time, the output in the server console has been updated: + +.. code-block:: console + + [INFO] [1612977403.805799037] [ping_server]: Ready to serve. + [INFO] [1612977404.807314904] [ping_server]: Incoming request [INFO] [1612977404.836405125] [ping_server]: Sending back response \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst b/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst index 59ef7698679..747425c75c3 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst @@ -1,115 +1,115 @@ -.. redirect-from:: - - Tutorials/Intermediate/Publishing-Messages-Using-YAML-Files - -Publishing messages using YAML files -==================================== - -**Goal:** Record and replay topics using YAML files. - -**Tutorial level:** Intermediate - -**Time:** 5 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Overview --------- - -Publishing ROS 2 messages via CLI is straightforward for simple types like {interface(std_msgs/msg/Bool)} or {interface(std_msgs/msg/String)}. -However, it becomes tedious for complex message structures. -This tutorial demonstrates how to use ``ros2 echo`` and ``ros2 pub`` with YAML files to record, edit, and replay topic data efficiently. - -Prerequisites -------------- - -This tutorial uses concepts like ROS 2 topics and CLI tools covered in the following tutorial: - -- :doc:`Understanding topics <../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` - -Tasks ------ - -We assume that an entity is publishing a {interface(geometry_msgs/msg/Twist)} message through a topic named ``cmd_vel`` and we want to capture the message, edit it and publish it to a topic. -We can use the ``echo`` verb to capture the message and save it in a YAML file ``cmd_vel.yaml`` using the output redirection operator ``>``. - -.. code-block:: console - - $ ros2 topic echo --once /cmd_vel > cmd_vel.yaml - -This creates a ``cmd_vel.yaml`` file with the following content in the directory the command was executed: - -.. code-block:: yaml - - linear: - x: 1.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -To publish a message, we utilize the ``--yaml-file`` option available with the ``pub`` verb of the ``ros2 topic`` command. -First, we specify the target topic—in this case, ``/cmd_vel``, followed by the message type {interface(geometry_msgs/msg/Twist)}. -Lastly, we specify the YAML file containing the message data. -The following command will publish the message contained in the ``YAML`` file to the designated ``topic`` once. - -.. code-block:: console - - $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml - publisher: beginning loop - publishing geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - -You can also publish more than once by adding more data to the YAML file as demonstrated in the example below. -In this case two messages where added to the YAML file with different values. - -.. code-block:: yaml - - linear: - x: 1.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - linear: - x: 3.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -By executing the same command as before, we publish three different messages to the ``/cmd_vel`` topic. - -.. code-block:: console - - $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml - publisher: beginning loop - publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - - publishing #2: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=3.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - - publishing #3: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) - -Next steps ----------- - +.. redirect-from:: + + Tutorials/Intermediate/Publishing-Messages-Using-YAML-Files + +Publishing messages using YAML files +==================================== + +**Goal:** Record and replay topics using YAML files. + +**Tutorial level:** Intermediate + +**Time:** 5 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Overview +-------- + +Publishing ROS 2 messages via CLI is straightforward for simple types like {interface(std_msgs/msg/Bool)} or {interface(std_msgs/msg/String)}. +However, it becomes tedious for complex message structures. +This tutorial demonstrates how to use ``ros2 echo`` and ``ros2 pub`` with YAML files to record, edit, and replay topic data efficiently. + +Prerequisites +------------- + +This tutorial uses concepts like ROS 2 topics and CLI tools covered in the following tutorial: + +- :doc:`Understanding topics <../../ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` + +Tasks +----- + +We assume that an entity is publishing a {interface(geometry_msgs/msg/Twist)} message through a topic named ``cmd_vel`` and we want to capture the message, edit it and publish it to a topic. +We can use the ``echo`` verb to capture the message and save it in a YAML file ``cmd_vel.yaml`` using the output redirection operator ``>``. + +.. code-block:: console + + $ ros2 topic echo --once /cmd_vel > cmd_vel.yaml + +This creates a ``cmd_vel.yaml`` file with the following content in the directory the command was executed: + +.. code-block:: yaml + + linear: + x: 1.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +To publish a message, we utilize the ``--yaml-file`` option available with the ``pub`` verb of the ``ros2 topic`` command. +First, we specify the target topic—in this case, ``/cmd_vel``, followed by the message type {interface(geometry_msgs/msg/Twist)}. +Lastly, we specify the YAML file containing the message data. +The following command will publish the message contained in the ``YAML`` file to the designated ``topic`` once. + +.. code-block:: console + + $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml + publisher: beginning loop + publishing geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + +You can also publish more than once by adding more data to the YAML file as demonstrated in the example below. +In this case two messages where added to the YAML file with different values. + +.. code-block:: yaml + + linear: + x: 1.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + linear: + x: 3.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +By executing the same command as before, we publish three different messages to the ``/cmd_vel`` topic. + +.. code-block:: console + + $ ros2 topic pub /cmd_vel geometry_msgs/msg/Twist --yaml-file cmd_vel.yaml + publisher: beginning loop + publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=1.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + + publishing #2: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=3.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + + publishing #3: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=0.0)) + +Next steps +---------- + If you are interested in publishing multiple topics using the CLI, you can take a look at the :doc:`Recording and playing back data <../../ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` tutorial. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst b/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst index c24e9fc4422..3fa0cc8124c 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst @@ -1,317 +1,317 @@ -.. redirect-from:: - - Topic-Statistics-Tutorial - Tutorials/Topics/Topic-Statistics-Tutorial - Tutorials/Advanced/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial - -Enabling topic statistics (C++) -=============================== - -**Goal:** Enable ROS 2 Topic Statistics and view the output statistics data. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Table of Contents - :local: - -Background ----------- - -This is a short tutorial on how to enable topic statistics in ROS 2 and view the published statistics output using command line tools (:doc:`ros2 topic <../../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). - -ROS 2 provides the integrated measurement of statistics for messages received by any subscription, -called Topic Statistics. -With Topic Statistics enabled for your subscription, you can characterize the performance of your -system or use the data to help diagnose any present issues. - -For more details please see the :doc:`Topic Statistics Concepts Page <../../../ROS-Framework/topics/About-Topic-Statistics>`. - -Prerequisites -------------- - -An installation from either binaries or source. - -In previous tutorials, you learned how to :doc:`create a workspace <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>`, -:doc:`create a package <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`, and create a :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` publisher and subscriber. - -This tutorial assumes that you still have your ``cpp_pubsub`` package from the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial. - -Tasks ------ - -1 Write the subscriber node with statistics enabled -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Navigate into the ``ros2_ws/src/cpp_pubsub/src`` folder, created in the :doc:`previous tutorial <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>`, and -download the example talker code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp - - .. group-tab:: Windows - - Right click this link and select Save As ``publisher_member_function.cpp``: - - https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp - -Now there will be a new file named ``member_function_with_topic_statistics.cpp``. -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp/subscription_options.hpp" - - #include "std_msgs/msg/string.hpp" - - class MinimalSubscriberWithTopicStatistics : public rclcpp::Node - { - public: - MinimalSubscriberWithTopicStatistics() - : Node("minimal_subscriber_with_topic_statistics") - { - // manually enable topic statistics via options - auto options = rclcpp::SubscriptionOptions(); - options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; - - // configure the collection window and publish period (default 1s) - options.topic_stats_options.publish_period = std::chrono::seconds(10); - - // configure the topic name (default '/statistics') - // options.topic_stats_options.publish_topic = "/topic_statistics" - - auto callback = [this](const std_msgs::msg::String & msg) { - this->topic_callback(msg); - }; - - subscription_ = this->create_subscription( - "topic", 10, callback, options); - } - - private: - void topic_callback(const std_msgs::msg::String & msg) const - { - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); - } - rclcpp::Subscription::SharedPtr subscription_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -As in the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial, we have a subscriber node which receives string messages from the -``topic`` topic from the ``topic_callback`` function. -However, we've now added options to configure the subscription to enable topic statistics with -the ``rclcpp::SubscriptionOptions()`` options struct. - -.. code-block:: C++ - - // manually enable topic statistics via options - auto options = rclcpp::SubscriptionOptions(); - options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; - -Optionally, fields such as the statistics collection/publish period and the topic used to publish -statistics can be configured as well. - -.. code-block:: C++ - - // configure the collection window and publish period (default 1s) - options.topic_stats_options.publish_period = std::chrono::seconds(10); - - // configure the topic name (default '/statistics') - // options.topic_stats_options.publish_topic = "/my_topic" - -The configurable fields are described in the following table: - -================================== ============================================================================================= -Subscription Config Field Purpose -================================== ============================================================================================= -topic_stats_options.state Enable or disable topic statistics (default ``rclcpp::TopicStatisticsState::Disable``) -topic_stats_options.publish_period The period in which to collect statistics data and publish a statistics message (default ``1s``) -topic_stats_options.publish_topic The topic to use when publishing statistics data (default ``/statistics``) -================================== ============================================================================================= - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. - -Add the executable and name it ``listener_with_topic_statistics`` so you can run your node using ``ros2 run``: - -.. code-block:: cmake - - add_executable(listener_with_topic_statistics src/member_function_with_topic_statistics.cpp) - target_link_libraries(listener_with_topic_statistics rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - talker - listener - listener_with_topic_statistics - DESTINATION lib/${PROJECT_NAME}) - -Make sure to save the file, and then your pub/sub system, with topic statistics enabled, -should be ready for use. - -2 Build and run -^^^^^^^^^^^^^^^ - -To build, see the :ref:`Build and run ` section in the pub/sub tutorial. - -Run the subscriber with statistics enabled node: - -.. code-block:: console - - $ ros2 run cpp_pubsub listener_with_topic_statistics - -Now run the talker node: - -.. code-block:: console - - $ ros2 run cpp_pubsub talker - [INFO] [minimal_publisher]: Publishing: "Hello World: 0" - [INFO] [minimal_publisher]: Publishing: "Hello World: 1" - [INFO] [minimal_publisher]: Publishing: "Hello World: 2" - [INFO] [minimal_publisher]: Publishing: "Hello World: 3" - [INFO] [minimal_publisher]: Publishing: "Hello World: 4" - -The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: - -.. code-block:: console - - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 10" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 11" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 12" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 13" - [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 14" - -Now that the subscriber node is receiving messages, it will periodically publish statistics messages. -We will observe these messages in the next section. - -3 Observe published statistic data -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -While the nodes are running, open a new terminal window. -Execute the following command, which will list all currently active topics. - -.. code-block:: console - - $ ros2 topic list - /parameter_events - /rosout - /statistics - /topic - -If you optionally changed the ``topic_stats_options.publish_topic`` field earlier in the tutorial, -then you will see that name instead of ``/statistics``. - -The subscriber node you created is publishing statistics, for the topic ``topic``, to the output topic -``/statistics``. - -We can visualize this using :doc:`RQt <../../Visualization/About-RQt>` - -.. image:: images/topic_stats_rqt.png - -Now we can view the statistics data published to this topic with the following command. -The terminal should start publishing statistics messages every 10 seconds, because the -``topic_stats_options.publish_period`` subscription configuration was optionally changed earlier in the tutorial: - -.. code-block:: console - - $ ros2 topic echo /statistics - --- - measurement_source_name: minimal_subscriber_with_topic_statistics - metrics_source: message_age - unit: ms - window_start: - sec: 1594856666 - nanosec: 931527366 - window_stop: - sec: 1594856676 - nanosec: 930797670 - statistics: - - data_type: 1 - data: 0.5522003000000001 - - data_type: 3 - data: 0.756992 - - data_type: 2 - data: 0.269039 - - data_type: 5 - data: 20.0 - - data_type: 4 - data: 0.16441001797065166 - --- - measurement_source_name: minimal_subscriber_with_topic_statistics - metrics_source: message_period - unit: ms - window_start: - sec: 1594856666 - nanosec: 931527366 - window_stop: - sec: 1594856676 - nanosec: 930797670 - statistics: - - data_type: 1 - data: 499.2746365105009 - - data_type: 3 - data: 500.0 - - data_type: 2 - data: 499.0 - - data_type: 5 - data: 619.0 - - data_type: 4 - data: 0.4463309283488427 - --- - -From the `message definition `__ -the ``data_types`` are as follows - -=============== =================== -data_type value statistics -=============== =================== -1 average -2 minimum -3 maximum -4 standard deviation -5 sample count -=============== =================== - -Here we see the two currently possible calculated statistics for the ``std_msgs::msg::String`` message published -to ``/topic`` by the ``minimal_publisher``. - -Summary -------- - -You created a subscriber node with topic statistics enabled, which published statistics data from -the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`'s publisher node. -You were able to compile and run this node. -While running, you were able to observe the statistics data. - -Related content ---------------- - -To observe how the ``message_age`` period is calculated please see the +.. redirect-from:: + + Topic-Statistics-Tutorial + Tutorials/Topics/Topic-Statistics-Tutorial + Tutorials/Advanced/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial + +Enabling topic statistics (C++) +=============================== + +**Goal:** Enable ROS 2 Topic Statistics and view the output statistics data. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Table of Contents + :local: + +Background +---------- + +This is a short tutorial on how to enable topic statistics in ROS 2 and view the published statistics output using command line tools (:doc:`ros2 topic <../../../ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). + +ROS 2 provides the integrated measurement of statistics for messages received by any subscription, +called Topic Statistics. +With Topic Statistics enabled for your subscription, you can characterize the performance of your +system or use the data to help diagnose any present issues. + +For more details please see the :doc:`Topic Statistics Concepts Page <../../../ROS-Framework/interfaces/topics/About-Topic-Statistics>`. + +Prerequisites +------------- + +An installation from either binaries or source. + +In previous tutorials, you learned how to :doc:`create a workspace <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>`, +:doc:`create a package <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>`, and create a :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` publisher and subscriber. + +This tutorial assumes that you still have your ``cpp_pubsub`` package from the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial. + +Tasks +----- + +1 Write the subscriber node with statistics enabled +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate into the ``ros2_ws/src/cpp_pubsub/src`` folder, created in the :doc:`previous tutorial <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>`, and +download the example talker code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget -O member_function_with_topic_statistics.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp + + .. group-tab:: Windows + + Right click this link and select Save As ``publisher_member_function.cpp``: + + https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/member_function_with_topic_statistics.cpp + +Now there will be a new file named ``member_function_with_topic_statistics.cpp``. +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp/subscription_options.hpp" + + #include "std_msgs/msg/string.hpp" + + class MinimalSubscriberWithTopicStatistics : public rclcpp::Node + { + public: + MinimalSubscriberWithTopicStatistics() + : Node("minimal_subscriber_with_topic_statistics") + { + // manually enable topic statistics via options + auto options = rclcpp::SubscriptionOptions(); + options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; + + // configure the collection window and publish period (default 1s) + options.topic_stats_options.publish_period = std::chrono::seconds(10); + + // configure the topic name (default '/statistics') + // options.topic_stats_options.publish_topic = "/topic_statistics" + + auto callback = [this](const std_msgs::msg::String & msg) { + this->topic_callback(msg); + }; + + subscription_ = this->create_subscription( + "topic", 10, callback, options); + } + + private: + void topic_callback(const std_msgs::msg::String & msg) const + { + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg.data.c_str()); + } + rclcpp::Subscription::SharedPtr subscription_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +As in the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber>` tutorial, we have a subscriber node which receives string messages from the +``topic`` topic from the ``topic_callback`` function. +However, we've now added options to configure the subscription to enable topic statistics with +the ``rclcpp::SubscriptionOptions()`` options struct. + +.. code-block:: C++ + + // manually enable topic statistics via options + auto options = rclcpp::SubscriptionOptions(); + options.topic_stats_options.state = rclcpp::TopicStatisticsState::Enable; + +Optionally, fields such as the statistics collection/publish period and the topic used to publish +statistics can be configured as well. + +.. code-block:: C++ + + // configure the collection window and publish period (default 1s) + options.topic_stats_options.publish_period = std::chrono::seconds(10); + + // configure the topic name (default '/statistics') + // options.topic_stats_options.publish_topic = "/my_topic" + +The configurable fields are described in the following table: + +================================== ============================================================================================= +Subscription Config Field Purpose +================================== ============================================================================================= +topic_stats_options.state Enable or disable topic statistics (default ``rclcpp::TopicStatisticsState::Disable``) +topic_stats_options.publish_period The period in which to collect statistics data and publish a statistics message (default ``1s``) +topic_stats_options.publish_topic The topic to use when publishing statistics data (default ``/statistics``) +================================== ============================================================================================= + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. + +Add the executable and name it ``listener_with_topic_statistics`` so you can run your node using ``ros2 run``: + +.. code-block:: cmake + + add_executable(listener_with_topic_statistics src/member_function_with_topic_statistics.cpp) + target_link_libraries(listener_with_topic_statistics rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + talker + listener + listener_with_topic_statistics + DESTINATION lib/${PROJECT_NAME}) + +Make sure to save the file, and then your pub/sub system, with topic statistics enabled, +should be ready for use. + +2 Build and run +^^^^^^^^^^^^^^^ + +To build, see the :ref:`Build and run ` section in the pub/sub tutorial. + +Run the subscriber with statistics enabled node: + +.. code-block:: console + + $ ros2 run cpp_pubsub listener_with_topic_statistics + +Now run the talker node: + +.. code-block:: console + + $ ros2 run cpp_pubsub talker + [INFO] [minimal_publisher]: Publishing: "Hello World: 0" + [INFO] [minimal_publisher]: Publishing: "Hello World: 1" + [INFO] [minimal_publisher]: Publishing: "Hello World: 2" + [INFO] [minimal_publisher]: Publishing: "Hello World: 3" + [INFO] [minimal_publisher]: Publishing: "Hello World: 4" + +The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: + +.. code-block:: console + + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 10" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 11" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 12" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 13" + [INFO] [minimal_subscriber_with_topic_statistics]: I heard: "Hello World: 14" + +Now that the subscriber node is receiving messages, it will periodically publish statistics messages. +We will observe these messages in the next section. + +3 Observe published statistic data +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +While the nodes are running, open a new terminal window. +Execute the following command, which will list all currently active topics. + +.. code-block:: console + + $ ros2 topic list + /parameter_events + /rosout + /statistics + /topic + +If you optionally changed the ``topic_stats_options.publish_topic`` field earlier in the tutorial, +then you will see that name instead of ``/statistics``. + +The subscriber node you created is publishing statistics, for the topic ``topic``, to the output topic +``/statistics``. + +We can visualize this using :doc:`RQt <../../Visualization/About-RQt>` + +.. image:: images/topic_stats_rqt.png + +Now we can view the statistics data published to this topic with the following command. +The terminal should start publishing statistics messages every 10 seconds, because the +``topic_stats_options.publish_period`` subscription configuration was optionally changed earlier in the tutorial: + +.. code-block:: console + + $ ros2 topic echo /statistics + --- + measurement_source_name: minimal_subscriber_with_topic_statistics + metrics_source: message_age + unit: ms + window_start: + sec: 1594856666 + nanosec: 931527366 + window_stop: + sec: 1594856676 + nanosec: 930797670 + statistics: + - data_type: 1 + data: 0.5522003000000001 + - data_type: 3 + data: 0.756992 + - data_type: 2 + data: 0.269039 + - data_type: 5 + data: 20.0 + - data_type: 4 + data: 0.16441001797065166 + --- + measurement_source_name: minimal_subscriber_with_topic_statistics + metrics_source: message_period + unit: ms + window_start: + sec: 1594856666 + nanosec: 931527366 + window_stop: + sec: 1594856676 + nanosec: 930797670 + statistics: + - data_type: 1 + data: 499.2746365105009 + - data_type: 3 + data: 500.0 + - data_type: 2 + data: 499.0 + - data_type: 5 + data: 619.0 + - data_type: 4 + data: 0.4463309283488427 + --- + +From the `message definition `__ +the ``data_types`` are as follows + +=============== =================== +data_type value statistics +=============== =================== +1 average +2 minimum +3 maximum +4 standard deviation +5 sample count +=============== =================== + +Here we see the two currently possible calculated statistics for the ``std_msgs::msg::String`` message published +to ``/topic`` by the ``minimal_publisher``. + +Summary +------- + +You created a subscriber node with topic statistics enabled, which published statistics data from +the :doc:`C++ <../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client>`'s publisher node. +You were able to compile and run this node. +While running, you were able to observe the statistics data. + +Related content +--------------- + +To observe how the ``message_age`` period is calculated please see the `ROS 2 Topic Statistics demo `__. \ No newline at end of file diff --git a/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst b/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst index 5e5abbc034d..9e098540372 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst @@ -1,199 +1,199 @@ -.. redirect-from:: - - Tutorials/Advanced/ROS2-Tracing-Trace-and-Analyze - -How to use ros2_tracing to trace and analyze an application -=========================================================== - -This tutorial shows how to use `ros2_tracing `_ to trace and analyze a ROS 2 application. -For this tutorial, the application will be `performance_test `_. - -Overview --------- - -This tutorial covers: - -1. running and tracing a ``performance_test`` run -2. analyzing the trace data using `tracetools_analysis `_ to plot the callback durations using `Jupyter Notebook `_ - -Prerequisites -------------- - -This tutorial is aimed at real-time Linux systems. -See the :doc:`real-time system setup tutorial <../../../Tutorials/Miscellaneous/Building-Realtime-rt_preempt-kernel-for-ROS-2>`. -However, the tutorial will work if you are using a non-real-time Linux system. - -Installing and building ------------------------ - -Install ROS 2 on Linux by following the :doc:`installation instructions <../../../Get-Started/Installation>`. - -.. note:: - - This tutorial should generally work with all supported Linux distributions. - However, you might need to adapt some commands. - -Install ``babeltrace`` and ``ros2trace``. - -.. code-block:: console - - $ sudo apt-get update - $ sudo apt-get install -y babeltrace ros-{DISTRO}-ros2trace ros-{DISTRO}-tracetools-analysis - - -Source the ROS 2 installation and verify that tracing is enabled: - -.. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run tracetools status - Tracing enabled - -Then create a workspace, and clone ``performance_test`` and ``tracetools_analysis``. - -.. code-block:: console - - $ cd ~/ - $ mkdir -p tracing_ws/src - $ cd tracing_ws/src/ - $ git clone https://gitlab.com/ApexAI/performance_test.git - $ git clone https://github.com/ros-tracing/tracetools_analysis.git -b {DISTRO} - $ cd .. - -Install dependencies with rosdep. - -.. code-block:: console - - $ rosdep update - $ rosdep install --from-paths src --ignore-src -y --skip-keys test_tracetools - -Then build and configure ``performance_test`` for ROS 2. -See its `documentation `_. - -.. code-block:: console - - $ colcon build --packages-select performance_test --cmake-args -DPERFORMANCE_TEST_RCLCPP_ENABLED=ON - -Next, we will run a ``performance_test`` experiment and trace it. - -Tracing -------- - -Step 1: Trace -^^^^^^^^^^^^^ - -In one terminal, source the workspace and set up tracing. -When running the command, a list of ROS 2 userspace events will be printed. -It will also print the path to the directory that will contain the resulting trace (under ``~/.ros/tracing``). -In Terminal 1 run: - -.. code-block:: console - - $ cd ~/tracing_ws - $ source install/setup.bash - $ ros2 trace --session-name perf-test --list - -Press enter to start tracing. - -Step 2: Run Application -^^^^^^^^^^^^^^^^^^^^^^^ - -In a second terminal, source the workspace. -In Terminal 2 run: - -.. code-block:: console - - $ cd ~/tracing_ws - $ source install/setup.bash - -Then run the ``performance_test`` experiment (or your own application). -We simply create an experiment with a node publishing ~1 MB messages to another node as fast as possible for 60 seconds using the second highest real-time priority so that we don't interfere with critical kernel threads. -We need to run ``performance_test`` as ``root`` to be able to use real-time priorities. -In Terminal 2 run: - -.. code-block:: console - - $ sudo ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 - -If that last command doesn't work for you (with an error like: "error while loading shared libraries"), run the slightly-different command below. -This is because, for security reasons, we need to manually pass ``*PATH`` environment variables for some shared libraries to be found (see `this explanation `_). -In Terminal 2 run: - -.. code-block:: console - - $ sudo env PATH="$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH" ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 - -.. note:: - - If you're not using a real-time kernel, simply run: - In Terminal 2 run: - - .. code-block:: console - - $ ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 - -Step 3: Validate Trace -^^^^^^^^^^^^^^^^^^^^^^ - -Once the experiment is done, in the first terminal, press enter again to stop tracing. -Use ``babeltrace`` to quickly look at the resulting trace. - -.. code-block:: console - - $ babeltrace ~/.ros/tracing/perf-test | less - -The output of the above command is a human-readable version of the raw Common Trace Format (CTF) data, which is a list of trace events. -Each event has a timestamp, an event type, some information on the process that generated the event, and the values of the fields of the given event type. - -Use the arrow keys to scroll, or press ``q`` to exit. - -Next, we will analyze the trace. - -Analysis --------- - -`tracetools_analysis `_ provides a Python API to easily analyze traces. -We can use it in a `Jupyter notebook `_ with `bokeh `_ to plot the data. -The ``tracetools_analysis`` repository contains a `few sample notebooks `_, including `one notebook to analyze subscription callback durations `_. - -For this tutorial, we will plot the durations of the subscription callback in the subscriber node. - -Install Jupyter notebook and bokeh, and then open the sample notebook. - -.. code-block:: console - - $ source install/setup.bash - $ python3 -m venv venv --system-site-packages - $ source venv/bin/activate - $ pip3 install bokeh ipykernel - $ python3 -m ipykernel install --user --name=venv - $ jupyter notebook ~/tracing_ws/src/tracetools_analysis/tracetools_analysis/analysis/callback_duration.ipynb - -This will open the notebook in the browser. -Click ``Kernel``, then ``Change kernel``, and select ``venv``. - -Replace the value for the ``path`` variable in the second cell to the path to the trace directory: - -.. code-block:: python - - path = '~/.ros/tracing/perf-test' - -Run the notebook by clicking the *Run* button for each cell. -Running the cell that does the trace processing might take a few minutes on the first run, but subsequent runs will be much quicker. - -You should get a plot that looks similar to this: - -.. image:: ./images/ros2_tracing_guide_result_plot.png - :alt: callback durations result plot - :align: center - -We can see that most of the callbacks take less than 0.01 ms, but there are some outliers taking over 0.02 or 0.03 ms. - -Conclusion ----------- - -This tutorial showed how to install tracing-related tools. -Then it showed how to trace a `performance_test `_ experiment using `ros2_tracing `_ and plot the callback durations using `tracetools_analysis `_. - -For more trace analyses, take a look at the `other sample notebooks `_ and the `tracetools_analysis API documentation `_. +.. redirect-from:: + + Tutorials/Advanced/ROS2-Tracing-Trace-and-Analyze + +How to use ros2_tracing to trace and analyze an application +=========================================================== + +This tutorial shows how to use `ros2_tracing `_ to trace and analyze a ROS 2 application. +For this tutorial, the application will be `performance_test `_. + +Overview +-------- + +This tutorial covers: + +1. running and tracing a ``performance_test`` run +2. analyzing the trace data using `tracetools_analysis `_ to plot the callback durations using `Jupyter Notebook `_ + +Prerequisites +------------- + +This tutorial is aimed at real-time Linux systems. +See the :doc:`real-time system setup tutorial <../../Build/Building-Realtime-rt_preempt-kernel-for-ROS-2/Building-Realtime-rt_preempt-kernel-for-ROS-2>`. +However, the tutorial will work if you are using a non-real-time Linux system. + +Installing and building +----------------------- + +Install ROS 2 on Linux by following the :doc:`installation instructions <../../../Get-Started/Installation>`. + +.. note:: + + This tutorial should generally work with all supported Linux distributions. + However, you might need to adapt some commands. + +Install ``babeltrace`` and ``ros2trace``. + +.. code-block:: console + + $ sudo apt-get update + $ sudo apt-get install -y babeltrace ros-{DISTRO}-ros2trace ros-{DISTRO}-tracetools-analysis + + +Source the ROS 2 installation and verify that tracing is enabled: + +.. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + $ ros2 run tracetools status + Tracing enabled + +Then create a workspace, and clone ``performance_test`` and ``tracetools_analysis``. + +.. code-block:: console + + $ cd ~/ + $ mkdir -p tracing_ws/src + $ cd tracing_ws/src/ + $ git clone https://gitlab.com/ApexAI/performance_test.git + $ git clone https://github.com/ros-tracing/tracetools_analysis.git -b {DISTRO} + $ cd .. + +Install dependencies with rosdep. + +.. code-block:: console + + $ rosdep update + $ rosdep install --from-paths src --ignore-src -y --skip-keys test_tracetools + +Then build and configure ``performance_test`` for ROS 2. +See its `documentation `_. + +.. code-block:: console + + $ colcon build --packages-select performance_test --cmake-args -DPERFORMANCE_TEST_RCLCPP_ENABLED=ON + +Next, we will run a ``performance_test`` experiment and trace it. + +Tracing +------- + +Step 1: Trace +^^^^^^^^^^^^^ + +In one terminal, source the workspace and set up tracing. +When running the command, a list of ROS 2 userspace events will be printed. +It will also print the path to the directory that will contain the resulting trace (under ``~/.ros/tracing``). +In Terminal 1 run: + +.. code-block:: console + + $ cd ~/tracing_ws + $ source install/setup.bash + $ ros2 trace --session-name perf-test --list + +Press enter to start tracing. + +Step 2: Run Application +^^^^^^^^^^^^^^^^^^^^^^^ + +In a second terminal, source the workspace. +In Terminal 2 run: + +.. code-block:: console + + $ cd ~/tracing_ws + $ source install/setup.bash + +Then run the ``performance_test`` experiment (or your own application). +We simply create an experiment with a node publishing ~1 MB messages to another node as fast as possible for 60 seconds using the second highest real-time priority so that we don't interfere with critical kernel threads. +We need to run ``performance_test`` as ``root`` to be able to use real-time priorities. +In Terminal 2 run: + +.. code-block:: console + + $ sudo ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 + +If that last command doesn't work for you (with an error like: "error while loading shared libraries"), run the slightly-different command below. +This is because, for security reasons, we need to manually pass ``*PATH`` environment variables for some shared libraries to be found (see `this explanation `_). +In Terminal 2 run: + +.. code-block:: console + + $ sudo env PATH="$PATH" LD_LIBRARY_PATH="$LD_LIBRARY_PATH" ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 --use-rt-prio 98 + +.. note:: + + If you're not using a real-time kernel, simply run: + In Terminal 2 run: + + .. code-block:: console + + $ ./install/performance_test/lib/performance_test/perf_test -c rclcpp-single-threaded-executor -p 1 -s 1 -r 0 -m Array1m --reliability RELIABLE --max-runtime 60 + +Step 3: Validate Trace +^^^^^^^^^^^^^^^^^^^^^^ + +Once the experiment is done, in the first terminal, press enter again to stop tracing. +Use ``babeltrace`` to quickly look at the resulting trace. + +.. code-block:: console + + $ babeltrace ~/.ros/tracing/perf-test | less + +The output of the above command is a human-readable version of the raw Common Trace Format (CTF) data, which is a list of trace events. +Each event has a timestamp, an event type, some information on the process that generated the event, and the values of the fields of the given event type. + +Use the arrow keys to scroll, or press ``q`` to exit. + +Next, we will analyze the trace. + +Analysis +-------- + +`tracetools_analysis `_ provides a Python API to easily analyze traces. +We can use it in a `Jupyter notebook `_ with `bokeh `_ to plot the data. +The ``tracetools_analysis`` repository contains a `few sample notebooks `_, including `one notebook to analyze subscription callback durations `_. + +For this tutorial, we will plot the durations of the subscription callback in the subscriber node. + +Install Jupyter notebook and bokeh, and then open the sample notebook. + +.. code-block:: console + + $ source install/setup.bash + $ python3 -m venv venv --system-site-packages + $ source venv/bin/activate + $ pip3 install bokeh ipykernel + $ python3 -m ipykernel install --user --name=venv + $ jupyter notebook ~/tracing_ws/src/tracetools_analysis/tracetools_analysis/analysis/callback_duration.ipynb + +This will open the notebook in the browser. +Click ``Kernel``, then ``Change kernel``, and select ``venv``. + +Replace the value for the ``path`` variable in the second cell to the path to the trace directory: + +.. code-block:: python + + path = '~/.ros/tracing/perf-test' + +Run the notebook by clicking the *Run* button for each cell. +Running the cell that does the trace processing might take a few minutes on the first run, but subsequent runs will be much quicker. + +You should get a plot that looks similar to this: + +.. image:: ./images/ros2_tracing_guide_result_plot.png + :alt: callback durations result plot + :align: center + +We can see that most of the callbacks take less than 0.01 ms, but there are some outliers taking over 0.02 or 0.03 ms. + +Conclusion +---------- + +This tutorial showed how to install tracing-related tools. +Then it showed how to trace a `performance_test `_ experiment using `ros2_tracing `_ and plot the callback durations using `tracetools_analysis `_. + +For more trace analyses, take a look at the `other sample notebooks `_ and the `tracetools_analysis API documentation `_. The `ros2_tracing design document `_ also contains a lot of information. \ No newline at end of file diff --git a/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst b/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst index 1653dc3c7e0..1a0fb24ba46 100644 --- a/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst +++ b/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst @@ -1,551 +1,551 @@ -.. redirect-from:: - - Tutorials/Launch-Files/Using-ROS2-Launch-for-Large-Projects - Tutorials/Launch/Using-ROS2-Launch-for-Large-Projects - Tutorials/Intermediate/Launch/Using-ROS2-Launch-For-Large-Projects - -.. _UsingROS2LaunchForLargeProjects: - -Managing large projects -======================= - -**Goal:** Learn best practices of managing large projects using ROS 2 launch files. - -**Tutorial level:** Intermediate - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 3 - :local: - -Background ----------- - -This tutorial describes some tips for writing launch files for large projects. -The focus is on how to structure launch files so they may be reused as much as possible in different situations. -Additionally, it covers usage examples of different ROS 2 launch tools, like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. - -Prerequisites -------------- - -This tutorial uses the :doc:`turtlesim <../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` and :doc:`turtle_tf2_py <../../ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2>` packages. -This tutorial also assumes you have :doc:`created a new package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` of build type ``ament_python`` called ``launch_tutorial``. - -Introduction ------------- - -Large applications on a robot typically involve several interconnected nodes, each of which can have many parameters. -Simulation of multiple turtles in the turtle simulator can serve as a good example. -The turtle simulation consists of multiple turtle nodes, the world configuration, and the TF broadcaster and listener nodes. -Between all of the nodes, there are a large number of ROS parameters that affect the behavior and appearance of these nodes. -ROS 2 launch files allow us to start all nodes and set corresponding parameters in one place. -By the end of a tutorial, you will build the ``launch_turtlesim_launch`` launch file in the ``launch_tutorial`` package. -This launch file will bring up different nodes responsible for the simulation of two turtlesim simulations, starting TF broadcasters and listener, loading parameters, and launching an RViz configuration. -In this tutorial, we'll go over this launch file and all related features used. - -.. attention:: Launch files can be written in XML, YAML, or Python format. - Throughout this tutorial, launch files are shown in all three formats using tabs. - You can choose whichever format you prefer - they are functionally equivalent. - Wherever you see the file name ``launch_turtlesim_launch`` make sure to use the correct file extension for your launch file type (i.e. ``launch_turtlesim_launch.py`` for Python, ``launch_turtlesim_launch.xml`` for XML, and ``launch_turtlesim_launch.yaml`` for YAML. - -Writing launch files --------------------- - -1 Top-level organization -^^^^^^^^^^^^^^^^^^^^^^^^ - -One of the aims in the process of writing launch files should be making them as reusable as possible. -This could be done by clustering related nodes and configurations into separate launch files. -Afterwards, a top-level launch file dedicated to a specific configuration could be written. -This would allow moving between identical robots to be done without changing the launch files at all. -Even a change such as moving from a real robot to a simulated one can be done with only a few changes. - -We will now go over the top-level launch file structure that makes this possible. -Firstly, we will create a launch file that will call separate launch files. -To do this, let's create a ``launch_turtlesim_launch`` file in the ``/launch`` folder of our ``launch_tutorial`` package. - -.. attention:: - - Earlier launch system versions may not support ``let`` inside ``include`` statements and require ``arg`` instead. - The syntax is the same: ``name`` and ``value`` attributes remain unchanged (e.g., ````). - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/launch_turtlesim_launch.xml`` file: - - .. literalinclude:: launch/launch_turtlesim_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/launch_turtlesim_launch.yaml`` file: - - .. literalinclude:: launch/launch_turtlesim_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/launch_turtlesim_launch.py`` file: - - .. literalinclude:: launch/launch_turtlesim_launch.py - :language: python - -This launch file includes a set of other launch files. -Each of these included launch files contains nodes, parameters, and possibly, nested includes, which pertain to one part of the system. -To be exact, we launch two turtlesim simulation worlds, TF broadcaster, TF listener, mimic, fixed frame broadcaster, and RViz nodes. - -.. note:: Design Tip: Top-level launch files should be short, consist of includes to other files corresponding to subcomponents of the application, and commonly changed parameters. - -Writing launch files in the following manner makes it easy to swap out one piece of the system, as we'll see later. -However, there are cases when some nodes or launch files have to be launched separately due to performance and usage reasons. - -.. note:: Design tip: Be aware of the tradeoffs when deciding how many top-level launch files your application requires. - -.. _Parameters: - -2 Parameters -^^^^^^^^^^^^ - -2.1 Setting parameters in the launch file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -We will begin by writing a launch file that will start our first turtlesim simulation. -First, create a new file called ``turtlesim_world_1_launch``. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_world_1_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_world_1_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.py`` file: - - .. literalinclude:: launch/turtlesim_world_1_launch.py - :language: python - -This launch file starts the ``turtlesim_node`` node, which starts the turtlesim simulation, with simulation configuration parameters that are defined and passed to the nodes. - -.. _LoadingParametersFromYAMLFile: - -2.2 Loading parameters from YAML file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the second launch, we will start a second turtlesim simulation with a different configuration. -Now create a ``turtlesim_world_2_launch`` file. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_world_2_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_world_2_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.py`` file: - - .. literalinclude:: launch/turtlesim_world_2_launch.py - :language: python - -This launch file will launch the same ``turtlesim_node`` with parameter values that are loaded directly from the YAML configuration file. -Defining arguments and parameters in YAML files make it easy to store and load a large number of variables. -It is also worth noting that this YAML file is not another launch file, it is a configuration file for the ``turtlesim_node`` that sets parameters for the node. -In addition, YAML files can be easily exported from the current ``ros2 param`` list. -To learn how to do that, refer to the :doc:`Understand parameters <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. - -Let's now create a configuration file, ``turtlesim.yaml``, in the ``/config`` folder of our package, which will be loaded by our launch file. - -.. code-block:: YAML - - /turtlesim2/sim: - ros__parameters: - background_b: 255 - background_g: 86 - background_r: 150 - -To learn more about using parameters and using YAML files, take a look at the :doc:`Understand parameters <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. - -2.3 Using wildcards in YAML files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -There are cases when we want to set the same parameters in more than one node. -These nodes could have different namespaces or names but still have the same parameters. -Defining separate YAML files that explicitly define namespaces and node names is not efficient. -A solution is to use wildcard characters, which act as substitutions for unknown characters in a text value, to apply parameters to several different nodes. - -Now let's create a new ``turtlesim_world_3_launch`` file similar to ``turtlesim_world_2_launch`` to include one more ``turtlesim_node`` node in a new namespace ``turtlesim3``: - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_world_3_launch.xml - :language: xml - :emphasize-lines: 3 - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_world_3_launch.yaml - :language: yaml - :emphasize-lines: 7 - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.py`` file: - - .. literalinclude:: launch/turtlesim_world_3_launch.py - :language: python - :emphasize-lines: 12 - -Loading the same YAML file, however, will not affect the appearance of the third turtlesim world. -The reason is that its parameters are stored under another namespace as shown below: - -.. code-block:: console - - /turtlesim3/sim: - background_b - background_g - background_r - -Therefore, instead of creating a new configuration for the same node that use the same parameters, we can use wildcards syntax. -``/**`` will assign all the parameters in every node, despite differences in node names and namespaces. - -We will now update the ``turtlesim.yaml``, in the ``/config`` folder in the following manner: - -.. code-block:: YAML - - /**: - ros__parameters: - background_b: 255 - background_g: 86 - background_r: 150 - -Now include the ``turtlesim_world_3_launch`` launch description in our main launch file. -Using that configuration file in our launch descriptions will assign ``background_b``, ``background_g``, and ``background_r`` parameters to specified values in ``turtlesim3/sim`` and ``turtlesim2/sim`` nodes. - -3 Namespaces -^^^^^^^^^^^^ - -As you may have noticed, we have defined the namespace for the turtlesim world in the ``turtlesim_world_2_launch`` file. -Unique namespaces allow the system to start two similar nodes without node name or topic name conflicts. - -.. code-block:: Python - - namespace='turtlesim2', - -However, if the launch file contains a large number of nodes, defining namespaces for each of them can become tedious. -To solve that issue, the ``PushROSNamespace`` action can be used to define the global namespace for each launch file description. -Every nested node will inherit that namespace automatically. - -.. attention:: ``PushROSNamespace`` has to be the first action in the list for the following actions to apply the namespace. - -To do that, firstly, we need to remove the ``namespace='turtlesim2'`` line from the ``turtlesim_world_2_launch`` file. -Afterwards, we need to update the ``launch_turtlesim_launch`` to change the include statement to the following: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: xml - - - - - - - .. group-tab:: YAML - - .. code-block:: yaml - - - group: - - push_ros_namespace: - namespace: "turtlesim2" - - include: - file: "$(find-pkg-share launch_tutorial)/launch/turtlesim_world_2_launch.yaml" - - .. group-tab:: Python - - .. code-block:: python - - from launch.actions import GroupAction - from launch_ros.actions import PushROSNamespace - - ... - GroupAction( - actions=[ - PushROSNamespace('turtlesim2'), - IncludeLaunchDescription(PathJoinSubstitution([launch_dir, 'turtlesim_world_2_launch.py'])), - ] - ), - -As a result, each node in the ``turtlesim_world_2_launch`` launch description will have a ``turtlesim2`` namespace. - -4 Reusing nodes -^^^^^^^^^^^^^^^ - -Now create a ``broadcaster_listener_launch`` file. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/broadcaster_listener_launch.xml`` file: - - .. literalinclude:: launch/broadcaster_listener_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/broadcaster_listener_launch.yaml`` file: - - .. literalinclude:: launch/broadcaster_listener_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/broadcaster_listener_launch.py`` file: - - .. literalinclude:: launch/broadcaster_listener_launch.py - :language: python - -In this file, we have declared the ``target_frame`` launch argument with a default value of ``turtle1``. -The default value means that the launch file can receive an argument to forward to its nodes, or in case the argument is not provided, it will pass the default value to its nodes. - -Afterwards, we use the ``turtle_tf2_broadcaster`` node two times using different names and parameters during launch. -This allows us to duplicate the same node without conflicts. - -We also start a ``turtle_tf2_listener`` node and set its ``target_frame`` parameter that we declared and acquired above. - -5 Parameter overrides -^^^^^^^^^^^^^^^^^^^^^ - -Recall that we called the ``broadcaster_listener_launch`` file in our top-level launch file. -In addition to that, we have passed it ``target_frame`` launch argument as shown below: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/launch_turtlesim_launch.xml - :language: xml - :lines: 5-7 - - .. group-tab:: YAML - - .. literalinclude:: launch/launch_turtlesim_launch.yaml - :language: yaml - :lines: 8-12 - - .. group-tab:: Python - - .. literalinclude:: launch/launch_turtlesim_launch.py - :language: python - :lines: 16-19 - -This syntax allows us to change the default goal target frame to ``carrot1``. -If you would like ``turtle2`` to follow ``turtle1`` instead of the ``carrot1``, just remove the line that passes the ``target_frame`` argument. -This will assign ``target_frame`` its default value, which is ``turtle1``. - -6 Remapping -^^^^^^^^^^^ - -Now create a ``mimic_launch`` file. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/mimic_launch.xml`` file: - - .. literalinclude:: launch/mimic_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/mimic_launch.yaml`` file: - - .. literalinclude:: launch/mimic_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/mimic_launch.py`` file: - - .. literalinclude:: launch/mimic_launch.py - :language: python - -This launch file will start the ``mimic`` node, which will give commands to one turtlesim to follow the other. -The node is designed to receive the target pose on the topic ``/input/pose``. -In our case, we want to remap the target pose from ``/turtle2/pose`` topic. -Finally, we remap the ``/output/cmd_vel`` topic to ``/turtlesim2/turtle1/cmd_vel``. -This way ``turtle1`` in our ``turtlesim2`` simulation world will follow ``turtle2`` in our initial turtlesim world. - -7 Config files -^^^^^^^^^^^^^^ - -Let's now create a file called ``turtlesim_rviz_launch``. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.xml`` file: - - .. literalinclude:: launch/turtlesim_rviz_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.yaml`` file: - - .. literalinclude:: launch/turtlesim_rviz_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.py`` file: - - .. literalinclude:: launch/turtlesim_rviz_launch.py - :language: python - -This launch file will start the RViz with the configuration file defined in the ``turtle_tf2_py`` package. -This RViz configuration will set the world frame, enable TF visualization, and start RViz with a top-down view. - -8 Environment Variables -^^^^^^^^^^^^^^^^^^^^^^^ - -Let's now create the last launch file called ``fixed_broadcaster_launch`` in our package. - -.. tabs:: - - .. group-tab:: XML - - Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.xml`` file: - - .. literalinclude:: launch/fixed_broadcaster_launch.xml - :language: xml - - .. group-tab:: YAML - - Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.yaml`` file: - - .. literalinclude:: launch/fixed_broadcaster_launch.yaml - :language: yaml - - .. group-tab:: Python - - Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.py`` file: - - .. literalinclude:: launch/fixed_broadcaster_launch.py - :language: python - -This launch file shows the way environment variables can be called inside the launch files. -Environment variables can be used to define or push namespaces for distinguishing nodes on different computers or robots. - -.. note:: If you are running the launch file where the ``USER`` environment variable is not defined (like in the ROS docker file), then you can replace the environment variable reference above with any other word of your liking. - -Running launch files --------------------- - -1 Update setup.py -^^^^^^^^^^^^^^^^^ - -Open ``setup.py`` and add the following lines so that the launch files from the ``launch/`` folder and configuration file from the ``config/`` would be installed. -The ``data_files`` field should now look like this: - -.. code-block:: Python - - import os - from glob import glob - from setuptools import setup - ... - - data_files=[ - ... - (os.path.join('share', package_name, 'launch'), - glob('launch/*')), - (os.path.join('share', package_name, 'config'), - glob('config/*.yaml')), - (os.path.join('share', package_name, 'rviz'), - glob('config/*.rviz')), - ], - -2 Build and run -^^^^^^^^^^^^^^^ - -To finally see the result of our code, build the package and launch the top-level launch file using the following command: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch launch_tutorial launch_turtlesim_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch launch_tutorial launch_turtlesim_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch launch_tutorial launch_turtlesim_launch.py - -You will now see the two turtlesim simulations started. -There are two turtles in the first one and one in the second one. -In the first simulation, ``turtle2`` is spawned in the bottom-left part of the world. -Its aim is to reach the ``carrot1`` frame which is five meters away on the x-axis relative to the ``turtle1`` frame. - -The ``turtlesim2/turtle1`` in the second is designed to mimic the behavior of the ``turtle2``. - -If you want to control the ``turtle1``, run the teleop node. - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -As a result, you will see a similar picture: - -.. image:: images/turtlesim_worlds.png - -In addition to that, the RViz should have started. -It will show all turtle frames relative to the ``world`` frame, whose origin is at the bottom-left corner. - -.. image:: images/turtlesim_rviz.png - -Summary -------- - +.. redirect-from:: + + Tutorials/Launch-Files/Using-ROS2-Launch-for-Large-Projects + Tutorials/Launch/Using-ROS2-Launch-for-Large-Projects + Tutorials/Intermediate/Launch/Using-ROS2-Launch-For-Large-Projects + +.. _UsingROS2LaunchForLargeProjects: + +Managing large projects +======================= + +**Goal:** Learn best practices of managing large projects using ROS 2 launch files. + +**Tutorial level:** Intermediate + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 3 + :local: + +Background +---------- + +This tutorial describes some tips for writing launch files for large projects. +The focus is on how to structure launch files so they may be reused as much as possible in different situations. +Additionally, it covers usage examples of different ROS 2 launch tools, like parameters, YAML files, remappings, namespaces, default arguments, and RViz configs. + +Prerequisites +------------- + +This tutorial uses the :doc:`turtlesim <../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` and :doc:`turtle_tf2_py <../../ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` packages. +This tutorial also assumes you have :doc:`created a new package <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package>` of build type ``ament_python`` called ``launch_tutorial``. + +Introduction +------------ + +Large applications on a robot typically involve several interconnected nodes, each of which can have many parameters. +Simulation of multiple turtles in the turtle simulator can serve as a good example. +The turtle simulation consists of multiple turtle nodes, the world configuration, and the TF broadcaster and listener nodes. +Between all of the nodes, there are a large number of ROS parameters that affect the behavior and appearance of these nodes. +ROS 2 launch files allow us to start all nodes and set corresponding parameters in one place. +By the end of a tutorial, you will build the ``launch_turtlesim_launch`` launch file in the ``launch_tutorial`` package. +This launch file will bring up different nodes responsible for the simulation of two turtlesim simulations, starting TF broadcasters and listener, loading parameters, and launching an RViz configuration. +In this tutorial, we'll go over this launch file and all related features used. + +.. attention:: Launch files can be written in XML, YAML, or Python format. + Throughout this tutorial, launch files are shown in all three formats using tabs. + You can choose whichever format you prefer - they are functionally equivalent. + Wherever you see the file name ``launch_turtlesim_launch`` make sure to use the correct file extension for your launch file type (i.e. ``launch_turtlesim_launch.py`` for Python, ``launch_turtlesim_launch.xml`` for XML, and ``launch_turtlesim_launch.yaml`` for YAML. + +Writing launch files +-------------------- + +1 Top-level organization +^^^^^^^^^^^^^^^^^^^^^^^^ + +One of the aims in the process of writing launch files should be making them as reusable as possible. +This could be done by clustering related nodes and configurations into separate launch files. +Afterwards, a top-level launch file dedicated to a specific configuration could be written. +This would allow moving between identical robots to be done without changing the launch files at all. +Even a change such as moving from a real robot to a simulated one can be done with only a few changes. + +We will now go over the top-level launch file structure that makes this possible. +Firstly, we will create a launch file that will call separate launch files. +To do this, let's create a ``launch_turtlesim_launch`` file in the ``/launch`` folder of our ``launch_tutorial`` package. + +.. attention:: + + Earlier launch system versions may not support ``let`` inside ``include`` statements and require ``arg`` instead. + The syntax is the same: ``name`` and ``value`` attributes remain unchanged (e.g., ````). + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/launch_turtlesim_launch.xml`` file: + + .. literalinclude:: launch/launch_turtlesim_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/launch_turtlesim_launch.yaml`` file: + + .. literalinclude:: launch/launch_turtlesim_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/launch_turtlesim_launch.py`` file: + + .. literalinclude:: launch/launch_turtlesim_launch.py + :language: python + +This launch file includes a set of other launch files. +Each of these included launch files contains nodes, parameters, and possibly, nested includes, which pertain to one part of the system. +To be exact, we launch two turtlesim simulation worlds, TF broadcaster, TF listener, mimic, fixed frame broadcaster, and RViz nodes. + +.. note:: Design Tip: Top-level launch files should be short, consist of includes to other files corresponding to subcomponents of the application, and commonly changed parameters. + +Writing launch files in the following manner makes it easy to swap out one piece of the system, as we'll see later. +However, there are cases when some nodes or launch files have to be launched separately due to performance and usage reasons. + +.. note:: Design tip: Be aware of the tradeoffs when deciding how many top-level launch files your application requires. + +.. _Parameters: + +2 Parameters +^^^^^^^^^^^^ + +2.1 Setting parameters in the launch file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We will begin by writing a launch file that will start our first turtlesim simulation. +First, create a new file called ``turtlesim_world_1_launch``. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_world_1_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_world_1_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_world_1_launch.py`` file: + + .. literalinclude:: launch/turtlesim_world_1_launch.py + :language: python + +This launch file starts the ``turtlesim_node`` node, which starts the turtlesim simulation, with simulation configuration parameters that are defined and passed to the nodes. + +.. _LoadingParametersFromYAMLFile: + +2.2 Loading parameters from YAML file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the second launch, we will start a second turtlesim simulation with a different configuration. +Now create a ``turtlesim_world_2_launch`` file. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_world_2_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_world_2_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_world_2_launch.py`` file: + + .. literalinclude:: launch/turtlesim_world_2_launch.py + :language: python + +This launch file will launch the same ``turtlesim_node`` with parameter values that are loaded directly from the YAML configuration file. +Defining arguments and parameters in YAML files make it easy to store and load a large number of variables. +It is also worth noting that this YAML file is not another launch file, it is a configuration file for the ``turtlesim_node`` that sets parameters for the node. +In addition, YAML files can be easily exported from the current ``ros2 param`` list. +To learn how to do that, refer to the :doc:`Understand parameters <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. + +Let's now create a configuration file, ``turtlesim.yaml``, in the ``/config`` folder of our package, which will be loaded by our launch file. + +.. code-block:: YAML + + /turtlesim2/sim: + ros__parameters: + background_b: 255 + background_g: 86 + background_r: 150 + +To learn more about using parameters and using YAML files, take a look at the :doc:`Understand parameters <../../ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters>` tutorial. + +2.3 Using wildcards in YAML files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +There are cases when we want to set the same parameters in more than one node. +These nodes could have different namespaces or names but still have the same parameters. +Defining separate YAML files that explicitly define namespaces and node names is not efficient. +A solution is to use wildcard characters, which act as substitutions for unknown characters in a text value, to apply parameters to several different nodes. + +Now let's create a new ``turtlesim_world_3_launch`` file similar to ``turtlesim_world_2_launch`` to include one more ``turtlesim_node`` node in a new namespace ``turtlesim3``: + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_world_3_launch.xml + :language: xml + :emphasize-lines: 3 + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_world_3_launch.yaml + :language: yaml + :emphasize-lines: 7 + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_world_3_launch.py`` file: + + .. literalinclude:: launch/turtlesim_world_3_launch.py + :language: python + :emphasize-lines: 12 + +Loading the same YAML file, however, will not affect the appearance of the third turtlesim world. +The reason is that its parameters are stored under another namespace as shown below: + +.. code-block:: console + + /turtlesim3/sim: + background_b + background_g + background_r + +Therefore, instead of creating a new configuration for the same node that use the same parameters, we can use wildcards syntax. +``/**`` will assign all the parameters in every node, despite differences in node names and namespaces. + +We will now update the ``turtlesim.yaml``, in the ``/config`` folder in the following manner: + +.. code-block:: YAML + + /**: + ros__parameters: + background_b: 255 + background_g: 86 + background_r: 150 + +Now include the ``turtlesim_world_3_launch`` launch description in our main launch file. +Using that configuration file in our launch descriptions will assign ``background_b``, ``background_g``, and ``background_r`` parameters to specified values in ``turtlesim3/sim`` and ``turtlesim2/sim`` nodes. + +3 Namespaces +^^^^^^^^^^^^ + +As you may have noticed, we have defined the namespace for the turtlesim world in the ``turtlesim_world_2_launch`` file. +Unique namespaces allow the system to start two similar nodes without node name or topic name conflicts. + +.. code-block:: Python + + namespace='turtlesim2', + +However, if the launch file contains a large number of nodes, defining namespaces for each of them can become tedious. +To solve that issue, the ``PushROSNamespace`` action can be used to define the global namespace for each launch file description. +Every nested node will inherit that namespace automatically. + +.. attention:: ``PushROSNamespace`` has to be the first action in the list for the following actions to apply the namespace. + +To do that, firstly, we need to remove the ``namespace='turtlesim2'`` line from the ``turtlesim_world_2_launch`` file. +Afterwards, we need to update the ``launch_turtlesim_launch`` to change the include statement to the following: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: xml + + + + + + + .. group-tab:: YAML + + .. code-block:: yaml + + - group: + - push_ros_namespace: + namespace: "turtlesim2" + - include: + file: "$(find-pkg-share launch_tutorial)/launch/turtlesim_world_2_launch.yaml" + + .. group-tab:: Python + + .. code-block:: python + + from launch.actions import GroupAction + from launch_ros.actions import PushROSNamespace + + ... + GroupAction( + actions=[ + PushROSNamespace('turtlesim2'), + IncludeLaunchDescription(PathJoinSubstitution([launch_dir, 'turtlesim_world_2_launch.py'])), + ] + ), + +As a result, each node in the ``turtlesim_world_2_launch`` launch description will have a ``turtlesim2`` namespace. + +4 Reusing nodes +^^^^^^^^^^^^^^^ + +Now create a ``broadcaster_listener_launch`` file. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/broadcaster_listener_launch.xml`` file: + + .. literalinclude:: launch/broadcaster_listener_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/broadcaster_listener_launch.yaml`` file: + + .. literalinclude:: launch/broadcaster_listener_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/broadcaster_listener_launch.py`` file: + + .. literalinclude:: launch/broadcaster_listener_launch.py + :language: python + +In this file, we have declared the ``target_frame`` launch argument with a default value of ``turtle1``. +The default value means that the launch file can receive an argument to forward to its nodes, or in case the argument is not provided, it will pass the default value to its nodes. + +Afterwards, we use the ``turtle_tf2_broadcaster`` node two times using different names and parameters during launch. +This allows us to duplicate the same node without conflicts. + +We also start a ``turtle_tf2_listener`` node and set its ``target_frame`` parameter that we declared and acquired above. + +5 Parameter overrides +^^^^^^^^^^^^^^^^^^^^^ + +Recall that we called the ``broadcaster_listener_launch`` file in our top-level launch file. +In addition to that, we have passed it ``target_frame`` launch argument as shown below: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/launch_turtlesim_launch.xml + :language: xml + :lines: 5-7 + + .. group-tab:: YAML + + .. literalinclude:: launch/launch_turtlesim_launch.yaml + :language: yaml + :lines: 8-12 + + .. group-tab:: Python + + .. literalinclude:: launch/launch_turtlesim_launch.py + :language: python + :lines: 16-19 + +This syntax allows us to change the default goal target frame to ``carrot1``. +If you would like ``turtle2`` to follow ``turtle1`` instead of the ``carrot1``, just remove the line that passes the ``target_frame`` argument. +This will assign ``target_frame`` its default value, which is ``turtle1``. + +6 Remapping +^^^^^^^^^^^ + +Now create a ``mimic_launch`` file. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/mimic_launch.xml`` file: + + .. literalinclude:: launch/mimic_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/mimic_launch.yaml`` file: + + .. literalinclude:: launch/mimic_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/mimic_launch.py`` file: + + .. literalinclude:: launch/mimic_launch.py + :language: python + +This launch file will start the ``mimic`` node, which will give commands to one turtlesim to follow the other. +The node is designed to receive the target pose on the topic ``/input/pose``. +In our case, we want to remap the target pose from ``/turtle2/pose`` topic. +Finally, we remap the ``/output/cmd_vel`` topic to ``/turtlesim2/turtle1/cmd_vel``. +This way ``turtle1`` in our ``turtlesim2`` simulation world will follow ``turtle2`` in our initial turtlesim world. + +7 Config files +^^^^^^^^^^^^^^ + +Let's now create a file called ``turtlesim_rviz_launch``. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.xml`` file: + + .. literalinclude:: launch/turtlesim_rviz_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.yaml`` file: + + .. literalinclude:: launch/turtlesim_rviz_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/turtlesim_rviz_launch.py`` file: + + .. literalinclude:: launch/turtlesim_rviz_launch.py + :language: python + +This launch file will start the RViz with the configuration file defined in the ``turtle_tf2_py`` package. +This RViz configuration will set the world frame, enable TF visualization, and start RViz with a top-down view. + +8 Environment Variables +^^^^^^^^^^^^^^^^^^^^^^^ + +Let's now create the last launch file called ``fixed_broadcaster_launch`` in our package. + +.. tabs:: + + .. group-tab:: XML + + Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.xml`` file: + + .. literalinclude:: launch/fixed_broadcaster_launch.xml + :language: xml + + .. group-tab:: YAML + + Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.yaml`` file: + + .. literalinclude:: launch/fixed_broadcaster_launch.yaml + :language: yaml + + .. group-tab:: Python + + Copy and paste the complete code into the ``launch/fixed_broadcaster_launch.py`` file: + + .. literalinclude:: launch/fixed_broadcaster_launch.py + :language: python + +This launch file shows the way environment variables can be called inside the launch files. +Environment variables can be used to define or push namespaces for distinguishing nodes on different computers or robots. + +.. note:: If you are running the launch file where the ``USER`` environment variable is not defined (like in the ROS docker file), then you can replace the environment variable reference above with any other word of your liking. + +Running launch files +-------------------- + +1 Update setup.py +^^^^^^^^^^^^^^^^^ + +Open ``setup.py`` and add the following lines so that the launch files from the ``launch/`` folder and configuration file from the ``config/`` would be installed. +The ``data_files`` field should now look like this: + +.. code-block:: Python + + import os + from glob import glob + from setuptools import setup + ... + + data_files=[ + ... + (os.path.join('share', package_name, 'launch'), + glob('launch/*')), + (os.path.join('share', package_name, 'config'), + glob('config/*.yaml')), + (os.path.join('share', package_name, 'rviz'), + glob('config/*.rviz')), + ], + +2 Build and run +^^^^^^^^^^^^^^^ + +To finally see the result of our code, build the package and launch the top-level launch file using the following command: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch launch_tutorial launch_turtlesim_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch launch_tutorial launch_turtlesim_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch launch_tutorial launch_turtlesim_launch.py + +You will now see the two turtlesim simulations started. +There are two turtles in the first one and one in the second one. +In the first simulation, ``turtle2`` is spawned in the bottom-left part of the world. +Its aim is to reach the ``carrot1`` frame which is five meters away on the x-axis relative to the ``turtle1`` frame. + +The ``turtlesim2/turtle1`` in the second is designed to mimic the behavior of the ``turtle2``. + +If you want to control the ``turtle1``, run the teleop node. + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +As a result, you will see a similar picture: + +.. image:: images/turtlesim_worlds.png + +In addition to that, the RViz should have started. +It will show all turtle frames relative to the ``world`` frame, whose origin is at the bottom-left corner. + +.. image:: images/turtlesim_rviz.png + +Summary +------- + In this tutorial, you learned about various tips and practices of managing large projects using ROS 2 launch files. \ No newline at end of file diff --git a/source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst b/source/Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package.rst similarity index 100% rename from source/Developer-Tools/Build/Documenting-a-ROS-2-Package.rst rename to source/Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package.rst diff --git a/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst b/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst index 586281a2cde..4f20f60b370 100644 --- a/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst +++ b/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst @@ -1,112 +1,112 @@ -.. redirect-from:: - - Guides/Overriding-QoS-Policies-For-Recording-And-Playback - Tutorials/Ros2bag/Overriding-QoS-Policies-For-Recording-And-Playback - How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback - -.. _ROS2Bag-QoS-Override: - -rosbag2: Overriding QoS Policies -================================ - -**Goal:** Override Ros2Bag QoS profile settings for recording and playback. - -.. contents:: Contents - :depth: 2 - :local: - - -Background ----------- - -With the introduction of DDS in ROS 2, Quality of Service (QoS) compatibility for publisher/subscriber nodes needs to be considered when recording and playing back data. -More detail on how QoS works can be found :doc:`here <../../ROS-Framework/topics/About-Quality-of-Service-Settings>`. -For the purposes of this guide, it is sufficient to know that only the reliability and durability policies affect whether publishers/subscribers are compatible and can receive data from one other. - -Ros2Bag adapts its requested/offered QoS profile when recording/playing data from a topic to prevent dropped messages. -During playback, Ros2bag also attempts to preserve the policy originally offered by the topic. -Certain situations may require specifying explicit QoS profile settings so Ros2Bag can record/playback topics. -These QoS profile overrides can be specified via the CLI using the ``--qos-profile-overrides-path`` flag. - -Using QoS Overrides -------------------- - -The YAML schema for the profile overrides is a dictionary of topic names with key/value pairs for each QoS policy: - -.. code-block:: yaml - - topic_name: str - qos_policy_name: str - ... - qos_duration: object - sec: int - nsec: int - -If a policy value is not specified, the value will fallback to the default used by Ros2Bag. -If you specify a Duration based policy such as ``deadline`` or ``lifespan``, you will need to specify both seconds and nanoseconds. -Policy values are determined by the policy's short keys which can be found using ``ros2topic`` verbs such as ``ros2 topic pub --help``. -All values are replicated below for reference. - -.. code-block:: yaml - - history: [keep_all, keep_last] - depth: int - reliability: [system_default, reliable, best_effort, unknown] - durability: [system_default, transient_local, volatile, unknown] - deadline: - sec: int - nsec: int - lifespan: - sec: int - nsec: int - liveliness: [system_default, automatic, manual_by_topic, unknown] - liveliness_lease_duration: - sec: int - nsec: int - avoid_ros_namespace_conventions: [true, false] - -Example -------- - -Consider a topic ``/talker`` offering a ``transient_local`` Durability policy. -ROS 2 publishers by default request ``volatile`` Durability. - -.. code-block:: console - - $ ros2 topic pub -r 0.1 --qos-durability transient_local /talker std_msgs/String "data: Hello World" - -In order for Ros2Bag to record the data, we would want to override the recording policy for that specific topic like so: - -.. code-block:: yaml - - # durability_override.yaml - /talker: - durability: transient_local - history: keep_all - -And call it from the CLI: - -.. code-block:: console - - $ ros2 bag record -a -o my_bag --qos-profile-overrides-path durability_override.yaml - -If we want to playback the bag file but with a different Reliability policy, we can specify one as such; - -.. code-block:: yaml - - # reliability_override.yaml - /talker: - reliability: best_effort - history: keep_all - -And call it from the CLI: - -.. code-block:: console - - $ ros2 bag play --qos-profile-overrides-path reliability_override.yaml my_bag - -We can see the results with ``ros2 topic`` - -.. code-block:: console - +.. redirect-from:: + + Guides/Overriding-QoS-Policies-For-Recording-And-Playback + Tutorials/Ros2bag/Overriding-QoS-Policies-For-Recording-And-Playback + How-To-Guides/Overriding-QoS-Policies-For-Recording-And-Playback + +.. _ROS2Bag-QoS-Override: + +rosbag2: Overriding QoS Policies +================================ + +**Goal:** Override Ros2Bag QoS profile settings for recording and playback. + +.. contents:: Contents + :depth: 2 + :local: + + +Background +---------- + +With the introduction of DDS in ROS 2, Quality of Service (QoS) compatibility for publisher/subscriber nodes needs to be considered when recording and playing back data. +More detail on how QoS works can be found :doc:`here <../../ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings>`. +For the purposes of this guide, it is sufficient to know that only the reliability and durability policies affect whether publishers/subscribers are compatible and can receive data from one other. + +Ros2Bag adapts its requested/offered QoS profile when recording/playing data from a topic to prevent dropped messages. +During playback, Ros2bag also attempts to preserve the policy originally offered by the topic. +Certain situations may require specifying explicit QoS profile settings so Ros2Bag can record/playback topics. +These QoS profile overrides can be specified via the CLI using the ``--qos-profile-overrides-path`` flag. + +Using QoS Overrides +------------------- + +The YAML schema for the profile overrides is a dictionary of topic names with key/value pairs for each QoS policy: + +.. code-block:: yaml + + topic_name: str + qos_policy_name: str + ... + qos_duration: object + sec: int + nsec: int + +If a policy value is not specified, the value will fallback to the default used by Ros2Bag. +If you specify a Duration based policy such as ``deadline`` or ``lifespan``, you will need to specify both seconds and nanoseconds. +Policy values are determined by the policy's short keys which can be found using ``ros2topic`` verbs such as ``ros2 topic pub --help``. +All values are replicated below for reference. + +.. code-block:: yaml + + history: [keep_all, keep_last] + depth: int + reliability: [system_default, reliable, best_effort, unknown] + durability: [system_default, transient_local, volatile, unknown] + deadline: + sec: int + nsec: int + lifespan: + sec: int + nsec: int + liveliness: [system_default, automatic, manual_by_topic, unknown] + liveliness_lease_duration: + sec: int + nsec: int + avoid_ros_namespace_conventions: [true, false] + +Example +------- + +Consider a topic ``/talker`` offering a ``transient_local`` Durability policy. +ROS 2 publishers by default request ``volatile`` Durability. + +.. code-block:: console + + $ ros2 topic pub -r 0.1 --qos-durability transient_local /talker std_msgs/String "data: Hello World" + +In order for Ros2Bag to record the data, we would want to override the recording policy for that specific topic like so: + +.. code-block:: yaml + + # durability_override.yaml + /talker: + durability: transient_local + history: keep_all + +And call it from the CLI: + +.. code-block:: console + + $ ros2 bag record -a -o my_bag --qos-profile-overrides-path durability_override.yaml + +If we want to playback the bag file but with a different Reliability policy, we can specify one as such; + +.. code-block:: yaml + + # reliability_override.yaml + /talker: + reliability: best_effort + history: keep_all + +And call it from the CLI: + +.. code-block:: console + + $ ros2 bag play --qos-profile-overrides-path reliability_override.yaml my_bag + +We can see the results with ``ros2 topic`` + +.. code-block:: console + $ ros2 topic echo --qos-reliability best_effort /talker std_msgs/String \ No newline at end of file diff --git a/source/First-Steps.rst b/source/First-Steps.rst index 9f9783c3f7e..1e302becf1a 100644 --- a/source/First-Steps.rst +++ b/source/First-Steps.rst @@ -36,29 +36,29 @@ Steps ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * About ROS -* :doc:`/Concepts/Basic/About-Nodes` +* :doc:`ROS-Framework/About-Nodes` * Interfaces (topics, services, actions) -* :doc:`/Concepts/Basic/About-Parameters` +* :doc:`ROS-Framework/About-Parameters` 2 Install ROS and turtlesim ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ROS installation includes the essential packages for working with ROS. If you're familiar with Linux, our recommended platform is Ubuntu (deb packages). -Otherwise, a good alternative installation platform is Windows (binaries): :doc:`Installation options ` +Otherwise, a good alternative installation platform is Windows (binaries): :doc:`Installation options ` -With turtlesim, a lightweight 2D simulation tool designed for beginners, you can learn core ROS concepts in a simple visual environment: :doc:`Install and set up turtlesim ` +With turtlesim, a lightweight 2D simulation tool designed for beginners, you can learn core ROS concepts in a simple visual environment: :doc:`Install and set up turtlesim ` 3 Try out working with the main communication components of the ROS framework ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Use turtlesim to familiarize yourself with the main communication components and try out messaging in the ROS framework. -#. Complete the nodes tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes` -#. Complete the topics tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics` -#. Complete the services tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services` -#. Complete the parameters tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters` -#. Complete the actions tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Actions/Understanding-ROS2-Actions` +#. Complete the nodes tutorial: :doc:`ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes` +#. Complete the topics tutorial: :doc:`ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics` +#. Complete the services tutorial: :doc:`ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services` +#. Complete the parameters tutorial: :doc:`ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters` +#. Complete the actions tutorial: :doc:`ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions` 4 Learn about introspection with logs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -66,21 +66,21 @@ Use turtlesim to familiarize yourself with the main communication components and Introspection enables you to see information about how a system is operating. Nodes use logs to output messages concerning events and status in a variety of ways. -To see introspection through logs in action, complete the rqt_console tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Using-Rqt-Console/Using-Rqt-Console` +To see introspection through logs in action, complete the rqt_console tutorial: :doc:`ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console` 5 Learn about using launch files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Launch files allow you to start and configure a number of processes containing ROS nodes simultaneously, instead of opening multiple terminals and re-entering configuration details for each node. -Complete the launch files tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Launching-Multiple-Nodes/Launching-Multiple-Nodes` +Complete the launch files tutorial: :doc:`ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes` 6 Learn about data recording and playback ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sometimes it's useful to replay data to reproduce the results of your tests and experiments, to debug your robot's behaviour, or to share your work with others. -Complete the recording and playback tutorial: :doc:`/Tutorials/Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data` +Complete the recording and playback tutorial: :doc:`ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data` Next steps ---------- diff --git a/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup-Pixi.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup-Pixi.rst index 51de869d3bd..b285e929314 100644 --- a/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup-Pixi.rst +++ b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup-Pixi.rst @@ -183,7 +183,7 @@ Continue with the :doc:`tutorials and demos <../../Tutorials>` to configure your Stay up to date --------------- -See :doc:`../Maintaining-a-Source-Checkout` to periodically refresh your source installation. +See :doc:`Maintaining-a-Source-Checkout` to periodically refresh your source installation. 1. If you installed your workspace with colcon as instructed above, "uninstalling" could be just a matter of opening a new terminal and not sourcing the workspace's ``setup`` file. This way, your environment will behave as though there is no {DISTRO_TITLE} install on your system. diff --git a/source/Get-Started/Installation/Ubuntu-Install-Debs.rst b/source/Get-Started/Installation/Ubuntu-Install-Debs.rst index a8f68750ae6..ea3f161ad2b 100644 --- a/source/Get-Started/Installation/Ubuntu-Install-Debs.rst +++ b/source/Get-Started/Installation/Ubuntu-Install-Debs.rst @@ -163,26 +163,26 @@ If you installed ``ros-{DISTRO}-desktop``, you can try some examples to check if You should see the talker saying that it's publishing messages and the listener saying that it hears those messages. This verifies both the C++ and Python APIs are working properly. -If you have issues with the installation, check the :doc:`troubleshooting techniques <../How-To-Guides/Installation-Troubleshooting>`. +If you have issues with the installation, check the :doc:`troubleshooting techniques `. If you want to use other RMW implementations, you can check the :doc:`guide `. Next steps ---------- -After the installation is complete, you can proceed with :doc:`configuring your environment <../Tutorials/Beginner-CLI-Tools/Configuring-ROS2-Environment>`. +After the installation is complete, you can proceed with :doc:`configuring your environment <../Configuring-ROS2-Environment>`. We recommend that you get familiar with key ROS concepts and check out the tutorials: -* :doc:`First steps with ROS - learning path <../First-Steps>` +* :doc:`First steps with ROS - learning path <../../First-Steps>` Related content --------------- More articles: -* :doc:`Create a workspace <../Tutorials/Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` -* :doc:`About ROS <../About-ROS>` +* :doc:`Create a workspace <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` +* :doc:`About ROS <../About-ROS/About-ROS>` Packages/reference: @@ -200,7 +200,7 @@ Which Ubuntu platforms are supported? ROS 2 {DISTRO_TITLE_FULL} is available for {DISTRO_UBUNTU_DEB_PLATFORM}. Why am I seeing ? - See :doc:`../How-To-Guides/Installation-Troubleshooting`. + See :doc:`Installation-Troubleshooting`. Can I switch from binaries to a source-based install? Yes. diff --git a/source/Get-Started/Releases/Release-Kilted-Kaiju.rst b/source/Get-Started/Releases/Release-Kilted-Kaiju.rst index 1211fbf16de..6999ced7818 100644 --- a/source/Get-Started/Releases/Release-Kilted-Kaiju.rst +++ b/source/Get-Started/Releases/Release-Kilted-Kaiju.rst @@ -1,559 +1,559 @@ -.. redirect-from:: - - Releases/Release-Kilted-Kaiju - -.. _kilted-release: - -Kilted Kaiju (codename 'kilted'; May, 2025) -=========================================== - -.. toctree:: - :hidden: - - Kilted-Kaiju-Complete-Changelog - -.. contents:: Table of Contents - :depth: 2 - :local: - -*Kilted Kaiju* is the eleventh release of ROS 2. -What follows is highlights of the important changes and features in Kilted Kaiju since the last release. -For a list of all of the changes since Jazzy, see the :doc:`long form changelog ` - -Supported Platforms -------------------- - -Kilted Kaiju supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: - -Tier 1 platforms: - -* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` -* Windows 10 (Visual Studio 2019): ``amd64`` - -Tier 2 platforms: - -* RHEL 9: ``amd64`` - -Tier 3 platforms: - -* macOS: ``amd64`` -* Debian Bookworm: ``amd64`` - -Targeted platforms: - -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -| Architecture | Ubuntu Noble | Windows 10 | RHEL 9 | macOS | Debian Bookworm | OpenEmbedded / | -| | (24.04) | (VS2019) | | | (12) | Yocto Project | -+==============+===================+===============+===================+===========+=================+================+ -| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s]| Tier 3 [s] | Tier 3 [s] | -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | -+--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ - -The following indicators show what delivery mechanisms are available for -each platform. - -\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be -provided for this platform for packages submitted to the rosdistro. - -\" \[a\] \" Binary releases are provided as a single archive per -platform containing all packages in the Jazzy ROS 2 repos file[^14]. - -\" \[s\] \" Compilation from source. - -Middleware Implementation Support: - -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | -+===========================+=========================+===============+============================+===============================+ -| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64| -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_zenoh_cpp | Eclipse Zenoh | Tier 1 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ -| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32| -+---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ - -\" \* \" means default RMW implementation. - -Middleware implementation support is dependent upon the platform support -tier. For example a Tier 1 middleware implementation on a Tier 2 -platform can only receive Tier 2 support. - -Minimum language requirements: - -- C++17 -- Python 3.9 - -Dependency Requirements: - -+---------------+-------------------------------+-------------------------------------------------------------+ -| | Required Support | Recommended Support | -+===============+===============+===============+==========+==========+==================+====================+ -| Package | Ubuntu Noble | Windows 10** | RHEL 9 | macOS** | Debian Bookworm | OpenEmbedded** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| CMake | 3.28.3 | 3.28.3 | 3.26.5 | 3.31.1 | 3.25.1 | 3.22.3 | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| EmPY | 3.3.4 | 3.3.4 | 3.3.4a | 3.3.4 | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Gazebo | Ionic* | N/A | N/A | Ionic* | Ionic* | N/A | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| NumPy | 1.26.4 | 1.26.4 | 1.20.1 | 2.1.3 | 1.24.2 | N/A | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Ogre | 1.12.10 | N/A | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| OpenCV | 4.6.0 | 4.9.0 | 4.6.0 | 4.10.0 | 4.6.0 | 4.1.0 / 3.2.0*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| OpenSSL | 3.0.13 | 3.3.2 | 3.2.2 | 1.1.1w | 3.0.15 | 1.1.1d / 1.1.1b*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Python | 3.12.3 | 3.12.3 | 3.9.19 | 3.13.0 | 3.11.2 | 3.8.2 / 3.7.5*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| Qt | 5.15.13 | 5.15.8 | 5.15.9 | 5.15.16 | 5.15.8 | 5.14.1 / 5.12.5*** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| | **Linux only** | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| PCL | 1.14.0 | N/A | 1.12.0 | 1.14.1 | 1.13.0 | 1.10.0 | -+---------------+---------------+---------------+----------+----------+------------------+--------------------+ -| **RMW Middleware** | -+---------------------------------------------------------------------+---------------------------------------+ -| Connext DDS | 7.3.0.0 | N/A | -+---------------+-----------------------------------------------------+---------------------------------------+ -| Cyclone DDS | 0.10.5 | -+---------------+---------------------------------------------------------------------------------------------+ -| Fast-DDS | 2.14.4 | -+---------------+-------------------------------+-------------------------------------------------------------+ -| Gurum DDS | 4.2.0 | N/A | -+---------------+-------------------------------+-------------------------------------------------------------+ -| Zenoh | 1.0.4 | -+---------------+---------------------------------------------------------------------------------------------+ - -\" \* \" means that this is not the upstream version (available on the -official Operating System repositories) but a package distributed by -OSRF or the community (package built and distributed on custom -repositories). - -\" \*\* \" means that the dependency may see multiple version changes, -because the dependency uses a package manager that continually updates -the dependency without a stable API. - -\" \*\*\* \" webOS OSE provides this different version. - -This document only captures the version at the first release of a ROS -distribution and will not be updated as the dependencies move forward. -These versions are thus a low watermark. - -Package manager use for dependencies: - -- Ubuntu, Debian: apt, pip -- Windows: pixi/conda, pip -- macOS: Homebrew, pip -- RHEL: dnf -- OpenEmbedded: opkg - -Build System Support: - -- ament_cmake -- cargo -- cmake -- setuptools - -Installation ------------- - -`Install Kilted Kaiju <../../kilted/Installation.html>`__ - -Supported Gazebo Release ------------------------- -For Kilted Kaiju, the recommended Gazebo release is `Ionic `__. - -New features in this ROS 2 release ----------------------------------- - -``ament_cmake_ros`` -^^^^^^^^^^^^^^^^^^^ - -Add rmw_test_fixture for supporting RMW-isolated testing -"""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -Included two new packages which provide an extensible mechanism for creating a test fixture for RMW-based communication isolation. -It is modeled closely after the rmw and rmw_implementation API. - -The ``rmw_test_fixture`` package currently provides only the API, which could be implemented by an RMW provider for configuring their RMW for a test to run. - -The ``rmw_test_fixture_implementation`` package provides the entry point for discovering, loading, and invoking the appropriate extension. - -See https://github.com/ros2/ament_cmake_ros/pull/21 for more details. - -``common_interfaces`` -^^^^^^^^^^^^^^^^^^^^^ - -New nav_msgs/Goals message -"""""""""""""""""""""""""" - -A new message type, {interface(nav_msgs/msg/Goals)}, has been introduced to support an array of navigation goals within the nav_msgs package. - -See https://github.com/ros2/common_interfaces/pull/269 for more details. - -``ros2cli`` -^^^^^^^^^^^ - -Action introspection -"""""""""""""""""""" - -This allows to instrospect an action with the command line. -Using ``ros2cli`` tools: ``ros2 action echo ``. - -See https://github.com/ros2/ros2cli/pull/978 for more information. -Visit :ref:`ros2 action echo ` and :doc:`Action Introspection <../../ROS-Framework/actions/Working-with-actions/Action-Introspection>` to learn more about this feature. - -``rclcpp`` -^^^^^^^^^^ - -Action generic client -""""""""""""""""""""" - -Support action generic client, this is used to support actions in rosbag2. - -See https://github.com/ros2/rclcpp/pull/2759 for more details. - -``rclpy`` -^^^^^^^^^ - -Static Type Checking -"""""""""""""""""""" - -Added static type hints to ``ActionClient`` and ``ActionServer``. - -See https://github.com/ros2/rclpy/pull/1349 for more details. - -Add support for `generics `_ in ``pub/sub/client/server/actions``, ``Future/Task``, and ``Parameter``. - -``Publisher``, ``Subscription``, ``Server``, ``Task``, and ``Parameter`` should need no updates to add support for generics. - -``Client`` will need to be updated to resemble the following to get the improved type checking. - -.. code-block:: python - - self._get_parameter_client: Client[GetParameters.Request, - GetParameters.Response] = self.node.create_client( - GetParameters, '/get_parameters', - qos_profile=qos_profile, callback_group=callback_group) - -``ActionClient`` will need to be updated to resemble the following to get the improved type checking. - -.. code-block:: python - - ac: ActionClient[Fibonacci.Goal, - Fibonacci.Result, - Fibonacci.Feedback] = ActionClient(self.node, Fibonacci, 'fibonacci') - -``Future`` will need to be updated to resemble the following to get the improved type checking. - -.. code-block:: python - - log_msgs_future: Future[bool] = Future() - -See https://github.com/ros2/rclpy/pull/1239, https://github.com/ros2/rclpy/pull/1275, https://github.com/ros2/rclpy/pull/1246, and https://github.com/ros2/rclpy/pull/1254/files for more details. - -Various other small improvements and corrections have also been made throughout all of ``rclpy``. - -Python types can be statically checked using `ament_mypy `_ which wraps `mypy `_. - -EventsExecutor -"""""""""""""" - -Support an experimental events executor for ``rclpy``, which is a port of the original ``rclcpp`` events executor concept. - -See https://github.com/ros2/rclpy/pull/1391 for more details. - -``Rosbag2`` -^^^^^^^^^^^ - -Action introspection Rosbag2 support -"""""""""""""""""""""""""""""""""""" - -Allow to record and play actions from a rosbag. - -See https://github.com/ros2/rosbag2/pull/1955 for more information. -Design document https://github.com/ros2/rosbag2/pull/1928. -Visit :ref:`Managing Action Data ` to learn more about this feature. - -Progress bar for ``ros2 bag play`` -"""""""""""""""""""""""""""""""""" - -Added a progress bar for ``ros2 bag play`` CLI, showing the bag time and duration, similar to -what is seen in ROS 1. - -See https://github.com/ros2/rosbag2/pull/1836 for more details. - -Added support for replaying multiple bags with ``ros2 bag play`` CLI -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -To replay multiple bags, use the new ``-i, --input`` CLI option: - -.. code-block:: console - - $ ros2 bag play -i bag1 -i bag2 -i bag3 [storage_id] - -See https://github.com/ros2/rosbag2/pull/1848 for more information. - -Added support for replaying messages chronologically based on their publication timestamp -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -This is exposed through ``ros2 bag play`` with a new ``--message-order {received,sent}`` option. -The default behavior is to play messages in the order they were received. - -See https://github.com/ros2/rosbag2/pull/1876 for more information. - -Make snapshot writing into a new file each time it is triggered -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1842 for more details. - -New ``--sort`` CLI option in the ``ros2 bag info`` command -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -With new ``--sort`` CLI option user will be able to sort topics, services and actions by name, topic type or number of recorded messages. - -See https://github.com/ros2/rosbag2/pull/1804 for more details. - -Show size contribution of each topic with ``ros2 bag info`` -""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -With new ``--size-contribution`` option together with ``ros2 bag info -v`` user will be able to see the size contribution of each topic in the bag file. - -See https://github.com/ros2/rosbag2/pull/1726 for more information. - -Added ``--log-level`` option to ``ros2 bag play`` and ``ros2 bag record`` to allow printing debug messages -"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" - -See https://github.com/ros2/rosbag2/pull/1625 for more details. - -``rosidl_rust`` -^^^^^^^^^^^^^^^ - -Added ``rosidl_rust`` -""""""""""""""""""""" - -A Rust idl generator was added to the list of default code generators. - -See https://github.com/ros2/ros2/pull/1674 for more details. - -``ros2`` -^^^^^^^^ - -Switch to using Pixi/Conda for Windows -"""""""""""""""""""""""""""""""""""""" - -This allows to easily manage dependencies, and to update them in the future. -The installation process is significantly simplified. -Instead of dozens of steps to install dependencies, it is just a couple of commands. -It is much easier to update dependencies. -The dependencies are installed in individual workspaces, with no “global” installation. - -See https://github.com/ros2/ci/pull/802 and https://github.com/ros2/ros2/pull/1642 for more details. -Visit :doc:`Windows source install instructions <../Installation/Alternatives/Windows-Development-Setup>` to install it on Windows. - -Support topic instances in DDS topics -""""""""""""""""""""""""""""""""""""" - -Topic instances are a way of multiplexing the transmission of updates of several objects of the same logical kind over the same resource, i.e. the topic. - -See https://github.com/ros2/ros2/issues/1538 for more information. -You can also check the documentation: https://github.com/ros2/design/pull/340/files. - -Changes since the Jazzy release -------------------------------- - -``common_interfaces`` -^^^^^^^^^^^^^^^^^^^^^ - -Added NV12 to pixel formats -""""""""""""""""""""""""""" - -Added NV12 to pixel formats, which is a common output format of hardware-accelerated decoders. - -See https://github.com/ros2/common_interfaces/pull/253 for more details. - -``rclcpp`` -^^^^^^^^^^ - -Consistent behavior for Subordinate nodes -""""""""""""""""""""""""""""""""""""""""" - -Inconsistent behavior of subordinate nodes was fixed. -The subordinate node is a secondary node associated with a primary node, that shares the same underlying context and resources while maintaining a separate name and namespace. -The behavioral modification may affect existing applications relying on the previous implementation: - -1. Generic clients created from a subordinate node now correctly respect the subordinate node's sub-namespace -2. Parameters obtained using a subordinate node now correctly use the (parent) node's ``rclcpp::node_interfaces::NodeParametersInterface`` - -See https://github.com/ros2/rclcpp/pull/2822 for more details. - -``rmw_connextdds_cpp`` -^^^^^^^^^^^^^^^^^^^^^^ - -Version bumped to 7.3 -""""""""""""""""""""" - -The RTI Connext DDS version was bumped to 7.3.0. - -See https://github.com/ros2/ci/pull/811 for more details. - -``Connextmicro`` -^^^^^^^^^^^^^^^^ - -deprecated Connextmicro -""""""""""""""""""""""" - -The RTI Connext Micro RMW package, ``rmw_connextddsmicro``, is going to stop receiving updates in Kilted Kaiju, and be removed in a future ROS 2 release. - -See https://github.com/ros2/rmw_connextdds/pull/182 for more information. - -``rosidl_dynamic_typesupport`` -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Removing support for float128 -""""""""""""""""""""""""""""" - -Removed support for float128 because there are inconsistencies in the definition. - -See https://github.com/ros2/rosidl_dynamic_typesupport/issues/11 for more details. - -``rmw_fastrtps_cpp`` -^^^^^^^^^^^^^^^^^^^^ - -Renaming package from fastrtps to fastdds -""""""""""""""""""""""""""""""""""""""""" - -``fastrtps`` was renamed to ``fastdds``. -The names of the rmw implementations stay the same. -XML Profile ENV strings will change. - -See https://github.com/ros2/ros2/pull/1641 for more details. - -ament_target_dependencies is deprecated -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The CMake macro ``ament_target_dependencies()`` has been deprecated in favor of ``target_link_libraries()`` with modern CMake targets. -The macro still works, but it emits a CMake deprecation warning at build time like this: - -.. code-block:: - - CMake Deprecation Warning at [...]/ament_cmake_target_dependencies/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:89 (message): - ament_target_dependencies() is deprecated. Use target_link_libraries() - with modern CMake targets instead. Try replacing this call with: - - target_link_libraries([...] PUBLIC - [...] - ) - -Try replacing the ``ament_target_dependencies()`` call with the ``target_link_libraries()`` call suggested by the warning. -For more information see `ament/ament_cmake#572 `__ and `ament/ament_cmake#292 `__. - -Note that the deprecation warning suggests a call to ``target_link_libraries`` with a scope keyword like ``PUBLIC``, ``PRIVATE``, or ``INTERFACE``. -If you have already used ``target_link_libraries()`` on this target without a scope keyword, then you must remove the scope keyword from the suggested call. -This can happen when using some ``ament_cmake`` macros, like ``ament_add_gtest``, which use the plain version of ``target_link_libraries`` internally. -You will know if you need to remove the keyword because CMake will emit an error saying: - -.. code-block:: - - All uses of target_link_libraries with a target must be either all-keyword or all-plain. - -For more information, see `ament/ament_cmake#580 `__. - - -``launch`` -^^^^^^^^^^ - -``PathJoinSubstitution`` -"""""""""""""""""""""""" - -``PathJoinSubstitution`` now supports concatenating strings or substitutions into a single path component. -For example: - -.. code-block:: python - - PathJoinSubstitution(['robot_description', 'urdf', [LaunchConfiguration('model'), '.xacro']]) - -If the ``model`` launch configuration was set to ``my_model``, this would result in a path equal to: - -.. code-block:: python - - 'robot_description/urdf/my_model.xacro' - -For more information, see `ros2/launch#835 `__ and `ros2/launch#838 `__. - -``rmw_zenoh_cpp`` -^^^^^^^^^^^^^^^^^ - -``Tier 1`` -"""""""""" - -The ``rmw_zenoh_cpp`` is now considered Tier 1. -There are many PRs (summarized in `ros2/rmw_zenoh#265 `__) in the ROS 2 core packages, such as: - - * Make the rmw pass all core tests. - * Implement and document security - * Make it work in the Tier 1 platforms. - * Added Quality declarations - * Added to REP 2005 - * A dedicated nightly CI job - * Among others - -For more information see https://github.com/ros2/rmw_zenoh/issues/265. - -Development progress --------------------- - -For progress on the development of Kiltled Kaiju, see `this project board `__. - -For the broad process followed by Kilted Kaiju, see the :doc:`process description page `. - -Release Timeline ----------------- - - December, 2024 - Platform decisions - REP 2000 is updated with the target platforms and major dependency versions. - - Mon. April 7, 2025 - Alpha + RMW freeze - Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. - - Mon. April 14, 2025 - Freeze - API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. - Only bug fix releases should be made after this point. - New packages can be released independently. - - Mon. April 21, 2025 - Branch - Branch from Rolling Ridley. - ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. - Kilted development shifts from ``ros-rolling-*`` packages to ``ros-kilted-*`` packages. - - Mon. April 28, 2025 - Beta - Updated releases of ROS Desktop [2]_ packages available. - Call for general testing. - - Thu, May 1, 2025 - Kick off of Tutorial Party - Tutorials hosted at https://github.com/ros2/kilted_tutorial_party are open for community testing. - - Mon. May 12, 2025 - Release Candidate - Release Candidate packages are built. - Updated releases of ROS Desktop [2]_ packages available. - - Mon. May 19, 2025 - Distro Freeze - Freeze all Kilted branches on all `ROS 2 desktop packages `__ and ``rosdistro``. - No pull requests for any ``kilted`` branch or targeting ``kilted/distribution.yaml`` in ``rosdistro`` repo will be merged. - - Fri. May 23, 2025 - General Availability - Release announcement. - `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Kilted pull requests. - -.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. +.. redirect-from:: + + Releases/Release-Kilted-Kaiju + +.. _kilted-release: + +Kilted Kaiju (codename 'kilted'; May, 2025) +=========================================== + +.. toctree:: + :hidden: + + Kilted-Kaiju-Complete-Changelog + +.. contents:: Table of Contents + :depth: 2 + :local: + +*Kilted Kaiju* is the eleventh release of ROS 2. +What follows is highlights of the important changes and features in Kilted Kaiju since the last release. +For a list of all of the changes since Jazzy, see the :doc:`long form changelog ` + +Supported Platforms +------------------- + +Kilted Kaiju supports the following platforms according to `the platform support tiers <../The-ROS2-Project/Platform-Support-Tiers>`: + +Tier 1 platforms: + +* Ubuntu 24.04 (Noble): ``amd64`` and ``arm64`` +* Windows 10 (Visual Studio 2019): ``amd64`` + +Tier 2 platforms: + +* RHEL 9: ``amd64`` + +Tier 3 platforms: + +* macOS: ``amd64`` +* Debian Bookworm: ``amd64`` + +Targeted platforms: + ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ +| Architecture | Ubuntu Noble | Windows 10 | RHEL 9 | macOS | Debian Bookworm | OpenEmbedded / | +| | (24.04) | (VS2019) | | | (12) | Yocto Project | ++==============+===================+===============+===================+===========+=================+================+ +| amd64 | Tier 1 [d][a][s] | Tier 1 [a][s] | Tier 2 [d][a][s] | Tier 3 [s]| Tier 3 [s] | Tier 3 [s] | ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ +| arm64 | Tier 1 [d][a][s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ +| arm32 | Tier 3 [s] | | | | Tier 3 [s] | Tier 3 [s] | ++--------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ + +The following indicators show what delivery mechanisms are available for +each platform. + +\" \[d\] \" Distribution-specific (Debian, RPM, etc.) packages will be +provided for this platform for packages submitted to the rosdistro. + +\" \[a\] \" Binary releases are provided as a single archive per +platform containing all packages in the Jazzy ROS 2 repos file[^14]. + +\" \[s\] \" Compilation from source. + +Middleware Implementation Support: + ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| Middleware Library | Middleware Provider | Support Level | Platforms | Architectures | ++===========================+=========================+===============+============================+===============================+ +| rmw_fastrtps_cpp* | eProsima Fast-DDS | Tier 1 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_connextdds | RTI Connext | Tier 1 | Ubuntu, Windows, and macOS | All Architectures except arm64| ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_cyclonedds_cpp | Eclipse Cyclone DDS | Tier 1 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_zenoh_cpp | Eclipse Zenoh | Tier 1 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_fastrtps_dynamic_cpp | eProsima Fast-DDS | Tier 2 | All Platforms | All Architectures | ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ +| rmw_gurumdds_cpp | GurumNetworks GurumDDS | Tier 3 | Ubuntu and Windows | All Architectures except arm32| ++---------------------------+-------------------------+---------------+----------------------------+-------------------------------+ + +\" \* \" means default RMW implementation. + +Middleware implementation support is dependent upon the platform support +tier. For example a Tier 1 middleware implementation on a Tier 2 +platform can only receive Tier 2 support. + +Minimum language requirements: + +- C++17 +- Python 3.9 + +Dependency Requirements: + ++---------------+-------------------------------+-------------------------------------------------------------+ +| | Required Support | Recommended Support | ++===============+===============+===============+==========+==========+==================+====================+ +| Package | Ubuntu Noble | Windows 10** | RHEL 9 | macOS** | Debian Bookworm | OpenEmbedded** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| CMake | 3.28.3 | 3.28.3 | 3.26.5 | 3.31.1 | 3.25.1 | 3.22.3 | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| EmPY | 3.3.4 | 3.3.4 | 3.3.4a | 3.3.4 | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Gazebo | Ionic* | N/A | N/A | Ionic* | Ionic* | N/A | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| NumPy | 1.26.4 | 1.26.4 | 1.20.1 | 2.1.3 | 1.24.2 | N/A | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Ogre | 1.12.10 | N/A | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| OpenCV | 4.6.0 | 4.9.0 | 4.6.0 | 4.10.0 | 4.6.0 | 4.1.0 / 3.2.0*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| OpenSSL | 3.0.13 | 3.3.2 | 3.2.2 | 1.1.1w | 3.0.15 | 1.1.1d / 1.1.1b*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Python | 3.12.3 | 3.12.3 | 3.9.19 | 3.13.0 | 3.11.2 | 3.8.2 / 3.7.5*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| Qt | 5.15.13 | 5.15.8 | 5.15.9 | 5.15.16 | 5.15.8 | 5.14.1 / 5.12.5*** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| | **Linux only** | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| PCL | 1.14.0 | N/A | 1.12.0 | 1.14.1 | 1.13.0 | 1.10.0 | ++---------------+---------------+---------------+----------+----------+------------------+--------------------+ +| **RMW Middleware** | ++---------------------------------------------------------------------+---------------------------------------+ +| Connext DDS | 7.3.0.0 | N/A | ++---------------+-----------------------------------------------------+---------------------------------------+ +| Cyclone DDS | 0.10.5 | ++---------------+---------------------------------------------------------------------------------------------+ +| Fast-DDS | 2.14.4 | ++---------------+-------------------------------+-------------------------------------------------------------+ +| Gurum DDS | 4.2.0 | N/A | ++---------------+-------------------------------+-------------------------------------------------------------+ +| Zenoh | 1.0.4 | ++---------------+---------------------------------------------------------------------------------------------+ + +\" \* \" means that this is not the upstream version (available on the +official Operating System repositories) but a package distributed by +OSRF or the community (package built and distributed on custom +repositories). + +\" \*\* \" means that the dependency may see multiple version changes, +because the dependency uses a package manager that continually updates +the dependency without a stable API. + +\" \*\*\* \" webOS OSE provides this different version. + +This document only captures the version at the first release of a ROS +distribution and will not be updated as the dependencies move forward. +These versions are thus a low watermark. + +Package manager use for dependencies: + +- Ubuntu, Debian: apt, pip +- Windows: pixi/conda, pip +- macOS: Homebrew, pip +- RHEL: dnf +- OpenEmbedded: opkg + +Build System Support: + +- ament_cmake +- cargo +- cmake +- setuptools + +Installation +------------ + +`Install Kilted Kaiju <../../kilted/Installation.html>`__ + +Supported Gazebo Release +------------------------ +For Kilted Kaiju, the recommended Gazebo release is `Ionic `__. + +New features in this ROS 2 release +---------------------------------- + +``ament_cmake_ros`` +^^^^^^^^^^^^^^^^^^^ + +Add rmw_test_fixture for supporting RMW-isolated testing +"""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +Included two new packages which provide an extensible mechanism for creating a test fixture for RMW-based communication isolation. +It is modeled closely after the rmw and rmw_implementation API. + +The ``rmw_test_fixture`` package currently provides only the API, which could be implemented by an RMW provider for configuring their RMW for a test to run. + +The ``rmw_test_fixture_implementation`` package provides the entry point for discovering, loading, and invoking the appropriate extension. + +See https://github.com/ros2/ament_cmake_ros/pull/21 for more details. + +``common_interfaces`` +^^^^^^^^^^^^^^^^^^^^^ + +New nav_msgs/Goals message +"""""""""""""""""""""""""" + +A new message type, {interface(nav_msgs/msg/Goals)}, has been introduced to support an array of navigation goals within the nav_msgs package. + +See https://github.com/ros2/common_interfaces/pull/269 for more details. + +``ros2cli`` +^^^^^^^^^^^ + +Action introspection +"""""""""""""""""""" + +This allows to instrospect an action with the command line. +Using ``ros2cli`` tools: ``ros2 action echo ``. + +See https://github.com/ros2/ros2cli/pull/978 for more information. +Visit :ref:`ros2 action echo ` and :doc:`Action Introspection <../../ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection>` to learn more about this feature. + +``rclcpp`` +^^^^^^^^^^ + +Action generic client +""""""""""""""""""""" + +Support action generic client, this is used to support actions in rosbag2. + +See https://github.com/ros2/rclcpp/pull/2759 for more details. + +``rclpy`` +^^^^^^^^^ + +Static Type Checking +"""""""""""""""""""" + +Added static type hints to ``ActionClient`` and ``ActionServer``. + +See https://github.com/ros2/rclpy/pull/1349 for more details. + +Add support for `generics `_ in ``pub/sub/client/server/actions``, ``Future/Task``, and ``Parameter``. + +``Publisher``, ``Subscription``, ``Server``, ``Task``, and ``Parameter`` should need no updates to add support for generics. + +``Client`` will need to be updated to resemble the following to get the improved type checking. + +.. code-block:: python + + self._get_parameter_client: Client[GetParameters.Request, + GetParameters.Response] = self.node.create_client( + GetParameters, '/get_parameters', + qos_profile=qos_profile, callback_group=callback_group) + +``ActionClient`` will need to be updated to resemble the following to get the improved type checking. + +.. code-block:: python + + ac: ActionClient[Fibonacci.Goal, + Fibonacci.Result, + Fibonacci.Feedback] = ActionClient(self.node, Fibonacci, 'fibonacci') + +``Future`` will need to be updated to resemble the following to get the improved type checking. + +.. code-block:: python + + log_msgs_future: Future[bool] = Future() + +See https://github.com/ros2/rclpy/pull/1239, https://github.com/ros2/rclpy/pull/1275, https://github.com/ros2/rclpy/pull/1246, and https://github.com/ros2/rclpy/pull/1254/files for more details. + +Various other small improvements and corrections have also been made throughout all of ``rclpy``. + +Python types can be statically checked using `ament_mypy `_ which wraps `mypy `_. + +EventsExecutor +"""""""""""""" + +Support an experimental events executor for ``rclpy``, which is a port of the original ``rclcpp`` events executor concept. + +See https://github.com/ros2/rclpy/pull/1391 for more details. + +``Rosbag2`` +^^^^^^^^^^^ + +Action introspection Rosbag2 support +"""""""""""""""""""""""""""""""""""" + +Allow to record and play actions from a rosbag. + +See https://github.com/ros2/rosbag2/pull/1955 for more information. +Design document https://github.com/ros2/rosbag2/pull/1928. +Visit :ref:`Managing Action Data ` to learn more about this feature. + +Progress bar for ``ros2 bag play`` +"""""""""""""""""""""""""""""""""" + +Added a progress bar for ``ros2 bag play`` CLI, showing the bag time and duration, similar to +what is seen in ROS 1. + +See https://github.com/ros2/rosbag2/pull/1836 for more details. + +Added support for replaying multiple bags with ``ros2 bag play`` CLI +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +To replay multiple bags, use the new ``-i, --input`` CLI option: + +.. code-block:: console + + $ ros2 bag play -i bag1 -i bag2 -i bag3 [storage_id] + +See https://github.com/ros2/rosbag2/pull/1848 for more information. + +Added support for replaying messages chronologically based on their publication timestamp +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +This is exposed through ``ros2 bag play`` with a new ``--message-order {received,sent}`` option. +The default behavior is to play messages in the order they were received. + +See https://github.com/ros2/rosbag2/pull/1876 for more information. + +Make snapshot writing into a new file each time it is triggered +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1842 for more details. + +New ``--sort`` CLI option in the ``ros2 bag info`` command +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +With new ``--sort`` CLI option user will be able to sort topics, services and actions by name, topic type or number of recorded messages. + +See https://github.com/ros2/rosbag2/pull/1804 for more details. + +Show size contribution of each topic with ``ros2 bag info`` +""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +With new ``--size-contribution`` option together with ``ros2 bag info -v`` user will be able to see the size contribution of each topic in the bag file. + +See https://github.com/ros2/rosbag2/pull/1726 for more information. + +Added ``--log-level`` option to ``ros2 bag play`` and ``ros2 bag record`` to allow printing debug messages +"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" + +See https://github.com/ros2/rosbag2/pull/1625 for more details. + +``rosidl_rust`` +^^^^^^^^^^^^^^^ + +Added ``rosidl_rust`` +""""""""""""""""""""" + +A Rust idl generator was added to the list of default code generators. + +See https://github.com/ros2/ros2/pull/1674 for more details. + +``ros2`` +^^^^^^^^ + +Switch to using Pixi/Conda for Windows +"""""""""""""""""""""""""""""""""""""" + +This allows to easily manage dependencies, and to update them in the future. +The installation process is significantly simplified. +Instead of dozens of steps to install dependencies, it is just a couple of commands. +It is much easier to update dependencies. +The dependencies are installed in individual workspaces, with no “global” installation. + +See https://github.com/ros2/ci/pull/802 and https://github.com/ros2/ros2/pull/1642 for more details. +Visit :doc:`Windows source install instructions <../Installation/Alternatives/Windows-Development-Setup>` to install it on Windows. + +Support topic instances in DDS topics +""""""""""""""""""""""""""""""""""""" + +Topic instances are a way of multiplexing the transmission of updates of several objects of the same logical kind over the same resource, i.e. the topic. + +See https://github.com/ros2/ros2/issues/1538 for more information. +You can also check the documentation: https://github.com/ros2/design/pull/340/files. + +Changes since the Jazzy release +------------------------------- + +``common_interfaces`` +^^^^^^^^^^^^^^^^^^^^^ + +Added NV12 to pixel formats +""""""""""""""""""""""""""" + +Added NV12 to pixel formats, which is a common output format of hardware-accelerated decoders. + +See https://github.com/ros2/common_interfaces/pull/253 for more details. + +``rclcpp`` +^^^^^^^^^^ + +Consistent behavior for Subordinate nodes +""""""""""""""""""""""""""""""""""""""""" + +Inconsistent behavior of subordinate nodes was fixed. +The subordinate node is a secondary node associated with a primary node, that shares the same underlying context and resources while maintaining a separate name and namespace. +The behavioral modification may affect existing applications relying on the previous implementation: + +1. Generic clients created from a subordinate node now correctly respect the subordinate node's sub-namespace +2. Parameters obtained using a subordinate node now correctly use the (parent) node's ``rclcpp::node_interfaces::NodeParametersInterface`` + +See https://github.com/ros2/rclcpp/pull/2822 for more details. + +``rmw_connextdds_cpp`` +^^^^^^^^^^^^^^^^^^^^^^ + +Version bumped to 7.3 +""""""""""""""""""""" + +The RTI Connext DDS version was bumped to 7.3.0. + +See https://github.com/ros2/ci/pull/811 for more details. + +``Connextmicro`` +^^^^^^^^^^^^^^^^ + +deprecated Connextmicro +""""""""""""""""""""""" + +The RTI Connext Micro RMW package, ``rmw_connextddsmicro``, is going to stop receiving updates in Kilted Kaiju, and be removed in a future ROS 2 release. + +See https://github.com/ros2/rmw_connextdds/pull/182 for more information. + +``rosidl_dynamic_typesupport`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Removing support for float128 +""""""""""""""""""""""""""""" + +Removed support for float128 because there are inconsistencies in the definition. + +See https://github.com/ros2/rosidl_dynamic_typesupport/issues/11 for more details. + +``rmw_fastrtps_cpp`` +^^^^^^^^^^^^^^^^^^^^ + +Renaming package from fastrtps to fastdds +""""""""""""""""""""""""""""""""""""""""" + +``fastrtps`` was renamed to ``fastdds``. +The names of the rmw implementations stay the same. +XML Profile ENV strings will change. + +See https://github.com/ros2/ros2/pull/1641 for more details. + +ament_target_dependencies is deprecated +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The CMake macro ``ament_target_dependencies()`` has been deprecated in favor of ``target_link_libraries()`` with modern CMake targets. +The macro still works, but it emits a CMake deprecation warning at build time like this: + +.. code-block:: + + CMake Deprecation Warning at [...]/ament_cmake_target_dependencies/share/ament_cmake_target_dependencies/cmake/ament_target_dependencies.cmake:89 (message): + ament_target_dependencies() is deprecated. Use target_link_libraries() + with modern CMake targets instead. Try replacing this call with: + + target_link_libraries([...] PUBLIC + [...] + ) + +Try replacing the ``ament_target_dependencies()`` call with the ``target_link_libraries()`` call suggested by the warning. +For more information see `ament/ament_cmake#572 `__ and `ament/ament_cmake#292 `__. + +Note that the deprecation warning suggests a call to ``target_link_libraries`` with a scope keyword like ``PUBLIC``, ``PRIVATE``, or ``INTERFACE``. +If you have already used ``target_link_libraries()`` on this target without a scope keyword, then you must remove the scope keyword from the suggested call. +This can happen when using some ``ament_cmake`` macros, like ``ament_add_gtest``, which use the plain version of ``target_link_libraries`` internally. +You will know if you need to remove the keyword because CMake will emit an error saying: + +.. code-block:: + + All uses of target_link_libraries with a target must be either all-keyword or all-plain. + +For more information, see `ament/ament_cmake#580 `__. + + +``launch`` +^^^^^^^^^^ + +``PathJoinSubstitution`` +"""""""""""""""""""""""" + +``PathJoinSubstitution`` now supports concatenating strings or substitutions into a single path component. +For example: + +.. code-block:: python + + PathJoinSubstitution(['robot_description', 'urdf', [LaunchConfiguration('model'), '.xacro']]) + +If the ``model`` launch configuration was set to ``my_model``, this would result in a path equal to: + +.. code-block:: python + + 'robot_description/urdf/my_model.xacro' + +For more information, see `ros2/launch#835 `__ and `ros2/launch#838 `__. + +``rmw_zenoh_cpp`` +^^^^^^^^^^^^^^^^^ + +``Tier 1`` +"""""""""" + +The ``rmw_zenoh_cpp`` is now considered Tier 1. +There are many PRs (summarized in `ros2/rmw_zenoh#265 `__) in the ROS 2 core packages, such as: + + * Make the rmw pass all core tests. + * Implement and document security + * Make it work in the Tier 1 platforms. + * Added Quality declarations + * Added to REP 2005 + * A dedicated nightly CI job + * Among others + +For more information see https://github.com/ros2/rmw_zenoh/issues/265. + +Development progress +-------------------- + +For progress on the development of Kiltled Kaiju, see `this project board `__. + +For the broad process followed by Kilted Kaiju, see the :doc:`process description page `. + +Release Timeline +---------------- + + December, 2024 - Platform decisions + REP 2000 is updated with the target platforms and major dependency versions. + + Mon. April 7, 2025 - Alpha + RMW freeze + Preliminary testing and stabilization of ROS Base [1]_ packages, and API and feature freeze for RMW provider packages. + + Mon. April 14, 2025 - Freeze + API and feature freeze for ROS Base [1]_ packages in Rolling Ridley. + Only bug fix releases should be made after this point. + New packages can be released independently. + + Mon. April 21, 2025 - Branch + Branch from Rolling Ridley. + ``rosdistro`` is reopened for Rolling PRs for ROS Base [1]_ packages. + Kilted development shifts from ``ros-rolling-*`` packages to ``ros-kilted-*`` packages. + + Mon. April 28, 2025 - Beta + Updated releases of ROS Desktop [2]_ packages available. + Call for general testing. + + Thu, May 1, 2025 - Kick off of Tutorial Party + Tutorials hosted at https://github.com/ros2/kilted_tutorial_party are open for community testing. + + Mon. May 12, 2025 - Release Candidate + Release Candidate packages are built. + Updated releases of ROS Desktop [2]_ packages available. + + Mon. May 19, 2025 - Distro Freeze + Freeze all Kilted branches on all `ROS 2 desktop packages `__ and ``rosdistro``. + No pull requests for any ``kilted`` branch or targeting ``kilted/distribution.yaml`` in ``rosdistro`` repo will be merged. + + Fri. May 23, 2025 - General Availability + Release announcement. + `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Kilted pull requests. + +.. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. .. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file diff --git a/source/Get-Started/Releases/Release-Lyrical-Luth.rst b/source/Get-Started/Releases/Release-Lyrical-Luth.rst index 9b670d48f9c..c68f3661d33 100644 --- a/source/Get-Started/Releases/Release-Lyrical-Luth.rst +++ b/source/Get-Started/Releases/Release-Lyrical-Luth.rst @@ -132,7 +132,7 @@ This class uses significantly less CPU compared to the default ``SingleThreadedE if __name__ == '__main__': asyncio.run(_main()) -See :doc:`../Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python` and `ros2/rclpy#1620 `_ for more details. +See :doc:`../../Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python` and `ros2/rclpy#1620 `_ for more details. Publish messages without copying data using ``rosidl::Buffer`` ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -147,9 +147,9 @@ Note that only publishers and subscribers using ``rmw_fastrtps_cpp`` may use thi Using a custom hardware accelerator or machine learning library? You can benefit from this too. -See :doc:`../Tutorials/Advanced/Writing-a-Buffer-Backend` to learn how to implement your own ``rosidl::BufferBackend``. +See :doc:`../../Tutorials/Advanced/Writing-a-Buffer-Backend` to learn how to implement your own ``rosidl::BufferBackend``. -See :doc:`../Concepts/Intermediate/About-Buffer-Backends` and :doc:`../How-To-Guides/Using-Buffer-Backends` for more details. +See :doc:`../../Concepts/Intermediate/About-Buffer-Backends` and :doc:`../../How-To-Guides/Using-Buffer-Backends` for more details. Annotate types in YAML Parameter Files ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/source/Get-Started/Releases/lyrical/supported-platforms.rst b/source/Get-Started/Releases/lyrical/supported-platforms.rst index 423cb4b158d..3dc2513b400 100644 --- a/source/Get-Started/Releases/lyrical/supported-platforms.rst +++ b/source/Get-Started/Releases/lyrical/supported-platforms.rst @@ -1,7 +1,7 @@ Lyrical Luth Supported Platforms ================================ -ROS Lyrical supports the following platforms according to :doc:`the platform support tiers <../../The-ROS2-Project/Platform-Support-Tiers>`: +ROS Lyrical supports the following platforms according to :doc:`the platform support tiers <../../../The-ROS2-Project/Platform-Support-Tiers>`: +--------------+-------------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ | Architecture | Ubuntu Resolute | Ubuntu Noble* | Windows 11 | RHEL 10 | macOS | Debian Trixie* | OpenEmbedded / | @@ -14,7 +14,7 @@ ROS Lyrical supports the following platforms according to :doc:`the platform sup | arm32 | Tier 3 | Tier 3 | | | | Tier 3 | Tier 3 | +--------------+-------------------+-------------------+---------------+-------------------+-----------+-----------------+----------------+ -* ``*`` Early EOL per :doc:`the platform EOL policy <../../The-ROS2-Project/Platform-EOL-Policy>` +* ``*`` Early EOL per :doc:`the platform EOL policy <../../../The-ROS2-Project/Platform-EOL-Policy>` * Ubuntu Noble is supported until ``2029-06-01`` * Debian Trixie is supported until ``2028-08-09`` * ``[d]`` You may install ROS Lyrical on this platform using Distribution-specific packaegs (Debian, RPM, etc.). diff --git a/source/Get-Started/Releases/makoa/supported-platforms.rst b/source/Get-Started/Releases/makoa/supported-platforms.rst index 70e933e48f6..ef0a127f8d3 100644 --- a/source/Get-Started/Releases/makoa/supported-platforms.rst +++ b/source/Get-Started/Releases/makoa/supported-platforms.rst @@ -1,7 +1,7 @@ Makoa Mata-mata Supported Platforms =================================== -ROS Makoa supports the following platforms according to :doc:`the platform support tiers <../../The-ROS2-Project/Platform-Support-Tiers>`: +ROS Makoa supports the following platforms according to :doc:`the platform support tiers <../../../The-ROS2-Project/Platform-Support-Tiers>`: TODO diff --git a/source/How-To-Guides/Using-Buffer-Backends.rst b/source/How-To-Guides/Using-Buffer-Backends.rst index 585e6ba7aab..87cf192a786 100644 --- a/source/How-To-Guides/Using-Buffer-Backends.rst +++ b/source/How-To-Guides/Using-Buffer-Backends.rst @@ -315,7 +315,7 @@ separate buffer backend name. Use the same RMW implementation for publisher and subscriber. Buffer descriptors are serialized through the RMW's normal type-support pipeline, so the ordinary advice for -:doc:`multiple RMW implementations ` +:doc:`multiple RMW implementations <../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` applies: set ``RMW_IMPLEMENTATION`` consistently. 3. Keep backend versions aligned with ROS 2 core @@ -376,12 +376,12 @@ serialization, which is visible at the default log level. Interaction with other transport features ----------------------------------------- -* :doc:`Loaned messages ` operate at a +* :doc:`Loaned messages <../ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages>` operate at a different layer: they let the RMW own the *message* memory, while ``rosidl::Buffer`` backends control the storage of individual variable-length array fields. The two features can be combined when both the RMW and the backend support it. -* :doc:`Intra-process communication <../Tutorials/Demos/Intra-Process-Communication>` +* :doc:`Intra-process communication <../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>` is orthogonal: a backend may implement its own intra-process fast path (the CUDA backend does), but the decision is up to the backend. diff --git a/source/Integrations-and-related/Related-Projects.rst b/source/Integrations-and-related/Related-Projects.rst index 177e85ed778..3760714cd66 100644 --- a/source/Integrations-and-related/Related-Projects.rst +++ b/source/Integrations-and-related/Related-Projects.rst @@ -1,53 +1,53 @@ -.. redirect-from:: - - Related-Projects - - -Related Projects -================ - -Gazebo ------- - -**Gazebo** `(gazebosim.org) `_ and its predecessor Gazebo Classic are the first open source choice for 3D physics simulation of ROS-based robots. - -Large Community Projects ------------------------- - -Large community projects involve multiple developers from all over the globe and are typically backed by a dedicated working group (cf. :doc:`../The-ROS2-Project/Governance`). - -* **ros2_control** `(control.ros.org) `_: Flexible framework for real-time control of robots implemented with ROS 2. -* **Navigation2** `(nav2.org) `_: Comprehensive and flexible navigation stack for mobile robots using ROS 2. -* **MoveIt** `(moveit.ai) `_: A rich platform for building manipulation applications featuring advanced kinematics, motion planning, control, collision checking, and much more. -* **micro-ROS** `(micro.ros.org) `_: A platform for putting ROS 2 onto microcontrollers, starting at less than 100 kB of RAM. - -Community ``rosidl::Buffer`` backends -------------------------------------- - -Out-of-tree :doc:`buffer backend ` plugins let ``rosidl::Buffer`` fields (``uint8[]``, etc.) use vendor-specific memory domains such as GPU memory. -For background, see :doc:`How-To-Guides/Using-Buffer-Backends` and :doc:`Tutorials/Advanced/Writing-a-Buffer-Backend`. - -* **rosidl_buffer_backends** `(github.com/ros2/rosidl_buffer_backends) `_: CUDA buffer backend implementation for ``rosidl::Buffer`` plus ``tensor_msgs/msg/ExperimentalTensor`` and ``torch_conversions`` helpers, enabling zero-copy GPU memory sharing between ROS 2 publishers and subscribers. -* **rosidl_buffer_backends_tutorials** `(github.com/ros2/rosidl_buffer_backends_tutorials) `_: End-to-end demos exercising ``rosidl_buffer_backends``, including the ``robot_arm_demo`` featured in :doc:`Tutorials/Demos/GPU-Buffer-Transport`. - -Further Community Projects --------------------------- - -The global ROS community develops and maintains hundreds of further packages on top of the core ROS 2 stack. -Some of them come with their own websites for documentation. -Your best entry point to discover these works is the **ROS Index** `(index.ros.org) `_. - -*Hint for developers:* If you maintain a ``README.md`` file in the root of your package folder (which is not necessarily the root of your repository), this file is rendered into the overview page of your package at `index.ros.org `_. -The file may be used for documenting your package and supersedes the package documentation pages in the ROS Wiki from ROS 1. -See the `fmi_adapter package `_ as an example. - -Company-driven Projects ------------------------ - -.. toctree:: - :maxdepth: 1 - - Related-Projects/Intel-ROS2-Projects - Related-Projects/Nvidia-ROS2-Projects - Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge +.. redirect-from:: + + Related-Projects + + +Related Projects +================ + +Gazebo +------ + +**Gazebo** `(gazebosim.org) `_ and its predecessor Gazebo Classic are the first open source choice for 3D physics simulation of ROS-based robots. + +Large Community Projects +------------------------ + +Large community projects involve multiple developers from all over the globe and are typically backed by a dedicated working group (cf. :doc:`../The-ROS2-Project/Governance`). + +* **ros2_control** `(control.ros.org) `_: Flexible framework for real-time control of robots implemented with ROS 2. +* **Navigation2** `(nav2.org) `_: Comprehensive and flexible navigation stack for mobile robots using ROS 2. +* **MoveIt** `(moveit.ai) `_: A rich platform for building manipulation applications featuring advanced kinematics, motion planning, control, collision checking, and much more. +* **micro-ROS** `(micro.ros.org) `_: A platform for putting ROS 2 onto microcontrollers, starting at less than 100 kB of RAM. + +Community ``rosidl::Buffer`` backends +------------------------------------- + +Out-of-tree :doc:`buffer backend <../Concepts/Intermediate/About-Buffer-Backends>` plugins let ``rosidl::Buffer`` fields (``uint8[]``, etc.) use vendor-specific memory domains such as GPU memory. +For background, see :doc:`../How-To-Guides/Using-Buffer-Backends` and :doc:`../Tutorials/Advanced/Writing-a-Buffer-Backend`. + +* **rosidl_buffer_backends** `(github.com/ros2/rosidl_buffer_backends) `_: CUDA buffer backend implementation for ``rosidl::Buffer`` plus ``tensor_msgs/msg/ExperimentalTensor`` and ``torch_conversions`` helpers, enabling zero-copy GPU memory sharing between ROS 2 publishers and subscribers. +* **rosidl_buffer_backends_tutorials** `(github.com/ros2/rosidl_buffer_backends_tutorials) `_: End-to-end demos exercising ``rosidl_buffer_backends``, including the ``robot_arm_demo`` featured in :doc:`../Tutorials/Demos/GPU-Buffer-Transport`. + +Further Community Projects +-------------------------- + +The global ROS community develops and maintains hundreds of further packages on top of the core ROS 2 stack. +Some of them come with their own websites for documentation. +Your best entry point to discover these works is the **ROS Index** `(index.ros.org) `_. + +*Hint for developers:* If you maintain a ``README.md`` file in the root of your package folder (which is not necessarily the root of your repository), this file is rendered into the overview page of your package at `index.ros.org `_. +The file may be used for documenting your package and supersedes the package documentation pages in the ROS Wiki from ROS 1. +See the `fmi_adapter package `_ as an example. + +Company-driven Projects +----------------------- + +.. toctree:: + :maxdepth: 1 + + Related-Projects/Intel-ROS2-Projects + Related-Projects/Nvidia-ROS2-Projects + Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge Related-Projects/Visualizing-ROS-2-Data-With-Foxglove \ No newline at end of file diff --git a/source/Integrations-and-related/Simulators/MVSim/Installation-Ubuntu.rst b/source/Integrations-and-related/Simulators/MVSim/Installation-Ubuntu.rst index 4f716e4ed7b..241412cb271 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Installation-Ubuntu.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Installation-Ubuntu.rst @@ -24,10 +24,10 @@ Prerequisites ------------- It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../../Tutorials`. -In particular, :doc:`../../../Beginner-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` is a useful prerequisite. +In particular, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace` is a useful prerequisite. You should have a working ROS 2 installation. -Follow the :doc:`ROS 2 install instructions <../../../../Installation>` if needed. +Follow the :doc:`ROS 2 install instructions <../../../Get-Started/Installation>` if needed. Tasks ----- diff --git a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst index 7d4845c6243..7b175f09e6e 100644 --- a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst +++ b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst @@ -31,7 +31,7 @@ Prerequisites ------------- It is recommended to understand basic ROS principles covered in the beginner :doc:`../../../Tutorials`. -In particular, :doc:`../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim`, :doc:`../../../ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` and :doc:`../../../Developer-Tools/Launch/Creating-Launch-Files` are useful prerequisites. +In particular, :doc:`../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim`, :doc:`../../../ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`, :doc:`../../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` and :doc:`../../../Developer-Tools/Launch/Creating-Launch-Files` are useful prerequisites. .. tabs:: diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst index 616d2de3e20..514628727f1 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst @@ -1,443 +1,443 @@ -.. redirect-from:: - - How-To-Guides/Migrating-from-ROS1/Migrating-CPP-Package-Example - -Migrating a C++ Package Example -=============================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -This example shows how to migrate an example C++ package from ROS 1 to ROS 2. - -Prerequisites -------------- - -You need a working ROS 2 installation, such as :doc:`ROS {DISTRO} <../../Get-Started/Installation>`. - -The ROS 1 code --------------- - -Say you have a ROS 1 package called ``talker`` that uses ``roscpp`` in one node, called ``talker``. -This package is in a catkin workspace, located at ``~/ros1_talker``. - -Your ROS 1 workspace has the following directory layout: - -.. code-block:: console - - $ cd ~/ros1_talker - $ find . - . - ./src - ./src/talker - ./src/talker/package.xml - ./src/talker/CMakeLists.txt - ./src/talker/talker.cpp - -The files have the following content: - -``src/talker/package.xml``: - -.. code-block:: xml - - - - - talker - 0.0.0 - talker - Brian Gerkey - Apache-2.0 - catkin - roscpp - std_msgs - - -``src/talker/CMakeLists.txt``: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 2.8.3) - project(talker) - find_package(catkin REQUIRED COMPONENTS roscpp std_msgs) - catkin_package() - include_directories(${catkin_INCLUDE_DIRS}) - add_executable(talker talker.cpp) - target_link_libraries(talker ${catkin_LIBRARIES}) - install(TARGETS talker - RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}) - -``src/talker/talker.cpp``: - -.. code-block:: cpp - - #include - #include "ros/ros.h" - #include "std_msgs/String.h" - int main(int argc, char **argv) - { - ros::init(argc, argv, "talker"); - ros::NodeHandle n; - ros::Publisher chatter_pub = n.advertise("chatter", 1000); - ros::Rate loop_rate(10); - int count = 0; - std_msgs::String msg; - while (ros::ok()) - { - std::stringstream ss; - ss << "hello world " << count++; - msg.data = ss.str(); - ROS_INFO("%s", msg.data.c_str()); - chatter_pub.publish(msg); - ros::spinOnce(); - loop_rate.sleep(); - } - return 0; - } - -Migrating to ROS 2 ------------------- - -Let's start by creating a new workspace in which to work: - -.. code-block:: console - - $ mkdir ~/ros2_talker - $ cd ~/ros2_talker - -We'll copy the source tree from our ROS 1 package into that workspace, where we can modify it: - -.. code-block:: console - - $ mkdir src - $ cp -a ~/ros1_talker/src/talker src - -Now we'll modify the C++ code in the node. -The ROS 2 C++ library, called ``rclcpp``, provides a different API from that -provided by ``roscpp``. -The concepts are very similar between the two libraries, which makes the changes -reasonably straightforward to make. - -Included headers -~~~~~~~~~~~~~~~~ - -In place of ``ros/ros.h``, which gave us access to the ``roscpp`` library API, we -need to include ``rclcpp/rclcpp.hpp``, which gives us access to the ``rclcpp`` -library API: - -.. code-block:: cpp - - //#include "ros/ros.h" - #include "rclcpp/rclcpp.hpp" - -To get the ``std_msgs/String`` message definition, in place of -``std_msgs/String.h``, we need to include ``std_msgs/msg/string.hpp``: - -.. code-block:: cpp - - //#include "std_msgs/String.h" - #include "std_msgs/msg/string.hpp" - -Changing C++ library calls -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Instead of passing the node's name to the library initialization call, we do -the initialization, then pass the node name to the creation of the node object: - -.. code-block:: cpp - - // ros::init(argc, argv, "talker"); - // ros::NodeHandle n; - rclcpp::init(argc, argv); - auto node = rclcpp::Node::make_shared("talker"); - -The creation of the publisher and rate objects looks pretty similar, with some -changes to the names of namespace and methods. - -.. code-block:: cpp - - // ros::Publisher chatter_pub = n.advertise("chatter", 1000); - // ros::Rate loop_rate(10); - auto chatter_pub = node->create_publisher("chatter", - 1000); - rclcpp::Rate loop_rate(10); - -To further control how message delivery is handled, a quality of service -(``QoS``) profile could be passed in. -The default profile is ``rmw_qos_profile_default``. -For more details, see the -`design document `__ -and :doc:`concept overview <../../ROS-Framework/topics/About-Quality-of-Service-Settings>`. - -The creation of the outgoing message is different in the namespace: - -.. code-block:: cpp - - // std_msgs::String msg; - std_msgs::msg::String msg; - -In place of ``ros::ok()``, we call ``rclcpp::ok()``: - -.. code-block:: cpp - - // while (ros::ok()) - while (rclcpp::ok()) - -Inside the publishing loop, we access the ``data`` field as before: - -.. code-block:: cpp - - msg.data = ss.str(); - -To print a console message, instead of using ``ROS_INFO()``, we use -``RCLCPP_INFO()`` and its various cousins. -The key difference is that ``RCLCPP_INFO()`` takes a Logger object as the first -argument. - -.. code-block:: cpp - - // ROS_INFO("%s", msg.data.c_str()); - RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); - -Change the publish call to use the ``->`` operator instead of ``.``. - -.. code-block:: cpp - - // chatter_pub.publish(msg); - chatter_pub->publish(msg); - -Spinning (i.e., letting the communications system process any pending -incoming/outgoing messages until no more work is available) is different -in that the call now takes the node and timeout as arguments: - -.. code-block:: cpp - - // ros::spinOnce(); - rclcpp::spin_all(node, 0s); - -Sleeping using the rate object is unchanged. - -Putting it all together, the new ``talker.cpp`` looks like this: - -.. code-block:: cpp - - #include - #include - // #include "ros/ros.h" - #include "rclcpp/rclcpp.hpp" - // #include "std_msgs/String.h" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - - int main(int argc, char **argv) - { - // ros::init(argc, argv, "talker"); - // ros::NodeHandle n; - rclcpp::init(argc, argv); - auto node = rclcpp::Node::make_shared("talker"); - // ros::Publisher chatter_pub = n.advertise("chatter", 1000); - // ros::Rate loop_rate(10); - auto chatter_pub = node->create_publisher("chatter", 1000); - rclcpp::Rate loop_rate(10); - int count = 0; - // std_msgs::String msg; - std_msgs::msg::String msg; - // while (ros::ok()) - while (rclcpp::ok()) - { - std::stringstream ss; - ss << "hello world " << count++; - msg.data = ss.str(); - // ROS_INFO("%s", msg.data.c_str()); - RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); - // chatter_pub.publish(msg); - chatter_pub->publish(msg); - // ros::spinOnce(); - rclcpp::spin_all(node, 0s); - loop_rate.sleep(); - } - return 0; - } - -Change the ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -ROS 2 packages use CMake functions and macros from ``ament_cmake_ros`` instead of ``catkin``. -Delete the dependency on ``catkin``: - -.. code-block:: - - - catkin` - -Add a new dependency on ``ament_cmake_ros``: - -.. code-block:: xml - - ament_cmake_ros - -ROS 2 C++ libraries use `rclcpp `__ instead of `roscpp `__. - -Delete the dependency on ``roscpp``: - -.. code-block:: - - - roscpp - -Add a dependency on ``rclcpp``: - -.. code-block:: xml - - rclcpp - - -Add an ```` section to tell colcon the package is an ``ament_cmake`` package instead of a ``catkin`` package. - -.. code-block:: xml - - - ament_cmake - - -Your ``package.xml`` now looks like this: - -.. code-block:: xml - - - - - talker - 0.0.0 - talker - Brian Gerkey - Apache-2.0 - ament_cmake - rclcpp - std_msgs - - ament_cmake - - - - -Changing the CMake code -~~~~~~~~~~~~~~~~~~~~~~~ - -Require a newer version of CMake so that ``ament_cmake`` functions work correctly. - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - -Use a newer C++ standard matching the version used by your target ROS distro in `REP 2000 `__. -If you are using C++20, then set that version with the following snippet after the ``project(talker)`` call. -Add extra compiler checks too because it is a good practice. - -.. code-block:: cmake - - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - -Replace the ``find_package(catkin ...)`` call with individual calls for each dependency. - -.. code-block:: cmake - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - -Delete the call to ``catkin_package()``. -Add a call to ``ament_package()`` at the bottom of the ``CMakeLists.txt``. - -.. code-block:: cmake - - ament_package() - -Make the ``target_link_libraries`` call modern CMake targets provided by ``rclcpp`` and ``std_msgs``. - -.. code-block:: cmake - - target_link_libraries(talker PUBLIC - rclcpp::rclcpp - std_msgs::std_msgs) - -Delete the call to ``include_directories()``. -Add a call to ``target_include_directories()`` below ``add_executable(talker talker.cpp)``. -Don't pass variables like ``rclcpp_INCLUDE_DIRS`` into ``target_include_directories()``. -The include directories are already handled by calling ``target_link_libraries()`` with modern CMake targets. - -.. code-block:: cmake - - target_include_directories(talker PUBLIC - "$" - "$") - -Change the call to ``install()`` so that the ``talker`` executable is installed into a project specific directory. - -.. code-block:: cmake - - install(TARGETS talker - DESTINATION lib/${PROJECT_NAME}) - -The new ``CMakeLists.txt`` looks like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(talker) - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - add_executable(talker talker.cpp) - target_include_directories(talker PUBLIC - "$" - "$") - target_link_libraries(talker PUBLIC - rclcpp::rclcpp - std_msgs::std_msgs) - install(TARGETS talker - DESTINATION lib/${PROJECT_NAME}) - ament_package() - -Building the ROS 2 code -~~~~~~~~~~~~~~~~~~~~~~~ - -We source an environment setup file (in this case the one generated by following -the ROS 2 installation tutorial, which builds in ``~/ros2_ws``, then we build our -package using ``colcon build``: - -.. code-block:: console - - $ . ~/ros2_ws/install/setup.bash - $ cd ~/ros2_talker - $ colcon build - -Running the ROS 2 node -~~~~~~~~~~~~~~~~~~~~~~ - -Because we installed the ``talker`` executable into the correct directory, after sourcing the -setup file, from our install tree, we can invoke it by running: - -.. code-block:: console - - $ . ~/ros2_ws/install/setup.bash - $ ros2 run talker talker - -Conclusion ----------- - -You have learned how to migrate an example C++ ROS 1 package to ROS 2. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-CPP-Package-Example + +Migrating a C++ Package Example +=============================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +This example shows how to migrate an example C++ package from ROS 1 to ROS 2. + +Prerequisites +------------- + +You need a working ROS 2 installation, such as :doc:`ROS {DISTRO} <../../Get-Started/Installation>`. + +The ROS 1 code +-------------- + +Say you have a ROS 1 package called ``talker`` that uses ``roscpp`` in one node, called ``talker``. +This package is in a catkin workspace, located at ``~/ros1_talker``. + +Your ROS 1 workspace has the following directory layout: + +.. code-block:: console + + $ cd ~/ros1_talker + $ find . + . + ./src + ./src/talker + ./src/talker/package.xml + ./src/talker/CMakeLists.txt + ./src/talker/talker.cpp + +The files have the following content: + +``src/talker/package.xml``: + +.. code-block:: xml + + + + + talker + 0.0.0 + talker + Brian Gerkey + Apache-2.0 + catkin + roscpp + std_msgs + + +``src/talker/CMakeLists.txt``: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 2.8.3) + project(talker) + find_package(catkin REQUIRED COMPONENTS roscpp std_msgs) + catkin_package() + include_directories(${catkin_INCLUDE_DIRS}) + add_executable(talker talker.cpp) + target_link_libraries(talker ${catkin_LIBRARIES}) + install(TARGETS talker + RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}) + +``src/talker/talker.cpp``: + +.. code-block:: cpp + + #include + #include "ros/ros.h" + #include "std_msgs/String.h" + int main(int argc, char **argv) + { + ros::init(argc, argv, "talker"); + ros::NodeHandle n; + ros::Publisher chatter_pub = n.advertise("chatter", 1000); + ros::Rate loop_rate(10); + int count = 0; + std_msgs::String msg; + while (ros::ok()) + { + std::stringstream ss; + ss << "hello world " << count++; + msg.data = ss.str(); + ROS_INFO("%s", msg.data.c_str()); + chatter_pub.publish(msg); + ros::spinOnce(); + loop_rate.sleep(); + } + return 0; + } + +Migrating to ROS 2 +------------------ + +Let's start by creating a new workspace in which to work: + +.. code-block:: console + + $ mkdir ~/ros2_talker + $ cd ~/ros2_talker + +We'll copy the source tree from our ROS 1 package into that workspace, where we can modify it: + +.. code-block:: console + + $ mkdir src + $ cp -a ~/ros1_talker/src/talker src + +Now we'll modify the C++ code in the node. +The ROS 2 C++ library, called ``rclcpp``, provides a different API from that +provided by ``roscpp``. +The concepts are very similar between the two libraries, which makes the changes +reasonably straightforward to make. + +Included headers +~~~~~~~~~~~~~~~~ + +In place of ``ros/ros.h``, which gave us access to the ``roscpp`` library API, we +need to include ``rclcpp/rclcpp.hpp``, which gives us access to the ``rclcpp`` +library API: + +.. code-block:: cpp + + //#include "ros/ros.h" + #include "rclcpp/rclcpp.hpp" + +To get the ``std_msgs/String`` message definition, in place of +``std_msgs/String.h``, we need to include ``std_msgs/msg/string.hpp``: + +.. code-block:: cpp + + //#include "std_msgs/String.h" + #include "std_msgs/msg/string.hpp" + +Changing C++ library calls +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Instead of passing the node's name to the library initialization call, we do +the initialization, then pass the node name to the creation of the node object: + +.. code-block:: cpp + + // ros::init(argc, argv, "talker"); + // ros::NodeHandle n; + rclcpp::init(argc, argv); + auto node = rclcpp::Node::make_shared("talker"); + +The creation of the publisher and rate objects looks pretty similar, with some +changes to the names of namespace and methods. + +.. code-block:: cpp + + // ros::Publisher chatter_pub = n.advertise("chatter", 1000); + // ros::Rate loop_rate(10); + auto chatter_pub = node->create_publisher("chatter", + 1000); + rclcpp::Rate loop_rate(10); + +To further control how message delivery is handled, a quality of service +(``QoS``) profile could be passed in. +The default profile is ``rmw_qos_profile_default``. +For more details, see the +`design document `__ +and :doc:`concept overview <../../ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings>`. + +The creation of the outgoing message is different in the namespace: + +.. code-block:: cpp + + // std_msgs::String msg; + std_msgs::msg::String msg; + +In place of ``ros::ok()``, we call ``rclcpp::ok()``: + +.. code-block:: cpp + + // while (ros::ok()) + while (rclcpp::ok()) + +Inside the publishing loop, we access the ``data`` field as before: + +.. code-block:: cpp + + msg.data = ss.str(); + +To print a console message, instead of using ``ROS_INFO()``, we use +``RCLCPP_INFO()`` and its various cousins. +The key difference is that ``RCLCPP_INFO()`` takes a Logger object as the first +argument. + +.. code-block:: cpp + + // ROS_INFO("%s", msg.data.c_str()); + RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); + +Change the publish call to use the ``->`` operator instead of ``.``. + +.. code-block:: cpp + + // chatter_pub.publish(msg); + chatter_pub->publish(msg); + +Spinning (i.e., letting the communications system process any pending +incoming/outgoing messages until no more work is available) is different +in that the call now takes the node and timeout as arguments: + +.. code-block:: cpp + + // ros::spinOnce(); + rclcpp::spin_all(node, 0s); + +Sleeping using the rate object is unchanged. + +Putting it all together, the new ``talker.cpp`` looks like this: + +.. code-block:: cpp + + #include + #include + // #include "ros/ros.h" + #include "rclcpp/rclcpp.hpp" + // #include "std_msgs/String.h" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + + int main(int argc, char **argv) + { + // ros::init(argc, argv, "talker"); + // ros::NodeHandle n; + rclcpp::init(argc, argv); + auto node = rclcpp::Node::make_shared("talker"); + // ros::Publisher chatter_pub = n.advertise("chatter", 1000); + // ros::Rate loop_rate(10); + auto chatter_pub = node->create_publisher("chatter", 1000); + rclcpp::Rate loop_rate(10); + int count = 0; + // std_msgs::String msg; + std_msgs::msg::String msg; + // while (ros::ok()) + while (rclcpp::ok()) + { + std::stringstream ss; + ss << "hello world " << count++; + msg.data = ss.str(); + // ROS_INFO("%s", msg.data.c_str()); + RCLCPP_INFO(node->get_logger(), "%s\n", msg.data.c_str()); + // chatter_pub.publish(msg); + chatter_pub->publish(msg); + // ros::spinOnce(); + rclcpp::spin_all(node, 0s); + loop_rate.sleep(); + } + return 0; + } + +Change the ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +ROS 2 packages use CMake functions and macros from ``ament_cmake_ros`` instead of ``catkin``. +Delete the dependency on ``catkin``: + +.. code-block:: + + + catkin` + +Add a new dependency on ``ament_cmake_ros``: + +.. code-block:: xml + + ament_cmake_ros + +ROS 2 C++ libraries use `rclcpp `__ instead of `roscpp `__. + +Delete the dependency on ``roscpp``: + +.. code-block:: + + + roscpp + +Add a dependency on ``rclcpp``: + +.. code-block:: xml + + rclcpp + + +Add an ```` section to tell colcon the package is an ``ament_cmake`` package instead of a ``catkin`` package. + +.. code-block:: xml + + + ament_cmake + + +Your ``package.xml`` now looks like this: + +.. code-block:: xml + + + + + talker + 0.0.0 + talker + Brian Gerkey + Apache-2.0 + ament_cmake + rclcpp + std_msgs + + ament_cmake + + + + +Changing the CMake code +~~~~~~~~~~~~~~~~~~~~~~~ + +Require a newer version of CMake so that ``ament_cmake`` functions work correctly. + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + +Use a newer C++ standard matching the version used by your target ROS distro in `REP 2000 `__. +If you are using C++20, then set that version with the following snippet after the ``project(talker)`` call. +Add extra compiler checks too because it is a good practice. + +.. code-block:: cmake + + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + +Replace the ``find_package(catkin ...)`` call with individual calls for each dependency. + +.. code-block:: cmake + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + +Delete the call to ``catkin_package()``. +Add a call to ``ament_package()`` at the bottom of the ``CMakeLists.txt``. + +.. code-block:: cmake + + ament_package() + +Make the ``target_link_libraries`` call modern CMake targets provided by ``rclcpp`` and ``std_msgs``. + +.. code-block:: cmake + + target_link_libraries(talker PUBLIC + rclcpp::rclcpp + std_msgs::std_msgs) + +Delete the call to ``include_directories()``. +Add a call to ``target_include_directories()`` below ``add_executable(talker talker.cpp)``. +Don't pass variables like ``rclcpp_INCLUDE_DIRS`` into ``target_include_directories()``. +The include directories are already handled by calling ``target_link_libraries()`` with modern CMake targets. + +.. code-block:: cmake + + target_include_directories(talker PUBLIC + "$" + "$") + +Change the call to ``install()`` so that the ``talker`` executable is installed into a project specific directory. + +.. code-block:: cmake + + install(TARGETS talker + DESTINATION lib/${PROJECT_NAME}) + +The new ``CMakeLists.txt`` looks like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(talker) + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + add_executable(talker talker.cpp) + target_include_directories(talker PUBLIC + "$" + "$") + target_link_libraries(talker PUBLIC + rclcpp::rclcpp + std_msgs::std_msgs) + install(TARGETS talker + DESTINATION lib/${PROJECT_NAME}) + ament_package() + +Building the ROS 2 code +~~~~~~~~~~~~~~~~~~~~~~~ + +We source an environment setup file (in this case the one generated by following +the ROS 2 installation tutorial, which builds in ``~/ros2_ws``, then we build our +package using ``colcon build``: + +.. code-block:: console + + $ . ~/ros2_ws/install/setup.bash + $ cd ~/ros2_talker + $ colcon build + +Running the ROS 2 node +~~~~~~~~~~~~~~~~~~~~~~ + +Because we installed the ``talker`` executable into the correct directory, after sourcing the +setup file, from our install tree, we can invoke it by running: + +.. code-block:: console + + $ . ~/ros2_ws/install/setup.bash + $ ros2 run talker talker + +Conclusion +---------- + +You have learned how to migrate an example C++ ROS 1 package to ROS 2. Use the :doc:`Migrating C++ Packages reference page ` to help you migrate your own C++ packages from ROS 1 to ROS 2. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst index 746b858520f..d7ec9bd6bba 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst @@ -1,55 +1,55 @@ -.. redirect-from:: - - How-To-Guides/Migrating-from-ROS1/Migrating-Interfaces - -Migrating Interfaces -==================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Messages, services, and actions are collectively called ``interfaces`` in ROS 2. - -Interface definitions ---------------------- - -Message files must end in ``.msg`` and must be located in the subfolder ``msg``. -Service files must end in ``.srv`` and must be located in the subfolder ``srv``. -Actions files must end in ``.action`` and must be located in the subfolder ``action``. - -These files might need to be updated to comply with the `ROS Interface definition `__. -Some primitive types have been removed and the types ``duration`` and ``time`` which were builtin types in ROS 1 have been replaced with normal message definitions and must be used from the `builtin_interfaces `__ package. -Also some naming conventions are stricter than in ROS 1. -There is additional information in the :doc:`conceptual article <../../ROS-Framework/About-Interfaces>`. - -Building interfaces -------------------- - -The way in which interfaces are built in ROS 2 differs substantially from ROS 1. -Interfaces can only be built from packages containing a ``CMakeLists.txt``. -If you are developing a pure Python package, then the interfaces should be placed in a different package containing only the interfaces (which is best practice anyway). -See the :doc:`custom interfaces tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces>` for more information. - -Migrating interface package to ROS 2 -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In your ``package.xml``: - -* Add ``rosidl_default_generators``. -* Add ``rosidl_default_runtime``. -* Add ``rosidl_interface_packages`` -* For each dependent message package, add ``message_package``. - -In your ``CMakeLists.txt``: - -* Enable C++20 - -.. code-block:: cmake - - set(CMAKE_CXX_STANDARD 20) - -* Add ``find_package(rosidl_default_generators REQUIRED)`` -* For each dependent message package, add ``find_package(message_package REQUIRED)`` and replace the CMake function call to ``generate_messages`` with ``rosidl_generate_interfaces``. - +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Interfaces + +Migrating Interfaces +==================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Messages, services, and actions are collectively called ``interfaces`` in ROS 2. + +Interface definitions +--------------------- + +Message files must end in ``.msg`` and must be located in the subfolder ``msg``. +Service files must end in ``.srv`` and must be located in the subfolder ``srv``. +Actions files must end in ``.action`` and must be located in the subfolder ``action``. + +These files might need to be updated to comply with the `ROS Interface definition `__. +Some primitive types have been removed and the types ``duration`` and ``time`` which were builtin types in ROS 1 have been replaced with normal message definitions and must be used from the `builtin_interfaces `__ package. +Also some naming conventions are stricter than in ROS 1. +There is additional information in the :doc:`conceptual article <../../ROS-Framework/interfaces/About-Interfaces>`. + +Building interfaces +------------------- + +The way in which interfaces are built in ROS 2 differs substantially from ROS 1. +Interfaces can only be built from packages containing a ``CMakeLists.txt``. +If you are developing a pure Python package, then the interfaces should be placed in a different package containing only the interfaces (which is best practice anyway). +See the :doc:`custom interfaces tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces>` for more information. + +Migrating interface package to ROS 2 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In your ``package.xml``: + +* Add ``rosidl_default_generators``. +* Add ``rosidl_default_runtime``. +* Add ``rosidl_interface_packages`` +* For each dependent message package, add ``message_package``. + +In your ``CMakeLists.txt``: + +* Enable C++20 + +.. code-block:: cmake + + set(CMAKE_CXX_STANDARD 20) + +* Add ``find_package(rosidl_default_generators REQUIRED)`` +* For each dependent message package, add ``find_package(message_package REQUIRED)`` and replace the CMake function call to ``generate_messages`` with ``rosidl_generate_interfaces``. + This will replace ``add_message_files`` and ``add_service_files`` listing of all the message and service files, which can be removed. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst index f40b974d322..fbdebdc1dd7 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst @@ -1,136 +1,136 @@ -.. redirect-from:: - - How-To-Guides/Migrating-from-ROS1/Migrating-Package-XML - -Migrating your package.xml to format 2 -====================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -ROS 2 requires ``package.xml`` files to use at least `format 2 `__. -This guide shows how to migrate a ``package.xml`` from format 1 to format 2. - -If the ```` tag at the start of your ``package.xml`` looks like either of the following, then it is using format 1 and you must migrate it. - -.. code-block:: xml - - - -.. code-block:: xml - - - - -Prerequisites -------------- - -You should have a working ROS 1 installation. -This enables you to check that the converted ``package.xml`` is valid by building and testing the package, since ROS 1 supports all ``package.xml`` format versions. - -Migrate from format 1 to 2 --------------------------- - -Format 1 and format 2 differ in how they specify dependencies. -Read the `compatibility section in REP-0140 `__ for a summary of the differences. - -Add ``format`` attribute to ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Add or set the ``format`` attribute to ``2`` to indicate that the ``package.xml`` uses format 2. - -.. code:: xml - - - -Replace ```` -~~~~~~~~~~~~~~~~~~~~~~~~ - -The ```` tag is no longer allowed. -If you have a dependency specified like this: - -.. code:: xml - - foo - -then replace it with one or both of these tags: - -.. code:: xml - - foo - foo - -If the dependency is needed when something in your package is executed, then use the ```` tag. -If packages that depend on your package need the dependency when they are built, then use the ```` tag. -Use both tags if you are unsure. - -Convert some ```` to ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In format 1 ```` declares dependencies that are needed when running your package's tests. -It still does that in format 2, but it additionally declares dependencies that are needed when building your package's tests. - -Because of the limitations of this tag in format 1, your package may have a test-only dependency specified as a ```` like this: - -.. code:: xml - - testfoo - -If so, change it to a ````. - -.. code:: xml - - testfoo - -.. note:: - - If you are using CMake, then make sure your test dependencies are only referenced within a ``if(BUILD_TESTING)`` block: - - .. code:: cmake - - if (BUILD_TESTING) - find_package(testfoo REQUIRED) - endif() - -Begin using ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Use the new ```` tag to declare dependencies needed for building your package's documentation. -For example, C++ packages might have this dependency: - -.. code:: xml - - doxygen - -while Python packages might have this one: - -.. code:: xml - - python3-sphinx - -See :doc:`the guide on documenting ROS 2 packages <../../Developer-Tools/Build/Documenting-a-ROS-2-Package>` for more information. - -Simplify dependencies with ```` -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -```` is a new tag that makes ``package.xml`` files more concise. -If your ``package.xml`` has these three tags for the same dependency: - -.. code:: - - foo - foo - foo - -then replace them with a single ```` like this: - -.. code:: xml - - foo - -Test your new ``package.xml`` ------------------------------ - -Build and test your package as you normally do using ``catkin_make``, ``cakin_make_isolated``, or the ``catkin`` build tool. +.. redirect-from:: + + How-To-Guides/Migrating-from-ROS1/Migrating-Package-XML + +Migrating your package.xml to format 2 +====================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +ROS 2 requires ``package.xml`` files to use at least `format 2 `__. +This guide shows how to migrate a ``package.xml`` from format 1 to format 2. + +If the ```` tag at the start of your ``package.xml`` looks like either of the following, then it is using format 1 and you must migrate it. + +.. code-block:: xml + + + +.. code-block:: xml + + + + +Prerequisites +------------- + +You should have a working ROS 1 installation. +This enables you to check that the converted ``package.xml`` is valid by building and testing the package, since ROS 1 supports all ``package.xml`` format versions. + +Migrate from format 1 to 2 +-------------------------- + +Format 1 and format 2 differ in how they specify dependencies. +Read the `compatibility section in REP-0140 `__ for a summary of the differences. + +Add ``format`` attribute to ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Add or set the ``format`` attribute to ``2`` to indicate that the ``package.xml`` uses format 2. + +.. code:: xml + + + +Replace ```` +~~~~~~~~~~~~~~~~~~~~~~~~ + +The ```` tag is no longer allowed. +If you have a dependency specified like this: + +.. code:: xml + + foo + +then replace it with one or both of these tags: + +.. code:: xml + + foo + foo + +If the dependency is needed when something in your package is executed, then use the ```` tag. +If packages that depend on your package need the dependency when they are built, then use the ```` tag. +Use both tags if you are unsure. + +Convert some ```` to ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In format 1 ```` declares dependencies that are needed when running your package's tests. +It still does that in format 2, but it additionally declares dependencies that are needed when building your package's tests. + +Because of the limitations of this tag in format 1, your package may have a test-only dependency specified as a ```` like this: + +.. code:: xml + + testfoo + +If so, change it to a ````. + +.. code:: xml + + testfoo + +.. note:: + + If you are using CMake, then make sure your test dependencies are only referenced within a ``if(BUILD_TESTING)`` block: + + .. code:: cmake + + if (BUILD_TESTING) + find_package(testfoo REQUIRED) + endif() + +Begin using ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Use the new ```` tag to declare dependencies needed for building your package's documentation. +For example, C++ packages might have this dependency: + +.. code:: xml + + doxygen + +while Python packages might have this one: + +.. code:: xml + + python3-sphinx + +See :doc:`the guide on documenting ROS 2 packages <../../Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package>` for more information. + +Simplify dependencies with ```` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +```` is a new tag that makes ``package.xml`` files more concise. +If your ``package.xml`` has these three tags for the same dependency: + +.. code:: + + foo + foo + foo + +then replace them with a single ```` like this: + +.. code:: xml + + foo + +Test your new ``package.xml`` +----------------------------- + +Build and test your package as you normally do using ``catkin_make``, ``cakin_make_isolated``, or the ``catkin`` build tool. If everything succeeds, then your ``package.xml`` is valid. \ No newline at end of file diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst index 029a365b91a..6bbae5e3486 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst @@ -1,178 +1,178 @@ -.. redirect-from:: - - Migration-Guide-Python - The-ROS2-Project/Contributing/Migration-Guide-Python - How-To-Guides/Migrating-from-ROS1/Migrating-Python-Packages - -Migrating Python Packages Reference -=================================== - -This page is a reference on how to migrate Python packages from ROS 1 to ROS 2. -If this is your first time migrating a Python package, then follow :doc:`this guide to migrate an example Python package ` first. - -.. contents:: Table of Contents - :depth: 2 - :local: - -Build tool ----------- - -Instead of using ``catkin_make``, ``catkin_make_isolated`` or ``catkin build`` ROS 2 uses the command line tool `colcon `__ to build and install a set of packages. -See the :doc:`beginner tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>` to get started with ``colcon``. - -Build system ------------- - -For pure Python packages, ROS 2 uses the standard ``setup.py`` installation mechanism familiar to Python developers. - -Update the files to use *setup.py* -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If the ROS 1 package uses CMake only to invoke the ``setup.py`` file and does not contain anything beside Python code (e.g. no messages, services, etc.) it should be converted into a pure Python package in ROS 2: - -* - Update or add the build type in the ``package.xml`` file: - - .. code-block:: xml - - - ament_python - - -* - Remove the ``CMakeLists.txt`` file - -* - Update the ``setup.py`` file to be a standard Python setup script - -ROS 2 supports Python 3 only. -While each package can choose to also support Python 2 it must invoke executables with Python 3 if it uses any API provided by other ROS 2 packages. - -Update source code ------------------- - -Node Initialization -^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - rospy.init_node('asdf') - - rospy.loginfo('Created node') - -In ROS 2: - -.. code-block:: python - - with rclpy.init(args=sys.argv): - node = rclpy.create_node('asdf') - - node.get_logger().info('Created node') - -ROS Parameters -^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - port = rospy.get_param('port', '/dev/ttyUSB0') - assert isinstance(port, str), 'port parameter must be a str' - - baudrate = rospy.get_param('baudrate', 115200) - assert isinstance(baudrate, int), 'baudrate parameter must be an integer' - - rospy.logwarn('port: ' + port) - -In ROS 2: - -.. code-block:: python - - port = node.declare_parameter('port', '/dev/ttyUSB0').value - assert isinstance(port, str), 'port parameter must be a str' - - baudrate = node.declare_parameter('baudrate', 115200).value - assert isinstance(baudrate, int), 'baudrate parameter must be an integer' - - node.get_logger().warn('port: ' + port) - -Creating a Publisher -^^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - pub = rospy.Publisher('chatter', String) - # or - pub = rospy.Publisher('chatter', String, queue_size=10) - -In ROS 2: - -.. code-block:: python - - pub = node.create_publisher(String, 'chatter', rclpy.qos.QoSProfile()) - # or - pub = node.create_publisher(String, 'chatter', 10) - -Creating a Subscriber -^^^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - sub = rospy.Subscriber('chatter', String, callback) - # or - sub = rospy.Subscriber('chatter', String, callback, queue_size=10) - -In ROS 2: - -.. code-block:: python - - sub = node.create_subscription(String, 'chatter', callback, rclpy.qos.QoSProfile()) - # or - sub = node.create_subscription(String, 'chatter', callback, 10) - -Creating a Service -^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - srv = rospy.Service('add_two_ints', AddTwoInts, add_two_ints_callback) - -In ROS 2: - -.. code-block:: python - - srv = node.create_service(AddTwoInts, 'add_two_ints', add_two_ints_callback) - -Creating a Service Client -^^^^^^^^^^^^^^^^^^^^^^^^^ - -In ROS 1: - -.. code-block:: python - - rospy.wait_for_service('add_two_ints') - add_two_ints = rospy.ServiceProxy('add_two_ints', AddTwoInts) - resp = add_two_ints(req) - -In ROS 2: - -.. code-block:: python - - add_two_ints = node.create_client(AddTwoInts, 'add_two_ints') - while not add_two_ints.wait_for_service(timeout_sec=1.0): - node.get_logger().info('service not available, waiting again...') - resp = add_two_ints.call_async(req) - rclpy.spin_until_future_complete(node, resp) - -.. warning:: - - Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. - For more details see the :doc:`sync deadlock article <../../ROS-Framework/services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file +.. redirect-from:: + + Migration-Guide-Python + The-ROS2-Project/Contributing/Migration-Guide-Python + How-To-Guides/Migrating-from-ROS1/Migrating-Python-Packages + +Migrating Python Packages Reference +=================================== + +This page is a reference on how to migrate Python packages from ROS 1 to ROS 2. +If this is your first time migrating a Python package, then follow :doc:`this guide to migrate an example Python package ` first. + +.. contents:: Table of Contents + :depth: 2 + :local: + +Build tool +---------- + +Instead of using ``catkin_make``, ``catkin_make_isolated`` or ``catkin build`` ROS 2 uses the command line tool `colcon `__ to build and install a set of packages. +See the :doc:`beginner tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial>` to get started with ``colcon``. + +Build system +------------ + +For pure Python packages, ROS 2 uses the standard ``setup.py`` installation mechanism familiar to Python developers. + +Update the files to use *setup.py* +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If the ROS 1 package uses CMake only to invoke the ``setup.py`` file and does not contain anything beside Python code (e.g. no messages, services, etc.) it should be converted into a pure Python package in ROS 2: + +* + Update or add the build type in the ``package.xml`` file: + + .. code-block:: xml + + + ament_python + + +* + Remove the ``CMakeLists.txt`` file + +* + Update the ``setup.py`` file to be a standard Python setup script + +ROS 2 supports Python 3 only. +While each package can choose to also support Python 2 it must invoke executables with Python 3 if it uses any API provided by other ROS 2 packages. + +Update source code +------------------ + +Node Initialization +^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + rospy.init_node('asdf') + + rospy.loginfo('Created node') + +In ROS 2: + +.. code-block:: python + + with rclpy.init(args=sys.argv): + node = rclpy.create_node('asdf') + + node.get_logger().info('Created node') + +ROS Parameters +^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + port = rospy.get_param('port', '/dev/ttyUSB0') + assert isinstance(port, str), 'port parameter must be a str' + + baudrate = rospy.get_param('baudrate', 115200) + assert isinstance(baudrate, int), 'baudrate parameter must be an integer' + + rospy.logwarn('port: ' + port) + +In ROS 2: + +.. code-block:: python + + port = node.declare_parameter('port', '/dev/ttyUSB0').value + assert isinstance(port, str), 'port parameter must be a str' + + baudrate = node.declare_parameter('baudrate', 115200).value + assert isinstance(baudrate, int), 'baudrate parameter must be an integer' + + node.get_logger().warn('port: ' + port) + +Creating a Publisher +^^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + pub = rospy.Publisher('chatter', String) + # or + pub = rospy.Publisher('chatter', String, queue_size=10) + +In ROS 2: + +.. code-block:: python + + pub = node.create_publisher(String, 'chatter', rclpy.qos.QoSProfile()) + # or + pub = node.create_publisher(String, 'chatter', 10) + +Creating a Subscriber +^^^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + sub = rospy.Subscriber('chatter', String, callback) + # or + sub = rospy.Subscriber('chatter', String, callback, queue_size=10) + +In ROS 2: + +.. code-block:: python + + sub = node.create_subscription(String, 'chatter', callback, rclpy.qos.QoSProfile()) + # or + sub = node.create_subscription(String, 'chatter', callback, 10) + +Creating a Service +^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + srv = rospy.Service('add_two_ints', AddTwoInts, add_two_ints_callback) + +In ROS 2: + +.. code-block:: python + + srv = node.create_service(AddTwoInts, 'add_two_ints', add_two_ints_callback) + +Creating a Service Client +^^^^^^^^^^^^^^^^^^^^^^^^^ + +In ROS 1: + +.. code-block:: python + + rospy.wait_for_service('add_two_ints') + add_two_ints = rospy.ServiceProxy('add_two_ints', AddTwoInts) + resp = add_two_ints(req) + +In ROS 2: + +.. code-block:: python + + add_two_ints = node.create_client(AddTwoInts, 'add_two_ints') + while not add_two_ints.wait_for_service(timeout_sec=1.0): + node.get_logger().info('service not available, waiting again...') + resp = add_two_ints.call_async(req) + rclpy.spin_until_future_complete(node, resp) + +.. warning:: + + Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. + For more details see the :doc:`sync deadlock article <../../ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file diff --git a/source/ROS-Framework.rst b/source/ROS-Framework.rst index ff77d5a0a6a..29ec2fe74c7 100644 --- a/source/ROS-Framework.rst +++ b/source/ROS-Framework.rst @@ -9,9 +9,6 @@ PLACEHOLDER :maxdepth: 3 ROS-Framework/About-Nodes - ROS-Framework/About-Interfaces - ROS-Framework/About-Actions - ROS-Framework/About-Services - ROS-Framework/About-Topics + ROS-Framework/Interfaces-Topics-Services-Actions ROS-Framework/About-Parameters ROS-Framework/About-Client-Libraries diff --git a/source/ROS-Framework/About-Nodes.rst b/source/ROS-Framework/About-Nodes.rst index 117b84ba1a7..19a2c694ce2 100644 --- a/source/ROS-Framework/About-Nodes.rst +++ b/source/ROS-Framework/About-Nodes.rst @@ -1,32 +1,32 @@ -.. redirect-from:: - - Concepts/Basic/About-Nodes - -Nodes -===== - -.. toctree:: - :maxdepth: 1 - :hidden: - - nodes/About-Discovery - nodes/About-Domain-ID - nodes/About-Logging/About-Logging - nodes/About-Composition - nodes/Working-with-nodes - -.. contents:: Table of Contents - :local: - -A node is a participant in the ROS 2 graph, which uses a :doc:`client library ` to communicate with other nodes. -Nodes can communicate with other nodes within the same process, in a different process, or on a different machine. -Nodes are typically the unit of computation in a ROS graph; each node should do one logical thing. - -Nodes can :doc:`publish ` to named topics to deliver data to other nodes, or :doc:`subscribe ` to named topics to get data from other nodes. -They can also act as a :doc:`service client ` to have another node perform a computation on their behalf, or as a :doc:`service server ` to provide functionality to other nodes. -For long-running computations, a node can act as an :doc:`action client ` to have another node perform it on their behalf, or as an :doc:`action server ` to provide functionality to other nodes. -Nodes can provide configurable :doc:`parameters ` to change behavior during run-time. - -Nodes are often a complex combination of publishers, subscribers, service servers, service clients, action servers, and action clients, all at the same time. - -Connections between nodes are established through a distributed :doc:`discovery ` process. +.. redirect-from:: + + Concepts/Basic/About-Nodes + +Nodes +===== + +.. toctree:: + :maxdepth: 1 + :hidden: + + nodes/About-Discovery + nodes/About-Domain-ID + nodes/About-Logging/About-Logging + nodes/About-Composition + nodes/Working-with-nodes + +.. contents:: Table of Contents + :local: + +A node is a participant in the ROS 2 graph, which uses a :doc:`client library ` to communicate with other nodes. +Nodes can communicate with other nodes within the same process, in a different process, or on a different machine. +Nodes are typically the unit of computation in a ROS graph; each node should do one logical thing. + +Nodes can :doc:`publish ` to named topics to deliver data to other nodes, or :doc:`subscribe ` to named topics to get data from other nodes. +They can also act as a :doc:`service client ` to have another node perform a computation on their behalf, or as a :doc:`service server ` to provide functionality to other nodes. +For long-running computations, a node can act as an :doc:`action client ` to have another node perform it on their behalf, or as an :doc:`action server ` to provide functionality to other nodes. +Nodes can provide configurable :doc:`parameters ` to change behavior during run-time. + +Nodes are often a complex combination of publishers, subscribers, service servers, service clients, action servers, and action clients, all at the same time. + +Connections between nodes are established through a distributed :doc:`discovery ` process. diff --git a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst b/source/ROS-Framework/Interfaces-Topics-Services-Actions.rst similarity index 87% rename from source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst rename to source/ROS-Framework/Interfaces-Topics-Services-Actions.rst index 15ae07e5b71..cb2225515be 100644 --- a/source/ROS-Framework/interfaces/Interfaces-Topics-Services-Actions.rst +++ b/source/ROS-Framework/Interfaces-Topics-Services-Actions.rst @@ -1,8 +1,24 @@ +.. redirect-from:: + + About-ROS-Interfaces + How-To-Guides/Topics-Services-Actions + .. _interfaces-topics-services-actions: +.. _TopicsServicesActions: Interfaces (topics, services, actions) ====================================== +.. toctree:: + :maxdepth: 1 + :hidden: + + interfaces/About-Interfaces + interfaces/About-Topics + interfaces/About-Services + interfaces/About-Actions + + Interfaces in ROS define how nodes exchange data. This article explains the different types of ROS interface and the differences between them. With this information, you'll be able to select the right interfaces for your purposes. @@ -14,13 +30,13 @@ Summary ROS nodes typically communicate through the following three types of interfaces: -* Topics: For continuous data streams. -* Services: For synchronous request/response interactions (short tasks which happen immediately). -* Actions: For long-running tasks with feedback (tasks that may take some time to complete). +* :doc:`Topics `: For continuous data streams. +* :doc:`Services `: For synchronous request/response interactions (short tasks which happen immediately). +* :doc:`Actions `: For long-running tasks with feedback (tasks that may take some time to complete). For consistent communication, each interface uses definitions provided in ``.msg``, ``.srv``, or ``.action`` files. -:doc:`Learn more about nodes <../About-Nodes>` +:doc:`Learn more about nodes ` Topics ------ @@ -62,7 +78,7 @@ This gives you a clear view of timing patterns, delays, and irregularities, maki The default interval is 1 second. The default statistics topic is ``/statistics``. -:doc:`Learn how to enable topic statistics <../../Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial>` +:doc:`Learn how to enable topic statistics <../Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial>` Services -------- diff --git a/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst index cb7c08f724b..7ef0536e6da 100644 --- a/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst @@ -1,241 +1,241 @@ -.. redirect-from:: - - Concepts/About-Internal-Interfaces - Concepts/Advanced/About-Internal-Interfaces - -Internal ROS 2 interfaces -========================= - -.. contents:: Table of Contents - :local: - -.. include:: ../../../global_substitutions.txt - -The internal ROS interfaces are public C |APIs| that are intended for use by developers who are creating |client libraries| or adding a new underlying middleware, but are not intended for use by typical ROS users. -The ROS |client libraries| provide the user facing |APIs| that most ROS users are familiar with, and may come in a variety of programming languages. - -Internal API Architecture Overview ----------------------------------- - -There are two main internal interfaces: - -- the ROS middleware interface (``rmw`` |API|) -- the ROS client library interface (``rcl`` |API|) - -The ``rmw`` |API| is the interface between the ROS 2 software stack and the underlying middleware implementation. -The underlying middleware used for ROS 2 is either a DDS or RTPS implementation, and is responsible for discovery, publish and subscribe mechanics, request-reply mechanics for services, and serialization of message types. - -The ``rcl`` |API| is a slightly higher level |API| which is used to implement the |client libraries| and does not touch the middleware implementation directly, but rather does so through the ROS middleware interface (``rmw`` |API|) abstraction. - -.. figure:: images/ros_client_library_api_stack.png - :alt: ros2 software stack - -As the diagram shows, these |APIs| are stacked such that the typical ROS user will use the |client library| |API|, e.g. ``rclcpp``, to implement their code (executable or library). -The implementation of the |client libraries|, e.g. ``rclcpp``, use the ``rcl`` interface which provides access to the ROS graph and graph events. -The ``rcl`` implementation in turn uses the ``rmw`` |API| to access the ROS graph. -The purpose of the ``rcl`` implementation is to provide a common implementation for more complex ROS concepts and utilities that may be used by various |client libraries|, while remaining agnostic to the underlying middleware being used. -The purpose of the ``rmw`` interface is to capture the absolute minimum middleware functionality needed to support ROS's client libraries. -Finally, the implementation of the ``rmw`` |API| is provided by a middleware implementation specific |package|, e.g. ``rmw_fastrtps_cpp``, the library of which is compiled against vendor specific DDS interfaces and types. - -In the diagram above there is also a box labeled ``ros_to_dds``, and the purpose of this box is to represent a category of possible packages which allow the user to access DDS vendor specific objects and settings using the ROS equivalents. -One of the goals of this abstraction interface is to completely insulate the ROS user space code from the middleware being used, so that changing DDS vendors or even middleware technology has a minimal impact on the users code. -However, we recognize that on occasion it is useful to reach into the implementation and manually adjust settings despite the consequences that might have. -By requiring the use of one of these packages in order to access the underlying DDS vendor's objects, we can avoid exposing vendor specific symbols and headers in the normal interface. -It also makes it easy to see what code is potentially violating the vendor portability by inspecting the package's dependencies to see if one of these ``ros_to_dds`` packages are being used. - -.. _Type Specific Interfaces: - -Type Specific Interfaces ------------------------- - -All along the way there are some parts of the |APIs| that are necessarily specific to the message types being exchanged, e.g. publishing a message or subscribing to a topic, and therefore require generated code for each message type. -The following diagram layouts the path from user defined ``rosidl`` files, e.g. ``.msg`` files, to the type specific code used by the user and system to perform type specific functions: - -.. figure:: images/ros_idl_api_stack_static.png - :alt: ros2 idl static type support stack - - Figure: flow chart of "static" type support generation, from ``rosidl`` files to user facing code. - -The right hand side of the diagram shows how the ``.msg`` files are passed directly to language specific code generators, e.g. ``rosidl_generator_cpp`` or ``rosidl_generator_py``. -These generators are responsible for creating the code that the user will include (or import) and use as the in-memory representation of the messages that were defined in the ``.msg`` files. -For example, consider the message ``std_msgs/String``, a user might use this file in C++ with the statement ``#include ``, or they might use the statement ``from std_msgs.msg import String`` in Python. -These statements work because of the files generated by these language specific (but middleware agnostic) generator packages. - -Separately, the ``.msg`` files are used to generate type support code for each type. -In this context, type support means: meta data or functions that are specific to a given type and that are used by the system to perform particular tasks for the given type. -The type support for a given message might include things like a list of the names and types for each field in the message. -It might also contain a reference to code that can perform particular tasks for that type, e.g. publish a message. - -.. _internal-interfaces_static-type-support: - -Static Type Support -^^^^^^^^^^^^^^^^^^^ - -When the type support references code to do particular functions for a specific message type, that code sometimes needs to do middleware specific work. -For example, consider the type specific publish function, when using "vendor A" the function will need to call some of "vendor A"'s |API|, but when using "vendor B" it will need to call "vendor B"'s |API|. -To allow for middleware vendor specific code, the user defined ``.msg`` files may result in the generation of vendor specific code. -This vendor specific code is still hidden from the user through the type support abstraction, which is similar to how the "Private Implementation" (or Pimpl) pattern works. - -Static Type Support with DDS -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -For middleware vendors based on DDS, and specifically those which generate code based on the OMG IDL files (``.idl`` files), the user defined ``rosidl`` files (``.msg`` files) are converted into equivalent OMG IDL files (``.idl`` files). -From these OMG IDL files, vendor specific code is created and then used within the type specific functions which are referenced by the type support for a given type. -The above diagram shows this on the left hand side, where the ``.msg`` files are consumed by the ``rosidl_dds`` package to produce ``.idl`` files, and then those ``.idl`` files are given to language specific and DDS vendor specific type support generation packages. - -For example, consider the Fast DDS implementation, which has a package called ``rosidl_typesupport_fastrtps_cpp``. -This package is responsible for generating code to handle things like converting a C++ message object into a serialized octet buffer to be written over the network. -This code, while specific to Fast DDS, is still not exposed to the user because of the abstraction in the type support code. - -.. _internal-interfaces_dynamic-type-support: - -Dynamic Type Support -^^^^^^^^^^^^^^^^^^^^ - -Another way to implement type support is to have generic functions for things like publishing to a topic, rather than generating a version of the function for each message type. -In order to accomplish this, this generic function needs some meta information about the message type being published, things like a list of field names and types in the order in which they appear in the message type. -Then to publish a message, you call a generic publish function and pass a message to be published along with a structure which contains the necessary meta data about the message type. -This is referred to as "dynamic" type support, as opposed to "static" type support which requires generated versions of a function for each type. - -.. figure:: images/ros_idl_api_stack_dynamic.png - :alt: ros2 idl dynamic type support stack - - Figure: flow chart of "dynamic" type support generation, from ``rosidl`` files to user facing code. - -The above diagram shows the flow from user defined ``rosidl`` files to generated user facing code. -It is very similar to the diagram for static type support, and differs only in how the type support is generated which is represented by the left hand side of the diagram. -In dynamic type support the ``.msg`` files are converted directly into user facing code. - -This code is also middleware agnostic, because it only contains meta information about the messages. -The function to actually do the work, e.g. publishing to a topic, is generic to the message type and will make any necessary calls to the middleware specific |APIs|. -Note that rather than dds vendor specific packages providing the type support code, which is the case in static type support, this method has middleware agnostic package for each language, e.g. ``rosidl_typesupport_introspection_c`` and ``rosidl_typesupport_introspection_cpp``. -The ``introspection`` part of the package name refers to the ability to introspect any message instance with the generated meta data for the message type. -This is the fundamental capability that allows for generic implementations of functions like "publish to a topic". - -This approach has the advantage that all generated code is middleware agnostic, which means it can be reused for different middleware implementations, so long as they allow for dynamic type support. -It also results in less generated code, which reduces compile time and code size. - -However, dynamic type support requires that the underlying middleware support a similar form of dynamic type support. -In the case of DDS the DDS-XTypes standard allows for publishing of messages using meta information rather than generated code. -DDS-XTypes, or something like it, is required in the underlying middleware in order to support dynamic type support. -Also, this approach to type support is normally slower than the static type support alternative. -The type specific generated code in static type support can be written to be more efficient as it does not need to iterate over the message type's meta data to perform things like serialization. - -The ``rcl`` repository ----------------------- - -The ROS Client Library interface (``rcl`` |API|) can be used by |client libraries| (e.g. ``rclc``, ``rclcpp``, ``rclpy``, etc.) in order to avoid duplicating logic and features. -By reusing the ``rcl`` |API|, client libraries can be smaller and more consistent with each other. -Some parts of the client library are intentionally left out of the ``rcl`` |API| because the language idiomatic method should be used to implement those parts of the system. -A good example of this is the execution model, which ``rcl`` does not address at all. -Instead the client library should provide a language idiomatic solution like ``pthreads`` in C, ``std::thread`` in C++11, and ``threading.Thread`` in Python. -Generally the ``rcl`` interface provides functions that are not specific to a language pattern and are not specific to a particular message type. - -The ``rcl`` |API| is located in the `ros2/rcl `_ repository on |GitHub|_ and contains the interface as C headers. -The ``rcl`` C implementation is provided by the ``rcl`` |package| in the same repository. -This implementation avoids direct contact with the middleware by instead using the ``rmw`` and ``rosidl`` |APIs|. - -For a complete definition of the ``rcl`` |API|, see `the rcl docs `_. - -The ``rmw`` repository ----------------------- - -The ROS middleware interface (``rmw`` |API|) is the minimal set of primitive middleware capabilities needed to build ROS on top. -Providers of different middleware implementations must implement this interface in order to support the entire ROS stack on top. -Currently most of the middleware implementations are for different DDS vendors. - -The ``rmw`` |API| is located in the `ros2/rmw `_ repository. -The ``rmw`` |package| contains the C headers which define the interface, the implementation of which is provided by the various |packages| of rmw implementations for different DDS vendors. - -For a definition of the ``rmw`` |API|, see `the rmw docs `_. - -For a more practical in-depth overview of how ROS 2 integrates with different middleware implementations, see :doc:`the middleware implementation tutorial <../Creating-An-RMW-Implementation>`. - -The ``rosidl`` repository -------------------------- - -The ``rosidl`` |API| consists of a few message related static functions and types along with a definition of what code should be generated by messages in different languages. -The generated message code specified in the |API| will be language specific, but may or may not reuse generated code for other languages. -The generated message code specified in the |API| contains things like the message data structure, functions for construction, destruction, etc. -The |API| will also implement a way to get the type support structure for the message type, which is used when publishing or subscribing to a topic of that message type. - -There are several repositories that play a role in the ``rosidl`` |API| and implementation. - -The ``rosidl`` repository, located on |GitHub|_ at `ros2/rosidl `_, defines the message IDL syntax, i.e. syntax of ``.msg`` files, ``.srv`` files, etc., and contains |packages| for parsing the files, for providing CMake infrastructure to generate code from the messages, for generating implementation agnostic code (headers and source files), and for establishing the default set of generators. -The repository contains these |packages|: - -- ``rosidl_cmake``: provides CMake functions and modules for generating code from ``rosidl`` files, e.g. ``.msg`` files, ``.srv`` files, etc. -- ``rosidl_default_generators``: defines the list of default generators which ensures that they are installed as dependencies, but other injected generators can also be used. -- ``rosidl_generator_c``: provides tools to generate C header files (``.h``) for ``rosidl`` files. -- ``rosidl_generator_cpp``: provides tools to generate C++ header files (``.hpp``) for ``rosidl`` files. -- ``rosidl_generator_py``: provides tools to generate Python modules for ``rosidl`` files. -- ``rosidl_parser``: provides Python |API| for parsing ``rosidl`` files. - -Generators for other languages, e.g. ``rosidl_generator_java``, are hosted externally (in different repositories) but would use the same mechanism that the above generators use to "register" themselves as a ``rosidl`` generator. - -In addition to the aforementioned |packages| for parsing and generating headers for the ``rosidl`` files, the ``rosidl`` repository also contains |packages| concerned with "type support" for the message types defined in the files. -Type support refers to the ability to interpret and manipulate the information represented by ROS message instances of particular types (publishing the messages, for example). -Type support can either be provided by code that is generated at compile time or it can be done programmatically based on the contents of the ``rosidl`` file, e.g. the ``.msg`` or ``.srv`` file, and the data received, by introspecting the data. -In the case of the latter, where type support is done through runtime interpretation of the messages, the message code generated by ROS 2 can be agnostic to the rmw implementation. -The packages that provide this type support through introspection of the data are: - -- ``rosidl_typesupport_introspection_c``: provides tools for generating C code for supporting ``rosidl`` message data types. -- ``rosidl_typesupport_introspection_cpp``: provides tools for generating C++ code for supporting ``rosidl`` message data types. - -In the case where type support is to be generated at compile time instead of being generated programmatically, a package specific to the rmw implementation will need to be used. -This is because typically a particular rmw implementation will require data to be stored and manipulated in a manner that is specific to the DDS vendor in order for the DDS implementation to make use of it. -See the :ref:`Type Specific Interfaces` section above for more details. - -The ``rosidl_generator_cpp`` package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This package is responsible for generating the C++ structures representing the IDL. -It also generates utilities for user-convenience and to facilitate interoperability with the C++ language. - -Message member names -"""""""""""""""""""" -The names of the members in a message can be retrieved at compile-time using ``rosidl_generator_traits::MessageTraits``. - -.. code-block:: cpp - - #include - - // ... - - using MessageTraitsTime = rosidl_generator_traits::MessageTraits; - std::array member_names = MessageTraitsTime::member_names; // Returns {"sec", "nanosec"} - -Message member metaprogramming -"""""""""""""""""""""""""""""" -To facilitate metaprogramming techniques ahead of C++26 reflection, an ``as_tuple_ref`` utility has been added to the code generation. -It returns references to each member of the structure as a tuple. -This makes it possible to both read and write message contents without accessing it through the member name. - -.. code-block:: cpp - - #include - #include - - // ... - - // Increment both members using ``std::apply`` and a fold-expression - builtin_interfaces::msg::Time time; - std::apply([](auto & ... member) { - ((member += 1), ...); - }, as_tuple_ref(msg)); - -.. warning:: - - Members of the same type can be swapped without detection using this technique. - Use with care if the interfaces can change. - The ``as_tuple_ref`` function does not extend the lifetime of the message passed to is. - It is the responsibility of the programmer to ensure that the lifetime of the message object exceeds the use of the references. - -The ``rcutils`` repository --------------------------- - -ROS 2 C Utilities (``rcutils``) is a C |API| composed of macros, functions, and data structures used throughout the ROS 2 codebase. -These are mainly used for error handling, commandline argument parsing, and logging which are not specific to the client or middleware layers and can be shared by both. - -The ``rcutils`` |API| and implementation are located in the `ros2/rcutils `_ repository on |GitHub|_ which contains the interface as C headers. - +.. redirect-from:: + + Concepts/About-Internal-Interfaces + Concepts/Advanced/About-Internal-Interfaces + +Internal ROS 2 interfaces +========================= + +.. contents:: Table of Contents + :local: + +.. include:: ../../../../global_substitutions.txt + +The internal ROS interfaces are public C |APIs| that are intended for use by developers who are creating |client libraries| or adding a new underlying middleware, but are not intended for use by typical ROS users. +The ROS |client libraries| provide the user facing |APIs| that most ROS users are familiar with, and may come in a variety of programming languages. + +Internal API Architecture Overview +---------------------------------- + +There are two main internal interfaces: + +- the ROS middleware interface (``rmw`` |API|) +- the ROS client library interface (``rcl`` |API|) + +The ``rmw`` |API| is the interface between the ROS 2 software stack and the underlying middleware implementation. +The underlying middleware used for ROS 2 is either a DDS or RTPS implementation, and is responsible for discovery, publish and subscribe mechanics, request-reply mechanics for services, and serialization of message types. + +The ``rcl`` |API| is a slightly higher level |API| which is used to implement the |client libraries| and does not touch the middleware implementation directly, but rather does so through the ROS middleware interface (``rmw`` |API|) abstraction. + +.. figure:: images/ros_client_library_api_stack.png + :alt: ros2 software stack + +As the diagram shows, these |APIs| are stacked such that the typical ROS user will use the |client library| |API|, e.g. ``rclcpp``, to implement their code (executable or library). +The implementation of the |client libraries|, e.g. ``rclcpp``, use the ``rcl`` interface which provides access to the ROS graph and graph events. +The ``rcl`` implementation in turn uses the ``rmw`` |API| to access the ROS graph. +The purpose of the ``rcl`` implementation is to provide a common implementation for more complex ROS concepts and utilities that may be used by various |client libraries|, while remaining agnostic to the underlying middleware being used. +The purpose of the ``rmw`` interface is to capture the absolute minimum middleware functionality needed to support ROS's client libraries. +Finally, the implementation of the ``rmw`` |API| is provided by a middleware implementation specific |package|, e.g. ``rmw_fastrtps_cpp``, the library of which is compiled against vendor specific DDS interfaces and types. + +In the diagram above there is also a box labeled ``ros_to_dds``, and the purpose of this box is to represent a category of possible packages which allow the user to access DDS vendor specific objects and settings using the ROS equivalents. +One of the goals of this abstraction interface is to completely insulate the ROS user space code from the middleware being used, so that changing DDS vendors or even middleware technology has a minimal impact on the users code. +However, we recognize that on occasion it is useful to reach into the implementation and manually adjust settings despite the consequences that might have. +By requiring the use of one of these packages in order to access the underlying DDS vendor's objects, we can avoid exposing vendor specific symbols and headers in the normal interface. +It also makes it easy to see what code is potentially violating the vendor portability by inspecting the package's dependencies to see if one of these ``ros_to_dds`` packages are being used. + +.. _Type Specific Interfaces: + +Type Specific Interfaces +------------------------ + +All along the way there are some parts of the |APIs| that are necessarily specific to the message types being exchanged, e.g. publishing a message or subscribing to a topic, and therefore require generated code for each message type. +The following diagram layouts the path from user defined ``rosidl`` files, e.g. ``.msg`` files, to the type specific code used by the user and system to perform type specific functions: + +.. figure:: images/ros_idl_api_stack_static.png + :alt: ros2 idl static type support stack + + Figure: flow chart of "static" type support generation, from ``rosidl`` files to user facing code. + +The right hand side of the diagram shows how the ``.msg`` files are passed directly to language specific code generators, e.g. ``rosidl_generator_cpp`` or ``rosidl_generator_py``. +These generators are responsible for creating the code that the user will include (or import) and use as the in-memory representation of the messages that were defined in the ``.msg`` files. +For example, consider the message ``std_msgs/String``, a user might use this file in C++ with the statement ``#include ``, or they might use the statement ``from std_msgs.msg import String`` in Python. +These statements work because of the files generated by these language specific (but middleware agnostic) generator packages. + +Separately, the ``.msg`` files are used to generate type support code for each type. +In this context, type support means: meta data or functions that are specific to a given type and that are used by the system to perform particular tasks for the given type. +The type support for a given message might include things like a list of the names and types for each field in the message. +It might also contain a reference to code that can perform particular tasks for that type, e.g. publish a message. + +.. _internal-interfaces_static-type-support: + +Static Type Support +^^^^^^^^^^^^^^^^^^^ + +When the type support references code to do particular functions for a specific message type, that code sometimes needs to do middleware specific work. +For example, consider the type specific publish function, when using "vendor A" the function will need to call some of "vendor A"'s |API|, but when using "vendor B" it will need to call "vendor B"'s |API|. +To allow for middleware vendor specific code, the user defined ``.msg`` files may result in the generation of vendor specific code. +This vendor specific code is still hidden from the user through the type support abstraction, which is similar to how the "Private Implementation" (or Pimpl) pattern works. + +Static Type Support with DDS +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For middleware vendors based on DDS, and specifically those which generate code based on the OMG IDL files (``.idl`` files), the user defined ``rosidl`` files (``.msg`` files) are converted into equivalent OMG IDL files (``.idl`` files). +From these OMG IDL files, vendor specific code is created and then used within the type specific functions which are referenced by the type support for a given type. +The above diagram shows this on the left hand side, where the ``.msg`` files are consumed by the ``rosidl_dds`` package to produce ``.idl`` files, and then those ``.idl`` files are given to language specific and DDS vendor specific type support generation packages. + +For example, consider the Fast DDS implementation, which has a package called ``rosidl_typesupport_fastrtps_cpp``. +This package is responsible for generating code to handle things like converting a C++ message object into a serialized octet buffer to be written over the network. +This code, while specific to Fast DDS, is still not exposed to the user because of the abstraction in the type support code. + +.. _internal-interfaces_dynamic-type-support: + +Dynamic Type Support +^^^^^^^^^^^^^^^^^^^^ + +Another way to implement type support is to have generic functions for things like publishing to a topic, rather than generating a version of the function for each message type. +In order to accomplish this, this generic function needs some meta information about the message type being published, things like a list of field names and types in the order in which they appear in the message type. +Then to publish a message, you call a generic publish function and pass a message to be published along with a structure which contains the necessary meta data about the message type. +This is referred to as "dynamic" type support, as opposed to "static" type support which requires generated versions of a function for each type. + +.. figure:: images/ros_idl_api_stack_dynamic.png + :alt: ros2 idl dynamic type support stack + + Figure: flow chart of "dynamic" type support generation, from ``rosidl`` files to user facing code. + +The above diagram shows the flow from user defined ``rosidl`` files to generated user facing code. +It is very similar to the diagram for static type support, and differs only in how the type support is generated which is represented by the left hand side of the diagram. +In dynamic type support the ``.msg`` files are converted directly into user facing code. + +This code is also middleware agnostic, because it only contains meta information about the messages. +The function to actually do the work, e.g. publishing to a topic, is generic to the message type and will make any necessary calls to the middleware specific |APIs|. +Note that rather than dds vendor specific packages providing the type support code, which is the case in static type support, this method has middleware agnostic package for each language, e.g. ``rosidl_typesupport_introspection_c`` and ``rosidl_typesupport_introspection_cpp``. +The ``introspection`` part of the package name refers to the ability to introspect any message instance with the generated meta data for the message type. +This is the fundamental capability that allows for generic implementations of functions like "publish to a topic". + +This approach has the advantage that all generated code is middleware agnostic, which means it can be reused for different middleware implementations, so long as they allow for dynamic type support. +It also results in less generated code, which reduces compile time and code size. + +However, dynamic type support requires that the underlying middleware support a similar form of dynamic type support. +In the case of DDS the DDS-XTypes standard allows for publishing of messages using meta information rather than generated code. +DDS-XTypes, or something like it, is required in the underlying middleware in order to support dynamic type support. +Also, this approach to type support is normally slower than the static type support alternative. +The type specific generated code in static type support can be written to be more efficient as it does not need to iterate over the message type's meta data to perform things like serialization. + +The ``rcl`` repository +---------------------- + +The ROS Client Library interface (``rcl`` |API|) can be used by |client libraries| (e.g. ``rclc``, ``rclcpp``, ``rclpy``, etc.) in order to avoid duplicating logic and features. +By reusing the ``rcl`` |API|, client libraries can be smaller and more consistent with each other. +Some parts of the client library are intentionally left out of the ``rcl`` |API| because the language idiomatic method should be used to implement those parts of the system. +A good example of this is the execution model, which ``rcl`` does not address at all. +Instead the client library should provide a language idiomatic solution like ``pthreads`` in C, ``std::thread`` in C++11, and ``threading.Thread`` in Python. +Generally the ``rcl`` interface provides functions that are not specific to a language pattern and are not specific to a particular message type. + +The ``rcl`` |API| is located in the `ros2/rcl `_ repository on |GitHub|_ and contains the interface as C headers. +The ``rcl`` C implementation is provided by the ``rcl`` |package| in the same repository. +This implementation avoids direct contact with the middleware by instead using the ``rmw`` and ``rosidl`` |APIs|. + +For a complete definition of the ``rcl`` |API|, see `the rcl docs `_. + +The ``rmw`` repository +---------------------- + +The ROS middleware interface (``rmw`` |API|) is the minimal set of primitive middleware capabilities needed to build ROS on top. +Providers of different middleware implementations must implement this interface in order to support the entire ROS stack on top. +Currently most of the middleware implementations are for different DDS vendors. + +The ``rmw`` |API| is located in the `ros2/rmw `_ repository. +The ``rmw`` |package| contains the C headers which define the interface, the implementation of which is provided by the various |packages| of rmw implementations for different DDS vendors. + +For a definition of the ``rmw`` |API|, see `the rmw docs `_. + +For a more practical in-depth overview of how ROS 2 integrates with different middleware implementations, see :doc:`the middleware implementation tutorial <../Working-with-Client-Libraries/Creating-An-RMW-Implementation>`. + +The ``rosidl`` repository +------------------------- + +The ``rosidl`` |API| consists of a few message related static functions and types along with a definition of what code should be generated by messages in different languages. +The generated message code specified in the |API| will be language specific, but may or may not reuse generated code for other languages. +The generated message code specified in the |API| contains things like the message data structure, functions for construction, destruction, etc. +The |API| will also implement a way to get the type support structure for the message type, which is used when publishing or subscribing to a topic of that message type. + +There are several repositories that play a role in the ``rosidl`` |API| and implementation. + +The ``rosidl`` repository, located on |GitHub|_ at `ros2/rosidl `_, defines the message IDL syntax, i.e. syntax of ``.msg`` files, ``.srv`` files, etc., and contains |packages| for parsing the files, for providing CMake infrastructure to generate code from the messages, for generating implementation agnostic code (headers and source files), and for establishing the default set of generators. +The repository contains these |packages|: + +- ``rosidl_cmake``: provides CMake functions and modules for generating code from ``rosidl`` files, e.g. ``.msg`` files, ``.srv`` files, etc. +- ``rosidl_default_generators``: defines the list of default generators which ensures that they are installed as dependencies, but other injected generators can also be used. +- ``rosidl_generator_c``: provides tools to generate C header files (``.h``) for ``rosidl`` files. +- ``rosidl_generator_cpp``: provides tools to generate C++ header files (``.hpp``) for ``rosidl`` files. +- ``rosidl_generator_py``: provides tools to generate Python modules for ``rosidl`` files. +- ``rosidl_parser``: provides Python |API| for parsing ``rosidl`` files. + +Generators for other languages, e.g. ``rosidl_generator_java``, are hosted externally (in different repositories) but would use the same mechanism that the above generators use to "register" themselves as a ``rosidl`` generator. + +In addition to the aforementioned |packages| for parsing and generating headers for the ``rosidl`` files, the ``rosidl`` repository also contains |packages| concerned with "type support" for the message types defined in the files. +Type support refers to the ability to interpret and manipulate the information represented by ROS message instances of particular types (publishing the messages, for example). +Type support can either be provided by code that is generated at compile time or it can be done programmatically based on the contents of the ``rosidl`` file, e.g. the ``.msg`` or ``.srv`` file, and the data received, by introspecting the data. +In the case of the latter, where type support is done through runtime interpretation of the messages, the message code generated by ROS 2 can be agnostic to the rmw implementation. +The packages that provide this type support through introspection of the data are: + +- ``rosidl_typesupport_introspection_c``: provides tools for generating C code for supporting ``rosidl`` message data types. +- ``rosidl_typesupport_introspection_cpp``: provides tools for generating C++ code for supporting ``rosidl`` message data types. + +In the case where type support is to be generated at compile time instead of being generated programmatically, a package specific to the rmw implementation will need to be used. +This is because typically a particular rmw implementation will require data to be stored and manipulated in a manner that is specific to the DDS vendor in order for the DDS implementation to make use of it. +See the :ref:`Type Specific Interfaces` section above for more details. + +The ``rosidl_generator_cpp`` package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +This package is responsible for generating the C++ structures representing the IDL. +It also generates utilities for user-convenience and to facilitate interoperability with the C++ language. + +Message member names +"""""""""""""""""""" +The names of the members in a message can be retrieved at compile-time using ``rosidl_generator_traits::MessageTraits``. + +.. code-block:: cpp + + #include + + // ... + + using MessageTraitsTime = rosidl_generator_traits::MessageTraits; + std::array member_names = MessageTraitsTime::member_names; // Returns {"sec", "nanosec"} + +Message member metaprogramming +"""""""""""""""""""""""""""""" +To facilitate metaprogramming techniques ahead of C++26 reflection, an ``as_tuple_ref`` utility has been added to the code generation. +It returns references to each member of the structure as a tuple. +This makes it possible to both read and write message contents without accessing it through the member name. + +.. code-block:: cpp + + #include + #include + + // ... + + // Increment both members using ``std::apply`` and a fold-expression + builtin_interfaces::msg::Time time; + std::apply([](auto & ... member) { + ((member += 1), ...); + }, as_tuple_ref(msg)); + +.. warning:: + + Members of the same type can be swapped without detection using this technique. + Use with care if the interfaces can change. + The ``as_tuple_ref`` function does not extend the lifetime of the message passed to is. + It is the responsibility of the programmer to ensure that the lifetime of the message object exceeds the use of the references. + +The ``rcutils`` repository +-------------------------- + +ROS 2 C Utilities (``rcutils``) is a C |API| composed of macros, functions, and data structures used throughout the ROS 2 codebase. +These are mainly used for error handling, commandline argument parsing, and logging which are not specific to the client or middleware layers and can be shared by both. + +The ``rcutils`` |API| and implementation are located in the `ros2/rcutils `_ repository on |GitHub|_ which contains the interface as C headers. + For a complete definition of the ``rcutils`` |API|, see `the rcutils docs `_. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst index 741f19e629e..03a35ca82b3 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst @@ -1,485 +1,485 @@ -.. redirect-from:: - - Tutorials/Advanced/Creating-An-RMW-Implementation - -Creating an ``rmw`` implementation -================================== - -**Goal:** Learn how to create a new ``rmw`` implementation, from the features required from the underlying middleware to the ``rmw`` implementation details. - -**Tutorial level:** Advanced - -**Time:** 30+ minutes - -.. contents:: Table of Contents - :local: - -Introduction ------------- - -ROS 2's architecture has two main :doc:`abstraction layers `. -From top to bottom: - -#. The client library interface, ``rcl``, which supports the user-facing :doc:`client libraries <../../About-Client-Libraries>`, such as ``rclcpp`` and ``rclpy`` -#. The middleware interface, ``rmw``, which abstracts away the :doc:`underlying middleware implementation <../About-Different-Middleware-Vendors>`, such as a specific DDS implementation, Zenoh, etc. - -The ``rmw`` `API includes function-level documentation `_, but there is no higher-level documentation on the features of the interface and what it expects from the underlying middleware. - -This guide is for developers who want to implement the ``rmw`` interface for a specific middleware. -It will first go over the ``rmw`` interface and how it works. -Then it will cover the main concepts or features that a middleware implementation must support. -Finally, it will go over some implementation details, including how to create an implementation skeleton and some tips to implement the interface functions. - -This guide is intended to be an entry point to kickstart the development of a new ``rmw`` implementation. -It will link to other pages and source code for more details where appropriate. - -.. note:: - - ROS 2 design articles on `design.ros2.org `_ are historical documents and may not reflect the current state of ROS 2. - However, in some cases, they provide useful context and information, so they may still be referenced by this guide or by pages that this guide links to. - -The ``rmw`` interface ---------------------- - -The ``rmw`` interface is declared by the ``rmw`` package through `C header files `_. -Implementations of the C functions declared in these headers are provided by ``rmw`` implementations, which are separate packages. -For example, the ``rmw_fastrtps_cpp`` package implements the interface for eProsima Fast DDS. - -Example implementations -^^^^^^^^^^^^^^^^^^^^^^^ - -The following ``rmw`` :doc:`implementations <../About-Middleware-Implementations>` can be used as references. -Note that there are different `support tiers, which are defined by REP 2000 `_. - -#. DDS: - - #. ``rmw_fastrtps_cpp``, ``rmw_fastrtps_dynamic_cpp``: `ros2/rmw_fastrtps `_ - #. ``rmw_cyclonedds_cpp``: `ros2/rmw_cyclonedds `_ - #. ``rmw_connextdds``: `ros2/rmw_connextdds `_ - #. ``rmw_gurumdds_cpp``: `ros2/rmw_gurumdds `_ - - * See :ref:`this overview ` - -#. ``rmw_zenoh_cpp``: `ros2/rmw_zenoh `_ - - * See :ref:`this overview ` and the `design document `_ - -#. ``rmw_email_cpp``, an email-based implementation: `christophebedard/rmw_email `_ - - * See the `design document for the underlying email middleware `_ and the `blog post for some context `_ - -.. _rmw-impl-guide_selection-mechanism: - -Build-time and runtime ``rmw`` implementation selection mechanism -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The dependency on the actual ``rmw`` implementation is done through the ``rmw_implementation`` `package `_. -Users of ``rmw``, such as ``rcl``, depend on the ``rmw`` package for the interface (headers) and some utility functions. -They also depend on the ``rmw_implementation`` package to get the actual implementation. - -By default, ROS 2 allows you to choose which ``rmw`` implementation to use at runtime. -This is convenient for comparing two implementations on the same machine, and it lets ROS 2 distribute a single set of binaries that is compatible with multiple ``rmw`` implementations. -The :doc:`implementation is selected at runtime <../../../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` through the ``RMW_IMPLEMENTATION`` environment variable, or, if that variable is unset, a default ``rmw`` implementation is loaded. - -This is accomplished by the ``rmw_implementation`` package, which acts as a proxy for an actual ``rmw`` implementation. -It works by creating placeholder ``rmw`` functions. -When they are called, it will ``dlopen()`` the appropriate library for the selected ``rmw`` implementation and then look up the corresponding symbols in the loaded shared library using the ``dlsym()`` function before calling them. - -The ``rmw_implementation`` package can be configured at build-time to change the default option or disable runtime selection. -The default implementation can be selected at build-time with the ``RMW_IMPLEMENTATION`` CMake variable (e.g., ``-DRMW_IMPLEMENTATION=rmw_other``) or the ``RMW_IMPLEMENTATION`` environment variable. -If only one implementation is available at build-time, or if runtime selection is disabled (``-DRMW_IMPLEMENTATION_DISABLE_RUNTIME_SELECTION=ON``), the ``rmw_implementation`` target will be a simple ``INTERFACE`` library for the single implementation. - -Because of the proxy mechanism and the CMake logic described above, an ``rmw`` implementation that does not implement all of the functions in the interface will only fail at runtime, when the symbol lookup fails, as opposed to failing at build-time (specifically at link-time) if runtime selection is disabled. - -Features --------- - -This section goes over the main features of the ``rmw`` interface, which the underlying middleware must support or deal with. -Depending on the middleware -- and how similar it is to the features expected by the interface -- the ``rmw`` implementation may be more or less trivial, i.e., it might have to do more "glue" work. -For some non-critical features or configuration options, the implementation can indicate that they are not supported through ``rmw_feature_supported()`` or by returning ``RMW_RET_UNSUPPORTED``. -In any case, any special behavior of the ``rmw`` implementation should ideally be documented. - -Topics, pub/sub, services -^^^^^^^^^^^^^^^^^^^^^^^^^ - -:doc:`Topics <../../About-Topics>` are a common concept in publish/subscribe middleware. -However, ROS 2 has its own topic name conventions, which is validated using ``rmw_validate_full_topic_name()``. -The ``rmw`` implementation simply has to use the given (resolved) topic name. -This might involve adapting or mangling the ROS topic name to fit the underlying middleware's topic name conventions or constraints, or encode useful information. -For example, a pub/sub topic called ``/chatter`` is usually mangled into ``rt/chatter`` for DDS-based implementations, making ROS topics on DDS easily distinguishable from normal DDS topics. -See the `"Mapping of ROS 2 Topic and Service Names to DDS Concepts" section in this design document `_. -For Zenoh, the domain ID, resolved topic name, topic type name, and topic type hash are `encoded in the underlying Zenoh key `_ to avoid communications between different ROS topic names & types. - -As for :doc:`services <../../About-Services>`, they are not always natively supported by the underlying middleware. -For DDS-based implementations, they are simply built on top of pub/sub: 1 request topic and 1 response topic. -[#fn_dds_rpc]_ -On the other hand, Zenoh natively supports services through `queryables `_, so they are used to implement services in ``rmw_zenoh_cpp``. - -Note that, while services are a part of the ``rmw`` interface, :doc:`actions <../../About-Actions>` are not. -They are an ``rcl`` concept implemented in the ``rcl_action`` package on top of services and pub/sub. - -Nodes -^^^^^ - -:doc:`Nodes <../../About-Nodes>` are mostly a ROS concept. -Neither DDS nor Zenoh has a corresponding concept, so they are mostly a logical concept in the ``rmw`` implementation. -Topic names get resolved with the node namespace/name, if needed, by ``rcl`` before they are passed to ``rmw`` when creating a pub/sub object. -Implementations just have to make sure to include nodes in :ref:`introspection data `. - -.. _rmw-impl-guide_waitsets: - -Wait sets and waiting -^^^^^^^^^^^^^^^^^^^^^ - -:doc:`Executors <../About-Executors/About-Executors>` are responsible for triggering user-provided callbacks when a new message is received, for example. -Executors are implemented at the client library level (``rclcpp``, ``rclpy``), but they rely on the underlying middleware to wait for new messages using a polling mechanism. -This is done using wait sets, which allow waiting on different entities at the same time in a standard way, e.g., subscriptions, service clients, and service servers. -The ``rmw_wait()`` `function `_ is called with lists of entities to wait on, as well as an implementation-specific wait set object. -It adds all entities to the wait set and asks it to wait until at least one entity has new data available or until it times out. -Then the executor checks the lists of entities to see which ones have new data available and triggers the corresponding callbacks. - -The key mechanism here is the ability to check if a given entity is ready, e.g., check if a subscription has a new message. -Then waiting simply involves continuously checking entities one at a time until one is ready or until the wait times out. - -Take a look at how ``rmw_email_cpp`` `implements wait sets and waiting `_ and dig down to the middleware, ``email``, since it's fairly simple. - -Taking data -^^^^^^^^^^^ - -Once an :ref:`executor is done waiting ` and there is a new message, request, or response, it takes it from the middleware and triggers the corresponding callback. -For instance, ``rmw_take()`` is called with a subscription and a type-erased pointer to an instance of the corresponding message type to write to. - -``rmw_email_cpp`` takes the new message (YAML string) from the underlying email middleware subscription object, and converts it into a ROS message by writing into the provided message. - -Metadata: GIDs, timestamps, sequence numbers -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Aside from actual user-specified data, message publications, service requests, service responses, and so on also have metadata associated with them: - -* GID: globally-unique ID that identifies an entity (e.g., pub, sub, client, server) - - * The GID for an entity should be unique within a ROS domain and should be the same when reported both locally and remotely. - For example, the publisher GID for a message being published should be the same publisher GID reported on the other side, when that message is received by a subscription. - [#fn_gid_remote_matching]_ - -* Source & received timestamps: publication & subscription reception timestamps, respectively - -* Publication & reception sequence numbers - -This means that service request metadata includes the GID of the client that made the request and the request sequence number. -Service response metadata also includes the client GID & sequence number of the request it is responding to. - -This metadata is available as structs through ``rmw_take_with_info()`` for subscription messages and ``rmw_take_{request,response}()`` for service requests/responses, which are wrapped & provided to user callbacks by the client libraries. - -Part of this metadata might be natively supported and provided by the underlying middleware, while another part might have to be included and transmitted alongside the application data by the ``rmw`` implementation. -For instance, DDS natively supports all of it for pub/sub through DDS sample info, but the client request metadata needs to be wrapped alongside the service response data by the ``rmw`` implementation. -``email`` natively supports all of this metadata, which is included in standard email headers (i.e., not in the email body). - -.. _rmw-impl-guide_typesupport: - -Type support -^^^^^^^^^^^^ - -To bridge the gap between ROS 2 :doc:`interfaces <../../About-Interfaces>` (specifically :doc:`custom interfaces `) and the underlying middleware, some glue code is needed. -This is referred to as :ref:`type support `. -When publishing a message of type {interface(std_msgs/msg/String)}, ``rmw_publish()`` only gets a ``void *`` to the message, which could point to a C++ instance, or a C instance, and so on. -The pointer will be interpreted based on the type support information provided when the publisher was created. - -First, code is generated for each combination of interface type and user-facing language, independent of the underlying middleware. -For example, for the {interface(std_msgs/msg/String)} message type, data structures are generated: - -#. C++: ``std_msgs/msg/string.hpp`` header with ``std_msgs::msg::String`` class generated by the ``rosidl_generator_cpp`` package -#. C: ``std_msgs/msg/string.h`` header with ``std_msgs__msg__String`` struct generated by the ``rosidl_generator_c`` package -#. Python: ``std_msgs`` module with ``std_msgs.msg.String`` class (which is just a wrapper around the C struct) generated by the ``rosidl_generator_py`` package -#. (and so on, e.g., for Rust) - -Second, for the underlying middleware to be able to send and receive messages, it needs to know how to interpret the user-facing data structure. -This is one of the most critical parts of an ``rmw`` implementation. -There are two options: :ref:`static type support ` and :ref:`dynamic type support `. -Static type support involves generating middleware-specific code for each interface. -For example, ``rosidl_typesupport_fastrtps_cpp`` generates code to serialize/deserialize C++ classes of each interface type into CDR using `Fast CDR `_ for ``rmw_fastrtps_cpp`` to pass on to Fast DDS. -[#fn_ts_fastrtps]_ -``rmw_connextdds`` and even ``rmw_zenoh_cpp`` use CDR for serialization, so they use this type support package as well. -On the other hand, dynamic type support involves generating a bit of middleware-independent code that provides generic information about each interface type. -[#fn_ts_dynamic]_ - -This information can be used at runtime by any ``rmw`` implementation to interpret a type-erased pointer to data: names & types of fields, functions to read from/write to fields depending on their type, functions to get the size of an array field, etc. -For C++, this is ``rosidl_typesupport_introspection_cpp``, which is used by ``rmw_fastrtps_dynamic_cpp`` (hence the "dynamic" part), for example. - -Dynamic type support is generally slower than static type support at runtime because it has to iterate over each message field, figure out what type it is, and then process it, e.g., serialize it. -Static type support knows exactly how to process the message thanks to the code it generated for each interface type. -This is why most ``rmw`` implementations use static type support. -However, dynamic type support does not require generating middleware-specific code. -Choosing between static and dynamic type support is an orthogonal decision to the ``rmw`` implementation itself. - -``rmw_email_cpp`` uses dynamic type support to convert messages to and from YAML string to be sent over email. -It gets the type support introspection information, and passes it and the message to an external/experimental package, `dynmsg `_, which converts the message to/from YAML. -The YAML object is then sent as a YAML-formatted string via email using the underlying middleware. -When a new message is received by the middleware, the YAML string is converted into a message. - -Domain ID -^^^^^^^^^ - -:doc:`Domain IDs <../../nodes/About-Domain-ID>` are a way to have separate logical networks on the same physical network. -It is a native feature of DDS, but not Zenoh. -DDS achieves this by using the domain ID as a network port offset, while Zenoh implements it by making the domain ID the first component of the internal Zenoh key corresponding to each ROS 2 topic. - -Quality of service (QoS) -^^^^^^^^^^^^^^^^^^^^^^^^ - -:doc:`Quality of service settings <../../topics/About-Quality-of-Service-Settings>` in ROS 2 are largely derived from DDS. -Basic QoS policies like history, depth, and durability are the same as ROS 1's, but more advanced policies simply come from DDS. -Implementations may simply ignore some settings. -For instance, ``rmw_zenoh_cpp`` doesn't implement the deadline and lifespan QoS policies. - -One important aspect of QoS is that two profiles, e.g., a publisher's profile and a subscription's profile, may be incompatible, meaning they cannot communicate. -It is up to the implementation to decide if two QoS profiles are compatible: ``rmw_qos_profile_check_compatible()``. -DDS-based implementations rely on ``rmw_dds_common::qos_profile_check_compatible()``, since :ref:`QoS profile compatibility ` is standard in DDS. -In Zenoh, `QoS settings are essentially never incompatible `_. - -To support a universal "default" behavior, QoS policies include a ``*_SYSTEM_DEFAULT`` setting (e.g., ``rmw_qos_reliability_policy_t``'s ``RMW_QOS_POLICY_RELIABILITY_SYSTEM_DEFAULT``), which leaves the value up to the middleware implementation. -Then the ``rmw_*_get_actual_qos()`` functions retrieve the actual QoS profile used by the implementation. - -.. _rmw-impl-guide_introspection: - -ROS graph introspection -^^^^^^^^^^^^^^^^^^^^^^^ - -Nodes are able to get a list of other nodes, topics, etc. -This also allows publishers to know if any subscriptions exist for their topic, for example. -This same mechanism is used to :doc:`list nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, and so on with the ROS 2 CLI: ``ros2 node list``, ``ros2 topic list``, etc. - -This is supported by a number of ``rmw`` functions: ``rmw_get_node_names()``, ``rmw_get_topic_names_and_types()``, ``rmw_publisher_count_matched_subscriptions()``, and many more. -While the implementation is not specified by the interface, ``rmw`` implementations usually maintain a cache of the ROS graph. -When they create a new entity (e.g., node, publisher, subscription, service, client), they note it in their internal graph cache and notify other participants through a middleware-specific mechanism so that they can add it to their cache. -The graph cache belongs to the ``rmw`` context, so it is initialized when ``rmw_init()`` is called. -This context indirectly belongs to the ``rclcpp`` context (e.g., initialized by ``rclcpp::init()``), so there is usually only one graph cache per process. - -Since DDS-based ``rmw`` implementations are very similar in this regard, they share a common graph cache implementation in the ``rmw_dds_common`` `package `__. -It uses an internal topic (usually ``ros_discovery_info``) to share information about new entities. -``rmw_zenoh_cpp`` `creates a Zenoh liveliness token `_ with the entity type & info and shares it with other participants. - -Events -^^^^^^ - -Users can provide callbacks for publishers & subscriptions to be triggered by the middleware (but executed by the client library) on certain events (``rmw_event_type_t``), such as :ref:`quality of service-related events ` and :ref:`pub-sub match events `. -Some of these events could be triggered on relevant changes to the graph cache. - -Security -^^^^^^^^ - -:doc:`Security <../../../Developer-Tools/Introspection-and-analysis/About-Security>` is not well-specified by the ``rmw`` interface; most of it is specified by :doc:`SROS2 <../../../Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security>`. -The interface only defines a few security options as part of the context initialization options, ``rmw_init_options_t``: - -#. ``rmw_security_options_t``, which includes a security policy (enforce/permissive) and a path to a directory containing security artifacts, i.e., a keystore. - These are set by ``rcl`` based on environment variables: ``ROS_SECURITY_ENABLE`` & ``ROS_SECURITY_STRATEGY`` and ``ROS_SECURITY_KEYSTORE``. -#. The name of a security enclave from the keystore to use for the given process. - This is set, for example, through the ``--enclave`` option when running a node with ``ros2 run``. - -However, in practice, the structure of the :doc:`keystore <../../../Developer-Tools/Build/The-Keystore>` directory and its security enclaves is based on the DDS Security specification. -Therefore, :doc:`security artifacts generated <../../../Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security>` with the ``sros2`` package can only be directly used by DDS-based ``rmw`` implementations. -For ``rmw_zenoh_cpp``, `Zenoh-specific security configuration files can be generated `_ from ``sros2``-generated artifacts using the ``zenoh_security_tools`` package and provided through the ``ZENOH_SESSION_CONFIG_URI`` environment variable, bypassing the ``ROS_SECURITY_*`` environment variables. - -Implementation --------------- - -Implementation skeleton -^^^^^^^^^^^^^^^^^^^^^^^ - -This section covers concrete steps to create the base files and directories for the new implementation package, including special handling in ``package.xml`` and ``CMakeLists.txt``. - -Start with the :doc:`package creation tutorial ` to create an empty package. -Then make the following changes: - -#. ``package.xml`` - - #. Define a package/implementation name - - The package name is also the name of the ``rmw`` implementation. - It will be used to :ref:`select the implementation ` through the ``RMW_IMPLEMENTATION`` environment variable or CMake option, for example. - The name usually starts with ``rmw_`` and is followed by the name of the underlying middleware. - Most :doc:`implementations in the ROS 2 ecosystem <../About-Different-Middleware-Vendors>` then append a suffix such as ``_cpp`` to indicate that the implementation is written in C++. - However, that is not required. - Examples: ``rmw_fastrtps_cpp``, ``rmw_cyclonedds_cpp``, ``rmw_connextdds``, ``rmw_zenoh_cpp``, and ``rmw_email_cpp``. - - .. code-block:: xml - - - rmw_IMPLEMENTATION_NAME_cpp - - #. Declare a dependency on ``rmw`` - - Since the package will implement the interface declared in the ``rmw`` package and will depend on some utility functions. - - .. code-block:: xml - - rmw - - #. Declare a dependency on the required type support packages - - See the :ref:`type support section ` for details. - - .. code-block:: xml - - - rosidl_typesupport_fastrtps_c - rosidl_typesupport_fastrtps_cpp - rosidl_typesupport_introspection_c - rosidl_typesupport_introspection_cpp - - #. Declare membership of the ``rmw_implementation_packages`` group - - This allows the ``rmw_implementation`` package to `depend on the implementation `_ so that it gets built alongside other implementations, since no package otherwise explicitly depends on any ``rmw`` implementations. - This way it can be found and used if selected. - - .. code-block:: xml - - rmw_implementation_packages - -#. ``CMakeLists.txt`` - - #. Create the library target - - The library has to be a shared library. - It should depend on ``rmw`` for headers and utility functions as well as the required type support packages. - It will also depend on the underlying middleware. - - .. code-block:: cmake - - add_library(${PROJECT_NAME} SHARED - src/file.cpp - # ... - ) - target_link_libraries(${PROJECT_NAME} PUBLIC - rmw::rmw - ) - target_link_libraries(${PROJECT_NAME} PRIVATE - rosidl_typesupport_fastrtps_c::rosidl_typesupport_fastrtps_c - rosidl_typesupport_fastrtps_cpp::rosidl_typesupport_fastrtps_cpp - rosidl_typesupport_introspection_c::rosidl_typesupport_introspection_c - rosidl_typesupport_introspection_cpp::rosidl_typesupport_introspection_cpp - # TODO add any implementation-specific dependencies, e.g., underlying middleware - ) - - #. Configure the implementation library target - - In practice, this simply makes symbols hidden by default to hide internal symbols, i.e., non-``rmw`` interface symbols. - If the implementation is written in C (not common), specify ``LANGUAGE "C"``. - - .. code-block:: cmake - - configure_rmw_library(${PROJECT_NAME}) - - #. Register the ``rmw`` implementation - - This registers the implementation in the :ref:`ament index ` so that it can be found at build-time (``get_available_rmw_implementations()``, ``get_rmw_typesupport()``) or at runtime (``ament_index_cpp::get_resources("rmw_typesupport")``). - It also registers the languages that the implementation supports and the list of type support packages. - For example, if the implementation only uses type support introspection (i.e., dynamic and not static) for C and C++ messages: - - .. code-block:: cmake - - register_rmw_implementation( - "c:rosidl_typesupport_introspection_c" - "cpp:rosidl_typesupport_introspection_cpp" - ) - - .. For example, the Python client library, ``rclpy``, uses C typesupport, and checks if C typesupport is available using ``get_rmw_typesupport()``, so the ``rmw`` implementation must support it. - - #. Install and export target - - .. code-block:: cmake - - install( - TARGETS ${PROJECT_NAME} - EXPORT ${PROJECT_NAME} - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin - ) - - ament_export_targets(${PROJECT_NAME}) - # ament_export_libraries(${PROJECT_NAME}) # Old-style CMake - - # ... - -Interface functions implementation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The first step is to define the C interface functions declared in the ``rmw`` headers. -Start with empty functions that simply return ``RMW_RET_OK``, and then implement them one by one in the order in which they are likely to be called at runtime. -For example: ``rmw_init()``, ``rmw_create_node()``, ``rmw_create_publisher()``, ``rmw_create_subscription()``, and so on. -This will allow building and running/testing the implementation incrementally. - -Most ``rmw`` functions have to perform input validation, as defined by the function's documentation. -There are various utility macros to simplify this, such as ``RMW_CHECK_ARGUMENT_FOR_NULL()`` and ``RMW_CHECK_TYPE_IDENTIFIERS_MATCH()``. - -``rmw`` structs usually include a type-erased pointer (or sometimes an opaque pointer) for ``rmw`` implementation-specific data. -For instance, ``rmw_publisher_t`` has a ``void * data``. -The implementation can place whatever it wants there, e.g., a pointer to an internal object that wraps the underlying middleware's publisher object and any relevant information, like type support. -This data/object can be fetched and used later when ``rmw_publish()`` is called with the corresponding ``rmw_publisher_t``. -To make sure that a different ``rmw`` implementation doesn't try to interpret this data, ``rmw_publisher_t`` includes the name of the implementation in its ``implementation_identifier`` field. - -Type support -^^^^^^^^^^^^ - -Type support structs can be confusing. -Here is an example for message type support for publishers/subscriptions. - -A publisher is created through ``rmw_create_publisher()``, which takes in a handle for the type support information: ``const rosidl_message_type_support_t *``. -This is the base language-dependent type support: ``rosidl_typesupport_c`` / ``rosidl_typesupport_cpp``. -From this, we can get the concrete type support handle, depending on the available type supports, e.g., ``rosidl_typesupport_fastrtps_c`` / ``rosidl_typesupport_fastrtps_cpp`` and ``rosidl_typesupport_introspection_c`` / ``rosidl_typesupport_introspection_cpp``. -The confusing part is that these are also of type ``const rosidl_message_type_support_t *``! -However, the concrete type support handles are the ones that contain actual useful information. -See `this example function `__, which extracts the concrete C or C++ dynamic message type support handle (``rosidl_typesupport_introspection_{c,cpp}``) given a base type support handle (``rosidl_typesupport_{c,cpp}``). -Publishers created by ``rclcpp`` will use C++ type support, while publishers created by ``rclpy`` will use C type support, since Python messages get converted into C messages. -The ``/rosout`` publisher is managed by ``rcl``, which is written in C, so it uses C type support. - -Then, using the concrete type support handle's type-erased pointer, ``const void * data``, we get type support-specific information. -For example, for C++ dynamic type support, this will be a ``const rosidl_typesupport_introspection_cpp::MessageMembers *``, which contains information about each field of the message. -See `this example function `__, which extracts language-dependent type support information from the concrete type support handle. -The information is used to read the type-erased message pointer and convert the message to a YAML object and then convert that to a string for the underlying middleware to publish. - -Service type support is similar, but ``rosidl_service_type_support_t`` points to separate type support information for the request and response message types. - -Tests ------ - -The ``rmw`` package contains some tests, but they are mostly for utilities (e.g., getting zero-initialized structs) and non-implementation-specific functions such as topic/node name/namespace validation. - -As for testing the new ``rmw`` implementation, the ``test_rmw_implementation`` package `contains tests for the interface `_. -Test executables are defined first and then a CMake function creates test targets for a given ``rmw`` implementation by setting the ``RMW_IMPLEMENTATION`` environment variable. -``rmw_implementation_cmake``'s ``call_for_each_rmw_implementation()`` is called and is provided with this CMake function, which is called with each available implementation. -See the `CMakeLists.txt file `__. -Many other packages, including the ``test_rclcpp`` test-only package, also `use this mechanism `__ to run tests against all available ``rmw`` implementations, otherwise tests are simply run with the default implementation. -Packages can also use ``get_available_rmw_implementations()`` to get the actual list of available implementations. - -Some tests have implementation-specific code, which is done for various reasons, such as unsupported interface subsets. -These tests can use ``rmw``'s ``rmw_get_implementation_identifier()`` `function `__ for this. - -Middleware- and ``rmw`` implementation-specific configuration -------------------------------------------------------------- - -The ``rmw`` interface allows providing arbitrary implementation-specific configuration payloads for publishers and subscriptions through the type-erased ``rmw_specific_publisher_payload`` / ``rmw_specific_subscription_payload`` fields in ``rmw_publisher_options_t`` / ``rmw_subscription_options_t``. -This is set by users through ``RMWImplementationSpecificPublisherPayload`` / ``RMWImplementationSpecificSubscriptionPayload`` in ``rclcpp``, for example. -This is an advanced, non-portable feature that is not currently used by any (tier 1) implementations. - -For a bit more flexibility, some implementations use environment variables: ``RMW_FASTRTPS_*``, ``RMW_CONNEXT_*``, etc. -The underlying middleware may also be configurable through environment variables: ``FASTDDS_*``, ``ZENOH_*``, ``CYCLONEDDS_*``, ``EMAIL_*``, etc. -For example, the ``CYCLONEDDS_URI``, ``FASTDDS_DEFAULT_PROFILES_FILE``, and ``ZENOH_SESSION_CONFIG_URI`` environment variables can be used to provide a path to a full configuration file if the relevant middleware is used. - -Footnotes ---------- - -.. [#fn_dds_rpc] - There now is a DDS RPC specification, but `it was not finalized and wasn't implemented by DDS vendors back when ROS 2 was initially designed `_. - Since the ``rmw`` interface is also officially DDS-agnostic, services are up to the ``rmw`` implementation, which explains why :ref:`cross-DDS vendor communications are not guaranteed `, even if pub/sub generally works. - -.. [#fn_gid_remote_matching] - In practice, this is not always the case, so this requirement is somewhat relaxed. - See `ros2/rmw_cyclonedds#377 `_. - -.. [#fn_ts_fastrtps] - For example, the C++ message Fast CDR serialization/deserialization code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_fastrtps_cpp/std_msgs/msg/detail/dds_fastrtps/header__type_support.cpp`` under the ``build/`` directory. - -.. [#fn_ts_dynamic] +.. redirect-from:: + + Tutorials/Advanced/Creating-An-RMW-Implementation + +Creating an ``rmw`` implementation +================================== + +**Goal:** Learn how to create a new ``rmw`` implementation, from the features required from the underlying middleware to the ``rmw`` implementation details. + +**Tutorial level:** Advanced + +**Time:** 30+ minutes + +.. contents:: Table of Contents + :local: + +Introduction +------------ + +ROS 2's architecture has two main :doc:`abstraction layers <../About-Internal-Interfaces/About-Internal-Interfaces>`. +From top to bottom: + +#. The client library interface, ``rcl``, which supports the user-facing :doc:`client libraries <../../About-Client-Libraries>`, such as ``rclcpp`` and ``rclpy`` +#. The middleware interface, ``rmw``, which abstracts away the :doc:`underlying middleware implementation <../About-Different-Middleware-Vendors>`, such as a specific DDS implementation, Zenoh, etc. + +The ``rmw`` `API includes function-level documentation `_, but there is no higher-level documentation on the features of the interface and what it expects from the underlying middleware. + +This guide is for developers who want to implement the ``rmw`` interface for a specific middleware. +It will first go over the ``rmw`` interface and how it works. +Then it will cover the main concepts or features that a middleware implementation must support. +Finally, it will go over some implementation details, including how to create an implementation skeleton and some tips to implement the interface functions. + +This guide is intended to be an entry point to kickstart the development of a new ``rmw`` implementation. +It will link to other pages and source code for more details where appropriate. + +.. note:: + + ROS 2 design articles on `design.ros2.org `_ are historical documents and may not reflect the current state of ROS 2. + However, in some cases, they provide useful context and information, so they may still be referenced by this guide or by pages that this guide links to. + +The ``rmw`` interface +--------------------- + +The ``rmw`` interface is declared by the ``rmw`` package through `C header files `_. +Implementations of the C functions declared in these headers are provided by ``rmw`` implementations, which are separate packages. +For example, the ``rmw_fastrtps_cpp`` package implements the interface for eProsima Fast DDS. + +Example implementations +^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``rmw`` :doc:`implementations <../About-Middleware-Implementations>` can be used as references. +Note that there are different `support tiers, which are defined by REP 2000 `_. + +#. DDS: + + #. ``rmw_fastrtps_cpp``, ``rmw_fastrtps_dynamic_cpp``: `ros2/rmw_fastrtps `_ + #. ``rmw_cyclonedds_cpp``: `ros2/rmw_cyclonedds `_ + #. ``rmw_connextdds``: `ros2/rmw_connextdds `_ + #. ``rmw_gurumdds_cpp``: `ros2/rmw_gurumdds `_ + + * See :ref:`this overview ` + +#. ``rmw_zenoh_cpp``: `ros2/rmw_zenoh `_ + + * See :ref:`this overview ` and the `design document `_ + +#. ``rmw_email_cpp``, an email-based implementation: `christophebedard/rmw_email `_ + + * See the `design document for the underlying email middleware `_ and the `blog post for some context `_ + +.. _rmw-impl-guide_selection-mechanism: + +Build-time and runtime ``rmw`` implementation selection mechanism +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The dependency on the actual ``rmw`` implementation is done through the ``rmw_implementation`` `package `_. +Users of ``rmw``, such as ``rcl``, depend on the ``rmw`` package for the interface (headers) and some utility functions. +They also depend on the ``rmw_implementation`` package to get the actual implementation. + +By default, ROS 2 allows you to choose which ``rmw`` implementation to use at runtime. +This is convenient for comparing two implementations on the same machine, and it lets ROS 2 distribute a single set of binaries that is compatible with multiple ``rmw`` implementations. +The :doc:`implementation is selected at runtime <../../../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` through the ``RMW_IMPLEMENTATION`` environment variable, or, if that variable is unset, a default ``rmw`` implementation is loaded. + +This is accomplished by the ``rmw_implementation`` package, which acts as a proxy for an actual ``rmw`` implementation. +It works by creating placeholder ``rmw`` functions. +When they are called, it will ``dlopen()`` the appropriate library for the selected ``rmw`` implementation and then look up the corresponding symbols in the loaded shared library using the ``dlsym()`` function before calling them. + +The ``rmw_implementation`` package can be configured at build-time to change the default option or disable runtime selection. +The default implementation can be selected at build-time with the ``RMW_IMPLEMENTATION`` CMake variable (e.g., ``-DRMW_IMPLEMENTATION=rmw_other``) or the ``RMW_IMPLEMENTATION`` environment variable. +If only one implementation is available at build-time, or if runtime selection is disabled (``-DRMW_IMPLEMENTATION_DISABLE_RUNTIME_SELECTION=ON``), the ``rmw_implementation`` target will be a simple ``INTERFACE`` library for the single implementation. + +Because of the proxy mechanism and the CMake logic described above, an ``rmw`` implementation that does not implement all of the functions in the interface will only fail at runtime, when the symbol lookup fails, as opposed to failing at build-time (specifically at link-time) if runtime selection is disabled. + +Features +-------- + +This section goes over the main features of the ``rmw`` interface, which the underlying middleware must support or deal with. +Depending on the middleware -- and how similar it is to the features expected by the interface -- the ``rmw`` implementation may be more or less trivial, i.e., it might have to do more "glue" work. +For some non-critical features or configuration options, the implementation can indicate that they are not supported through ``rmw_feature_supported()`` or by returning ``RMW_RET_UNSUPPORTED``. +In any case, any special behavior of the ``rmw`` implementation should ideally be documented. + +Topics, pub/sub, services +^^^^^^^^^^^^^^^^^^^^^^^^^ + +:doc:`Topics <../../interfaces/About-Topics>` are a common concept in publish/subscribe middleware. +However, ROS 2 has its own topic name conventions, which is validated using ``rmw_validate_full_topic_name()``. +The ``rmw`` implementation simply has to use the given (resolved) topic name. +This might involve adapting or mangling the ROS topic name to fit the underlying middleware's topic name conventions or constraints, or encode useful information. +For example, a pub/sub topic called ``/chatter`` is usually mangled into ``rt/chatter`` for DDS-based implementations, making ROS topics on DDS easily distinguishable from normal DDS topics. +See the `"Mapping of ROS 2 Topic and Service Names to DDS Concepts" section in this design document `_. +For Zenoh, the domain ID, resolved topic name, topic type name, and topic type hash are `encoded in the underlying Zenoh key `_ to avoid communications between different ROS topic names & types. + +As for :doc:`services <../../interfaces/About-Services>`, they are not always natively supported by the underlying middleware. +For DDS-based implementations, they are simply built on top of pub/sub: 1 request topic and 1 response topic. +[#fn_dds_rpc]_ +On the other hand, Zenoh natively supports services through `queryables `_, so they are used to implement services in ``rmw_zenoh_cpp``. + +Note that, while services are a part of the ``rmw`` interface, :doc:`actions <../../interfaces/About-Actions>` are not. +They are an ``rcl`` concept implemented in the ``rcl_action`` package on top of services and pub/sub. + +Nodes +^^^^^ + +:doc:`Nodes <../../About-Nodes>` are mostly a ROS concept. +Neither DDS nor Zenoh has a corresponding concept, so they are mostly a logical concept in the ``rmw`` implementation. +Topic names get resolved with the node namespace/name, if needed, by ``rcl`` before they are passed to ``rmw`` when creating a pub/sub object. +Implementations just have to make sure to include nodes in :ref:`introspection data `. + +.. _rmw-impl-guide_waitsets: + +Wait sets and waiting +^^^^^^^^^^^^^^^^^^^^^ + +:doc:`Executors <../About-Executors/About-Executors>` are responsible for triggering user-provided callbacks when a new message is received, for example. +Executors are implemented at the client library level (``rclcpp``, ``rclpy``), but they rely on the underlying middleware to wait for new messages using a polling mechanism. +This is done using wait sets, which allow waiting on different entities at the same time in a standard way, e.g., subscriptions, service clients, and service servers. +The ``rmw_wait()`` `function `_ is called with lists of entities to wait on, as well as an implementation-specific wait set object. +It adds all entities to the wait set and asks it to wait until at least one entity has new data available or until it times out. +Then the executor checks the lists of entities to see which ones have new data available and triggers the corresponding callbacks. + +The key mechanism here is the ability to check if a given entity is ready, e.g., check if a subscription has a new message. +Then waiting simply involves continuously checking entities one at a time until one is ready or until the wait times out. + +Take a look at how ``rmw_email_cpp`` `implements wait sets and waiting `_ and dig down to the middleware, ``email``, since it's fairly simple. + +Taking data +^^^^^^^^^^^ + +Once an :ref:`executor is done waiting ` and there is a new message, request, or response, it takes it from the middleware and triggers the corresponding callback. +For instance, ``rmw_take()`` is called with a subscription and a type-erased pointer to an instance of the corresponding message type to write to. + +``rmw_email_cpp`` takes the new message (YAML string) from the underlying email middleware subscription object, and converts it into a ROS message by writing into the provided message. + +Metadata: GIDs, timestamps, sequence numbers +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Aside from actual user-specified data, message publications, service requests, service responses, and so on also have metadata associated with them: + +* GID: globally-unique ID that identifies an entity (e.g., pub, sub, client, server) + + * The GID for an entity should be unique within a ROS domain and should be the same when reported both locally and remotely. + For example, the publisher GID for a message being published should be the same publisher GID reported on the other side, when that message is received by a subscription. + [#fn_gid_remote_matching]_ + +* Source & received timestamps: publication & subscription reception timestamps, respectively + +* Publication & reception sequence numbers + +This means that service request metadata includes the GID of the client that made the request and the request sequence number. +Service response metadata also includes the client GID & sequence number of the request it is responding to. + +This metadata is available as structs through ``rmw_take_with_info()`` for subscription messages and ``rmw_take_{request,response}()`` for service requests/responses, which are wrapped & provided to user callbacks by the client libraries. + +Part of this metadata might be natively supported and provided by the underlying middleware, while another part might have to be included and transmitted alongside the application data by the ``rmw`` implementation. +For instance, DDS natively supports all of it for pub/sub through DDS sample info, but the client request metadata needs to be wrapped alongside the service response data by the ``rmw`` implementation. +``email`` natively supports all of this metadata, which is included in standard email headers (i.e., not in the email body). + +.. _rmw-impl-guide_typesupport: + +Type support +^^^^^^^^^^^^ + +To bridge the gap between ROS 2 :doc:`interfaces <../../interfaces/About-Interfaces>` (specifically :doc:`custom interfaces `) and the underlying middleware, some glue code is needed. +This is referred to as :ref:`type support `. +When publishing a message of type {interface(std_msgs/msg/String)}, ``rmw_publish()`` only gets a ``void *`` to the message, which could point to a C++ instance, or a C instance, and so on. +The pointer will be interpreted based on the type support information provided when the publisher was created. + +First, code is generated for each combination of interface type and user-facing language, independent of the underlying middleware. +For example, for the {interface(std_msgs/msg/String)} message type, data structures are generated: + +#. C++: ``std_msgs/msg/string.hpp`` header with ``std_msgs::msg::String`` class generated by the ``rosidl_generator_cpp`` package +#. C: ``std_msgs/msg/string.h`` header with ``std_msgs__msg__String`` struct generated by the ``rosidl_generator_c`` package +#. Python: ``std_msgs`` module with ``std_msgs.msg.String`` class (which is just a wrapper around the C struct) generated by the ``rosidl_generator_py`` package +#. (and so on, e.g., for Rust) + +Second, for the underlying middleware to be able to send and receive messages, it needs to know how to interpret the user-facing data structure. +This is one of the most critical parts of an ``rmw`` implementation. +There are two options: :ref:`static type support ` and :ref:`dynamic type support `. +Static type support involves generating middleware-specific code for each interface. +For example, ``rosidl_typesupport_fastrtps_cpp`` generates code to serialize/deserialize C++ classes of each interface type into CDR using `Fast CDR `_ for ``rmw_fastrtps_cpp`` to pass on to Fast DDS. +[#fn_ts_fastrtps]_ +``rmw_connextdds`` and even ``rmw_zenoh_cpp`` use CDR for serialization, so they use this type support package as well. +On the other hand, dynamic type support involves generating a bit of middleware-independent code that provides generic information about each interface type. +[#fn_ts_dynamic]_ + +This information can be used at runtime by any ``rmw`` implementation to interpret a type-erased pointer to data: names & types of fields, functions to read from/write to fields depending on their type, functions to get the size of an array field, etc. +For C++, this is ``rosidl_typesupport_introspection_cpp``, which is used by ``rmw_fastrtps_dynamic_cpp`` (hence the "dynamic" part), for example. + +Dynamic type support is generally slower than static type support at runtime because it has to iterate over each message field, figure out what type it is, and then process it, e.g., serialize it. +Static type support knows exactly how to process the message thanks to the code it generated for each interface type. +This is why most ``rmw`` implementations use static type support. +However, dynamic type support does not require generating middleware-specific code. +Choosing between static and dynamic type support is an orthogonal decision to the ``rmw`` implementation itself. + +``rmw_email_cpp`` uses dynamic type support to convert messages to and from YAML string to be sent over email. +It gets the type support introspection information, and passes it and the message to an external/experimental package, `dynmsg `_, which converts the message to/from YAML. +The YAML object is then sent as a YAML-formatted string via email using the underlying middleware. +When a new message is received by the middleware, the YAML string is converted into a message. + +Domain ID +^^^^^^^^^ + +:doc:`Domain IDs <../../nodes/About-Domain-ID>` are a way to have separate logical networks on the same physical network. +It is a native feature of DDS, but not Zenoh. +DDS achieves this by using the domain ID as a network port offset, while Zenoh implements it by making the domain ID the first component of the internal Zenoh key corresponding to each ROS 2 topic. + +Quality of service (QoS) +^^^^^^^^^^^^^^^^^^^^^^^^ + +:doc:`Quality of service settings <../../interfaces/topics/About-Quality-of-Service-Settings>` in ROS 2 are largely derived from DDS. +Basic QoS policies like history, depth, and durability are the same as ROS 1's, but more advanced policies simply come from DDS. +Implementations may simply ignore some settings. +For instance, ``rmw_zenoh_cpp`` doesn't implement the deadline and lifespan QoS policies. + +One important aspect of QoS is that two profiles, e.g., a publisher's profile and a subscription's profile, may be incompatible, meaning they cannot communicate. +It is up to the implementation to decide if two QoS profiles are compatible: ``rmw_qos_profile_check_compatible()``. +DDS-based implementations rely on ``rmw_dds_common::qos_profile_check_compatible()``, since :ref:`QoS profile compatibility ` is standard in DDS. +In Zenoh, `QoS settings are essentially never incompatible `_. + +To support a universal "default" behavior, QoS policies include a ``*_SYSTEM_DEFAULT`` setting (e.g., ``rmw_qos_reliability_policy_t``'s ``RMW_QOS_POLICY_RELIABILITY_SYSTEM_DEFAULT``), which leaves the value up to the middleware implementation. +Then the ``rmw_*_get_actual_qos()`` functions retrieve the actual QoS profile used by the implementation. + +.. _rmw-impl-guide_introspection: + +ROS graph introspection +^^^^^^^^^^^^^^^^^^^^^^^ + +Nodes are able to get a list of other nodes, topics, etc. +This also allows publishers to know if any subscriptions exist for their topic, for example. +This same mechanism is used to :doc:`list nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, and so on with the ROS 2 CLI: ``ros2 node list``, ``ros2 topic list``, etc. + +This is supported by a number of ``rmw`` functions: ``rmw_get_node_names()``, ``rmw_get_topic_names_and_types()``, ``rmw_publisher_count_matched_subscriptions()``, and many more. +While the implementation is not specified by the interface, ``rmw`` implementations usually maintain a cache of the ROS graph. +When they create a new entity (e.g., node, publisher, subscription, service, client), they note it in their internal graph cache and notify other participants through a middleware-specific mechanism so that they can add it to their cache. +The graph cache belongs to the ``rmw`` context, so it is initialized when ``rmw_init()`` is called. +This context indirectly belongs to the ``rclcpp`` context (e.g., initialized by ``rclcpp::init()``), so there is usually only one graph cache per process. + +Since DDS-based ``rmw`` implementations are very similar in this regard, they share a common graph cache implementation in the ``rmw_dds_common`` `package `__. +It uses an internal topic (usually ``ros_discovery_info``) to share information about new entities. +``rmw_zenoh_cpp`` `creates a Zenoh liveliness token `_ with the entity type & info and shares it with other participants. + +Events +^^^^^^ + +Users can provide callbacks for publishers & subscriptions to be triggered by the middleware (but executed by the client library) on certain events (``rmw_event_type_t``), such as :ref:`quality of service-related events ` and :ref:`pub-sub match events `. +Some of these events could be triggered on relevant changes to the graph cache. + +Security +^^^^^^^^ + +:doc:`Security <../../../Developer-Tools/Introspection-and-analysis/About-Security>` is not well-specified by the ``rmw`` interface; most of it is specified by :doc:`SROS2 <../../../Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security>`. +The interface only defines a few security options as part of the context initialization options, ``rmw_init_options_t``: + +#. ``rmw_security_options_t``, which includes a security policy (enforce/permissive) and a path to a directory containing security artifacts, i.e., a keystore. + These are set by ``rcl`` based on environment variables: ``ROS_SECURITY_ENABLE`` & ``ROS_SECURITY_STRATEGY`` and ``ROS_SECURITY_KEYSTORE``. +#. The name of a security enclave from the keystore to use for the given process. + This is set, for example, through the ``--enclave`` option when running a node with ``ros2 run``. + +However, in practice, the structure of the :doc:`keystore <../../../Developer-Tools/Build/The-Keystore>` directory and its security enclaves is based on the DDS Security specification. +Therefore, :doc:`security artifacts generated <../../../Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security>` with the ``sros2`` package can only be directly used by DDS-based ``rmw`` implementations. +For ``rmw_zenoh_cpp``, `Zenoh-specific security configuration files can be generated `_ from ``sros2``-generated artifacts using the ``zenoh_security_tools`` package and provided through the ``ZENOH_SESSION_CONFIG_URI`` environment variable, bypassing the ``ROS_SECURITY_*`` environment variables. + +Implementation +-------------- + +Implementation skeleton +^^^^^^^^^^^^^^^^^^^^^^^ + +This section covers concrete steps to create the base files and directories for the new implementation package, including special handling in ``package.xml`` and ``CMakeLists.txt``. + +Start with the :doc:`package creation tutorial ` to create an empty package. +Then make the following changes: + +#. ``package.xml`` + + #. Define a package/implementation name + + The package name is also the name of the ``rmw`` implementation. + It will be used to :ref:`select the implementation ` through the ``RMW_IMPLEMENTATION`` environment variable or CMake option, for example. + The name usually starts with ``rmw_`` and is followed by the name of the underlying middleware. + Most :doc:`implementations in the ROS 2 ecosystem <../About-Different-Middleware-Vendors>` then append a suffix such as ``_cpp`` to indicate that the implementation is written in C++. + However, that is not required. + Examples: ``rmw_fastrtps_cpp``, ``rmw_cyclonedds_cpp``, ``rmw_connextdds``, ``rmw_zenoh_cpp``, and ``rmw_email_cpp``. + + .. code-block:: xml + + + rmw_IMPLEMENTATION_NAME_cpp + + #. Declare a dependency on ``rmw`` + + Since the package will implement the interface declared in the ``rmw`` package and will depend on some utility functions. + + .. code-block:: xml + + rmw + + #. Declare a dependency on the required type support packages + + See the :ref:`type support section ` for details. + + .. code-block:: xml + + + rosidl_typesupport_fastrtps_c + rosidl_typesupport_fastrtps_cpp + rosidl_typesupport_introspection_c + rosidl_typesupport_introspection_cpp + + #. Declare membership of the ``rmw_implementation_packages`` group + + This allows the ``rmw_implementation`` package to `depend on the implementation `_ so that it gets built alongside other implementations, since no package otherwise explicitly depends on any ``rmw`` implementations. + This way it can be found and used if selected. + + .. code-block:: xml + + rmw_implementation_packages + +#. ``CMakeLists.txt`` + + #. Create the library target + + The library has to be a shared library. + It should depend on ``rmw`` for headers and utility functions as well as the required type support packages. + It will also depend on the underlying middleware. + + .. code-block:: cmake + + add_library(${PROJECT_NAME} SHARED + src/file.cpp + # ... + ) + target_link_libraries(${PROJECT_NAME} PUBLIC + rmw::rmw + ) + target_link_libraries(${PROJECT_NAME} PRIVATE + rosidl_typesupport_fastrtps_c::rosidl_typesupport_fastrtps_c + rosidl_typesupport_fastrtps_cpp::rosidl_typesupport_fastrtps_cpp + rosidl_typesupport_introspection_c::rosidl_typesupport_introspection_c + rosidl_typesupport_introspection_cpp::rosidl_typesupport_introspection_cpp + # TODO add any implementation-specific dependencies, e.g., underlying middleware + ) + + #. Configure the implementation library target + + In practice, this simply makes symbols hidden by default to hide internal symbols, i.e., non-``rmw`` interface symbols. + If the implementation is written in C (not common), specify ``LANGUAGE "C"``. + + .. code-block:: cmake + + configure_rmw_library(${PROJECT_NAME}) + + #. Register the ``rmw`` implementation + + This registers the implementation in the :ref:`ament index ` so that it can be found at build-time (``get_available_rmw_implementations()``, ``get_rmw_typesupport()``) or at runtime (``ament_index_cpp::get_resources("rmw_typesupport")``). + It also registers the languages that the implementation supports and the list of type support packages. + For example, if the implementation only uses type support introspection (i.e., dynamic and not static) for C and C++ messages: + + .. code-block:: cmake + + register_rmw_implementation( + "c:rosidl_typesupport_introspection_c" + "cpp:rosidl_typesupport_introspection_cpp" + ) + + .. For example, the Python client library, ``rclpy``, uses C typesupport, and checks if C typesupport is available using ``get_rmw_typesupport()``, so the ``rmw`` implementation must support it. + + #. Install and export target + + .. code-block:: cmake + + install( + TARGETS ${PROJECT_NAME} + EXPORT ${PROJECT_NAME} + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin + ) + + ament_export_targets(${PROJECT_NAME}) + # ament_export_libraries(${PROJECT_NAME}) # Old-style CMake + + # ... + +Interface functions implementation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The first step is to define the C interface functions declared in the ``rmw`` headers. +Start with empty functions that simply return ``RMW_RET_OK``, and then implement them one by one in the order in which they are likely to be called at runtime. +For example: ``rmw_init()``, ``rmw_create_node()``, ``rmw_create_publisher()``, ``rmw_create_subscription()``, and so on. +This will allow building and running/testing the implementation incrementally. + +Most ``rmw`` functions have to perform input validation, as defined by the function's documentation. +There are various utility macros to simplify this, such as ``RMW_CHECK_ARGUMENT_FOR_NULL()`` and ``RMW_CHECK_TYPE_IDENTIFIERS_MATCH()``. + +``rmw`` structs usually include a type-erased pointer (or sometimes an opaque pointer) for ``rmw`` implementation-specific data. +For instance, ``rmw_publisher_t`` has a ``void * data``. +The implementation can place whatever it wants there, e.g., a pointer to an internal object that wraps the underlying middleware's publisher object and any relevant information, like type support. +This data/object can be fetched and used later when ``rmw_publish()`` is called with the corresponding ``rmw_publisher_t``. +To make sure that a different ``rmw`` implementation doesn't try to interpret this data, ``rmw_publisher_t`` includes the name of the implementation in its ``implementation_identifier`` field. + +Type support +^^^^^^^^^^^^ + +Type support structs can be confusing. +Here is an example for message type support for publishers/subscriptions. + +A publisher is created through ``rmw_create_publisher()``, which takes in a handle for the type support information: ``const rosidl_message_type_support_t *``. +This is the base language-dependent type support: ``rosidl_typesupport_c`` / ``rosidl_typesupport_cpp``. +From this, we can get the concrete type support handle, depending on the available type supports, e.g., ``rosidl_typesupport_fastrtps_c`` / ``rosidl_typesupport_fastrtps_cpp`` and ``rosidl_typesupport_introspection_c`` / ``rosidl_typesupport_introspection_cpp``. +The confusing part is that these are also of type ``const rosidl_message_type_support_t *``! +However, the concrete type support handles are the ones that contain actual useful information. +See `this example function `__, which extracts the concrete C or C++ dynamic message type support handle (``rosidl_typesupport_introspection_{c,cpp}``) given a base type support handle (``rosidl_typesupport_{c,cpp}``). +Publishers created by ``rclcpp`` will use C++ type support, while publishers created by ``rclpy`` will use C type support, since Python messages get converted into C messages. +The ``/rosout`` publisher is managed by ``rcl``, which is written in C, so it uses C type support. + +Then, using the concrete type support handle's type-erased pointer, ``const void * data``, we get type support-specific information. +For example, for C++ dynamic type support, this will be a ``const rosidl_typesupport_introspection_cpp::MessageMembers *``, which contains information about each field of the message. +See `this example function `__, which extracts language-dependent type support information from the concrete type support handle. +The information is used to read the type-erased message pointer and convert the message to a YAML object and then convert that to a string for the underlying middleware to publish. + +Service type support is similar, but ``rosidl_service_type_support_t`` points to separate type support information for the request and response message types. + +Tests +----- + +The ``rmw`` package contains some tests, but they are mostly for utilities (e.g., getting zero-initialized structs) and non-implementation-specific functions such as topic/node name/namespace validation. + +As for testing the new ``rmw`` implementation, the ``test_rmw_implementation`` package `contains tests for the interface `_. +Test executables are defined first and then a CMake function creates test targets for a given ``rmw`` implementation by setting the ``RMW_IMPLEMENTATION`` environment variable. +``rmw_implementation_cmake``'s ``call_for_each_rmw_implementation()`` is called and is provided with this CMake function, which is called with each available implementation. +See the `CMakeLists.txt file `__. +Many other packages, including the ``test_rclcpp`` test-only package, also `use this mechanism `__ to run tests against all available ``rmw`` implementations, otherwise tests are simply run with the default implementation. +Packages can also use ``get_available_rmw_implementations()`` to get the actual list of available implementations. + +Some tests have implementation-specific code, which is done for various reasons, such as unsupported interface subsets. +These tests can use ``rmw``'s ``rmw_get_implementation_identifier()`` `function `__ for this. + +Middleware- and ``rmw`` implementation-specific configuration +------------------------------------------------------------- + +The ``rmw`` interface allows providing arbitrary implementation-specific configuration payloads for publishers and subscriptions through the type-erased ``rmw_specific_publisher_payload`` / ``rmw_specific_subscription_payload`` fields in ``rmw_publisher_options_t`` / ``rmw_subscription_options_t``. +This is set by users through ``RMWImplementationSpecificPublisherPayload`` / ``RMWImplementationSpecificSubscriptionPayload`` in ``rclcpp``, for example. +This is an advanced, non-portable feature that is not currently used by any (tier 1) implementations. + +For a bit more flexibility, some implementations use environment variables: ``RMW_FASTRTPS_*``, ``RMW_CONNEXT_*``, etc. +The underlying middleware may also be configurable through environment variables: ``FASTDDS_*``, ``ZENOH_*``, ``CYCLONEDDS_*``, ``EMAIL_*``, etc. +For example, the ``CYCLONEDDS_URI``, ``FASTDDS_DEFAULT_PROFILES_FILE``, and ``ZENOH_SESSION_CONFIG_URI`` environment variables can be used to provide a path to a full configuration file if the relevant middleware is used. + +Footnotes +--------- + +.. [#fn_dds_rpc] + There now is a DDS RPC specification, but `it was not finalized and wasn't implemented by DDS vendors back when ROS 2 was initially designed `_. + Since the ``rmw`` interface is also officially DDS-agnostic, services are up to the ``rmw`` implementation, which explains why :ref:`cross-DDS vendor communications are not guaranteed `, even if pub/sub generally works. + +.. [#fn_gid_remote_matching] + In practice, this is not always the case, so this requirement is somewhat relaxed. + See `ros2/rmw_cyclonedds#377 `_. + +.. [#fn_ts_fastrtps] + For example, the C++ message Fast CDR serialization/deserialization code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_fastrtps_cpp/std_msgs/msg/detail/dds_fastrtps/header__type_support.cpp`` under the ``build/`` directory. + +.. [#fn_ts_dynamic] For example, the C++ message introspection code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_introspection_cpp/std_msgs/msg/detail/header__type_support.cpp`` under the ``build/`` directory. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst index 44ee8411f7a..bcb815c6a8a 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst @@ -1,800 +1,800 @@ -.. redirect-from:: - - Tutorials/Custom-ROS2-Interfaces - Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces - -.. _CustomInterfaces: - -Creating custom msg and srv files -================================= - -**Goal:** Define custom interface files (``.msg`` and ``.srv``) and use them with Python and C++ nodes. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials you utilized message and service interfaces to learn about :doc:`topics <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, and simple publisher/subscriber (:doc:`C++ `/:doc:`Python `) and service/client (:doc:`C++ `/:doc:`Python `) nodes. -The interfaces you used were predefined in those cases. - -While it's good practice to use predefined interface definitions, you will probably need to define your own messages and services sometimes as well. -This tutorial will introduce you to the simplest method of creating custom interface definitions. - -Prerequisites -------------- - -You should have a :doc:`ROS 2 workspace `. - -This tutorial also uses the packages created in the publisher/subscriber (:doc:`C++ ` and :doc:`Python `) and service/client (:doc:`C++ ` and :doc:`Python `) tutorials to try out the new custom messages. - -Tasks ------ - -1 Create a new package -^^^^^^^^^^^^^^^^^^^^^^^ - -For this tutorial you will be creating custom ``.msg`` and ``.srv`` files in their own package, and then utilizing them in a separate package. -Both packages should be in the same workspace. - -Since we will use the pub/sub and service/client packages created in earlier tutorials, make sure you are in the same workspace as those packages (``ros2_ws/src``), and then run the following command to create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 tutorial_interfaces - -``tutorial_interfaces`` is the name of the new package. -Note that it is, and can only be, an ament_cmake package, but this doesn't restrict in which type of packages you can use your messages and services. -You can create your own custom interfaces in an ament_cmake package, and then use it in a C++ or Python node, which will be covered in the last section. - -The ``.msg`` and ``.srv`` files are required to be placed in directories called ``msg`` and ``srv`` respectively. -Create the directories in ``ros2_ws/src/tutorial_interfaces``: - -.. code-block:: console - - $ mkdir msg srv - -2 Create custom definitions -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -2.1 msg definition -~~~~~~~~~~~~~~~~~~ - -In the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Num.msg`` with one line of code declaring its data structure: - -.. code-block:: bash - - int64 num - -This is a custom message that transfers a single 64-bit integer called ``num``. - -Also in the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Sphere.msg`` with the following content: - -.. code-block:: bash - - geometry_msgs/Point center - float64 radius - -This custom message uses a message from another message package (``geometry_msgs/Point`` in this case). - -2.2 srv definition -~~~~~~~~~~~~~~~~~~ - -Back in the ``tutorial_interfaces/srv`` directory you just created, make a new file called ``AddThreeInts.srv`` with the following request and response structure: - -.. code-block:: bash - - int64 a - int64 b - int64 c - --- - int64 sum - -This is your custom service that requests three integers named ``a``, ``b``, and ``c``, and responds with an integer called ``sum``. - -3 ``CMakeLists.txt`` -^^^^^^^^^^^^^^^^^^^^ - -To convert the interfaces you defined into language-specific code (like C++ and Python) so that they can be used in those languages, add the following lines to ``CMakeLists.txt``: - -.. code-block:: cmake - - find_package(geometry_msgs REQUIRED) - find_package(rosidl_default_generators REQUIRED) - - rosidl_generate_interfaces(${PROJECT_NAME} - "msg/Num.msg" - "msg/Sphere.msg" - "srv/AddThreeInts.srv" - DEPENDENCIES geometry_msgs # Add packages that above messages depend on, in this case geometry_msgs for Sphere.msg - ) - -.. note:: - - The first argument (library name) in the ``rosidl_generate_interfaces`` must start with the name of the package, e.g., simply ``${PROJECT_NAME}`` or ``${PROJECT_NAME}_suffix``. - See https://github.com/ros2/rosidl/issues/441#issuecomment-591025515. - -4 ``package.xml`` -^^^^^^^^^^^^^^^^^ - -Because the interfaces rely on ``rosidl_default_generators`` for generating language-specific code, you need to declare a build tool dependency on it. -``rosidl_default_runtime`` is a runtime or execution-stage dependency, needed to be able to use the interfaces later. -The ``rosidl_interface_packages`` is the name of the dependency group that your package, ``tutorial_interfaces``, should be associated with, declared using the ```` tag. - -Add the following lines within the ```` element of ``package.xml``: - -.. code-block:: xml - - geometry_msgs - rosidl_default_generators - rosidl_default_runtime - rosidl_interface_packages - -5 Build the ``tutorial_interfaces`` package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now that all the parts of your custom interfaces package are in place, you can build the package. -In the root of your workspace (``~/ros2_ws``), run the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select tutorial_interfaces - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select tutorial_interfaces - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select tutorial_interfaces - -Now the interfaces will be discoverable by other ROS 2 packages. - -6 Confirm msg and srv creation -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -In a new terminal, run the following command from within your workspace (``ros2_ws``) to source it: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now you can confirm that your interface creation worked by using the ``ros2 interface show`` command. -The output you see in your terminal should look similar to the following: - -.. code-block:: console - - $ ros2 interface show tutorial_interfaces/msg/Num - int64 num - -.. code-block:: console - - $ ros2 interface show tutorial_interfaces/msg/Sphere - geometry_msgs/Point center - float64 x - float64 y - float64 z - float64 radius - -.. code-block:: console - - $ ros2 interface show tutorial_interfaces/srv/AddThreeInts - int64 a - int64 b - int64 c - --- - int64 sum - -7 Test the new interfaces -^^^^^^^^^^^^^^^^^^^^^^^^^ - -For this step you can use the packages you created in previous tutorials. -A few simple modifications to the nodes, ``CMakeLists.txt`` and ``package.xml`` files will allow you to use your new interfaces. - -7.1 Testing ``Num.msg`` with pub/sub -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -With a few modifications to the publisher/subscriber package created in a previous tutorial (:doc:`C++ ` or :doc:`Python `), you can see ``Num.msg`` in action. -Since you'll be changing the standard string msg to a numerical one, the output will be slightly different. - -**Publisher** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/msg/num.hpp" // CHANGE - - using namespace std::chrono_literals; - - class MinimalPublisher : public rclcpp::Node - { - public: - MinimalPublisher() - : Node("minimal_publisher"), count_(0) - { - publisher_ = this->create_publisher("topic", 10); // CHANGE - - auto timer_callback = [this](){ - auto message = tutorial_interfaces::msg::Num(); // CHANGE - message.num = this->count_++; // CHANGE - RCLCPP_INFO_STREAM(this->get_logger(), "Publishing: '" << message.num << "'"); // CHANGE - publisher_->publish(message); - }; - timer_ = this->create_wall_timer(500ms, timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; // CHANGE - size_t count_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tutorial_interfaces.msg import Num # CHANGE - - - class MinimalPublisher(Node): - - def __init__(self): - super().__init__('minimal_publisher') - self.publisher_ = self.create_publisher(Num, 'topic', 10) # CHANGE - timer_period = 0.5 # seconds - self.timer = self.create_timer(timer_period, self.timer_callback) - self.i = 0 - - def timer_callback(self): - msg = Num() # CHANGE - msg.num = self.i # CHANGE - self.publisher_.publish(msg) - self.get_logger().info('Publishing: "%d"' % msg.num) # CHANGE - self.i += 1 - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_publisher = MinimalPublisher() - - rclpy.spin(minimal_publisher) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -**Subscriber** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/msg/num.hpp" // CHANGE - - using std::placeholders::_1; - - class MinimalSubscriber : public rclcpp::Node - { - public: - MinimalSubscriber() - : Node("minimal_subscriber") - { - auto topic_callback = [this](const tutorial_interfaces::msg::Num & msg){ // CHANGE - RCLCPP_INFO_STREAM(this->get_logger(), "I heard: '" << msg.num << "'"); // CHANGE - }; - subscription_ = this->create_subscription( // CHANGE - "topic", 10, topic_callback); - } - - private: - rclcpp::Subscription::SharedPtr subscription_; // CHANGE - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tutorial_interfaces.msg import Num # CHANGE - - - class MinimalSubscriber(Node): - - def __init__(self): - super().__init__('minimal_subscriber') - self.subscription = self.create_subscription( - Num, # CHANGE - 'topic', - self.listener_callback, - 10) - self.subscription # prevent unused variable warning - - def listener_callback(self, msg): - self.get_logger().info('I heard: "%d"' % msg.num) # CHANGE - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_subscriber = MinimalSubscriber() - - rclpy.spin(minimal_subscriber) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -**CMakeLists.txt** - -Add the following lines (C++ only): - -.. code-block:: cmake - - #... - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(tutorial_interfaces REQUIRED) # CHANGE - - add_executable(talker src/publisher_lambda_function.cpp) - target_link_libraries(talker PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - add_executable(listener src/subscriber_lambda_function.cpp) - target_link_libraries(listener PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - install(TARGETS - talker - listener - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - - -**package.xml** - -Add the following line: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - tutorial_interfaces - - .. group-tab:: Python - - .. code-block:: python - - tutorial_interfaces - - -After making the above edits and saving all the changes, build the package: - -.. tabs:: - - .. group-tab:: C++ - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select cpp_pubsub - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_pubsub - - .. group-tab:: Python - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select py_pubsub - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select py_pubsub - -Then open two new terminals, source ``ros2_ws`` in each, and run: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: console - - $ ros2 run cpp_pubsub talker - - .. code-block:: console - - $ ros2 run cpp_pubsub listener - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 run py_pubsub talker - - .. code-block:: console - - $ ros2 run py_pubsub listener - -Since ``Num.msg`` relays only an integer, the talker should only be publishing integer values, as opposed to the string it published previously: - -.. code-block:: console - - [INFO] [minimal_publisher]: Publishing: '0' - [INFO] [minimal_publisher]: Publishing: '1' - [INFO] [minimal_publisher]: Publishing: '2' - - -7.2 Testing ``AddThreeInts.srv`` with service/client -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -With a few modifications to the service/client package created in a previous tutorial (:doc:`C++ ` or :doc:`Python `), you can see ``AddThreeInts.srv`` in action. -Since you'll be changing the original two integer request srv to a three integer request srv, the output will be slightly different. - -**Service** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE - - #include - - void add(const std::shared_ptr request, // CHANGE - std::shared_ptr response) // CHANGE - { - response->sum = request->a + request->b + request->c; // CHANGE - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Incoming request\na: %ld" " b: %ld" " c: %ld", // CHANGE - request->a, request->b, request->c); // CHANGE - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "sending back response: [%ld]", (long int)response->sum); - } - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_server"); // CHANGE - - rclcpp::Service::SharedPtr service = // CHANGE - node->create_service("add_three_ints", &add); // CHANGE - - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Ready to add three ints."); // CHANGE - - rclcpp::spin(node); - rclcpp::shutdown(); - } - - .. group-tab:: Python - - .. code-block:: python - - from tutorial_interfaces.srv import AddThreeInts # CHANGE - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalService(Node): - - def __init__(self): - super().__init__('minimal_service') - self.srv = self.create_service(AddThreeInts, 'add_three_ints', self.add_three_ints_callback) # CHANGE - - def add_three_ints_callback(self, request, response): - response.sum = request.a + request.b + request.c # CHANGE - self.get_logger().info('Incoming request\na: %d b: %d c: %d' % (request.a, request.b, request.c)) # CHANGE - - return response - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_service = MinimalService() - - rclpy.spin(minimal_service) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -**Client** - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - #include "rclcpp/rclcpp.hpp" - #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE - - #include - #include - #include - - using namespace std::chrono_literals; - - int main(int argc, char **argv) - { - rclcpp::init(argc, argv); - - std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_client"); // CHANGE - rclcpp::Client::SharedPtr client = // CHANGE - node->create_client("add_three_ints"); // CHANGE - - auto request = std::make_shared(); // CHANGE - request->a = 41; - request->b = 1; - request->c = 1; // CHANGE - - while (!client->wait_for_service(1s)) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Interrupted while waiting for the service. Exiting."); - return 0; - } - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "service not available, waiting again..."); - } - - auto result = client->async_send_request(request); - // Wait for the result. - if (rclcpp::spin_until_future_complete(node, result) == - rclcpp::FutureReturnCode::SUCCESS) - { - RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Sum: %ld", result.get()->sum); - } else { - RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Failed to call service add_three_ints"); // CHANGE - } - - rclcpp::shutdown(); - return 0; - } - - .. group-tab:: Python - - .. code-block:: python - - from tutorial_interfaces.srv import AddThreeInts # CHANGE - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalClientAsync(Node): - - def __init__(self): - super().__init__('minimal_client_async') - self.cli = self.create_client(AddThreeInts, 'add_three_ints') # CHANGE - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddThreeInts.Request() # CHANGE - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - self.req.c = 1 # CHANGE - return self.cli.call_async(self.req) - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_client = MinimalClientAsync() - future = minimal_client.send_request() - rclpy.spin_until_future_complete(minimal_client, future) - response = future.result() - minimal_client.get_logger().info( - 'Result of add_three_ints: for %d + %d + %d = %d' % # CHANGE - (minimal_client.req.a, minimal_client.req.b, minimal_client.req.c, response.sum)) # CHANGE - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -**CMakeLists.txt** - -Add the following lines (C++ only): - -.. code-block:: cmake - - #... - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(tutorial_interfaces REQUIRED) # CHANGE - - add_executable(server src/add_two_ints_server.cpp) - target_link_libraries(server PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - add_executable(client src/add_two_ints_client.cpp) - target_link_libraries(client PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE - - install(TARGETS - server - client - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - - -**package.xml** - -Add the following line: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: c++ - - tutorial_interfaces - - .. group-tab:: Python - - .. code-block:: python - - tutorial_interfaces - - -After making the above edits and saving all the changes, build the package: - -.. tabs:: - - .. group-tab:: C++ - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select cpp_srvcli - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_srvcli - - - .. group-tab:: Python - - On Linux/macOS: - - .. code-block:: console - - $ colcon build --packages-select py_srvcli - - On Windows: - - .. code-block:: console - - $ colcon build --merge-install --packages-select py_srvcli - -Then open two new terminals, source ``ros2_ws`` in each, and run: - -.. tabs:: - - .. group-tab:: C++ - - .. code-block:: console - - $ ros2 run cpp_srvcli server - - .. code-block:: console - - $ ros2 run cpp_srvcli client - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 run py_srvcli service - - .. code-block:: console - - $ ros2 run py_srvcli client - - -Summary -------- - -In this tutorial, you learned how to create custom interfaces in their own package and how to utilize those interfaces in other packages. - -This tutorial only scratches the surface about defining custom interfaces. -You can learn more about it in :doc:`About ROS 2 interfaces <../../About-Interfaces>`. - -Next steps ----------- - +.. redirect-from:: + + Tutorials/Custom-ROS2-Interfaces + Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces + +.. _CustomInterfaces: + +Creating custom msg and srv files +================================= + +**Goal:** Define custom interface files (``.msg`` and ``.srv``) and use them with Python and C++ nodes. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials you utilized message and service interfaces to learn about :doc:`topics <../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../../interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, and simple publisher/subscriber (:doc:`C++ `/:doc:`Python `) and service/client (:doc:`C++ `/:doc:`Python `) nodes. +The interfaces you used were predefined in those cases. + +While it's good practice to use predefined interface definitions, you will probably need to define your own messages and services sometimes as well. +This tutorial will introduce you to the simplest method of creating custom interface definitions. + +Prerequisites +------------- + +You should have a :doc:`ROS 2 workspace `. + +This tutorial also uses the packages created in the publisher/subscriber (:doc:`C++ ` and :doc:`Python `) and service/client (:doc:`C++ ` and :doc:`Python `) tutorials to try out the new custom messages. + +Tasks +----- + +1 Create a new package +^^^^^^^^^^^^^^^^^^^^^^^ + +For this tutorial you will be creating custom ``.msg`` and ``.srv`` files in their own package, and then utilizing them in a separate package. +Both packages should be in the same workspace. + +Since we will use the pub/sub and service/client packages created in earlier tutorials, make sure you are in the same workspace as those packages (``ros2_ws/src``), and then run the following command to create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 tutorial_interfaces + +``tutorial_interfaces`` is the name of the new package. +Note that it is, and can only be, an ament_cmake package, but this doesn't restrict in which type of packages you can use your messages and services. +You can create your own custom interfaces in an ament_cmake package, and then use it in a C++ or Python node, which will be covered in the last section. + +The ``.msg`` and ``.srv`` files are required to be placed in directories called ``msg`` and ``srv`` respectively. +Create the directories in ``ros2_ws/src/tutorial_interfaces``: + +.. code-block:: console + + $ mkdir msg srv + +2 Create custom definitions +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +2.1 msg definition +~~~~~~~~~~~~~~~~~~ + +In the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Num.msg`` with one line of code declaring its data structure: + +.. code-block:: bash + + int64 num + +This is a custom message that transfers a single 64-bit integer called ``num``. + +Also in the ``tutorial_interfaces/msg`` directory you just created, make a new file called ``Sphere.msg`` with the following content: + +.. code-block:: bash + + geometry_msgs/Point center + float64 radius + +This custom message uses a message from another message package (``geometry_msgs/Point`` in this case). + +2.2 srv definition +~~~~~~~~~~~~~~~~~~ + +Back in the ``tutorial_interfaces/srv`` directory you just created, make a new file called ``AddThreeInts.srv`` with the following request and response structure: + +.. code-block:: bash + + int64 a + int64 b + int64 c + --- + int64 sum + +This is your custom service that requests three integers named ``a``, ``b``, and ``c``, and responds with an integer called ``sum``. + +3 ``CMakeLists.txt`` +^^^^^^^^^^^^^^^^^^^^ + +To convert the interfaces you defined into language-specific code (like C++ and Python) so that they can be used in those languages, add the following lines to ``CMakeLists.txt``: + +.. code-block:: cmake + + find_package(geometry_msgs REQUIRED) + find_package(rosidl_default_generators REQUIRED) + + rosidl_generate_interfaces(${PROJECT_NAME} + "msg/Num.msg" + "msg/Sphere.msg" + "srv/AddThreeInts.srv" + DEPENDENCIES geometry_msgs # Add packages that above messages depend on, in this case geometry_msgs for Sphere.msg + ) + +.. note:: + + The first argument (library name) in the ``rosidl_generate_interfaces`` must start with the name of the package, e.g., simply ``${PROJECT_NAME}`` or ``${PROJECT_NAME}_suffix``. + See https://github.com/ros2/rosidl/issues/441#issuecomment-591025515. + +4 ``package.xml`` +^^^^^^^^^^^^^^^^^ + +Because the interfaces rely on ``rosidl_default_generators`` for generating language-specific code, you need to declare a build tool dependency on it. +``rosidl_default_runtime`` is a runtime or execution-stage dependency, needed to be able to use the interfaces later. +The ``rosidl_interface_packages`` is the name of the dependency group that your package, ``tutorial_interfaces``, should be associated with, declared using the ```` tag. + +Add the following lines within the ```` element of ``package.xml``: + +.. code-block:: xml + + geometry_msgs + rosidl_default_generators + rosidl_default_runtime + rosidl_interface_packages + +5 Build the ``tutorial_interfaces`` package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now that all the parts of your custom interfaces package are in place, you can build the package. +In the root of your workspace (``~/ros2_ws``), run the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select tutorial_interfaces + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select tutorial_interfaces + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select tutorial_interfaces + +Now the interfaces will be discoverable by other ROS 2 packages. + +6 Confirm msg and srv creation +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In a new terminal, run the following command from within your workspace (``ros2_ws``) to source it: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now you can confirm that your interface creation worked by using the ``ros2 interface show`` command. +The output you see in your terminal should look similar to the following: + +.. code-block:: console + + $ ros2 interface show tutorial_interfaces/msg/Num + int64 num + +.. code-block:: console + + $ ros2 interface show tutorial_interfaces/msg/Sphere + geometry_msgs/Point center + float64 x + float64 y + float64 z + float64 radius + +.. code-block:: console + + $ ros2 interface show tutorial_interfaces/srv/AddThreeInts + int64 a + int64 b + int64 c + --- + int64 sum + +7 Test the new interfaces +^^^^^^^^^^^^^^^^^^^^^^^^^ + +For this step you can use the packages you created in previous tutorials. +A few simple modifications to the nodes, ``CMakeLists.txt`` and ``package.xml`` files will allow you to use your new interfaces. + +7.1 Testing ``Num.msg`` with pub/sub +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With a few modifications to the publisher/subscriber package created in a previous tutorial (:doc:`C++ ` or :doc:`Python `), you can see ``Num.msg`` in action. +Since you'll be changing the standard string msg to a numerical one, the output will be slightly different. + +**Publisher** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/msg/num.hpp" // CHANGE + + using namespace std::chrono_literals; + + class MinimalPublisher : public rclcpp::Node + { + public: + MinimalPublisher() + : Node("minimal_publisher"), count_(0) + { + publisher_ = this->create_publisher("topic", 10); // CHANGE + + auto timer_callback = [this](){ + auto message = tutorial_interfaces::msg::Num(); // CHANGE + message.num = this->count_++; // CHANGE + RCLCPP_INFO_STREAM(this->get_logger(), "Publishing: '" << message.num << "'"); // CHANGE + publisher_->publish(message); + }; + timer_ = this->create_wall_timer(500ms, timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; // CHANGE + size_t count_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tutorial_interfaces.msg import Num # CHANGE + + + class MinimalPublisher(Node): + + def __init__(self): + super().__init__('minimal_publisher') + self.publisher_ = self.create_publisher(Num, 'topic', 10) # CHANGE + timer_period = 0.5 # seconds + self.timer = self.create_timer(timer_period, self.timer_callback) + self.i = 0 + + def timer_callback(self): + msg = Num() # CHANGE + msg.num = self.i # CHANGE + self.publisher_.publish(msg) + self.get_logger().info('Publishing: "%d"' % msg.num) # CHANGE + self.i += 1 + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_publisher = MinimalPublisher() + + rclpy.spin(minimal_publisher) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +**Subscriber** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/msg/num.hpp" // CHANGE + + using std::placeholders::_1; + + class MinimalSubscriber : public rclcpp::Node + { + public: + MinimalSubscriber() + : Node("minimal_subscriber") + { + auto topic_callback = [this](const tutorial_interfaces::msg::Num & msg){ // CHANGE + RCLCPP_INFO_STREAM(this->get_logger(), "I heard: '" << msg.num << "'"); // CHANGE + }; + subscription_ = this->create_subscription( // CHANGE + "topic", 10, topic_callback); + } + + private: + rclcpp::Subscription::SharedPtr subscription_; // CHANGE + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tutorial_interfaces.msg import Num # CHANGE + + + class MinimalSubscriber(Node): + + def __init__(self): + super().__init__('minimal_subscriber') + self.subscription = self.create_subscription( + Num, # CHANGE + 'topic', + self.listener_callback, + 10) + self.subscription # prevent unused variable warning + + def listener_callback(self, msg): + self.get_logger().info('I heard: "%d"' % msg.num) # CHANGE + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_subscriber = MinimalSubscriber() + + rclpy.spin(minimal_subscriber) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +**CMakeLists.txt** + +Add the following lines (C++ only): + +.. code-block:: cmake + + #... + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(tutorial_interfaces REQUIRED) # CHANGE + + add_executable(talker src/publisher_lambda_function.cpp) + target_link_libraries(talker PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + add_executable(listener src/subscriber_lambda_function.cpp) + target_link_libraries(listener PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + install(TARGETS + talker + listener + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + + +**package.xml** + +Add the following line: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + tutorial_interfaces + + .. group-tab:: Python + + .. code-block:: python + + tutorial_interfaces + + +After making the above edits and saving all the changes, build the package: + +.. tabs:: + + .. group-tab:: C++ + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select cpp_pubsub + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_pubsub + + .. group-tab:: Python + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select py_pubsub + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select py_pubsub + +Then open two new terminals, source ``ros2_ws`` in each, and run: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: console + + $ ros2 run cpp_pubsub talker + + .. code-block:: console + + $ ros2 run cpp_pubsub listener + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 run py_pubsub talker + + .. code-block:: console + + $ ros2 run py_pubsub listener + +Since ``Num.msg`` relays only an integer, the talker should only be publishing integer values, as opposed to the string it published previously: + +.. code-block:: console + + [INFO] [minimal_publisher]: Publishing: '0' + [INFO] [minimal_publisher]: Publishing: '1' + [INFO] [minimal_publisher]: Publishing: '2' + + +7.2 Testing ``AddThreeInts.srv`` with service/client +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With a few modifications to the service/client package created in a previous tutorial (:doc:`C++ ` or :doc:`Python `), you can see ``AddThreeInts.srv`` in action. +Since you'll be changing the original two integer request srv to a three integer request srv, the output will be slightly different. + +**Service** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE + + #include + + void add(const std::shared_ptr request, // CHANGE + std::shared_ptr response) // CHANGE + { + response->sum = request->a + request->b + request->c; // CHANGE + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Incoming request\na: %ld" " b: %ld" " c: %ld", // CHANGE + request->a, request->b, request->c); // CHANGE + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "sending back response: [%ld]", (long int)response->sum); + } + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_server"); // CHANGE + + rclcpp::Service::SharedPtr service = // CHANGE + node->create_service("add_three_ints", &add); // CHANGE + + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Ready to add three ints."); // CHANGE + + rclcpp::spin(node); + rclcpp::shutdown(); + } + + .. group-tab:: Python + + .. code-block:: python + + from tutorial_interfaces.srv import AddThreeInts # CHANGE + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalService(Node): + + def __init__(self): + super().__init__('minimal_service') + self.srv = self.create_service(AddThreeInts, 'add_three_ints', self.add_three_ints_callback) # CHANGE + + def add_three_ints_callback(self, request, response): + response.sum = request.a + request.b + request.c # CHANGE + self.get_logger().info('Incoming request\na: %d b: %d c: %d' % (request.a, request.b, request.c)) # CHANGE + + return response + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_service = MinimalService() + + rclpy.spin(minimal_service) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +**Client** + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + #include "rclcpp/rclcpp.hpp" + #include "tutorial_interfaces/srv/add_three_ints.hpp" // CHANGE + + #include + #include + #include + + using namespace std::chrono_literals; + + int main(int argc, char **argv) + { + rclcpp::init(argc, argv); + + std::shared_ptr node = rclcpp::Node::make_shared("add_three_ints_client"); // CHANGE + rclcpp::Client::SharedPtr client = // CHANGE + node->create_client("add_three_ints"); // CHANGE + + auto request = std::make_shared(); // CHANGE + request->a = 41; + request->b = 1; + request->c = 1; // CHANGE + + while (!client->wait_for_service(1s)) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Interrupted while waiting for the service. Exiting."); + return 0; + } + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "service not available, waiting again..."); + } + + auto result = client->async_send_request(request); + // Wait for the result. + if (rclcpp::spin_until_future_complete(node, result) == + rclcpp::FutureReturnCode::SUCCESS) + { + RCLCPP_INFO(rclcpp::get_logger("rclcpp"), "Sum: %ld", result.get()->sum); + } else { + RCLCPP_ERROR(rclcpp::get_logger("rclcpp"), "Failed to call service add_three_ints"); // CHANGE + } + + rclcpp::shutdown(); + return 0; + } + + .. group-tab:: Python + + .. code-block:: python + + from tutorial_interfaces.srv import AddThreeInts # CHANGE + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalClientAsync(Node): + + def __init__(self): + super().__init__('minimal_client_async') + self.cli = self.create_client(AddThreeInts, 'add_three_ints') # CHANGE + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddThreeInts.Request() # CHANGE + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + self.req.c = 1 # CHANGE + return self.cli.call_async(self.req) + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_client = MinimalClientAsync() + future = minimal_client.send_request() + rclpy.spin_until_future_complete(minimal_client, future) + response = future.result() + minimal_client.get_logger().info( + 'Result of add_three_ints: for %d + %d + %d = %d' % # CHANGE + (minimal_client.req.a, minimal_client.req.b, minimal_client.req.c, response.sum)) # CHANGE + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +**CMakeLists.txt** + +Add the following lines (C++ only): + +.. code-block:: cmake + + #... + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(tutorial_interfaces REQUIRED) # CHANGE + + add_executable(server src/add_two_ints_server.cpp) + target_link_libraries(server PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + add_executable(client src/add_two_ints_client.cpp) + target_link_libraries(client PUBLIC rclcpp::rclcpp tutorial_interfaces::tutorial_interfaces) # CHANGE + + install(TARGETS + server + client + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + + +**package.xml** + +Add the following line: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: c++ + + tutorial_interfaces + + .. group-tab:: Python + + .. code-block:: python + + tutorial_interfaces + + +After making the above edits and saving all the changes, build the package: + +.. tabs:: + + .. group-tab:: C++ + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select cpp_srvcli + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_srvcli + + + .. group-tab:: Python + + On Linux/macOS: + + .. code-block:: console + + $ colcon build --packages-select py_srvcli + + On Windows: + + .. code-block:: console + + $ colcon build --merge-install --packages-select py_srvcli + +Then open two new terminals, source ``ros2_ws`` in each, and run: + +.. tabs:: + + .. group-tab:: C++ + + .. code-block:: console + + $ ros2 run cpp_srvcli server + + .. code-block:: console + + $ ros2 run cpp_srvcli client + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 run py_srvcli service + + .. code-block:: console + + $ ros2 run py_srvcli client + + +Summary +------- + +In this tutorial, you learned how to create custom interfaces in their own package and how to utilize those interfaces in other packages. + +This tutorial only scratches the surface about defining custom interfaces. +You can learn more about it in :doc:`About ROS 2 interfaces <../../interfaces/About-Interfaces>`. + +Next steps +---------- + The :doc:`next tutorial ` covers more ways to use interfaces in ROS 2. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst index 187cf8043e5..86c2eaadb28 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst @@ -1,472 +1,472 @@ -.. _SinglePkgInterface: - -.. redirect-from:: - - Rosidl-Tutorial - Tutorials/Single-Package-Define-And-Use-Interface - Tutorials/Beginner-Client-Libraries/Single-Package-Define-And-Use-Interface - -Implementing custom interfaces -============================== - -**Goal:** Learn more ways to implement custom interfaces in ROS 2. - -**Tutorial level:** Beginner - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In a :doc:`previous tutorial `, you learned how to create custom msg and srv interfaces. - -While best practice is to declare interfaces in dedicated interface packages, sometimes it can be convenient to declare, create and use an interface all in one package. - -Recall that interfaces can currently only be defined in CMake packages. -It is possible, however, to have Python libraries and nodes in CMake packages (using `ament_cmake_python `_), so you could define interfaces and Python nodes together in one package. -We'll use a CMake package and C++ nodes here for the sake of simplicity. - -This tutorial will focus on the msg interface type, but the steps here are applicable to all interface types. - -Prerequisites -------------- - -We assume you've reviewed the basics in the :doc:`Custom-ROS2-Interfaces` tutorial before working through this one. - -You should have :doc:`ROS 2 installed <../../../Get-Started/Installation>`, a :doc:`workspace `, and an understanding of :doc:`creating packages `. - -As always, don't forget to :doc:`source ROS 2 <../../../Get-Started/Configuring-ROS2-Environment>` in every new terminal you open. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -In your workspace ``src`` directory, create a package ``more_interfaces`` and make a directory within it for msg files: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 more_interfaces - $ mkdir more_interfaces/msg - -2 Create a msg file -^^^^^^^^^^^^^^^^^^^ - -Inside ``more_interfaces/msg``, create a new file ``AddressBook.msg``, and paste the following code to create a message meant to carry information about an individual: - -:: - - uint8 PHONE_TYPE_HOME=0 - uint8 PHONE_TYPE_WORK=1 - uint8 PHONE_TYPE_MOBILE=2 - - string first_name - string last_name - string phone_number - uint8 phone_type - -This message is composed of these fields: - -* first_name: of type string -* last_name: of type string -* phone_number: of type string -* phone_type: of type uint8, with several named constant values defined - -Note that it's possible to set default values for fields within a message definition. -See :doc:`../../About-Interfaces` for more ways you can customize interfaces. - -Next, we need to make sure that the msg file is turned into source code for C++, Python, and other languages. - -2.1 Build a msg file -~~~~~~~~~~~~~~~~~~~~ - -Open ``package.xml`` and add the following lines: - -.. code-block:: xml - - rosidl_default_generators - - rosidl_default_runtime - - rosidl_interface_packages - -Note that at build time, we need ``rosidl_default_generators``, while at runtime, we only need ``rosidl_default_runtime``. - -Open ``CMakeLists.txt`` and add the following lines: - -Find the package that generates message code from msg/srv files: - -.. code-block:: cmake - - find_package(rosidl_default_generators REQUIRED) - -Declare the list of messages you want to generate: - -.. code-block:: cmake - - set(msg_files - "msg/AddressBook.msg" - ) - -By adding the .msg files manually, we make sure that CMake knows when it has to reconfigure the project after you add other .msg files. - -Generate the messages: - -.. code-block:: cmake - - rosidl_generate_interfaces(${PROJECT_NAME} - ${msg_files} - ) - -Also make sure you export the message runtime dependency: - -.. code-block:: cmake - - ament_export_dependencies(rosidl_default_runtime) - -Now you're ready to generate source files from your msg definition. -We'll skip the compile step for now as we'll do it all together below in step 4. - -3 Use an interface from the same package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Now we can start writing code that uses this message. - -In ``more_interfaces/src`` create a file called ``publish_address_book.cpp`` and paste the following code: - -.. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "more_interfaces/msg/address_book.hpp" - - using namespace std::chrono_literals; - - class AddressBookPublisher : public rclcpp::Node - { - public: - AddressBookPublisher() - : Node("address_book_publisher") - { - address_book_publisher_ = - this->create_publisher("address_book", 10); - - auto publish_msg = [this]() -> void { - auto message = more_interfaces::msg::AddressBook(); - - message.first_name = "John"; - message.last_name = "Doe"; - message.phone_number = "1234567890"; - message.phone_type = message.PHONE_TYPE_MOBILE; - - std::cout << "Publishing Contact\nFirst:" << message.first_name << - " Last:" << message.last_name << std::endl; - - this->address_book_publisher_->publish(message); - }; - timer_ = this->create_wall_timer(1s, publish_msg); - } - - private: - rclcpp::Publisher::SharedPtr address_book_publisher_; - rclcpp::TimerBase::SharedPtr timer_; - }; - - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - - return 0; - } - -3.1 The code explained -~~~~~~~~~~~~~~~~~~~~~~ - -Include the header of our newly created ``AddressBook.msg``. - -.. code-block:: c++ - - #include "more_interfaces/msg/address_book.hpp" - -Create a node and an ``AddressBook`` publisher. - -.. code-block:: c++ - - using namespace std::chrono_literals; - - class AddressBookPublisher : public rclcpp::Node - { - public: - AddressBookPublisher() - : Node("address_book_publisher") - { - address_book_publisher_ = - this->create_publisher("address_book"); - -Create a callback to publish the messages periodically. - -.. code-block:: c++ - - auto publish_msg = [this]() -> void { - -Create an ``AddressBook`` message instance that we will later publish. - -.. code-block:: c++ - - auto message = more_interfaces::msg::AddressBook(); - -Populate ``AddressBook`` fields. - -.. code-block:: c++ - - message.first_name = "John"; - message.last_name = "Doe"; - message.phone_number = "1234567890"; - message.phone_type = message.PHONE_TYPE_MOBILE; - -Finally send the message periodically. - -.. code-block:: c++ - - std::cout << "Publishing Contact\nFirst:" << message.first_name << - " Last:" << message.last_name << std::endl; - - this->address_book_publisher_->publish(message); - -Create a 1 second timer to call our ``publish_msg`` function every second. - -.. code-block:: c++ - - timer_ = this->create_wall_timer(1s, publish_msg); - -3.2 Build the publisher -~~~~~~~~~~~~~~~~~~~~~~~ - -We need to create a new target for this node in the ``CMakeLists.txt``: - -.. code-block:: cmake - - find_package(rclcpp REQUIRED) - - add_executable(publish_address_book src/publish_address_book.cpp) - target_link_libraries(publish_address_book rclcpp::rclcpp) - - install(TARGETS - publish_address_book - DESTINATION lib/${PROJECT_NAME}) - -3.3 Link against the interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to use the messages generated in the same package we need to use the following CMake code: - -.. code-block:: cmake - - rosidl_get_typesupport_target(cpp_typesupport_target - ${PROJECT_NAME} rosidl_typesupport_cpp) - - target_link_libraries(publish_address_book "${cpp_typesupport_target}") - -This finds the relevant generated C++ code from ``AddressBook.msg`` and allows your target to link against it. - -You may have noticed that this step was not necessary when the interfaces being used were from a different package that was built independently. -This CMake code is only required when you want to use interfaces in the same package as the one in which they are defined. - -4 Try it out -^^^^^^^^^^^^ - -Return to the root of the workspace to build the package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws - $ colcon build --packages-up-to more_interfaces - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws - $ colcon build --packages-up-to more_interfaces - - .. group-tab:: Windows - - .. code-block:: console - - $ cd /ros2_ws - $ colcon build --merge-install --packages-up-to more_interfaces - -Then source the workspace and run the publisher: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/local_setup.bash - $ ros2 run more_interfaces publish_address_book - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/local_setup.bash - $ ros2 run more_interfaces publish_address_book - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/local_setup.bat - $ ros2 run more_interfaces publish_address_book - - Or using Powershell: - - .. code-block:: console - - $ install/local_setup.ps1 - $ ros2 run more_interfaces publish_address_book - -You should see the publisher relaying the msg you defined, including the values you set in ``publish_address_book.cpp``. - -To confirm the message is being published on the ``address_book`` topic, open another terminal, source the workspace, and call ``topic echo``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - $ ros2 topic echo /address_book - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - $ ros2 topic echo /address_book - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - $ ros2 topic echo /address_book - - Or using Powershell: - - .. code-block:: console - - $ install/setup.ps1 - $ ros2 topic echo /address_book - -We won't create a subscriber in this tutorial, but you can try to write one yourself for practice (use :doc:`Writing-A-Simple-Cpp-Publisher-And-Subscriber` to help). - -5 (Extra) Use an existing interface definition -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. note:: - - You can use an existing interface definition in a new interface definition. - For example, let's say there is a message named ``Contact.msg`` that belongs to an existing ROS 2 package named ``rosidl_tutorials_msgs``. - Assume that its definition is identical to our custom-made ``AddressBook.msg`` interface from earlier. - - In that case you could have defined ``AddressBook.msg`` (an interface in the package *with* your nodes) as type ``Contact`` (an interface in a *separate* package). - You could even define ``AddressBook.msg`` as an *array* of type ``Contact``, like so: - - :: - - rosidl_tutorials_msgs/Contact[] address_book - - To generate this message you would need to declare a dependency on ``Contact.msg's`` package, ``rosidl_tutorials_msgs``, in ``package.xml``: - - .. code-block:: xml - - rosidl_tutorials_msgs - - rosidl_tutorials_msgs - - And in ``CMakeLists.txt``: - - .. code-block:: cmake - - find_package(rosidl_tutorials_msgs REQUIRED) - - rosidl_generate_interfaces(${PROJECT_NAME} - ${msg_files} - DEPENDENCIES rosidl_tutorials_msgs - ) - - You would also need to include the header of ``Contact.msg`` in your publisher node in order to be able to add ``contacts`` to your ``address_book``. - - .. code-block:: c++ - - #include "rosidl_tutorials_msgs/msg/contact.hpp" - - You could change the callback to something like this: - - .. code-block:: c++ - - auto publish_msg = [this]() -> void { - auto msg = std::make_shared(); - { - rosidl_tutorials_msgs::msg::Contact contact; - contact.first_name = "John"; - contact.last_name = "Doe"; - contact.phone_number = "1234567890"; - contact.phone_type = contact.PHONE_TYPE_MOBILE; - msg->address_book.push_back(contact); - } - { - rosidl_tutorials_msgs::msg::Contact contact; - contact.first_name = "Jane"; - contact.last_name = "Doe"; - contact.phone_number = "4254242424"; - contact.phone_type = contact.PHONE_TYPE_HOME; - msg->address_book.push_back(contact); - } - - std::cout << "Publishing address book:" << std::endl; - for (auto contact : msg->address_book) { - std::cout << "First:" << contact.first_name << " Last:" << contact.last_name << - std::endl; - } - - address_book_publisher_->publish(*msg); - }; - - Building and running these changes would show the msg defined as expected, as well as the array of msgs defined above. - -Summary -------- - -In this tutorial, you tried out different field types for defining interfaces, then built an interface in the same package where it's being used. - -You also learned how to use another interface as a field type, as well as the ``package.xml``, ``CMakeLists.txt``, and ``#include`` statements necessary for utilizing that feature. - -Next steps ----------- - -Next you will create a simple ROS 2 package with a custom parameter that you will learn to set from a launch file. -Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. - -Related content ---------------- - +.. _SinglePkgInterface: + +.. redirect-from:: + + Rosidl-Tutorial + Tutorials/Single-Package-Define-And-Use-Interface + Tutorials/Beginner-Client-Libraries/Single-Package-Define-And-Use-Interface + +Implementing custom interfaces +============================== + +**Goal:** Learn more ways to implement custom interfaces in ROS 2. + +**Tutorial level:** Beginner + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In a :doc:`previous tutorial `, you learned how to create custom msg and srv interfaces. + +While best practice is to declare interfaces in dedicated interface packages, sometimes it can be convenient to declare, create and use an interface all in one package. + +Recall that interfaces can currently only be defined in CMake packages. +It is possible, however, to have Python libraries and nodes in CMake packages (using `ament_cmake_python `_), so you could define interfaces and Python nodes together in one package. +We'll use a CMake package and C++ nodes here for the sake of simplicity. + +This tutorial will focus on the msg interface type, but the steps here are applicable to all interface types. + +Prerequisites +------------- + +We assume you've reviewed the basics in the :doc:`Custom-ROS2-Interfaces` tutorial before working through this one. + +You should have :doc:`ROS 2 installed <../../../Get-Started/Installation>`, a :doc:`workspace `, and an understanding of :doc:`creating packages `. + +As always, don't forget to :doc:`source ROS 2 <../../../Get-Started/Configuring-ROS2-Environment>` in every new terminal you open. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +In your workspace ``src`` directory, create a package ``more_interfaces`` and make a directory within it for msg files: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 more_interfaces + $ mkdir more_interfaces/msg + +2 Create a msg file +^^^^^^^^^^^^^^^^^^^ + +Inside ``more_interfaces/msg``, create a new file ``AddressBook.msg``, and paste the following code to create a message meant to carry information about an individual: + +:: + + uint8 PHONE_TYPE_HOME=0 + uint8 PHONE_TYPE_WORK=1 + uint8 PHONE_TYPE_MOBILE=2 + + string first_name + string last_name + string phone_number + uint8 phone_type + +This message is composed of these fields: + +* first_name: of type string +* last_name: of type string +* phone_number: of type string +* phone_type: of type uint8, with several named constant values defined + +Note that it's possible to set default values for fields within a message definition. +See :doc:`../../interfaces/About-Interfaces` for more ways you can customize interfaces. + +Next, we need to make sure that the msg file is turned into source code for C++, Python, and other languages. + +2.1 Build a msg file +~~~~~~~~~~~~~~~~~~~~ + +Open ``package.xml`` and add the following lines: + +.. code-block:: xml + + rosidl_default_generators + + rosidl_default_runtime + + rosidl_interface_packages + +Note that at build time, we need ``rosidl_default_generators``, while at runtime, we only need ``rosidl_default_runtime``. + +Open ``CMakeLists.txt`` and add the following lines: + +Find the package that generates message code from msg/srv files: + +.. code-block:: cmake + + find_package(rosidl_default_generators REQUIRED) + +Declare the list of messages you want to generate: + +.. code-block:: cmake + + set(msg_files + "msg/AddressBook.msg" + ) + +By adding the .msg files manually, we make sure that CMake knows when it has to reconfigure the project after you add other .msg files. + +Generate the messages: + +.. code-block:: cmake + + rosidl_generate_interfaces(${PROJECT_NAME} + ${msg_files} + ) + +Also make sure you export the message runtime dependency: + +.. code-block:: cmake + + ament_export_dependencies(rosidl_default_runtime) + +Now you're ready to generate source files from your msg definition. +We'll skip the compile step for now as we'll do it all together below in step 4. + +3 Use an interface from the same package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Now we can start writing code that uses this message. + +In ``more_interfaces/src`` create a file called ``publish_address_book.cpp`` and paste the following code: + +.. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "more_interfaces/msg/address_book.hpp" + + using namespace std::chrono_literals; + + class AddressBookPublisher : public rclcpp::Node + { + public: + AddressBookPublisher() + : Node("address_book_publisher") + { + address_book_publisher_ = + this->create_publisher("address_book", 10); + + auto publish_msg = [this]() -> void { + auto message = more_interfaces::msg::AddressBook(); + + message.first_name = "John"; + message.last_name = "Doe"; + message.phone_number = "1234567890"; + message.phone_type = message.PHONE_TYPE_MOBILE; + + std::cout << "Publishing Contact\nFirst:" << message.first_name << + " Last:" << message.last_name << std::endl; + + this->address_book_publisher_->publish(message); + }; + timer_ = this->create_wall_timer(1s, publish_msg); + } + + private: + rclcpp::Publisher::SharedPtr address_book_publisher_; + rclcpp::TimerBase::SharedPtr timer_; + }; + + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + + return 0; + } + +3.1 The code explained +~~~~~~~~~~~~~~~~~~~~~~ + +Include the header of our newly created ``AddressBook.msg``. + +.. code-block:: c++ + + #include "more_interfaces/msg/address_book.hpp" + +Create a node and an ``AddressBook`` publisher. + +.. code-block:: c++ + + using namespace std::chrono_literals; + + class AddressBookPublisher : public rclcpp::Node + { + public: + AddressBookPublisher() + : Node("address_book_publisher") + { + address_book_publisher_ = + this->create_publisher("address_book"); + +Create a callback to publish the messages periodically. + +.. code-block:: c++ + + auto publish_msg = [this]() -> void { + +Create an ``AddressBook`` message instance that we will later publish. + +.. code-block:: c++ + + auto message = more_interfaces::msg::AddressBook(); + +Populate ``AddressBook`` fields. + +.. code-block:: c++ + + message.first_name = "John"; + message.last_name = "Doe"; + message.phone_number = "1234567890"; + message.phone_type = message.PHONE_TYPE_MOBILE; + +Finally send the message periodically. + +.. code-block:: c++ + + std::cout << "Publishing Contact\nFirst:" << message.first_name << + " Last:" << message.last_name << std::endl; + + this->address_book_publisher_->publish(message); + +Create a 1 second timer to call our ``publish_msg`` function every second. + +.. code-block:: c++ + + timer_ = this->create_wall_timer(1s, publish_msg); + +3.2 Build the publisher +~~~~~~~~~~~~~~~~~~~~~~~ + +We need to create a new target for this node in the ``CMakeLists.txt``: + +.. code-block:: cmake + + find_package(rclcpp REQUIRED) + + add_executable(publish_address_book src/publish_address_book.cpp) + target_link_libraries(publish_address_book rclcpp::rclcpp) + + install(TARGETS + publish_address_book + DESTINATION lib/${PROJECT_NAME}) + +3.3 Link against the interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to use the messages generated in the same package we need to use the following CMake code: + +.. code-block:: cmake + + rosidl_get_typesupport_target(cpp_typesupport_target + ${PROJECT_NAME} rosidl_typesupport_cpp) + + target_link_libraries(publish_address_book "${cpp_typesupport_target}") + +This finds the relevant generated C++ code from ``AddressBook.msg`` and allows your target to link against it. + +You may have noticed that this step was not necessary when the interfaces being used were from a different package that was built independently. +This CMake code is only required when you want to use interfaces in the same package as the one in which they are defined. + +4 Try it out +^^^^^^^^^^^^ + +Return to the root of the workspace to build the package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws + $ colcon build --packages-up-to more_interfaces + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws + $ colcon build --packages-up-to more_interfaces + + .. group-tab:: Windows + + .. code-block:: console + + $ cd /ros2_ws + $ colcon build --merge-install --packages-up-to more_interfaces + +Then source the workspace and run the publisher: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/local_setup.bash + $ ros2 run more_interfaces publish_address_book + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/local_setup.bash + $ ros2 run more_interfaces publish_address_book + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/local_setup.bat + $ ros2 run more_interfaces publish_address_book + + Or using Powershell: + + .. code-block:: console + + $ install/local_setup.ps1 + $ ros2 run more_interfaces publish_address_book + +You should see the publisher relaying the msg you defined, including the values you set in ``publish_address_book.cpp``. + +To confirm the message is being published on the ``address_book`` topic, open another terminal, source the workspace, and call ``topic echo``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + $ ros2 topic echo /address_book + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + $ ros2 topic echo /address_book + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + $ ros2 topic echo /address_book + + Or using Powershell: + + .. code-block:: console + + $ install/setup.ps1 + $ ros2 topic echo /address_book + +We won't create a subscriber in this tutorial, but you can try to write one yourself for practice (use :doc:`Writing-A-Simple-Cpp-Publisher-And-Subscriber` to help). + +5 (Extra) Use an existing interface definition +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. note:: + + You can use an existing interface definition in a new interface definition. + For example, let's say there is a message named ``Contact.msg`` that belongs to an existing ROS 2 package named ``rosidl_tutorials_msgs``. + Assume that its definition is identical to our custom-made ``AddressBook.msg`` interface from earlier. + + In that case you could have defined ``AddressBook.msg`` (an interface in the package *with* your nodes) as type ``Contact`` (an interface in a *separate* package). + You could even define ``AddressBook.msg`` as an *array* of type ``Contact``, like so: + + :: + + rosidl_tutorials_msgs/Contact[] address_book + + To generate this message you would need to declare a dependency on ``Contact.msg's`` package, ``rosidl_tutorials_msgs``, in ``package.xml``: + + .. code-block:: xml + + rosidl_tutorials_msgs + + rosidl_tutorials_msgs + + And in ``CMakeLists.txt``: + + .. code-block:: cmake + + find_package(rosidl_tutorials_msgs REQUIRED) + + rosidl_generate_interfaces(${PROJECT_NAME} + ${msg_files} + DEPENDENCIES rosidl_tutorials_msgs + ) + + You would also need to include the header of ``Contact.msg`` in your publisher node in order to be able to add ``contacts`` to your ``address_book``. + + .. code-block:: c++ + + #include "rosidl_tutorials_msgs/msg/contact.hpp" + + You could change the callback to something like this: + + .. code-block:: c++ + + auto publish_msg = [this]() -> void { + auto msg = std::make_shared(); + { + rosidl_tutorials_msgs::msg::Contact contact; + contact.first_name = "John"; + contact.last_name = "Doe"; + contact.phone_number = "1234567890"; + contact.phone_type = contact.PHONE_TYPE_MOBILE; + msg->address_book.push_back(contact); + } + { + rosidl_tutorials_msgs::msg::Contact contact; + contact.first_name = "Jane"; + contact.last_name = "Doe"; + contact.phone_number = "4254242424"; + contact.phone_type = contact.PHONE_TYPE_HOME; + msg->address_book.push_back(contact); + } + + std::cout << "Publishing address book:" << std::endl; + for (auto contact : msg->address_book) { + std::cout << "First:" << contact.first_name << " Last:" << contact.last_name << + std::endl; + } + + address_book_publisher_->publish(*msg); + }; + + Building and running these changes would show the msg defined as expected, as well as the array of msgs defined above. + +Summary +------- + +In this tutorial, you tried out different field types for defining interfaces, then built an interface in the same package where it's being used. + +You also learned how to use another interface as a field type, as well as the ``package.xml``, ``CMakeLists.txt``, and ``#include`` statements necessary for utilizing that feature. + +Next steps +---------- + +Next you will create a simple ROS 2 package with a custom parameter that you will learn to set from a launch file. +Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. + +Related content +--------------- + There are `several design articles `_ on ROS 2 interfaces and the IDL (interface definition language). \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst index efae2bab67d..28a92529368 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst @@ -1,494 +1,494 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Cpp - Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Cpp - -Writing a broadcaster (C++) -=========================== - -**Goal:** Learn how to broadcast the state of a robot to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. - -Prerequisites -------------- - -This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (C++) `. -We'll be reusing the ``learning_tf2_cpp`` package from that last tutorial. - -In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Write the broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. -Inside the ``src`` directory download the example broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2/LinearMath/Quaternion.hpp" - #include "tf2_ros/transform_broadcaster.h" - #include "turtlesim_msgs/msg/pose.hpp" - - class FramePublisher : public rclcpp::Node - { - public: - FramePublisher() - : Node("turtle_tf2_frame_publisher") - { - // Declare and acquire `turtlename` parameter - turtlename_ = this->declare_parameter("turtlename", "turtle"); - - // Initialize the transform broadcaster - tf_broadcaster_ = - std::make_unique(*this); - - // Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose - // callback function on each message - std::ostringstream stream; - stream << "/" << turtlename_.c_str() << "/pose"; - std::string topic_name = stream.str(); - - auto handle_turtle_pose = [this](const std::shared_ptr msg){ - geometry_msgs::msg::TransformStamped t; - - // Read message content and assign it to - // corresponding tf variables - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = turtlename_.c_str(); - - // Turtle only exists in 2D, thus we get x and y translation - // coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg->x; - t.transform.translation.y = msg->y; - t.transform.translation.z = 0.0; - - // For the same reason, turtle can only rotate around one axis - // and this why we set rotation in x and y to 0 and obtain - // rotation in z axis from the message - tf2::Quaternion q; - q.setRPY(0, 0, msg->theta); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - - // Send the transformation - tf_broadcaster_->sendTransform(t); - }; - subscription_ = this->create_subscription( - topic_name, 10, - handle_turtle_pose); - } - - private: - rclcpp::Subscription::SharedPtr subscription_; - std::unique_ptr tf_broadcaster_; - std::string turtlename_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. -Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. - -.. code-block:: C++ - - turtlename_ = this->declare_parameter("turtlename", "turtle"); - -Afterward, the node subscribes to topic ``turtleX/pose`` and runs function ``handle_turtle_pose`` on every incoming message. - -.. code-block:: C++ - - subscription_ = this->create_subscription( - topic_name, 10, - handle_turtle_pose); - -Now, we create a ``TransformStamped`` object and give it the appropriate metadata. - -#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``this->get_clock()->now()``. - This will return the current time used by the ``Node``. - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. - -#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. - -The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. - -.. code-block:: C++ - - geometry_msgs::msg::TransformStamped t; - - // Read message content and assign it to - // corresponding tf variables - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = turtlename_.c_str(); - -Here we copy the information from the 3D turtle pose into the 3D transform. - -.. code-block:: C++ - - // Turtle only exists in 2D, thus we get x and y translation - // coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg->x; - t.transform.translation.y = msg->y; - t.transform.translation.z = 0.0; - - // For the same reason, turtle can only rotate around one axis - // and this why we set rotation in x and y to 0 and obtain - // rotation in z axis from the message - tf2::Quaternion q; - q.setRPY(0, 0, msg->theta); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - -Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. - -.. code-block:: C++ - - // Send the transformation - tf_broadcaster_->sendTransform(t); - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - find_package(turtlesim_msgs REQUIRED) - add_executable(turtle_tf2_broadcaster src/turtle_tf2_broadcaster.cpp) - target_link_libraries( - turtle_tf2_broadcaster PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2::tf2 - tf2_ros::tf2_ros - turtlesim_msgs::turtlesim_msgs - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - turtle_tf2_broadcaster - DESTINATION lib/${PROJECT_NAME}) - -2 Write the launch file -^^^^^^^^^^^^^^^^^^^^^^^ - -Now create a launch file for this demo. -Create a ``launch`` folder in the ``src/learning_tf2_cpp`` directory. -With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_demo_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_demo_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_demo_launch.py - :language: python - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Let's examine the launch file structure. -Each format has its own way of setting up the launch file: - -.. tabs:: - - .. group-tab:: XML - - XML launch files start with an XML declaration and a root ```` element. - - .. literalinclude:: launch/turtle_tf2_demo_launch.xml - :language: xml - :lines: 1-2 - - .. group-tab:: YAML - - YAML launch files start with a YAML version declaration and a ``launch:`` key. - - .. literalinclude:: launch/turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 1-3 - - .. group-tab:: Python - - In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. - It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. - - .. literalinclude:: launch/turtle_tf2_demo_launch.py - :language: python - :lines: 1-2 - -Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/turtle_tf2_demo_launch.xml - :language: xml - :lines: 3-6 - - .. group-tab:: YAML - - .. literalinclude:: launch/turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 4-9 - - .. group-tab:: Python - - .. literalinclude:: launch/turtle_tf2_demo_launch.py - :language: python - :lines: 5-20 - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Open ``package.xml`` with your text editor. -Add the following dependencies corresponding to your launch file's import statements: - -.. code-block:: xml - - launch - launch_ros - -This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. - -Make sure to save the file. - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Reopen ``CMakeLists.txt`` and add the line so that the launch files from the ``launch/`` folder will be installed. - -.. code-block:: console - - install(DIRECTORY launch - DESTINATION share/${PROJECT_NAME}) - -You can learn more about creating launch files in :doc:`this tutorial <../../../../Developer-Tools/Launch/Creating-Launch-Files>`. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -4 Run -^^^^^ - -Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py - -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -You will now see that the turtlesim simulation have started with one turtle that you can control. - -.. image:: images/turtlesim_broadcast.png - -Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo world turtle1 - -This should show you the pose of the first turtle. -Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). -In your console output you will see something similar to this: - -.. code-block:: console - - At time 1625137663.912474878 - - Translation: [5.276, 7.930, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] - At time 1625137664.950813527 - - Translation: [3.750, 6.563, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] - At time 1625137665.906280726 - - Translation: [2.320, 5.282, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] - At time 1625137666.850775673 - - Translation: [2.153, 5.133, 0.000] - - Rotation: in Quaternion [0.000, 0.000, -0.365, 0.931] - -If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. -However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. - -Summary -------- - -In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Cpp + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Cpp + +Writing a broadcaster (C++) +=========================== + +**Goal:** Learn how to broadcast the state of a robot to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. + +Prerequisites +------------- + +This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (C++) `. +We'll be reusing the ``learning_tf2_cpp`` package from that last tutorial. + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Write the broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. +Inside the ``src`` directory download the example broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_broadcaster.cpp -o turtle_tf2_broadcaster.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2/LinearMath/Quaternion.hpp" + #include "tf2_ros/transform_broadcaster.h" + #include "turtlesim_msgs/msg/pose.hpp" + + class FramePublisher : public rclcpp::Node + { + public: + FramePublisher() + : Node("turtle_tf2_frame_publisher") + { + // Declare and acquire `turtlename` parameter + turtlename_ = this->declare_parameter("turtlename", "turtle"); + + // Initialize the transform broadcaster + tf_broadcaster_ = + std::make_unique(*this); + + // Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose + // callback function on each message + std::ostringstream stream; + stream << "/" << turtlename_.c_str() << "/pose"; + std::string topic_name = stream.str(); + + auto handle_turtle_pose = [this](const std::shared_ptr msg){ + geometry_msgs::msg::TransformStamped t; + + // Read message content and assign it to + // corresponding tf variables + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = turtlename_.c_str(); + + // Turtle only exists in 2D, thus we get x and y translation + // coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg->x; + t.transform.translation.y = msg->y; + t.transform.translation.z = 0.0; + + // For the same reason, turtle can only rotate around one axis + // and this why we set rotation in x and y to 0 and obtain + // rotation in z axis from the message + tf2::Quaternion q; + q.setRPY(0, 0, msg->theta); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + + // Send the transformation + tf_broadcaster_->sendTransform(t); + }; + subscription_ = this->create_subscription( + topic_name, 10, + handle_turtle_pose); + } + + private: + rclcpp::Subscription::SharedPtr subscription_; + std::unique_ptr tf_broadcaster_; + std::string turtlename_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. +Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. + +.. code-block:: C++ + + turtlename_ = this->declare_parameter("turtlename", "turtle"); + +Afterward, the node subscribes to topic ``turtleX/pose`` and runs function ``handle_turtle_pose`` on every incoming message. + +.. code-block:: C++ + + subscription_ = this->create_subscription( + topic_name, 10, + handle_turtle_pose); + +Now, we create a ``TransformStamped`` object and give it the appropriate metadata. + +#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``this->get_clock()->now()``. + This will return the current time used by the ``Node``. + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. + +#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. + +The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. + +.. code-block:: C++ + + geometry_msgs::msg::TransformStamped t; + + // Read message content and assign it to + // corresponding tf variables + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = turtlename_.c_str(); + +Here we copy the information from the 3D turtle pose into the 3D transform. + +.. code-block:: C++ + + // Turtle only exists in 2D, thus we get x and y translation + // coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg->x; + t.transform.translation.y = msg->y; + t.transform.translation.z = 0.0; + + // For the same reason, turtle can only rotate around one axis + // and this why we set rotation in x and y to 0 and obtain + // rotation in z axis from the message + tf2::Quaternion q; + q.setRPY(0, 0, msg->theta); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + +Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. + +.. code-block:: C++ + + // Send the transformation + tf_broadcaster_->sendTransform(t); + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + find_package(turtlesim_msgs REQUIRED) + add_executable(turtle_tf2_broadcaster src/turtle_tf2_broadcaster.cpp) + target_link_libraries( + turtle_tf2_broadcaster PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2::tf2 + tf2_ros::tf2_ros + turtlesim_msgs::turtlesim_msgs + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + turtle_tf2_broadcaster + DESTINATION lib/${PROJECT_NAME}) + +2 Write the launch file +^^^^^^^^^^^^^^^^^^^^^^^ + +Now create a launch file for this demo. +Create a ``launch`` folder in the ``src/learning_tf2_cpp`` directory. +With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_demo_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_demo_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_demo_launch.py + :language: python + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Let's examine the launch file structure. +Each format has its own way of setting up the launch file: + +.. tabs:: + + .. group-tab:: XML + + XML launch files start with an XML declaration and a root ```` element. + + .. literalinclude:: launch/turtle_tf2_demo_launch.xml + :language: xml + :lines: 1-2 + + .. group-tab:: YAML + + YAML launch files start with a YAML version declaration and a ``launch:`` key. + + .. literalinclude:: launch/turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 1-3 + + .. group-tab:: Python + + In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. + It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. + + .. literalinclude:: launch/turtle_tf2_demo_launch.py + :language: python + :lines: 1-2 + +Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/turtle_tf2_demo_launch.xml + :language: xml + :lines: 3-6 + + .. group-tab:: YAML + + .. literalinclude:: launch/turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 4-9 + + .. group-tab:: Python + + .. literalinclude:: launch/turtle_tf2_demo_launch.py + :language: python + :lines: 5-20 + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Open ``package.xml`` with your text editor. +Add the following dependencies corresponding to your launch file's import statements: + +.. code-block:: xml + + launch + launch_ros + +This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. + +Make sure to save the file. + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Reopen ``CMakeLists.txt`` and add the line so that the launch files from the ``launch/`` folder will be installed. + +.. code-block:: console + + install(DIRECTORY launch + DESTINATION share/${PROJECT_NAME}) + +You can learn more about creating launch files in :doc:`this tutorial <../../../../Developer-Tools/Launch/Creating-Launch-Files>`. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +4 Run +^^^^^ + +Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py + +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +You will now see that the turtlesim simulation have started with one turtle that you can control. + +.. image:: images/turtlesim_broadcast.png + +Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo world turtle1 + +This should show you the pose of the first turtle. +Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). +In your console output you will see something similar to this: + +.. code-block:: console + + At time 1625137663.912474878 + - Translation: [5.276, 7.930, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] + At time 1625137664.950813527 + - Translation: [3.750, 6.563, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] + At time 1625137665.906280726 + - Translation: [2.320, 5.282, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.934, -0.357] + At time 1625137666.850775673 + - Translation: [2.153, 5.133, 0.000] + - Rotation: in Quaternion [0.000, 0.000, -0.365, 0.931] + +If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. +However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. + +Summary +------- + +In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst index a6474d78dab..14b93c31c7c 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst @@ -1,512 +1,512 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Py - Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Py - -Writing a broadcaster (Python) -============================== - -**Goal:** Learn how to broadcast the state of a robot to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. - -Prerequisites -------------- - -This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (Python) `. -We'll be reusing the ``learning_tf2_py`` package from that last tutorial. - -In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Write the broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_py`` package we created in the previous tutorial. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py - -Now open the file called ``turtle_tf2_broadcaster.py`` using your preferred text editor. - -.. code-block:: python - - import math - - from geometry_msgs.msg import TransformStamped - - import numpy as np - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros import TransformBroadcaster - - from turtlesim_msgs.msg import Pose - - - def quaternion_from_euler(ai, aj, ak): - ai /= 2.0 - aj /= 2.0 - ak /= 2.0 - ci = math.cos(ai) - si = math.sin(ai) - cj = math.cos(aj) - sj = math.sin(aj) - ck = math.cos(ak) - sk = math.sin(ak) - cc = ci*ck - cs = ci*sk - sc = si*ck - ss = si*sk - - q = np.empty((4, )) - q[0] = cj*sc - sj*cs - q[1] = cj*ss + sj*cc - q[2] = cj*cs - sj*sc - q[3] = cj*cc + sj*ss - - return q - - - class FramePublisher(Node): - - def __init__(self): - super().__init__('turtle_tf2_frame_publisher') - - # Declare and acquire `turtlename` parameter - self.turtlename = self.declare_parameter( - 'turtlename', 'turtle').get_parameter_value().string_value - - # Initialize the transform broadcaster - self.tf_broadcaster = TransformBroadcaster(self) - - # Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose - # callback function on each message - self.subscription = self.create_subscription( - Pose, - f'/{self.turtlename}/pose', - self.handle_turtle_pose, - 1) - self.subscription # prevent unused variable warning - - def handle_turtle_pose(self, msg): - t = TransformStamped() - - # Read message content and assign it to - # corresponding tf variables - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = self.turtlename - - # Turtle only exists in 2D, thus we get x and y translation - # coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg.x - t.transform.translation.y = msg.y - t.transform.translation.z = 0.0 - - # For the same reason, turtle can only rotate around one axis - # and this why we set rotation in x and y to 0 and obtain - # rotation in z axis from the message - q = quaternion_from_euler(0, 0, msg.theta) - t.transform.rotation.x = q[0] - t.transform.rotation.y = q[1] - t.transform.rotation.z = q[2] - t.transform.rotation.w = q[3] - - # Send the transformation - self.tf_broadcaster.sendTransform(t) - - - def main(): - try: - with rclpy.init(): - node = FramePublisher() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. -Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. - -.. code-block:: python - - self.turtlename = self.declare_parameter( - 'turtlename', 'turtle').get_parameter_value().string_value - -Afterward, the node subscribes to topic ``{self.turtlename}/pose`` and runs function ``handle_turtle_pose`` on every incoming message. - -.. code-block:: python - - self .subscription = self.create_subscription( - Pose, - f'/{self.turtlename}/pose', - self.handle_turtle_pose, - 1) - -Now, we create a ``TransformStamped`` object and give it the appropriate metadata. - -#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``self.get_clock().now()``. - This will return the current time used by the ``Node``. - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. - -#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. - -The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. - -.. code-block:: python - - t = TransformStamped() - - # Read message content and assign it to - # corresponding tf variables - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = self.turtlename - -Here we copy the information from the 3D turtle pose into the 3D transform. - -.. code-block:: python - - # Turtle only exists in 2D, thus we get x and y translation - # coordinates from the message and set the z coordinate to 0 - t.transform.translation.x = msg.x - t.transform.translation.y = msg.y - t.transform.translation.z = 0.0 - - # For the same reason, turtle can only rotate around one axis - # and this why we set rotation in x and y to 0 and obtain - # rotation in z axis from the message - q = quaternion_from_euler(0, 0, msg.theta) - t.transform.rotation.x = q[0] - t.transform.rotation.y = q[1] - t.transform.rotation.z = q[2] - t.transform.rotation.w = q[3] - -Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. - -.. code-block:: python - - # Send the transformation - self.tf_broadcaster.sendTransform(t) - -1.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point -to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'turtle_tf2_broadcaster = learning_tf2_py.turtle_tf2_broadcaster:main', - -2 Write the launch file -^^^^^^^^^^^^^^^^^^^^^^^ - -Now create a launch file for this demo. -Create a ``launch`` folder in the ``src/learning_tf2_py`` directory. -With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml - :language: xml - :name: turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml - :language: yaml - :name: turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.py - :language: python - :name: turtle_tf2_demo_launch.py - - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Let's examine the launch file structure. -Each format has its own way of setting up the launch file: - -.. tabs:: - - .. group-tab:: XML - - XML launch files start with an XML declaration and a root ```` element. - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml - :language: xml - :lines: 1-2 - - .. group-tab:: YAML - - YAML launch files start with a YAML version declaration and a ``launch:`` key. - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 1-3 - - .. group-tab:: Python - - In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. - It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.py - :language: python - :lines: 1-2 - -Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml - :language: xml - :lines: 3-6 - - .. group-tab:: YAML - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml - :language: yaml - :lines: 4-9 - - .. group-tab:: Python - - .. literalinclude:: launch/py_turtle_tf2_demo_launch.py - :language: python - :lines: 5-20 - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files are located. - -Open ``package.xml`` with your text editor. -Add the following dependencies corresponding to your launch file's import statements: - -.. code-block:: xml - - launch - launch_ros - -This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. - -Make sure to save the file. - -2.3 Update setup.py -~~~~~~~~~~~~~~~~~~~ - -Reopen ``setup.py`` and add the line so that the launch files from the ``launch/`` folder will be installed. -The ``data_files`` field should now look like this: - -.. code-block:: python - - data_files=[ - ... - (os.path.join('share', package_name, 'launch'), glob('launch/*')), - ], - -Also add the appropriate imports at the top of the file: - -.. code-block:: python - - import os - from glob import glob - -You can learn more about creating launch files in :doc:`this tutorial <../../../../Developer-Tools/Launch/Creating-Launch-Files>`. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - -4 Run -^^^^^ - -Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py - -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -You will now see that the turtlesim simulation has started with one turtle that you can control. - -.. image:: images/turtlesim_broadcast.png - -Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo world turtle1 - -This should show you the pose of the first turtle. -Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). -In your console output you will see something similar to this: - -.. code-block:: console - - At time 1714913843.708748879 - - Translation: [4.541, 3.889, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.999, -0.035] - - Rotation: in RPY (radian) [0.000, -0.000, -3.072] - - Rotation: in RPY (degree) [0.000, -0.000, -176.013] - - Matrix: - -0.998 0.070 0.000 4.541 - -0.070 -0.998 0.000 3.889 - 0.000 0.000 1.000 0.000 - 0.000 0.000 0.000 1.000 - -If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. -However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. - -Summary -------- - -In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Broadcaster-Py + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Broadcaster-Py + +Writing a broadcaster (Python) +============================== + +**Goal:** Learn how to broadcast the state of a robot to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features, including the usage of timeouts in transformation lookups and time travel. + +Prerequisites +------------- + +This tutorial assumes you have a working knowledge of ROS 2 and you have completed the :doc:`Introduction to tf2 tutorial <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` and :doc:`tf2 static broadcaster tutorial (Python) `. +We'll be reusing the ``learning_tf2_py`` package from that last tutorial. + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Write the broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_py`` package we created in the previous tutorial. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_broadcaster.py -o turtle_tf2_broadcaster.py + +Now open the file called ``turtle_tf2_broadcaster.py`` using your preferred text editor. + +.. code-block:: python + + import math + + from geometry_msgs.msg import TransformStamped + + import numpy as np + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros import TransformBroadcaster + + from turtlesim_msgs.msg import Pose + + + def quaternion_from_euler(ai, aj, ak): + ai /= 2.0 + aj /= 2.0 + ak /= 2.0 + ci = math.cos(ai) + si = math.sin(ai) + cj = math.cos(aj) + sj = math.sin(aj) + ck = math.cos(ak) + sk = math.sin(ak) + cc = ci*ck + cs = ci*sk + sc = si*ck + ss = si*sk + + q = np.empty((4, )) + q[0] = cj*sc - sj*cs + q[1] = cj*ss + sj*cc + q[2] = cj*cs - sj*sc + q[3] = cj*cc + sj*ss + + return q + + + class FramePublisher(Node): + + def __init__(self): + super().__init__('turtle_tf2_frame_publisher') + + # Declare and acquire `turtlename` parameter + self.turtlename = self.declare_parameter( + 'turtlename', 'turtle').get_parameter_value().string_value + + # Initialize the transform broadcaster + self.tf_broadcaster = TransformBroadcaster(self) + + # Subscribe to a turtle{1}{2}/pose topic and call handle_turtle_pose + # callback function on each message + self.subscription = self.create_subscription( + Pose, + f'/{self.turtlename}/pose', + self.handle_turtle_pose, + 1) + self.subscription # prevent unused variable warning + + def handle_turtle_pose(self, msg): + t = TransformStamped() + + # Read message content and assign it to + # corresponding tf variables + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = self.turtlename + + # Turtle only exists in 2D, thus we get x and y translation + # coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg.x + t.transform.translation.y = msg.y + t.transform.translation.z = 0.0 + + # For the same reason, turtle can only rotate around one axis + # and this why we set rotation in x and y to 0 and obtain + # rotation in z axis from the message + q = quaternion_from_euler(0, 0, msg.theta) + t.transform.rotation.x = q[0] + t.transform.rotation.y = q[1] + t.transform.rotation.z = q[2] + t.transform.rotation.w = q[3] + + # Send the transformation + self.tf_broadcaster.sendTransform(t) + + + def main(): + try: + with rclpy.init(): + node = FramePublisher() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now, let's take a look at the code that is relevant to publishing the turtle pose to tf2. +Firstly, we define and acquire a single parameter ``turtlename``, which specifies a turtle name, e.g. ``turtle1`` or ``turtle2``. + +.. code-block:: python + + self.turtlename = self.declare_parameter( + 'turtlename', 'turtle').get_parameter_value().string_value + +Afterward, the node subscribes to topic ``{self.turtlename}/pose`` and runs function ``handle_turtle_pose`` on every incoming message. + +.. code-block:: python + + self .subscription = self.create_subscription( + Pose, + f'/{self.turtlename}/pose', + self.handle_turtle_pose, + 1) + +Now, we create a ``TransformStamped`` object and give it the appropriate metadata. + +#. We need to give the transform being published a timestamp, and we'll just stamp it with the current time by calling ``self.get_clock().now()``. + This will return the current time used by the ``Node``. + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world``. + +#. Finally, we need to set the name of the child node of the link we're creating, in this case this is the name of the turtle itself. + +The handler function for the turtle pose message broadcasts this turtle's translation and rotation, and publishes it as a transform from frame ``world`` to frame ``turtleX``. + +.. code-block:: python + + t = TransformStamped() + + # Read message content and assign it to + # corresponding tf variables + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = self.turtlename + +Here we copy the information from the 3D turtle pose into the 3D transform. + +.. code-block:: python + + # Turtle only exists in 2D, thus we get x and y translation + # coordinates from the message and set the z coordinate to 0 + t.transform.translation.x = msg.x + t.transform.translation.y = msg.y + t.transform.translation.z = 0.0 + + # For the same reason, turtle can only rotate around one axis + # and this why we set rotation in x and y to 0 and obtain + # rotation in z axis from the message + q = quaternion_from_euler(0, 0, msg.theta) + t.transform.rotation.x = q[0] + t.transform.rotation.y = q[1] + t.transform.rotation.z = q[2] + t.transform.rotation.w = q[3] + +Finally we take the transform that we constructed and pass it to the ``sendTransform`` method of the ``TransformBroadcaster`` that will take care of broadcasting. + +.. code-block:: python + + # Send the transformation + self.tf_broadcaster.sendTransform(t) + +1.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point +to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'turtle_tf2_broadcaster = learning_tf2_py.turtle_tf2_broadcaster:main', + +2 Write the launch file +^^^^^^^^^^^^^^^^^^^^^^^ + +Now create a launch file for this demo. +Create a ``launch`` folder in the ``src/learning_tf2_py`` directory. +With your text editor, create a new file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``launch`` folder, and add the following lines: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml + :language: xml + :name: turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml + :language: yaml + :name: turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.py + :language: python + :name: turtle_tf2_demo_launch.py + + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Let's examine the launch file structure. +Each format has its own way of setting up the launch file: + +.. tabs:: + + .. group-tab:: XML + + XML launch files start with an XML declaration and a root ```` element. + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml + :language: xml + :lines: 1-2 + + .. group-tab:: YAML + + YAML launch files start with a YAML version declaration and a ``launch:`` key. + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 1-3 + + .. group-tab:: Python + + In Python launch files, we first import required modules from the ``launch`` and ``launch_ros`` packages. + It should be noted that ``launch`` is a generic launching framework (not ROS 2 specific) and ``launch_ros`` has ROS 2 specific things, like nodes that we import here. + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.py + :language: python + :lines: 1-2 + +Now we run our nodes that start the turtlesim simulation and broadcast ``turtle1`` state to the tf2 using our ``turtle_tf2_broadcaster`` node. + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.xml + :language: xml + :lines: 3-6 + + .. group-tab:: YAML + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.yaml + :language: yaml + :lines: 4-9 + + .. group-tab:: Python + + .. literalinclude:: launch/py_turtle_tf2_demo_launch.py + :language: python + :lines: 5-20 + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files are located. + +Open ``package.xml`` with your text editor. +Add the following dependencies corresponding to your launch file's import statements: + +.. code-block:: xml + + launch + launch_ros + +This declares the additional required ``launch`` and ``launch_ros`` dependencies when its code is executed. + +Make sure to save the file. + +2.3 Update setup.py +~~~~~~~~~~~~~~~~~~~ + +Reopen ``setup.py`` and add the line so that the launch files from the ``launch/`` folder will be installed. +The ``data_files`` field should now look like this: + +.. code-block:: python + + data_files=[ + ... + (os.path.join('share', package_name, 'launch'), glob('launch/*')), + ], + +Also add the appropriate imports at the top of the file: + +.. code-block:: python + + import os + from glob import glob + +You can learn more about creating launch files in :doc:`this tutorial <../../../../Developer-Tools/Launch/Creating-Launch-Files>`. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + +4 Run +^^^^^ + +Now run the launch file that will start the turtlesim simulation node and ``turtle_tf2_broadcaster`` node: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py + +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +You will now see that the turtlesim simulation has started with one turtle that you can control. + +.. image:: images/turtlesim_broadcast.png + +Now, use the ``tf2_echo`` tool to check if the turtle pose is actually getting broadcast to tf2: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo world turtle1 + +This should show you the pose of the first turtle. +Drive around the turtle using the arrow keys (make sure your ``turtle_teleop_key`` terminal window is active, not your simulator window). +In your console output you will see something similar to this: + +.. code-block:: console + + At time 1714913843.708748879 + - Translation: [4.541, 3.889, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.999, -0.035] + - Rotation: in RPY (radian) [0.000, -0.000, -3.072] + - Rotation: in RPY (degree) [0.000, -0.000, -176.013] + - Matrix: + -0.998 0.070 0.000 4.541 + -0.070 -0.998 0.000 3.889 + 0.000 0.000 1.000 0.000 + 0.000 0.000 0.000 1.000 + +If you run ``tf2_echo`` for the transform between the ``world`` and ``turtle2``, you should not see a transform, because the second turtle is not there yet. +However, as soon as we add the second turtle in the next tutorial, the pose of ``turtle2`` will be broadcast to tf2. + +Summary +------- + +In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst index 5f724368f78..70f761a5250 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst @@ -1,415 +1,415 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Listener-Cpp - Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Cpp - -Writing a listener (C++) -======================== - -**Goal:** Learn how to use tf2 to get access to frame transformations. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. - -In this tutorial we'll create a tf2 listener to start using tf2. - -Prerequisites -------------- - -This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (C++) ` and the :doc:`tf2 broadcaster tutorial (C++) `. -In the previous tutorial, we created a ``learning_tf2_cpp`` package, which is where we will continue working from. - -Tasks ------ - -1 Write the listener node -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. -Inside the ``src`` directory download the example listener code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "geometry_msgs/msg/twist.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2/exceptions.hpp" - #include "tf2_ros/transform_listener.h" - #include "tf2_ros/buffer.h" - #include "turtlesim_msgs/srv/spawn.hpp" - - using namespace std::chrono_literals; - - class FrameListener : public rclcpp::Node - { - public: - FrameListener() - : Node("turtle_tf2_frame_listener"), - turtle_spawning_service_ready_(false), - turtle_spawned_(false) - { - // Declare and acquire `target_frame` parameter - target_frame_ = this->declare_parameter("target_frame", "turtle1"); - - tf_buffer_ = - std::make_unique(this->get_clock()); - tf_listener_ = - std::make_shared(*tf_buffer_); - - // Create a client to spawn a turtle - spawner_ = - this->create_client("spawn"); - - // Create turtle2 velocity publisher - publisher_ = - this->create_publisher("turtle2/cmd_vel", 1); - - // Call on_timer function every second - timer_ = this->create_wall_timer( - 1s, [this]() {return this->on_timer();}); - } - - private: - void on_timer() - { - // Store frame names in variables that will be used to - // compute transformations - std::string fromFrameRel = target_frame_.c_str(); - std::string toFrameRel = "turtle2"; - - if (turtle_spawning_service_ready_) { - if (turtle_spawned_) { - geometry_msgs::msg::TransformStamped t; - - // Look up for the transformation between target_frame and turtle2 frames - // and send velocity commands for turtle2 to reach target_frame - try { - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePointZero); - } catch (const tf2::TransformException & ex) { - RCLCPP_INFO( - this->get_logger(), "Could not transform %s to %s: %s", - toFrameRel.c_str(), fromFrameRel.c_str(), ex.what()); - return; - } - - geometry_msgs::msg::Twist msg; - - static const double scaleRotationRate = 1.0; - msg.angular.z = scaleRotationRate * atan2( - t.transform.translation.y, - t.transform.translation.x); - - static const double scaleForwardSpeed = 0.5; - msg.linear.x = scaleForwardSpeed * sqrt( - pow(t.transform.translation.x, 2) + - pow(t.transform.translation.y, 2)); - - publisher_->publish(msg); - } else { - RCLCPP_INFO(this->get_logger(), "Successfully spawned"); - turtle_spawned_ = true; - } - } else { - // Check if the service is ready - if (spawner_->service_is_ready()) { - // Initialize request with turtle name and coordinates - // Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn - auto request = std::make_shared(); - request->x = 4.0; - request->y = 2.0; - request->theta = 0.0; - request->name = "turtle2"; - - // Call request - using ServiceResponseFuture = - rclcpp::Client::SharedFuture; - auto response_received_callback = [this](ServiceResponseFuture future) { - auto result = future.get(); - if (strcmp(result->name.c_str(), "turtle2") == 0) { - turtle_spawning_service_ready_ = true; - } else { - RCLCPP_ERROR(this->get_logger(), "Service callback result mismatch"); - } - }; - auto result = spawner_->async_send_request(request, response_received_callback); - } else { - RCLCPP_INFO(this->get_logger(), "Service is not ready"); - } - } - } - - // Boolean values to store the information - // if the service for spawning turtle is available - bool turtle_spawning_service_ready_; - // if the turtle was successfully spawned - bool turtle_spawned_; - rclcpp::Client::SharedPtr spawner_{nullptr}; - rclcpp::TimerBase::SharedPtr timer_{nullptr}; - rclcpp::Publisher::SharedPtr publisher_{nullptr}; - std::shared_ptr tf_listener_{nullptr}; - std::unique_ptr tf_buffer_; - std::string target_frame_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (C++) <../Writing-A-Simple-Cpp-Service-And-Client>` tutorial. - -Now, let's take a look at the code that is relevant to get access to frame transformations. -The ``tf2_ros`` contains a ``TransformListener`` class that makes the task of receiving transforms easier. - -.. code-block:: C++ - - #include "tf2_ros/transform_listener.h" - -Here, we create a ``TransformListener`` object. -Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. - -.. code-block:: C++ - - tf_listener_ = - std::make_shared(*tf_buffer_); - -Finally, we query the listener for a specific transformation. -We call ``lookup_transform`` method with following arguments: - -#. Target frame - -#. Source frame - -#. The time at which we want to transform - -Providing ``tf2::TimePointZero`` will just get us the latest available transform. -All this is wrapped in a try-catch block to handle possible exceptions. - -.. code-block:: C++ - - t = tf_buffer_->lookupTransform( - toFrameRel, fromFrameRel, - tf2::TimePointZero); - -The resulting transformation represents the position and orientation of the target turtle relative to ``turtle2``. -The angle between the turtles is then used to calculate a velocity command to follow the target turtle. -For more general information about tf2 see also the :doc:`tf2 page in the Concepts section <../../../interfaces/About-Tf2/About-Tf2>`. - -1.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. - -Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_listener``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - add_executable(turtle_tf2_listener src/turtle_tf2_listener.cpp) - target_link_libraries( - turtle_tf2_listener PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2::tf2 - tf2_ros::tf2_ros - turtlesim_msgs::turtlesim_msgs - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - turtle_tf2_listener - DESTINATION lib/${PROJECT_NAME}) - -2 Update the launch file -^^^^^^^^^^^^^^^^^^^^^^^^ - -Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. -The resulting file should look like: - -.. tabs:: - - .. group-tab:: Python - - .. literalinclude:: launch/listener_cpp_launch.py - :language: python - - .. group-tab:: XML - - .. literalinclude:: launch/listener_cpp_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/listener_cpp_launch.yaml - :language: yaml - -This will declare a ``target_frame`` launch argument, start a broadcaster for the second turtle that we will spawn and a listener that will subscribe to those transformations. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - -4 Run -^^^^^ - -Now you're ready to start your full turtle demo: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py - -You should see the turtle sim with two turtles. -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! - -Summary -------- - -In this tutorial you learned how to use tf2 to get access to frame transformations. -You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. \ No newline at end of file +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Listener-Cpp + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Cpp + +Writing a listener (C++) +======================== + +**Goal:** Learn how to use tf2 to get access to frame transformations. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. + +In this tutorial we'll create a tf2 listener to start using tf2. + +Prerequisites +------------- + +This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (C++) ` and the :doc:`tf2 broadcaster tutorial (C++) `. +In the previous tutorial, we created a ``learning_tf2_cpp`` package, which is where we will continue working from. + +Tasks +----- + +1 Write the listener node +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_cpp`` package we created in the previous tutorial. +Inside the ``src`` directory download the example listener code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/turtle_tf2_listener.cpp -o turtle_tf2_listener.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "geometry_msgs/msg/twist.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2/exceptions.hpp" + #include "tf2_ros/transform_listener.h" + #include "tf2_ros/buffer.h" + #include "turtlesim_msgs/srv/spawn.hpp" + + using namespace std::chrono_literals; + + class FrameListener : public rclcpp::Node + { + public: + FrameListener() + : Node("turtle_tf2_frame_listener"), + turtle_spawning_service_ready_(false), + turtle_spawned_(false) + { + // Declare and acquire `target_frame` parameter + target_frame_ = this->declare_parameter("target_frame", "turtle1"); + + tf_buffer_ = + std::make_unique(this->get_clock()); + tf_listener_ = + std::make_shared(*tf_buffer_); + + // Create a client to spawn a turtle + spawner_ = + this->create_client("spawn"); + + // Create turtle2 velocity publisher + publisher_ = + this->create_publisher("turtle2/cmd_vel", 1); + + // Call on_timer function every second + timer_ = this->create_wall_timer( + 1s, [this]() {return this->on_timer();}); + } + + private: + void on_timer() + { + // Store frame names in variables that will be used to + // compute transformations + std::string fromFrameRel = target_frame_.c_str(); + std::string toFrameRel = "turtle2"; + + if (turtle_spawning_service_ready_) { + if (turtle_spawned_) { + geometry_msgs::msg::TransformStamped t; + + // Look up for the transformation between target_frame and turtle2 frames + // and send velocity commands for turtle2 to reach target_frame + try { + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePointZero); + } catch (const tf2::TransformException & ex) { + RCLCPP_INFO( + this->get_logger(), "Could not transform %s to %s: %s", + toFrameRel.c_str(), fromFrameRel.c_str(), ex.what()); + return; + } + + geometry_msgs::msg::Twist msg; + + static const double scaleRotationRate = 1.0; + msg.angular.z = scaleRotationRate * atan2( + t.transform.translation.y, + t.transform.translation.x); + + static const double scaleForwardSpeed = 0.5; + msg.linear.x = scaleForwardSpeed * sqrt( + pow(t.transform.translation.x, 2) + + pow(t.transform.translation.y, 2)); + + publisher_->publish(msg); + } else { + RCLCPP_INFO(this->get_logger(), "Successfully spawned"); + turtle_spawned_ = true; + } + } else { + // Check if the service is ready + if (spawner_->service_is_ready()) { + // Initialize request with turtle name and coordinates + // Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn + auto request = std::make_shared(); + request->x = 4.0; + request->y = 2.0; + request->theta = 0.0; + request->name = "turtle2"; + + // Call request + using ServiceResponseFuture = + rclcpp::Client::SharedFuture; + auto response_received_callback = [this](ServiceResponseFuture future) { + auto result = future.get(); + if (strcmp(result->name.c_str(), "turtle2") == 0) { + turtle_spawning_service_ready_ = true; + } else { + RCLCPP_ERROR(this->get_logger(), "Service callback result mismatch"); + } + }; + auto result = spawner_->async_send_request(request, response_received_callback); + } else { + RCLCPP_INFO(this->get_logger(), "Service is not ready"); + } + } + } + + // Boolean values to store the information + // if the service for spawning turtle is available + bool turtle_spawning_service_ready_; + // if the turtle was successfully spawned + bool turtle_spawned_; + rclcpp::Client::SharedPtr spawner_{nullptr}; + rclcpp::TimerBase::SharedPtr timer_{nullptr}; + rclcpp::Publisher::SharedPtr publisher_{nullptr}; + std::shared_ptr tf_listener_{nullptr}; + std::unique_ptr tf_buffer_; + std::string target_frame_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (C++) <../Writing-A-Simple-Cpp-Service-And-Client>` tutorial. + +Now, let's take a look at the code that is relevant to get access to frame transformations. +The ``tf2_ros`` contains a ``TransformListener`` class that makes the task of receiving transforms easier. + +.. code-block:: C++ + + #include "tf2_ros/transform_listener.h" + +Here, we create a ``TransformListener`` object. +Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. + +.. code-block:: C++ + + tf_listener_ = + std::make_shared(*tf_buffer_); + +Finally, we query the listener for a specific transformation. +We call ``lookup_transform`` method with following arguments: + +#. Target frame + +#. Source frame + +#. The time at which we want to transform + +Providing ``tf2::TimePointZero`` will just get us the latest available transform. +All this is wrapped in a try-catch block to handle possible exceptions. + +.. code-block:: C++ + + t = tf_buffer_->lookupTransform( + toFrameRel, fromFrameRel, + tf2::TimePointZero); + +The resulting transformation represents the position and orientation of the target turtle relative to ``turtle2``. +The angle between the turtles is then used to calculate a velocity command to follow the target turtle. +For more general information about tf2 see also the :doc:`tf2 page in the Concepts section <../../../interfaces/About-Tf2/About-Tf2>`. + +1.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files are located. + +Now open the ``CMakeLists.txt`` add the executable and name it ``turtle_tf2_listener``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + add_executable(turtle_tf2_listener src/turtle_tf2_listener.cpp) + target_link_libraries( + turtle_tf2_listener PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2::tf2 + tf2_ros::tf2_ros + turtlesim_msgs::turtlesim_msgs + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + turtle_tf2_listener + DESTINATION lib/${PROJECT_NAME}) + +2 Update the launch file +^^^^^^^^^^^^^^^^^^^^^^^^ + +Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_cpp/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. +The resulting file should look like: + +.. tabs:: + + .. group-tab:: Python + + .. literalinclude:: launch/listener_cpp_launch.py + :language: python + + .. group-tab:: XML + + .. literalinclude:: launch/listener_cpp_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/listener_cpp_launch.yaml + :language: yaml + +This will declare a ``target_frame`` launch argument, start a broadcaster for the second turtle that we will spawn and a listener that will subscribe to those transformations. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + +4 Run +^^^^^ + +Now you're ready to start your full turtle demo: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_cpp turtle_tf2_demo_launch.py + +You should see the turtle sim with two turtles. +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! + +Summary +------- + +In this tutorial you learned how to use tf2 to get access to frame transformations. +You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst index 48bc8933d31..ebb3eacb191 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst @@ -1,369 +1,369 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Listener-Py - Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Py - -Writing a listener (Python) -=========================== - -**Goal:** Learn how to use tf2 to get access to frame transformations. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. - -In this tutorial we'll create a tf2 listener to start using tf2. - -Prerequisites -------------- - -This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (Python) ` and :doc:`tf2 broadcaster tutorial (Python) `. -In the previous tutorial, we created a ``learning_tf2_py`` package, which is where we will continue working from. - -Tasks ------ - -1 Write the listener node -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Go to the ``learning_tf2_py`` package we created in the previous tutorial. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example listener code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py - -Now open the file called ``turtle_tf2_listener.py`` using your preferred text editor. - -.. code-block:: python - - import math - - from geometry_msgs.msg import Twist - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros import TransformException - from tf2_ros.buffer import Buffer - from tf2_ros.transform_listener import TransformListener - - from turtlesim_msgs.srv import Spawn - - - class FrameListener(Node): - - def __init__(self): - super().__init__('turtle_tf2_frame_listener') - - # Declare and acquire `target_frame` parameter - self.target_frame = self.declare_parameter( - 'target_frame', 'turtle1').get_parameter_value().string_value - - self.tf_buffer = Buffer() - self.tf_listener = TransformListener(self.tf_buffer, self) - - # Create a client to spawn a turtle - self.spawner = self.create_client(Spawn, 'spawn') - # Boolean values to store the information - # if the service for spawning turtle is available - self.turtle_spawning_service_ready = False - # if the turtle was successfully spawned - self.turtle_spawned = False - - # Create turtle2 velocity publisher - self.publisher = self.create_publisher(Twist, 'turtle2/cmd_vel', 1) - - # Call on_timer function every second - self.timer = self.create_timer(1.0, self.on_timer) - - def on_timer(self): - # Store frame names in variables that will be used to - # compute transformations - from_frame_rel = self.target_frame - to_frame_rel = 'turtle2' - - if self.turtle_spawning_service_ready: - if self.turtle_spawned: - # Look up for the transformation between target_frame and turtle2 frames - # and send velocity commands for turtle2 to reach target_frame - try: - t = self.tf_buffer.lookup_transform( - to_frame_rel, - from_frame_rel, - rclpy.time.Time()) - except TransformException as ex: - self.get_logger().info( - f'Could not transform {to_frame_rel} to {from_frame_rel}: {ex}') - return - - msg = Twist() - scale_rotation_rate = 1.0 - msg.angular.z = scale_rotation_rate * math.atan2( - t.transform.translation.y, - t.transform.translation.x) - - scale_forward_speed = 0.5 - msg.linear.x = scale_forward_speed * math.sqrt( - t.transform.translation.x ** 2 + - t.transform.translation.y ** 2) - - self.publisher.publish(msg) - else: - if self.result.done(): - self.get_logger().info( - f'Successfully spawned {self.result.result().name}') - self.turtle_spawned = True - else: - self.get_logger().info('Spawn is not finished') - else: - if self.spawner.service_is_ready(): - # Initialize request with turtle name and coordinates - # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn - request = Spawn.Request() - request.name = 'turtle2' - request.x = float(4) - request.y = float(2) - request.theta = float(0) - # Call request - self.result = self.spawner.call_async(request) - self.turtle_spawning_service_ready = True - else: - # Check if the service is ready - self.get_logger().info('Service is not ready') - - - def main(): - try: - with rclpy.init(): - node = FrameListener() - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -1.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (Python) <../Writing-A-Simple-Py-Service-And-Client>` tutorial. - -Now, let's take a look at the code that is relevant to get access to frame transformations. -The ``tf2_ros`` package provides an implementation of a ``TransformListener`` to help make the task of receiving transforms easier. - -.. code-block:: python - - from tf2_ros.transform_listener import TransformListener - -Here, we create a ``TransformListener`` object. -Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. - -.. code-block:: python - - self.tf_listener = TransformListener(self.tf_buffer, self) - -Finally, we query the listener for a specific transformation. -We call ``lookup_transform`` method with following arguments: - -#. Target frame - -#. Source frame - -#. The time at which we want to transform - -Providing ``rclpy.time.Time()`` will just get us the latest available transform. -All this is wrapped in a try-except block to handle possible exceptions. - -.. code-block:: python - - t = self.tf_buffer.lookup_transform( - to_frame_rel, - from_frame_rel, - rclpy.time.Time()) - -1.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'turtle_tf2_listener = learning_tf2_py.turtle_tf2_listener:main', - -2 Update the launch file -^^^^^^^^^^^^^^^^^^^^^^^^ - -Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. -The resulting file should look like: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/listener_py_launch.xml - :language: xml - :name: turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. literalinclude:: launch/listener_py_launch.yaml - :language: yaml - :name: turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. literalinclude:: launch/listener_py_launch.py - :language: python - :name: turtle_tf2_demo_launch.py - -This will declare a ``target_frame`` launch argument, start a broadcaster for second turtle that we will spawn and listener that will subscribe to those transformations. - -3 Build -^^^^^^^ - -Run ``rosdep`` in the root of your workspace to check for missing dependencies. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - - -4 Run -^^^^^ - -Now you're ready to start your full turtle demo: - -.. tabs:: - - .. group-tab:: XML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml - - .. group-tab:: YAML - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml - - .. group-tab:: Python - - .. code-block:: console - - $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py - -You should see the turtle sim with two turtles. -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! - -Summary -------- - -In this tutorial you learned how to use tf2 to get access to frame transformations. -You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. \ No newline at end of file +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Listener-Py + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Listener-Py + +Writing a listener (Python) +=========================== + +**Goal:** Learn how to use tf2 to get access to frame transformations. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In previous tutorials we created a tf2 broadcaster to publish the pose of a turtle to tf2. + +In this tutorial we'll create a tf2 listener to start using tf2. + +Prerequisites +------------- + +This tutorial assumes you have completed the :doc:`tf2 static broadcaster tutorial (Python) ` and :doc:`tf2 broadcaster tutorial (Python) `. +In the previous tutorial, we created a ``learning_tf2_py`` package, which is where we will continue working from. + +Tasks +----- + +1 Write the listener node +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Go to the ``learning_tf2_py`` package we created in the previous tutorial. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example listener code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/turtle_tf2_listener.py -o turtle_tf2_listener.py + +Now open the file called ``turtle_tf2_listener.py`` using your preferred text editor. + +.. code-block:: python + + import math + + from geometry_msgs.msg import Twist + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros import TransformException + from tf2_ros.buffer import Buffer + from tf2_ros.transform_listener import TransformListener + + from turtlesim_msgs.srv import Spawn + + + class FrameListener(Node): + + def __init__(self): + super().__init__('turtle_tf2_frame_listener') + + # Declare and acquire `target_frame` parameter + self.target_frame = self.declare_parameter( + 'target_frame', 'turtle1').get_parameter_value().string_value + + self.tf_buffer = Buffer() + self.tf_listener = TransformListener(self.tf_buffer, self) + + # Create a client to spawn a turtle + self.spawner = self.create_client(Spawn, 'spawn') + # Boolean values to store the information + # if the service for spawning turtle is available + self.turtle_spawning_service_ready = False + # if the turtle was successfully spawned + self.turtle_spawned = False + + # Create turtle2 velocity publisher + self.publisher = self.create_publisher(Twist, 'turtle2/cmd_vel', 1) + + # Call on_timer function every second + self.timer = self.create_timer(1.0, self.on_timer) + + def on_timer(self): + # Store frame names in variables that will be used to + # compute transformations + from_frame_rel = self.target_frame + to_frame_rel = 'turtle2' + + if self.turtle_spawning_service_ready: + if self.turtle_spawned: + # Look up for the transformation between target_frame and turtle2 frames + # and send velocity commands for turtle2 to reach target_frame + try: + t = self.tf_buffer.lookup_transform( + to_frame_rel, + from_frame_rel, + rclpy.time.Time()) + except TransformException as ex: + self.get_logger().info( + f'Could not transform {to_frame_rel} to {from_frame_rel}: {ex}') + return + + msg = Twist() + scale_rotation_rate = 1.0 + msg.angular.z = scale_rotation_rate * math.atan2( + t.transform.translation.y, + t.transform.translation.x) + + scale_forward_speed = 0.5 + msg.linear.x = scale_forward_speed * math.sqrt( + t.transform.translation.x ** 2 + + t.transform.translation.y ** 2) + + self.publisher.publish(msg) + else: + if self.result.done(): + self.get_logger().info( + f'Successfully spawned {self.result.result().name}') + self.turtle_spawned = True + else: + self.get_logger().info('Spawn is not finished') + else: + if self.spawner.service_is_ready(): + # Initialize request with turtle name and coordinates + # Note that x, y and theta are defined as floats in turtlesim_msgs/srv/Spawn + request = Spawn.Request() + request.name = 'turtle2' + request.x = float(4) + request.y = float(2) + request.theta = float(0) + # Call request + self.result = self.spawner.call_async(request) + self.turtle_spawning_service_ready = True + else: + # Check if the service is ready + self.get_logger().info('Service is not ready') + + + def main(): + try: + with rclpy.init(): + node = FrameListener() + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +1.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +To understand how the service behind spawning turtle works, please refer to :doc:`writing a simple service and client (Python) <../Writing-A-Simple-Py-Service-And-Client>` tutorial. + +Now, let's take a look at the code that is relevant to get access to frame transformations. +The ``tf2_ros`` package provides an implementation of a ``TransformListener`` to help make the task of receiving transforms easier. + +.. code-block:: python + + from tf2_ros.transform_listener import TransformListener + +Here, we create a ``TransformListener`` object. +Once the listener is created, it starts receiving tf2 transformations over the wire, and buffers them for up to 10 seconds. + +.. code-block:: python + + self.tf_listener = TransformListener(self.tf_buffer, self) + +Finally, we query the listener for a specific transformation. +We call ``lookup_transform`` method with following arguments: + +#. Target frame + +#. Source frame + +#. The time at which we want to transform + +Providing ``rclpy.time.Time()`` will just get us the latest available transform. +All this is wrapped in a try-except block to handle possible exceptions. + +.. code-block:: python + + t = self.tf_buffer.lookup_transform( + to_frame_rel, + from_frame_rel, + rclpy.time.Time()) + +1.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'turtle_tf2_listener = learning_tf2_py.turtle_tf2_listener:main', + +2 Update the launch file +^^^^^^^^^^^^^^^^^^^^^^^^ + +Open the launch file called ``turtle_tf2_demo_launch`` with extension ``.py``, ``.xml``, or ``.yaml`` in the ``src/learning_tf2_py/launch`` directory with your text editor, add two new nodes to the launch description, add a launch argument, and add the imports. +The resulting file should look like: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/listener_py_launch.xml + :language: xml + :name: turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. literalinclude:: launch/listener_py_launch.yaml + :language: yaml + :name: turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. literalinclude:: launch/listener_py_launch.py + :language: python + :name: turtle_tf2_demo_launch.py + +This will declare a ``target_frame`` launch argument, start a broadcaster for second turtle that we will spawn and listener that will subscribe to those transformations. + +3 Build +^^^^^^^ + +Run ``rosdep`` in the root of your workspace to check for missing dependencies. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + + +4 Run +^^^^^ + +Now you're ready to start your full turtle demo: + +.. tabs:: + + .. group-tab:: XML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.xml + + .. group-tab:: YAML + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.yaml + + .. group-tab:: Python + + .. code-block:: console + + $ ros2 launch learning_tf2_py turtle_tf2_demo_launch.py + +You should see the turtle sim with two turtles. +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +To see if things work, simply drive around the first turtle using the arrow keys (make sure your terminal window is active, not your simulator window), and you'll see the second turtle following the first one! + +Summary +------- + +In this tutorial you learned how to use tf2 to get access to frame transformations. +You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst index 25be3f8fbb5..90d8cc9fd41 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst @@ -1,440 +1,440 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp - Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp - -Writing a static broadcaster (C++) -================================== - -**Goal:** Learn how to broadcast static coordinate frames to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. -For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. - -This is a standalone tutorial covering the basics of static transforms, which consists of two parts. -In the first part we will write code to publish static transforms to tf2. -In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First we will create a package that will be used for this tutorial and the following ones. -The package called ``learning_tf2_cpp`` will depend on ``geometry_msgs``, ``rclcpp``, ``tf2``, ``tf2_ros``, and ``turtlesim``. -Code for this tutorial is stored `here `_. - -Open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. -Navigate to workspace's ``src`` folder and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies geometry_msgs rclcpp tf2 tf2_ros turtlesim -- learning_tf2_cpp - -Your terminal will return a message verifying the creation of your package ``learning_tf2_cpp`` and all its necessary files and folders. - -2 Write the static broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Inside the ``src/learning_tf2_cpp/src`` directory download the example static broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp - -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - - #include "geometry_msgs/msg/transform_stamped.hpp" - #include "rclcpp/rclcpp.hpp" - #include "tf2/LinearMath/Quaternion.hpp" - #include "tf2_ros/static_transform_broadcaster.h" - - class StaticFramePublisher : public rclcpp::Node - { - public: - explicit StaticFramePublisher(char * transformation[]) - : Node("static_turtle_tf2_broadcaster") - { - tf_static_broadcaster_ = std::make_shared(this); - - // Publish static transforms once at startup - this->make_transforms(transformation); - } - - private: - void make_transforms(char * transformation[]) - { - geometry_msgs::msg::TransformStamped t; - - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = transformation[1]; - - t.transform.translation.x = atof(transformation[2]); - t.transform.translation.y = atof(transformation[3]); - t.transform.translation.z = atof(transformation[4]); - tf2::Quaternion q; - q.setRPY( - atof(transformation[5]), - atof(transformation[6]), - atof(transformation[7])); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - - tf_static_broadcaster_->sendTransform(t); - } - - std::shared_ptr tf_static_broadcaster_; - }; - - int main(int argc, char * argv[]) - { - auto logger = rclcpp::get_logger("logger"); - - // Obtain parameters from command line arguments - if (argc != 8) { - RCLCPP_INFO( - logger, "Invalid number of parameters\nusage: " - "$ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster " - "child_frame_name x y z roll pitch yaw"); - return 1; - } - - // As the parent frame of the transform is `world`, it is - // necessary to check that the frame name passed is different - if (strcmp(argv[1], "world") == 0) { - RCLCPP_INFO(logger, "Your static turtle name cannot be 'world'"); - return 1; - } - - // Pass parameters and initialize node - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared(argv)); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now let's look at the code that is relevant to publishing the static turtle pose to tf2. -The first lines include the required header files. -First we include ``geometry_msgs/msg/transform_stamped.hpp`` to access the ``TransformStamped`` message type, which we will publish to the transformation tree. - -.. code-block:: C++ - - #include "geometry_msgs/msg/transform_stamped.hpp" - -Afterward, ``rclcpp`` is included so its ``rclcpp::Node`` class can be used. - -.. code-block:: C++ - - #include "rclcpp/rclcpp.hpp" - -``tf2::Quaternion`` is a class for a quaternion that provides convenient functions for converting Euler angles to quaternions and vice versa. -We also include ``tf2_ros/static_transform_broadcaster.h`` to use the ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. - -.. code-block:: C++ - - #include "tf2/LinearMath/Quaternion.hpp" - #include "tf2_ros/static_transform_broadcaster.h" - -The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. -Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. - -.. code-block:: C++ - - tf_static_broadcaster_ = std::make_shared(this); - - this->make_transforms(transformation); - -Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. -Before passing the actual transform values we need to give it the appropriate metadata. - -#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``this->get_clock()->now()`` - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` - -#. Finally, we need to set the name of the child frame of the link we're creating - -.. code-block:: C++ - - geometry_msgs::msg::TransformStamped t; - - t.header.stamp = this->get_clock()->now(); - t.header.frame_id = "world"; - t.child_frame_id = transformation[1]; - -Here we populate the 6D pose (translation and rotation) of the turtle. - -.. code-block:: C++ - - t.transform.translation.x = atof(transformation[2]); - t.transform.translation.y = atof(transformation[3]); - t.transform.translation.z = atof(transformation[4]); - tf2::Quaternion q; - q.setRPY( - atof(transformation[5]), - atof(transformation[6]), - atof(transformation[7])); - t.transform.rotation.x = q.x(); - t.transform.rotation.y = q.y(); - t.transform.rotation.z = q.z(); - t.transform.rotation.w = q.w(); - -Finally, we broadcast static transform using the ``sendTransform()`` function. - -.. code-block:: C++ - - tf_static_broadcaster_->sendTransform(t); - -2.2 Update package.xml -~~~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``src/learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`Create a package <../Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Learning tf2 with rclcpp - Your Name - Apache-2.0 - -Make sure to save the file. - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Add the executable to the CMakeLists.txt and name it ``static_turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. - -.. code-block:: console - - add_executable(static_turtle_tf2_broadcaster src/static_turtle_tf2_broadcaster.cpp) - target_link_libraries( - static_turtle_tf2_broadcaster PUBLIC - geometry_msgs::geometry_msgs - rclcpp::rclcpp - tf2::tf2 - tf2_ros::tf2_ros - ) - -Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: - -.. code-block:: console - - install(TARGETS - static_turtle_tf2_broadcaster - DESTINATION lib/${PROJECT_NAME}) - -3 Build -^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_cpp - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - - -4 Run -^^^^^ - -Now run the ``static_turtle_tf2_broadcaster`` node: - -.. code-block:: console - - $ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 - -This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. - -We can now check that the static transform has been published by echoing the ``tf_static`` topic. -If everything is well you should see a single static transform: - -.. code-block:: console - - $ ros2 topic echo /tf_static - transforms: - - header: - stamp: - sec: 1622908754 - nanosec: 208515730 - frame_id: world - child_frame_id: mystaticturtle - transform: - translation: - x: 0.0 - y: 0.0 - z: 1.0 - rotation: - x: 0.0 - y: 0.0 - z: 0.0 - w: 1.0 - -The proper way to publish static transforms -------------------------------------------- - -This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. -In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. -``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. - -The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. -In ROS 2, roll/pitch/yaw refers to rotation about the x/y/z-axis, respectively. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle - -The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle - -``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. -For example: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/static_transform_publisher_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/static_transform_publisher_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/static_transform_publisher_launch.py - :language: python - -Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. - -Summary -------- - -In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. -In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp + +Writing a static broadcaster (C++) +================================== + +**Goal:** Learn how to broadcast static coordinate frames to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. +For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. + +This is a standalone tutorial covering the basics of static transforms, which consists of two parts. +In the first part we will write code to publish static transforms to tf2. +In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First we will create a package that will be used for this tutorial and the following ones. +The package called ``learning_tf2_cpp`` will depend on ``geometry_msgs``, ``rclcpp``, ``tf2``, ``tf2_ros``, and ``turtlesim``. +Code for this tutorial is stored `here `_. + +Open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Navigate to workspace's ``src`` folder and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 --dependencies geometry_msgs rclcpp tf2 tf2_ros turtlesim -- learning_tf2_cpp + +Your terminal will return a message verifying the creation of your package ``learning_tf2_cpp`` and all its necessary files and folders. + +2 Write the static broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Inside the ``src/learning_tf2_cpp/src`` directory download the example static broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_cpp/src/static_turtle_tf2_broadcaster.cpp -o static_turtle_tf2_broadcaster.cpp + +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + + #include "geometry_msgs/msg/transform_stamped.hpp" + #include "rclcpp/rclcpp.hpp" + #include "tf2/LinearMath/Quaternion.hpp" + #include "tf2_ros/static_transform_broadcaster.h" + + class StaticFramePublisher : public rclcpp::Node + { + public: + explicit StaticFramePublisher(char * transformation[]) + : Node("static_turtle_tf2_broadcaster") + { + tf_static_broadcaster_ = std::make_shared(this); + + // Publish static transforms once at startup + this->make_transforms(transformation); + } + + private: + void make_transforms(char * transformation[]) + { + geometry_msgs::msg::TransformStamped t; + + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = transformation[1]; + + t.transform.translation.x = atof(transformation[2]); + t.transform.translation.y = atof(transformation[3]); + t.transform.translation.z = atof(transformation[4]); + tf2::Quaternion q; + q.setRPY( + atof(transformation[5]), + atof(transformation[6]), + atof(transformation[7])); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + + tf_static_broadcaster_->sendTransform(t); + } + + std::shared_ptr tf_static_broadcaster_; + }; + + int main(int argc, char * argv[]) + { + auto logger = rclcpp::get_logger("logger"); + + // Obtain parameters from command line arguments + if (argc != 8) { + RCLCPP_INFO( + logger, "Invalid number of parameters\nusage: " + "$ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster " + "child_frame_name x y z roll pitch yaw"); + return 1; + } + + // As the parent frame of the transform is `world`, it is + // necessary to check that the frame name passed is different + if (strcmp(argv[1], "world") == 0) { + RCLCPP_INFO(logger, "Your static turtle name cannot be 'world'"); + return 1; + } + + // Pass parameters and initialize node + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared(argv)); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now let's look at the code that is relevant to publishing the static turtle pose to tf2. +The first lines include the required header files. +First we include ``geometry_msgs/msg/transform_stamped.hpp`` to access the ``TransformStamped`` message type, which we will publish to the transformation tree. + +.. code-block:: C++ + + #include "geometry_msgs/msg/transform_stamped.hpp" + +Afterward, ``rclcpp`` is included so its ``rclcpp::Node`` class can be used. + +.. code-block:: C++ + + #include "rclcpp/rclcpp.hpp" + +``tf2::Quaternion`` is a class for a quaternion that provides convenient functions for converting Euler angles to quaternions and vice versa. +We also include ``tf2_ros/static_transform_broadcaster.h`` to use the ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. + +.. code-block:: C++ + + #include "tf2/LinearMath/Quaternion.hpp" + #include "tf2_ros/static_transform_broadcaster.h" + +The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. +Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. + +.. code-block:: C++ + + tf_static_broadcaster_ = std::make_shared(this); + + this->make_transforms(transformation); + +Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. +Before passing the actual transform values we need to give it the appropriate metadata. + +#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``this->get_clock()->now()`` + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` + +#. Finally, we need to set the name of the child frame of the link we're creating + +.. code-block:: C++ + + geometry_msgs::msg::TransformStamped t; + + t.header.stamp = this->get_clock()->now(); + t.header.frame_id = "world"; + t.child_frame_id = transformation[1]; + +Here we populate the 6D pose (translation and rotation) of the turtle. + +.. code-block:: C++ + + t.transform.translation.x = atof(transformation[2]); + t.transform.translation.y = atof(transformation[3]); + t.transform.translation.z = atof(transformation[4]); + tf2::Quaternion q; + q.setRPY( + atof(transformation[5]), + atof(transformation[6]), + atof(transformation[7])); + t.transform.rotation.x = q.x(); + t.transform.rotation.y = q.y(); + t.transform.rotation.z = q.z(); + t.transform.rotation.w = q.w(); + +Finally, we broadcast static transform using the ``sendTransform()`` function. + +.. code-block:: C++ + + tf_static_broadcaster_->sendTransform(t); + +2.2 Update package.xml +~~~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``src/learning_tf2_cpp`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`Create a package <../Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Learning tf2 with rclcpp + Your Name + Apache-2.0 + +Make sure to save the file. + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Add the executable to the CMakeLists.txt and name it ``static_turtle_tf2_broadcaster``, which you'll use later with ``ros2 run``. + +.. code-block:: console + + add_executable(static_turtle_tf2_broadcaster src/static_turtle_tf2_broadcaster.cpp) + target_link_libraries( + static_turtle_tf2_broadcaster PUBLIC + geometry_msgs::geometry_msgs + rclcpp::rclcpp + tf2::tf2 + tf2_ros::tf2_ros + ) + +Finally, add the ``install(TARGETS…)`` section so ``ros2 run`` can find your executable: + +.. code-block:: console + + install(TARGETS + static_turtle_tf2_broadcaster + DESTINATION lib/${PROJECT_NAME}) + +3 Build +^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_cpp + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + + +4 Run +^^^^^ + +Now run the ``static_turtle_tf2_broadcaster`` node: + +.. code-block:: console + + $ ros2 run learning_tf2_cpp static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 + +This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. + +We can now check that the static transform has been published by echoing the ``tf_static`` topic. +If everything is well you should see a single static transform: + +.. code-block:: console + + $ ros2 topic echo /tf_static + transforms: + - header: + stamp: + sec: 1622908754 + nanosec: 208515730 + frame_id: world + child_frame_id: mystaticturtle + transform: + translation: + x: 0.0 + y: 0.0 + z: 1.0 + rotation: + x: 0.0 + y: 0.0 + z: 0.0 + w: 1.0 + +The proper way to publish static transforms +------------------------------------------- + +This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. +In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. +``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. + +The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. +In ROS 2, roll/pitch/yaw refers to rotation about the x/y/z-axis, respectively. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle + +The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle + +``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. +For example: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/static_transform_publisher_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/static_transform_publisher_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/static_transform_publisher_launch.py + :language: python + +Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. + +Summary +------- + +In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. +In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst index f431b90cd22..2919b7ceaa9 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst @@ -1,459 +1,459 @@ -.. redirect-from:: - - Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Py - Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Py - -Writing a static broadcaster (Python) -===================================== - -**Goal:** Learn how to broadcast static coordinate frames to tf2. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. -For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. - -This is a standalone tutorial covering the basics of static transforms, which consists of two parts. -In the first part we will write code to publish static transforms to tf2. -In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. - -In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2>` tutorial. -After that, the following tutorials focus on extending the demo with more advanced tf2 features. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -First we will create a package that will be used for this tutorial and the following ones. -The package called ``learning_tf2_py`` will depend on ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs``. -Code for this tutorial is stored `here `_. - -Open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. -Navigate to workspace's ``src`` folder and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 -- learning_tf2_py - -Your terminal will return a message verifying the creation of your package ``learning_tf2_py`` and all its necessary files and folders. - -2 Write the static broadcaster node -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's first create the source files. -Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example static broadcaster code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py - -Now open the file called ``static_turtle_tf2_broadcaster.py`` using your preferred text editor. - -.. code-block:: python - - import math - import sys - - from geometry_msgs.msg import TransformStamped - - import numpy as np - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster - - - def quaternion_from_euler(ai, aj, ak): - ai /= 2.0 - aj /= 2.0 - ak /= 2.0 - ci = math.cos(ai) - si = math.sin(ai) - cj = math.cos(aj) - sj = math.sin(aj) - ck = math.cos(ak) - sk = math.sin(ak) - cc = ci*ck - cs = ci*sk - sc = si*ck - ss = si*sk - - q = np.empty((4, )) - q[0] = cj*sc - sj*cs - q[1] = cj*ss + sj*cc - q[2] = cj*cs - sj*sc - q[3] = cj*cc + sj*ss - - return q - - - class StaticFramePublisher(Node): - """ - Broadcast transforms that never change. - - This example publishes transforms from `world` to a static turtle frame. - The transforms are only published once at startup, and are constant for all - time. - """ - - def __init__(self, transformation): - super().__init__('static_turtle_tf2_broadcaster') - - self.tf_static_broadcaster = StaticTransformBroadcaster(self) - - # Publish static transforms once at startup - self.make_transforms(transformation) - - def make_transforms(self, transformation): - t = TransformStamped() - - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = transformation[1] - - t.transform.translation.x = float(transformation[2]) - t.transform.translation.y = float(transformation[3]) - t.transform.translation.z = float(transformation[4]) - quat = quaternion_from_euler( - float(transformation[5]), float(transformation[6]), float(transformation[7])) - t.transform.rotation.x = quat[0] - t.transform.rotation.y = quat[1] - t.transform.rotation.z = quat[2] - t.transform.rotation.w = quat[3] - - self.tf_static_broadcaster.sendTransform(t) - - - def main(): - try: - logger = rclpy.logging.get_logger('logger') - - # obtain parameters from command line arguments - if len(sys.argv) != 8: - logger.info('Invalid number of parameters. Usage: \n' - '$ ros2 run learning_tf2_py static_turtle_tf2_broadcaster' - 'child_frame_name x y z roll pitch yaw') - sys.exit(1) - - if sys.argv[1] == 'world': - logger.info('Your static turtle name cannot be "world"') - sys.exit(2) - - # pass parameters and initialize node - with rclpy.init(): - node = StaticFramePublisher(sys.argv) - rclpy.spin(node) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Now let's look at the code that is relevant to publishing the static turtle pose to tf2. -The first lines import required packages. -First we import the ``TransformStamped`` from the ``geometry_msgs``, which provides us a template for the message that we will publish to the transformation tree. - -.. code-block:: python - - from geometry_msgs.msg import TransformStamped - -Afterward, ``rclpy`` is imported so its ``Node`` class can be used. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The ``tf2_ros`` package provides a ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. -To use the ``StaticTransformBroadcaster``, we need to import it from the ``tf2_ros`` module. - -.. code-block:: python - - from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster - -The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. -Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. - -.. code-block:: python - - self.tf_static_broadcaster = StaticTransformBroadcaster(self) - self.make_transforms(transformation) - -Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. -Before passing the actual transform values we need to give it the appropriate metadata. - -#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``self.get_clock().now()`` - -#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` - -#. Finally, we need to set the name of the child frame of the link we're creating - -.. code-block:: python - - t = TransformStamped() - - t.header.stamp = self.get_clock().now().to_msg() - t.header.frame_id = 'world' - t.child_frame_id = transformation[1] - -Here we populate the 6D pose (translation and rotation) of the turtle. - -.. code-block:: python - - t.transform.translation.x = float(transformation[2]) - t.transform.translation.y = float(transformation[3]) - t.transform.translation.z = float(transformation[4]) - quat = quaternion_from_euler( - float(transformation[5]), float(transformation[6]), float(transformation[7])) - t.transform.rotation.x = quat[0] - t.transform.rotation.y = quat[1] - t.transform.rotation.z = quat[2] - t.transform.rotation.w = quat[3] - -Finally, we broadcast static transform using the ``sendTransform()`` function. - -.. code-block:: python - - self.tf_static_broadcaster.sendTransform(t) - -2.2 Update package.xml -~~~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``src/learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`Create a package <../Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Learning tf2 with rclpy - Your Name - Apache-2.0 - -After the lines above, add the following dependencies corresponding to your node's import statements: - -.. code-block:: xml - - geometry_msgs - python3-numpy - rclpy - tf2_ros_py - turtlesim_msgs - -This declares the required ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs`` dependencies when its code is executed. - -Make sure to save the file. - -2.3 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'static_turtle_tf2_broadcaster = learning_tf2_py.static_turtle_tf2_broadcaster:main', - -3 Build -^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - - .. group-tab:: Windows - - rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself - -Still in the root of your workspace, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select learning_tf2_py - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select learning_tf2_py - -Open a new terminal, navigate to the root of your workspace, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ call install\setup.bat - - Or in powershell: - - .. code-block:: console - - $ .\install\setup.ps1 - - - -4 Run -^^^^^ - -Now run the ``static_turtle_tf2_broadcaster`` node: - -.. code-block:: console - - $ ros2 run learning_tf2_py static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 - -This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. - -We can now check that the static transform has been published by echoing the ``tf_static`` topic -If everything is well you should see a single static transform: - -.. code-block:: console - - $ ros2 topic echo /tf_static - transforms: - - header: - stamp: - sec: 1622908754 - nanosec: 208515730 - frame_id: world - child_frame_id: mystaticturtle - transform: - translation: - x: 0.0 - y: 0.0 - z: 1.0 - rotation: - x: 0.0 - y: 0.0 - z: 0.0 - w: 1.0 - -The proper way to publish static transforms -------------------------------------------- - -This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. -In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. -``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. - -The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. -In ROS 2, roll/pitch/yaw refers to rotation in radians about the x/y/z-axis, respectively. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle - -The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. - -.. code-block:: console - - $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle - -``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. -For example: - -.. tabs:: - - .. group-tab:: XML - - .. literalinclude:: launch/static_transform_publisher_launch.xml - :language: xml - - .. group-tab:: YAML - - .. literalinclude:: launch/static_transform_publisher_launch.yaml - :language: yaml - - .. group-tab:: Python - - .. literalinclude:: launch/static_transform_publisher_launch.py - :language: python - -Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. - -Summary -------- - -In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. -In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. +.. redirect-from:: + + Tutorials/Tf2/Writing-A-Tf2-Static-Broadcaster-Py + Tutorials/Intermediate/Tf2/Writing-A-Tf2-Static-Broadcaster-Py + +Writing a static broadcaster (Python) +===================================== + +**Goal:** Learn how to broadcast static coordinate frames to tf2. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Publishing static transforms is useful to define the relationship between a robot base and its sensors or non-moving parts. +For example, it is easiest to reason about laser scan measurements in a frame at the center of the laser scanner. + +This is a standalone tutorial covering the basics of static transforms, which consists of two parts. +In the first part we will write code to publish static transforms to tf2. +In the second part we will explain how to use the commandline ``static_transform_publisher`` executable tool in ``tf2_ros``. + +In the next two tutorials we will write the code to reproduce the demo from the :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. +After that, the following tutorials focus on extending the demo with more advanced tf2 features. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace <../Creating-A-Workspace/Creating-A-Workspace>` and :doc:`create a package <../Creating-Your-First-ROS2-Package>`. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +First we will create a package that will be used for this tutorial and the following ones. +The package called ``learning_tf2_py`` will depend on ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs``. +Code for this tutorial is stored `here `_. + +Open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Navigate to workspace's ``src`` folder and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 -- learning_tf2_py + +Your terminal will return a message verifying the creation of your package ``learning_tf2_py`` and all its necessary files and folders. + +2 Write the static broadcaster node +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's first create the source files. +Inside the ``src/learning_tf2_py/learning_tf2_py`` directory download the example static broadcaster code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros/geometry_tutorials/{DISTRO}/turtle_tf2_py/turtle_tf2_py/static_turtle_tf2_broadcaster.py -o static_turtle_tf2_broadcaster.py + +Now open the file called ``static_turtle_tf2_broadcaster.py`` using your preferred text editor. + +.. code-block:: python + + import math + import sys + + from geometry_msgs.msg import TransformStamped + + import numpy as np + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster + + + def quaternion_from_euler(ai, aj, ak): + ai /= 2.0 + aj /= 2.0 + ak /= 2.0 + ci = math.cos(ai) + si = math.sin(ai) + cj = math.cos(aj) + sj = math.sin(aj) + ck = math.cos(ak) + sk = math.sin(ak) + cc = ci*ck + cs = ci*sk + sc = si*ck + ss = si*sk + + q = np.empty((4, )) + q[0] = cj*sc - sj*cs + q[1] = cj*ss + sj*cc + q[2] = cj*cs - sj*sc + q[3] = cj*cc + sj*ss + + return q + + + class StaticFramePublisher(Node): + """ + Broadcast transforms that never change. + + This example publishes transforms from `world` to a static turtle frame. + The transforms are only published once at startup, and are constant for all + time. + """ + + def __init__(self, transformation): + super().__init__('static_turtle_tf2_broadcaster') + + self.tf_static_broadcaster = StaticTransformBroadcaster(self) + + # Publish static transforms once at startup + self.make_transforms(transformation) + + def make_transforms(self, transformation): + t = TransformStamped() + + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = transformation[1] + + t.transform.translation.x = float(transformation[2]) + t.transform.translation.y = float(transformation[3]) + t.transform.translation.z = float(transformation[4]) + quat = quaternion_from_euler( + float(transformation[5]), float(transformation[6]), float(transformation[7])) + t.transform.rotation.x = quat[0] + t.transform.rotation.y = quat[1] + t.transform.rotation.z = quat[2] + t.transform.rotation.w = quat[3] + + self.tf_static_broadcaster.sendTransform(t) + + + def main(): + try: + logger = rclpy.logging.get_logger('logger') + + # obtain parameters from command line arguments + if len(sys.argv) != 8: + logger.info('Invalid number of parameters. Usage: \n' + '$ ros2 run learning_tf2_py static_turtle_tf2_broadcaster' + 'child_frame_name x y z roll pitch yaw') + sys.exit(1) + + if sys.argv[1] == 'world': + logger.info('Your static turtle name cannot be "world"') + sys.exit(2) + + # pass parameters and initialize node + with rclpy.init(): + node = StaticFramePublisher(sys.argv) + rclpy.spin(node) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Now let's look at the code that is relevant to publishing the static turtle pose to tf2. +The first lines import required packages. +First we import the ``TransformStamped`` from the ``geometry_msgs``, which provides us a template for the message that we will publish to the transformation tree. + +.. code-block:: python + + from geometry_msgs.msg import TransformStamped + +Afterward, ``rclpy`` is imported so its ``Node`` class can be used. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The ``tf2_ros`` package provides a ``StaticTransformBroadcaster`` to make the publishing of static transforms easy. +To use the ``StaticTransformBroadcaster``, we need to import it from the ``tf2_ros`` module. + +.. code-block:: python + + from tf2_ros.static_transform_broadcaster import StaticTransformBroadcaster + +The ``StaticFramePublisher`` class constructor initializes the node with the name ``static_turtle_tf2_broadcaster``. +Then, ``StaticTransformBroadcaster`` is created, which will send one static transformation upon the startup. + +.. code-block:: python + + self.tf_static_broadcaster = StaticTransformBroadcaster(self) + self.make_transforms(transformation) + +Here we create a ``TransformStamped`` object, which will be the message we will send over once populated. +Before passing the actual transform values we need to give it the appropriate metadata. + +#. We need to give the transform being published a timestamp and we'll just stamp it with the current time, ``self.get_clock().now()`` + +#. Then we need to set the name of the parent frame of the link we're creating, in this case ``world`` + +#. Finally, we need to set the name of the child frame of the link we're creating + +.. code-block:: python + + t = TransformStamped() + + t.header.stamp = self.get_clock().now().to_msg() + t.header.frame_id = 'world' + t.child_frame_id = transformation[1] + +Here we populate the 6D pose (translation and rotation) of the turtle. + +.. code-block:: python + + t.transform.translation.x = float(transformation[2]) + t.transform.translation.y = float(transformation[3]) + t.transform.translation.z = float(transformation[4]) + quat = quaternion_from_euler( + float(transformation[5]), float(transformation[6]), float(transformation[7])) + t.transform.rotation.x = quat[0] + t.transform.rotation.y = quat[1] + t.transform.rotation.z = quat[2] + t.transform.rotation.w = quat[3] + +Finally, we broadcast static transform using the ``sendTransform()`` function. + +.. code-block:: python + + self.tf_static_broadcaster.sendTransform(t) + +2.2 Update package.xml +~~~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``src/learning_tf2_py`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`Create a package <../Creating-Your-First-ROS2-Package>` tutorial, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Learning tf2 with rclpy + Your Name + Apache-2.0 + +After the lines above, add the following dependencies corresponding to your node's import statements: + +.. code-block:: xml + + geometry_msgs + python3-numpy + rclpy + tf2_ros_py + turtlesim_msgs + +This declares the required ``geometry_msgs``, ``python3-numpy``, ``rclpy``, ``tf2_ros_py``, and ``turtlesim_msgs`` dependencies when its code is executed. + +Make sure to save the file. + +2.3 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``src/learning_tf2_py`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'static_turtle_tf2_broadcaster = learning_tf2_py.static_turtle_tf2_broadcaster:main', + +3 Build +^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + + .. group-tab:: Windows + + rosdep only runs on Linux, so you will need to install ``geometry_msgs`` and ``turtlesim`` dependencies yourself + +Still in the root of your workspace, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select learning_tf2_py + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select learning_tf2_py + +Open a new terminal, navigate to the root of your workspace, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ call install\setup.bat + + Or in powershell: + + .. code-block:: console + + $ .\install\setup.ps1 + + + +4 Run +^^^^^ + +Now run the ``static_turtle_tf2_broadcaster`` node: + +.. code-block:: console + + $ ros2 run learning_tf2_py static_turtle_tf2_broadcaster mystaticturtle 0 0 1 0 0 0 + +This sets a turtle pose broadcast for ``mystaticturtle`` to float 1 meter above the ground. + +We can now check that the static transform has been published by echoing the ``tf_static`` topic +If everything is well you should see a single static transform: + +.. code-block:: console + + $ ros2 topic echo /tf_static + transforms: + - header: + stamp: + sec: 1622908754 + nanosec: 208515730 + frame_id: world + child_frame_id: mystaticturtle + transform: + translation: + x: 0.0 + y: 0.0 + z: 1.0 + rotation: + x: 0.0 + y: 0.0 + z: 0.0 + w: 1.0 + +The proper way to publish static transforms +------------------------------------------- + +This tutorial aimed to show how ``StaticTransformBroadcaster`` can be used to publish static transforms. +In your real development process you shouldn't have to write this code yourself and should use the dedicated ``tf2_ros`` tool to do so. +``tf2_ros`` provides an executable named ``static_transform_publisher`` that can be used either as a commandline tool or a node that you can add to your launchfiles. + +The following command publishes a static coordinate transform to tf2 resulting in a 1 meter offset in z and no rotation between the frames ``world`` and ``mystaticturtle``. +In ROS 2, roll/pitch/yaw refers to rotation in radians about the x/y/z-axis, respectively. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --yaw 0 --pitch 0 --roll 0 --frame-id world --child-frame-id mystaticturtle + +The following command publishes the same static coordinate transform to tf2, but using quaternion representation for the rotation. + +.. code-block:: console + + $ ros2 run tf2_ros static_transform_publisher --x 0 --y 0 --z 1 --qx 0 --qy 0 --qz 0 --qw 1 --frame-id world --child-frame-id mystaticturtle + +``static_transform_publisher`` is designed both as a command-line tool for manual use, as well as for use within ``launch`` files for setting static transforms. +For example: + +.. tabs:: + + .. group-tab:: XML + + .. literalinclude:: launch/static_transform_publisher_launch.xml + :language: xml + + .. group-tab:: YAML + + .. literalinclude:: launch/static_transform_publisher_launch.yaml + :language: yaml + + .. group-tab:: Python + + .. literalinclude:: launch/static_transform_publisher_launch.py + :language: python + +Note that all arguments except for ``--frame-id`` and ``--child-frame-id`` are optional; if a particular option isn't specified, then the identity will be assumed. + +Summary +------- + +In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. +In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst index 6ef863961d1..bd76ae118cb 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst @@ -1,537 +1,537 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Cpp-Publisher-And-Subscriber - Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber - -.. _CppPubSub: - -Writing a simple publisher and subscriber (C++) -=============================================== - -**Goal:** Create and run a publisher and subscriber node using C++. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -:doc:`Nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` are executable processes that communicate over the ROS graph. -In this tutorial, the nodes will pass information in the form of string messages to each other over a :doc:`topic <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. -The example used here is a simple "talker" and "listener" system; one node publishes data and the other subscribes to the topic so it can receive that data. - -The code used in these examples can be found `here `__. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -So, navigate into ``ros2_ws/src``, and run the package creation command: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_pubsub - -Your terminal will return a message verifying the creation of your package ``cpp_pubsub`` and all its necessary files and folders. - -Navigate into ``ros2_ws/src/cpp_pubsub/src``. -Recall that this is the directory in any CMake package where the source files containing executables belong. - - -2 Write the publisher node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Download the example talker code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp - -Now there will be a new file named ``publisher_lambda_function.cpp``. -Open the file using your preferred text editor. - -.. code-block:: C++ - - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - - /* This example creates a subclass of Node and uses a fancy C++11 lambda - * function to shorten the callback syntax, at the expense of making the - * code somewhat more difficult to understand at first glance. */ - - class MinimalPublisher : public rclcpp::Node - { - public: - MinimalPublisher() - : Node("minimal_publisher"), count_(0) - { - publisher_ = this->create_publisher("topic", 10); - auto timer_callback = - [this]() -> void { - auto message = std_msgs::msg::String(); - message.data = "Hello, world! " + std::to_string(this->count_++); - RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); - this->publisher_->publish(message); - }; - timer_ = this->create_wall_timer(500ms, timer_callback); - } - - private: - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; - size_t count_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The top of the code includes the standard C++ headers you will be using. -After the standard C++ headers is the ``rclcpp/rclcpp.hpp`` include which allows you to use the most common pieces of the ROS 2 system. -Last is ``std_msgs/msg/string.hpp``, which includes the built-in message type you will use to publish data. - -.. code-block:: C++ - - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - using namespace std::chrono_literals; - -These lines represent the node's dependencies. -Recall that dependencies have to be added to ``package.xml`` and ``CMakeLists.txt``, which you'll do in the next section. - -The next line creates the node class ``MinimalPublisher`` by inheriting from ``rclcpp::Node``. -Every ``this`` in the code is referring to the node. - -.. code-block:: C++ - - class MinimalPublisher : public rclcpp::Node - -The public constructor names the node ``minimal_publisher`` and initializes ``count_`` to 0. -Inside the constructor, the publisher is initialized with the ``String`` message type, the topic name ``topic``, and the required queue size to limit messages in the event of a backup. -Next, a `lambda function `_ called ``timer_callback`` is declared. -It performs a by-reference capture of the current object ``this``, takes no input arguments and returns void. -The ``timer_callback`` function creates a new message of type ``String``, sets its data with the desired string and publishes it. -The ``RCLCPP_INFO`` macro ensures every published message is printed to the console. -At last, ``timer_`` is initialized, which causes the ``timer_callback`` function to be executed twice a second. - -.. code-block:: C++ - - public: - MinimalPublisher() - : Node("minimal_publisher"), count_(0) - { - publisher_ = this->create_publisher("topic", 10); - auto timer_callback = - [this]() -> void { - auto message = std_msgs::msg::String(); - message.data = "Hello, world! " + std::to_string(this->count_++); - RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); - this->publisher_->publish(message); - }; - timer_ = this->create_wall_timer(500ms, timer_callback); - } - -In the bottom of the class is the declaration of the timer, publisher, and counter fields. - -.. code-block:: C++ - - private: - rclcpp::TimerBase::SharedPtr timer_; - rclcpp::Publisher::SharedPtr publisher_; - size_t count_; - -Following the ``MinimalPublisher`` class is ``main``, where the node actually executes. -``rclcpp::init`` initializes ROS 2, and ``rclcpp::spin`` starts processing data from the node, including callbacks from the timer. - -.. code-block:: C++ - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``ros2_ws/src/cpp_pubsub`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`previous tutorial `, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Examples of minimal publisher/subscriber using rclcpp - Your Name - Apache-2.0 - -Add a new line after the ``ament_cmake`` buildtool dependency and paste the following dependencies corresponding to your node's include statements: - -.. code-block:: xml - - rclcpp - std_msgs - -This declares the package needs ``rclcpp`` and ``std_msgs`` when its code is built and executed. - -Make sure to save the file. - -2.3 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Now open the ``CMakeLists.txt`` file. -Below the existing dependency ``find_package(ament_cmake REQUIRED)``, add the lines: - -.. code-block:: cmake - - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - -After that, add the executable and name it ``talker`` so you can run your node using ``ros2 run``: - -.. code-block:: cmake - - add_executable(talker src/publisher_lambda_function.cpp) - target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - -Finally, add the ``install(TARGETS...)`` section so ``ros2 run`` can find your executable: - -.. code-block:: cmake - - install(TARGETS - talker - DESTINATION lib/${PROJECT_NAME}) - -You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(cpp_pubsub) - - # Default to C++20 - if(NOT CMAKE_CXX_STANDARD) - set(CMAKE_CXX_STANDARD 20) - endif() - - if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") - add_compile_options(-Wall -Wextra -Wpedantic) - endif() - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(std_msgs REQUIRED) - - add_executable(talker src/publisher_lambda_function.cpp) - target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - talker - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - -You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. - -3 Write the subscriber node -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Return to ``ros2_ws/src/cpp_pubsub/src`` to create the next node. -Enter the following code in your terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp - -Check to ensure that these files exist: - -.. code-block:: console - - publisher_lambda_function.cpp subscriber_lambda_function.cpp - -Open the ``subscriber_lambda_function.cpp`` with your text editor. - -.. code-block:: C++ - - #include - - #include "rclcpp/rclcpp.hpp" - #include "std_msgs/msg/string.hpp" - - class MinimalSubscriber : public rclcpp::Node - { - public: - MinimalSubscriber() - : Node("minimal_subscriber") - { - auto topic_callback = - [this](std_msgs::msg::String::UniquePtr msg) -> void { - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); - }; - subscription_ = - this->create_subscription("topic", 10, topic_callback); - } - - private: - rclcpp::Subscription::SharedPtr subscription_; - }; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - rclcpp::spin(std::make_shared()); - rclcpp::shutdown(); - return 0; - } - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The subscriber node's code is nearly identical to the publisher's. -Now the node is named ``minimal_subscriber``, and the constructor uses the node's ``create_subscription`` function to execute the callback. - -There is no timer because the subscriber simply responds whenever data is published to the ``topic`` topic. - -The ``topic_callback`` function receives the string message data published over the topic, and simply writes it to the console using the ``RCLCPP_INFO`` macro. - -Recall from the :doc:`topic tutorial <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. - -.. code-block:: C++ - - public: - MinimalSubscriber() - : Node("minimal_subscriber") - { - auto topic_callback = - [this](std_msgs::msg::String::UniquePtr msg) -> void { - RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); - }; - subscription_ = - this->create_subscription("topic", 10, topic_callback); - } - -The only field declaration in this class is the subscription. - -.. code-block:: C++ - - private: - rclcpp::Subscription::SharedPtr subscription_; - -The ``main`` function is exactly the same, except now it spins the ``MinimalSubscriber`` node. -For the publisher node, spinning meant starting the timer, but for the subscriber it simply means preparing to receive messages whenever they come. - -Since this node has the same dependencies as the publisher node, there's nothing new to add to ``package.xml``. - -3.2 CMakeLists.txt -~~~~~~~~~~~~~~~~~~ - -Reopen ``CMakeLists.txt`` and add the executable and target for the subscriber node below the publisher's entries. - -.. code-block:: cmake - - add_executable(listener src/subscriber_lambda_function.cpp) - target_link_libraries(listener PUBLIC rclcpp::rclcpp std_msgs::std_msgs) - - install(TARGETS - talker - listener - DESTINATION lib/${PROJECT_NAME}) - -Make sure to save the file, and then your pub/sub system should be ready. - -.. _cpppubsub-build-and-run: - -4 Build and run -^^^^^^^^^^^^^^^ -You likely already have the ``rclcpp`` and ``std_msgs`` packages installed as part of your ROS 2 system. -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Still in the root of your workspace, ``ros2_ws``, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select cpp_pubsub - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select cpp_pubsub - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_pubsub - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the talker node. -The terminal should start publishing info messages every 0.5 seconds, like so: - -.. code-block:: console - - $ ros2 run cpp_pubsub talker - [INFO] [minimal_publisher]: Publishing: "Hello World: 0" - [INFO] [minimal_publisher]: Publishing: "Hello World: 1" - [INFO] [minimal_publisher]: Publishing: "Hello World: 2" - [INFO] [minimal_publisher]: Publishing: "Hello World: 3" - [INFO] [minimal_publisher]: Publishing: "Hello World: 4" - -Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. -The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time: - -.. code-block:: console - - $ ros2 run cpp_pubsub listener - [INFO] [minimal_subscriber]: I heard: "Hello World: 10" - [INFO] [minimal_subscriber]: I heard: "Hello World: 11" - [INFO] [minimal_subscriber]: I heard: "Hello World: 12" - [INFO] [minimal_subscriber]: I heard: "Hello World: 13" - [INFO] [minimal_subscriber]: I heard: "Hello World: 14" - -Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. - -Summary -------- - -You created two nodes to publish and subscribe to data over a topic. -Before compiling and running them, you added their dependencies and executables to the package configuration files. - -Next steps ----------- - -Next you'll create another simple ROS 2 package using the service/client model. -Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Writing-A-Simple-Cpp-Publisher-And-Subscriber + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber + +.. _CppPubSub: + +Writing a simple publisher and subscriber (C++) +=============================================== + +**Goal:** Create and run a publisher and subscriber node using C++. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +:doc:`Nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` are executable processes that communicate over the ROS graph. +In this tutorial, the nodes will pass information in the form of string messages to each other over a :doc:`topic <../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. +The example used here is a simple "talker" and "listener" system; one node publishes data and the other subscribes to the topic so it can receive that data. + +The code used in these examples can be found `here `__. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +So, navigate into ``ros2_ws/src``, and run the package creation command: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_pubsub + +Your terminal will return a message verifying the creation of your package ``cpp_pubsub`` and all its necessary files and folders. + +Navigate into ``ros2_ws/src/cpp_pubsub/src``. +Recall that this is the directory in any CMake package where the source files containing executables belong. + + +2 Write the publisher node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Download the example talker code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget -O publisher_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/lambda.cpp -o publisher_lambda_function.cpp + +Now there will be a new file named ``publisher_lambda_function.cpp``. +Open the file using your preferred text editor. + +.. code-block:: C++ + + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + + /* This example creates a subclass of Node and uses a fancy C++11 lambda + * function to shorten the callback syntax, at the expense of making the + * code somewhat more difficult to understand at first glance. */ + + class MinimalPublisher : public rclcpp::Node + { + public: + MinimalPublisher() + : Node("minimal_publisher"), count_(0) + { + publisher_ = this->create_publisher("topic", 10); + auto timer_callback = + [this]() -> void { + auto message = std_msgs::msg::String(); + message.data = "Hello, world! " + std::to_string(this->count_++); + RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); + this->publisher_->publish(message); + }; + timer_ = this->create_wall_timer(500ms, timer_callback); + } + + private: + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; + size_t count_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The top of the code includes the standard C++ headers you will be using. +After the standard C++ headers is the ``rclcpp/rclcpp.hpp`` include which allows you to use the most common pieces of the ROS 2 system. +Last is ``std_msgs/msg/string.hpp``, which includes the built-in message type you will use to publish data. + +.. code-block:: C++ + + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + using namespace std::chrono_literals; + +These lines represent the node's dependencies. +Recall that dependencies have to be added to ``package.xml`` and ``CMakeLists.txt``, which you'll do in the next section. + +The next line creates the node class ``MinimalPublisher`` by inheriting from ``rclcpp::Node``. +Every ``this`` in the code is referring to the node. + +.. code-block:: C++ + + class MinimalPublisher : public rclcpp::Node + +The public constructor names the node ``minimal_publisher`` and initializes ``count_`` to 0. +Inside the constructor, the publisher is initialized with the ``String`` message type, the topic name ``topic``, and the required queue size to limit messages in the event of a backup. +Next, a `lambda function `_ called ``timer_callback`` is declared. +It performs a by-reference capture of the current object ``this``, takes no input arguments and returns void. +The ``timer_callback`` function creates a new message of type ``String``, sets its data with the desired string and publishes it. +The ``RCLCPP_INFO`` macro ensures every published message is printed to the console. +At last, ``timer_`` is initialized, which causes the ``timer_callback`` function to be executed twice a second. + +.. code-block:: C++ + + public: + MinimalPublisher() + : Node("minimal_publisher"), count_(0) + { + publisher_ = this->create_publisher("topic", 10); + auto timer_callback = + [this]() -> void { + auto message = std_msgs::msg::String(); + message.data = "Hello, world! " + std::to_string(this->count_++); + RCLCPP_INFO(this->get_logger(), "Publishing: '%s'", message.data.c_str()); + this->publisher_->publish(message); + }; + timer_ = this->create_wall_timer(500ms, timer_callback); + } + +In the bottom of the class is the declaration of the timer, publisher, and counter fields. + +.. code-block:: C++ + + private: + rclcpp::TimerBase::SharedPtr timer_; + rclcpp::Publisher::SharedPtr publisher_; + size_t count_; + +Following the ``MinimalPublisher`` class is ``main``, where the node actually executes. +``rclcpp::init`` initializes ROS 2, and ``rclcpp::spin`` starts processing data from the node, including callbacks from the timer. + +.. code-block:: C++ + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``ros2_ws/src/cpp_pubsub`` directory, where the ``CMakeLists.txt`` and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`previous tutorial `, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Examples of minimal publisher/subscriber using rclcpp + Your Name + Apache-2.0 + +Add a new line after the ``ament_cmake`` buildtool dependency and paste the following dependencies corresponding to your node's include statements: + +.. code-block:: xml + + rclcpp + std_msgs + +This declares the package needs ``rclcpp`` and ``std_msgs`` when its code is built and executed. + +Make sure to save the file. + +2.3 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Now open the ``CMakeLists.txt`` file. +Below the existing dependency ``find_package(ament_cmake REQUIRED)``, add the lines: + +.. code-block:: cmake + + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + +After that, add the executable and name it ``talker`` so you can run your node using ``ros2 run``: + +.. code-block:: cmake + + add_executable(talker src/publisher_lambda_function.cpp) + target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + +Finally, add the ``install(TARGETS...)`` section so ``ros2 run`` can find your executable: + +.. code-block:: cmake + + install(TARGETS + talker + DESTINATION lib/${PROJECT_NAME}) + +You can clean up your ``CMakeLists.txt`` by removing some unnecessary sections and comments, so it looks like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(cpp_pubsub) + + # Default to C++20 + if(NOT CMAKE_CXX_STANDARD) + set(CMAKE_CXX_STANDARD 20) + endif() + + if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang") + add_compile_options(-Wall -Wextra -Wpedantic) + endif() + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(std_msgs REQUIRED) + + add_executable(talker src/publisher_lambda_function.cpp) + target_link_libraries(talker PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + talker + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + +You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. + +3 Write the subscriber node +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Return to ``ros2_ws/src/cpp_pubsub/src`` to create the next node. +Enter the following code in your terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ wget -O subscriber_lambda_function.cpp https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_subscriber/lambda.cpp -o subscriber_lambda_function.cpp + +Check to ensure that these files exist: + +.. code-block:: console + + publisher_lambda_function.cpp subscriber_lambda_function.cpp + +Open the ``subscriber_lambda_function.cpp`` with your text editor. + +.. code-block:: C++ + + #include + + #include "rclcpp/rclcpp.hpp" + #include "std_msgs/msg/string.hpp" + + class MinimalSubscriber : public rclcpp::Node + { + public: + MinimalSubscriber() + : Node("minimal_subscriber") + { + auto topic_callback = + [this](std_msgs::msg::String::UniquePtr msg) -> void { + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); + }; + subscription_ = + this->create_subscription("topic", 10, topic_callback); + } + + private: + rclcpp::Subscription::SharedPtr subscription_; + }; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + rclcpp::spin(std::make_shared()); + rclcpp::shutdown(); + return 0; + } + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The subscriber node's code is nearly identical to the publisher's. +Now the node is named ``minimal_subscriber``, and the constructor uses the node's ``create_subscription`` function to execute the callback. + +There is no timer because the subscriber simply responds whenever data is published to the ``topic`` topic. + +The ``topic_callback`` function receives the string message data published over the topic, and simply writes it to the console using the ``RCLCPP_INFO`` macro. + +Recall from the :doc:`topic tutorial <../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. + +.. code-block:: C++ + + public: + MinimalSubscriber() + : Node("minimal_subscriber") + { + auto topic_callback = + [this](std_msgs::msg::String::UniquePtr msg) -> void { + RCLCPP_INFO(this->get_logger(), "I heard: '%s'", msg->data.c_str()); + }; + subscription_ = + this->create_subscription("topic", 10, topic_callback); + } + +The only field declaration in this class is the subscription. + +.. code-block:: C++ + + private: + rclcpp::Subscription::SharedPtr subscription_; + +The ``main`` function is exactly the same, except now it spins the ``MinimalSubscriber`` node. +For the publisher node, spinning meant starting the timer, but for the subscriber it simply means preparing to receive messages whenever they come. + +Since this node has the same dependencies as the publisher node, there's nothing new to add to ``package.xml``. + +3.2 CMakeLists.txt +~~~~~~~~~~~~~~~~~~ + +Reopen ``CMakeLists.txt`` and add the executable and target for the subscriber node below the publisher's entries. + +.. code-block:: cmake + + add_executable(listener src/subscriber_lambda_function.cpp) + target_link_libraries(listener PUBLIC rclcpp::rclcpp std_msgs::std_msgs) + + install(TARGETS + talker + listener + DESTINATION lib/${PROJECT_NAME}) + +Make sure to save the file, and then your pub/sub system should be ready. + +.. _cpppubsub-build-and-run: + +4 Build and run +^^^^^^^^^^^^^^^ +You likely already have the ``rclcpp`` and ``std_msgs`` packages installed as part of your ROS 2 system. +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Still in the root of your workspace, ``ros2_ws``, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select cpp_pubsub + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select cpp_pubsub + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_pubsub + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the talker node. +The terminal should start publishing info messages every 0.5 seconds, like so: + +.. code-block:: console + + $ ros2 run cpp_pubsub talker + [INFO] [minimal_publisher]: Publishing: "Hello World: 0" + [INFO] [minimal_publisher]: Publishing: "Hello World: 1" + [INFO] [minimal_publisher]: Publishing: "Hello World: 2" + [INFO] [minimal_publisher]: Publishing: "Hello World: 3" + [INFO] [minimal_publisher]: Publishing: "Hello World: 4" + +Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. +The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time: + +.. code-block:: console + + $ ros2 run cpp_pubsub listener + [INFO] [minimal_subscriber]: I heard: "Hello World: 10" + [INFO] [minimal_subscriber]: I heard: "Hello World: 11" + [INFO] [minimal_subscriber]: I heard: "Hello World: 12" + [INFO] [minimal_subscriber]: I heard: "Hello World: 13" + [INFO] [minimal_subscriber]: I heard: "Hello World: 14" + +Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. + +Summary +------- + +You created two nodes to publish and subscribe to data over a topic. +Before compiling and running them, you added their dependencies and executables to the package configuration files. + +Next steps +---------- + +Next you'll create another simple ROS 2 package using the service/client model. +Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. + +Related content +--------------- + There are several ways you could write a publisher and subscriber in C++; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst index 40cfbe1b061..35bbbb361ff 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst @@ -1,410 +1,410 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Cpp-Service-And-Client - Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client - -.. _CppSrvCli: - -Writing a simple service and client (C++) -========================================= - -**Goal:** Create and run service and client nodes using C++. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. -The structure of the request and response is determined by a ``.srv`` file. - -The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. - - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -Navigate into ``ros2_ws/src`` and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_srvcli --dependencies rclcpp example_interfaces - -Your terminal will return a message verifying the creation of your package ``cpp_srvcli`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. -``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: - -.. code-block:: bash - - int64 a - int64 b - --- - int64 sum - -The first two lines are the parameters of the request, and below the dashes is the response. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. - -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - C++ client server tutorial - Your Name - Apache-2.0 - - -2 Write the service node -^^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_server.cpp`` and paste the following code within: - -.. code-block:: C++ - - #include - #include - - #include "example_interfaces/srv/add_two_ints.hpp" - #include "rclcpp/rclcpp.hpp" - - using AddTwoInts = example_interfaces::srv::AddTwoInts; - rclcpp::Node::SharedPtr g_node = nullptr; - - void handle_service( - const std::shared_ptr request_header, - const std::shared_ptr request, - const std::shared_ptr response) - { - (void)request_header; - RCLCPP_INFO( - g_node->get_logger(), - "request: %" PRId64 " + %" PRId64, request->a, request->b); - response->sum = request->a + request->b; - } - - int main(int argc, char ** argv) - { - rclcpp::init(argc, argv); - g_node = rclcpp::Node::make_shared("minimal_service"); - auto server = g_node->create_service("add_two_ints", handle_service); - rclcpp::spin(g_node); - rclcpp::shutdown(); - g_node = nullptr; - return 0; - } - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The first ``#include`` statements are your package dependencies. - -The ``handle_service`` function adds two integers from the request and gives the sum to the response, while notifying the console of its status using logs. - -.. code-block:: C++ - - void handle_service( - const std::shared_ptr request_header, - const std::shared_ptr request, - const std::shared_ptr response) - { - (void)request_header; - RCLCPP_INFO( - g_node->get_logger(), - "request: %" PRId64 " + %" PRId64, request->a, request->b); - response->sum = request->a + request->b; - } - -The ``main`` function accomplishes the following, line by line: - -* Initializes ROS 2 C++ client library: - - .. code-block:: C++ - - rclcpp::init(argc, argv); - -* Creates a node named ``minimal_service``: - - .. code-block:: C++ - - g_node = rclcpp::Node::make_shared("minimal_service"); - -* Creates a service named ``add_two_ints`` for that node and automatically advertises it over the networks with the ``handle_service`` method: - - .. code-block:: C++ - - auto server = g_node->create_service("add_two_ints", handle_service); - -* Spins the node, making the service available. - - .. code-block:: C++ - - rclcpp::spin(g_node); - -2.2 Add executable -~~~~~~~~~~~~~~~~~~ - -The ``add_executable`` macro generates an executable you can run using ``ros2 run``. -Add the following code block to ``CMakeLists.txt`` just below the dependencies to create an executable named ``server``: - -.. code-block:: cmake - - add_executable(server src/add_two_ints_server.cpp) - target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) - -So ``ros2 run`` can find the executable, add the following lines to the end of the file, right before ``ament_package()``: - -.. code-block:: cmake - - install(TARGETS - server - DESTINATION lib/${PROJECT_NAME}) - -You could build your package now, source the local setup files, and run it, but let's create the client node first so you can see the full system at work. - -3 Write the client node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_client.cpp`` and paste the following code within: - -.. code-block:: C++ - - #include - #include - #include - - #include "example_interfaces/srv/add_two_ints.hpp" - #include "rclcpp/rclcpp.hpp" - - using AddTwoInts = example_interfaces::srv::AddTwoInts; - - int main(int argc, char * argv[]) - { - rclcpp::init(argc, argv); - auto node = rclcpp::Node::make_shared("minimal_client"); - auto client = node->create_client("add_two_ints"); - while (!client->wait_for_service(std::chrono::seconds(1))) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); - return 1; - } - RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); - } - auto request = std::make_shared(); - request->a = 41; - request->b = 1; - auto result_future = client->async_send_request(request); - if (rclcpp::spin_until_future_complete(node, result_future) != - rclcpp::FutureReturnCode::SUCCESS) - { - RCLCPP_ERROR(node->get_logger(), "service call failed :("); - client->remove_pending_request(result_future); - return 1; - } - auto result = result_future.get(); - RCLCPP_INFO( - node->get_logger(), "result of %" PRId64 " + %" PRId64 " = %" PRId64, - request->a, request->b, result->sum); - rclcpp::shutdown(); - return 0; - } - - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Similar to the service node, the following lines of code create the node and then create the client for that node: - -.. code-block:: C++ - - auto node = rclcpp::Node::make_shared("minimal_client"); - auto client = node->create_client("add_two_ints"); - -Next, the code waits for the service to appear. -The ``while`` loop gives the client 1 second to search for service nodes in the network. -If it can't find any, it will continue waiting. -If the client is canceled (e.g. by you entering ``Ctrl+C`` into the terminal), it will return an error log message stating it was interrupted. - -.. code-block:: C++ - - while (!client->wait_for_service(std::chrono::seconds(1))) { - if (!rclcpp::ok()) { - RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); - return 1; - } - RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); - } - -Next, the request is created. -Its structure is defined by the ``.srv`` file mentioned earlier. - -.. code-block:: C++ - - auto request = std::make_shared(); - request->a = 41; - request->b = 1; - - -Then the client sends its request, and the node spins until it receives its response, or fails. - -3.2 Add executable -~~~~~~~~~~~~~~~~~~ - -Return to ``CMakeLists.txt`` to add the executable and target for the new node. -After removing some unnecessary boilerplate from the automatically generated file, your ``CMakeLists.txt`` should look like this: - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20) - project(cpp_srvcli) - - find_package(ament_cmake REQUIRED) - find_package(rclcpp REQUIRED) - find_package(example_interfaces REQUIRED) - - add_executable(server src/add_two_ints_server.cpp) - target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) - - add_executable(client src/add_two_ints_client.cpp) - target_link_libraries(client PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) - - install(TARGETS - server - client - DESTINATION lib/${PROJECT_NAME}) - - ament_package() - - -4 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select cpp_srvcli - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select cpp_srvcli - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select cpp_srvcli - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the service node: - -.. code-block:: console - - $ ros2 run cpp_srvcli server - -The terminal should wait for incoming requests. - -Open another terminal, source the setup files from inside ``ros2_ws`` again. -Start the client node, followed by any two integers separated by a space. -The client sends the request to the service, which computes the sum and returns the result: - -.. code-block:: console - - $ ros2 run cpp_srvcli client - [INFO] [minimal_client]: result of 41 + 1: 42 - -The client should receive the response above. - -Return to the terminal where your service node is running. -You will see that it published log messages when it received the request and the data it received, and the response it sent back: - -.. code-block:: console - - [INFO] [minimal_service]: request: 41 + 1 - -Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. - -Summary -------- - -You created two nodes to request and respond to data over a service. -You added their dependencies and executables to the package configuration files so that you could build and run them, and see a service/client system at work. - -Next steps ----------- - -In the last few tutorials you've been utilizing interfaces to pass data across topics and services. -Next, you'll learn how to :doc:`create custom interfaces `. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Writing-A-Simple-Cpp-Service-And-Client + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client + +.. _CppSrvCli: + +Writing a simple service and client (C++) +========================================= + +**Goal:** Create and run service and client nodes using C++. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../../interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. +The structure of the request and response is determined by a ``.srv`` file. + +The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. + + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +Navigate into ``ros2_ws/src`` and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 cpp_srvcli --dependencies rclcpp example_interfaces + +Your terminal will return a message verifying the creation of your package ``cpp_srvcli`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml`` and ``CMakeLists.txt``. +``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: + +.. code-block:: bash + + int64 a + int64 b + --- + int64 sum + +The first two lines are the parameters of the request, and below the dashes is the response. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml`` or ``CMakeLists.txt``. + +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + C++ client server tutorial + Your Name + Apache-2.0 + + +2 Write the service node +^^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_server.cpp`` and paste the following code within: + +.. code-block:: C++ + + #include + #include + + #include "example_interfaces/srv/add_two_ints.hpp" + #include "rclcpp/rclcpp.hpp" + + using AddTwoInts = example_interfaces::srv::AddTwoInts; + rclcpp::Node::SharedPtr g_node = nullptr; + + void handle_service( + const std::shared_ptr request_header, + const std::shared_ptr request, + const std::shared_ptr response) + { + (void)request_header; + RCLCPP_INFO( + g_node->get_logger(), + "request: %" PRId64 " + %" PRId64, request->a, request->b); + response->sum = request->a + request->b; + } + + int main(int argc, char ** argv) + { + rclcpp::init(argc, argv); + g_node = rclcpp::Node::make_shared("minimal_service"); + auto server = g_node->create_service("add_two_ints", handle_service); + rclcpp::spin(g_node); + rclcpp::shutdown(); + g_node = nullptr; + return 0; + } + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The first ``#include`` statements are your package dependencies. + +The ``handle_service`` function adds two integers from the request and gives the sum to the response, while notifying the console of its status using logs. + +.. code-block:: C++ + + void handle_service( + const std::shared_ptr request_header, + const std::shared_ptr request, + const std::shared_ptr response) + { + (void)request_header; + RCLCPP_INFO( + g_node->get_logger(), + "request: %" PRId64 " + %" PRId64, request->a, request->b); + response->sum = request->a + request->b; + } + +The ``main`` function accomplishes the following, line by line: + +* Initializes ROS 2 C++ client library: + + .. code-block:: C++ + + rclcpp::init(argc, argv); + +* Creates a node named ``minimal_service``: + + .. code-block:: C++ + + g_node = rclcpp::Node::make_shared("minimal_service"); + +* Creates a service named ``add_two_ints`` for that node and automatically advertises it over the networks with the ``handle_service`` method: + + .. code-block:: C++ + + auto server = g_node->create_service("add_two_ints", handle_service); + +* Spins the node, making the service available. + + .. code-block:: C++ + + rclcpp::spin(g_node); + +2.2 Add executable +~~~~~~~~~~~~~~~~~~ + +The ``add_executable`` macro generates an executable you can run using ``ros2 run``. +Add the following code block to ``CMakeLists.txt`` just below the dependencies to create an executable named ``server``: + +.. code-block:: cmake + + add_executable(server src/add_two_ints_server.cpp) + target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) + +So ``ros2 run`` can find the executable, add the following lines to the end of the file, right before ``ament_package()``: + +.. code-block:: cmake + + install(TARGETS + server + DESTINATION lib/${PROJECT_NAME}) + +You could build your package now, source the local setup files, and run it, but let's create the client node first so you can see the full system at work. + +3 Write the client node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/cpp_srvcli/src`` directory, create a new file called ``add_two_ints_client.cpp`` and paste the following code within: + +.. code-block:: C++ + + #include + #include + #include + + #include "example_interfaces/srv/add_two_ints.hpp" + #include "rclcpp/rclcpp.hpp" + + using AddTwoInts = example_interfaces::srv::AddTwoInts; + + int main(int argc, char * argv[]) + { + rclcpp::init(argc, argv); + auto node = rclcpp::Node::make_shared("minimal_client"); + auto client = node->create_client("add_two_ints"); + while (!client->wait_for_service(std::chrono::seconds(1))) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); + return 1; + } + RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); + } + auto request = std::make_shared(); + request->a = 41; + request->b = 1; + auto result_future = client->async_send_request(request); + if (rclcpp::spin_until_future_complete(node, result_future) != + rclcpp::FutureReturnCode::SUCCESS) + { + RCLCPP_ERROR(node->get_logger(), "service call failed :("); + client->remove_pending_request(result_future); + return 1; + } + auto result = result_future.get(); + RCLCPP_INFO( + node->get_logger(), "result of %" PRId64 " + %" PRId64 " = %" PRId64, + request->a, request->b, result->sum); + rclcpp::shutdown(); + return 0; + } + + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Similar to the service node, the following lines of code create the node and then create the client for that node: + +.. code-block:: C++ + + auto node = rclcpp::Node::make_shared("minimal_client"); + auto client = node->create_client("add_two_ints"); + +Next, the code waits for the service to appear. +The ``while`` loop gives the client 1 second to search for service nodes in the network. +If it can't find any, it will continue waiting. +If the client is canceled (e.g. by you entering ``Ctrl+C`` into the terminal), it will return an error log message stating it was interrupted. + +.. code-block:: C++ + + while (!client->wait_for_service(std::chrono::seconds(1))) { + if (!rclcpp::ok()) { + RCLCPP_ERROR(node->get_logger(), "client interrupted while waiting for service to appear."); + return 1; + } + RCLCPP_INFO(node->get_logger(), "waiting for service to appear..."); + } + +Next, the request is created. +Its structure is defined by the ``.srv`` file mentioned earlier. + +.. code-block:: C++ + + auto request = std::make_shared(); + request->a = 41; + request->b = 1; + + +Then the client sends its request, and the node spins until it receives its response, or fails. + +3.2 Add executable +~~~~~~~~~~~~~~~~~~ + +Return to ``CMakeLists.txt`` to add the executable and target for the new node. +After removing some unnecessary boilerplate from the automatically generated file, your ``CMakeLists.txt`` should look like this: + +.. code-block:: cmake + + cmake_minimum_required(VERSION 3.20) + project(cpp_srvcli) + + find_package(ament_cmake REQUIRED) + find_package(rclcpp REQUIRED) + find_package(example_interfaces REQUIRED) + + add_executable(server src/add_two_ints_server.cpp) + target_link_libraries(server PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) + + add_executable(client src/add_two_ints_client.cpp) + target_link_libraries(client PUBLIC rclcpp::rclcpp example_interfaces::example_interfaces) + + install(TARGETS + server + client + DESTINATION lib/${PROJECT_NAME}) + + ament_package() + + +4 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select cpp_srvcli + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select cpp_srvcli + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select cpp_srvcli + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the service node: + +.. code-block:: console + + $ ros2 run cpp_srvcli server + +The terminal should wait for incoming requests. + +Open another terminal, source the setup files from inside ``ros2_ws`` again. +Start the client node, followed by any two integers separated by a space. +The client sends the request to the service, which computes the sum and returns the result: + +.. code-block:: console + + $ ros2 run cpp_srvcli client + [INFO] [minimal_client]: result of 41 + 1: 42 + +The client should receive the response above. + +Return to the terminal where your service node is running. +You will see that it published log messages when it received the request and the data it received, and the response it sent back: + +.. code-block:: console + + [INFO] [minimal_service]: request: 41 + 1 + +Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. + +Summary +------- + +You created two nodes to request and respond to data over a service. +You added their dependencies and executables to the package configuration files so that you could build and run them, and see a service/client system at work. + +Next steps +---------- + +In the last few tutorials you've been utilizing interfaces to pass data across topics and services. +Next, you'll learn how to :doc:`create custom interfaces `. + +Related content +--------------- + * There are several ways you could write a service and client in C++; check out the ``minimal_service`` and ``minimal_client`` packages in the `ros2/examples `_ repo. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst index 4b520500c85..d80378374cb 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst @@ -1,516 +1,516 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Py-Publisher-And-Subscriber - Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber - -.. _PyPubSub: - -Writing a simple publisher and subscriber (Python) -================================================== - -**Goal:** Create and run a publisher and subscriber node using Python. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -In this tutorial, you will create :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that pass information in the form of string messages to each other over a :doc:`topic <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. -The example used here is a simple "talker" and "listener" system; -one node publishes data and the other subscribes to the topic so it can receive that data. - -The code used in these examples can be found `here `__. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. - -A basic understanding of Python is recommended, but not entirely necessary. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -So, navigate into ``ros2_ws/src``, and run the package creation command: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_pubsub - -Your terminal will return a message verifying the creation of your package ``py_pubsub`` and all its necessary files and folders. - -2 Write the publisher node -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Navigate into ``ros2_ws/src/py_pubsub/py_pubsub``. -Recall that this directory is a `Python package `__ with the same name as the ROS 2 package it's nested in. - -Download the example talker code by entering the following command: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py - -Now there will be a new file named ``publisher_member_function.py`` adjacent to ``__init__.py``. - -Open the file using your preferred text editor. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from std_msgs.msg import String - - - class MinimalPublisher(Node): - - def __init__(self): - super().__init__('minimal_publisher') - self.publisher_ = self.create_publisher(String, 'topic', 10) - timer_period = 0.5 # seconds - self.timer = self.create_timer(timer_period, self.timer_callback) - self.i = 0 - - def timer_callback(self): - msg = String() - msg.data = 'Hello World: %d' % self.i - self.publisher_.publish(msg) - self.get_logger().info('Publishing: "%s"' % msg.data) - self.i += 1 - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_publisher = MinimalPublisher() - - rclpy.spin(minimal_publisher) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The first lines of code after the comments import {package(rclpy)} so its `Node <{package_link(rclpy)}api/node.html>`__ class can be used. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The next statement imports the built-in {interface(std_msgs/msg/String)} message type that the node uses to structure the data that it passes on the topic. - -.. code-block:: python - - from std_msgs.msg import String - -These lines represent the node's dependencies. -Recall that dependencies have to be added to ``package.xml``, which you'll do in the next section. - -Next, the ``MinimalPublisher`` class is created, which inherits from (or is a subclass of) `Node <{package_link(rclpy)}api/node.html>`__. - -.. code-block:: python - - class MinimalPublisher(Node): - -Following is the definition of the class's constructor. -``super().__init__`` calls the `Node <{package_link(rclpy)}api/node.html>`__ class's constructor and gives it your node name, in this case ``minimal_publisher``. - -`create_publisher <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_publisher>`__ declares that the node publishes messages of type {interface(std_msgs/msg/String)} (imported from the ``std_msgs.msg`` module), over a topic named ``topic``, and that the "queue size" is 10. -Queue size is a required :doc:`Quality of Service <../../topics/About-Quality-of-Service-Settings>` (QoS) setting that limits the amount of queued messages if a subscriber is not receiving them fast enough. - -Next, `create_timer <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_timer>`__ is used to create a callback that executes every 0.5 seconds. -``self.i`` is a counter used in the callback. - -.. code-block:: python - - def __init__(self): - super().__init__('minimal_publisher') - self.publisher_ = self.create_publisher(String, 'topic', 10) - timer_period = 0.5 # seconds - self.timer = self.create_timer(timer_period, self.timer_callback) - self.i = 0 - -``timer_callback`` creates a message with the counter value appended, publishes it, and prints it to the console with `get_logger() <{package_link(rclpy)}api/node.html#rclpy.node.Node.get_logger>`__'s `info() <{package_link(rclpy)}rclpy.impl.rcutils_logger.html#rclpy.impl.rcutils_logger.RcutilsLogger.info>`__ function. - -.. code-block:: python - - def timer_callback(self): - msg = String() - msg.data = 'Hello World: %d' % self.i - self.publisher_.publish(msg) - self.get_logger().info('Publishing: "%s"' % msg.data) - self.i += 1 - -Lastly, the main function is defined. - -.. code-block:: python - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_publisher = MinimalPublisher() - - rclpy.spin(minimal_publisher) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - -First the {package(rclpy)} library is initialized, then the node is created, and then it "spins" the node (using `spin() <{package_link(rclpy)}api/init_shutdown.html#rclpy.spin>`__) so its callbacks are called. - -2.2 Add dependencies -~~~~~~~~~~~~~~~~~~~~ - -Navigate one level back to the ``ros2_ws/src/py_pubsub`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. - -Open ``package.xml`` with your text editor. - -As mentioned in the :doc:`previous tutorial `, make sure to fill in the ````, ```` and ```` tags: - -.. code-block:: xml - - Examples of minimal publisher/subscriber using rclpy - Your Name - Apache-2.0 - -After the lines above, add the following dependencies corresponding to your node's import statements: - -.. code-block:: xml - - rclpy - std_msgs - -This declares the package needs {package(rclpy)} and {package(std_msgs)} when its code is executed. - -Make sure to save the file. - -2.3 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Open the ``setup.py`` file. -Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: - -.. code-block:: python - - maintainer='YourName', - maintainer_email='you@email.com', - description='Examples of minimal publisher/subscriber using rclpy', - license='Apache-2.0', - -Add the following line within the ``console_scripts`` brackets of the `entry_points `__ field: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'talker = py_pubsub.publisher_member_function:main', - ], - }, - -Don't forget to save. - -2.4 Check setup.cfg -~~~~~~~~~~~~~~~~~~~ - -The contents of the ``setup.cfg`` file should be correctly populated automatically, like so: - -.. code-block:: ini - - [develop] - script_dir=$base/lib/py_pubsub - [install] - install_scripts=$base/lib/py_pubsub - -This is simply telling `setuptools `__ to put your executables in ``lib``, because ``ros2 run`` will look for them there. - -You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. - -3 Write the subscriber node -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Return to ``ros2_ws/src/py_pubsub/py_pubsub`` to create the next node. -Enter the following code in your terminal: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py - - .. group-tab:: macOS - - .. code-block:: console - - $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py - - .. group-tab:: Windows - - In a Windows command line prompt: - - .. code-block:: console - - $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py - - Or in powershell: - - .. code-block:: console - - $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py - -Now the directory should have these files: - -.. code-block:: console - - __init__.py publisher_member_function.py subscriber_member_function.py - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -Open the ``subscriber_member_function.py`` with your text editor. - -.. code-block:: python - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - from std_msgs.msg import String - - - class MinimalSubscriber(Node): - - def __init__(self): - super().__init__('minimal_subscriber') - self.subscription = self.create_subscription( - String, - 'topic', - self.listener_callback, - 10) - self.subscription # prevent unused variable warning - - def listener_callback(self, msg): - self.get_logger().info('I heard: "%s"' % msg.data) - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_subscriber = MinimalSubscriber() - - rclpy.spin(minimal_subscriber) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -The subscriber node's code is nearly identical to the publisher's. -The constructor creates a subscriber with the same arguments as the publisher using `create_subscription <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_subscription>`__. -Recall from the :doc:`topics tutorial <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. - -.. code-block:: python - - self.subscription = self.create_subscription( - String, - 'topic', - self.listener_callback, - 10) - -The subscriber's constructor and callback don't include any timer definition, because it doesn't need one. -Its callback gets called as soon as it receives a message. - -The callback definition simply prints an info message to the console, along with the data it received. -Recall that the publisher defines ``msg.data = 'Hello World: %d' % self.i`` - -.. code-block:: python - - def listener_callback(self, msg): - self.get_logger().info('I heard: "%s"' % msg.data) - -The ``main`` definition is almost exactly the same, replacing the creation and spinning of the publisher with the subscriber. - -.. code-block:: python - - minimal_subscriber = MinimalSubscriber() - - rclpy.spin(minimal_subscriber) - -Since this node has the same dependencies as the publisher, there's nothing new to add to ``package.xml``. -The ``setup.cfg`` file can also remain untouched. - - -3.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Reopen ``setup.py`` and add the entry point for the subscriber node below the publisher's entry point. -The `entry_points `__ field should now look like this: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'talker = py_pubsub.publisher_member_function:main', - 'listener = py_pubsub.subscriber_member_function:main', - ], - }, - -Make sure to save the file, and then your pub/sub system should be ready. - -4 Build and run -^^^^^^^^^^^^^^^ -You likely already have the {package(rclpy)} and {package(std_msgs)} packages installed as part of your ROS 2 system. -It's good practice to run `rosdep `__ (check the :doc:`rosdep tutorial `) in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Still in the root of your workspace, ``ros2_ws``, build your new package: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ colcon build --packages-select py_pubsub - - .. group-tab:: macOS - - .. code-block:: console - - $ colcon build --packages-select py_pubsub - - .. group-tab:: Windows - - .. code-block:: console - - $ colcon build --merge-install --packages-select py_pubsub - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the talker node. -The terminal should start publishing info messages every 0.5 seconds, like so: - -.. code-block:: console - - $ ros2 run py_pubsub talker - [info] [minimal_publisher]: publishing: "hello world: 0" - [info] [minimal_publisher]: publishing: "hello world: 1" - [info] [minimal_publisher]: publishing: "hello world: 2" - [info] [minimal_publisher]: publishing: "hello world: 3" - [info] [minimal_publisher]: publishing: "hello world: 4" - ... - -Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. -The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: - -.. code-block:: console - - $ ros2 run py_pubsub listener - [INFO] [minimal_subscriber]: I heard: "Hello World: 10" - [INFO] [minimal_subscriber]: I heard: "Hello World: 11" - [INFO] [minimal_subscriber]: I heard: "Hello World: 12" - [INFO] [minimal_subscriber]: I heard: "Hello World: 13" - [INFO] [minimal_subscriber]: I heard: "Hello World: 14" - -Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. - -Summary -------- - -You created two nodes to publish and subscribe to data over a topic. -Before running them, you added their dependencies and entry points to the package configuration files. - -Next steps ----------- - -Next you'll create another simple ROS 2 package using the service/client model. -Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Writing-A-Simple-Py-Publisher-And-Subscriber + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber + +.. _PyPubSub: + +Writing a simple publisher and subscriber (Python) +================================================== + +**Goal:** Create and run a publisher and subscriber node using Python. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +In this tutorial, you will create :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that pass information in the form of string messages to each other over a :doc:`topic <../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. +The example used here is a simple "talker" and "listener" system; +one node publishes data and the other subscribes to the topic so it can receive that data. + +The code used in these examples can be found `here `__. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +A basic understanding of Python is recommended, but not entirely necessary. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +So, navigate into ``ros2_ws/src``, and run the package creation command: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_pubsub + +Your terminal will return a message verifying the creation of your package ``py_pubsub`` and all its necessary files and folders. + +2 Write the publisher node +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Navigate into ``ros2_ws/src/py_pubsub/py_pubsub``. +Recall that this directory is a `Python package `__ with the same name as the ROS 2 package it's nested in. + +Download the example talker code by entering the following command: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_publisher/examples_rclpy_minimal_publisher/publisher_member_function.py -o publisher_member_function.py + +Now there will be a new file named ``publisher_member_function.py`` adjacent to ``__init__.py``. + +Open the file using your preferred text editor. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from std_msgs.msg import String + + + class MinimalPublisher(Node): + + def __init__(self): + super().__init__('minimal_publisher') + self.publisher_ = self.create_publisher(String, 'topic', 10) + timer_period = 0.5 # seconds + self.timer = self.create_timer(timer_period, self.timer_callback) + self.i = 0 + + def timer_callback(self): + msg = String() + msg.data = 'Hello World: %d' % self.i + self.publisher_.publish(msg) + self.get_logger().info('Publishing: "%s"' % msg.data) + self.i += 1 + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_publisher = MinimalPublisher() + + rclpy.spin(minimal_publisher) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The first lines of code after the comments import {package(rclpy)} so its `Node <{package_link(rclpy)}api/node.html>`__ class can be used. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The next statement imports the built-in {interface(std_msgs/msg/String)} message type that the node uses to structure the data that it passes on the topic. + +.. code-block:: python + + from std_msgs.msg import String + +These lines represent the node's dependencies. +Recall that dependencies have to be added to ``package.xml``, which you'll do in the next section. + +Next, the ``MinimalPublisher`` class is created, which inherits from (or is a subclass of) `Node <{package_link(rclpy)}api/node.html>`__. + +.. code-block:: python + + class MinimalPublisher(Node): + +Following is the definition of the class's constructor. +``super().__init__`` calls the `Node <{package_link(rclpy)}api/node.html>`__ class's constructor and gives it your node name, in this case ``minimal_publisher``. + +`create_publisher <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_publisher>`__ declares that the node publishes messages of type {interface(std_msgs/msg/String)} (imported from the ``std_msgs.msg`` module), over a topic named ``topic``, and that the "queue size" is 10. +Queue size is a required :doc:`Quality of Service <../../interfaces/topics/About-Quality-of-Service-Settings>` (QoS) setting that limits the amount of queued messages if a subscriber is not receiving them fast enough. + +Next, `create_timer <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_timer>`__ is used to create a callback that executes every 0.5 seconds. +``self.i`` is a counter used in the callback. + +.. code-block:: python + + def __init__(self): + super().__init__('minimal_publisher') + self.publisher_ = self.create_publisher(String, 'topic', 10) + timer_period = 0.5 # seconds + self.timer = self.create_timer(timer_period, self.timer_callback) + self.i = 0 + +``timer_callback`` creates a message with the counter value appended, publishes it, and prints it to the console with `get_logger() <{package_link(rclpy)}api/node.html#rclpy.node.Node.get_logger>`__'s `info() <{package_link(rclpy)}rclpy.impl.rcutils_logger.html#rclpy.impl.rcutils_logger.RcutilsLogger.info>`__ function. + +.. code-block:: python + + def timer_callback(self): + msg = String() + msg.data = 'Hello World: %d' % self.i + self.publisher_.publish(msg) + self.get_logger().info('Publishing: "%s"' % msg.data) + self.i += 1 + +Lastly, the main function is defined. + +.. code-block:: python + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_publisher = MinimalPublisher() + + rclpy.spin(minimal_publisher) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + +First the {package(rclpy)} library is initialized, then the node is created, and then it "spins" the node (using `spin() <{package_link(rclpy)}api/init_shutdown.html#rclpy.spin>`__) so its callbacks are called. + +2.2 Add dependencies +~~~~~~~~~~~~~~~~~~~~ + +Navigate one level back to the ``ros2_ws/src/py_pubsub`` directory, where the ``setup.py``, ``setup.cfg``, and ``package.xml`` files have been created for you. + +Open ``package.xml`` with your text editor. + +As mentioned in the :doc:`previous tutorial `, make sure to fill in the ````, ```` and ```` tags: + +.. code-block:: xml + + Examples of minimal publisher/subscriber using rclpy + Your Name + Apache-2.0 + +After the lines above, add the following dependencies corresponding to your node's import statements: + +.. code-block:: xml + + rclpy + std_msgs + +This declares the package needs {package(rclpy)} and {package(std_msgs)} when its code is executed. + +Make sure to save the file. + +2.3 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Open the ``setup.py`` file. +Again, match the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields to your ``package.xml``: + +.. code-block:: python + + maintainer='YourName', + maintainer_email='you@email.com', + description='Examples of minimal publisher/subscriber using rclpy', + license='Apache-2.0', + +Add the following line within the ``console_scripts`` brackets of the `entry_points `__ field: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'talker = py_pubsub.publisher_member_function:main', + ], + }, + +Don't forget to save. + +2.4 Check setup.cfg +~~~~~~~~~~~~~~~~~~~ + +The contents of the ``setup.cfg`` file should be correctly populated automatically, like so: + +.. code-block:: ini + + [develop] + script_dir=$base/lib/py_pubsub + [install] + install_scripts=$base/lib/py_pubsub + +This is simply telling `setuptools `__ to put your executables in ``lib``, because ``ros2 run`` will look for them there. + +You could build your package now, source the local setup files, and run it, but let's create the subscriber node first so you can see the full system at work. + +3 Write the subscriber node +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Return to ``ros2_ws/src/py_pubsub/py_pubsub`` to create the next node. +Enter the following code in your terminal: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py + + .. group-tab:: macOS + + .. code-block:: console + + $ wget https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py + + .. group-tab:: Windows + + In a Windows command line prompt: + + .. code-block:: console + + $ curl -sk https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py + + Or in powershell: + + .. code-block:: console + + $ curl https://raw.githubusercontent.com/ros2/examples/{REPOS_FILE_BRANCH}/rclpy/topics/minimal_subscriber/examples_rclpy_minimal_subscriber/subscriber_member_function.py -o subscriber_member_function.py + +Now the directory should have these files: + +.. code-block:: console + + __init__.py publisher_member_function.py subscriber_member_function.py + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +Open the ``subscriber_member_function.py`` with your text editor. + +.. code-block:: python + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + from std_msgs.msg import String + + + class MinimalSubscriber(Node): + + def __init__(self): + super().__init__('minimal_subscriber') + self.subscription = self.create_subscription( + String, + 'topic', + self.listener_callback, + 10) + self.subscription # prevent unused variable warning + + def listener_callback(self, msg): + self.get_logger().info('I heard: "%s"' % msg.data) + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_subscriber = MinimalSubscriber() + + rclpy.spin(minimal_subscriber) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +The subscriber node's code is nearly identical to the publisher's. +The constructor creates a subscriber with the same arguments as the publisher using `create_subscription <{package_link(rclpy)}api/node.html#rclpy.node.Node.create_subscription>`__. +Recall from the :doc:`topics tutorial <../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>` that the topic name and message type used by the publisher and subscriber must match to allow them to communicate. + +.. code-block:: python + + self.subscription = self.create_subscription( + String, + 'topic', + self.listener_callback, + 10) + +The subscriber's constructor and callback don't include any timer definition, because it doesn't need one. +Its callback gets called as soon as it receives a message. + +The callback definition simply prints an info message to the console, along with the data it received. +Recall that the publisher defines ``msg.data = 'Hello World: %d' % self.i`` + +.. code-block:: python + + def listener_callback(self, msg): + self.get_logger().info('I heard: "%s"' % msg.data) + +The ``main`` definition is almost exactly the same, replacing the creation and spinning of the publisher with the subscriber. + +.. code-block:: python + + minimal_subscriber = MinimalSubscriber() + + rclpy.spin(minimal_subscriber) + +Since this node has the same dependencies as the publisher, there's nothing new to add to ``package.xml``. +The ``setup.cfg`` file can also remain untouched. + + +3.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Reopen ``setup.py`` and add the entry point for the subscriber node below the publisher's entry point. +The `entry_points `__ field should now look like this: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'talker = py_pubsub.publisher_member_function:main', + 'listener = py_pubsub.subscriber_member_function:main', + ], + }, + +Make sure to save the file, and then your pub/sub system should be ready. + +4 Build and run +^^^^^^^^^^^^^^^ +You likely already have the {package(rclpy)} and {package(std_msgs)} packages installed as part of your ROS 2 system. +It's good practice to run `rosdep `__ (check the :doc:`rosdep tutorial `) in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Still in the root of your workspace, ``ros2_ws``, build your new package: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ colcon build --packages-select py_pubsub + + .. group-tab:: macOS + + .. code-block:: console + + $ colcon build --packages-select py_pubsub + + .. group-tab:: Windows + + .. code-block:: console + + $ colcon build --merge-install --packages-select py_pubsub + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the talker node. +The terminal should start publishing info messages every 0.5 seconds, like so: + +.. code-block:: console + + $ ros2 run py_pubsub talker + [info] [minimal_publisher]: publishing: "hello world: 0" + [info] [minimal_publisher]: publishing: "hello world: 1" + [info] [minimal_publisher]: publishing: "hello world: 2" + [info] [minimal_publisher]: publishing: "hello world: 3" + [info] [minimal_publisher]: publishing: "hello world: 4" + ... + +Open another terminal, source the setup files from inside ``ros2_ws`` again, and then start the listener node. +The listener will start printing messages to the console, starting at whatever message count the publisher is on at that time, like so: + +.. code-block:: console + + $ ros2 run py_pubsub listener + [INFO] [minimal_subscriber]: I heard: "Hello World: 10" + [INFO] [minimal_subscriber]: I heard: "Hello World: 11" + [INFO] [minimal_subscriber]: I heard: "Hello World: 12" + [INFO] [minimal_subscriber]: I heard: "Hello World: 13" + [INFO] [minimal_subscriber]: I heard: "Hello World: 14" + +Enter ``Ctrl+C`` in each terminal to stop the nodes from spinning. + +Summary +------- + +You created two nodes to publish and subscribe to data over a topic. +Before running them, you added their dependencies and entry points to the package configuration files. + +Next steps +---------- + +Next you'll create another simple ROS 2 package using the service/client model. +Again, you can choose to write it in either :doc:`C++ ` or :doc:`Python `. + +Related content +--------------- + There are several ways you could write a publisher and subscriber in Python; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. \ No newline at end of file diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst index 689a10cea43..6ed570d5cfc 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst @@ -1,395 +1,395 @@ -.. redirect-from:: - - Tutorials/Writing-A-Simple-Py-Service-And-Client - Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client - -.. _PySrvCli: - -Writing a simple service and client (Python) -============================================ - -**Goal:** Create and run service and client nodes using Python. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -When :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. -The structure of the request and response is determined by a ``.srv`` file. - -The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. - -Prerequisites -------------- - -In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. - -Tasks ------ - -1 Create a package -^^^^^^^^^^^^^^^^^^ - -Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. - -Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. - -Recall that packages should be created in the ``src`` directory, not the root of the workspace. -Navigate into ``ros2_ws/src`` and create a new package: - -.. code-block:: console - - $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_srvcli --dependencies rclpy example_interfaces - -Your terminal will return a message verifying the creation of your package ``py_srvcli`` and all its necessary files and folders. - -The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. -``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: - -.. code-block:: bash - - int64 a - int64 b - --- - int64 sum - -The first two lines are the parameters of the request, and below the dashes is the response. - -1.1 Update ``package.xml`` -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. - -As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. - -.. code-block:: xml - - Python client server tutorial - Your Name - Apache-2.0 - -1.2 Update ``setup.py`` -~~~~~~~~~~~~~~~~~~~~~~~ - -Add the same information to the ``setup.py`` file for the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields: - -.. code-block:: python - - maintainer='Your Name', - maintainer_email='you@email.com', - description='Python client server tutorial', - license='Apache-2.0', - -2 Write the service node -^^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``service_member_function.py`` and paste the following code within: - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalService(Node): - - def __init__(self): - super().__init__('minimal_service') - self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) - - def add_two_ints_callback(self, request, response): - response.sum = request.a + request.b - self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) - - return response - - - def main(): - try: - with rclpy.init(): - minimal_service = MinimalService() - - rclpy.spin(minimal_service) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -2.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -The first ``import`` statement imports the ``AddTwoInts`` service type from the ``example_interfaces`` package. -The following ``import`` statements import the necessary ROS 2 Python client library interfaces. - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The ``MinimalService`` class constructor initializes the node with the name ``minimal_service``. -Then, it creates a service and defines the type, name, and callback. - -.. code-block:: python - - def __init__(self): - super().__init__('minimal_service') - self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) - -The definition of the service callback receives the request data, sums it, and returns the sum as a response. - -.. code-block:: python - - def add_two_ints_callback(self, request, response): - response.sum = request.a + request.b - self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) - - return response - -Finally, the main class initializes the ROS 2 Python client library, instantiates the ``MinimalService`` class to create the service node and spins the node to handle callbacks. - -2.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``ros2_ws/src/py_srvcli`` directory). - -Add the following line between the ``'console_scripts':`` brackets: - -.. code-block:: python - - 'service = py_srvcli.service_member_function:main', - -3 Write the client node -^^^^^^^^^^^^^^^^^^^^^^^ - -Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``client_member_function.py`` and paste the following code within: - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - - class MinimalClientAsync(Node): - - def __init__(self): - super().__init__('minimal_client_async') - self.cli = self.create_client(AddTwoInts, 'add_two_ints') - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddTwoInts.Request() - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - return self.cli.call_async(self.req) - - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_client = MinimalClientAsync() - future = minimal_client.send_request() - rclpy.spin_until_future_complete(minimal_client, future) - response = future.result() - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - - -3.1 Examine the code -~~~~~~~~~~~~~~~~~~~~ - -As with the service code, we first ``import`` the necessary libraries. - -.. code-block:: python - - from example_interfaces.srv import AddTwoInts - - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - -The ``MinimalClientAsync`` class constructor initializes the node with the name ``minimal_client_async``. -The constructor definition creates a client with the same type and name as the service node. -The type and name must match for the client and service to be able to communicate. -The ``while`` loop in the constructor checks if a service matching the type and name of the client is available once a second. -Finally it creates a new ``AddTwoInts`` request object. - -.. code-block:: python - - def __init__(self): - super().__init__('minimal_client_async') - self.cli = self.create_client(AddTwoInts, 'add_two_ints') - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddTwoInts.Request() - -Below the constructor is the ``send_request`` method, which will send the request and spin until it receives the response or fails. - -.. code-block:: python - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - return self.cli.call_async(self.req) - -Finally we have the ``main`` method, which constructs a ``MinimalClientAsync`` object, sends the request using the passed-in command-line arguments, calls ``rclpy.spin_until_future_complete`` to wait for the result, and logs the results. - -.. code-block:: python - - def main(args=None): - try: - with rclpy.init(args=args): - minimal_client = MinimalClientAsync() - future = minimal_client.send_request() - rclpy.spin_until_future_complete(minimal_client, future) - response = future.result() - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - except (KeyboardInterrupt, ExternalShutdownException): - pass - -.. warning:: - - Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. - For more details see the :doc:`sync deadlock article <../../services/Working-with-services/Sync-Vs-Async>`. - -3.2 Add an entry point -~~~~~~~~~~~~~~~~~~~~~~ - -Like the service node, you also have to add an entry point to be able to run the client node. - -The ``entry_points`` field of your ``setup.py`` file should look like this: - -.. code-block:: python - - entry_points={ - 'console_scripts': [ - 'service = py_srvcli.service_member_function:main', - 'client = py_srvcli.client_member_function:main', - ], - }, - -4 Build and run -^^^^^^^^^^^^^^^ - -It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ rosdep install -i --from-path src --rosdistro {DISTRO} -y - - .. group-tab:: macOS - - rosdep only runs on Linux, so you can skip ahead to next step. - - .. group-tab:: Windows - - rosdep only runs on Linux, so you can skip ahead to next step. - - -Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: - -.. code-block:: console - - $ colcon build --packages-select py_srvcli - -Open a new terminal, navigate to ``ros2_ws``, and source the setup files: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . install/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call install/setup.bat - -Now run the service node: - -.. code-block:: console - - $ ros2 run py_srvcli service - -The node will wait for the client's request. - -Open another terminal and source the setup files from inside ``ros2_ws`` again. -Start the client node. -The client sends the request to the service, which computes the sum and returns the result: - -.. code-block:: console - - $ ros2 run py_srvcli client - [INFO] [minimal_client_async]: Result of add_two_ints: for 41 + 1 = 42 - -Return to the terminal where your service node is running. -You will see that it published log messages when it received the request: - -.. code-block:: console - - [INFO] [minimal_service]: Incoming request - a: 41 b: 1 - -Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. - - -Summary -------- - -You created two nodes to request and respond to data over a service. -You added their dependencies and executables to the package configuration files so that you could build and run them, allowing you to see a service/client system at work. - -Next steps ----------- - -In the last few tutorials you've been utilizing interfaces to pass data across topics and services. -Next, you'll learn how to :doc:`create custom interfaces `. - -Related content ---------------- - -* There are several ways you could write a service and client in Python; check out the ``minimal_client`` and ``minimal_service`` packages in the `ros2/examples `_ repo. - -* In this tutorial, you used the ``call_async()`` API in your client node to call the service. - There is another service call API available for Python called synchronous calls. - We do not recommend using synchronous calls, but if you'd like to learn more about them, read the guide to :doc:`Synchronous vs. asynchronous clients <../../services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file +.. redirect-from:: + + Tutorials/Writing-A-Simple-Py-Service-And-Client + Tutorials/Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client + +.. _PySrvCli: + +Writing a simple service and client (Python) +============================================ + +**Goal:** Create and run service and client nodes using Python. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +When :doc:`nodes <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` communicate using :doc:`services <../../interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>`, the node that sends a request for data is called the client node, and the one that responds to the request is the service node. +The structure of the request and response is determined by a ``.srv`` file. + +The example used here is a simple integer addition system; one node requests the sum of two integers, and the other responds with the result. + +Prerequisites +------------- + +In previous tutorials, you learned how to :doc:`create a workspace ` and :doc:`create a package `. + +Tasks +----- + +1 Create a package +^^^^^^^^^^^^^^^^^^ + +Open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. + +Navigate into the ``ros2_ws`` directory created in a :ref:`previous tutorial `. + +Recall that packages should be created in the ``src`` directory, not the root of the workspace. +Navigate into ``ros2_ws/src`` and create a new package: + +.. code-block:: console + + $ ros2 pkg create --build-type ament_python --license Apache-2.0 py_srvcli --dependencies rclpy example_interfaces + +Your terminal will return a message verifying the creation of your package ``py_srvcli`` and all its necessary files and folders. + +The ``--dependencies`` argument will automatically add the necessary dependency lines to ``package.xml``. +``example_interfaces`` is the package that includes `the .srv file `__ you will need to structure your requests and responses: + +.. code-block:: bash + + int64 a + int64 b + --- + int64 sum + +The first two lines are the parameters of the request, and below the dashes is the response. + +1.1 Update ``package.xml`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because you used the ``--dependencies`` option during package creation, you don't have to manually add dependencies to ``package.xml``. + +As always, though, make sure to add the description, maintainer email and name, and license information to ``package.xml``. + +.. code-block:: xml + + Python client server tutorial + Your Name + Apache-2.0 + +1.2 Update ``setup.py`` +~~~~~~~~~~~~~~~~~~~~~~~ + +Add the same information to the ``setup.py`` file for the ``maintainer``, ``maintainer_email``, ``description`` and ``license`` fields: + +.. code-block:: python + + maintainer='Your Name', + maintainer_email='you@email.com', + description='Python client server tutorial', + license='Apache-2.0', + +2 Write the service node +^^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``service_member_function.py`` and paste the following code within: + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalService(Node): + + def __init__(self): + super().__init__('minimal_service') + self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) + + def add_two_ints_callback(self, request, response): + response.sum = request.a + request.b + self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) + + return response + + + def main(): + try: + with rclpy.init(): + minimal_service = MinimalService() + + rclpy.spin(minimal_service) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +2.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +The first ``import`` statement imports the ``AddTwoInts`` service type from the ``example_interfaces`` package. +The following ``import`` statements import the necessary ROS 2 Python client library interfaces. + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The ``MinimalService`` class constructor initializes the node with the name ``minimal_service``. +Then, it creates a service and defines the type, name, and callback. + +.. code-block:: python + + def __init__(self): + super().__init__('minimal_service') + self.srv = self.create_service(AddTwoInts, 'add_two_ints', self.add_two_ints_callback) + +The definition of the service callback receives the request data, sums it, and returns the sum as a response. + +.. code-block:: python + + def add_two_ints_callback(self, request, response): + response.sum = request.a + request.b + self.get_logger().info('Incoming request\na: %d b: %d' % (request.a, request.b)) + + return response + +Finally, the main class initializes the ROS 2 Python client library, instantiates the ``MinimalService`` class to create the service node and spins the node to handle callbacks. + +2.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +To allow the ``ros2 run`` command to run your node, you must add the entry point to ``setup.py`` (located in the ``ros2_ws/src/py_srvcli`` directory). + +Add the following line between the ``'console_scripts':`` brackets: + +.. code-block:: python + + 'service = py_srvcli.service_member_function:main', + +3 Write the client node +^^^^^^^^^^^^^^^^^^^^^^^ + +Inside the ``ros2_ws/src/py_srvcli/py_srvcli`` directory, create a new file called ``client_member_function.py`` and paste the following code within: + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + + class MinimalClientAsync(Node): + + def __init__(self): + super().__init__('minimal_client_async') + self.cli = self.create_client(AddTwoInts, 'add_two_ints') + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddTwoInts.Request() + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + return self.cli.call_async(self.req) + + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_client = MinimalClientAsync() + future = minimal_client.send_request() + rclpy.spin_until_future_complete(minimal_client, future) + response = future.result() + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + + +3.1 Examine the code +~~~~~~~~~~~~~~~~~~~~ + +As with the service code, we first ``import`` the necessary libraries. + +.. code-block:: python + + from example_interfaces.srv import AddTwoInts + + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + +The ``MinimalClientAsync`` class constructor initializes the node with the name ``minimal_client_async``. +The constructor definition creates a client with the same type and name as the service node. +The type and name must match for the client and service to be able to communicate. +The ``while`` loop in the constructor checks if a service matching the type and name of the client is available once a second. +Finally it creates a new ``AddTwoInts`` request object. + +.. code-block:: python + + def __init__(self): + super().__init__('minimal_client_async') + self.cli = self.create_client(AddTwoInts, 'add_two_ints') + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddTwoInts.Request() + +Below the constructor is the ``send_request`` method, which will send the request and spin until it receives the response or fails. + +.. code-block:: python + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + return self.cli.call_async(self.req) + +Finally we have the ``main`` method, which constructs a ``MinimalClientAsync`` object, sends the request using the passed-in command-line arguments, calls ``rclpy.spin_until_future_complete`` to wait for the result, and logs the results. + +.. code-block:: python + + def main(args=None): + try: + with rclpy.init(args=args): + minimal_client = MinimalClientAsync() + future = minimal_client.send_request() + rclpy.spin_until_future_complete(minimal_client, future) + response = future.result() + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + except (KeyboardInterrupt, ExternalShutdownException): + pass + +.. warning:: + + Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. + For more details see the :doc:`sync deadlock article <../../interfaces/services/Working-with-services/Sync-Vs-Async>`. + +3.2 Add an entry point +~~~~~~~~~~~~~~~~~~~~~~ + +Like the service node, you also have to add an entry point to be able to run the client node. + +The ``entry_points`` field of your ``setup.py`` file should look like this: + +.. code-block:: python + + entry_points={ + 'console_scripts': [ + 'service = py_srvcli.service_member_function:main', + 'client = py_srvcli.client_member_function:main', + ], + }, + +4 Build and run +^^^^^^^^^^^^^^^ + +It's good practice to run ``rosdep`` in the root of your workspace (``ros2_ws``) to check for missing dependencies before building: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ rosdep install -i --from-path src --rosdistro {DISTRO} -y + + .. group-tab:: macOS + + rosdep only runs on Linux, so you can skip ahead to next step. + + .. group-tab:: Windows + + rosdep only runs on Linux, so you can skip ahead to next step. + + +Navigate back to the root of your workspace, ``ros2_ws``, and build your new package: + +.. code-block:: console + + $ colcon build --packages-select py_srvcli + +Open a new terminal, navigate to ``ros2_ws``, and source the setup files: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . install/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call install/setup.bat + +Now run the service node: + +.. code-block:: console + + $ ros2 run py_srvcli service + +The node will wait for the client's request. + +Open another terminal and source the setup files from inside ``ros2_ws`` again. +Start the client node. +The client sends the request to the service, which computes the sum and returns the result: + +.. code-block:: console + + $ ros2 run py_srvcli client + [INFO] [minimal_client_async]: Result of add_two_ints: for 41 + 1 = 42 + +Return to the terminal where your service node is running. +You will see that it published log messages when it received the request: + +.. code-block:: console + + [INFO] [minimal_service]: Incoming request + a: 41 b: 1 + +Enter ``Ctrl+C`` in the server terminal to stop the node from spinning. + + +Summary +------- + +You created two nodes to request and respond to data over a service. +You added their dependencies and executables to the package configuration files so that you could build and run them, allowing you to see a service/client system at work. + +Next steps +---------- + +In the last few tutorials you've been utilizing interfaces to pass data across topics and services. +Next, you'll learn how to :doc:`create custom interfaces `. + +Related content +--------------- + +* There are several ways you could write a service and client in Python; check out the ``minimal_client`` and ``minimal_service`` packages in the `ros2/examples `_ repo. + +* In this tutorial, you used the ``call_async()`` API in your client node to call the service. + There is another service call API available for Python called synchronous calls. + We do not recommend using synchronous calls, but if you'd like to learn more about them, read the guide to :doc:`Synchronous vs. asynchronous clients <../../interfaces/services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file diff --git a/source/ROS-Framework/About-Actions.rst b/source/ROS-Framework/interfaces/About-Actions.rst similarity index 100% rename from source/ROS-Framework/About-Actions.rst rename to source/ROS-Framework/interfaces/About-Actions.rst diff --git a/source/ROS-Framework/About-Interfaces.rst b/source/ROS-Framework/interfaces/About-Interfaces.rst similarity index 94% rename from source/ROS-Framework/About-Interfaces.rst rename to source/ROS-Framework/interfaces/About-Interfaces.rst index 1c3f1bd9e2a..dcac18f1f8e 100644 --- a/source/ROS-Framework/About-Interfaces.rst +++ b/source/ROS-Framework/interfaces/About-Interfaces.rst @@ -1,317 +1,314 @@ -.. redirect-from:: - - About-ROS-Interfaces - Concepts/About-ROS-Interfaces - Concepts/Basic/About-Interfaces - -Interfaces -========== - -.. toctree:: - :maxdepth: 1 - :hidden: - - interfaces/Interfaces-Topics-Services-Actions - interfaces/Topics-Services-Actions - interfaces/About-Tf2/About-Tf2 - interfaces/Working-with-interfaces - -.. contents:: Table of Contents - :local: - -Background ----------- - -ROS applications typically communicate through interfaces of one of three types: :doc:`topics `, :doc:`services `, or :doc:`actions `. -ROS 2 uses a simplified description language, the interface definition language (IDL), to describe these interfaces. -This description makes it easy for ROS tools to automatically generate source code for the interface type in several target languages. - -In this document we will describe the supported types: - -* msg: ``.msg`` files are simple text files that describe the fields of a ROS message. - They are used to generate source code for messages in different languages. -* srv: ``.srv`` files describe a service. - They are composed of two parts: a request and a response. - The request and response are message declarations. -* action: ``.action`` files describe actions. - They are composed of three parts: a goal, a result, and feedback. - Each part is a message declaration itself. - -Messages --------- - -Messages are a way for a ROS 2 node to send data on the network to other ROS nodes, with no response expected. -For instance, if a ROS 2 node reads temperature data from a sensor, it can then publish that data on the ROS 2 network using a ``Temperature`` message. -Other nodes on the ROS 2 network can subscribe to that data and receive the ``Temperature`` message. - -Messages are described and defined in ``.msg`` files in the ``msg/`` directory of a ROS package. -``.msg`` files are composed of two parts: fields and constants. - -Fields -^^^^^^ - -Each field consists of a type and a name, separated by a space, i.e: - -.. code-block:: bash - - fieldtype1 fieldname1 - fieldtype2 fieldname2 - fieldtype3 fieldname3 - -For example: - -.. code-block:: bash - - int32 my_int - string my_string - -Field types -~~~~~~~~~~~ - -Field types can be: - -* a built-in-type -* names of Message descriptions defined on their own, such as "geometry_msgs/PoseStamped" - -*Built-in-types currently supported:* - -.. list-table:: - :header-rows: 1 - - * - Type name - - `C++ `__ - - `Python `__ - - `DDS type `__ - * - bool - - bool - - builtins.bool - - boolean - * - byte - - uint8_t - - builtins.bytes* - - octet - * - char - - char - - builtins.int* - - char - * - float32 - - float - - builtins.float* - - float - * - float64 - - double - - builtins.float* - - double - * - int8 - - int8_t - - builtins.int* - - octet - * - uint8 - - uint8_t - - builtins.int* - - octet - * - int16 - - int16_t - - builtins.int* - - short - * - uint16 - - uint16_t - - builtins.int* - - unsigned short - * - int32 - - int32_t - - builtins.int* - - long - * - uint32 - - uint32_t - - builtins.int* - - unsigned long - * - int64 - - int64_t - - builtins.int* - - long long - * - uint64 - - uint64_t - - builtins.int* - - unsigned long long - * - string - - std::string - - builtins.str - - string - * - wstring - - std::u16string - - builtins.str - - wstring - -*Every built-in-type can be used to define arrays:* - -.. list-table:: - :header-rows: 1 - - * - Type name - - `C++ `__ - - `Python `__ - - `DDS type `__ - * - static array - - std::array - - builtins.list* - - T[N] - * - unbounded dynamic array - - std::vector - - builtins.list - - sequence - * - bounded dynamic array - - custom_class - - builtins.list* - - sequence - * - bounded string - - std::string - - builtins.str* - - string - -(*) All types that are more permissive than their ROS definition enforce the ROS constraints in range and length by software. - -*Example of message definition using arrays and bounded types:* - -.. code-block:: bash - - int32[] unbounded_integer_array - int32[5] five_integers_array - int32[<=5] up_to_five_integers_array - - string string_of_unbounded_size - string<=10 up_to_ten_characters_string - - string[<=5] up_to_five_unbounded_strings - string<=10[] unbounded_array_of_strings_up_to_ten_characters_each - string<=10[<=5] up_to_five_strings_up_to_ten_characters_each - -Field names -~~~~~~~~~~~ - -Field names must be lowercase alphanumeric characters with underscores for separating words. -They must start with an alphabetic character, and they must not end with an underscore or have two consecutive underscores. - -Field default value -~~~~~~~~~~~~~~~~~~~ - -Default values can be set to any field in the message type. -Currently default values are not supported for string arrays and complex types (i.e. types not present in the built-in-types table above; that applies to all nested messages). - -Defining a default value is done by adding a third element to the field definition line, i.e: - -.. code-block:: bash - - fieldtype fieldname fielddefaultvalue - -For example: - -.. code-block:: bash - - uint8 x 42 - int16 y -2000 - string full_name "John Doe" - int32[] samples [-200, -100, 0, 100, 200] - -.. note:: - - * string values must be defined in single ``'`` or double ``"`` quotes - * currently string values are not escaped - -Constants -^^^^^^^^^ - -Each constant definition is like a field description with a default value, except that this value can never be changed programmatically. -This value assignment is indicated by use of an equal '=' sign, e.g. - -.. code-block:: bash - - constanttype CONSTANTNAME=constantvalue - -For example: - -.. code-block:: bash - - int32 X=123 - int32 Y=-123 - string FOO="foo" - string EXAMPLE='bar' - -.. note:: - - Constants names have to be UPPERCASE - -Services --------- - -Services are a request/response communication, where the client (requester) is waiting for the server (responder) to make a short computation and return a result. - -Services are described and defined in ``.srv`` files in the ``srv/`` directory of a ROS package. - -A service description file consists of a request and a response msg type, separated by ``---``. -Any two ``.msg`` files concatenated with a ``---`` are a legal service description. - -Here is a very simple example of a service that takes in a string and returns a string: - -.. code-block:: bash - - string str - --- - string str - -We can of course get much more complicated (if you want to refer to a message from the same package you must not mention the package name): - -.. code-block:: bash - - # request constants - int8 FOO=1 - int8 BAR=2 - # request fields - int8 foobar - another_pkg/AnotherMessage msg - --- - # response constants - uint32 SECRET=123456 - # response fields - another_pkg/YetAnotherMessage val - CustomMessageDefinedInThisPackage value - uint32 an_integer - -You cannot embed another service inside of a service. - -Actions -------- - -Actions are a long-running request/response communication, where the action client (requester) is waiting for the action server (the responder) to take some action and return a result. -In contrast to services, actions can be long-running (many seconds or minutes), provide feedback while they are happening, and can be interrupted. - -Action definitions have the following form: - -.. code:: - - - --- - - --- - - -Like services, the request fields are before and the response fields are after the first triple-dash (``---``), respectively. -There is also a third set of fields after the second triple-dash, which is the fields to be sent when sending feedback. - -There can be arbitrary numbers of request fields (including zero), arbitrary numbers of response fields (including zero), and arbitrary numbers of feedback fields (including zero). - -The ````, ````, and ```` follow all of the same rules as the ```` for a message. -The ````, ````, and ```` follow all of the same rules as the ```` for a message. - -For instance, the ``Fibonacci`` action definition contains the following: - -.. code:: - - int32 order - --- - int32[] sequence - --- - int32[] sequence - -This is an action definition where the action client is sending a single ``int32`` field representing the number of Fibonacci steps to take, and expecting the action server to produce an array of ``int32`` containing the complete steps. +.. redirect-from:: + + Concepts/Basic/About-Interfaces + +Interfaces +========== + +.. toctree:: + :maxdepth: 1 + :hidden: + + Topics-Services-Actions + About-Tf2/About-Tf2 + Working-with-interfaces + +.. contents:: Table of Contents + :local: + +Background +---------- + +ROS applications typically communicate through interfaces of one of three types: :doc:`topics `, :doc:`services `, or :doc:`actions `. +ROS 2 uses a simplified description language, the interface definition language (IDL), to describe these interfaces. +This description makes it easy for ROS tools to automatically generate source code for the interface type in several target languages. + +In this document we will describe the supported types: + +* msg: ``.msg`` files are simple text files that describe the fields of a ROS message. + They are used to generate source code for messages in different languages. +* srv: ``.srv`` files describe a service. + They are composed of two parts: a request and a response. + The request and response are message declarations. +* action: ``.action`` files describe actions. + They are composed of three parts: a goal, a result, and feedback. + Each part is a message declaration itself. + +Messages +-------- + +Messages are a way for a ROS 2 node to send data on the network to other ROS nodes, with no response expected. +For instance, if a ROS 2 node reads temperature data from a sensor, it can then publish that data on the ROS 2 network using a ``Temperature`` message. +Other nodes on the ROS 2 network can subscribe to that data and receive the ``Temperature`` message. + +Messages are described and defined in ``.msg`` files in the ``msg/`` directory of a ROS package. +``.msg`` files are composed of two parts: fields and constants. + +Fields +^^^^^^ + +Each field consists of a type and a name, separated by a space, i.e: + +.. code-block:: bash + + fieldtype1 fieldname1 + fieldtype2 fieldname2 + fieldtype3 fieldname3 + +For example: + +.. code-block:: bash + + int32 my_int + string my_string + +Field types +~~~~~~~~~~~ + +Field types can be: + +* a built-in-type +* names of Message descriptions defined on their own, such as "geometry_msgs/PoseStamped" + +*Built-in-types currently supported:* + +.. list-table:: + :header-rows: 1 + + * - Type name + - `C++ `__ + - `Python `__ + - `DDS type `__ + * - bool + - bool + - builtins.bool + - boolean + * - byte + - uint8_t + - builtins.bytes* + - octet + * - char + - char + - builtins.int* + - char + * - float32 + - float + - builtins.float* + - float + * - float64 + - double + - builtins.float* + - double + * - int8 + - int8_t + - builtins.int* + - octet + * - uint8 + - uint8_t + - builtins.int* + - octet + * - int16 + - int16_t + - builtins.int* + - short + * - uint16 + - uint16_t + - builtins.int* + - unsigned short + * - int32 + - int32_t + - builtins.int* + - long + * - uint32 + - uint32_t + - builtins.int* + - unsigned long + * - int64 + - int64_t + - builtins.int* + - long long + * - uint64 + - uint64_t + - builtins.int* + - unsigned long long + * - string + - std::string + - builtins.str + - string + * - wstring + - std::u16string + - builtins.str + - wstring + +*Every built-in-type can be used to define arrays:* + +.. list-table:: + :header-rows: 1 + + * - Type name + - `C++ `__ + - `Python `__ + - `DDS type `__ + * - static array + - std::array + - builtins.list* + - T[N] + * - unbounded dynamic array + - std::vector + - builtins.list + - sequence + * - bounded dynamic array + - custom_class + - builtins.list* + - sequence + * - bounded string + - std::string + - builtins.str* + - string + +(*) All types that are more permissive than their ROS definition enforce the ROS constraints in range and length by software. + +*Example of message definition using arrays and bounded types:* + +.. code-block:: bash + + int32[] unbounded_integer_array + int32[5] five_integers_array + int32[<=5] up_to_five_integers_array + + string string_of_unbounded_size + string<=10 up_to_ten_characters_string + + string[<=5] up_to_five_unbounded_strings + string<=10[] unbounded_array_of_strings_up_to_ten_characters_each + string<=10[<=5] up_to_five_strings_up_to_ten_characters_each + +Field names +~~~~~~~~~~~ + +Field names must be lowercase alphanumeric characters with underscores for separating words. +They must start with an alphabetic character, and they must not end with an underscore or have two consecutive underscores. + +Field default value +~~~~~~~~~~~~~~~~~~~ + +Default values can be set to any field in the message type. +Currently default values are not supported for string arrays and complex types (i.e. types not present in the built-in-types table above; that applies to all nested messages). + +Defining a default value is done by adding a third element to the field definition line, i.e: + +.. code-block:: bash + + fieldtype fieldname fielddefaultvalue + +For example: + +.. code-block:: bash + + uint8 x 42 + int16 y -2000 + string full_name "John Doe" + int32[] samples [-200, -100, 0, 100, 200] + +.. note:: + + * string values must be defined in single ``'`` or double ``"`` quotes + * currently string values are not escaped + +Constants +^^^^^^^^^ + +Each constant definition is like a field description with a default value, except that this value can never be changed programmatically. +This value assignment is indicated by use of an equal '=' sign, e.g. + +.. code-block:: bash + + constanttype CONSTANTNAME=constantvalue + +For example: + +.. code-block:: bash + + int32 X=123 + int32 Y=-123 + string FOO="foo" + string EXAMPLE='bar' + +.. note:: + + Constants names have to be UPPERCASE + +Services +-------- + +Services are a request/response communication, where the client (requester) is waiting for the server (responder) to make a short computation and return a result. + +Services are described and defined in ``.srv`` files in the ``srv/`` directory of a ROS package. + +A service description file consists of a request and a response msg type, separated by ``---``. +Any two ``.msg`` files concatenated with a ``---`` are a legal service description. + +Here is a very simple example of a service that takes in a string and returns a string: + +.. code-block:: bash + + string str + --- + string str + +We can of course get much more complicated (if you want to refer to a message from the same package you must not mention the package name): + +.. code-block:: bash + + # request constants + int8 FOO=1 + int8 BAR=2 + # request fields + int8 foobar + another_pkg/AnotherMessage msg + --- + # response constants + uint32 SECRET=123456 + # response fields + another_pkg/YetAnotherMessage val + CustomMessageDefinedInThisPackage value + uint32 an_integer + +You cannot embed another service inside of a service. + +Actions +------- + +Actions are a long-running request/response communication, where the action client (requester) is waiting for the action server (the responder) to take some action and return a result. +In contrast to services, actions can be long-running (many seconds or minutes), provide feedback while they are happening, and can be interrupted. + +Action definitions have the following form: + +.. code:: + + + --- + + --- + + +Like services, the request fields are before and the response fields are after the first triple-dash (``---``), respectively. +There is also a third set of fields after the second triple-dash, which is the fields to be sent when sending feedback. + +There can be arbitrary numbers of request fields (including zero), arbitrary numbers of response fields (including zero), and arbitrary numbers of feedback fields (including zero). + +The ````, ````, and ```` follow all of the same rules as the ```` for a message. +The ````, ````, and ```` follow all of the same rules as the ```` for a message. + +For instance, the ``Fibonacci`` action definition contains the following: + +.. code:: + + int32 order + --- + int32[] sequence + --- + int32[] sequence + +This is an action definition where the action client is sending a single ``int32`` field representing the number of Fibonacci steps to take, and expecting the action server to produce an array of ``int32`` containing the complete steps. Along the way, the action server may also provide an intermediate array of ``int32`` containing the steps accomplished up until a certain point. \ No newline at end of file diff --git a/source/ROS-Framework/About-Services.rst b/source/ROS-Framework/interfaces/About-Services.rst similarity index 100% rename from source/ROS-Framework/About-Services.rst rename to source/ROS-Framework/interfaces/About-Services.rst diff --git a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst index ffd80def8d6..aa8fd2053ea 100644 --- a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst +++ b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst @@ -1,161 +1,161 @@ -.. redirect-from:: - - Concepts/About-Tf2 - Concepts/Intermediate/About-Tf2 - -Tf2 -=== - -.. contents:: Table of Contents - :local: - -Overview --------- - -tf2 is the transform library, which lets the user keep track of multiple coordinate frames over time. -tf2 maintains the relationship between coordinate frames in a tree structure buffered in time and lets the user transform points, vectors, etc. between any two coordinate frames at any desired point in time. - -.. image:: images/ros2_tf2_frames.png - -Properties of tf2 ------------------ - -A robotic system typically has many 3D coordinate frames that change over time, such as a world frame, base frame, gripper frame, head frame, etc. -tf2 keeps track of all these frames over time, and allows you to ask questions like: - -* Where was the head frame relative to the world frame 5 seconds ago? -* What is the pose of the object in my gripper relative to my base? -* What is the current pose of the base frame in the map frame? - -tf2 can operate in a distributed system. -This means all the information about the coordinate frames of a robot is available to all ROS 2 components on any computer in the system. -tf2 can have every component in your distributed system build its own transform information database or have a central node that gathers and stores all transform information. - -.. mermaid:: - - flowchart LR - E((Earth)) - E --> A[[Car A]] - E --> B[[Car B]] - E --> C{{Satellite C}} - E --> D((Moon D)) - -Publishing transforms -^^^^^^^^^^^^^^^^^^^^^ - -When publishing transforms we typically think of the transforms as the transform from one frame to the other. -The semantic difference is whether you are transforming data represented in a frame or transforming the frame itself. -These values are directly inverse. -Transforms published in the ``geometry_msgs/msg/Transform`` message represent the frame formulation. -Keep this in mind when debugging published transforms they are the inverse of what you will lookup depending on what direction you're traversing the transform tree. - -.. math:: - - - _{B}T^{data}_{A} = (_{B}T^{frame}_{A})^{-1} - -The TF library handles inverting these elements for you depending on which way you're traversing the transform tree. -For the rest of this document we will just use :math:`T^{data}` but the ``data`` is unwritten. - -Position -^^^^^^^^ - -If the driver in car :math:`A` observes something and a person on the ground wants to know where it is relative to it's position, you transform the observation from the source frame to the target frame. - -.. math:: - - _{E}T_{A} * P_{A}^{Obs} = P_{E}^{Obs} - - -Now if a person in car B wants to know where it is too you can compute the net transform. - - -.. math:: - - _{B}T_{E} * _{E}T_{A} * P_{A}^{Obs} = _{B}T_{A} * P_{A}^{Obs} = P_{B}^{Obs} - - -This is exactly what ``lookupTransform`` provides where ``A`` is the *source* ``frame_id`` and ``B`` is the *target* ``frame_id``. - -It is recommended to use the ``transform(target_frame, ...)`` methods when possible because they will read the *source* ``frame_id`` from the datatype and write out the *target* ``frame_id`` in the resulting datatype and the math will be taken care of internally. - -If :math:`P` is a ``Stamped`` datatype then :math:`_A` is it's ``frame_id``. - -As an example, if a root frame ``A`` is one meter below frame ``B`` the transform from ``A`` to ``B`` is positive. - -However when converting data from coordinate frame ``B`` to coordinate frame ``A`` you have to use the inverse of this value. -This can be seen as you'll be adding value to the height when you change to the lower reference frame. -However if you are transforming data from coordinate frame ``A`` into coordinate frame ``B`` the height is reduced because the new reference is higher. - -.. math:: - - - _{B}T_{A} = (_{B}{Tf}_{A})^{-1} - - -Velocity -^^^^^^^^ - -For representing ``Velocity`` we have three pieces of information. -:math:`V^{moving\_frame - reference\_frame}_{observing\_frame}` -This velocity represents the velocity between the moving frame and the reference frame. -And it is represented in the observing frame. - -For example a driver in Car A can report that they're driving forward (observed in A) at 1m/s (relative to earth) so that would be :math:`V_{A}^{A - E} = (1,0,0)` -Whereas that same velocity could be observed from the view point of the earth (lets assume the car is driving east and Earth is NED), it would be :math:`V_{E}^{A - E} = (0, 1, 0)` - -However transforms can show that these are actually the same with: - -.. math:: - - _{E}T_{A} * V_{A}^{A - E} = V_{E}^{A - E} - - -Velocities can be added or subtracted if they're represented in the same frame, in this case ``Obs``. - -.. math:: - - V_{Obs}^{A - C} = V_{Obs}^{A - B} + V_{Obs}^{D - C} - -Velocities can be "reversed" by inverting. - -.. math:: - - V_{Obs}^{A - C} = -(V_{Obs}^{C - A}) - -If you want to compare two velocities you must first transform them into the same observational frame first. - - -Tutorials ---------- - -We created a set of :doc:`tutorials <../../client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` that walks you through using tf2, step by step. -You can get started on the :doc:`introduction to tf2 <../Working-with-interfaces/Introduction-To-Tf2>` tutorial. -For a complete list of all tf2 and tf2-related tutorials check out the :doc:`tutorials <../../client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` page. - -There are essentially two main tasks that any user would use tf2 for, listening for transforms and broadcasting transforms. - -If you want to use tf2 to transform between coordinate frames, your nodes will need to listen for transforms. -What you will do is receive and buffer all coordinate frames that are broadcasted in the system, and query for specific transforms between frames. -Check out the "Writing a listener" tutorial :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp>` to learn more. - -To extend the capabilities of a robot, you will need to start broadcasting transforms. -Broadcasting transforms means to send out the relative pose of coordinate frames to the rest of the system. -A system can have many broadcasters that each provide information about a different part of the robot. -Check out the "Writing a broadcaster" tutorial :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp>` to learn more. - -In addition to that, tf2 can broadcast static transforms that do not change over time. -This mainly saves storage and lookup time, but also reduces the publishing overhead. -You should note that static transforms are published once and assumed to not change, so no history is stored. -If you want to define static transforms in your tf2 tree, take a look at the "Writing a static broadcaster" :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp>` tutorial. - -You can also learn how to add fixed and dynamic frames to your tf2 tree in the "Adding a frame" :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp>` tutorial. - -Once you are finished with the basic tutorials, you can move on to learn about tf2 and time. -The tf2 and time tutorial :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp>` teaches the basic principles of tf2 and time. -The advanced tutorial about tf2 and time :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp>` teaches the principles of time traveling with tf2. - -Paper ------ - +.. redirect-from:: + + Concepts/About-Tf2 + Concepts/Intermediate/About-Tf2 + +Tf2 +=== + +.. contents:: Table of Contents + :local: + +Overview +-------- + +tf2 is the transform library, which lets the user keep track of multiple coordinate frames over time. +tf2 maintains the relationship between coordinate frames in a tree structure buffered in time and lets the user transform points, vectors, etc. between any two coordinate frames at any desired point in time. + +.. image:: images/ros2_tf2_frames.png + +Properties of tf2 +----------------- + +A robotic system typically has many 3D coordinate frames that change over time, such as a world frame, base frame, gripper frame, head frame, etc. +tf2 keeps track of all these frames over time, and allows you to ask questions like: + +* Where was the head frame relative to the world frame 5 seconds ago? +* What is the pose of the object in my gripper relative to my base? +* What is the current pose of the base frame in the map frame? + +tf2 can operate in a distributed system. +This means all the information about the coordinate frames of a robot is available to all ROS 2 components on any computer in the system. +tf2 can have every component in your distributed system build its own transform information database or have a central node that gathers and stores all transform information. + +.. mermaid:: + + flowchart LR + E((Earth)) + E --> A[[Car A]] + E --> B[[Car B]] + E --> C{{Satellite C}} + E --> D((Moon D)) + +Publishing transforms +^^^^^^^^^^^^^^^^^^^^^ + +When publishing transforms we typically think of the transforms as the transform from one frame to the other. +The semantic difference is whether you are transforming data represented in a frame or transforming the frame itself. +These values are directly inverse. +Transforms published in the ``geometry_msgs/msg/Transform`` message represent the frame formulation. +Keep this in mind when debugging published transforms they are the inverse of what you will lookup depending on what direction you're traversing the transform tree. + +.. math:: + + + _{B}T^{data}_{A} = (_{B}T^{frame}_{A})^{-1} + +The TF library handles inverting these elements for you depending on which way you're traversing the transform tree. +For the rest of this document we will just use :math:`T^{data}` but the ``data`` is unwritten. + +Position +^^^^^^^^ + +If the driver in car :math:`A` observes something and a person on the ground wants to know where it is relative to it's position, you transform the observation from the source frame to the target frame. + +.. math:: + + _{E}T_{A} * P_{A}^{Obs} = P_{E}^{Obs} + + +Now if a person in car B wants to know where it is too you can compute the net transform. + + +.. math:: + + _{B}T_{E} * _{E}T_{A} * P_{A}^{Obs} = _{B}T_{A} * P_{A}^{Obs} = P_{B}^{Obs} + + +This is exactly what ``lookupTransform`` provides where ``A`` is the *source* ``frame_id`` and ``B`` is the *target* ``frame_id``. + +It is recommended to use the ``transform(target_frame, ...)`` methods when possible because they will read the *source* ``frame_id`` from the datatype and write out the *target* ``frame_id`` in the resulting datatype and the math will be taken care of internally. + +If :math:`P` is a ``Stamped`` datatype then :math:`_A` is it's ``frame_id``. + +As an example, if a root frame ``A`` is one meter below frame ``B`` the transform from ``A`` to ``B`` is positive. + +However when converting data from coordinate frame ``B`` to coordinate frame ``A`` you have to use the inverse of this value. +This can be seen as you'll be adding value to the height when you change to the lower reference frame. +However if you are transforming data from coordinate frame ``A`` into coordinate frame ``B`` the height is reduced because the new reference is higher. + +.. math:: + + + _{B}T_{A} = (_{B}{Tf}_{A})^{-1} + + +Velocity +^^^^^^^^ + +For representing ``Velocity`` we have three pieces of information. +:math:`V^{moving\_frame - reference\_frame}_{observing\_frame}` +This velocity represents the velocity between the moving frame and the reference frame. +And it is represented in the observing frame. + +For example a driver in Car A can report that they're driving forward (observed in A) at 1m/s (relative to earth) so that would be :math:`V_{A}^{A - E} = (1,0,0)` +Whereas that same velocity could be observed from the view point of the earth (lets assume the car is driving east and Earth is NED), it would be :math:`V_{E}^{A - E} = (0, 1, 0)` + +However transforms can show that these are actually the same with: + +.. math:: + + _{E}T_{A} * V_{A}^{A - E} = V_{E}^{A - E} + + +Velocities can be added or subtracted if they're represented in the same frame, in this case ``Obs``. + +.. math:: + + V_{Obs}^{A - C} = V_{Obs}^{A - B} + V_{Obs}^{D - C} + +Velocities can be "reversed" by inverting. + +.. math:: + + V_{Obs}^{A - C} = -(V_{Obs}^{C - A}) + +If you want to compare two velocities you must first transform them into the same observational frame first. + + +Tutorials +--------- + +We created a set of :doc:`tutorials <../../client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` that walks you through using tf2, step by step. +You can get started on the :doc:`introduction to tf2 <../Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. +For a complete list of all tf2 and tf2-related tutorials check out the :doc:`tutorials <../../client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main>` page. + +There are essentially two main tasks that any user would use tf2 for, listening for transforms and broadcasting transforms. + +If you want to use tf2 to transform between coordinate frames, your nodes will need to listen for transforms. +What you will do is receive and buffer all coordinate frames that are broadcasted in the system, and query for specific transforms between frames. +Check out the "Writing a listener" tutorial :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp>` to learn more. + +To extend the capabilities of a robot, you will need to start broadcasting transforms. +Broadcasting transforms means to send out the relative pose of coordinate frames to the rest of the system. +A system can have many broadcasters that each provide information about a different part of the robot. +Check out the "Writing a broadcaster" tutorial :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp>` to learn more. + +In addition to that, tf2 can broadcast static transforms that do not change over time. +This mainly saves storage and lookup time, but also reduces the publishing overhead. +You should note that static transforms are published once and assumed to not change, so no history is stored. +If you want to define static transforms in your tf2 tree, take a look at the "Writing a static broadcaster" :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp>` tutorial. + +You can also learn how to add fixed and dynamic frames to your tf2 tree in the "Adding a frame" :doc:`(Python) <../../client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py>` :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp>` tutorial. + +Once you are finished with the basic tutorials, you can move on to learn about tf2 and time. +The tf2 and time tutorial :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp>` teaches the basic principles of tf2 and time. +The advanced tutorial about tf2 and time :doc:`(C++) <../../client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp>` teaches the principles of time traveling with tf2. + +Paper +----- + There is a paper on tf2 presented at TePRA 2013: `tf: The transform library `_. \ No newline at end of file diff --git a/source/ROS-Framework/About-Topics.rst b/source/ROS-Framework/interfaces/About-Topics.rst similarity index 100% rename from source/ROS-Framework/About-Topics.rst rename to source/ROS-Framework/interfaces/About-Topics.rst diff --git a/source/ROS-Framework/interfaces/Topics-Services-Actions.rst b/source/ROS-Framework/interfaces/Topics-Services-Actions.rst index 79995d63698..23cc9124ab7 100644 --- a/source/ROS-Framework/interfaces/Topics-Services-Actions.rst +++ b/source/ROS-Framework/interfaces/Topics-Services-Actions.rst @@ -1,43 +1,37 @@ -.. redirect-from:: - - How-To-Guides/Topics-Services-Actions - -.. _TopicsServicesActions: - -Topics vs Services vs Actions -============================= - -.. contents:: Contents - :depth: 1 - :local: - -When designing a system there are three primary styles of interfaces. -The specifications for the content is in the :doc:`Interfaces Overview <../About-Interfaces>`. -This is written to provide the reader with guidelines about when to use each type of interface. - -Topics ------- - -* Should be used for continuous data streams (sensor data, robot state, ...) -* Are for continuous data flow. - Data might be published and subscribed at any time independent of any senders/receivers. - Many to many connection. - Callbacks receive data once it is available. - The publisher decides when data is sent. - -Services --------- - -* Should be used for remote procedure calls that terminate quickly, e.g. for querying the state of a node or doing a quick calculation such as IK. - They should never be used for longer running processes, in particular processes that might be required to preempt if exceptional situations occur and they should never change or depend on state to avoid unwanted side effects for other nodes. - -Actions -------- - -* Should be used for any discrete behavior that moves a robot or that runs for a longer time but provides feedback during execution. -* The most important property of actions is that they can be preempted and preemption should always be implemented cleanly by action servers. -* Actions can keep state for the lifetime of a goal, i.e. if executing two action goals in parallel on the same server, for each client a separate state instance can be kept since the goal is uniquely identified by its id. -* Slow perception routines which take several seconds to terminate or initiating a lower-level control mode are good use cases for actions. -* More complex non-blocking background processing. - Used for longer tasks like execution of robot actions. +Topics vs Services vs Actions +============================= + +.. contents:: Contents + :depth: 1 + :local: + +When designing a system there are three primary styles of interfaces. +The specifications for the content is in the :doc:`Interfaces Overview `. +This is written to provide the reader with guidelines about when to use each type of interface. + +Topics +------ + +* Should be used for continuous data streams (sensor data, robot state, ...) +* Are for continuous data flow. + Data might be published and subscribed at any time independent of any senders/receivers. + Many to many connection. + Callbacks receive data once it is available. + The publisher decides when data is sent. + +Services +-------- + +* Should be used for remote procedure calls that terminate quickly, e.g. for querying the state of a node or doing a quick calculation such as IK. + They should never be used for longer running processes, in particular processes that might be required to preempt if exceptional situations occur and they should never change or depend on state to avoid unwanted side effects for other nodes. + +Actions +------- + +* Should be used for any discrete behavior that moves a robot or that runs for a longer time but provides feedback during execution. +* The most important property of actions is that they can be preempted and preemption should always be implemented cleanly by action servers. +* Actions can keep state for the lifetime of a goal, i.e. if executing two action goals in parallel on the same server, for each client a separate state instance can be kept since the goal is uniquely identified by its id. +* Slow perception routines which take several seconds to terminate or initiating a lower-level control mode are good use cases for actions. +* More complex non-blocking background processing. + Used for longer tasks like execution of robot actions. Semantically for real-world actions. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst index c5d001f75f6..6b452eff046 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst @@ -1,173 +1,173 @@ -.. redirect-from:: - - Tutorials/Tf2/Introduction-To-Tf2 - Tutorials/Intermediate/Tf2/Introduction-To-Tf2 - -.. _IntroToTf2: - -Introducing ``tf2`` -=================== - -**Goal:** Run a turtlesim demo and see some of the power of tf2 in a multi-robot example using turtlesim. - -**Tutorial level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Installing the demo -------------------- - -Let's start by installing the demo package and its dependencies. - -.. tabs:: - - .. group-tab:: Ubuntu Packages - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim - - .. group-tab:: RHEL Packages - - .. code-block:: console - - $ sudo dnf install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim - - .. group-tab:: From Source - - .. code-block:: console - - $ git clone https://github.com/ros/geometry_tutorials.git -b ros2 - -Running the demo ----------------- - -Now that we've installed the ``turtle_tf2_py`` tutorial package let's run the demo. -First, open a new terminal and :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. -Then run the following command: - -.. code-block:: console - - $ ros2 launch turtle_tf2_py turtle_tf2_demo.launch.py - -You will see the turtlesim start with two turtles. - -.. image:: images/turtlesim_follow1.png - -In the second terminal window type the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Once the turtlesim is started you can drive the central turtle around in the turtlesim using the keyboard arrow keys, -select the second terminal window so that your keystrokes will be captured to drive the turtle. - -.. image:: images/turtlesim_follow2.png - -You can see that one turtle continuously moves to follow the turtle you are driving around. - -What is happening? ------------------- - -This demo is using the tf2 library to create three coordinate frames: a ``world`` frame, a ``turtle1`` frame, and a ``turtle2`` frame. -This tutorial uses a *tf2 broadcaster* to publish the turtle coordinate frames and a *tf2 listener* to compute the difference in the turtle frames and move one turtle to follow the other. - -tf2 tools ---------- - -Now let's look at how tf2 is being used to create this demo. -We can use ``tf2_tools`` to look at what tf2 is doing behind the scenes. - -1 Using view_frames -^^^^^^^^^^^^^^^^^^^ - -``view_frames`` creates a diagram of the frames being broadcast by tf2 over ROS. -Note that this utility only works on Linux; if you are Windows, skip to "Using tf2_echo" below. - -.. code-block:: console - - $ ros2 run tf2_tools view_frames - Listening to tf data during 5 seconds... - Generating graph in frames.pdf file... - -Here a tf2 listener is listening to the frames that are being broadcast over ROS and drawing a tree of how the frames are connected. -To view the tree, open the resulting ``frames.pdf`` with your favorite PDF viewer. - -.. image:: images/turtlesim_frames.png - -Here we can see three frames that are broadcast by tf2: ``world``, ``turtle1``, and ``turtle2``. -The ``world`` frame is the parent of the ``turtle1`` and ``turtle2`` frames. -``view_frames`` also reports some diagnostic information about when the oldest and most -recent frame transforms were received and how fast the tf2 frame is published to tf2 for debugging purposes. - -2 Using tf2_echo -^^^^^^^^^^^^^^^^ - -``tf2_echo`` reports the transform between any two frames broadcast over ROS. - -Usage: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo [source_frame] [target_frame] - -Let's look at the transform of the ``turtle2`` frame with respect to ``turtle1`` frame which is equivalent to: - -.. code-block:: console - - $ ros2 run tf2_ros tf2_echo turtle2 turtle1 - At time 1683385337.850619099 - - Translation: [2.157, 0.901, 0.000] - - Rotation: in Quaternion [0.000, 0.000, 0.172, 0.985] - - Rotation: in RPY (radian) [0.000, -0.000, 0.345] - - Rotation: in RPY (degree) [0.000, -0.000, 19.760] - - Matrix: - 0.941 -0.338 0.000 2.157 - 0.338 0.941 0.000 0.901 - 0.000 0.000 1.000 0.000 - 0.000 0.000 0.000 1.000 - At time 1683385338.841997774 - - Translation: [1.256, 0.216, 0.000] - - Rotation: in Quaternion [0.000, 0.000, -0.016, 1.000] - - Rotation: in RPY (radian) [0.000, 0.000, -0.032] - - Rotation: in RPY (degree) [0.000, 0.000, -1.839] - - Matrix: - 0.999 0.032 0.000 1.256 - -0.032 0.999 -0.000 0.216 - -0.000 0.000 1.000 0.000 - 0.000 0.000 0.000 1.000 - - -You will see the transform displayed as the ``tf2_echo`` listener receives the frames broadcast over ROS 2. - -As you drive your turtle around you will see the transform change as the two turtles move relative to each other. - -rviz2 and tf2 -------------- - -``rviz2`` is a visualization tool that is useful for examining tf2 frames. -Let's look at our turtle frames using ``rviz2`` by starting it with a configuration file using the ``-d`` option: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ ros2 run rviz2 rviz2 -d $(ros2 pkg prefix --share turtle_tf2_py)/rviz/turtle_rviz.rviz - - .. group-tab:: Windows - - .. code-block:: console - - $ for /f "usebackq tokens=*" %a in (`ros2 pkg prefix --share turtle_tf2_py`) do rviz2 -d %a/rviz/turtle_rviz.rviz - -.. image:: images/turtlesim_rviz.png - -In the side bar you will see the frames broadcast by tf2. +.. redirect-from:: + + Tutorials/Tf2/Introduction-To-Tf2 + Tutorials/Intermediate/Tf2/Introduction-To-Tf2 + +.. _IntroToTf2: + +Introducing ``tf2`` +=================== + +**Goal:** Run a turtlesim demo and see some of the power of tf2 in a multi-robot example using turtlesim. + +**Tutorial level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Installing the demo +------------------- + +Let's start by installing the demo package and its dependencies. + +.. tabs:: + + .. group-tab:: Ubuntu Packages + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim + + .. group-tab:: RHEL Packages + + .. code-block:: console + + $ sudo dnf install ros-{DISTRO}-rviz2 ros-{DISTRO}-turtle-tf2-py ros-{DISTRO}-tf2-ros ros-{DISTRO}-tf2-tools ros-{DISTRO}-turtlesim + + .. group-tab:: From Source + + .. code-block:: console + + $ git clone https://github.com/ros/geometry_tutorials.git -b ros2 + +Running the demo +---------------- + +Now that we've installed the ``turtle_tf2_py`` tutorial package let's run the demo. +First, open a new terminal and :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Then run the following command: + +.. code-block:: console + + $ ros2 launch turtle_tf2_py turtle_tf2_demo.launch.py + +You will see the turtlesim start with two turtles. + +.. image:: images/turtlesim_follow1.png + +In the second terminal window type the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Once the turtlesim is started you can drive the central turtle around in the turtlesim using the keyboard arrow keys, +select the second terminal window so that your keystrokes will be captured to drive the turtle. + +.. image:: images/turtlesim_follow2.png + +You can see that one turtle continuously moves to follow the turtle you are driving around. + +What is happening? +------------------ + +This demo is using the tf2 library to create three coordinate frames: a ``world`` frame, a ``turtle1`` frame, and a ``turtle2`` frame. +This tutorial uses a *tf2 broadcaster* to publish the turtle coordinate frames and a *tf2 listener* to compute the difference in the turtle frames and move one turtle to follow the other. + +tf2 tools +--------- + +Now let's look at how tf2 is being used to create this demo. +We can use ``tf2_tools`` to look at what tf2 is doing behind the scenes. + +1 Using view_frames +^^^^^^^^^^^^^^^^^^^ + +``view_frames`` creates a diagram of the frames being broadcast by tf2 over ROS. +Note that this utility only works on Linux; if you are Windows, skip to "Using tf2_echo" below. + +.. code-block:: console + + $ ros2 run tf2_tools view_frames + Listening to tf data during 5 seconds... + Generating graph in frames.pdf file... + +Here a tf2 listener is listening to the frames that are being broadcast over ROS and drawing a tree of how the frames are connected. +To view the tree, open the resulting ``frames.pdf`` with your favorite PDF viewer. + +.. image:: images/turtlesim_frames.png + +Here we can see three frames that are broadcast by tf2: ``world``, ``turtle1``, and ``turtle2``. +The ``world`` frame is the parent of the ``turtle1`` and ``turtle2`` frames. +``view_frames`` also reports some diagnostic information about when the oldest and most +recent frame transforms were received and how fast the tf2 frame is published to tf2 for debugging purposes. + +2 Using tf2_echo +^^^^^^^^^^^^^^^^ + +``tf2_echo`` reports the transform between any two frames broadcast over ROS. + +Usage: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo [source_frame] [target_frame] + +Let's look at the transform of the ``turtle2`` frame with respect to ``turtle1`` frame which is equivalent to: + +.. code-block:: console + + $ ros2 run tf2_ros tf2_echo turtle2 turtle1 + At time 1683385337.850619099 + - Translation: [2.157, 0.901, 0.000] + - Rotation: in Quaternion [0.000, 0.000, 0.172, 0.985] + - Rotation: in RPY (radian) [0.000, -0.000, 0.345] + - Rotation: in RPY (degree) [0.000, -0.000, 19.760] + - Matrix: + 0.941 -0.338 0.000 2.157 + 0.338 0.941 0.000 0.901 + 0.000 0.000 1.000 0.000 + 0.000 0.000 0.000 1.000 + At time 1683385338.841997774 + - Translation: [1.256, 0.216, 0.000] + - Rotation: in Quaternion [0.000, 0.000, -0.016, 1.000] + - Rotation: in RPY (radian) [0.000, 0.000, -0.032] + - Rotation: in RPY (degree) [0.000, 0.000, -1.839] + - Matrix: + 0.999 0.032 0.000 1.256 + -0.032 0.999 -0.000 0.216 + -0.000 0.000 1.000 0.000 + 0.000 0.000 0.000 1.000 + + +You will see the transform displayed as the ``tf2_echo`` listener receives the frames broadcast over ROS 2. + +As you drive your turtle around you will see the transform change as the two turtles move relative to each other. + +rviz2 and tf2 +------------- + +``rviz2`` is a visualization tool that is useful for examining tf2 frames. +Let's look at our turtle frames using ``rviz2`` by starting it with a configuration file using the ``-d`` option: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ ros2 run rviz2 rviz2 -d $(ros2 pkg prefix --share turtle_tf2_py)/rviz/turtle_rviz.rviz + + .. group-tab:: Windows + + .. code-block:: console + + $ for /f "usebackq tokens=*" %a in (`ros2 pkg prefix --share turtle_tf2_py`) do rviz2 -d %a/rviz/turtle_rviz.rviz + +.. image:: images/turtlesim_rviz.png + +In the side bar you will see the frames broadcast by tf2. As you drive the turtle around you will see the frames move in rviz. \ No newline at end of file diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst index e3fc86ff6ce..21cd2dafdf2 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst @@ -1,739 +1,739 @@ -.. redirect-from:: - - Tutorials/Ros2bag/Recording-And-Playing-Back-Data - Tutorials/Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data - -.. _ROS2Bag: - -Recording and playing back data -=============================== - -**Goal:** Record data published on a topic, a service and an action so you can replay and examine it any time. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``ros2 bag`` is a command line tool for recording data published on topics, services and actions in your ROS 2 system. -It accumulates the data passed on any number of topics, services and actions, then saves it in a database. -You can then replay the data to reproduce the results of your tests and experiments. -Recording topics, services and actions is also a great way to share your work and allow others to recreate it. - - -Prerequisites -------------- - -You should have ``ros2 bag`` installed as a part of your regular ROS 2 setup. - -If you need to install ROS 2, see the :doc:`Installation instructions <../../../../Get-Started/Installation>`. - -This tutorial talks about concepts covered in previous tutorials, like :doc:`nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>` and :doc:`actions <../../../actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. -It also uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`, :doc:`Service Introspection Demo <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>` and :doc:`Action Introspection Demo <../../../actions/Working-with-actions/Action-Introspection>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. - - -Managing Topic Data -------------------- - -1 Setup -^^^^^^^ - -You'll be recording your keyboard input in the ``turtlesim`` system to save and replay later on, so begin by starting up the ``/turtlesim`` and ``/teleop_turtle`` nodes. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Let's also make a new directory to store our saved recordings, just as good practice: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir bag_files - $ cd bag_files - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir bag_files - $ cd bag_files - - .. group-tab:: Windows - - .. code-block:: console - - $ md bag_files - $ cd bag_files - - -2 Choose a topic -^^^^^^^^^^^^^^^^ - -``ros2 bag`` can record data from messages published to topics. -To see the list of your system's topics, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 topic list - /parameter_events - /rosout - /turtle1/cmd_vel - /turtle1/color_sensor - /turtle1/pose - -In the topics tutorial, you learned that the ``/turtle_teleop`` node publishes commands on the ``/turtle1/cmd_vel`` topic to make the turtle move in turtlesim. - -To see the data that ``/turtle1/cmd_vel`` is publishing, run the command: - -.. code-block:: console - - $ ros2 topic echo /turtle1/cmd_vel - -Nothing will show up at first because no data is being published by the teleop. -Return to the terminal where you ran the teleop and select it so it's active. -Use the arrow keys to move the turtle around, and you will see data being published on the terminal running ``ros2 topic echo``. - -.. code-block:: console - - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - - -3 Record topics -^^^^^^^^^^^^^^^ - -3.1 Record a single topic -~~~~~~~~~~~~~~~~~~~~~~~~~ - -To record the data published to a topic use the command syntax: - -.. code-block:: console - - $ ros2 bag record --topics - -Before running this command on your chosen topic, open a new terminal and move into the ``bag_files`` directory you created earlier, because the rosbag file will save in the directory where you run it. - -Run the command: - -.. code-block:: console - - $ ros2 bag record --topics /turtle1/cmd_vel - [INFO] [rosbag2_storage]: Opened database 'rosbag2_2019_10_11-05_18_45'. - [INFO] [rosbag2_transport]: Listening for topics... - [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' - [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... - -Now ``ros2 bag`` is recording the data published on the ``/turtle1/cmd_vel`` topic. -Return to the teleop terminal and move the turtle around again. -The movements don't matter, but try to make a recognizable pattern to see when you replay the data later. - -.. image:: images/record.png - -Press :kbd:`Ctrl-C` to stop recording. - -The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. -This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. - -3.2 Record multiple topics -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can also record multiple topics, as well as change the name of the bag directory ``ros2 bag`` saves to. - -Run the following command: - -.. code-block:: console - - $ ros2 bag record -o subset --topics /turtle1/cmd_vel /turtle1/pose - [INFO] [rosbag2_storage]: Opened database 'subset'. - [INFO] [rosbag2_transport]: Listening for topics... - [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' - [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/pose' - [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... - -The ``-o`` option allows you to choose a unique name for your bag directory. -The following string, in this case ``subset``, is the bag directory name. - -To record more than one topic at a time, simply list each topic separated by a space after ``--topics``. -In this case, the command output above confirms that both topics are being recorded. - -You can move the turtle around and press :kbd:`Ctrl-C` when you're finished. - -.. note:: - - There is another option you can add to the command, ``-a``, which records all the topics on your system. - -3.3 Split recording into multiple files -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can also split your recording into multiple files, based on either recording duration or file size. -``-d `` ensures that each file only lasts ```` seconds before it starts writing to a new file, or ``-b `` ensures that each file does not exceed ```` bytes in file size. -This prevents large and unwieldy file sizes, and protects against losing all data if the recording operation becomes corrupted at some point. - -Run the following for at least 15 seconds, allowing for three 5-second bag files to be written: - -.. code-block:: console - - $ ros2 bag record -o subset_split -d 5 --topics /turtle1/cmd_vel /turtle1/pose - [INFO] [rosbag2_recorder]: Press SPACE for pausing/resuming - [INFO] [rosbag2_recorder]: Listening for topics... - [INFO] [rosbag2_recorder]: Event publisher thread: Starting - [INFO] [rosbag2_recorder]: Recording... - [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/cmd_vel' - [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/pose' - [INFO] [rosbag2_recorder]: All requested topics are subscribed. Stopping discovery... - [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while - [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while - [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while - -Press :kbd:`Ctrl-C` when you're finished. -You should find a ``subset_split`` directory with these files inside: ``0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, ``1_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and so on. - -4 Inspect topic data -^^^^^^^^^^^^^^^^^^^^ - -You can see details about your recording by running: - -.. code-block:: console - - $ ros2 bag info - -Running this command on the ``subset`` bag recording will return a list of information: - -.. code-block:: console - - $ ros2 bag info subset - Files: subset_0.mcap - Bag size: 228.5 KiB - Storage id: mcap - ROS Distro: rolling - Duration: 48.47s - Start: Oct 11 2019 06:09:09.12 (1570799349.12) - End Oct 11 2019 06:09:57.60 (1570799397.60) - Messages: 3013 - Topic information: Topic: /turtle1/cmd_vel | Type: geometry_msgs/msg/Twist | Count: 9 | Serialization Format: cdr - Topic: /turtle1/pose | Type: turtlesim_msgs/msg/Pose | Count: 3004 | Serialization Format: cdr - Services: 0 - Service information: - Actions: 0 - Action information: - -Alternatively, you can also call ``ros2 bag info`` on an individual file, such as ``subset_split/0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and it will only show information for that portion of the recording; in this case, the first 5 seconds. - -5 Play topic data -^^^^^^^^^^^^^^^^^ - -5.1 Play a single bag -~~~~~~~~~~~~~~~~~~~~~ - -Before replaying the bag, enter :kbd:`Ctrl-C` in the terminal where the teleop is running. -Then make sure your turtlesim window is visible so you can see the bag file in action. - -Enter the command: - -.. code-block:: console - - $ ros2 bag play subset - [INFO] [rosbag2_player]: Set rate to 1 - [INFO] [rosbag2_player]: Adding keyboard callbacks. - [INFO] [rosbag2_player]: Press SPACE for Pause/Resume - [INFO] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message - [INFO] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% - [INFO] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% - Progress bar enabled at 3 Hz. - Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped - [INFO] [rosbag2_player]: Playback until timestamp: -1 - - - ====== Playback Progress ====== - [1751923361.427372456] Duration 0.00/48.47 [R] - -Your turtle will follow the same path you entered while recording (though not 100% exactly; turtlesim is sensitive to small changes in the system's timing). - -.. image:: images/playback.png - -Because the ``subset`` file recorded the ``/turtle1/pose`` topic, the ``ros2 bag play`` command won't quit for as long as you had turtlesim running, even if you weren't moving. - -This is because as long as the ``/turtlesim`` node is active, it publishes data on the ``/turtle1/pose`` topic at regular intervals. -You may have noticed in the ``ros2 bag info`` example result above that the ``/turtle1/cmd_vel`` topic's ``Count`` information was only 9; that's how many times we pressed the arrow keys while recording. - -Notice that ``/turtle1/pose`` has a ``Count`` value of over 3000; while we were recording, data was published on that topic 3000 times. - -To get an idea of how often position data is published, you can run the command: - -.. code-block:: console - - $ ros2 topic hz /turtle1/pose - -5.2 Play multiple bags -~~~~~~~~~~~~~~~~~~~~~~ - -At times, it is relevant to split the desired recorded topics amongst multiple recordings, as a way to distribute the recording workload. -As an example, we can record ``/turtle1/cmd_vel`` and ``/turtle1/pose`` each to their own bag. - -Create two terminal instances. -In the first one, run the following: - -.. code-block:: console - - $ ros2 bag record -o subset_cmd_vel --topics /turtle1/cmd_vel - -In the second terminal, run this: - -.. code-block:: console - - $ ros2 bag record -o subset_pose --topics /turtle1/pose - -Move the turtle around as you did before, then end both recordings with :kbd:`Ctrl-C` when finished. - -To have these two recordings play in parallel with correct timing, call ``ros2 bag play`` with ``-i `` for each bag you want to include. -In this case, run: - -.. code-block:: console - - $ ros2 bag play -i subset_cmd_vel -i subset_pose - -This will play the ``subset_cmd_vel`` and ``subset_pose`` recordings together, with the playback synced to replicate the original order of messages. -If used, the optional argument ``--message-order {received,sent}`` determines whether the messages are sequenced according to the time they were received or published (defaults to received). -This applies to playing a single bag as well. - -Managing Service Data ---------------------- - -1 Setup -^^^^^^^ - -You'll be recording service data between ``introspection_client`` and ``introspection_service``, then display and replay that same data later on. -To record service data between service client and server, ``Service Introspection`` must be enabled on the node. - -Let's start ``introspection_client`` and ``introspection_service`` nodes and enable ``Service Introspection``. -You can see more details for :doc:`Service Introspection Demo <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>`. - -Open a new terminal and run ``introspection_service``, enabling ``Service Introspection``: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp introspection_service --ros-args -p service_configure_introspection:=contents - -Open another terminal and run ``introspection_client``, enabling ``Service Introspection``: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp introspection_client --ros-args -p client_configure_introspection:=contents - -2 Check service availability -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``ros2 bag`` can only record data from available services. -To see the list of your system's services, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 service list - /add_two_ints - /introspection_client/describe_parameters - /introspection_client/get_parameter_types - /introspection_client/get_parameters - /introspection_client/get_type_description - /introspection_client/list_parameters - /introspection_client/set_parameters - /introspection_client/set_parameters_atomically - /introspection_service/describe_parameters - /introspection_service/get_parameter_types - /introspection_service/get_parameters - /introspection_service/get_type_description - /introspection_service/list_parameters - /introspection_service/set_parameters - /introspection_service/set_parameters_atomically - -To check if ``Service Introspection`` is enabled on the client and service, run the command: - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - info: - event_type: REQUEST_SENT - stamp: - sec: 1713995389 - nanosec: 386809259 - client_gid: [1, 15, 96, 219, 162, 1, 108, 201, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 133 - request: [{a: 2, b: 3}] - response: [] - --- - -You should see the service communication. - -3 Record services -^^^^^^^^^^^^^^^^^ - -To record service data, the following options are supported. -Service data can be recorded with topics at the same time. - -To record specific services: - -.. code-block:: console - - $ ros2 bag record --service - -To record all services: - -.. code-block:: console - - $ ros2 bag record --all-services - -Run the command: - -.. code-block:: console - - $ ros2 bag record --service /add_two_ints - [INFO] [1713995957.643573503] [rosbag2_recorder]: Press SPACE for pausing/resuming - [INFO] [1713995957.662067587] [rosbag2_recorder]: Event publisher thread: Starting - [INFO] [1713995957.662067614] [rosbag2_recorder]: Listening for topics... - [INFO] [1713995957.666048323] [rosbag2_recorder]: Subscribed to topic '/add_two_ints/_service_event' - [INFO] [1713995957.666092458] [rosbag2_recorder]: Recording... - -Now ``ros2 bag`` is recording the service data published on the ``/add_two_ints`` service. -To stop the recording, enter :kbd:`Ctrl-C` in the terminal. - -The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. -This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. - -4 Inspect service data -^^^^^^^^^^^^^^^^^^^^^^ - -You can see details about your recording by running: - -.. code-block:: console - - $ ros2 bag info - Files: rosbag2_2024_04_24-14_59_17_0.mcap - Bag size: 15.1 KiB - Storage id: mcap - ROS Distro: rolling - Duration: 9.211s - Start: Apr 24 2024 14:59:17.676 (1713995957.676) - End: Apr 24 2024 14:59:26.888 (1713995966.888) - Messages: 0 - Topic information: - Service: 1 - Service information: Service: /add_two_ints | Type: example_interfaces/srv/AddTwoInts | Event Count: 78 | Serialization Format: cdr - -5 Play service data -^^^^^^^^^^^^^^^^^^^ - -Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``introspection_client`` is running. -When ``introspection_client`` stops running, ``introspection_service`` also stops printing the result because there are no incoming requests. - -Replaying the service data from the bag file will start sending the requests to ``introspection_service``. - -Enter the command: - -.. code-block:: console - - $ ros2 bag play --publish-service-requests - [INFO] [1713997477.870856190] [rosbag2_player]: Set rate to 1 - [INFO] [1713997477.877417477] [rosbag2_player]: Adding keyboard callbacks. - [INFO] [1713997477.877442404] [rosbag2_player]: Press SPACE for Pause/Resume - [INFO] [1713997477.877447855] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message - [INFO] [1713997477.877452655] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% - [INFO] [1713997477.877456954] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% - [INFO] [1713997477.877573647] [rosbag2_player]: Playback until timestamp: -1 - -Your ``introspection_service`` terminal will once again start printing the following service messages: - -.. code-block:: console - - [INFO] [1713997478.090466075] [introspection_service]: Incoming request - a: 2 b: 3 - -This is because ``ros2 bag play`` sends the service request data from the bag file to the ``/add_two_ints`` service. - -We can also introspect service communication as ``ros2 bag play`` is playing it back to verify the ``introspection_service``. - -Run this command before ``ros2 bag play`` to see the ``introspection_service``: - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - -You can see the service request from the bag file and the service response from ``introspection_service``. - -.. code-block:: console - - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1713998176 - nanosec: 372700698 - client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: RESPONSE_SENT - stamp: - sec: 1713998176 - nanosec: 373016882 - client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [] - response: [{sum: 5}] - -.. _record-play-data-action: - -Managing Action Data --------------------- - -1 Setup -^^^^^^^ - -You'll be recording action data between ``fibonacci_action_client`` and ``fibonacci_action_server``, then display and replay that same data later on. -To record action data between action client and server, ``Action Introspection`` must be enabled on the nodes. - -Let's start ``fibonacci_action_client`` and ``fibonacci_action_server`` nodes and enable ``Action Introspection``. -You can see more details for :doc:`Action Introspection Demo <../../../actions/Working-with-actions/Action-Introspection>`. - -Open a new terminal and run ``fibonacci_action_server``, enabling ``Action Introspection``: - -.. code-block:: console - - $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents - -Open another terminal and run ``fibonacci_action_client``, enabling ``Action Introspection``: - -.. code-block:: console - - $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents - -2 Check action availability -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -``ros2 bag`` can only record data from available actions. -To see the list of your system's actions, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 action list - /fibonacci - -To check if ``Action Introspection`` is enabled on the action, run the command: - -.. code-block:: console - - $ ros2 action echo --flow-style /fibonacci - interface: GOAL_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1744917904 - nanosec: 760683446 - client_gid: [1, 15, 165, 231, 234, 109, 65, 202, 0, 0, 0, 0, 0, 0, 19, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [81, 55, 121, 145, 81, 66, 209, 93, 214, 113, 255, 100, 120, 6, 102, 83]}, goal: {order: 10}}] - response: [] - --- - ... - -3 Record actions -^^^^^^^^^^^^^^^^ - -To record action data, the following options are supported. -Action data can be recorded with topics and services at the same time. - -To record specific actions: - -.. code-block:: console - - $ ros2 bag record --action - -To record all actions: - -.. code-block:: console - - $ ros2 bag record --all-actions - -Run the command: - -.. code-block:: console - - $ ros2 bag record --action /fibonacci - [INFO] [1744953225.214114862] [rosbag2_recorder]: Press SPACE for pausing/resuming - [INFO] [1744953225.218369761] [rosbag2_recorder]: Listening for topics... - [INFO] [1744953225.218386223] [rosbag2_recorder]: Event publisher thread: Starting - [INFO] [1744953225.218580294] [rosbag2_recorder]: Recording... - [INFO] [1744953225.725417634] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/cancel_goal/_service_event' - [INFO] [1744953225.727901848] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/feedback' - [INFO] [1744953225.729655213] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/get_result/_service_event' - [INFO] [1744953225.731315612] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/send_goal/_service_event' - [INFO] [1744953225.735061252] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/status' - ... - -Now ``ros2 bag`` is recording the action data for the ``/fibonacci`` action: goal, result, and feedback. -To stop the recording, enter :kbd:`Ctrl-C` in the terminal. - -The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. -This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. - -4 Inspect action data -^^^^^^^^^^^^^^^^^^^^^ - -You can see details about your recording by running: - -.. code-block:: console - - $ ros2 bag info - Files: rosbag2_2025_04_17-22_20_40_0.mcap - Bag size: 20.7 KiB - Storage id: mcap - ROS Distro: rolling - Duration: 9.019568080s - Start: Apr 17 2025 22:20:47.263125070 (1744953647.263125070) - End: Apr 17 2025 22:20:56.282693150 (1744953656.282693150) - Messages: 0 - Topic information: - Services: 0 - Service information: - Actions: 1 - Action information: - Action: /fibonacci | Type: example_interfaces/action/Fibonacci | Topics: 2 | Service: 3 | Serialization Format: cdr - Topic: feedback | Count: 9 - Topic: status | Count: 3 - Service: send_goal | Event Count: 4 - Service: cancel_goal | Event Count: 0 - Service: get_result | Event Count: 4 - -5 Play action data -^^^^^^^^^^^^^^^^^^ - -Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``fibonacci_action_client`` is running. -When ``fibonacci_action_client`` stops running, ``fibonacci_action_server`` also stops printing the result because there are no incoming requests. - -Replaying the action data from the bag file will start sending the requests to ``fibonacci_action_server``. - -Enter the command: - -.. code-block:: console - - $ ros2 bag play --send-actions-as-client - [INFO] [1744953720.691068674] [rosbag2_player]: Set rate to 1 - [INFO] [1744953720.702365209] [rosbag2_player]: Adding keyboard callbacks. - [INFO] [1744953720.702409447] [rosbag2_player]: Press SPACE for Pause/Resume - [INFO] [1744953720.702423063] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message - [INFO] [1744953720.702431404] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% - [INFO] [1744953720.702437677] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% - Progress bar enabled at 3 Hz. - Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped - [INFO] [1744953720.702577680] [rosbag2_player]: Playback until timestamp: -1 - - - ====== Playback Progress ====== - [1744953656.281683207] Duration 9.02/9.02 [R] - -Your ``fibonacci_action_server`` terminal will once again start printing the following service messages: - -.. code-block:: console - - [INFO] [1744953720.815577088] [fibonacci_action_server]: Executing goal... - [INFO] [1744953720.815927050] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1]) - [INFO] [1744953721.816509658] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2]) - [INFO] [1744953722.817220270] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3]) - [INFO] [1744953723.817876426] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5]) - [INFO] [1744953724.818498515] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8]) - [INFO] [1744953725.819182228] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13]) - [INFO] [1744953726.820032562] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21]) - [INFO] [1744953727.820738690] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]) - [INFO] [1744953728.821449308] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]) - -This is because ``ros2 bag play`` sends the action goal request data from the bag file to the ``/fibonacci`` action. - -We can also introspect action communication as ``ros2 bag play`` is playing it back to verify the ``fibonacci_action_server``. - -Run this command before ``ros2 bag play`` to see the ``fibonacci_action_server``. -You can see the action goal request from the bag file and the service response from ``fibonacci_action_server``: - -.. code-block:: console - - $ ros2 action echo --flow-style /fibonacci - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [34, 116, 225, 217, 48, 121, 146, 36, 240, 98, 99, 134, 55, 227, 184, 72]}, stamp: {sec: 1744953720, nanosec: 804984321}}, status: 4}] - --- - interface: GOAL_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1744953927 - nanosec: 957359210 - client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, goal: {order: 10}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: RESPONSE_SENT - stamp: - sec: 1744953927 - nanosec: 957726145 - client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] - sequence_number: 1 - request: [] - response: [{accepted: true, stamp: {sec: 1744953927, nanosec: 957615866}}] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, stamp: {sec: 1744953927, nanosec: 957663383}}, status: 2}] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12] - feedback: - sequence: [0, 1, 1] - --- - ... - -Summary -------- - -You can record data passed on topics, services and actions in your ROS 2 system using the ``ros2 bag`` command. -Whether you're sharing your work with others or introspecting your own experiments, it's a great tool to know about. - -Next steps ----------- - -You've completed the "Beginner: CLI Tools" tutorials! -The next step is tackling the "Beginner: Client Libraries" tutorials, starting with :doc:`../../../client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`. - -Related content ---------------- - -A more thorough explanation of ``ros2 bag`` can be found in the README `here `__. -For more information on service recording and playback can be found in the design document `here `__. -For more information on action recording and playback can be found in the design document `here `__. +.. redirect-from:: + + Tutorials/Ros2bag/Recording-And-Playing-Back-Data + Tutorials/Beginner-CLI-Tools/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data + +.. _ROS2Bag: + +Recording and playing back data +=============================== + +**Goal:** Record data published on a topic, a service and an action so you can replay and examine it any time. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``ros2 bag`` is a command line tool for recording data published on topics, services and actions in your ROS 2 system. +It accumulates the data passed on any number of topics, services and actions, then saves it in a database. +You can then replay the data to reproduce the results of your tests and experiments. +Recording topics, services and actions is also a great way to share your work and allow others to recreate it. + + +Prerequisites +------------- + +You should have ``ros2 bag`` installed as a part of your regular ROS 2 setup. + +If you need to install ROS 2, see the :doc:`Installation instructions <../../../../Get-Started/Installation>`. + +This tutorial talks about concepts covered in previous tutorials, like :doc:`nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>`, :doc:`topics <../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, :doc:`services <../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services>` and :doc:`actions <../../actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. +It also uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`, :doc:`Service Introspection Demo <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>` and :doc:`Action Introspection Demo <../../actions/Working-with-actions/Action-Introspection>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + + +Managing Topic Data +------------------- + +1 Setup +^^^^^^^ + +You'll be recording your keyboard input in the ``turtlesim`` system to save and replay later on, so begin by starting up the ``/turtlesim`` and ``/teleop_turtle`` nodes. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Let's also make a new directory to store our saved recordings, just as good practice: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir bag_files + $ cd bag_files + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir bag_files + $ cd bag_files + + .. group-tab:: Windows + + .. code-block:: console + + $ md bag_files + $ cd bag_files + + +2 Choose a topic +^^^^^^^^^^^^^^^^ + +``ros2 bag`` can record data from messages published to topics. +To see the list of your system's topics, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 topic list + /parameter_events + /rosout + /turtle1/cmd_vel + /turtle1/color_sensor + /turtle1/pose + +In the topics tutorial, you learned that the ``/turtle_teleop`` node publishes commands on the ``/turtle1/cmd_vel`` topic to make the turtle move in turtlesim. + +To see the data that ``/turtle1/cmd_vel`` is publishing, run the command: + +.. code-block:: console + + $ ros2 topic echo /turtle1/cmd_vel + +Nothing will show up at first because no data is being published by the teleop. +Return to the terminal where you ran the teleop and select it so it's active. +Use the arrow keys to move the turtle around, and you will see data being published on the terminal running ``ros2 topic echo``. + +.. code-block:: console + + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + + +3 Record topics +^^^^^^^^^^^^^^^ + +3.1 Record a single topic +~~~~~~~~~~~~~~~~~~~~~~~~~ + +To record the data published to a topic use the command syntax: + +.. code-block:: console + + $ ros2 bag record --topics + +Before running this command on your chosen topic, open a new terminal and move into the ``bag_files`` directory you created earlier, because the rosbag file will save in the directory where you run it. + +Run the command: + +.. code-block:: console + + $ ros2 bag record --topics /turtle1/cmd_vel + [INFO] [rosbag2_storage]: Opened database 'rosbag2_2019_10_11-05_18_45'. + [INFO] [rosbag2_transport]: Listening for topics... + [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' + [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... + +Now ``ros2 bag`` is recording the data published on the ``/turtle1/cmd_vel`` topic. +Return to the teleop terminal and move the turtle around again. +The movements don't matter, but try to make a recognizable pattern to see when you replay the data later. + +.. image:: images/record.png + +Press :kbd:`Ctrl-C` to stop recording. + +The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. +This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. + +3.2 Record multiple topics +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also record multiple topics, as well as change the name of the bag directory ``ros2 bag`` saves to. + +Run the following command: + +.. code-block:: console + + $ ros2 bag record -o subset --topics /turtle1/cmd_vel /turtle1/pose + [INFO] [rosbag2_storage]: Opened database 'subset'. + [INFO] [rosbag2_transport]: Listening for topics... + [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/cmd_vel' + [INFO] [rosbag2_transport]: Subscribed to topic '/turtle1/pose' + [INFO] [rosbag2_transport]: All requested topics are subscribed. Stopping discovery... + +The ``-o`` option allows you to choose a unique name for your bag directory. +The following string, in this case ``subset``, is the bag directory name. + +To record more than one topic at a time, simply list each topic separated by a space after ``--topics``. +In this case, the command output above confirms that both topics are being recorded. + +You can move the turtle around and press :kbd:`Ctrl-C` when you're finished. + +.. note:: + + There is another option you can add to the command, ``-a``, which records all the topics on your system. + +3.3 Split recording into multiple files +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can also split your recording into multiple files, based on either recording duration or file size. +``-d `` ensures that each file only lasts ```` seconds before it starts writing to a new file, or ``-b `` ensures that each file does not exceed ```` bytes in file size. +This prevents large and unwieldy file sizes, and protects against losing all data if the recording operation becomes corrupted at some point. + +Run the following for at least 15 seconds, allowing for three 5-second bag files to be written: + +.. code-block:: console + + $ ros2 bag record -o subset_split -d 5 --topics /turtle1/cmd_vel /turtle1/pose + [INFO] [rosbag2_recorder]: Press SPACE for pausing/resuming + [INFO] [rosbag2_recorder]: Listening for topics... + [INFO] [rosbag2_recorder]: Event publisher thread: Starting + [INFO] [rosbag2_recorder]: Recording... + [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/cmd_vel' + [INFO] [rosbag2_recorder]: Subscribed to topic '/turtle1/pose' + [INFO] [rosbag2_recorder]: All requested topics are subscribed. Stopping discovery... + [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while + [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while + [INFO] [rosbag2_cpp]: Writing remaining messages from cache to the bag. It may take a while + +Press :kbd:`Ctrl-C` when you're finished. +You should find a ``subset_split`` directory with these files inside: ``0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, ``1_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and so on. + +4 Inspect topic data +^^^^^^^^^^^^^^^^^^^^ + +You can see details about your recording by running: + +.. code-block:: console + + $ ros2 bag info + +Running this command on the ``subset`` bag recording will return a list of information: + +.. code-block:: console + + $ ros2 bag info subset + Files: subset_0.mcap + Bag size: 228.5 KiB + Storage id: mcap + ROS Distro: rolling + Duration: 48.47s + Start: Oct 11 2019 06:09:09.12 (1570799349.12) + End Oct 11 2019 06:09:57.60 (1570799397.60) + Messages: 3013 + Topic information: Topic: /turtle1/cmd_vel | Type: geometry_msgs/msg/Twist | Count: 9 | Serialization Format: cdr + Topic: /turtle1/pose | Type: turtlesim_msgs/msg/Pose | Count: 3004 | Serialization Format: cdr + Services: 0 + Service information: + Actions: 0 + Action information: + +Alternatively, you can also call ``ros2 bag info`` on an individual file, such as ``subset_split/0_subset_split_YYYY_MM_DD-HH_MM_SS.mcap``, and it will only show information for that portion of the recording; in this case, the first 5 seconds. + +5 Play topic data +^^^^^^^^^^^^^^^^^ + +5.1 Play a single bag +~~~~~~~~~~~~~~~~~~~~~ + +Before replaying the bag, enter :kbd:`Ctrl-C` in the terminal where the teleop is running. +Then make sure your turtlesim window is visible so you can see the bag file in action. + +Enter the command: + +.. code-block:: console + + $ ros2 bag play subset + [INFO] [rosbag2_player]: Set rate to 1 + [INFO] [rosbag2_player]: Adding keyboard callbacks. + [INFO] [rosbag2_player]: Press SPACE for Pause/Resume + [INFO] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message + [INFO] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% + [INFO] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% + Progress bar enabled at 3 Hz. + Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped + [INFO] [rosbag2_player]: Playback until timestamp: -1 + + + ====== Playback Progress ====== + [1751923361.427372456] Duration 0.00/48.47 [R] + +Your turtle will follow the same path you entered while recording (though not 100% exactly; turtlesim is sensitive to small changes in the system's timing). + +.. image:: images/playback.png + +Because the ``subset`` file recorded the ``/turtle1/pose`` topic, the ``ros2 bag play`` command won't quit for as long as you had turtlesim running, even if you weren't moving. + +This is because as long as the ``/turtlesim`` node is active, it publishes data on the ``/turtle1/pose`` topic at regular intervals. +You may have noticed in the ``ros2 bag info`` example result above that the ``/turtle1/cmd_vel`` topic's ``Count`` information was only 9; that's how many times we pressed the arrow keys while recording. + +Notice that ``/turtle1/pose`` has a ``Count`` value of over 3000; while we were recording, data was published on that topic 3000 times. + +To get an idea of how often position data is published, you can run the command: + +.. code-block:: console + + $ ros2 topic hz /turtle1/pose + +5.2 Play multiple bags +~~~~~~~~~~~~~~~~~~~~~~ + +At times, it is relevant to split the desired recorded topics amongst multiple recordings, as a way to distribute the recording workload. +As an example, we can record ``/turtle1/cmd_vel`` and ``/turtle1/pose`` each to their own bag. + +Create two terminal instances. +In the first one, run the following: + +.. code-block:: console + + $ ros2 bag record -o subset_cmd_vel --topics /turtle1/cmd_vel + +In the second terminal, run this: + +.. code-block:: console + + $ ros2 bag record -o subset_pose --topics /turtle1/pose + +Move the turtle around as you did before, then end both recordings with :kbd:`Ctrl-C` when finished. + +To have these two recordings play in parallel with correct timing, call ``ros2 bag play`` with ``-i `` for each bag you want to include. +In this case, run: + +.. code-block:: console + + $ ros2 bag play -i subset_cmd_vel -i subset_pose + +This will play the ``subset_cmd_vel`` and ``subset_pose`` recordings together, with the playback synced to replicate the original order of messages. +If used, the optional argument ``--message-order {received,sent}`` determines whether the messages are sequenced according to the time they were received or published (defaults to received). +This applies to playing a single bag as well. + +Managing Service Data +--------------------- + +1 Setup +^^^^^^^ + +You'll be recording service data between ``introspection_client`` and ``introspection_service``, then display and replay that same data later on. +To record service data between service client and server, ``Service Introspection`` must be enabled on the node. + +Let's start ``introspection_client`` and ``introspection_service`` nodes and enable ``Service Introspection``. +You can see more details for :doc:`Service Introspection Demo <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>`. + +Open a new terminal and run ``introspection_service``, enabling ``Service Introspection``: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp introspection_service --ros-args -p service_configure_introspection:=contents + +Open another terminal and run ``introspection_client``, enabling ``Service Introspection``: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp introspection_client --ros-args -p client_configure_introspection:=contents + +2 Check service availability +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``ros2 bag`` can only record data from available services. +To see the list of your system's services, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 service list + /add_two_ints + /introspection_client/describe_parameters + /introspection_client/get_parameter_types + /introspection_client/get_parameters + /introspection_client/get_type_description + /introspection_client/list_parameters + /introspection_client/set_parameters + /introspection_client/set_parameters_atomically + /introspection_service/describe_parameters + /introspection_service/get_parameter_types + /introspection_service/get_parameters + /introspection_service/get_type_description + /introspection_service/list_parameters + /introspection_service/set_parameters + /introspection_service/set_parameters_atomically + +To check if ``Service Introspection`` is enabled on the client and service, run the command: + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + info: + event_type: REQUEST_SENT + stamp: + sec: 1713995389 + nanosec: 386809259 + client_gid: [1, 15, 96, 219, 162, 1, 108, 201, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 133 + request: [{a: 2, b: 3}] + response: [] + --- + +You should see the service communication. + +3 Record services +^^^^^^^^^^^^^^^^^ + +To record service data, the following options are supported. +Service data can be recorded with topics at the same time. + +To record specific services: + +.. code-block:: console + + $ ros2 bag record --service + +To record all services: + +.. code-block:: console + + $ ros2 bag record --all-services + +Run the command: + +.. code-block:: console + + $ ros2 bag record --service /add_two_ints + [INFO] [1713995957.643573503] [rosbag2_recorder]: Press SPACE for pausing/resuming + [INFO] [1713995957.662067587] [rosbag2_recorder]: Event publisher thread: Starting + [INFO] [1713995957.662067614] [rosbag2_recorder]: Listening for topics... + [INFO] [1713995957.666048323] [rosbag2_recorder]: Subscribed to topic '/add_two_ints/_service_event' + [INFO] [1713995957.666092458] [rosbag2_recorder]: Recording... + +Now ``ros2 bag`` is recording the service data published on the ``/add_two_ints`` service. +To stop the recording, enter :kbd:`Ctrl-C` in the terminal. + +The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. +This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. + +4 Inspect service data +^^^^^^^^^^^^^^^^^^^^^^ + +You can see details about your recording by running: + +.. code-block:: console + + $ ros2 bag info + Files: rosbag2_2024_04_24-14_59_17_0.mcap + Bag size: 15.1 KiB + Storage id: mcap + ROS Distro: rolling + Duration: 9.211s + Start: Apr 24 2024 14:59:17.676 (1713995957.676) + End: Apr 24 2024 14:59:26.888 (1713995966.888) + Messages: 0 + Topic information: + Service: 1 + Service information: Service: /add_two_ints | Type: example_interfaces/srv/AddTwoInts | Event Count: 78 | Serialization Format: cdr + +5 Play service data +^^^^^^^^^^^^^^^^^^^ + +Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``introspection_client`` is running. +When ``introspection_client`` stops running, ``introspection_service`` also stops printing the result because there are no incoming requests. + +Replaying the service data from the bag file will start sending the requests to ``introspection_service``. + +Enter the command: + +.. code-block:: console + + $ ros2 bag play --publish-service-requests + [INFO] [1713997477.870856190] [rosbag2_player]: Set rate to 1 + [INFO] [1713997477.877417477] [rosbag2_player]: Adding keyboard callbacks. + [INFO] [1713997477.877442404] [rosbag2_player]: Press SPACE for Pause/Resume + [INFO] [1713997477.877447855] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message + [INFO] [1713997477.877452655] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% + [INFO] [1713997477.877456954] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% + [INFO] [1713997477.877573647] [rosbag2_player]: Playback until timestamp: -1 + +Your ``introspection_service`` terminal will once again start printing the following service messages: + +.. code-block:: console + + [INFO] [1713997478.090466075] [introspection_service]: Incoming request + a: 2 b: 3 + +This is because ``ros2 bag play`` sends the service request data from the bag file to the ``/add_two_ints`` service. + +We can also introspect service communication as ``ros2 bag play`` is playing it back to verify the ``introspection_service``. + +Run this command before ``ros2 bag play`` to see the ``introspection_service``: + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + +You can see the service request from the bag file and the service response from ``introspection_service``. + +.. code-block:: console + + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1713998176 + nanosec: 372700698 + client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: RESPONSE_SENT + stamp: + sec: 1713998176 + nanosec: 373016882 + client_gid: [1, 15, 96, 219, 80, 2, 158, 123, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [] + response: [{sum: 5}] + +.. _record-play-data-action: + +Managing Action Data +-------------------- + +1 Setup +^^^^^^^ + +You'll be recording action data between ``fibonacci_action_client`` and ``fibonacci_action_server``, then display and replay that same data later on. +To record action data between action client and server, ``Action Introspection`` must be enabled on the nodes. + +Let's start ``fibonacci_action_client`` and ``fibonacci_action_server`` nodes and enable ``Action Introspection``. +You can see more details for :doc:`Action Introspection Demo <../../actions/Working-with-actions/Action-Introspection>`. + +Open a new terminal and run ``fibonacci_action_server``, enabling ``Action Introspection``: + +.. code-block:: console + + $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents + +Open another terminal and run ``fibonacci_action_client``, enabling ``Action Introspection``: + +.. code-block:: console + + $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents + +2 Check action availability +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +``ros2 bag`` can only record data from available actions. +To see the list of your system's actions, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 action list + /fibonacci + +To check if ``Action Introspection`` is enabled on the action, run the command: + +.. code-block:: console + + $ ros2 action echo --flow-style /fibonacci + interface: GOAL_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1744917904 + nanosec: 760683446 + client_gid: [1, 15, 165, 231, 234, 109, 65, 202, 0, 0, 0, 0, 0, 0, 19, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [81, 55, 121, 145, 81, 66, 209, 93, 214, 113, 255, 100, 120, 6, 102, 83]}, goal: {order: 10}}] + response: [] + --- + ... + +3 Record actions +^^^^^^^^^^^^^^^^ + +To record action data, the following options are supported. +Action data can be recorded with topics and services at the same time. + +To record specific actions: + +.. code-block:: console + + $ ros2 bag record --action + +To record all actions: + +.. code-block:: console + + $ ros2 bag record --all-actions + +Run the command: + +.. code-block:: console + + $ ros2 bag record --action /fibonacci + [INFO] [1744953225.214114862] [rosbag2_recorder]: Press SPACE for pausing/resuming + [INFO] [1744953225.218369761] [rosbag2_recorder]: Listening for topics... + [INFO] [1744953225.218386223] [rosbag2_recorder]: Event publisher thread: Starting + [INFO] [1744953225.218580294] [rosbag2_recorder]: Recording... + [INFO] [1744953225.725417634] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/cancel_goal/_service_event' + [INFO] [1744953225.727901848] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/feedback' + [INFO] [1744953225.729655213] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/get_result/_service_event' + [INFO] [1744953225.731315612] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/send_goal/_service_event' + [INFO] [1744953225.735061252] [rosbag2_recorder]: Subscribed to topic '/fibonacci/_action/status' + ... + +Now ``ros2 bag`` is recording the action data for the ``/fibonacci`` action: goal, result, and feedback. +To stop the recording, enter :kbd:`Ctrl-C` in the terminal. + +The data will be accumulated in a new bag directory with a name in the pattern of ``rosbag2_year_month_day-hour_minute_second``. +This directory will contain a ``metadata.yaml`` along with the bag file in the recorded format. + +4 Inspect action data +^^^^^^^^^^^^^^^^^^^^^ + +You can see details about your recording by running: + +.. code-block:: console + + $ ros2 bag info + Files: rosbag2_2025_04_17-22_20_40_0.mcap + Bag size: 20.7 KiB + Storage id: mcap + ROS Distro: rolling + Duration: 9.019568080s + Start: Apr 17 2025 22:20:47.263125070 (1744953647.263125070) + End: Apr 17 2025 22:20:56.282693150 (1744953656.282693150) + Messages: 0 + Topic information: + Services: 0 + Service information: + Actions: 1 + Action information: + Action: /fibonacci | Type: example_interfaces/action/Fibonacci | Topics: 2 | Service: 3 | Serialization Format: cdr + Topic: feedback | Count: 9 + Topic: status | Count: 3 + Service: send_goal | Event Count: 4 + Service: cancel_goal | Event Count: 0 + Service: get_result | Event Count: 4 + +5 Play action data +^^^^^^^^^^^^^^^^^^ + +Before replaying the bag file, enter :kbd:`Ctrl-C` in the terminal where ``fibonacci_action_client`` is running. +When ``fibonacci_action_client`` stops running, ``fibonacci_action_server`` also stops printing the result because there are no incoming requests. + +Replaying the action data from the bag file will start sending the requests to ``fibonacci_action_server``. + +Enter the command: + +.. code-block:: console + + $ ros2 bag play --send-actions-as-client + [INFO] [1744953720.691068674] [rosbag2_player]: Set rate to 1 + [INFO] [1744953720.702365209] [rosbag2_player]: Adding keyboard callbacks. + [INFO] [1744953720.702409447] [rosbag2_player]: Press SPACE for Pause/Resume + [INFO] [1744953720.702423063] [rosbag2_player]: Press CURSOR_RIGHT for Play Next Message + [INFO] [1744953720.702431404] [rosbag2_player]: Press CURSOR_UP for Increase Rate 10% + [INFO] [1744953720.702437677] [rosbag2_player]: Press CURSOR_DOWN for Decrease Rate 10% + Progress bar enabled at 3 Hz. + Progress bar [?]: [R]unning, [P]aused, [B]urst, [D]elayed, [S]topped + [INFO] [1744953720.702577680] [rosbag2_player]: Playback until timestamp: -1 + + + ====== Playback Progress ====== + [1744953656.281683207] Duration 9.02/9.02 [R] + +Your ``fibonacci_action_server`` terminal will once again start printing the following service messages: + +.. code-block:: console + + [INFO] [1744953720.815577088] [fibonacci_action_server]: Executing goal... + [INFO] [1744953720.815927050] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1]) + [INFO] [1744953721.816509658] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2]) + [INFO] [1744953722.817220270] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3]) + [INFO] [1744953723.817876426] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5]) + [INFO] [1744953724.818498515] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8]) + [INFO] [1744953725.819182228] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13]) + [INFO] [1744953726.820032562] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21]) + [INFO] [1744953727.820738690] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]) + [INFO] [1744953728.821449308] [fibonacci_action_server]: Feedback: array('i', [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]) + +This is because ``ros2 bag play`` sends the action goal request data from the bag file to the ``/fibonacci`` action. + +We can also introspect action communication as ``ros2 bag play`` is playing it back to verify the ``fibonacci_action_server``. + +Run this command before ``ros2 bag play`` to see the ``fibonacci_action_server``. +You can see the action goal request from the bag file and the service response from ``fibonacci_action_server``: + +.. code-block:: console + + $ ros2 action echo --flow-style /fibonacci + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [34, 116, 225, 217, 48, 121, 146, 36, 240, 98, 99, 134, 55, 227, 184, 72]}, stamp: {sec: 1744953720, nanosec: 804984321}}, status: 4}] + --- + interface: GOAL_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1744953927 + nanosec: 957359210 + client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, goal: {order: 10}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: RESPONSE_SENT + stamp: + sec: 1744953927 + nanosec: 957726145 + client_gid: [1, 15, 165, 231, 190, 254, 1, 50, 0, 0, 0, 0, 0, 0, 19, 4] + sequence_number: 1 + request: [] + response: [{accepted: true, stamp: {sec: 1744953927, nanosec: 957615866}}] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12]}, stamp: {sec: 1744953927, nanosec: 957663383}}, status: 2}] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [191, 200, 153, 122, 221, 251, 152, 172, 60, 69, 94, 20, 212, 160, 40, 12] + feedback: + sequence: [0, 1, 1] + --- + ... + +Summary +------- + +You can record data passed on topics, services and actions in your ROS 2 system using the ``ros2 bag`` command. +Whether you're sharing your work with others or introspecting your own experiments, it's a great tool to know about. + +Next steps +---------- + +You've completed the "Beginner: CLI Tools" tutorials! +The next step is tackling the "Beginner: Client Libraries" tutorials, starting with :doc:`../../../client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace`. + +Related content +--------------- + +A more thorough explanation of ``ros2 bag`` can be found in the README `here `__. +For more information on service recording and playback can be found in the design document `here `__. +For more information on action recording and playback can be found in the design document `here `__. For more information on QoS compatibility and ``ros2 bag``, see :doc:`../../../../Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback`. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions.rst similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions.rst rename to source/ROS-Framework/interfaces/actions/Working-with-actions.rst diff --git a/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst similarity index 95% rename from source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst index ce7f33300f4..38826475f96 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Action-Introspection.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst @@ -1,346 +1,346 @@ -.. redirect-from:: - - Tutorials/Demos/Action-Introspection - -Configure action introspection -============================== - -**Goal:** Configure action introspection for an action client and an action server. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 2 - :local: - -Overview --------- - -ROS 2 applications usually consist of actions to execute specific long-running procedures or work in remote nodes. -It is possible to introspect action data communication with action introspection. - -ROS 2 actions are built on topics and services, so action introspection is based on :doc:`Service Introspection <../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>`. - -In this demo, we'll be highlighting how to configure action introspection state for an action client and an action server and monitor action communication with ``ros2 action echo``. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. - -If you've installed ROS 2 binary packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` and ``ros-{DISTRO}-demo-nodes-py`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Introspection Configuration State ---------------------------------- - -There are three configuration states for action introspection that are the same states as service introspection. - -.. list-table:: Action Introspection Configuration State - :widths: 25 25 - - * - RCL_SERVICE_INTROSPECTION_OFF - - Disabled - * - RCL_SERVICE_INTROSPECTION_METADATA - - Only metadata without any user data contents - * - RCL_SERVICE_INTROSPECTION_CONTENTS - - User data contents with metadata - -Introspection demo ------------------- - -This demo shows how to manage action introspection and monitor the action data communication with using ``ros2 action echo``. - -Action server -^^^^^^^^^^^^^ - -You can find the source code here: `fibonacci_action_server.py `__. -``FibonacciActionServer`` has a parameter named ``action_server_configure_introspection`` to configure the action introspection state. - -.. code-block:: python - - class FibonacciActionServer(Node): - ... - def on_post_set_parameters_callback(self, parameter_list): - for param in parameter_list: - if param.name != 'action_server_configure_introspection': - continue - - introspection_state = ServiceIntrospectionState.OFF - if param.value == 'disabled': - introspection_state = ServiceIntrospectionState.OFF - elif param.value == 'metadata': - introspection_state = ServiceIntrospectionState.METADATA - elif param.value == 'contents': - introspection_state = ServiceIntrospectionState.CONTENTS - - self._action_server.configure_introspection(self.get_clock(), - qos_profile_system_default, - introspection_state) - break - ... - -If you want to try the C++ version, you can find the source code here: `fibonacci_action_server.cpp `__. - -Action introspection is disabled by default, so users need to enable it with ``action_server_configure_introspection`` parameter when the server starts up. -In this demo, ``FibonacciActionServer`` enables action introspection when the value of the ``action_server_configure_introspection`` parameter is ``contents``. - -.. code-block:: console - - $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents - -To change action introspection state, we need to set the ``action_server_configure_introspection`` parameter as follows. - -To change it to user data contents with metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_server action_server_configure_introspection contents - -To change it to only metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_server action_server_configure_introspection metadata - -To disable: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_server action_server_configure_introspection disabled - -Action client -^^^^^^^^^^^^^ - -You can find the source code here: `fibonacci_action_client.cpp `__. -``FibonacciActionClient`` has a parameter named ``action_client_configure_introspection`` to configure the action introspection state. - -.. code-block:: c++ - - namespace action_tutorials_cpp - { - class FibonacciActionClient : public rclcpp::Node - ... - auto post_set_parameter_callback = - [this](const std::vector & parameters) { - for (const rclcpp::Parameter & param : parameters) { - if (param.get_name() != "action_client_configure_introspection") { - continue; - } - - rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - - if (param.as_string() == "disabled") { - introspection_state = RCL_SERVICE_INTROSPECTION_OFF; - } else if (param.as_string() == "metadata") { - introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; - } else if (param.as_string() == "contents") { - introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; - } - - this->client_ptr_->configure_introspection( - this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); - break; - } - }; - ... - -If you want to try the Python version, you can find the source code here: `fibonacci_action_client.py `__. - -And then, we start and configure ``FibonacciActionClient`` in the same way. - -.. code-block:: console - - $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents - -To change action introspection state, we need to set the ``action_client_configure_introspection`` parameter as follows. -Note that ``FibonacciActionClient`` only runs in short time, so it is recommended to set the parameter before running the client as above. - -To change it to user data contents with metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_client action_client_configure_introspection contents - -To change it to only metadata: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_client action_client_configure_introspection metadata - -To disable: - -.. code-block:: console - - $ ros2 param set /fibonacci_action_client action_client_configure_introspection disabled - -Introspect -^^^^^^^^^^ - -In this tutorial, the following is an example output with action introspection state ``contents`` on both ``FibonacciActionServer`` and ``FibonacciActionClient``. -To monitor action communication between ``FibonacciActionServer`` and ``FibonacciActionClient``, let's run it: - -.. code-block:: console - - $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style - interface: GOAL_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 400435819 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1742070798 - nanosec: 400706446 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: RESULT_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 401486678 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] - response: [] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] - --- - interface: GOAL_SERVICE - info: - event_type: RESPONSE_SENT - stamp: - sec: 1742070798 - nanosec: 401109161 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [] - response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] - --- - interface: RESULT_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1742070798 - nanosec: 401579875 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1742070798 - nanosec: 401234269 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [] - response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55] - --- - interface: RESULT_SERVICE - info: - event_type: RESPONSE_SENT - stamp: - sec: 1742070807 - nanosec: 402339670 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [] - response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] - --- - interface: RESULT_SERVICE - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1742070807 - nanosec: 402698784 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [] - response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 4}] - --- - ... - -You can see the ``interface: GOAL_SERVICE`` and ``interface: RESULT_SERVICE``, those introspection service events take place in both ``FibonacciActionServer`` and ``FibonacciActionClient``. -And you can also see ``interface: FEEDBACK_TOPIC`` and ``interface: STATUS_TOPIC`` data, those topics are published by ``FibonacciActionServer`` and subscribed by ``FibonacciActionClient``. - -Now you can see the action communication between ``FibonacciActionServer`` and ``FibonacciActionClient`` with ``ros2 action echo``. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Demos/Action-Introspection + +Configure action introspection +============================== + +**Goal:** Configure action introspection for an action client and an action server. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 2 + :local: + +Overview +-------- + +ROS 2 applications usually consist of actions to execute specific long-running procedures or work in remote nodes. +It is possible to introspect action data communication with action introspection. + +ROS 2 actions are built on topics and services, so action introspection is based on :doc:`Service Introspection <../../../../Developer-Tools/Introspection-and-analysis/Service-Introspection>`. + +In this demo, we'll be highlighting how to configure action introspection state for an action client and an action server and monitor action communication with ``ros2 action echo``. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 binary packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` and ``ros-{DISTRO}-demo-nodes-py`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Introspection Configuration State +--------------------------------- + +There are three configuration states for action introspection that are the same states as service introspection. + +.. list-table:: Action Introspection Configuration State + :widths: 25 25 + + * - RCL_SERVICE_INTROSPECTION_OFF + - Disabled + * - RCL_SERVICE_INTROSPECTION_METADATA + - Only metadata without any user data contents + * - RCL_SERVICE_INTROSPECTION_CONTENTS + - User data contents with metadata + +Introspection demo +------------------ + +This demo shows how to manage action introspection and monitor the action data communication with using ``ros2 action echo``. + +Action server +^^^^^^^^^^^^^ + +You can find the source code here: `fibonacci_action_server.py `__. +``FibonacciActionServer`` has a parameter named ``action_server_configure_introspection`` to configure the action introspection state. + +.. code-block:: python + + class FibonacciActionServer(Node): + ... + def on_post_set_parameters_callback(self, parameter_list): + for param in parameter_list: + if param.name != 'action_server_configure_introspection': + continue + + introspection_state = ServiceIntrospectionState.OFF + if param.value == 'disabled': + introspection_state = ServiceIntrospectionState.OFF + elif param.value == 'metadata': + introspection_state = ServiceIntrospectionState.METADATA + elif param.value == 'contents': + introspection_state = ServiceIntrospectionState.CONTENTS + + self._action_server.configure_introspection(self.get_clock(), + qos_profile_system_default, + introspection_state) + break + ... + +If you want to try the C++ version, you can find the source code here: `fibonacci_action_server.cpp `__. + +Action introspection is disabled by default, so users need to enable it with ``action_server_configure_introspection`` parameter when the server starts up. +In this demo, ``FibonacciActionServer`` enables action introspection when the value of the ``action_server_configure_introspection`` parameter is ``contents``. + +.. code-block:: console + + $ ros2 run action_tutorials_py fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents + +To change action introspection state, we need to set the ``action_server_configure_introspection`` parameter as follows. + +To change it to user data contents with metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_server action_server_configure_introspection contents + +To change it to only metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_server action_server_configure_introspection metadata + +To disable: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_server action_server_configure_introspection disabled + +Action client +^^^^^^^^^^^^^ + +You can find the source code here: `fibonacci_action_client.cpp `__. +``FibonacciActionClient`` has a parameter named ``action_client_configure_introspection`` to configure the action introspection state. + +.. code-block:: c++ + + namespace action_tutorials_cpp + { + class FibonacciActionClient : public rclcpp::Node + ... + auto post_set_parameter_callback = + [this](const std::vector & parameters) { + for (const rclcpp::Parameter & param : parameters) { + if (param.get_name() != "action_client_configure_introspection") { + continue; + } + + rcl_service_introspection_state_t introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + + if (param.as_string() == "disabled") { + introspection_state = RCL_SERVICE_INTROSPECTION_OFF; + } else if (param.as_string() == "metadata") { + introspection_state = RCL_SERVICE_INTROSPECTION_METADATA; + } else if (param.as_string() == "contents") { + introspection_state = RCL_SERVICE_INTROSPECTION_CONTENTS; + } + + this->client_ptr_->configure_introspection( + this->get_clock(), rclcpp::SystemDefaultsQoS(), introspection_state); + break; + } + }; + ... + +If you want to try the Python version, you can find the source code here: `fibonacci_action_client.py `__. + +And then, we start and configure ``FibonacciActionClient`` in the same way. + +.. code-block:: console + + $ ros2 run action_tutorials_cpp fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents + +To change action introspection state, we need to set the ``action_client_configure_introspection`` parameter as follows. +Note that ``FibonacciActionClient`` only runs in short time, so it is recommended to set the parameter before running the client as above. + +To change it to user data contents with metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_client action_client_configure_introspection contents + +To change it to only metadata: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_client action_client_configure_introspection metadata + +To disable: + +.. code-block:: console + + $ ros2 param set /fibonacci_action_client action_client_configure_introspection disabled + +Introspect +^^^^^^^^^^ + +In this tutorial, the following is an example output with action introspection state ``contents`` on both ``FibonacciActionServer`` and ``FibonacciActionClient``. +To monitor action communication between ``FibonacciActionServer`` and ``FibonacciActionClient``, let's run it: + +.. code-block:: console + + $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style + interface: GOAL_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 400435819 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1742070798 + nanosec: 400706446 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: RESULT_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 401486678 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] + response: [] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] + --- + interface: GOAL_SERVICE + info: + event_type: RESPONSE_SENT + stamp: + sec: 1742070798 + nanosec: 401109161 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [] + response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] + --- + interface: RESULT_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1742070798 + nanosec: 401579875 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1742070798 + nanosec: 401234269 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [] + response: [{accepted: true, stamp: {sec: 0, nanosec: 0}}] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55] + --- + interface: RESULT_SERVICE + info: + event_type: RESPONSE_SENT + stamp: + sec: 1742070807 + nanosec: 402339670 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [] + response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] + --- + interface: RESULT_SERVICE + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1742070807 + nanosec: 402698784 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [] + response: [{status: 4, result: {sequence: [0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]}}] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 4}] + --- + ... + +You can see the ``interface: GOAL_SERVICE`` and ``interface: RESULT_SERVICE``, those introspection service events take place in both ``FibonacciActionServer`` and ``FibonacciActionClient``. +And you can also see ``interface: FEEDBACK_TOPIC`` and ``interface: STATUS_TOPIC`` data, those topics are published by ``FibonacciActionServer`` and subscribed by ``FibonacciActionClient``. + +Now you can see the action communication between ``FibonacciActionServer`` and ``FibonacciActionClient`` with ``ros2 action echo``. + +Related content +--------------- + - `Action Introspection REP-2018 `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst similarity index 90% rename from source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst index 97e10035a5a..52e9977f0cd 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Creating-an-Action.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst @@ -1,223 +1,223 @@ -.. redirect-from:: - - Tutorials/Actions/Creating-an-Action - Tutorials/Intermediate/Creating-an-Action - -.. _ActionCreate: - -Creating an action -================== - -**Goal:** Define an action in a ROS 2 package. - -**Tutorial level:** Intermediate - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -You learned about actions previously in the :doc:`Understanding-ROS2-Actions/Understanding-ROS2-Actions` tutorial. -Like the other communication types and their respective interfaces (topics/msg and services/srv), -you can also custom-define actions in your packages. -This tutorial shows you how to define and build an action that you can use -with the action server and action client you will write in the next tutorial. - -Prerequisites -------------- - -You should have :doc:`ROS 2 <../../../Get-Started/Installation>` and `colcon `__ installed. - -You should know how to set up a :doc:`workspace <../../client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and create packages. - -Remember to :doc:`source your ROS 2 installation <../../../Get-Started/Configuring-ROS2-Environment>` first. - -Tasks ------ - -1 Creating an interface package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src # you can reuse an existing workspace with this naming convention - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces - - .. group-tab:: macOS - - .. code-block:: console - - $ mkdir -p ~/ros2_ws/src - $ cd ~/ros2_ws/src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces - - .. group-tab:: Windows - - .. code-block:: console - - $ md \ros2_ws\src - $ cd \ros2_ws\src - $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces - -``custom_action_interfaces`` is the name of the new package. -Note that it is, and can only be, a CMake package, but this doesn't restrict in which type of packages you can use your actions. -The ``--build-type ament_cmake`` flag is largely optional when creating a new ROS 2 package but we are including it here for completeness. -You can create your own custom interfaces in a CMake package, and then use it in a C++ or Python node. - -.. note:: - - It is good practice to keep ``.msg``, ``.srv``, and ``.action`` files in separate packages from the nodes that use them. - This makes it easier to reuse the interface definitions across different packages. - - -2 Defining an action -^^^^^^^^^^^^^^^^^^^^ - -Actions are defined in ``.action`` files of the form: - -.. code-block:: bash - - # Request - --- - # Result - --- - # Feedback - -An action definition is made up of three message definitions separated by ``---``. - -- A *request* message is sent from an action client to an action server initiating a new goal. -- A *result* message is sent from an action server to an action client when a goal is done. -- *Feedback* messages are periodically sent from an action server to an action client with updates about a goal. - -An instance of an action is typically referred to as a *goal*. - -Say we want to define a new action "Fibonacci" for computing the `Fibonacci sequence `__. - -Create an ``action`` directory in our ROS 2 package ``custom_action_interfaces``: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd custom_action_interfaces - $ mkdir action - - .. group-tab:: macOS - - .. code-block:: console - - $ cd custom_action_interfaces - $ mkdir action - - .. group-tab:: Windows - - .. code-block:: console - - $ cd custom_action_interfaces - $ md action - -Within the ``action`` directory, create a file called ``Fibonacci.action`` with the following contents: - -.. code-block:: bash - - int32 order - --- - int32[] sequence - --- - int32[] sequence - -The goal request is the ``order`` of the Fibonacci sequence we want to compute, the result is the final ``sequence``, and the feedback is the ``sequence`` computed so far. - -3 Building an action -^^^^^^^^^^^^^^^^^^^^ - -Before we can use the new Fibonacci action type in our code, we must pass the definition to the rosidl code generation pipeline. - -This is accomplished by adding the following lines to our ``CMakeLists.txt`` before the ``ament_package()`` line: - -.. code-block:: cmake - - find_package(rosidl_default_generators REQUIRED) - - rosidl_generate_interfaces(${PROJECT_NAME} - "action/Fibonacci.action" - ) - -We should also add the required dependencies to our ``package.xml``: - -.. code-block:: xml - - rosidl_default_generators - - rosidl_interface_packages - -We should now be able to build the package containing the ``Fibonacci`` action definition: - -.. code-block:: console - - $ cd ~/ros2_ws # Change to the root of the workspace - $ colcon build # Build - -We're done! - -By convention, action types will be prefixed by their package name and the word ``action``. -So when we want to refer to our new action, it will have the full name ``custom_action_interfaces/action/Fibonacci``. - -We can check that our action built successfully with the command line tool. -First source our workspace: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source install/local_setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ source install/local_setup.console - - .. group-tab:: Windows - - .. code-block:: console - - $ call install\local_setup.bat - -Now check that our action definition exists: - -.. code-block:: console - - $ ros2 interface show custom_action_interfaces/action/Fibonacci - -You should see the Fibonacci action definition printed to the screen. - -Summary -------- - -In this tutorial, you learned the structure of an action definition. -You also learned how to correctly build a new action interface using ``CMakeLists.txt`` and ``package.xml``, -and how to verify a successful build. - -Next steps ----------- - -Next, let's utilize your newly defined action interface by creating an action service and client (in :doc:`Python ` or :doc:`C++ `). - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Actions/Creating-an-Action + Tutorials/Intermediate/Creating-an-Action + +.. _ActionCreate: + +Creating an action +================== + +**Goal:** Define an action in a ROS 2 package. + +**Tutorial level:** Intermediate + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +You learned about actions previously in the :doc:`Understanding-ROS2-Actions/Understanding-ROS2-Actions` tutorial. +Like the other communication types and their respective interfaces (topics/msg and services/srv), +you can also custom-define actions in your packages. +This tutorial shows you how to define and build an action that you can use +with the action server and action client you will write in the next tutorial. + +Prerequisites +------------- + +You should have :doc:`ROS 2 <../../../../Get-Started/Installation>` and `colcon `__ installed. + +You should know how to set up a :doc:`workspace <../../../client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace>` and create packages. + +Remember to :doc:`source your ROS 2 installation <../../../../Get-Started/Configuring-ROS2-Environment>` first. + +Tasks +----- + +1 Creating an interface package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src # you can reuse an existing workspace with this naming convention + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces + + .. group-tab:: macOS + + .. code-block:: console + + $ mkdir -p ~/ros2_ws/src + $ cd ~/ros2_ws/src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces + + .. group-tab:: Windows + + .. code-block:: console + + $ md \ros2_ws\src + $ cd \ros2_ws\src + $ ros2 pkg create --build-type ament_cmake --license Apache-2.0 custom_action_interfaces + +``custom_action_interfaces`` is the name of the new package. +Note that it is, and can only be, a CMake package, but this doesn't restrict in which type of packages you can use your actions. +The ``--build-type ament_cmake`` flag is largely optional when creating a new ROS 2 package but we are including it here for completeness. +You can create your own custom interfaces in a CMake package, and then use it in a C++ or Python node. + +.. note:: + + It is good practice to keep ``.msg``, ``.srv``, and ``.action`` files in separate packages from the nodes that use them. + This makes it easier to reuse the interface definitions across different packages. + + +2 Defining an action +^^^^^^^^^^^^^^^^^^^^ + +Actions are defined in ``.action`` files of the form: + +.. code-block:: bash + + # Request + --- + # Result + --- + # Feedback + +An action definition is made up of three message definitions separated by ``---``. + +- A *request* message is sent from an action client to an action server initiating a new goal. +- A *result* message is sent from an action server to an action client when a goal is done. +- *Feedback* messages are periodically sent from an action server to an action client with updates about a goal. + +An instance of an action is typically referred to as a *goal*. + +Say we want to define a new action "Fibonacci" for computing the `Fibonacci sequence `__. + +Create an ``action`` directory in our ROS 2 package ``custom_action_interfaces``: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd custom_action_interfaces + $ mkdir action + + .. group-tab:: macOS + + .. code-block:: console + + $ cd custom_action_interfaces + $ mkdir action + + .. group-tab:: Windows + + .. code-block:: console + + $ cd custom_action_interfaces + $ md action + +Within the ``action`` directory, create a file called ``Fibonacci.action`` with the following contents: + +.. code-block:: bash + + int32 order + --- + int32[] sequence + --- + int32[] sequence + +The goal request is the ``order`` of the Fibonacci sequence we want to compute, the result is the final ``sequence``, and the feedback is the ``sequence`` computed so far. + +3 Building an action +^^^^^^^^^^^^^^^^^^^^ + +Before we can use the new Fibonacci action type in our code, we must pass the definition to the rosidl code generation pipeline. + +This is accomplished by adding the following lines to our ``CMakeLists.txt`` before the ``ament_package()`` line: + +.. code-block:: cmake + + find_package(rosidl_default_generators REQUIRED) + + rosidl_generate_interfaces(${PROJECT_NAME} + "action/Fibonacci.action" + ) + +We should also add the required dependencies to our ``package.xml``: + +.. code-block:: xml + + rosidl_default_generators + + rosidl_interface_packages + +We should now be able to build the package containing the ``Fibonacci`` action definition: + +.. code-block:: console + + $ cd ~/ros2_ws # Change to the root of the workspace + $ colcon build # Build + +We're done! + +By convention, action types will be prefixed by their package name and the word ``action``. +So when we want to refer to our new action, it will have the full name ``custom_action_interfaces/action/Fibonacci``. + +We can check that our action built successfully with the command line tool. +First source our workspace: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source install/local_setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ source install/local_setup.console + + .. group-tab:: Windows + + .. code-block:: console + + $ call install\local_setup.bat + +Now check that our action definition exists: + +.. code-block:: console + + $ ros2 interface show custom_action_interfaces/action/Fibonacci + +You should see the Fibonacci action definition printed to the screen. + +Summary +------- + +In this tutorial, you learned the structure of an action definition. +You also learned how to correctly build a new action interface using ``CMakeLists.txt`` and ``package.xml``, +and how to verify a successful build. + +Next steps +---------- + +Next, let's utilize your newly defined action interface by creating an action service and client (in :doc:`Python ` or :doc:`C++ `). + +Related content +--------------- + For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst similarity index 93% rename from source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst index 553aba7b72a..6131e81c02f 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst @@ -1,425 +1,425 @@ -.. redirect-from:: - - Tutorials/Understanding-ROS2-Actions - Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Actions/Understanding-ROS2-Actions - -.. _ROS2Actions: - -Understanding actions -===================== - -**Goal:** Introspect actions in ROS 2. - -**Tutorial level:** Beginner - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Actions are one of the communication types in ROS 2 and are intended for long running tasks. -They consist of three parts: a goal, feedback, and a result. - -Actions are built on topics and services. -Their functionality is similar to services, except actions can be canceled. -They also provide steady feedback, as opposed to services which return a single response. - -Actions use a client-server model, similar to the publisher-subscriber model (described in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). -An "action client" node sends a goal to an "action server" node that acknowledges the goal and returns a stream of feedback and a result. - -.. image:: images/Action-SingleActionClient.gif - -Prerequisites -------------- - -This tutorial builds off concepts, like :doc:`nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, covered in previous tutorials. - -This tutorial uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ - -Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - - -2 Use actions -^^^^^^^^^^^^^ - -When you launch the ``/teleop_turtle`` node, you will see the following message in your terminal: - -.. code-block:: console - - Use arrow keys to move the turtle. - Use G|B|V|C|D|E|R|T keys to rotate to absolute orientations. 'F' to cancel a rotation. - -Let's focus on the second line, which corresponds to an action. -(The first instruction corresponds to the "cmd_vel" topic, discussed previously in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`.) - -Notice that the letter keys ``G|B|V|C|D|E|R|T`` form a "box" around the ``F`` key on a US QWERTY keyboard (if you are not using a QWERTY keyboard, see `this link `__ to follow along). -Each key's position around ``F`` corresponds to that orientation in turtlesim. -For example, the ``E`` will rotate the turtle's orientation to the upper left corner. - -Pay attention to the terminal where the ``/turtlesim`` node is running. -Each time you press one of these keys, you are sending a goal to an action server that is part of the ``/turtlesim`` node. -The goal is to rotate the turtle to face a particular direction. -A message relaying the result of the goal should display once the turtle completes its rotation: - -.. code-block:: console - - [INFO] [turtlesim]: Rotation goal completed successfully - -The ``F`` key will cancel a goal mid-execution. - -Try pressing the ``C`` key, and then pressing the ``F`` key before the turtle can complete its rotation. -In the terminal where the ``/turtlesim`` node is running, you will see the message: - -.. code-block:: console - - [INFO] [turtlesim]: Rotation goal canceled - -Not only can the client-side (your input in the teleop) stop a goal, but the server-side (the ``/turtlesim`` node) can as well. -When the server-side chooses to stop processing a goal, it is said to "abort" the goal. - -Try hitting the ``D`` key, then the ``G`` key before the first rotation can complete. -In the terminal where the ``/turtlesim`` node is running, you will see the message: - -.. code-block:: console - - [WARN] [turtlesim]: Rotation goal received before a previous goal finished. Aborting previous goal - -This action server chose to abort the first goal because it got a new one. -It could have chosen something else, like reject the new goal or execute the second goal after the first one finished. -Don't assume every action server will choose to abort the current goal when it gets a new one. - -3 ros2 node info -^^^^^^^^^^^^^^^^ - -To see the list of actions a node provides, ``/turtlesim`` in this case, open a new terminal and run the command: - -.. code-block:: console - - $ ros2 node info /turtlesim - /turtlesim - Subscribers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /turtle1/cmd_vel: geometry_msgs/msg/Twist - Publishers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /rosout: rcl_interfaces/msg/Log - /turtle1/color_sensor: turtlesim_msgs/msg/Color - /turtle1/pose: turtlesim_msgs/msg/Pose - Service Servers: - /clear: std_srvs/srv/Empty - /kill: turtlesim_msgs/srv/Kill - /reset: std_srvs/srv/Empty - /spawn: turtlesim_msgs/srv/Spawn - /turtle1/set_pen: turtlesim_msgs/srv/SetPen - /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute - /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative - /turtlesim/describe_parameters: rcl_interfaces/srv/DescribeParameters - /turtlesim/get_parameter_types: rcl_interfaces/srv/GetParameterTypes - /turtlesim/get_parameters: rcl_interfaces/srv/GetParameters - /turtlesim/list_parameters: rcl_interfaces/srv/ListParameters - /turtlesim/set_parameters: rcl_interfaces/srv/SetParameters - /turtlesim/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically - Service Clients: - - Action Servers: - /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute - Action Clients: - -The command returns a list of ``/turtlesim``'s subscribers, publishers, services, action servers and action clients. - -Notice that the ``/turtle1/rotate_absolute`` action for ``/turtlesim`` is under ``Action Servers``. -This means ``/turtlesim`` responds to and provides feedback for the ``/turtle1/rotate_absolute`` action. - -The ``/teleop_turtle`` node has the name ``/turtle1/rotate_absolute`` under ``Action Clients`` meaning that it sends goals for that action name. -To see that, run: - -.. code-block:: console - - $ ros2 node info /teleop_turtle - /teleop_turtle - Subscribers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - Publishers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /rosout: rcl_interfaces/msg/Log - /turtle1/cmd_vel: geometry_msgs/msg/Twist - Service Servers: - /teleop_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters - /teleop_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes - /teleop_turtle/get_parameters: rcl_interfaces/srv/GetParameters - /teleop_turtle/list_parameters: rcl_interfaces/srv/ListParameters - /teleop_turtle/set_parameters: rcl_interfaces/srv/SetParameters - /teleop_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically - Service Clients: - - Action Servers: - - Action Clients: - /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute - -4 ros2 action list -^^^^^^^^^^^^^^^^^^ - -To identify all the actions in the ROS graph, run the command: - -.. code-block:: console - - $ ros2 action list - /turtle1/rotate_absolute - -This is the only action in the ROS graph right now. -It controls the turtle's rotation, as you saw earlier. -You also already know that there is one action client (part of ``/teleop_turtle``) and one action server (part of ``/turtlesim``) for this action from using the ``ros2 node info `` command. - -4.1 ros2 action list -t -~~~~~~~~~~~~~~~~~~~~~~~ - -Actions have types, similar to topics and services. -To find ``/turtle1/rotate_absolute``'s type, run the command: - -.. code-block:: console - - $ ros2 action list -t - /turtle1/rotate_absolute [turtlesim_msgs/action/RotateAbsolute] - -In brackets to the right of each action name (in this case only ``/turtle1/rotate_absolute``) is the action type, ``turtlesim_msgs/action/RotateAbsolute``. -You will need this when you want to execute an action from the command line or from code. - -5 ros2 action type -^^^^^^^^^^^^^^^^^^ - -If you want to check the action type for the action, run the command: - -.. code-block:: console - - $ ros2 action type /turtle1/rotate_absolute - turtlesim_msgs/action/RotateAbsolute - -6 ros2 action info -^^^^^^^^^^^^^^^^^^ - -You can further introspect the ``/turtle1/rotate_absolute`` action with the command: - -.. code-block:: console - - $ ros2 action info /turtle1/rotate_absolute - Action: /turtle1/rotate_absolute - Action clients: 1 - /teleop_turtle - Action servers: 1 - /turtlesim - -This tells us what we learned earlier from running ``ros2 node info`` on each node: -The ``/teleop_turtle`` node has an action client and the ``/turtlesim`` node has an action server for the ``/turtle1/rotate_absolute`` action. - -7 ros2 interface show -^^^^^^^^^^^^^^^^^^^^^ - -One more piece of information you will need before sending or executing an action goal yourself is the structure of the action type. - -Recall that you identified ``/turtle1/rotate_absolute``'s type when running the command ``ros2 action list -t``. -Enter the following command with the action type in your terminal: - -.. code-block:: console - - $ ros2 interface show turtlesim_msgs/action/RotateAbsolute - -Which will return: - -.. code-block:: text - - # The desired heading in radians - float32 theta - --- - # The angular displacement in radians to the starting position - float32 delta - --- - # The remaining rotation in radians - float32 remaining - -The section of this message above the first ``---`` is the structure (data type and name) of the goal request. -The next section is the structure of the result. -The last section is the structure of the feedback. - -8 ros2 action send_goal -^^^^^^^^^^^^^^^^^^^^^^^ - -Now let's send an action goal from the command line with the following syntax: - -.. code-block:: console - - $ ros2 action send_goal - -```` need to be in YAML format. - -Keep an eye on the turtlesim window, and enter the following command into your terminal: - -.. code-block:: console - - $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: 1.57}" - Waiting for an action server to become available... - Sending goal: - theta: 1.57 - - Goal accepted with ID: f8db8f44410849eaa93d3feb747dd444 - - Result: - delta: -1.568000316619873 - - Goal finished with status: SUCCEEDED - - -You should see the turtle rotating. - - -All goals have a unique ID, shown in the return message. -You can also see the result, a field with the name ``delta``, which is the displacement to the starting position. - -To see the feedback of this goal, add ``--feedback`` to the ``ros2 action send_goal`` command: - -.. code-block:: console - - $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: -1.57}" --feedback - Sending goal: - theta: -1.57 - - Goal accepted with ID: e6092c831f994afda92f0086f220da27 - - Feedback: - remaining: -3.1268222332000732 - - Feedback: - remaining: -3.1108222007751465 - - … - - Result: - delta: 3.1200008392333984 - - Goal finished with status: SUCCEEDED - -You will continue to receive feedback, the remaining radians, until the goal is complete. - -.. _understanding-actions-ros2-action-echo: - -9 ros2 action echo -^^^^^^^^^^^^^^^^^^ - -To see the data communication between an action client and an action server you can ``echo`` the action data using: - -.. code-block:: console - - $ ros2 action echo - -``ros2 action echo`` depends on action introspection of an action client and server, that is disabled by default. -To enable it, users must call ``configure_introspection`` after creating an action client or server. - -Start up the ``fibonacci_action_server`` and ``fibonacci_action_client``, enabling ``action_server_configure_introspection`` parameter for demonstration. - -.. code-block:: console - - $ ros2 run action_tutorials_cpp fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents - -.. code-block:: console - - $ ros2 run action_tutorials_py fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents - -Now we are able to see the action communication between ``fibonacci_action_server`` and ``fibonacci_action_client`` via ``ros2 action echo``. - -.. code-block:: console - - $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style - interface: GOAL_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 400435819 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: GOAL_SERVICE - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1742070798 - nanosec: 400706446 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] - response: [] - --- - interface: RESULT_SERVICE - info: - event_type: REQUEST_SENT - stamp: - sec: 1742070798 - nanosec: 401486678 - client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] - sequence_number: 1 - request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] - response: [] - --- - interface: FEEDBACK_TOPIC - goal_id: - uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] - feedback: - sequence: [0, 1, 1] - --- - interface: STATUS_TOPIC - status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] - --- - ... - -.. note:: - - This feature is available on ``Kilted Kaiju`` or later. - -Summary -------- - -Actions are like services that allow you to execute long running tasks, provide regular feedback, and are cancelable. - -A robot system would likely use actions for navigation. -An action goal could tell a robot to travel to a position. -While the robot navigates to the position, it can send updates along the way (i.e. feedback), and then a final result message once it's reached its destination. - -Turtlesim has an action server that action clients can send goals to for rotating turtles. -In this tutorial, you introspected that action, ``/turtle1/rotate_absolute``, to get a better idea of what actions are and how they work. - -Next steps ----------- - -Now you've covered all of the core ROS 2 concepts. -The last few tutorials in this set will introduce you to some tools and techniques that will make using ROS 2 easier, starting with :doc:`../../../nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console`. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Understanding-ROS2-Actions + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Actions/Understanding-ROS2-Actions + +.. _ROS2Actions: + +Understanding actions +===================== + +**Goal:** Introspect actions in ROS 2. + +**Tutorial level:** Beginner + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Actions are one of the communication types in ROS 2 and are intended for long running tasks. +They consist of three parts: a goal, feedback, and a result. + +Actions are built on topics and services. +Their functionality is similar to services, except actions can be canceled. +They also provide steady feedback, as opposed to services which return a single response. + +Actions use a client-server model, similar to the publisher-subscriber model (described in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`). +An "action client" node sends a goal to an "action server" node that acknowledges the goal and returns a stream of feedback and a result. + +.. image:: images/Action-SingleActionClient.gif + +Prerequisites +------------- + +This tutorial builds off concepts, like :doc:`nodes <../../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, covered in previous tutorials. + +This tutorial uses the :doc:`turtlesim package <../../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ + +Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + + +2 Use actions +^^^^^^^^^^^^^ + +When you launch the ``/teleop_turtle`` node, you will see the following message in your terminal: + +.. code-block:: console + + Use arrow keys to move the turtle. + Use G|B|V|C|D|E|R|T keys to rotate to absolute orientations. 'F' to cancel a rotation. + +Let's focus on the second line, which corresponds to an action. +(The first instruction corresponds to the "cmd_vel" topic, discussed previously in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`.) + +Notice that the letter keys ``G|B|V|C|D|E|R|T`` form a "box" around the ``F`` key on a US QWERTY keyboard (if you are not using a QWERTY keyboard, see `this link `__ to follow along). +Each key's position around ``F`` corresponds to that orientation in turtlesim. +For example, the ``E`` will rotate the turtle's orientation to the upper left corner. + +Pay attention to the terminal where the ``/turtlesim`` node is running. +Each time you press one of these keys, you are sending a goal to an action server that is part of the ``/turtlesim`` node. +The goal is to rotate the turtle to face a particular direction. +A message relaying the result of the goal should display once the turtle completes its rotation: + +.. code-block:: console + + [INFO] [turtlesim]: Rotation goal completed successfully + +The ``F`` key will cancel a goal mid-execution. + +Try pressing the ``C`` key, and then pressing the ``F`` key before the turtle can complete its rotation. +In the terminal where the ``/turtlesim`` node is running, you will see the message: + +.. code-block:: console + + [INFO] [turtlesim]: Rotation goal canceled + +Not only can the client-side (your input in the teleop) stop a goal, but the server-side (the ``/turtlesim`` node) can as well. +When the server-side chooses to stop processing a goal, it is said to "abort" the goal. + +Try hitting the ``D`` key, then the ``G`` key before the first rotation can complete. +In the terminal where the ``/turtlesim`` node is running, you will see the message: + +.. code-block:: console + + [WARN] [turtlesim]: Rotation goal received before a previous goal finished. Aborting previous goal + +This action server chose to abort the first goal because it got a new one. +It could have chosen something else, like reject the new goal or execute the second goal after the first one finished. +Don't assume every action server will choose to abort the current goal when it gets a new one. + +3 ros2 node info +^^^^^^^^^^^^^^^^ + +To see the list of actions a node provides, ``/turtlesim`` in this case, open a new terminal and run the command: + +.. code-block:: console + + $ ros2 node info /turtlesim + /turtlesim + Subscribers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /turtle1/cmd_vel: geometry_msgs/msg/Twist + Publishers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /rosout: rcl_interfaces/msg/Log + /turtle1/color_sensor: turtlesim_msgs/msg/Color + /turtle1/pose: turtlesim_msgs/msg/Pose + Service Servers: + /clear: std_srvs/srv/Empty + /kill: turtlesim_msgs/srv/Kill + /reset: std_srvs/srv/Empty + /spawn: turtlesim_msgs/srv/Spawn + /turtle1/set_pen: turtlesim_msgs/srv/SetPen + /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute + /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative + /turtlesim/describe_parameters: rcl_interfaces/srv/DescribeParameters + /turtlesim/get_parameter_types: rcl_interfaces/srv/GetParameterTypes + /turtlesim/get_parameters: rcl_interfaces/srv/GetParameters + /turtlesim/list_parameters: rcl_interfaces/srv/ListParameters + /turtlesim/set_parameters: rcl_interfaces/srv/SetParameters + /turtlesim/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically + Service Clients: + + Action Servers: + /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute + Action Clients: + +The command returns a list of ``/turtlesim``'s subscribers, publishers, services, action servers and action clients. + +Notice that the ``/turtle1/rotate_absolute`` action for ``/turtlesim`` is under ``Action Servers``. +This means ``/turtlesim`` responds to and provides feedback for the ``/turtle1/rotate_absolute`` action. + +The ``/teleop_turtle`` node has the name ``/turtle1/rotate_absolute`` under ``Action Clients`` meaning that it sends goals for that action name. +To see that, run: + +.. code-block:: console + + $ ros2 node info /teleop_turtle + /teleop_turtle + Subscribers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + Publishers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /rosout: rcl_interfaces/msg/Log + /turtle1/cmd_vel: geometry_msgs/msg/Twist + Service Servers: + /teleop_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters + /teleop_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes + /teleop_turtle/get_parameters: rcl_interfaces/srv/GetParameters + /teleop_turtle/list_parameters: rcl_interfaces/srv/ListParameters + /teleop_turtle/set_parameters: rcl_interfaces/srv/SetParameters + /teleop_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically + Service Clients: + + Action Servers: + + Action Clients: + /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute + +4 ros2 action list +^^^^^^^^^^^^^^^^^^ + +To identify all the actions in the ROS graph, run the command: + +.. code-block:: console + + $ ros2 action list + /turtle1/rotate_absolute + +This is the only action in the ROS graph right now. +It controls the turtle's rotation, as you saw earlier. +You also already know that there is one action client (part of ``/teleop_turtle``) and one action server (part of ``/turtlesim``) for this action from using the ``ros2 node info `` command. + +4.1 ros2 action list -t +~~~~~~~~~~~~~~~~~~~~~~~ + +Actions have types, similar to topics and services. +To find ``/turtle1/rotate_absolute``'s type, run the command: + +.. code-block:: console + + $ ros2 action list -t + /turtle1/rotate_absolute [turtlesim_msgs/action/RotateAbsolute] + +In brackets to the right of each action name (in this case only ``/turtle1/rotate_absolute``) is the action type, ``turtlesim_msgs/action/RotateAbsolute``. +You will need this when you want to execute an action from the command line or from code. + +5 ros2 action type +^^^^^^^^^^^^^^^^^^ + +If you want to check the action type for the action, run the command: + +.. code-block:: console + + $ ros2 action type /turtle1/rotate_absolute + turtlesim_msgs/action/RotateAbsolute + +6 ros2 action info +^^^^^^^^^^^^^^^^^^ + +You can further introspect the ``/turtle1/rotate_absolute`` action with the command: + +.. code-block:: console + + $ ros2 action info /turtle1/rotate_absolute + Action: /turtle1/rotate_absolute + Action clients: 1 + /teleop_turtle + Action servers: 1 + /turtlesim + +This tells us what we learned earlier from running ``ros2 node info`` on each node: +The ``/teleop_turtle`` node has an action client and the ``/turtlesim`` node has an action server for the ``/turtle1/rotate_absolute`` action. + +7 ros2 interface show +^^^^^^^^^^^^^^^^^^^^^ + +One more piece of information you will need before sending or executing an action goal yourself is the structure of the action type. + +Recall that you identified ``/turtle1/rotate_absolute``'s type when running the command ``ros2 action list -t``. +Enter the following command with the action type in your terminal: + +.. code-block:: console + + $ ros2 interface show turtlesim_msgs/action/RotateAbsolute + +Which will return: + +.. code-block:: text + + # The desired heading in radians + float32 theta + --- + # The angular displacement in radians to the starting position + float32 delta + --- + # The remaining rotation in radians + float32 remaining + +The section of this message above the first ``---`` is the structure (data type and name) of the goal request. +The next section is the structure of the result. +The last section is the structure of the feedback. + +8 ros2 action send_goal +^^^^^^^^^^^^^^^^^^^^^^^ + +Now let's send an action goal from the command line with the following syntax: + +.. code-block:: console + + $ ros2 action send_goal + +```` need to be in YAML format. + +Keep an eye on the turtlesim window, and enter the following command into your terminal: + +.. code-block:: console + + $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: 1.57}" + Waiting for an action server to become available... + Sending goal: + theta: 1.57 + + Goal accepted with ID: f8db8f44410849eaa93d3feb747dd444 + + Result: + delta: -1.568000316619873 + + Goal finished with status: SUCCEEDED + + +You should see the turtle rotating. + + +All goals have a unique ID, shown in the return message. +You can also see the result, a field with the name ``delta``, which is the displacement to the starting position. + +To see the feedback of this goal, add ``--feedback`` to the ``ros2 action send_goal`` command: + +.. code-block:: console + + $ ros2 action send_goal /turtle1/rotate_absolute turtlesim_msgs/action/RotateAbsolute "{theta: -1.57}" --feedback + Sending goal: + theta: -1.57 + + Goal accepted with ID: e6092c831f994afda92f0086f220da27 + + Feedback: + remaining: -3.1268222332000732 + + Feedback: + remaining: -3.1108222007751465 + + … + + Result: + delta: 3.1200008392333984 + + Goal finished with status: SUCCEEDED + +You will continue to receive feedback, the remaining radians, until the goal is complete. + +.. _understanding-actions-ros2-action-echo: + +9 ros2 action echo +^^^^^^^^^^^^^^^^^^ + +To see the data communication between an action client and an action server you can ``echo`` the action data using: + +.. code-block:: console + + $ ros2 action echo + +``ros2 action echo`` depends on action introspection of an action client and server, that is disabled by default. +To enable it, users must call ``configure_introspection`` after creating an action client or server. + +Start up the ``fibonacci_action_server`` and ``fibonacci_action_client``, enabling ``action_server_configure_introspection`` parameter for demonstration. + +.. code-block:: console + + $ ros2 run action_tutorials_cpp fibonacci_action_server --ros-args -p action_server_configure_introspection:=contents + +.. code-block:: console + + $ ros2 run action_tutorials_py fibonacci_action_client --ros-args -p action_client_configure_introspection:=contents + +Now we are able to see the action communication between ``fibonacci_action_server`` and ``fibonacci_action_client`` via ``ros2 action echo``. + +.. code-block:: console + + $ ros2 action echo /fibonacci example_interfaces/action/Fibonacci --flow-style + interface: GOAL_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 400435819 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: GOAL_SERVICE + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1742070798 + nanosec: 400706446 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, goal: {order: 10}}] + response: [] + --- + interface: RESULT_SERVICE + info: + event_type: REQUEST_SENT + stamp: + sec: 1742070798 + nanosec: 401486678 + client_gid: [1, 15, 165, 231, 194, 197, 167, 157, 0, 0, 0, 0, 0, 0, 24, 4] + sequence_number: 1 + request: [{goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}}] + response: [] + --- + interface: FEEDBACK_TOPIC + goal_id: + uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110] + feedback: + sequence: [0, 1, 1] + --- + interface: STATUS_TOPIC + status_list: [{goal_info: {goal_id: {uuid: [230, 96, 12, 6, 100, 69, 69, 70, 220, 205, 135, 251, 210, 2, 231, 110]}, stamp: {sec: 1742070798, nanosec: 401146752}}, status: 2}] + --- + ... + +.. note:: + + This feature is available on ``Kilted Kaiju`` or later. + +Summary +------- + +Actions are like services that allow you to execute long running tasks, provide regular feedback, and are cancelable. + +A robot system would likely use actions for navigation. +An action goal could tell a robot to travel to a position. +While the robot navigates to the position, it can send updates along the way (i.e. feedback), and then a final result message once it's reached its destination. + +Turtlesim has an action server that action clients can send goals to for rotating turtles. +In this tutorial, you introspected that action, ``/turtle1/rotate_absolute``, to get a better idea of what actions are and how they work. + +Next steps +---------- + +Now you've covered all of the core ROS 2 concepts. +The last few tutorials in this set will introduce you to some tools and techniques that will make using ROS 2 easier, starting with :doc:`../../../../nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console`. + +Related content +--------------- + You can read more about the design decisions behind actions in ROS 2 `here `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/images/Action-SingleActionClient.gif b/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/images/Action-SingleActionClient.gif similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Understanding-ROS2-Actions/images/Action-SingleActionClient.gif rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/images/Action-SingleActionClient.gif diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst similarity index 95% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst index 15e1e613fc7..728e322d69b 100644 --- a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst @@ -1,399 +1,399 @@ -.. redirect-from:: - - Tutorials/Actions/Writing-a-Cpp-Action-Server-Client - Tutorials/Intermediate/Writing-an-Action-Server-Client/Cpp - -.. _ActionsCpp: - -Writing an action server and client (C++) -========================================= - -**Goal:** Implement an action server and client in C++. - -**Tutorial level:** Intermediate - -**Time:** 15 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Actions are a form of asynchronous communication in ROS. -*Action clients* send goal requests to *action servers*. -*Action servers* send goal feedback and results to *action clients*. - -Prerequisites -------------- - -You will need the ``custom_action_interfaces`` package and the ``Fibonacci.action`` -interface defined in the previous tutorial, :doc:`../Creating-an-Action`. - -Tasks ------ - -1 Creating the custom_action_cpp package -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -As we saw in the :doc:`../../../client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` tutorial, we need to create a new package to hold our C++ and supporting code. - -1.1 Creating the custom_action_cpp package -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Go into the action workspace you created in the :doc:`previous tutorial <../Creating-an-Action>` (remember to source the workspace), and create a new package for the C++ action server: - - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/ros2_ws/src - $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/ros2_ws/src - $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp - - .. group-tab:: Windows - - .. code-block:: console - - $ cd \ros2_ws\src - $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp - -1.2 Adding in visibility control -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In order to make the package compile and work on Windows, we need to add in some "visibility control". -For more details, see :ref:`Windows Symbol Visibility in the Windows Tips and Tricks document `. - -Open up ``custom_action_cpp/include/custom_action_cpp/visibility_control.h``, and put the following code in: - -.. code-block:: c++ - - #ifndef CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ - #define CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ - - #ifdef __cplusplus - extern "C" - { - #endif - - // This logic was borrowed (then namespaced) from the examples on the gcc wiki: - // https://gcc.gnu.org/wiki/Visibility - - #if defined _WIN32 || defined __CYGWIN__ - #ifdef __GNUC__ - #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((dllexport)) - #define CUSTOM_ACTION_CPP_IMPORT __attribute__ ((dllimport)) - #else - #define CUSTOM_ACTION_CPP_EXPORT __declspec(dllexport) - #define CUSTOM_ACTION_CPP_IMPORT __declspec(dllimport) - #endif - #ifdef CUSTOM_ACTION_CPP_BUILDING_DLL - #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_EXPORT - #else - #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_IMPORT - #endif - #define CUSTOM_ACTION_CPP_PUBLIC_TYPE CUSTOM_ACTION_CPP_PUBLIC - #define CUSTOM_ACTION_CPP_LOCAL - #else - #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((visibility("default"))) - #define CUSTOM_ACTION_CPP_IMPORT - #if __GNUC__ >= 4 - #define CUSTOM_ACTION_CPP_PUBLIC __attribute__ ((visibility("default"))) - #define CUSTOM_ACTION_CPP_LOCAL __attribute__ ((visibility("hidden"))) - #else - #define CUSTOM_ACTION_CPP_PUBLIC - #define CUSTOM_ACTION_CPP_LOCAL - #endif - #define CUSTOM_ACTION_CPP_PUBLIC_TYPE - #endif - - #ifdef __cplusplus - } - #endif - - #endif // CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ - -2 Writing an action server -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Let's focus on writing an action server that computes the Fibonacci sequence using the action we created in the :doc:`../Creating-an-Action` tutorial. - -2.1 Writing the action server code -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Open up ``custom_action_cpp/src/fibonacci_action_server.cpp``, and put the following code in: - -.. literalinclude:: scripts/server.cpp - :language: c++ - -The first few lines include all of the headers we need to compile. - -Next we create a class that is a derived class of ``rclcpp::Node``: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 14 - -The constructor for the ``FibonacciActionServer`` class initializes the node name as ``fibonacci_action_server``: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 21-22 - -The constructor also instantiates a new action server: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 52-57 - -An action server requires 6 things: - -1. The templated action type name: ``Fibonacci``. -2. A ROS 2 node to add the action to: ``this``. -3. The action name: ``'fibonacci'``. -4. A callback function for handling goals: ``handle_goal`` -5. A callback function for handling cancellation: ``handle_cancel``. -6. A callback function for handling goal accept: ``handle_accept``. - -The implementation of the various callbacks is done with `lambda expressions `_ within the constructor. -Note that all of the callbacks need to return quickly, otherwise we risk starving the executor. - -We start with the callback for handling new goals: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 26-33 - -This implementation just accepts all goals. - -Next up is the callback for dealing with cancellation: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 35-41 - -This implementation just tells the client that it accepted the cancellation. - -The last of the callbacks accepts a new goal and starts processing it: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 43-50 - -Since the execution is a long-running operation, we spawn off a thread to do the actual work and return from ``handle_accepted`` quickly. - -All further processing and updates are done in the ``execute`` method in the new thread: - -.. literalinclude:: scripts/server.cpp - :language: c++ - :lines: 63-96 - -This work thread processes one sequence number of the Fibonacci sequence every second, publishing a feedback update for each step. -When it has finished processing, it marks the ``goal_handle`` as succeeded, and quits. - -We now have a fully functioning action server. -Let's get it built and running. - -2.2 Compiling the action server -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the previous section we put the action server code into place. -To get it to compile and run, we need to do a couple of additional things. - -First we need to setup the CMakeLists.txt so that the action server is compiled. -Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: - -.. code-block:: cmake - - add_library(action_server SHARED - src/fibonacci_action_server.cpp) - target_include_directories(action_server PRIVATE - $ - $) - target_compile_definitions(action_server - PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") - target_link_libraries(action_server PUBLIC - custom_action_interfaces::custom_action_interfaces - rclcpp::rclcpp - rclcpp_action::rclcpp_action - rclcpp_components::component) - rclcpp_components_register_node(action_server PLUGIN "custom_action_cpp::FibonacciActionServer" EXECUTABLE fibonacci_action_server) - install(TARGETS - action_server - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin) - -And now we can compile the package. -Go to the top-level of the ``ros2_ws``, and run: - -.. code-block:: console - - $ colcon build - -This should compile the entire workspace, including the ``fibonacci_action_server`` in the ``custom_action_cpp`` package. - -2.3 Running the action server -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now that we have the action server built, we can run it. -Source the workspace we just built (``ros2_ws``), and try to run the action server: - -.. code-block:: console - - $ ros2 run custom_action_cpp fibonacci_action_server - -3 Writing an action client -^^^^^^^^^^^^^^^^^^^^^^^^^^ - -3.1 Writing the action client code -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Open up ``custom_action_cpp/src/fibonacci_action_client.cpp``, and put the following code in: - -.. literalinclude:: scripts/client.cpp - :language: c++ - -The first few lines include all of the headers we need to compile. - -Next we create a class that is a derived class of ``rclcpp::Node``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 15 - -The constructor for the ``FibonacciActionClient`` class initializes the node name as ``fibonacci_action_client``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 20-22 - -The constructor also instantiates a new action client: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 24-26 - -An action client requires 3 things: - -1. The templated action type name: ``Fibonacci``. -2. A ROS 2 node to add the action client to: ``this``. -3. The action name: ``'fibonacci'``. - -We also instantiate a ROS timer that will kick off the one and only call to ``send_goal``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 28-31 - -When the timer expires, it will call ``send_goal``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 34-96 - -This function does the following: - -1. Cancels the timer (so it is only called once). -2. Waits for the action server to come up. -3. Instantiates a new ``Fibonacci::Goal``. -4. Sets the response, feedback, and result callbacks. -5. Sends the goal to the server. - -When the server receives and accepts the goal, it will send a response to the client. -That response is handled by ``goal_response_callback``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 51-58 - -Assuming the goal was accepted by the server, it will start processing. -Any feedback to the client will be handled by the ``feedback_callback``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 60-70 - -When the server is finished processing, it will return a result to the client. -The result is handled by the ``result_callback``: - -.. literalinclude:: scripts/client.cpp - :language: c++ - :lines: 72-94 - -We now have a fully functioning action client. -Let's get it built and running. - -3.2 Compiling the action client -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -In the previous section we put the action client code into place. -To get it to compile and run, we need to do a couple of additional things. - -First we need to setup the CMakeLists.txt so that the action client is compiled. -Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: - -.. code-block:: cmake - - add_library(action_client SHARED - src/fibonacci_action_client.cpp) - target_include_directories(action_client PRIVATE - $ - $) - target_compile_definitions(action_client - PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") - target_link_libraries(action_client PUBLIC - custom_action_interfaces::custom_action_interfaces - rclcpp::rclcpp - rclcpp_action::rclcpp_action - rclcpp_components::component) - rclcpp_components_register_node(action_client PLUGIN "custom_action_cpp::FibonacciActionClient" EXECUTABLE fibonacci_action_client) - install(TARGETS - action_client - ARCHIVE DESTINATION lib - LIBRARY DESTINATION lib - RUNTIME DESTINATION bin) - -And now we can compile the package. -Go to the top-level of the ``ros2_ws``, and run: - -.. code-block:: console - - $ colcon build - -This should compile the entire workspace, including the ``fibonacci_action_client`` in the ``custom_action_cpp`` package. - -3.3 Running the action client -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Now that we have the action client built, we can run it. -First make sure that an action server is running in a separate terminal. -Now source the workspace we just built (``ros2_ws``), and try to run the action client: - -.. code-block:: console - - $ ros2 run custom_action_cpp fibonacci_action_client - -You should see logged messages for the goal being accepted, feedback being printed, and the final result. - -Summary -------- - -In this tutorial, you put together a C++ action server and action client line by line, and configured them to exchange goals, feedback, and results. - -Related content ---------------- - -* There are several ways you could write an action server and client in C++; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. - +.. redirect-from:: + + Tutorials/Actions/Writing-a-Cpp-Action-Server-Client + Tutorials/Intermediate/Writing-an-Action-Server-Client/Cpp + +.. _ActionsCpp: + +Writing an action server and client (C++) +========================================= + +**Goal:** Implement an action server and client in C++. + +**Tutorial level:** Intermediate + +**Time:** 15 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Actions are a form of asynchronous communication in ROS. +*Action clients* send goal requests to *action servers*. +*Action servers* send goal feedback and results to *action clients*. + +Prerequisites +------------- + +You will need the ``custom_action_interfaces`` package and the ``Fibonacci.action`` +interface defined in the previous tutorial, :doc:`../Creating-an-Action`. + +Tasks +----- + +1 Creating the custom_action_cpp package +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +As we saw in the :doc:`../../../../client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package` tutorial, we need to create a new package to hold our C++ and supporting code. + +1.1 Creating the custom_action_cpp package +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Go into the action workspace you created in the :doc:`previous tutorial <../Creating-an-Action>` (remember to source the workspace), and create a new package for the C++ action server: + + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/ros2_ws/src + $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/ros2_ws/src + $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp + + .. group-tab:: Windows + + .. code-block:: console + + $ cd \ros2_ws\src + $ ros2 pkg create --dependencies custom_action_interfaces rclcpp rclcpp_action rclcpp_components --license Apache-2.0 -- custom_action_cpp + +1.2 Adding in visibility control +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In order to make the package compile and work on Windows, we need to add in some "visibility control". +For more details, see :ref:`Windows Symbol Visibility in the Windows Tips and Tricks document `. + +Open up ``custom_action_cpp/include/custom_action_cpp/visibility_control.h``, and put the following code in: + +.. code-block:: c++ + + #ifndef CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ + #define CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ + + #ifdef __cplusplus + extern "C" + { + #endif + + // This logic was borrowed (then namespaced) from the examples on the gcc wiki: + // https://gcc.gnu.org/wiki/Visibility + + #if defined _WIN32 || defined __CYGWIN__ + #ifdef __GNUC__ + #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((dllexport)) + #define CUSTOM_ACTION_CPP_IMPORT __attribute__ ((dllimport)) + #else + #define CUSTOM_ACTION_CPP_EXPORT __declspec(dllexport) + #define CUSTOM_ACTION_CPP_IMPORT __declspec(dllimport) + #endif + #ifdef CUSTOM_ACTION_CPP_BUILDING_DLL + #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_EXPORT + #else + #define CUSTOM_ACTION_CPP_PUBLIC CUSTOM_ACTION_CPP_IMPORT + #endif + #define CUSTOM_ACTION_CPP_PUBLIC_TYPE CUSTOM_ACTION_CPP_PUBLIC + #define CUSTOM_ACTION_CPP_LOCAL + #else + #define CUSTOM_ACTION_CPP_EXPORT __attribute__ ((visibility("default"))) + #define CUSTOM_ACTION_CPP_IMPORT + #if __GNUC__ >= 4 + #define CUSTOM_ACTION_CPP_PUBLIC __attribute__ ((visibility("default"))) + #define CUSTOM_ACTION_CPP_LOCAL __attribute__ ((visibility("hidden"))) + #else + #define CUSTOM_ACTION_CPP_PUBLIC + #define CUSTOM_ACTION_CPP_LOCAL + #endif + #define CUSTOM_ACTION_CPP_PUBLIC_TYPE + #endif + + #ifdef __cplusplus + } + #endif + + #endif // CUSTOM_ACTION_CPP__VISIBILITY_CONTROL_H_ + +2 Writing an action server +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Let's focus on writing an action server that computes the Fibonacci sequence using the action we created in the :doc:`../Creating-an-Action` tutorial. + +2.1 Writing the action server code +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Open up ``custom_action_cpp/src/fibonacci_action_server.cpp``, and put the following code in: + +.. literalinclude:: scripts/server.cpp + :language: c++ + +The first few lines include all of the headers we need to compile. + +Next we create a class that is a derived class of ``rclcpp::Node``: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 14 + +The constructor for the ``FibonacciActionServer`` class initializes the node name as ``fibonacci_action_server``: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 21-22 + +The constructor also instantiates a new action server: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 52-57 + +An action server requires 6 things: + +1. The templated action type name: ``Fibonacci``. +2. A ROS 2 node to add the action to: ``this``. +3. The action name: ``'fibonacci'``. +4. A callback function for handling goals: ``handle_goal`` +5. A callback function for handling cancellation: ``handle_cancel``. +6. A callback function for handling goal accept: ``handle_accept``. + +The implementation of the various callbacks is done with `lambda expressions `_ within the constructor. +Note that all of the callbacks need to return quickly, otherwise we risk starving the executor. + +We start with the callback for handling new goals: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 26-33 + +This implementation just accepts all goals. + +Next up is the callback for dealing with cancellation: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 35-41 + +This implementation just tells the client that it accepted the cancellation. + +The last of the callbacks accepts a new goal and starts processing it: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 43-50 + +Since the execution is a long-running operation, we spawn off a thread to do the actual work and return from ``handle_accepted`` quickly. + +All further processing and updates are done in the ``execute`` method in the new thread: + +.. literalinclude:: scripts/server.cpp + :language: c++ + :lines: 63-96 + +This work thread processes one sequence number of the Fibonacci sequence every second, publishing a feedback update for each step. +When it has finished processing, it marks the ``goal_handle`` as succeeded, and quits. + +We now have a fully functioning action server. +Let's get it built and running. + +2.2 Compiling the action server +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the previous section we put the action server code into place. +To get it to compile and run, we need to do a couple of additional things. + +First we need to setup the CMakeLists.txt so that the action server is compiled. +Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: + +.. code-block:: cmake + + add_library(action_server SHARED + src/fibonacci_action_server.cpp) + target_include_directories(action_server PRIVATE + $ + $) + target_compile_definitions(action_server + PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") + target_link_libraries(action_server PUBLIC + custom_action_interfaces::custom_action_interfaces + rclcpp::rclcpp + rclcpp_action::rclcpp_action + rclcpp_components::component) + rclcpp_components_register_node(action_server PLUGIN "custom_action_cpp::FibonacciActionServer" EXECUTABLE fibonacci_action_server) + install(TARGETS + action_server + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin) + +And now we can compile the package. +Go to the top-level of the ``ros2_ws``, and run: + +.. code-block:: console + + $ colcon build + +This should compile the entire workspace, including the ``fibonacci_action_server`` in the ``custom_action_cpp`` package. + +2.3 Running the action server +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now that we have the action server built, we can run it. +Source the workspace we just built (``ros2_ws``), and try to run the action server: + +.. code-block:: console + + $ ros2 run custom_action_cpp fibonacci_action_server + +3 Writing an action client +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +3.1 Writing the action client code +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Open up ``custom_action_cpp/src/fibonacci_action_client.cpp``, and put the following code in: + +.. literalinclude:: scripts/client.cpp + :language: c++ + +The first few lines include all of the headers we need to compile. + +Next we create a class that is a derived class of ``rclcpp::Node``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 15 + +The constructor for the ``FibonacciActionClient`` class initializes the node name as ``fibonacci_action_client``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 20-22 + +The constructor also instantiates a new action client: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 24-26 + +An action client requires 3 things: + +1. The templated action type name: ``Fibonacci``. +2. A ROS 2 node to add the action client to: ``this``. +3. The action name: ``'fibonacci'``. + +We also instantiate a ROS timer that will kick off the one and only call to ``send_goal``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 28-31 + +When the timer expires, it will call ``send_goal``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 34-96 + +This function does the following: + +1. Cancels the timer (so it is only called once). +2. Waits for the action server to come up. +3. Instantiates a new ``Fibonacci::Goal``. +4. Sets the response, feedback, and result callbacks. +5. Sends the goal to the server. + +When the server receives and accepts the goal, it will send a response to the client. +That response is handled by ``goal_response_callback``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 51-58 + +Assuming the goal was accepted by the server, it will start processing. +Any feedback to the client will be handled by the ``feedback_callback``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 60-70 + +When the server is finished processing, it will return a result to the client. +The result is handled by the ``result_callback``: + +.. literalinclude:: scripts/client.cpp + :language: c++ + :lines: 72-94 + +We now have a fully functioning action client. +Let's get it built and running. + +3.2 Compiling the action client +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the previous section we put the action client code into place. +To get it to compile and run, we need to do a couple of additional things. + +First we need to setup the CMakeLists.txt so that the action client is compiled. +Open up ``custom_action_cpp/CMakeLists.txt``, and add the following right after the ``find_package`` calls: + +.. code-block:: cmake + + add_library(action_client SHARED + src/fibonacci_action_client.cpp) + target_include_directories(action_client PRIVATE + $ + $) + target_compile_definitions(action_client + PRIVATE "CUSTOM_ACTION_CPP_BUILDING_DLL") + target_link_libraries(action_client PUBLIC + custom_action_interfaces::custom_action_interfaces + rclcpp::rclcpp + rclcpp_action::rclcpp_action + rclcpp_components::component) + rclcpp_components_register_node(action_client PLUGIN "custom_action_cpp::FibonacciActionClient" EXECUTABLE fibonacci_action_client) + install(TARGETS + action_client + ARCHIVE DESTINATION lib + LIBRARY DESTINATION lib + RUNTIME DESTINATION bin) + +And now we can compile the package. +Go to the top-level of the ``ros2_ws``, and run: + +.. code-block:: console + + $ colcon build + +This should compile the entire workspace, including the ``fibonacci_action_client`` in the ``custom_action_cpp`` package. + +3.3 Running the action client +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now that we have the action client built, we can run it. +First make sure that an action server is running in a separate terminal. +Now source the workspace we just built (``ros2_ws``), and try to run the action client: + +.. code-block:: console + + $ ros2 run custom_action_cpp fibonacci_action_client + +You should see logged messages for the goal being accepted, feedback being printed, and the final result. + +Summary +------- + +In this tutorial, you put together a C++ action server and action client line by line, and configured them to exchange goals, feedback, and results. + +Related content +--------------- + +* There are several ways you could write an action server and client in C++; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. + * For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client.cpp b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client.cpp similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client.cpp rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client.cpp diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_0.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_0.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_0.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_0.py diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_1.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_1.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_1.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_1.py diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_2.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_2.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_2.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/client_2.py diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server.cpp b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server.cpp similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server.cpp rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server.cpp diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_0.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_0.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_0.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_0.py diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_1.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_1.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_1.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_1.py diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_2.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_2.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_2.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_2.py diff --git a/source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_3.py b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_3.py similarity index 100% rename from source/ROS-Framework/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_3.py rename to source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/scripts/server_3.py diff --git a/source/ROS-Framework/services/Working-with-services.rst b/source/ROS-Framework/interfaces/services/Working-with-services.rst similarity index 100% rename from source/ROS-Framework/services/Working-with-services.rst rename to source/ROS-Framework/interfaces/services/Working-with-services.rst diff --git a/source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst b/source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst similarity index 92% rename from source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst rename to source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst index b88e0b6affc..e6c6c239d6f 100644 --- a/source/ROS-Framework/services/Working-with-services/Sync-Vs-Async.rst +++ b/source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst @@ -1,151 +1,151 @@ -.. redirect-from:: - - Guides/Sync-Vs-Async - Tutorials/Sync-Vs-Async - How-To-Guides/Sync-Vs-Async - -.. _SyncAsync: - -Synchronous vs. asynchronous service clients -============================================ - -**Level:** Intermediate - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - - -Introduction ------------- - -This guide is intended to warn users of the risks associated with the Python synchronous service client ``call()`` API. -It is very easy to mistakenly cause deadlock when calling services synchronously, so we do not recommend using ``call()``. - -We provide an example on how to use ``call()`` correctly for experienced users who wish to use synchronous calls and are aware of the pitfalls. -We also highlight possible scenarios for deadlock that accompany it. - -Because we recommend avoiding sync calls, this guide will also address the features and usage of the recommended alternative, async calls (``call_async()``). - -The C++ service call API is only available in async, so the comparisons and examples in this guide pertain to Python services and clients. -The definition of async given here generally applies to C++, with some exceptions. - -1 Synchronous calls -------------------- - -A synchronous client will block the calling thread when sending a request to a service until a response has been received; nothing else can happen on that thread during the call. -The call can take arbitrary amounts of time to complete. -Once complete, the response returns directly to the client. - -The following is an example of how to correctly execute a synchronous service call from a client node, similar to the async node in the :doc:`Simple Service and Client <../../client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial. - -.. code-block:: python - - from threading import Thread - - from example_interfaces.srv import AddTwoInts - import rclpy - from rclpy.executors import ExternalShutdownException - from rclpy.node import Node - - class MinimalClientSync(Node): - - def __init__(self): - super().__init__('minimal_client_sync') - self.cli = self.create_client(AddTwoInts, 'add_two_ints') - while not self.cli.wait_for_service(timeout_sec=1.0): - self.get_logger().info('service not available, waiting again...') - self.req = AddTwoInts.Request() - - def send_request(self): - self.req.a = 41 - self.req.b = 1 - return self.cli.call(self.req) - # This only works because rclpy.spin() is called in a separate thread below. - # Another configuration, like spinning later in main() or calling this method from a timer callback, would result in a deadlock. - - def main(): - try: - with rclpy.init(): - minimal_client = MinimalClientSync() - - spin_thread = Thread(target=rclpy.spin, args=(minimal_client,)) - spin_thread.start() - - response = minimal_client.send_request() - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - except (KeyboardInterrupt, ExternalShutdownException): - pass - - - if __name__ == '__main__': - main() - -Note inside ``main()`` that the client calls ``rclpy.spin`` in a separate thread. -Both ``send_request`` and ``rclpy.spin`` are blocking, so they need to be on separate threads. - -1.1 Sync deadlock ------------------ - -There are several ways that the synchronous ``call()`` API can cause deadlock. - -As mentioned in the comments of the example above, failing to create a separate thread to spin ``rclpy`` is one cause of deadlock. -When a client is blocking a thread waiting for a response, but the response can only be returned on that same thread, the client will never stop waiting, and nothing else can happen. - -Another cause of deadlock is blocking ``rclpy.spin`` by calling a service synchronously in a subscription, timer callback or service callback. -For example, if the synchronous client's ``send_request`` is placed in a callback: - -.. code-block:: python - - def trigger_request(msg): - response = minimal_client.send_request() # This will cause deadlock - minimal_client.get_logger().info( - 'Result of add_two_ints: for %d + %d = %d' % - (minimal_client.req.a, minimal_client.req.b, response.sum)) - subscription = minimal_client.create_subscription(String, 'trigger', trigger_request, 10) - - rclpy.spin(minimal_client) - -Deadlock occurs because ``rclpy.spin`` will not preempt the callback with the ``send_request`` call. -In general, callbacks should only perform light and fast operations. - -.. warning:: - - When deadlock occurs, you will not receive any indication that the service is blocked. - There will be no warning or exception thrown, no indication in the stack trace, and the call will not fail. - -2 Asynchronous calls --------------------- - -Async calls in ``rclpy`` are entirely safe and the recommended method of calling services. -They can be made from anywhere without running the risk of blocking other ROS and non-ROS processes, unlike sync calls. - -An asynchronous client will immediately return ``future``, a value that indicates whether the call and response is finished (not the value of the response itself), after sending a request to a service. -The returned ``future`` may be queried for a response at any time. - -Since sending a request doesn't block anything, a loop can be used to both spin ``rclpy`` and check ``future`` in the same thread, for example: - -.. code-block:: python - - while rclpy.ok(): - rclpy.spin_once(node) - if future.done(): - #Get response - -The :doc:`Simple Service and Client <../../client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial for Python illustrates how to perform an async service call and retrieve the ``future`` using a loop. - -The ``future`` can also be retrieved using a timer or callback, like in `this example `_, a dedicated thread, or by another method. -It is up to you, as the caller, to decide how to store ``future``, check on its status, and retrieve your response. - -Summary -------- - -It is not recommended to implement a synchronous service client. -They are susceptible to deadlock, but will not provide any indication of issue when deadlock occurs. -If you must use synchronous calls, the example in section `1 Synchronous calls`_ is a safe method of doing so. -You should also be aware of the conditions that cause deadlock outlined in section `1.1 Sync deadlock`_. +.. redirect-from:: + + Guides/Sync-Vs-Async + Tutorials/Sync-Vs-Async + How-To-Guides/Sync-Vs-Async + +.. _SyncAsync: + +Synchronous vs. asynchronous service clients +============================================ + +**Level:** Intermediate + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + + +Introduction +------------ + +This guide is intended to warn users of the risks associated with the Python synchronous service client ``call()`` API. +It is very easy to mistakenly cause deadlock when calling services synchronously, so we do not recommend using ``call()``. + +We provide an example on how to use ``call()`` correctly for experienced users who wish to use synchronous calls and are aware of the pitfalls. +We also highlight possible scenarios for deadlock that accompany it. + +Because we recommend avoiding sync calls, this guide will also address the features and usage of the recommended alternative, async calls (``call_async()``). + +The C++ service call API is only available in async, so the comparisons and examples in this guide pertain to Python services and clients. +The definition of async given here generally applies to C++, with some exceptions. + +1 Synchronous calls +------------------- + +A synchronous client will block the calling thread when sending a request to a service until a response has been received; nothing else can happen on that thread during the call. +The call can take arbitrary amounts of time to complete. +Once complete, the response returns directly to the client. + +The following is an example of how to correctly execute a synchronous service call from a client node, similar to the async node in the :doc:`Simple Service and Client <../../../client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial. + +.. code-block:: python + + from threading import Thread + + from example_interfaces.srv import AddTwoInts + import rclpy + from rclpy.executors import ExternalShutdownException + from rclpy.node import Node + + class MinimalClientSync(Node): + + def __init__(self): + super().__init__('minimal_client_sync') + self.cli = self.create_client(AddTwoInts, 'add_two_ints') + while not self.cli.wait_for_service(timeout_sec=1.0): + self.get_logger().info('service not available, waiting again...') + self.req = AddTwoInts.Request() + + def send_request(self): + self.req.a = 41 + self.req.b = 1 + return self.cli.call(self.req) + # This only works because rclpy.spin() is called in a separate thread below. + # Another configuration, like spinning later in main() or calling this method from a timer callback, would result in a deadlock. + + def main(): + try: + with rclpy.init(): + minimal_client = MinimalClientSync() + + spin_thread = Thread(target=rclpy.spin, args=(minimal_client,)) + spin_thread.start() + + response = minimal_client.send_request() + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + except (KeyboardInterrupt, ExternalShutdownException): + pass + + + if __name__ == '__main__': + main() + +Note inside ``main()`` that the client calls ``rclpy.spin`` in a separate thread. +Both ``send_request`` and ``rclpy.spin`` are blocking, so they need to be on separate threads. + +1.1 Sync deadlock +----------------- + +There are several ways that the synchronous ``call()`` API can cause deadlock. + +As mentioned in the comments of the example above, failing to create a separate thread to spin ``rclpy`` is one cause of deadlock. +When a client is blocking a thread waiting for a response, but the response can only be returned on that same thread, the client will never stop waiting, and nothing else can happen. + +Another cause of deadlock is blocking ``rclpy.spin`` by calling a service synchronously in a subscription, timer callback or service callback. +For example, if the synchronous client's ``send_request`` is placed in a callback: + +.. code-block:: python + + def trigger_request(msg): + response = minimal_client.send_request() # This will cause deadlock + minimal_client.get_logger().info( + 'Result of add_two_ints: for %d + %d = %d' % + (minimal_client.req.a, minimal_client.req.b, response.sum)) + subscription = minimal_client.create_subscription(String, 'trigger', trigger_request, 10) + + rclpy.spin(minimal_client) + +Deadlock occurs because ``rclpy.spin`` will not preempt the callback with the ``send_request`` call. +In general, callbacks should only perform light and fast operations. + +.. warning:: + + When deadlock occurs, you will not receive any indication that the service is blocked. + There will be no warning or exception thrown, no indication in the stack trace, and the call will not fail. + +2 Asynchronous calls +-------------------- + +Async calls in ``rclpy`` are entirely safe and the recommended method of calling services. +They can be made from anywhere without running the risk of blocking other ROS and non-ROS processes, unlike sync calls. + +An asynchronous client will immediately return ``future``, a value that indicates whether the call and response is finished (not the value of the response itself), after sending a request to a service. +The returned ``future`` may be queried for a response at any time. + +Since sending a request doesn't block anything, a loop can be used to both spin ``rclpy`` and check ``future`` in the same thread, for example: + +.. code-block:: python + + while rclpy.ok(): + rclpy.spin_once(node) + if future.done(): + #Get response + +The :doc:`Simple Service and Client <../../../client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>` tutorial for Python illustrates how to perform an async service call and retrieve the ``future`` using a loop. + +The ``future`` can also be retrieved using a timer or callback, like in `this example `_, a dedicated thread, or by another method. +It is up to you, as the caller, to decide how to store ``future``, check on its status, and retrieve your response. + +Summary +------- + +It is not recommended to implement a synchronous service client. +They are susceptible to deadlock, but will not provide any indication of issue when deadlock occurs. +If you must use synchronous calls, the example in section `1 Synchronous calls`_ is a safe method of doing so. +You should also be aware of the conditions that cause deadlock outlined in section `1.1 Sync deadlock`_. We recommend using async service clients instead. \ No newline at end of file diff --git a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst similarity index 91% rename from source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst rename to source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst index c56cf0a95c0..98163f7d833 100644 --- a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst +++ b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst @@ -1,416 +1,416 @@ -.. redirect-from:: - - Tutorials/Services/Understanding-ROS2-Services - Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services - -.. _ROS2Services: - -Understanding services -====================== - -**Goal:** Learn about services in ROS 2 using command line tools. - -**Tutorial level:** Beginner - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -Services are another method of communication for nodes in the ROS graph. -Services are based on a call-and-response model versus the publisher-subscriber model of topics. -While topics allow nodes to subscribe to data streams and get continual updates, services only provide data when they are specifically called by a client. - -.. image:: images/Service-SingleServiceClient.gif - -.. image:: images/Service-MultipleServiceClient.gif - -Prerequisites -------------- - -Some concepts mentioned in this tutorial, like :doc:`Nodes <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`Topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, were covered in previous tutorials in the series. - -You will need the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ -Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -2 ros2 service list -^^^^^^^^^^^^^^^^^^^ - -Running the ``ros2 service list`` command in a new terminal will return a list of all the services currently active in the system: - -.. code-block:: console - - $ ros2 service list - /clear - /kill - /reset - /spawn - /teleop_turtle/describe_parameters - /teleop_turtle/get_parameter_types - /teleop_turtle/get_parameters - /teleop_turtle/list_parameters - /teleop_turtle/set_parameters - /teleop_turtle/set_parameters_atomically - /turtle1/set_pen - /turtle1/teleport_absolute - /turtle1/teleport_relative - /turtlesim/describe_parameters - /turtlesim/get_parameter_types - /turtlesim/get_parameters - /turtlesim/list_parameters - /turtlesim/set_parameters - /turtlesim/set_parameters_atomically - -You will see that both nodes have the same six services with ``parameters`` in their names. -Nearly every node in ROS 2 has these infrastructure services that parameters are built off of. -There will be more about parameters in the next tutorial. -In this tutorial, the parameter services will be omitted from the discussion. - -For now, let's focus on the turtlesim-specific services, ``/clear``, ``/kill``, ``/reset``, ``/spawn``, ``/turtle1/set_pen``, ``/turtle1/teleport_absolute``, and ``/turtle1/teleport_relative``. -You may recall interacting with some of these services using rqt in the :doc:`Use turtlesim, ros2, and rqt <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` tutorial. - - -3 ros2 service type -^^^^^^^^^^^^^^^^^^^ - -Services have types that describe how the request and response data of a service is structured. -Service types are defined similarly to topic types, except service types have two parts: one message for the request and another for the response. - -To find out the type of a service, use the command: - -.. code-block:: console - - $ ros2 service type - -Let's take a look at turtlesim's ``/clear`` service. -In a new terminal, enter the command: - -.. code-block:: console - - $ ros2 service type /clear - std_srvs/srv/Empty - -The ``Empty`` type means the service call sends no data when making a request and receives no data when receiving a response. - -3.1 ros2 service list -t -~~~~~~~~~~~~~~~~~~~~~~~~ - -To see the types of all the active services at the same time, you can append the ``--show-types`` option, abbreviated as ``-t``, to the ``list`` command: - -.. code-block:: console - - $ ros2 service list -t - /clear [std_srvs/srv/Empty] - /kill [turtlesim_msgs/srv/Kill] - /reset [std_srvs/srv/Empty] - /spawn [turtlesim_msgs/srv/Spawn] - ... - /turtle1/set_pen [turtlesim_msgs/srv/SetPen] - /turtle1/teleport_absolute [turtlesim_msgs/srv/TeleportAbsolute] - /turtle1/teleport_relative [turtlesim_msgs/srv/TeleportRelative] - ... - -4 ros2 service info -^^^^^^^^^^^^^^^^^^^ - -To see information of a particular service, use the command: - -.. code-block:: console - - $ ros2 service info - -This returns the service type and the count of service clients and servers. - -For example, you can find the count of clients and servers for the ``/clear`` service: - -.. code-block:: console - - $ ros2 service info /clear - Type: std_srvs/srv/Empty - Clients count: 0 - Services count: 1 - -4.1 ros2 service info --verbose -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -For more detailed information about a service, you can append the ``--verbose`` (or ``-v``) option to the ``info`` command: - -.. code-block:: console - - $ ros2 service info --verbose - -For example: you can get verbose information about the ``/clear`` service: - -.. code-block:: console - - $ ros2 service info --verbose /clear - -This will return additional information including the node name and namespace of the service server, as well as the underlying middleware (RMW) implementation details. -An important information for Developers that the ``Endpoint count`` will be 2 for DDS based RMW implementations (connextdds, cyclone, fastrtps) because DDS creates two endpoints (one for request and one for response) for each service server. - -.. code-block:: console - - Type: std_srvs/srv/Empty - Clients count: 0 - Services count: 1 - Node name: turtlesim - Node namespace: / - Service type: std_srvs/srv/Empty - Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 - Endpoint type: SERVER - Endpoint count: 2 - GIDs: - - Request Reader : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.13.04 - - Response Writer : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.14.03 - QoS profiles: - - Request Reader : - Reliability: RELIABLE - History (Depth): KEEP_LAST (10) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Response Writer : - Reliability: RELIABLE - History (Depth): KEEP_LAST (10) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -Where as for non-DDS based RMW implementations like ``rmw_zenoh_cpp``, the ``Endpoint count`` will be 1 because it uses a single endpoint for both request and response. - -.. code-block:: console - - Type: std_srvs/srv/Empty - Clients count: 0 - Services count: 1 - Node name: turtlesim - Node namespace: / - Service type: std_srvs/srv/Empty - Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 - Endpoint type: SERVER - Endpoint count: 1 - GID: 59.b0.ea.78.57.3c.52.b4.c6.e9.af.44.22.3d.7c.f5 - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (10) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -If you want to learn more about different RMW implementations, refer to the :doc:`About Different Middleware Vendors <../../../client-libraries/About-Different-Middleware-Vendors>` concept. - -5 ros2 service find -^^^^^^^^^^^^^^^^^^^ - -If you want to find all the services of a specific type, you can use the command: - -.. code-block:: console - - $ ros2 service find - -For example, you can find all the ``Empty`` typed services like this: - -.. code-block:: console - - $ ros2 service find std_srvs/srv/Empty - /clear - /reset - -6 ros2 interface show -^^^^^^^^^^^^^^^^^^^^^ - -You can call services from the command line, but first you need to know the structure of the input arguments. - -.. code-block:: console - - $ ros2 interface show - -Try this on the ``/clear`` service's type, ``Empty``: - -.. code-block:: console - - $ ros2 interface show std_srvs/srv/Empty - --- - -The ``---`` separates the request structure (above) from the response structure (below). -But, as you learned earlier, the ``Empty`` type doesn't send or receive any data. -So, naturally, its structure is blank. - -Let's introspect a service with a type that sends and receives data, like ``/spawn``. -From the results of ``ros2 service list -t``, we know ``/spawn``'s type is ``turtlesim_msgs/srv/Spawn``. - -To see the request and response arguments of the ``/spawn`` service, run the command: - -.. code-block:: console - - $ ros2 interface show turtlesim_msgs/srv/Spawn - float32 x - float32 y - float32 theta - string name # Optional. A unique name will be created and returned if this is empty - --- - string name - -The information above the ``---`` line tells us the arguments needed to call ``/spawn``. -``x``, ``y`` and ``theta`` determine the 2D pose of the spawned turtle, and ``name`` is clearly optional. - -The information below the line isn't something you need to know in this case, but it can help you understand the data type of the response you get from the call. - -7 ros2 service call -^^^^^^^^^^^^^^^^^^^ - -Now that you know what a service type is, how to find a service's type, and how to find the structure of that type's arguments, you can call a service using: - -.. code-block:: console - - $ ros2 service call - -The ```` part is optional. -For example, you know that ``Empty`` typed services don't have any arguments: - -.. code-block:: console - - $ ros2 service call /clear std_srvs/srv/Empty - -This command will clear the turtlesim window of any lines your turtle has drawn. - -.. image:: images/clear.png - -Now let's spawn a new turtle by calling ``/spawn`` and setting arguments. -Input ```` in a service call from the command-line need to be in YAML syntax. - -Enter the command: - -.. code-block:: console - - $ ros2 service call /spawn turtlesim_msgs/srv/Spawn "{x: 2, y: 2, theta: 0.2, name: ''}" - requester: making request: turtlesim_msgs.srv.Spawn_Request(x=2.0, y=2.0, theta=0.2, name='') - - response: - turtlesim_msgs.srv.Spawn_Response(name='turtle2') - -You will get this method-style view of what's happening, and then the service response. - -Your turtlesim window will update with the newly spawned turtle right away: - -.. image:: images/spawn.png - -8 ros2 service echo -^^^^^^^^^^^^^^^^^^^ - -To see the data communication between a service client and a service server you can ``echo`` the service using: - -.. code-block:: console - - $ ros2 service echo - -``ros2 service echo`` depends on service introspection of a service client and server, that is disabled by default. -To enable it, users must call ``configure_introspection`` after creating a service client or server. - -Start up the ``introspection_client`` and ``introspection_service`` service introspection demo. - -.. code-block:: console - - $ ros2 launch demo_nodes_cpp introspect_services_launch.py - -Open another terminal and run the following to enable service introspection for ``introspection_client`` and ``introspection_service``. - -.. code-block:: console - - $ ros2 param set /introspection_service service_configure_introspection contents - $ ros2 param set /introspection_client client_configure_introspection contents - -Now we are able to see the service communication between ``introspection_client`` and ``introspection_service`` via ``ros2 service echo``. - -.. code-block:: console - - $ ros2 service echo --flow-style /add_two_ints - info: - event_type: REQUEST_SENT - stamp: - sec: 1709408301 - nanosec: 423227292 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 618 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: REQUEST_RECEIVED - stamp: - sec: 1709408301 - nanosec: 423601471 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 618 - request: [{a: 2, b: 3}] - response: [] - --- - info: - event_type: RESPONSE_SENT - stamp: - sec: 1709408301 - nanosec: 423900744 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] - sequence_number: 618 - request: [] - response: [{sum: 5}] - --- - info: - event_type: RESPONSE_RECEIVED - stamp: - sec: 1709408301 - nanosec: 424153133 - client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] - sequence_number: 618 - request: [] - response: [{sum: 5}] - --- - -Summary -------- - -Nodes can communicate using services in ROS 2. -Unlike a topic - a one way communication pattern where a node publishes information that can be consumed by one or more subscribers - a service is a request/response pattern where a client makes a request to a node providing the service and the service processes the request and generates a response. - -You generally don't want to use a service for continuous calls; topics or even actions would be better suited. - -In this tutorial you used command line tools to identify, introspect, and call services. - -Next steps ----------- - -In the next tutorial, :doc:`../../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters`, you will learn about configuring node settings. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Services/Understanding-ROS2-Services + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Services/Understanding-ROS2-Services + +.. _ROS2Services: + +Understanding services +====================== + +**Goal:** Learn about services in ROS 2 using command line tools. + +**Tutorial level:** Beginner + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +Services are another method of communication for nodes in the ROS graph. +Services are based on a call-and-response model versus the publisher-subscriber model of topics. +While topics allow nodes to subscribe to data streams and get continual updates, services only provide data when they are specifically called by a client. + +.. image:: images/Service-SingleServiceClient.gif + +.. image:: images/Service-MultipleServiceClient.gif + +Prerequisites +------------- + +Some concepts mentioned in this tutorial, like :doc:`Nodes <../../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` and :doc:`Topics <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`, were covered in previous tutorials in the series. + +You will need the :doc:`turtlesim package <../../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ +Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +2 ros2 service list +^^^^^^^^^^^^^^^^^^^ + +Running the ``ros2 service list`` command in a new terminal will return a list of all the services currently active in the system: + +.. code-block:: console + + $ ros2 service list + /clear + /kill + /reset + /spawn + /teleop_turtle/describe_parameters + /teleop_turtle/get_parameter_types + /teleop_turtle/get_parameters + /teleop_turtle/list_parameters + /teleop_turtle/set_parameters + /teleop_turtle/set_parameters_atomically + /turtle1/set_pen + /turtle1/teleport_absolute + /turtle1/teleport_relative + /turtlesim/describe_parameters + /turtlesim/get_parameter_types + /turtlesim/get_parameters + /turtlesim/list_parameters + /turtlesim/set_parameters + /turtlesim/set_parameters_atomically + +You will see that both nodes have the same six services with ``parameters`` in their names. +Nearly every node in ROS 2 has these infrastructure services that parameters are built off of. +There will be more about parameters in the next tutorial. +In this tutorial, the parameter services will be omitted from the discussion. + +For now, let's focus on the turtlesim-specific services, ``/clear``, ``/kill``, ``/reset``, ``/spawn``, ``/turtle1/set_pen``, ``/turtle1/teleport_absolute``, and ``/turtle1/teleport_relative``. +You may recall interacting with some of these services using rqt in the :doc:`Use turtlesim, ros2, and rqt <../../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` tutorial. + + +3 ros2 service type +^^^^^^^^^^^^^^^^^^^ + +Services have types that describe how the request and response data of a service is structured. +Service types are defined similarly to topic types, except service types have two parts: one message for the request and another for the response. + +To find out the type of a service, use the command: + +.. code-block:: console + + $ ros2 service type + +Let's take a look at turtlesim's ``/clear`` service. +In a new terminal, enter the command: + +.. code-block:: console + + $ ros2 service type /clear + std_srvs/srv/Empty + +The ``Empty`` type means the service call sends no data when making a request and receives no data when receiving a response. + +3.1 ros2 service list -t +~~~~~~~~~~~~~~~~~~~~~~~~ + +To see the types of all the active services at the same time, you can append the ``--show-types`` option, abbreviated as ``-t``, to the ``list`` command: + +.. code-block:: console + + $ ros2 service list -t + /clear [std_srvs/srv/Empty] + /kill [turtlesim_msgs/srv/Kill] + /reset [std_srvs/srv/Empty] + /spawn [turtlesim_msgs/srv/Spawn] + ... + /turtle1/set_pen [turtlesim_msgs/srv/SetPen] + /turtle1/teleport_absolute [turtlesim_msgs/srv/TeleportAbsolute] + /turtle1/teleport_relative [turtlesim_msgs/srv/TeleportRelative] + ... + +4 ros2 service info +^^^^^^^^^^^^^^^^^^^ + +To see information of a particular service, use the command: + +.. code-block:: console + + $ ros2 service info + +This returns the service type and the count of service clients and servers. + +For example, you can find the count of clients and servers for the ``/clear`` service: + +.. code-block:: console + + $ ros2 service info /clear + Type: std_srvs/srv/Empty + Clients count: 0 + Services count: 1 + +4.1 ros2 service info --verbose +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For more detailed information about a service, you can append the ``--verbose`` (or ``-v``) option to the ``info`` command: + +.. code-block:: console + + $ ros2 service info --verbose + +For example: you can get verbose information about the ``/clear`` service: + +.. code-block:: console + + $ ros2 service info --verbose /clear + +This will return additional information including the node name and namespace of the service server, as well as the underlying middleware (RMW) implementation details. +An important information for Developers that the ``Endpoint count`` will be 2 for DDS based RMW implementations (connextdds, cyclone, fastrtps) because DDS creates two endpoints (one for request and one for response) for each service server. + +.. code-block:: console + + Type: std_srvs/srv/Empty + Clients count: 0 + Services count: 1 + Node name: turtlesim + Node namespace: / + Service type: std_srvs/srv/Empty + Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 + Endpoint type: SERVER + Endpoint count: 2 + GIDs: + - Request Reader : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.13.04 + - Response Writer : 01.0f.93.f0.07.92.53.47.00.00.00.00.00.00.14.03 + QoS profiles: + - Request Reader : + Reliability: RELIABLE + History (Depth): KEEP_LAST (10) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + - Response Writer : + Reliability: RELIABLE + History (Depth): KEEP_LAST (10) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +Where as for non-DDS based RMW implementations like ``rmw_zenoh_cpp``, the ``Endpoint count`` will be 1 because it uses a single endpoint for both request and response. + +.. code-block:: console + + Type: std_srvs/srv/Empty + Clients count: 0 + Services count: 1 + Node name: turtlesim + Node namespace: / + Service type: std_srvs/srv/Empty + Service type hash: RIHS01_5888399dedec5ccc85ea6451949fd2c9f97bfdf963f9a588821639fcd31b5d19 + Endpoint type: SERVER + Endpoint count: 1 + GID: 59.b0.ea.78.57.3c.52.b4.c6.e9.af.44.22.3d.7c.f5 + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (10) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +If you want to learn more about different RMW implementations, refer to the :doc:`About Different Middleware Vendors <../../../../client-libraries/About-Different-Middleware-Vendors>` concept. + +5 ros2 service find +^^^^^^^^^^^^^^^^^^^ + +If you want to find all the services of a specific type, you can use the command: + +.. code-block:: console + + $ ros2 service find + +For example, you can find all the ``Empty`` typed services like this: + +.. code-block:: console + + $ ros2 service find std_srvs/srv/Empty + /clear + /reset + +6 ros2 interface show +^^^^^^^^^^^^^^^^^^^^^ + +You can call services from the command line, but first you need to know the structure of the input arguments. + +.. code-block:: console + + $ ros2 interface show + +Try this on the ``/clear`` service's type, ``Empty``: + +.. code-block:: console + + $ ros2 interface show std_srvs/srv/Empty + --- + +The ``---`` separates the request structure (above) from the response structure (below). +But, as you learned earlier, the ``Empty`` type doesn't send or receive any data. +So, naturally, its structure is blank. + +Let's introspect a service with a type that sends and receives data, like ``/spawn``. +From the results of ``ros2 service list -t``, we know ``/spawn``'s type is ``turtlesim_msgs/srv/Spawn``. + +To see the request and response arguments of the ``/spawn`` service, run the command: + +.. code-block:: console + + $ ros2 interface show turtlesim_msgs/srv/Spawn + float32 x + float32 y + float32 theta + string name # Optional. A unique name will be created and returned if this is empty + --- + string name + +The information above the ``---`` line tells us the arguments needed to call ``/spawn``. +``x``, ``y`` and ``theta`` determine the 2D pose of the spawned turtle, and ``name`` is clearly optional. + +The information below the line isn't something you need to know in this case, but it can help you understand the data type of the response you get from the call. + +7 ros2 service call +^^^^^^^^^^^^^^^^^^^ + +Now that you know what a service type is, how to find a service's type, and how to find the structure of that type's arguments, you can call a service using: + +.. code-block:: console + + $ ros2 service call + +The ```` part is optional. +For example, you know that ``Empty`` typed services don't have any arguments: + +.. code-block:: console + + $ ros2 service call /clear std_srvs/srv/Empty + +This command will clear the turtlesim window of any lines your turtle has drawn. + +.. image:: images/clear.png + +Now let's spawn a new turtle by calling ``/spawn`` and setting arguments. +Input ```` in a service call from the command-line need to be in YAML syntax. + +Enter the command: + +.. code-block:: console + + $ ros2 service call /spawn turtlesim_msgs/srv/Spawn "{x: 2, y: 2, theta: 0.2, name: ''}" + requester: making request: turtlesim_msgs.srv.Spawn_Request(x=2.0, y=2.0, theta=0.2, name='') + + response: + turtlesim_msgs.srv.Spawn_Response(name='turtle2') + +You will get this method-style view of what's happening, and then the service response. + +Your turtlesim window will update with the newly spawned turtle right away: + +.. image:: images/spawn.png + +8 ros2 service echo +^^^^^^^^^^^^^^^^^^^ + +To see the data communication between a service client and a service server you can ``echo`` the service using: + +.. code-block:: console + + $ ros2 service echo + +``ros2 service echo`` depends on service introspection of a service client and server, that is disabled by default. +To enable it, users must call ``configure_introspection`` after creating a service client or server. + +Start up the ``introspection_client`` and ``introspection_service`` service introspection demo. + +.. code-block:: console + + $ ros2 launch demo_nodes_cpp introspect_services_launch.py + +Open another terminal and run the following to enable service introspection for ``introspection_client`` and ``introspection_service``. + +.. code-block:: console + + $ ros2 param set /introspection_service service_configure_introspection contents + $ ros2 param set /introspection_client client_configure_introspection contents + +Now we are able to see the service communication between ``introspection_client`` and ``introspection_service`` via ``ros2 service echo``. + +.. code-block:: console + + $ ros2 service echo --flow-style /add_two_ints + info: + event_type: REQUEST_SENT + stamp: + sec: 1709408301 + nanosec: 423227292 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 618 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: REQUEST_RECEIVED + stamp: + sec: 1709408301 + nanosec: 423601471 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 618 + request: [{a: 2, b: 3}] + response: [] + --- + info: + event_type: RESPONSE_SENT + stamp: + sec: 1709408301 + nanosec: 423900744 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 20, 4] + sequence_number: 618 + request: [] + response: [{sum: 5}] + --- + info: + event_type: RESPONSE_RECEIVED + stamp: + sec: 1709408301 + nanosec: 424153133 + client_gid: [1, 15, 0, 18, 250, 205, 12, 100, 0, 0, 0, 0, 0, 0, 21, 3] + sequence_number: 618 + request: [] + response: [{sum: 5}] + --- + +Summary +------- + +Nodes can communicate using services in ROS 2. +Unlike a topic - a one way communication pattern where a node publishes information that can be consumed by one or more subscribers - a service is a request/response pattern where a client makes a request to a node providing the service and the service processes the request and generates a response. + +You generally don't want to use a service for continuous calls; topics or even actions would be better suited. + +In this tutorial you used command line tools to identify, introspect, and call services. + +Next steps +---------- + +In the next tutorial, :doc:`../../../../parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters`, you will learn about configuring node settings. + +Related content +--------------- + Check out `this tutorial `_; it's an excellent realistic application of ROS services using a Robotis robot arm. \ No newline at end of file diff --git a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/Service-MultipleServiceClient.gif b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/Service-MultipleServiceClient.gif similarity index 100% rename from source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/Service-MultipleServiceClient.gif rename to source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/Service-MultipleServiceClient.gif diff --git a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/Service-SingleServiceClient.gif b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/Service-SingleServiceClient.gif similarity index 100% rename from source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/Service-SingleServiceClient.gif rename to source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/Service-SingleServiceClient.gif diff --git a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/clear.png b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/clear.png similarity index 100% rename from source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/clear.png rename to source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/clear.png diff --git a/source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/spawn.png b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/spawn.png similarity index 100% rename from source/ROS-Framework/services/Working-with-services/Understanding-ROS2-Services/images/spawn.png rename to source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/images/spawn.png diff --git a/source/ROS-Framework/topics/About-Quality-of-Service-Settings.rst b/source/ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings.rst similarity index 100% rename from source/ROS-Framework/topics/About-Quality-of-Service-Settings.rst rename to source/ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings.rst diff --git a/source/ROS-Framework/topics/About-Topic-Statistics.rst b/source/ROS-Framework/interfaces/topics/About-Topic-Statistics.rst similarity index 100% rename from source/ROS-Framework/topics/About-Topic-Statistics.rst rename to source/ROS-Framework/interfaces/topics/About-Topic-Statistics.rst diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst similarity index 93% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst index 0539313ca1f..eef5142e177 100644 --- a/source/ROS-Framework/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst +++ b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst @@ -1,550 +1,550 @@ -.. redirect-from:: - - Tutorials/Topics/Understanding-ROS2-Topics - Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics - -.. _ROS2Topics: - -Understanding topics -==================== - -**Goal:** Use rqt_graph and command line tools to introspect ROS 2 topics. - -**Tutorial level:** Beginner - -**Time:** 20 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -ROS 2 breaks complex systems down into many modular nodes. -Topics are a vital element of the ROS graph that act as a bus for nodes to exchange messages. - -.. image:: images/Topic-SinglePublisherandSingleSubscriber.gif - -A node may publish data to any number of topics and simultaneously have subscriptions to any number of topics. - -.. image:: images/Topic-MultiplePublisherandMultipleSubscriber.gif - -Topics are one of the main ways in which data is moved between nodes and therefore between different parts of the system. - - -Prerequisites -------------- - -The :doc:`previous tutorial <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` provides some useful background information on nodes that is built upon here. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../Get-Started/Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ - -By now you should be comfortable starting up turtlesim. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Recall from the :doc:`previous tutorial <../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that the names of these nodes are ``/turtlesim`` and ``/teleop_turtle`` by default. - - -2 rqt_graph -^^^^^^^^^^^ - -Throughout this tutorial, we will use ``rqt_graph`` to visualize the changing nodes and topics, as well as the connections between them. - -The :doc:`turtlesim tutorial <../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` tells you how to install rqt and all its plugins, including ``rqt_graph``. - -To run rqt_graph, open a new terminal and enter the command: - -.. code-block:: console - - $ ros2 run rqt_graph rqt_graph - -You can also open rqt_graph by opening ``rqt`` and selecting **Plugins** > **Introspection** > **Node Graph**. - -.. image:: images/rqt_graph.png - -You should see the above nodes and topic, as well as two actions around the periphery of the graph (let's ignore those for now). -If you hover your mouse over the topic in the center, you'll see the color highlighting like in the image above. - -The graph is depicting how the ``/turtlesim`` node and the ``/teleop_turtle`` node are communicating with each other over a topic. -The ``/teleop_turtle`` node is publishing data (the keystrokes you enter to move the turtle around) to the ``/turtle1/cmd_vel`` topic, and the ``/turtlesim`` node is subscribed to that topic to receive the data. - -The highlighting feature of rqt_graph is very helpful when examining more complex systems with many nodes and topics connected in many different ways. - -rqt_graph is a graphical introspection tool. -Now we'll look at some command line tools for introspecting topics. - - -3 ros2 topic list -^^^^^^^^^^^^^^^^^ - -Running the ``ros2 topic list`` command in a new terminal will return a list of all the topics currently active in the system: - -.. code-block:: console - - $ ros2 topic list - /parameter_events - /rosout - /turtle1/cmd_vel - /turtle1/color_sensor - /turtle1/pose - -``ros2 topic list -t`` will return the same list of topics, this time with the topic type appended in brackets: - -.. code-block:: console - - $ ros2 topic list -t - /parameter_events [rcl_interfaces/msg/ParameterEvent] - /rosout [rcl_interfaces/msg/Log] - /turtle1/cmd_vel [geometry_msgs/msg/Twist] - /turtle1/color_sensor [turtlesim_msgs/msg/Color] - /turtle1/pose [turtlesim_msgs/msg/Pose] - -These attributes, particularly the type, are how nodes know they're talking about the same information as it moves over topics. - -If you're wondering where all these topics are in rqt_graph, you can uncheck all the boxes under **Hide:** - -.. image:: images/unhide.png - -For now, though, leave those options checked to avoid confusion. - -4 ros2 topic echo -^^^^^^^^^^^^^^^^^ - -To see the data being published on a topic, use: - -.. code-block:: console - - $ ros2 topic echo - -Since we know that ``/teleop_turtle`` publishes data to ``/turtlesim`` over the ``/turtle1/cmd_vel`` topic, let's use ``echo`` to introspect that topic: - -.. code-block:: console - - $ ros2 topic echo /turtle1/cmd_vel - -At first, this command won't return any data. -That's because it's waiting for ``/teleop_turtle`` to publish something. - -Return to the terminal where ``turtle_teleop_key`` is running and use the arrows to move the turtle around. -Watch the terminal where your ``echo`` is running at the same time, and you'll see position data being published for every movement you make: - -.. code-block:: console - - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -Now return to rqt_graph and uncheck the **Debug** box. - -.. image:: images/debug.png - -``/_ros2cli_26646`` is the node created by the ``echo`` command we just ran (the number might be different). -Now you can see that the publisher is publishing data over the ``cmd_vel`` topic, and two subscribers are subscribed to it. - -5 ros2 topic info -^^^^^^^^^^^^^^^^^ - -Topics don't have to only be one-to-one communication; they can be one-to-many, many-to-one, or many-to-many. - -Another way to look at this is running: - -.. code-block:: console - - $ ros2 topic info /turtle1/cmd_vel - Type: geometry_msgs/msg/Twist - Publisher count: 1 - Subscription count: 2 - -5.1 ros2 topic info --verbose -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -For more detailed information about a topic, you can use the ``--verbose`` (or ``-v``) flag: - -.. code-block:: console - - $ ros2 topic info /turtle1/cmd_vel --verbose - -This will return additional details including: - -- Node names and namespaces of publishers and subscribers -- Topic type -- QoS profiles - -.. code-block:: console - - Type: geometry_msgs/msg/Twist - - Publisher count: 1 - - Node name: teleop_turtle - Node namespace: / - Topic type: geometry_msgs/msg/Twist - Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a - Endpoint type: PUBLISHER - GID: 24.ba.3e.e7.c1.51.bb.46.21.41.de.36.1b.14.73.5e - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (7) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Subscription count: 2 - - Node name: _ros2cli_300492 - Node namespace: / - Topic type: geometry_msgs/msg/Twist - Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a - Endpoint type: SUBSCRIPTION - GID: cc.4d.98.79.29.91.fe.25.8a.0a.c9.03.db.1a.ec.81 - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (5) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - - Node name: turtlesim - Node namespace: / - Topic type: geometry_msgs/msg/Twist - Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a - Endpoint type: SUBSCRIPTION - GID: 9c.33.59.38.b2.f2.42.47.69.1b.7f.0e.5e.1d.86.f5 - QoS profile: - Reliability: RELIABLE - History (Depth): KEEP_LAST (7) - Durability: VOLATILE - Lifespan: Infinite - Deadline: Infinite - Liveliness: AUTOMATIC - Liveliness lease duration: Infinite - -6 ros2 interface show -^^^^^^^^^^^^^^^^^^^^^ - -Nodes send data over topics using messages. -Publishers and subscribers must send and receive the same type of message to communicate. - -The topic types we saw earlier after running ``ros2 topic list -t`` let us know what message type is used on each topic. -Recall that the ``cmd_vel`` topic has the type: - -.. code-block:: console - - geometry_msgs/msg/Twist - -This means that in the package ``geometry_msgs`` there is a ``msg`` called ``Twist``. - -Now we can run ``ros2 interface show `` on this type to learn its details. -Specifically, what structure of data the message expects. - -.. code-block:: console - - $ ros2 interface show geometry_msgs/msg/Twist - -Which will return: - -.. code-block:: text - - # This expresses velocity in free space broken into its linear and angular parts. - Vector3 linear - float64 x - float64 y - float64 z - Vector3 angular - float64 x - float64 y - float64 z - -This tells you that the ``/turtlesim`` node is expecting a message with two vectors, ``linear`` and ``angular``, of three elements each. -If you recall the data we saw ``/teleop_turtle`` passing to ``/turtlesim`` with the ``echo`` command, it's in the same structure: - -.. code-block:: console - - linear: - x: 2.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - --- - -7 ros2 topic pub -^^^^^^^^^^^^^^^^ - -Now that you have the message structure, you can publish data to a topic directly from the command line using: - -.. code-block:: console - - $ ros2 topic pub '' - -The ``''`` argument is the actual data you'll pass to the topic, in the structure you just discovered in the previous section. - -There are four main ways to use the ``pub`` command as shown below. -However, the autocomplete feature described in ``c.`` and ``d.`` is not supported in Windows. - -a. **Publishing dictionary strings**: - - In order to publish data to a topic, you need to pass the data in the form of YAML strings. - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - - However, you do not need to specify the entire message, if you are just changing the linear or angular velocity, you can just specify the values you want to change. - - For example, if you want to change the linear velocity to 2.0 and keep the angular velocity at 1.8, you can do the following: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0}, angular: {z: 1.8}}" - -b. **Publishing an empty message**: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist - - This will publish the default values for the message type at 1 Hz. - In this case, this equivalent to the following command: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}" --rate 1 - -c. **Using autocomplete**: - - You can trigger the autocomplete feature of your terminal by the following: - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist - --keep-alive - --max-wait-time-secs - --node-name - --once - --print - --qos-depth - --qos-durability - --qos-history - --qos-liveliness - --qos-liveliness-lease-duration-seconds - --qos-profile - --qos-reliability - --rate - --spin-time - --stdin - --times - --use-sim-time - --wait-matching-subscriptions - --yaml-file - -1 - -n - -p - -r - -s - -t - -w - \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' - - All the options will be autocompleted by pressing the :kbd:`tab` key after the entering the first few characters of the option. - However, the topic message prototype will only be autocompleted after ``\'`` is entered. - - This is because the terminal does not recognize the single quote as part of the autocomplete string. - Hence it needs to be escaped by using ``\'`` to be recognized as part of the string. - - The final autocompleted string will look like this: - - .. code-block:: bash - - ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist 'linear: - x: 0.0 - y: 0.0 - z: 0.0 - angular: - x: 0.0 - y: 0.0 - z: 0.0 - ' - - This string is editable and you can change the values of the message type as required. - -d. **Using the raw autocompleted string**: - - As mentioned above, the autocompleted string for ``geometry_msgs/msg/Twist`` looks like this: - - .. code-block:: console - - \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' - - This can be directly used in place of the yaml string in the command line. - - .. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' - - -The turtle (and commonly the real robots which it is meant to emulate) require a steady stream of commands to operate continuously. -So, to get the turtle moving, and keep it moving, you can use the following dictionary string: - -.. code-block:: console - - $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - -.. image:: images/pub_stream.png - -At times you may want to publish data to your topic only once (rather than continuously). -To publish your command just once add the ``--once`` option. - -.. code-block:: console - - $ ros2 topic pub --once -w 2 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" - -``--once`` is an optional argument meaning "publish one message then exit". - -``-w 2`` is an optional argument meaning "wait for two matching subscriptions". -This is needed because we have both turtlesim and the topic echo subscribed. - -You will see the following output in the terminal: - -.. code-block:: console - - Waiting for at least 2 matching subscription(s)... - publisher: beginning loop - publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=1.8)) - -And you will see your turtle move like so: - -.. image:: images/pub_once.png - - -You can refresh rqt_graph to see what's happening graphically. -You will see that the ``ros2 topic pub ...`` node (``/_ros2cli_30358``) is publishing over the ``/turtle1/cmd_vel`` topic, which is being received by both the ``ros2 topic echo ...`` node (``/_ros2cli_26646``) and the ``/turtlesim`` node now. - -.. image:: images/rqt_graph2.png - -Finally, you can run ``echo`` on the ``pose`` topic and recheck rqt_graph: - -.. code-block:: console - - $ ros2 topic echo /turtle1/pose - -.. image:: images/rqt_graph3.png - -You can see that the ``/turtlesim`` node is also publishing to the ``pose`` topic, which the new ``echo`` node has subscribed to. - -When publishing messages with timestamps, ``pub`` has two methods to automatically fill them out with the current time. -For messages with a ``std_msgs/msg/Header``, the header field can be set to ``auto`` to fill out the ``stamp`` field. - -.. code-block:: console - - $ ros2 topic pub /pose geometry_msgs/msg/PoseStamped '{header: "auto", pose: {position: {x: 1.0, y: 2.0, z: 3.0}}}' - -If the message does not use a full header, but just has a field with type ``builtin_interfaces/msg/Time``, that can be set to the value ``now``. - -.. code-block:: console - - $ ros2 topic pub /reference sensor_msgs/msg/TimeReference '{header: "auto", time_ref: "now", source: "dumy"}' - -8 ros2 topic hz -^^^^^^^^^^^^^^^ - -You can also view the rate at which data is published using: - -.. code-block:: console - - $ ros2 topic hz /turtle1/pose - average rate: 59.354 - min: 0.005s max: 0.027s std dev: 0.00284s window: 58 - -It will return data on the rate at which the ``/turtlesim`` node is publishing data to the ``pose`` topic. - -Recall that you set the rate of ``turtle1/cmd_vel`` to publish at a steady 1 Hz using ``ros2 topic pub --rate 1``. -If you run the above command with ``turtle1/cmd_vel`` instead of ``turtle1/pose``, you will see an average reflecting that rate. - -.. Note:: The rate reflects the receiving rate on the subscription created by the ``ros2 topic hz`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher rate. - -9 ros2 topic bw -^^^^^^^^^^^^^^^ - -The bandwidth used by a topic can be viewed using: - -.. code-block:: console - - $ ros2 topic bw /turtle1/pose - Subscribed to [/turtle1/pose] - 1.51 KB/s from 62 messages - Message size mean: 0.02 KB min: 0.02 KB max: 0.02 KB - -It returns the bandwidth utilization and number of messages being published to the ``/turtle1/pose`` topic. - -.. Note:: The bandwidth reflects the receiving rate on the subscription created by the ``ros2 topic bw`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher's bandwidth. - -10 ros2 topic find -^^^^^^^^^^^^^^^^^^ - -To list a list of available topics of a given type use: - -.. code-block:: console - - $ ros2 topic find - -Recall that the ``cmd_vel`` topic has the type: - -.. code-block:: console - - geometry_msgs/msg/Twist - -Using the ``find`` command outputs topics available when given the message type: - -.. code-block:: console - - $ ros2 topic find geometry_msgs/msg/Twist - /turtle1/cmd_vel - -11 Clean up -^^^^^^^^^^^ - -At this point you'll have a lot of nodes running. -Don't forget to stop them by entering ``Ctrl+C`` in each terminal. - -Summary -------- - -Nodes publish information over topics, which allows any number of other nodes to subscribe to and access that information. -In this tutorial you examined the connections between several nodes over topics using rqt_graph and command line tools. -You should now have a good idea of how data moves around a ROS 2 system. - -Next steps ----------- - +.. redirect-from:: + + Tutorials/Topics/Understanding-ROS2-Topics + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Topics/Understanding-ROS2-Topics + +.. _ROS2Topics: + +Understanding topics +==================== + +**Goal:** Use rqt_graph and command line tools to introspect ROS 2 topics. + +**Tutorial level:** Beginner + +**Time:** 20 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +ROS 2 breaks complex systems down into many modular nodes. +Topics are a vital element of the ROS graph that act as a bus for nodes to exchange messages. + +.. image:: images/Topic-SinglePublisherandSingleSubscriber.gif + +A node may publish data to any number of topics and simultaneously have subscriptions to any number of topics. + +.. image:: images/Topic-MultiplePublisherandMultipleSubscriber.gif + +Topics are one of the main ways in which data is moved between nodes and therefore between different parts of the system. + + +Prerequisites +------------- + +The :doc:`previous tutorial <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` provides some useful background information on nodes that is built upon here. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ + +By now you should be comfortable starting up turtlesim. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Recall from the :doc:`previous tutorial <../../../nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes>` that the names of these nodes are ``/turtlesim`` and ``/teleop_turtle`` by default. + + +2 rqt_graph +^^^^^^^^^^^ + +Throughout this tutorial, we will use ``rqt_graph`` to visualize the changing nodes and topics, as well as the connections between them. + +The :doc:`turtlesim tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` tells you how to install rqt and all its plugins, including ``rqt_graph``. + +To run rqt_graph, open a new terminal and enter the command: + +.. code-block:: console + + $ ros2 run rqt_graph rqt_graph + +You can also open rqt_graph by opening ``rqt`` and selecting **Plugins** > **Introspection** > **Node Graph**. + +.. image:: images/rqt_graph.png + +You should see the above nodes and topic, as well as two actions around the periphery of the graph (let's ignore those for now). +If you hover your mouse over the topic in the center, you'll see the color highlighting like in the image above. + +The graph is depicting how the ``/turtlesim`` node and the ``/teleop_turtle`` node are communicating with each other over a topic. +The ``/teleop_turtle`` node is publishing data (the keystrokes you enter to move the turtle around) to the ``/turtle1/cmd_vel`` topic, and the ``/turtlesim`` node is subscribed to that topic to receive the data. + +The highlighting feature of rqt_graph is very helpful when examining more complex systems with many nodes and topics connected in many different ways. + +rqt_graph is a graphical introspection tool. +Now we'll look at some command line tools for introspecting topics. + + +3 ros2 topic list +^^^^^^^^^^^^^^^^^ + +Running the ``ros2 topic list`` command in a new terminal will return a list of all the topics currently active in the system: + +.. code-block:: console + + $ ros2 topic list + /parameter_events + /rosout + /turtle1/cmd_vel + /turtle1/color_sensor + /turtle1/pose + +``ros2 topic list -t`` will return the same list of topics, this time with the topic type appended in brackets: + +.. code-block:: console + + $ ros2 topic list -t + /parameter_events [rcl_interfaces/msg/ParameterEvent] + /rosout [rcl_interfaces/msg/Log] + /turtle1/cmd_vel [geometry_msgs/msg/Twist] + /turtle1/color_sensor [turtlesim_msgs/msg/Color] + /turtle1/pose [turtlesim_msgs/msg/Pose] + +These attributes, particularly the type, are how nodes know they're talking about the same information as it moves over topics. + +If you're wondering where all these topics are in rqt_graph, you can uncheck all the boxes under **Hide:** + +.. image:: images/unhide.png + +For now, though, leave those options checked to avoid confusion. + +4 ros2 topic echo +^^^^^^^^^^^^^^^^^ + +To see the data being published on a topic, use: + +.. code-block:: console + + $ ros2 topic echo + +Since we know that ``/teleop_turtle`` publishes data to ``/turtlesim`` over the ``/turtle1/cmd_vel`` topic, let's use ``echo`` to introspect that topic: + +.. code-block:: console + + $ ros2 topic echo /turtle1/cmd_vel + +At first, this command won't return any data. +That's because it's waiting for ``/teleop_turtle`` to publish something. + +Return to the terminal where ``turtle_teleop_key`` is running and use the arrows to move the turtle around. +Watch the terminal where your ``echo`` is running at the same time, and you'll see position data being published for every movement you make: + +.. code-block:: console + + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +Now return to rqt_graph and uncheck the **Debug** box. + +.. image:: images/debug.png + +``/_ros2cli_26646`` is the node created by the ``echo`` command we just ran (the number might be different). +Now you can see that the publisher is publishing data over the ``cmd_vel`` topic, and two subscribers are subscribed to it. + +5 ros2 topic info +^^^^^^^^^^^^^^^^^ + +Topics don't have to only be one-to-one communication; they can be one-to-many, many-to-one, or many-to-many. + +Another way to look at this is running: + +.. code-block:: console + + $ ros2 topic info /turtle1/cmd_vel + Type: geometry_msgs/msg/Twist + Publisher count: 1 + Subscription count: 2 + +5.1 ros2 topic info --verbose +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For more detailed information about a topic, you can use the ``--verbose`` (or ``-v``) flag: + +.. code-block:: console + + $ ros2 topic info /turtle1/cmd_vel --verbose + +This will return additional details including: + +- Node names and namespaces of publishers and subscribers +- Topic type +- QoS profiles + +.. code-block:: console + + Type: geometry_msgs/msg/Twist + + Publisher count: 1 + + Node name: teleop_turtle + Node namespace: / + Topic type: geometry_msgs/msg/Twist + Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a + Endpoint type: PUBLISHER + GID: 24.ba.3e.e7.c1.51.bb.46.21.41.de.36.1b.14.73.5e + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (7) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + + Subscription count: 2 + + Node name: _ros2cli_300492 + Node namespace: / + Topic type: geometry_msgs/msg/Twist + Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a + Endpoint type: SUBSCRIPTION + GID: cc.4d.98.79.29.91.fe.25.8a.0a.c9.03.db.1a.ec.81 + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (5) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + + Node name: turtlesim + Node namespace: / + Topic type: geometry_msgs/msg/Twist + Topic type hash: RIHS01_9c45bf16fe0983d80e3cfe750d6835843d265a9a6c46bd2e609fcddde6fb8d2a + Endpoint type: SUBSCRIPTION + GID: 9c.33.59.38.b2.f2.42.47.69.1b.7f.0e.5e.1d.86.f5 + QoS profile: + Reliability: RELIABLE + History (Depth): KEEP_LAST (7) + Durability: VOLATILE + Lifespan: Infinite + Deadline: Infinite + Liveliness: AUTOMATIC + Liveliness lease duration: Infinite + +6 ros2 interface show +^^^^^^^^^^^^^^^^^^^^^ + +Nodes send data over topics using messages. +Publishers and subscribers must send and receive the same type of message to communicate. + +The topic types we saw earlier after running ``ros2 topic list -t`` let us know what message type is used on each topic. +Recall that the ``cmd_vel`` topic has the type: + +.. code-block:: console + + geometry_msgs/msg/Twist + +This means that in the package ``geometry_msgs`` there is a ``msg`` called ``Twist``. + +Now we can run ``ros2 interface show `` on this type to learn its details. +Specifically, what structure of data the message expects. + +.. code-block:: console + + $ ros2 interface show geometry_msgs/msg/Twist + +Which will return: + +.. code-block:: text + + # This expresses velocity in free space broken into its linear and angular parts. + Vector3 linear + float64 x + float64 y + float64 z + Vector3 angular + float64 x + float64 y + float64 z + +This tells you that the ``/turtlesim`` node is expecting a message with two vectors, ``linear`` and ``angular``, of three elements each. +If you recall the data we saw ``/teleop_turtle`` passing to ``/turtlesim`` with the ``echo`` command, it's in the same structure: + +.. code-block:: console + + linear: + x: 2.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + --- + +7 ros2 topic pub +^^^^^^^^^^^^^^^^ + +Now that you have the message structure, you can publish data to a topic directly from the command line using: + +.. code-block:: console + + $ ros2 topic pub '' + +The ``''`` argument is the actual data you'll pass to the topic, in the structure you just discovered in the previous section. + +There are four main ways to use the ``pub`` command as shown below. +However, the autocomplete feature described in ``c.`` and ``d.`` is not supported in Windows. + +a. **Publishing dictionary strings**: + + In order to publish data to a topic, you need to pass the data in the form of YAML strings. + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + + However, you do not need to specify the entire message, if you are just changing the linear or angular velocity, you can just specify the values you want to change. + + For example, if you want to change the linear velocity to 2.0 and keep the angular velocity at 1.8, you can do the following: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0}, angular: {z: 1.8}}" + +b. **Publishing an empty message**: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist + + This will publish the default values for the message type at 1 Hz. + In this case, this equivalent to the following command: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 0.0}}" --rate 1 + +c. **Using autocomplete**: + + You can trigger the autocomplete feature of your terminal by the following: + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist + --keep-alive + --max-wait-time-secs + --node-name + --once + --print + --qos-depth + --qos-durability + --qos-history + --qos-liveliness + --qos-liveliness-lease-duration-seconds + --qos-profile + --qos-reliability + --rate + --spin-time + --stdin + --times + --use-sim-time + --wait-matching-subscriptions + --yaml-file + -1 + -n + -p + -r + -s + -t + -w + \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' + + All the options will be autocompleted by pressing the :kbd:`tab` key after the entering the first few characters of the option. + However, the topic message prototype will only be autocompleted after ``\'`` is entered. + + This is because the terminal does not recognize the single quote as part of the autocomplete string. + Hence it needs to be escaped by using ``\'`` to be recognized as part of the string. + + The final autocompleted string will look like this: + + .. code-block:: bash + + ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist 'linear: + x: 0.0 + y: 0.0 + z: 0.0 + angular: + x: 0.0 + y: 0.0 + z: 0.0 + ' + + This string is editable and you can change the values of the message type as required. + +d. **Using the raw autocompleted string**: + + As mentioned above, the autocompleted string for ``geometry_msgs/msg/Twist`` looks like this: + + .. code-block:: console + + \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' + + This can be directly used in place of the yaml string in the command line. + + .. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist \'linear:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^Jangular:\^J\ \ x:\ 0.0\^J\ \ y:\ 0.0\^J\ \ z:\ 0.0\^J\' + + +The turtle (and commonly the real robots which it is meant to emulate) require a steady stream of commands to operate continuously. +So, to get the turtle moving, and keep it moving, you can use the following dictionary string: + +.. code-block:: console + + $ ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + +.. image:: images/pub_stream.png + +At times you may want to publish data to your topic only once (rather than continuously). +To publish your command just once add the ``--once`` option. + +.. code-block:: console + + $ ros2 topic pub --once -w 2 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0, y: 0.0, z: 1.8}}" + +``--once`` is an optional argument meaning "publish one message then exit". + +``-w 2`` is an optional argument meaning "wait for two matching subscriptions". +This is needed because we have both turtlesim and the topic echo subscribed. + +You will see the following output in the terminal: + +.. code-block:: console + + Waiting for at least 2 matching subscription(s)... + publisher: beginning loop + publishing #1: geometry_msgs.msg.Twist(linear=geometry_msgs.msg.Vector3(x=2.0, y=0.0, z=0.0), angular=geometry_msgs.msg.Vector3(x=0.0, y=0.0, z=1.8)) + +And you will see your turtle move like so: + +.. image:: images/pub_once.png + + +You can refresh rqt_graph to see what's happening graphically. +You will see that the ``ros2 topic pub ...`` node (``/_ros2cli_30358``) is publishing over the ``/turtle1/cmd_vel`` topic, which is being received by both the ``ros2 topic echo ...`` node (``/_ros2cli_26646``) and the ``/turtlesim`` node now. + +.. image:: images/rqt_graph2.png + +Finally, you can run ``echo`` on the ``pose`` topic and recheck rqt_graph: + +.. code-block:: console + + $ ros2 topic echo /turtle1/pose + +.. image:: images/rqt_graph3.png + +You can see that the ``/turtlesim`` node is also publishing to the ``pose`` topic, which the new ``echo`` node has subscribed to. + +When publishing messages with timestamps, ``pub`` has two methods to automatically fill them out with the current time. +For messages with a ``std_msgs/msg/Header``, the header field can be set to ``auto`` to fill out the ``stamp`` field. + +.. code-block:: console + + $ ros2 topic pub /pose geometry_msgs/msg/PoseStamped '{header: "auto", pose: {position: {x: 1.0, y: 2.0, z: 3.0}}}' + +If the message does not use a full header, but just has a field with type ``builtin_interfaces/msg/Time``, that can be set to the value ``now``. + +.. code-block:: console + + $ ros2 topic pub /reference sensor_msgs/msg/TimeReference '{header: "auto", time_ref: "now", source: "dumy"}' + +8 ros2 topic hz +^^^^^^^^^^^^^^^ + +You can also view the rate at which data is published using: + +.. code-block:: console + + $ ros2 topic hz /turtle1/pose + average rate: 59.354 + min: 0.005s max: 0.027s std dev: 0.00284s window: 58 + +It will return data on the rate at which the ``/turtlesim`` node is publishing data to the ``pose`` topic. + +Recall that you set the rate of ``turtle1/cmd_vel`` to publish at a steady 1 Hz using ``ros2 topic pub --rate 1``. +If you run the above command with ``turtle1/cmd_vel`` instead of ``turtle1/pose``, you will see an average reflecting that rate. + +.. Note:: The rate reflects the receiving rate on the subscription created by the ``ros2 topic hz`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher rate. + +9 ros2 topic bw +^^^^^^^^^^^^^^^ + +The bandwidth used by a topic can be viewed using: + +.. code-block:: console + + $ ros2 topic bw /turtle1/pose + Subscribed to [/turtle1/pose] + 1.51 KB/s from 62 messages + Message size mean: 0.02 KB min: 0.02 KB max: 0.02 KB + +It returns the bandwidth utilization and number of messages being published to the ``/turtle1/pose`` topic. + +.. Note:: The bandwidth reflects the receiving rate on the subscription created by the ``ros2 topic bw`` command, which might be affected by platform resources and QoS configuration, and may not exactly match the publisher's bandwidth. + +10 ros2 topic find +^^^^^^^^^^^^^^^^^^ + +To list a list of available topics of a given type use: + +.. code-block:: console + + $ ros2 topic find + +Recall that the ``cmd_vel`` topic has the type: + +.. code-block:: console + + geometry_msgs/msg/Twist + +Using the ``find`` command outputs topics available when given the message type: + +.. code-block:: console + + $ ros2 topic find geometry_msgs/msg/Twist + /turtle1/cmd_vel + +11 Clean up +^^^^^^^^^^^ + +At this point you'll have a lot of nodes running. +Don't forget to stop them by entering ``Ctrl+C`` in each terminal. + +Summary +------- + +Nodes publish information over topics, which allows any number of other nodes to subscribe to and access that information. +In this tutorial you examined the connections between several nodes over topics using rqt_graph and command line tools. +You should now have a good idea of how data moves around a ROS 2 system. + +Next steps +---------- + Next you'll learn about another communication type in the ROS graph with the tutorial :doc:`../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services`. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/Topic-MultiplePublisherandMultipleSubscriber.gif b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/Topic-MultiplePublisherandMultipleSubscriber.gif similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/Topic-MultiplePublisherandMultipleSubscriber.gif rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/Topic-MultiplePublisherandMultipleSubscriber.gif diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/Topic-SinglePublisherandSingleSubscriber.gif b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/Topic-SinglePublisherandSingleSubscriber.gif similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/Topic-SinglePublisherandSingleSubscriber.gif rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/Topic-SinglePublisherandSingleSubscriber.gif diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/debug.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/debug.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/debug.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/debug.png diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/pub_once.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/pub_once.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/pub_once.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/pub_once.png diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/pub_stream.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/pub_stream.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/pub_stream.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/pub_stream.png diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/rqt_graph.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/rqt_graph.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/rqt_graph.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/rqt_graph.png diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/rqt_graph2.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/rqt_graph2.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/rqt_graph2.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/rqt_graph2.png diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/rqt_graph3.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/rqt_graph3.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/rqt_graph3.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/rqt_graph3.png diff --git a/source/ROS-Framework/topics/Understanding-ROS2-Topics/images/unhide.png b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/unhide.png similarity index 100% rename from source/ROS-Framework/topics/Understanding-ROS2-Topics/images/unhide.png rename to source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/images/unhide.png diff --git a/source/ROS-Framework/topics/Working-with-topics.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics.rst similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics.rst rename to source/ROS-Framework/interfaces/topics/Working-with-topics.rst diff --git a/source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst similarity index 97% rename from source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst index b31a6a09151..943e2fea0d2 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst @@ -1,312 +1,312 @@ -.. redirect-from:: - - Tutorials/Content-Filtering-Subscription - Tutorials/Demos/Content-Filtering-Subscription - -Creating a content filtering subscription -========================================= - -**Goal:** Create a content filtering subscription. - -**Tutorial level:** Advanced - -**Time:** 15 minutes - -.. contents:: Table of Contents - :depth: 1 - :local: - -Overview --------- - -ROS 2 applications typically consist of topics to transmit data from publishers to subscriptions. -Basically, subscriptions receive all published data from publishers on the topic. -But sometimes, a subscription might be interested in only a subset of the data which is being sent by publishers. -A content filtering subscription allows to receive only the data of interest for the application. - -In this demo, we'll be highlighting how to create a content filtering subscription and how they work. - -RMW Support ------------ - -Content filtering subscriptions require RMW implementation support. - -.. list-table:: Content-Filtering-Subscription Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - * - rmw_zenoh_cpp - - not supported - -Currently all RMW implementations that support content filtering subscriptions are `DDS `__ based. -That means that the supported filtering expressions and parameters are also dependent on `DDS `__, you can refer to `DDS specification `__ ``Annex B - Syntax for Queries and Filters`` for details. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Temperature filtering demo --------------------------- - -This demo shows how a content filtering subscription can be used to only receive temperature values that are out of the acceptable temperature range, detecting emergencies. -The content filtering subscription filters out the uninteresting temperature data, so that the subscription callback is not issued. - -ContentFilteringPublisher: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_publisher.cpp - -.. code-block:: c++ - - #include - #include - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp_components/register_node_macro.hpp" - - #include "std_msgs/msg/float32.hpp" - - #include "demo_nodes_cpp/visibility_control.h" - - namespace demo_nodes_cpp - { - // The simulated temperature data starts from -100.0 and ends at 150.0 with a step size of 10.0 - constexpr std::array TEMPERATURE_SETTING {-100.0f, 150.0f, 10.0f}; - - // Create a ContentFilteringPublisher class that subclasses the generic rclcpp::Node base class. - // The main function below will instantiate the class as a ROS node. - class ContentFilteringPublisher final : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit ContentFilteringPublisher(const rclcpp::NodeOptions & options) - : Node("content_filtering_publisher", options) - { - // Create a function for when messages are to be sent. - auto publish_message = - [this]() -> void - { - msg_ = std::make_unique(); - msg_->data = temperature_; - temperature_ += TEMPERATURE_SETTING[2]; - if (temperature_ > TEMPERATURE_SETTING[1]) { - temperature_ = TEMPERATURE_SETTING[0]; - } - RCLCPP_INFO(this->get_logger(), "Publishing: '%f'", msg_->data); - // Put the message into a queue to be processed by the middleware. - // This call is non-blocking. - pub_->publish(std::move(msg_)); - }; - // Create a publisher with a custom Quality of Service profile. - // Uniform initialization is suggested so it can be trivially changed to - // rclcpp::KeepAll{} if the user wishes. - // (rclcpp::KeepLast(7) -> rclcpp::KeepAll() fails to compile) - rclcpp::QoS qos(rclcpp::KeepLast{7}); - pub_ = this->create_publisher("temperature", qos); - - int64_t publish_ms = this->declare_parameter("publish_ms", 1000); - - // Use a timer to schedule periodic message publishing. - timer_ = this->create_wall_timer(std::chrono::milliseconds(publish_ms), publish_message); - } - - private: - float temperature_ = TEMPERATURE_SETTING[0]; - std::unique_ptr msg_; - rclcpp::Publisher::SharedPtr pub_; - rclcpp::TimerBase::SharedPtr timer_; - }; - - } // namespace demo_nodes_cpp - -The content filter is defined in the subscription side, publishers don't need to be configured in any special way to allow content filtering. -The ``ContentFilteringPublisher`` node publishes simulated temperature data starting from -100.0 and ending at 150.0 with a step size of 10.0 every second. - -We can run the demo by running the ``ros2 run demo_nodes_cpp content_filtering_publisher`` executable (don't forget to source the setup file first): - -.. code-block:: console - - $ ros2 run demo_nodes_cpp content_filtering_publisher - [INFO] [1651094594.822753479] [content_filtering_publisher]: Publishing: '-100.000000' - [INFO] [1651094595.822723857] [content_filtering_publisher]: Publishing: '-90.000000' - [INFO] [1651094596.822752996] [content_filtering_publisher]: Publishing: '-80.000000' - [INFO] [1651094597.822752475] [content_filtering_publisher]: Publishing: '-70.000000' - [INFO] [1651094598.822721485] [content_filtering_publisher]: Publishing: '-60.000000' - [INFO] [1651094599.822696188] [content_filtering_publisher]: Publishing: '-50.000000' - [INFO] [1651094600.822699217] [content_filtering_publisher]: Publishing: '-40.000000' - [INFO] [1651094601.822744113] [content_filtering_publisher]: Publishing: '-30.000000' - [INFO] [1651094602.822694805] [content_filtering_publisher]: Publishing: '-20.000000' - [INFO] [1651094603.822735805] [content_filtering_publisher]: Publishing: '-10.000000' - [INFO] [1651094604.822722094] [content_filtering_publisher]: Publishing: '0.000000' - [INFO] [1651094605.822699960] [content_filtering_publisher]: Publishing: '10.000000' - [INFO] [1651094606.822748946] [content_filtering_publisher]: Publishing: '20.000000' - [INFO] [1651094607.822694017] [content_filtering_publisher]: Publishing: '30.000000' - [INFO] [1651094608.822708798] [content_filtering_publisher]: Publishing: '40.000000' - [INFO] [1651094609.822692417] [content_filtering_publisher]: Publishing: '50.000000' - [INFO] [1651094610.822696426] [content_filtering_publisher]: Publishing: '60.000000' - [INFO] [1651094611.822751913] [content_filtering_publisher]: Publishing: '70.000000' - [INFO] [1651094612.822692231] [content_filtering_publisher]: Publishing: '80.000000' - [INFO] [1651094613.822745549] [content_filtering_publisher]: Publishing: '90.000000' - [INFO] [1651094614.822701982] [content_filtering_publisher]: Publishing: '100.000000' - [INFO] [1651094615.822691465] [content_filtering_publisher]: Publishing: '110.000000' - [INFO] [1651094616.822649070] [content_filtering_publisher]: Publishing: '120.000000' - [INFO] [1651094617.822693616] [content_filtering_publisher]: Publishing: '130.000000' - [INFO] [1651094618.822691832] [content_filtering_publisher]: Publishing: '140.000000' - [INFO] [1651094619.822688452] [content_filtering_publisher]: Publishing: '150.000000' - [INFO] [1651094620.822645327] [content_filtering_publisher]: Publishing: '-100.000000' - [INFO] [1651094621.822689219] [content_filtering_publisher]: Publishing: '-90.000000' - [INFO] [1651094622.822694292] [content_filtering_publisher]: Publishing: '-80.000000' - [...] - -ContentFilteringSubscriber: - -https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_subscriber.cpp - -.. code-block:: c++ - - #include - #include - - #include "rclcpp/rclcpp.hpp" - #include "rclcpp_components/register_node_macro.hpp" - #include "rcpputils/join.hpp" - - #include "std_msgs/msg/float32.hpp" - - #include "demo_nodes_cpp/visibility_control.h" - - namespace demo_nodes_cpp - { - // Emergency temperature data less than -30 or greater than 100 - constexpr std::array EMERGENCY_TEMPERATURE {-30.0f, 100.0f}; - - // Create a ContentFilteringSubscriber class that subclasses the generic rclcpp::Node base class. - // The main function below will instantiate the class as a ROS node. - class ContentFilteringSubscriber : public rclcpp::Node - { - public: - DEMO_NODES_CPP_PUBLIC - explicit ContentFilteringSubscriber(const rclcpp::NodeOptions & options) - : Node("content_filtering_subscriber", options) - { - // Create a callback function for when messages are received. - auto callback = - [this](const std_msgs::msg::Float32 & msg) -> void - { - if (msg.data < EMERGENCY_TEMPERATURE[0] || msg.data > EMERGENCY_TEMPERATURE[1]) { - RCLCPP_INFO( - this->get_logger(), - "I receive an emergency temperature data: [%f]", msg.data); - } else { - RCLCPP_INFO(this->get_logger(), "I receive a temperature data: [%f]", msg.data); - } - }; - - // Initialize a subscription with a content filter to receive emergency temperature data that - // are less than -30 or greater than 100. - rclcpp::SubscriptionOptions sub_options; - sub_options.content_filter_options.filter_expression = "data < %0 OR data > %1"; - sub_options.content_filter_options.expression_parameters = { - std::to_string(EMERGENCY_TEMPERATURE[0]), - std::to_string(EMERGENCY_TEMPERATURE[1]) - }; - - sub_ = create_subscription("temperature", 10, callback, sub_options); - - if (!sub_->is_cft_enabled()) { - RCLCPP_WARN( - this->get_logger(), "Content filter is not enabled since it's not supported"); - } else { - RCLCPP_INFO( - this->get_logger(), - "subscribed to topic \"%s\" with content filter options \"%s, {%s}\"", - sub_->get_topic_name(), - sub_options.content_filter_options.filter_expression.c_str(), - rcpputils::join(sub_options.content_filter_options.expression_parameters, ", ").c_str()); - } - } - - private: - rclcpp::Subscription::SharedPtr sub_; - }; - - } // namespace demo_nodes_cpp - -To enable content filtering, applications can set the filtering expression and the expression parameters in ``SubscriptionOptions``. -The application can also check if content filtering is enabled on the subscription. - -In this demo, the ``ContentFilteringSubscriber`` node creates a content filtering subscription that receives a message only if the temperature value is less than -30.0 or greater than 100.0. - -As commented before, content filtering subscription support depends on the RMW implementation. -Applications can use the ``is_cft_enabled`` method to check if content filtering is actually enabled on the subscription. - -To test content filtering subscription, let's run it: - -.. code-block:: console - - $ ros2 run demo_nodes_cpp content_filtering_subscriber - [INFO] [1651094590.682660703] [content_filtering_subscriber]: subscribed to topic "/temperature" with content filter options "data < %0 OR data > %1, {-30.000000, 100.000000}" - [INFO] [1651094594.823805294] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] - [INFO] [1651094595.823419993] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] - [INFO] [1651094596.823410859] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] - [INFO] [1651094597.823350377] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] - [INFO] [1651094598.823282657] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] - [INFO] [1651094599.823297857] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] - [INFO] [1651094600.823355597] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] - [INFO] [1651094615.823315377] [content_filtering_subscriber]: I receive an emergency temperature data: [110.000000] - [INFO] [1651094616.823258458] [content_filtering_subscriber]: I receive an emergency temperature data: [120.000000] - [INFO] [1651094617.823323525] [content_filtering_subscriber]: I receive an emergency temperature data: [130.000000] - [INFO] [1651094618.823315527] [content_filtering_subscriber]: I receive an emergency temperature data: [140.000000] - [INFO] [1651094619.823331424] [content_filtering_subscriber]: I receive an emergency temperature data: [150.000000] - [INFO] [1651094620.823271748] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] - [INFO] [1651094621.823343550] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] - [INFO] [1651094622.823286326] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] - [INFO] [1651094623.823371031] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] - [INFO] [1651094624.823333112] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] - [INFO] [1651094625.823266469] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] - [INFO] [1651094626.823284093] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] - -You should see a message showing the content filtering options used and logs for each message received only if the temperature value is less than -30.0 or greater than 100.0. - -If content filtering is not supported by the RMW implementation, the subscription will still be created without content filtering enabled. -We can try that by executing ``RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_publisher``. - -.. code-block:: console - - $ RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_subscriber - [WARN] [1651096637.893842072] [content_filtering_subscriber]: Content filter is not enabled since it is not supported - [INFO] [1651096641.246043703] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] - [INFO] [1651096642.245833527] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] - [INFO] [1651096643.245743471] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] - [INFO] [1651096644.245833932] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] - [INFO] [1651096645.245916679] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] - [INFO] [1651096646.245861895] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] - [INFO] [1651096647.245946352] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] - [INFO] [1651096648.245934569] [content_filtering_subscriber]: I receive a temperature data: [-30.000000] - [INFO] [1651096649.245877906] [content_filtering_subscriber]: I receive a temperature data: [-20.000000] - [INFO] [1651096650.245939068] [content_filtering_subscriber]: I receive a temperature data: [-10.000000] - [INFO] [1651096651.245911450] [content_filtering_subscriber]: I receive a temperature data: [0.000000] - [INFO] [1651096652.245879830] [content_filtering_subscriber]: I receive a temperature data: [10.000000] - [INFO] [1651096653.245858329] [content_filtering_subscriber]: I receive a temperature data: [20.000000] - [INFO] [1651096654.245916370] [content_filtering_subscriber]: I receive a temperature data: [30.000000] - [INFO] [1651096655.245933741] [content_filtering_subscriber]: I receive a temperature data: [40.000000] - [INFO] [1651096656.245833975] [content_filtering_subscriber]: I receive a temperature data: [50.000000] - [INFO] [1651096657.245971483] [content_filtering_subscriber]: I receive a temperature data: [60.000000] - -You can see the message ``Content filter is not enabled`` because underlying RMW implementation does not support the feature, but the demo still successfully creates the normal subscription to receive all temperature data. - -Related content ---------------- - -- `content filtering examples `__ that covers all interfaces for content filtering subscription. +.. redirect-from:: + + Tutorials/Content-Filtering-Subscription + Tutorials/Demos/Content-Filtering-Subscription + +Creating a content filtering subscription +========================================= + +**Goal:** Create a content filtering subscription. + +**Tutorial level:** Advanced + +**Time:** 15 minutes + +.. contents:: Table of Contents + :depth: 1 + :local: + +Overview +-------- + +ROS 2 applications typically consist of topics to transmit data from publishers to subscriptions. +Basically, subscriptions receive all published data from publishers on the topic. +But sometimes, a subscription might be interested in only a subset of the data which is being sent by publishers. +A content filtering subscription allows to receive only the data of interest for the application. + +In this demo, we'll be highlighting how to create a content filtering subscription and how they work. + +RMW Support +----------- + +Content filtering subscriptions require RMW implementation support. + +.. list-table:: Content-Filtering-Subscription Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + * - rmw_zenoh_cpp + - not supported + +Currently all RMW implementations that support content filtering subscriptions are `DDS `__ based. +That means that the supported filtering expressions and parameters are also dependent on `DDS `__, you can refer to `DDS specification `__ ``Annex B - Syntax for Queries and Filters`` for details. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-demo-nodes-cpp`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Temperature filtering demo +-------------------------- + +This demo shows how a content filtering subscription can be used to only receive temperature values that are out of the acceptable temperature range, detecting emergencies. +The content filtering subscription filters out the uninteresting temperature data, so that the subscription callback is not issued. + +ContentFilteringPublisher: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_publisher.cpp + +.. code-block:: c++ + + #include + #include + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp_components/register_node_macro.hpp" + + #include "std_msgs/msg/float32.hpp" + + #include "demo_nodes_cpp/visibility_control.h" + + namespace demo_nodes_cpp + { + // The simulated temperature data starts from -100.0 and ends at 150.0 with a step size of 10.0 + constexpr std::array TEMPERATURE_SETTING {-100.0f, 150.0f, 10.0f}; + + // Create a ContentFilteringPublisher class that subclasses the generic rclcpp::Node base class. + // The main function below will instantiate the class as a ROS node. + class ContentFilteringPublisher final : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit ContentFilteringPublisher(const rclcpp::NodeOptions & options) + : Node("content_filtering_publisher", options) + { + // Create a function for when messages are to be sent. + auto publish_message = + [this]() -> void + { + msg_ = std::make_unique(); + msg_->data = temperature_; + temperature_ += TEMPERATURE_SETTING[2]; + if (temperature_ > TEMPERATURE_SETTING[1]) { + temperature_ = TEMPERATURE_SETTING[0]; + } + RCLCPP_INFO(this->get_logger(), "Publishing: '%f'", msg_->data); + // Put the message into a queue to be processed by the middleware. + // This call is non-blocking. + pub_->publish(std::move(msg_)); + }; + // Create a publisher with a custom Quality of Service profile. + // Uniform initialization is suggested so it can be trivially changed to + // rclcpp::KeepAll{} if the user wishes. + // (rclcpp::KeepLast(7) -> rclcpp::KeepAll() fails to compile) + rclcpp::QoS qos(rclcpp::KeepLast{7}); + pub_ = this->create_publisher("temperature", qos); + + int64_t publish_ms = this->declare_parameter("publish_ms", 1000); + + // Use a timer to schedule periodic message publishing. + timer_ = this->create_wall_timer(std::chrono::milliseconds(publish_ms), publish_message); + } + + private: + float temperature_ = TEMPERATURE_SETTING[0]; + std::unique_ptr msg_; + rclcpp::Publisher::SharedPtr pub_; + rclcpp::TimerBase::SharedPtr timer_; + }; + + } // namespace demo_nodes_cpp + +The content filter is defined in the subscription side, publishers don't need to be configured in any special way to allow content filtering. +The ``ContentFilteringPublisher`` node publishes simulated temperature data starting from -100.0 and ending at 150.0 with a step size of 10.0 every second. + +We can run the demo by running the ``ros2 run demo_nodes_cpp content_filtering_publisher`` executable (don't forget to source the setup file first): + +.. code-block:: console + + $ ros2 run demo_nodes_cpp content_filtering_publisher + [INFO] [1651094594.822753479] [content_filtering_publisher]: Publishing: '-100.000000' + [INFO] [1651094595.822723857] [content_filtering_publisher]: Publishing: '-90.000000' + [INFO] [1651094596.822752996] [content_filtering_publisher]: Publishing: '-80.000000' + [INFO] [1651094597.822752475] [content_filtering_publisher]: Publishing: '-70.000000' + [INFO] [1651094598.822721485] [content_filtering_publisher]: Publishing: '-60.000000' + [INFO] [1651094599.822696188] [content_filtering_publisher]: Publishing: '-50.000000' + [INFO] [1651094600.822699217] [content_filtering_publisher]: Publishing: '-40.000000' + [INFO] [1651094601.822744113] [content_filtering_publisher]: Publishing: '-30.000000' + [INFO] [1651094602.822694805] [content_filtering_publisher]: Publishing: '-20.000000' + [INFO] [1651094603.822735805] [content_filtering_publisher]: Publishing: '-10.000000' + [INFO] [1651094604.822722094] [content_filtering_publisher]: Publishing: '0.000000' + [INFO] [1651094605.822699960] [content_filtering_publisher]: Publishing: '10.000000' + [INFO] [1651094606.822748946] [content_filtering_publisher]: Publishing: '20.000000' + [INFO] [1651094607.822694017] [content_filtering_publisher]: Publishing: '30.000000' + [INFO] [1651094608.822708798] [content_filtering_publisher]: Publishing: '40.000000' + [INFO] [1651094609.822692417] [content_filtering_publisher]: Publishing: '50.000000' + [INFO] [1651094610.822696426] [content_filtering_publisher]: Publishing: '60.000000' + [INFO] [1651094611.822751913] [content_filtering_publisher]: Publishing: '70.000000' + [INFO] [1651094612.822692231] [content_filtering_publisher]: Publishing: '80.000000' + [INFO] [1651094613.822745549] [content_filtering_publisher]: Publishing: '90.000000' + [INFO] [1651094614.822701982] [content_filtering_publisher]: Publishing: '100.000000' + [INFO] [1651094615.822691465] [content_filtering_publisher]: Publishing: '110.000000' + [INFO] [1651094616.822649070] [content_filtering_publisher]: Publishing: '120.000000' + [INFO] [1651094617.822693616] [content_filtering_publisher]: Publishing: '130.000000' + [INFO] [1651094618.822691832] [content_filtering_publisher]: Publishing: '140.000000' + [INFO] [1651094619.822688452] [content_filtering_publisher]: Publishing: '150.000000' + [INFO] [1651094620.822645327] [content_filtering_publisher]: Publishing: '-100.000000' + [INFO] [1651094621.822689219] [content_filtering_publisher]: Publishing: '-90.000000' + [INFO] [1651094622.822694292] [content_filtering_publisher]: Publishing: '-80.000000' + [...] + +ContentFilteringSubscriber: + +https://github.com/ros2/demos/blob/{REPOS_FILE_BRANCH}/demo_nodes_cpp/src/topics/content_filtering_subscriber.cpp + +.. code-block:: c++ + + #include + #include + + #include "rclcpp/rclcpp.hpp" + #include "rclcpp_components/register_node_macro.hpp" + #include "rcpputils/join.hpp" + + #include "std_msgs/msg/float32.hpp" + + #include "demo_nodes_cpp/visibility_control.h" + + namespace demo_nodes_cpp + { + // Emergency temperature data less than -30 or greater than 100 + constexpr std::array EMERGENCY_TEMPERATURE {-30.0f, 100.0f}; + + // Create a ContentFilteringSubscriber class that subclasses the generic rclcpp::Node base class. + // The main function below will instantiate the class as a ROS node. + class ContentFilteringSubscriber : public rclcpp::Node + { + public: + DEMO_NODES_CPP_PUBLIC + explicit ContentFilteringSubscriber(const rclcpp::NodeOptions & options) + : Node("content_filtering_subscriber", options) + { + // Create a callback function for when messages are received. + auto callback = + [this](const std_msgs::msg::Float32 & msg) -> void + { + if (msg.data < EMERGENCY_TEMPERATURE[0] || msg.data > EMERGENCY_TEMPERATURE[1]) { + RCLCPP_INFO( + this->get_logger(), + "I receive an emergency temperature data: [%f]", msg.data); + } else { + RCLCPP_INFO(this->get_logger(), "I receive a temperature data: [%f]", msg.data); + } + }; + + // Initialize a subscription with a content filter to receive emergency temperature data that + // are less than -30 or greater than 100. + rclcpp::SubscriptionOptions sub_options; + sub_options.content_filter_options.filter_expression = "data < %0 OR data > %1"; + sub_options.content_filter_options.expression_parameters = { + std::to_string(EMERGENCY_TEMPERATURE[0]), + std::to_string(EMERGENCY_TEMPERATURE[1]) + }; + + sub_ = create_subscription("temperature", 10, callback, sub_options); + + if (!sub_->is_cft_enabled()) { + RCLCPP_WARN( + this->get_logger(), "Content filter is not enabled since it's not supported"); + } else { + RCLCPP_INFO( + this->get_logger(), + "subscribed to topic \"%s\" with content filter options \"%s, {%s}\"", + sub_->get_topic_name(), + sub_options.content_filter_options.filter_expression.c_str(), + rcpputils::join(sub_options.content_filter_options.expression_parameters, ", ").c_str()); + } + } + + private: + rclcpp::Subscription::SharedPtr sub_; + }; + + } // namespace demo_nodes_cpp + +To enable content filtering, applications can set the filtering expression and the expression parameters in ``SubscriptionOptions``. +The application can also check if content filtering is enabled on the subscription. + +In this demo, the ``ContentFilteringSubscriber`` node creates a content filtering subscription that receives a message only if the temperature value is less than -30.0 or greater than 100.0. + +As commented before, content filtering subscription support depends on the RMW implementation. +Applications can use the ``is_cft_enabled`` method to check if content filtering is actually enabled on the subscription. + +To test content filtering subscription, let's run it: + +.. code-block:: console + + $ ros2 run demo_nodes_cpp content_filtering_subscriber + [INFO] [1651094590.682660703] [content_filtering_subscriber]: subscribed to topic "/temperature" with content filter options "data < %0 OR data > %1, {-30.000000, 100.000000}" + [INFO] [1651094594.823805294] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] + [INFO] [1651094595.823419993] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] + [INFO] [1651094596.823410859] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] + [INFO] [1651094597.823350377] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] + [INFO] [1651094598.823282657] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] + [INFO] [1651094599.823297857] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] + [INFO] [1651094600.823355597] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] + [INFO] [1651094615.823315377] [content_filtering_subscriber]: I receive an emergency temperature data: [110.000000] + [INFO] [1651094616.823258458] [content_filtering_subscriber]: I receive an emergency temperature data: [120.000000] + [INFO] [1651094617.823323525] [content_filtering_subscriber]: I receive an emergency temperature data: [130.000000] + [INFO] [1651094618.823315527] [content_filtering_subscriber]: I receive an emergency temperature data: [140.000000] + [INFO] [1651094619.823331424] [content_filtering_subscriber]: I receive an emergency temperature data: [150.000000] + [INFO] [1651094620.823271748] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] + [INFO] [1651094621.823343550] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] + [INFO] [1651094622.823286326] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] + [INFO] [1651094623.823371031] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] + [INFO] [1651094624.823333112] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] + [INFO] [1651094625.823266469] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] + [INFO] [1651094626.823284093] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] + +You should see a message showing the content filtering options used and logs for each message received only if the temperature value is less than -30.0 or greater than 100.0. + +If content filtering is not supported by the RMW implementation, the subscription will still be created without content filtering enabled. +We can try that by executing ``RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_publisher``. + +.. code-block:: console + + $ RMW_IMPLEMENTATION=rmw_cyclonedds_cpp ros2 run demo_nodes_cpp content_filtering_subscriber + [WARN] [1651096637.893842072] [content_filtering_subscriber]: Content filter is not enabled since it is not supported + [INFO] [1651096641.246043703] [content_filtering_subscriber]: I receive an emergency temperature data: [-100.000000] + [INFO] [1651096642.245833527] [content_filtering_subscriber]: I receive an emergency temperature data: [-90.000000] + [INFO] [1651096643.245743471] [content_filtering_subscriber]: I receive an emergency temperature data: [-80.000000] + [INFO] [1651096644.245833932] [content_filtering_subscriber]: I receive an emergency temperature data: [-70.000000] + [INFO] [1651096645.245916679] [content_filtering_subscriber]: I receive an emergency temperature data: [-60.000000] + [INFO] [1651096646.245861895] [content_filtering_subscriber]: I receive an emergency temperature data: [-50.000000] + [INFO] [1651096647.245946352] [content_filtering_subscriber]: I receive an emergency temperature data: [-40.000000] + [INFO] [1651096648.245934569] [content_filtering_subscriber]: I receive a temperature data: [-30.000000] + [INFO] [1651096649.245877906] [content_filtering_subscriber]: I receive a temperature data: [-20.000000] + [INFO] [1651096650.245939068] [content_filtering_subscriber]: I receive a temperature data: [-10.000000] + [INFO] [1651096651.245911450] [content_filtering_subscriber]: I receive a temperature data: [0.000000] + [INFO] [1651096652.245879830] [content_filtering_subscriber]: I receive a temperature data: [10.000000] + [INFO] [1651096653.245858329] [content_filtering_subscriber]: I receive a temperature data: [20.000000] + [INFO] [1651096654.245916370] [content_filtering_subscriber]: I receive a temperature data: [30.000000] + [INFO] [1651096655.245933741] [content_filtering_subscriber]: I receive a temperature data: [40.000000] + [INFO] [1651096656.245833975] [content_filtering_subscriber]: I receive a temperature data: [50.000000] + [INFO] [1651096657.245971483] [content_filtering_subscriber]: I receive a temperature data: [60.000000] + +You can see the message ``Content filter is not enabled`` because underlying RMW implementation does not support the feature, but the demo still successfully creates the normal subscription to receive all temperature data. + +Related content +--------------- + +- `content filtering examples `__ that covers all interfaces for content filtering subscription. - `content filtering design PR `__ \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst similarity index 96% rename from source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst index 30d72988dcf..b68fb865827 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Quality-of-Service.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst @@ -1,188 +1,188 @@ -.. redirect-from:: - - Quality-of-Service - Tutorials/Quality-of-Service - Tutorials/Demos/Quality-of-Service - -Using quality-of-service settings for lossy networks -==================================================== - -.. contents:: Table of Contents - :depth: 2 - :local: - -Background ----------- - -Please read the documentation page `about QoS settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>` for background information on available support in ROS 2. - -In this demo, we will spawn a node that publishes a camera image and another that subscribes to the image and shows it on the screen. -We will then simulate a lossy network connection between them and show how different quality of service settings handle the bad link. - - -Prerequisites -------------- -This tutorial assumes you have a :doc:`working ROS 2 installation <../../../Get-Started/Installation>` and OpenCV. -See the `OpenCV documentation `__ for its installation instructions. -You will also need the ROS package ``image_tools``. - -.. tabs:: - - .. group-tab:: Linux Binaries - - .. code-block:: console - - $ sudo apt-get install ros-{DISTRO}-image-tools - - .. group-tab:: From Source - - Clone and build the demos repo using the branch that matches your installation. - - .. code-block:: console - - $ git clone https://github.com/ros2/demos.git -b {REPOS_FILE_BRANCH} - - -Run the demo ------------- - -Before running the demo, make sure you have a working webcam connected to your computer. - -Once you've installed ROS 2, source your setup file: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ . /setup.bash - - .. group-tab:: macOS - - .. code-block:: console - - $ . /setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call /local_setup.bat - -Then run: - -.. code-block:: console - - $ ros2 run image_tools showimage - -Nothing will happen yet. -``showimage`` is a subscriber node that is waiting for a publisher on the ``image`` topic. - -Note: you have to close the ``showimage`` process with ``Ctrl-C`` later. -You can't just close the window. - -In a separate terminal, source the install file and run the publisher node: - -.. code-block:: console - - $ ros2 run image_tools cam2image - -This will publish an image from your webcam. -In case you don't have a camera attached to your computer, there is a commandline option which publishes predefined images. - - -.. code-block:: console - - $ ros2 run image_tools cam2image --ros-args -p burger_mode:=True - [INFO] [1715662452.055277255] [cam2image]: Publishing image #1 - [INFO] [1715662452.119336061] [cam2image]: Publishing image #2 - [INFO] [1715662452.187315139] [cam2image]: Publishing image #3 - ... - -A window will pop up with the title "view" showing your camera feed. -In the first window, you'll see output from the subscriber: - -.. code-block:: console - - [INFO] [1715662452.188906764] [showimage]: Received image #camera_frame - Received image #camera_frame - [INFO] [1715662452.252836919] [showimage]: Received image #camera_frame - Received image #camera_frame - [INFO] [1715662452.320878578] [showimage]: Received image #camera_frame - Received image #camera_frame - ... - -.. note:: - - macOS users: If these examples do not work or you receive an error like ``ddsi_conn_write failed -1`` then you'll need to increase your system wide UDP packet size: - - .. code-block:: console - - $ sudo sysctl -w net.inet.udp.recvspace=209715 - $ sudo sysctl -w net.inet.udp.maxdgram=65500 - - These changes will not persist a reboot. - If you want the changes to persist, add these lines to ``/etc/sysctl.conf`` (create the file if it doesn't exist already): - - .. code-block:: bash - - net.inet.udp.recvspace=209715 - net.inet.udp.maxdgram=65500 - -Command line options -^^^^^^^^^^^^^^^^^^^^ - -In one of your terminals, add a -h flag to the original command: - - -.. code-block:: console - - $ ros2 run image_tools showimage -h - - - -Add network traffic -^^^^^^^^^^^^^^^^^^^ - -.. warning:: - - This section of the demo won't work on RTI's Connext DDS and Fast-DDS. - When running multiple nodes in the same host, those DDS implementations use shared memory along with the loopback interface. - Degrading the loopback interface throughput won't affect shared memory, thus traffic between the two nodes won't be affected. - -.. note:: - - This next section is Linux-specific. - - However, for macOS and Windows you can achieve a similar effect with the utilities "Network Link Conditioner" (part of the xcode tool suite) and `"Clumsy" `_, respectively, but they will not be covered in this tutorial. - -We are going to use the Linux network traffic control utility, ``tc`` (`man page `_) . - -.. code-block:: console - - $ sudo tc qdisc add dev lo root netem loss 5% - -This magical incantation will simulate 5% packet loss over the local loopback device. -If you use a higher resolution of the images (e.g. ``--ros-args -p width:=640 -p height:=480``) you might want to try a lower packet loss rate (e.g. ``1%``). - -Next we start the ``cam2image`` and ``showimage``, and we'll soon notice that both programs seem to have slowed down the rate at which images are transmitted. -This is caused by the behavior of the default QoS settings. -Enforcing reliability on a lossy channel means that the publisher (in this case, ``cam2image``) will resend the network packets until it receives acknowledgement from the consumer (i.e. ``showimage``). - -Let's now try running both programs, but with more suitable settings. -First of all, we'll use the ``-p reliability:=best_effort`` option to enable best effort communication. -The publisher will now just attempt to deliver the network packets, and don't expect acknowledgement from the consumer. -We see now that some of the frames on the ``showimage`` side were dropped, so the frame numbers in the shell running ``showimage`` won't be consecutive anymore: - - -.. image:: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png - :target: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png - :alt: Best effort image transfer - - -When you're done, remember to delete the queueing discipline: - -.. code-block:: console - +.. redirect-from:: + + Quality-of-Service + Tutorials/Quality-of-Service + Tutorials/Demos/Quality-of-Service + +Using quality-of-service settings for lossy networks +==================================================== + +.. contents:: Table of Contents + :depth: 2 + :local: + +Background +---------- + +Please read the documentation page `about QoS settings <../../Concepts/Intermediate/About-Quality-of-Service-Settings>` for background information on available support in ROS 2. + +In this demo, we will spawn a node that publishes a camera image and another that subscribes to the image and shows it on the screen. +We will then simulate a lossy network connection between them and show how different quality of service settings handle the bad link. + + +Prerequisites +------------- +This tutorial assumes you have a :doc:`working ROS 2 installation <../../../../Get-Started/Installation>` and OpenCV. +See the `OpenCV documentation `__ for its installation instructions. +You will also need the ROS package ``image_tools``. + +.. tabs:: + + .. group-tab:: Linux Binaries + + .. code-block:: console + + $ sudo apt-get install ros-{DISTRO}-image-tools + + .. group-tab:: From Source + + Clone and build the demos repo using the branch that matches your installation. + + .. code-block:: console + + $ git clone https://github.com/ros2/demos.git -b {REPOS_FILE_BRANCH} + + +Run the demo +------------ + +Before running the demo, make sure you have a working webcam connected to your computer. + +Once you've installed ROS 2, source your setup file: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ . /setup.bash + + .. group-tab:: macOS + + .. code-block:: console + + $ . /setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call /local_setup.bat + +Then run: + +.. code-block:: console + + $ ros2 run image_tools showimage + +Nothing will happen yet. +``showimage`` is a subscriber node that is waiting for a publisher on the ``image`` topic. + +Note: you have to close the ``showimage`` process with ``Ctrl-C`` later. +You can't just close the window. + +In a separate terminal, source the install file and run the publisher node: + +.. code-block:: console + + $ ros2 run image_tools cam2image + +This will publish an image from your webcam. +In case you don't have a camera attached to your computer, there is a commandline option which publishes predefined images. + + +.. code-block:: console + + $ ros2 run image_tools cam2image --ros-args -p burger_mode:=True + [INFO] [1715662452.055277255] [cam2image]: Publishing image #1 + [INFO] [1715662452.119336061] [cam2image]: Publishing image #2 + [INFO] [1715662452.187315139] [cam2image]: Publishing image #3 + ... + +A window will pop up with the title "view" showing your camera feed. +In the first window, you'll see output from the subscriber: + +.. code-block:: console + + [INFO] [1715662452.188906764] [showimage]: Received image #camera_frame + Received image #camera_frame + [INFO] [1715662452.252836919] [showimage]: Received image #camera_frame + Received image #camera_frame + [INFO] [1715662452.320878578] [showimage]: Received image #camera_frame + Received image #camera_frame + ... + +.. note:: + + macOS users: If these examples do not work or you receive an error like ``ddsi_conn_write failed -1`` then you'll need to increase your system wide UDP packet size: + + .. code-block:: console + + $ sudo sysctl -w net.inet.udp.recvspace=209715 + $ sudo sysctl -w net.inet.udp.maxdgram=65500 + + These changes will not persist a reboot. + If you want the changes to persist, add these lines to ``/etc/sysctl.conf`` (create the file if it doesn't exist already): + + .. code-block:: bash + + net.inet.udp.recvspace=209715 + net.inet.udp.maxdgram=65500 + +Command line options +^^^^^^^^^^^^^^^^^^^^ + +In one of your terminals, add a -h flag to the original command: + + +.. code-block:: console + + $ ros2 run image_tools showimage -h + + + +Add network traffic +^^^^^^^^^^^^^^^^^^^ + +.. warning:: + + This section of the demo won't work on RTI's Connext DDS and Fast-DDS. + When running multiple nodes in the same host, those DDS implementations use shared memory along with the loopback interface. + Degrading the loopback interface throughput won't affect shared memory, thus traffic between the two nodes won't be affected. + +.. note:: + + This next section is Linux-specific. + + However, for macOS and Windows you can achieve a similar effect with the utilities "Network Link Conditioner" (part of the xcode tool suite) and `"Clumsy" `_, respectively, but they will not be covered in this tutorial. + +We are going to use the Linux network traffic control utility, ``tc`` (`man page `_) . + +.. code-block:: console + + $ sudo tc qdisc add dev lo root netem loss 5% + +This magical incantation will simulate 5% packet loss over the local loopback device. +If you use a higher resolution of the images (e.g. ``--ros-args -p width:=640 -p height:=480``) you might want to try a lower packet loss rate (e.g. ``1%``). + +Next we start the ``cam2image`` and ``showimage``, and we'll soon notice that both programs seem to have slowed down the rate at which images are transmitted. +This is caused by the behavior of the default QoS settings. +Enforcing reliability on a lossy channel means that the publisher (in this case, ``cam2image``) will resend the network packets until it receives acknowledgement from the consumer (i.e. ``showimage``). + +Let's now try running both programs, but with more suitable settings. +First of all, we'll use the ``-p reliability:=best_effort`` option to enable best effort communication. +The publisher will now just attempt to deliver the network packets, and don't expect acknowledgement from the consumer. +We see now that some of the frames on the ``showimage`` side were dropped, so the frame numbers in the shell running ``showimage`` won't be consecutive anymore: + + +.. image:: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png + :target: https://raw.githubusercontent.com/ros2/demos/{REPOS_FILE_BRANCH}/image_tools/doc/qos-best-effort.png + :alt: Best effort image transfer + + +When you're done, remember to delete the queueing discipline: + +.. code-block:: console + $ sudo tc qdisc delete dev lo root netem loss 5% \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst similarity index 97% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst index b387f47129c..0cd6ecd7509 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst @@ -1,389 +1,389 @@ -.. redirect-from:: - - Tutorials/Advanced/Topic-Keys/Filtered-Topic-Keys-Tutorial - -.. _filtered_topic_keys_tutorial: - -Topic Keys Subscription Filtering Tutorial -========================================== - -This tutorial aims to demonstrate how to receive data only from certain topic instances by combining the use of topic keys and topic content filtering. - -.. contents:: - :depth: 2 - :local: - :backlinks: none - -Background ----------- - -In ROS 2, topics are a mean for representing the state of an object. -Keyed topics are special topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. -This allows the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. - -The :doc:`Content Filter Topic <../Content-Filtering-Subscription>` facilitates efficient data distribution by allowing the subscription (reader-side) to specify criteria for the types of data they wish to receive. -By defining this criteria, irrelevant data can be filtered out and applications can focus only on the information that is relevant to their needs. -This functionality not only reduces the amount of data transmitted over the network but also minimizes processing overhead on the receiving end, leading to improved system performance and scalability. - -When combined with topic instances, the benefits of the Content Filter are further enhanced. -By associating specific filter criteria with each topic instance, it is possible fine-tune the data selection process and tailor it to their precise requirements. -This granular level of filtering enables applications to optimally manage data while ensuring that they exchange only the information that is pertinent to their individual use cases. - -.. image:: figures/keyed-topics-cft.gif - :align: center - :width: 70% - -RMW Support ------------ - -Keyed topics require RMW implementation support. - -.. list-table:: Keyed Topics Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - -Implementations not supporting the feature will treat keyed topics as standard topics. -The implications are explained throughout the tutorial. -In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. - -Prerequisites -------------- - -* An up-to-date ROS 2 installation and setup. - Either installed in local host, or using Docker images. - -Preparing the demo package --------------------------- - -Lets start by setting up the ROS 2 environment. -For this, there are two possible options: - -#. Running a ROS 2 Docker image. - - .. code-block:: console - - $ docker run -it --rm osrt/ros:{DISTRO}-desktop - -#. Running the tutorial on the local host. - Please, follow the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. - -Source the following file to setup the ROS 2 environment: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - - -Retrieving the sources -^^^^^^^^^^^^^^^^^^^^^^ - -Create a new workspace and download the demo package sources as indicated below: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg - $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp - $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py - - .. group-tab:: macOS - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg - $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp - $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py - - .. group-tab:: Windows - - .. code-block:: console - - # Create directory structure - $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\msg - $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\src - $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\launch - $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp - - # Download demo package source code - $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt - $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml - $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md - $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg - $ irm -OutFile src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp - $ irm -OutFile src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp - $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py - -The resulting directory structure should be: - -.. code-block:: - - ~/tutorial_ws - ├──src - ├── demo_keys_filtering_cpp - ├── CMakeLists.txt - ├── README.md - ├── launch - │ └── keyed_sensors_launch.py - ├── msg - │ └── KeyedSensorDataMsg.msg - ├── package.xml - └── src - ├── filtered_keyed_controller.cpp - └── filtered_keyed_sensor.cpp - -A brief analysis on the provided files is explained below: - -* *demo_keys_filtering_cpp* : This directory contains the main source code and configuration files for the demonstration. -* ``CMakeLists.txt``: This file is used with CMake to specify build configurations and dependencies. -* ``README.md``: This is a markdown file providing instructions or information about the demonstration. -* *launch*: This directory contains launch configuration files for launching ROS nodes. - - * ``keyed_sensors_launch.py``: This Python script is used to launch the demonstration nodes. - -* *msg*: This directory contains message definition files. - - * KeyedSensorDataMsg.msg: This is the file defining the message structure for keyed sensor data used in the tutorial. - -* ``package.xml``: This is an XML file containing metadata about the ROS package. -* *src*: This directory contains the source code files for the demonstration. - - * ``filtered_keyed_controller.cpp``: This is the source code for a controller node that filters keyed sensor data in reception, being the most relevant lines the ones that define the filter expression and Quality of Service settings: - - .. code-block:: cpp - - // Initialize a subscription with a content filter to receive data from sensors 2 to 4 - rclcpp::SubscriptionOptions sub_options; - sub_options.content_filter_options.filter_expression = - "sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0"; - sub_options.content_filter_options.expression_parameters = { - std::to_string(SENSOR_TRIGGER) - }; - - // Create the subscription with the content filter options - sub_ = create_subscription("/robot/sensors", - rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local(), - callback, - sub_options); - - * ``filtered_keyed_sensor.cpp``: This is the source code for a sensor node that publishes keyed sensor data. - The most relevant lines are the ones that create the publication with a particular Quality of Service settings that enables the controller to late join the application but still receiving the latest update for every instance with the use of topic keys. - - .. code-block:: cpp - - pub_ = this->create_publisher( - "/robot/sensors", - rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local()); - -Generating the IDL files -^^^^^^^^^^^^^^^^^^^^^^^^ - -Generate the corresponding IDL definition from the provided ``KeyedSensorDataMsg.msg`` file, using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm KeyedSensorDataMsg.msg - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm KeyedSensorDataMsg.msg - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp\msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ del KeyedSensorDataMsg.msg - -Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. -Its content should look like the following: - -.. code-block:: idl - - /* KeyedSensorDataMsg.idl */ - module demo_keys_filtering_cpp { - module msg { - struct KeyedSensorDataMsg { - @key int16 sensor_id; - double measurement; - string data; - }; - }; - }; - -Building the demo package -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Once the environment has been setup and the demo package sources are available, the demo package can be built. -Get into the root of the workspace and build it with the following commands: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws - $ colcon build - - -Running the demo ----------------- - -In the demo, different sensors are publishing data to a controller node using a keyed topic as exemplified below: - -.. image:: figures/cft_tutorial_diagram.svg - :align: center - :width: 80% - -Run the demo by executing the following commands in separate terminals: - -.. note:: - - If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. - This can be done by running ``docker exec -it /bin/bash``. - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller - -The resulting output should be similar to the following, in which the controller node is only receiving data from the specified sensors, i.e. sensors which sensor_id is in the range [2, 4]. -In addition, only when the measurement is greater than 60, the controller node will receive data. -That is specified in the filter expression ``sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0``: - -.. image:: figures/filtered_keyed_topic.gif - :align: center - :width: 100% - -Even in a late-joining scenario, the controller node will receive the latest data of the sensors that meet the filtering criteria at the moment it joins the application, which could be crucial depending on the type of the real application. - -Overall, the combination of topic instances with a content filter topic offers significant benefits in terms of data efficiency, scalability, adaptability and resource optimization. +.. redirect-from:: + + Tutorials/Advanced/Topic-Keys/Filtered-Topic-Keys-Tutorial + +.. _filtered_topic_keys_tutorial: + +Topic Keys Subscription Filtering Tutorial +========================================== + +This tutorial aims to demonstrate how to receive data only from certain topic instances by combining the use of topic keys and topic content filtering. + +.. contents:: + :depth: 2 + :local: + :backlinks: none + +Background +---------- + +In ROS 2, topics are a mean for representing the state of an object. +Keyed topics are special topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. +This allows the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. + +The :doc:`Content Filter Topic <../Content-Filtering-Subscription>` facilitates efficient data distribution by allowing the subscription (reader-side) to specify criteria for the types of data they wish to receive. +By defining this criteria, irrelevant data can be filtered out and applications can focus only on the information that is relevant to their needs. +This functionality not only reduces the amount of data transmitted over the network but also minimizes processing overhead on the receiving end, leading to improved system performance and scalability. + +When combined with topic instances, the benefits of the Content Filter are further enhanced. +By associating specific filter criteria with each topic instance, it is possible fine-tune the data selection process and tailor it to their precise requirements. +This granular level of filtering enables applications to optimally manage data while ensuring that they exchange only the information that is pertinent to their individual use cases. + +.. image:: figures/keyed-topics-cft.gif + :align: center + :width: 70% + +RMW Support +----------- + +Keyed topics require RMW implementation support. + +.. list-table:: Keyed Topics Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + +Implementations not supporting the feature will treat keyed topics as standard topics. +The implications are explained throughout the tutorial. +In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. + +Prerequisites +------------- + +* An up-to-date ROS 2 installation and setup. + Either installed in local host, or using Docker images. + +Preparing the demo package +-------------------------- + +Lets start by setting up the ROS 2 environment. +For this, there are two possible options: + +#. Running a ROS 2 Docker image. + + .. code-block:: console + + $ docker run -it --rm osrt/ros:{DISTRO}-desktop + +#. Running the tutorial on the local host. + Please, follow the :doc:`installation instructions <../../../../../Get-Started/Installation>` for details on installing ROS 2. + +Source the following file to setup the ROS 2 environment: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + + +Retrieving the sources +^^^^^^^^^^^^^^^^^^^^^^ + +Create a new workspace and download the demo package sources as indicated below: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg + $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp + $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py + + .. group-tab:: macOS + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_filtering_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_filtering_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg + $ wget -O src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp + $ wget -O src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py + + .. group-tab:: Windows + + .. code-block:: console + + # Create directory structure + $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\msg + $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\src + $ mkdir C:\tutorial_ws\src\demo_keys_filtering_cpp\launch + $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp + + # Download demo package source code + $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/CMakeLists.txt + $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/package.xml + $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/README.md + $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg + $ irm -OutFile src/filtered_keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp + $ irm -OutFile src/filtered_keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp + $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py + +The resulting directory structure should be: + +.. code-block:: + + ~/tutorial_ws + ├──src + ├── demo_keys_filtering_cpp + ├── CMakeLists.txt + ├── README.md + ├── launch + │ └── keyed_sensors_launch.py + ├── msg + │ └── KeyedSensorDataMsg.msg + ├── package.xml + └── src + ├── filtered_keyed_controller.cpp + └── filtered_keyed_sensor.cpp + +A brief analysis on the provided files is explained below: + +* *demo_keys_filtering_cpp* : This directory contains the main source code and configuration files for the demonstration. +* ``CMakeLists.txt``: This file is used with CMake to specify build configurations and dependencies. +* ``README.md``: This is a markdown file providing instructions or information about the demonstration. +* *launch*: This directory contains launch configuration files for launching ROS nodes. + + * ``keyed_sensors_launch.py``: This Python script is used to launch the demonstration nodes. + +* *msg*: This directory contains message definition files. + + * KeyedSensorDataMsg.msg: This is the file defining the message structure for keyed sensor data used in the tutorial. + +* ``package.xml``: This is an XML file containing metadata about the ROS package. +* *src*: This directory contains the source code files for the demonstration. + + * ``filtered_keyed_controller.cpp``: This is the source code for a controller node that filters keyed sensor data in reception, being the most relevant lines the ones that define the filter expression and Quality of Service settings: + + .. code-block:: cpp + + // Initialize a subscription with a content filter to receive data from sensors 2 to 4 + rclcpp::SubscriptionOptions sub_options; + sub_options.content_filter_options.filter_expression = + "sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0"; + sub_options.content_filter_options.expression_parameters = { + std::to_string(SENSOR_TRIGGER) + }; + + // Create the subscription with the content filter options + sub_ = create_subscription("/robot/sensors", + rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local(), + callback, + sub_options); + + * ``filtered_keyed_sensor.cpp``: This is the source code for a sensor node that publishes keyed sensor data. + The most relevant lines are the ones that create the publication with a particular Quality of Service settings that enables the controller to late join the application but still receiving the latest update for every instance with the use of topic keys. + + .. code-block:: cpp + + pub_ = this->create_publisher( + "/robot/sensors", + rclcpp::QoS(rclcpp::KeepLast(1)).reliable().transient_local()); + +Generating the IDL files +^^^^^^^^^^^^^^^^^^^^^^^^ + +Generate the corresponding IDL definition from the provided ``KeyedSensorDataMsg.msg`` file, using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm KeyedSensorDataMsg.msg + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_filtering_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm KeyedSensorDataMsg.msg + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws\src\demo_keys_filtering_cpp\msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ del KeyedSensorDataMsg.msg + +Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. +Its content should look like the following: + +.. code-block:: idl + + /* KeyedSensorDataMsg.idl */ + module demo_keys_filtering_cpp { + module msg { + struct KeyedSensorDataMsg { + @key int16 sensor_id; + double measurement; + string data; + }; + }; + }; + +Building the demo package +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Once the environment has been setup and the demo package sources are available, the demo package can be built. +Get into the root of the workspace and build it with the following commands: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws + $ colcon build + + +Running the demo +---------------- + +In the demo, different sensors are publishing data to a controller node using a keyed topic as exemplified below: + +.. image:: figures/cft_tutorial_diagram.svg + :align: center + :width: 80% + +Run the demo by executing the following commands in separate terminals: + +.. note:: + + If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. + This can be done by running ``docker exec -it /bin/bash``. + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_filtering_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 run demo_keys_filtering_cpp filtered_keyed_controller + +The resulting output should be similar to the following, in which the controller node is only receiving data from the specified sensors, i.e. sensors which sensor_id is in the range [2, 4]. +In addition, only when the measurement is greater than 60, the controller node will receive data. +That is specified in the filter expression ``sensor_id >= 2 AND sensor_id <= 4 AND measurement > %0``: + +.. image:: figures/filtered_keyed_topic.gif + :align: center + :width: 100% + +Even in a late-joining scenario, the controller node will receive the latest data of the sensors that meet the filtering criteria at the moment it joins the application, which could be crucial depending on the type of the real application. + +Overall, the combination of topic instances with a content filter topic offers significant benefits in terms of data efficiency, scalability, adaptability and resource optimization. By leveraging these capabilities, ROS 2 applications can efficiently manage and distribute data in complex distributed environments. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst similarity index 97% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst index 8d7aaf8083f..13eef26ab4e 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst @@ -1,586 +1,586 @@ -.. redirect-from:: - - Tutorials/Advanced/Topic-Keys/Topic-Keys-Tutorial - -.. _topic_keys_tutorial: - -Topic Keys Tutorial -=================== - -This tutorial aims to demonstrate the use of topic keys by simulating a scenario in which multiple sensors are transmitting their readings to a controller that processes them. - -.. contents:: - :depth: 2 - :local: - :backlinks: none - -Background ----------- - -In ROS 2, a :doc:`Topic <../../../About-Topics>` is a communication channel used for publishing and subscribing to updates of object states. -The value of data associated with a topic changes over time and each of these values are known as *data samples*. -Keyed topics refer to topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. - -Unlike standard topics, where each data sample updates the entire object state with every data sample, keyed topics allow the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. - -.. image:: figures/keyed-topics.gif - :align: center - :width: 70% - -RMW Support ------------ - -Keyed topics require RMW implementation support. - -.. list-table:: Keyed Topics Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - not supported - -Implementations not supporting the feature will treat keyed topics as standard topics. -The implications are explained throughout the tutorial. -In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. - -Creating custom IDL messages -^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -ROS 2 users can define their own :ref:`custom topic messages` in the ``.msg`` format. -Then, the ROS 2 message generation stack translates it to the DDS native `OMG IDL (Interface Definition Language) `_ message format. - -One of the advantages of defining messages in IDL is the ability to use annotations. -Annotations are metadata to the data structure definition that provide additional information about IDL constructs such as modules, interfaces, operations, attributes, and data types. -They are relevant for code generation, documentation, or other purposes. -Annotations in IDL typically follow the ``@`` symbol and can be applied to various IDL constructs. -The ``@key`` annotation is used to designate a member as key, which is covered in the following section. - -Users can define their own messages in the IDL format directly (following the `ROS 2 interface design documentation `_) or use the ``msg2idl`` tool within the ``rosidl_adapter`` package. - -Creating Keyed Messages -^^^^^^^^^^^^^^^^^^^^^^^ - -Keyed topics exist when one or more fields in the data structure are annotated as keys. -These key fields serve as unique identifiers for topic instances in order to organize and manage the data samples, facilitating efficient access, retrieval, and filtering of data based on the specified key criteria. - -The ``@key`` annotation designates a field as a key for the given topic type, which can have zero or more key fields and can be applied to structure fields of various types: - -* Any primitive, such as booleans, integers, characters, strings or sequences. -* Other existing or defined messages. - If those have defined an inner key member, then those fields will we used as part of the key. - Otherwise, the key will be the concatenation of all the fields. - -In order to specify multiple keys, separate ``@key`` annotations are used. -The following example shows how to define a keyed message using the IDL format: - -.. code-block:: console - - # KeyedMsgName.idl - module package_name { - module msg { - struct KeyedMsgName { - @key long key; - string data; - }; - }; - }; - -.. note:: - - Currently, the only supported message format that can be annotated with ``@key`` is *.idl*. - Neither ``.msg`` nor ``.srv`` files support annotations yet. - -Prerequisites -------------- - -* An up-to-date ROS 2 installation and setup. - Either installed in local host, or using Docker images. - -Preparing the demo package --------------------------- - -Lets start by setting up the environment. -For this, there are two possible options: - -#. Running a ROS 2 Docker image. - - .. code-block:: console - - $ docker run -it --rm osrt/ros:{DISTRO}-desktop - -#. Running the tutorial on the local host. - Please, follow the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. - -Source the following file to setup the ROS 2 environment: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ source /opt/ros/{DISTRO}/setup.bash - - Replace ``.bash`` with your shell if you're not using bash. - Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. - - .. group-tab:: macOS - - .. code-block:: console - - $ . ~/ros2_install/ros2-osx/setup.bash - - .. group-tab:: Windows - - .. code-block:: console - - $ call C:\dev\ros2\local_setup.bat - - -Retrieving the sources -^^^^^^^^^^^^^^^^^^^^^^ - -In order to retrieve the example demo code, create a new workspace and download the demo package sources as indicated below: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md - $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg - $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp - $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp - $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp - $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp - $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp - $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp - $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py - $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py - - .. group-tab:: macOS - - .. code-block:: console - - # Create directory structure - $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src - $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch - $ cd ~/tutorial_ws/src/demo_keys_cpp - - # Download demo package source code - $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt - $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml - $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md - $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg - $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg - $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp - $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp - $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp - $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp - $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp - $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp - $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py - $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py - $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py - - .. group-tab:: Windows - - .. code-block:: console - - # Create directory structure - $ mkdir C:\tutorial_ws\src\demo_keys_cpp\msg - $ mkdir C:\tutorial_ws\src\demo_keys_cpp\src - $ mkdir C:\tutorial_ws\src\demo_keys_cpp\launch - $ cd C:\tutorial_ws\src\demo_keys_cpp - - # Download demo package source code - $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt - $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml - $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md - $ irm -OutFile msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg - $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg - $ irm -OutFile src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp - $ irm -OutFile src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp - $ irm -OutFile src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp - $ irm -OutFile src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp - $ irm -OutFile src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp - $ irm -OutFile src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp - $ irm -OutFile launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py - $ irm -OutFile launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py - $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py - -Like any other ROS 2 related package, the external dependencies are listed in the ``package.xml``. -The ``CMakeLists.txt`` file defines the different targets to be built and the dependencies between them. -Note that it is built in a component manner meaning that the nodes defined in the source files can be also loaded as composable plugins apart from being executed as standalone nodes. -The *src/* directory contains the core source files for the different nodes that will be executed in the demo. -The launch files for sensors are also provided in the *launch/* directory in which 10 different nodes are launched for each one of the cases that will be later explained. -Finally, the *msg/* directory contains two different IDL message definitions, one with key annotations (sensor_id) and another without it. - -The resulting directory structure should be: - -.. code-block:: - - ~/tutorial_ws - ├──src - ├── demo_keys_cpp - ├── CMakeLists.txt - ├── README.md - ├── launch - │ ├── keyed_sensors_launch.py - │ ├── multiple_topic_sensors_launch.py - │ └── single_topic_sensors_launch.py - ├── msg - │ ├── KeyedSensorDataMsg.msg - │ └── SensorDataMsg.msg - ├── package.xml - └── src - ├── keyed_controller.cpp - ├── keyed_sensor.cpp - ├── multiple_topic_controller.cpp - ├── multiple_topic_sensor.cpp - ├── single_topic_controller.cpp - └── single_topic_sensor.cpp - -Generating the IDL files -^^^^^^^^^^^^^^^^^^^^^^^^ - -Starting from the provided ``.msg`` files, generate the corresponding IDL files using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws/src/demo_keys_cpp/msg - $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws\src\demo_keys_cpp\msg - $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg - $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg - $ del SensorDataMsg.msg KeyedSensorDataMsg.msg - - -Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. -Its content should look like the following: - -.. code-block:: idl - - /* KeyedSensorDataMsg.idl */ - module demo_keys_cpp { - module msg { - struct KeyedSensorDataMsg { - @key int16 sensor_id; - string data; - }; - }; - }; - -Building the demo package -^^^^^^^^^^^^^^^^^^^^^^^^^ - -Once the environment has been setup and the demo package sources are available, we are ready to build the workspace. -Get into the root of the workspace and build it with the following commands: - -.. tabs:: - - .. group-tab:: Linux - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: macOS - - .. code-block:: console - - $ cd ~/tutorial_ws - $ colcon build - - .. group-tab:: Windows - - .. code-block:: console - - $ cd C:\tutorial_ws - $ colcon build - -Running the demo ----------------- - -The tutorial demo consists of a controller node that subscribes to the data published by multiple sensors. -Each of the sensors are identified by a *sensor_id* and publish data to the controller at different rates, in particular, the publication period (in seconds) is the *sensor_id* times 1. -Three different valid approaches are used to address the situation: - -* In the first one, multiple sensors are publishing data to the controller using different topics for each sensor and the controller subscribing to each one of them. -* In the second approach, multiple sensors publish data to the controller using a single standalone topic. -* Finally, in the third one, the sensors use a single keyed topic defining a single data instance per unique *sensor_id*. - -In addition, all the publications and subscriptions use the following QoS settings: - -* History QoS: ``KEEP_LAST 1``. -* Reliable communication. -* Transient Local durability. - -This is set this way to recreate late joining of the controller to the application and evaluate the behavior in each of the three different scenarios. -The following diagram depicts the three different scenarios: - -.. image:: figures/tutorial_diagram.svg - :align: center - :width: 90% - -Lets start with the first scenario. -Run the demo by executing the following commands in separate terminals: - -.. note:: - - If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. - This can be done by running ``docker exec -it /bin/bash``. - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_cpp multiple_topic_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 run demo_keys_cpp multiple_topic_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 run demo_keys_cpp multiple_topic_controller - -The resulting output should be similar to the following: - -.. image:: figures/multiple_topics.gif - :align: center - :width: 100% - -It is important to note that this initial approach is not the most efficient one, as it entails the creation of multiple topics, publishers, and subscriptions. -Furthermore, apart from being inefficient, it also makes the application more complex, harder to maintain, and resource demanding. -Moreover, as a consequence of creating far more entities than needed, the application incurs in an unnecessary discovery overhead. - -Lets go a step further. -In this second approach a single topic is used in which all the sensors will publish their data (without using a keyed topic). -Run the demo by executing the following commands in separate terminals: - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp single_topic_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp single_topic_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp single_topic_controller - -Which leads to an output similar to the one shown below: - -.. image:: figures/single_topics.gif - :align: center - :width: 100% - - -This second scenario illustrates that using one single topic, a late-joining controller will not recover the state of all the sensors when it joins the application. -This is easily noticeable in the case of sensor with *id* 10; the controller will not receive the latest data published by this sensor until it publishes a new one. -Furthermore, sensors publishing at higher rates (sensors 1~3) can overwrite the data of low rate sensors, causing starvation even in the case of augmenting the history size. -These are severe problems that should be avoided. - -Now, lets move on to the third approach for addressing the problem. -Start, or reuse previous opened terminals and run the following commands: - -.. tabs:: - - .. group-tab:: Linux - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp keyed_controller - - .. group-tab:: macOS - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - $ ros2 launch demo_keys_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ source ~/tutorial_ws/install/setup.bash - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp keyed_controller - - .. group-tab:: Windows - - .. tabs:: - - .. tab:: Shell 1 (Sensors) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - $ ros2 launch demo_keys_cpp keyed_sensors_launch.py - - .. tab:: Shell 2 (Controller) - - .. code-block:: console - - $ call C:\tutorial_ws\install\setup.bat - #Wait until sensor[10] publishes the first data (10 secs) - $ ros2 run demo_keys_cpp keyed_controller - -The resulting output should be similar to the following: - -.. image:: figures/keyed_topic.gif - :align: center - :width: 100% - -In this final case, the controller is able to successfully recover the latest state of each sensor (data instance) when it joins the application. -In addition, it uses optimum resources (it only requires one topic and one subscription) and guarantees a minimum discovery overhead. -Hence, it is by using topic keys when the reception of the latest status of each instance (sensor) is assured. -This is because the Quality of Service settings are applied per data instance. +.. redirect-from:: + + Tutorials/Advanced/Topic-Keys/Topic-Keys-Tutorial + +.. _topic_keys_tutorial: + +Topic Keys Tutorial +=================== + +This tutorial aims to demonstrate the use of topic keys by simulating a scenario in which multiple sensors are transmitting their readings to a controller that processes them. + +.. contents:: + :depth: 2 + :local: + :backlinks: none + +Background +---------- + +In ROS 2, a :doc:`Topic <../../../About-Topics>` is a communication channel used for publishing and subscribing to updates of object states. +The value of data associated with a topic changes over time and each of these values are known as *data samples*. +Keyed topics refer to topics where each data sample represent an update of the state of a specific object (known as *instance*) among all those objects represented in the topic. + +Unlike standard topics, where each data sample updates the entire object state with every data sample, keyed topics allow the user to reduce the number of required resources (topics, along with its associated publisher and subscriber) by multiplexing updates of several objects of the same kind into a single resource. + +.. image:: figures/keyed-topics.gif + :align: center + :width: 70% + +RMW Support +----------- + +Keyed topics require RMW implementation support. + +.. list-table:: Keyed Topics Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - not supported + +Implementations not supporting the feature will treat keyed topics as standard topics. +The implications are explained throughout the tutorial. +In addition, endpoints using `Cyclone DDS `_ will not even match with Fast DDS or Connext DDS endpoints for this kind of topics. + +Creating custom IDL messages +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ROS 2 users can define their own :ref:`custom topic messages` in the ``.msg`` format. +Then, the ROS 2 message generation stack translates it to the DDS native `OMG IDL (Interface Definition Language) `_ message format. + +One of the advantages of defining messages in IDL is the ability to use annotations. +Annotations are metadata to the data structure definition that provide additional information about IDL constructs such as modules, interfaces, operations, attributes, and data types. +They are relevant for code generation, documentation, or other purposes. +Annotations in IDL typically follow the ``@`` symbol and can be applied to various IDL constructs. +The ``@key`` annotation is used to designate a member as key, which is covered in the following section. + +Users can define their own messages in the IDL format directly (following the `ROS 2 interface design documentation `_) or use the ``msg2idl`` tool within the ``rosidl_adapter`` package. + +Creating Keyed Messages +^^^^^^^^^^^^^^^^^^^^^^^ + +Keyed topics exist when one or more fields in the data structure are annotated as keys. +These key fields serve as unique identifiers for topic instances in order to organize and manage the data samples, facilitating efficient access, retrieval, and filtering of data based on the specified key criteria. + +The ``@key`` annotation designates a field as a key for the given topic type, which can have zero or more key fields and can be applied to structure fields of various types: + +* Any primitive, such as booleans, integers, characters, strings or sequences. +* Other existing or defined messages. + If those have defined an inner key member, then those fields will we used as part of the key. + Otherwise, the key will be the concatenation of all the fields. + +In order to specify multiple keys, separate ``@key`` annotations are used. +The following example shows how to define a keyed message using the IDL format: + +.. code-block:: console + + # KeyedMsgName.idl + module package_name { + module msg { + struct KeyedMsgName { + @key long key; + string data; + }; + }; + }; + +.. note:: + + Currently, the only supported message format that can be annotated with ``@key`` is *.idl*. + Neither ``.msg`` nor ``.srv`` files support annotations yet. + +Prerequisites +------------- + +* An up-to-date ROS 2 installation and setup. + Either installed in local host, or using Docker images. + +Preparing the demo package +-------------------------- + +Lets start by setting up the environment. +For this, there are two possible options: + +#. Running a ROS 2 Docker image. + + .. code-block:: console + + $ docker run -it --rm osrt/ros:{DISTRO}-desktop + +#. Running the tutorial on the local host. + Please, follow the :doc:`installation instructions <../../../../../Get-Started/Installation>` for details on installing ROS 2. + +Source the following file to setup the ROS 2 environment: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ source /opt/ros/{DISTRO}/setup.bash + + Replace ``.bash`` with your shell if you're not using bash. + Possible values are: ``setup.bash``, ``setup.sh``, ``setup.zsh``. + + .. group-tab:: macOS + + .. code-block:: console + + $ . ~/ros2_install/ros2-osx/setup.bash + + .. group-tab:: Windows + + .. code-block:: console + + $ call C:\dev\ros2\local_setup.bat + + +Retrieving the sources +^^^^^^^^^^^^^^^^^^^^^^ + +In order to retrieve the example demo code, create a new workspace and download the demo package sources as indicated below: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md + $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg + $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp + $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp + $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp + $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp + $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp + $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp + $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py + $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py + + .. group-tab:: macOS + + .. code-block:: console + + # Create directory structure + $ mkdir -p ~/tutorial_ws/src/demo_keys_cpp + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/msg + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/src + $ mkdir ~/tutorial_ws/src/demo_keys_cpp/launch + $ cd ~/tutorial_ws/src/demo_keys_cpp + + # Download demo package source code + $ wget -O CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt + $ wget -O package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml + $ wget -O README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md + $ wget -O msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg + $ wget -O msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg + $ wget -O src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp + $ wget -O src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp + $ wget -O src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp + $ wget -O src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp + $ wget -O src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp + $ wget -O src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp + $ wget -O launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py + $ wget -O launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py + $ wget -O launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py + + .. group-tab:: Windows + + .. code-block:: console + + # Create directory structure + $ mkdir C:\tutorial_ws\src\demo_keys_cpp\msg + $ mkdir C:\tutorial_ws\src\demo_keys_cpp\src + $ mkdir C:\tutorial_ws\src\demo_keys_cpp\launch + $ cd C:\tutorial_ws\src\demo_keys_cpp + + # Download demo package source code + $ irm -OutFile CMakeLists.txt https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/CMakeLists.txt + $ irm -OutFile package.xml https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/package.xml + $ irm -OutFile README.md https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/README.md + $ irm -OutFile msg/SensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg + $ irm -OutFile msg/KeyedSensorDataMsg.msg https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg + $ irm -OutFile src/multiple_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp + $ irm -OutFile src/multiple_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp + $ irm -OutFile src/single_topic_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp + $ irm -OutFile src/single_topic_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/single_topic_controller.cpp + $ irm -OutFile src/keyed_sensor.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_sensor.cpp + $ irm -OutFile src/keyed_controller.cpp https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/src/keyed_controller.cpp + $ irm -OutFile launch/multiple_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py + $ irm -OutFile launch/single_topic_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py + $ irm -OutFile launch/keyed_sensors_launch.py https://raw.githubusercontent.com/ros2/ros2_documentation/{DISTRO}/source/Tutorials/Advanced/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py + +Like any other ROS 2 related package, the external dependencies are listed in the ``package.xml``. +The ``CMakeLists.txt`` file defines the different targets to be built and the dependencies between them. +Note that it is built in a component manner meaning that the nodes defined in the source files can be also loaded as composable plugins apart from being executed as standalone nodes. +The *src/* directory contains the core source files for the different nodes that will be executed in the demo. +The launch files for sensors are also provided in the *launch/* directory in which 10 different nodes are launched for each one of the cases that will be later explained. +Finally, the *msg/* directory contains two different IDL message definitions, one with key annotations (sensor_id) and another without it. + +The resulting directory structure should be: + +.. code-block:: + + ~/tutorial_ws + ├──src + ├── demo_keys_cpp + ├── CMakeLists.txt + ├── README.md + ├── launch + │ ├── keyed_sensors_launch.py + │ ├── multiple_topic_sensors_launch.py + │ └── single_topic_sensors_launch.py + ├── msg + │ ├── KeyedSensorDataMsg.msg + │ └── SensorDataMsg.msg + ├── package.xml + └── src + ├── keyed_controller.cpp + ├── keyed_sensor.cpp + ├── multiple_topic_controller.cpp + ├── multiple_topic_sensor.cpp + ├── single_topic_controller.cpp + └── single_topic_sensor.cpp + +Generating the IDL files +^^^^^^^^^^^^^^^^^^^^^^^^ + +Starting from the provided ``.msg`` files, generate the corresponding IDL files using the ``msg2idl.py`` script from the ``rosidl_adapter`` package. + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws/src/demo_keys_cpp/msg + $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ rm SensorDataMsg.msg KeyedSensorDataMsg.msg + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws\src\demo_keys_cpp\msg + $ ros2 run rosidl_adapter msg2idl.py SensorDataMsg.msg + $ ros2 run rosidl_adapter msg2idl.py KeyedSensorDataMsg.msg + $ del SensorDataMsg.msg KeyedSensorDataMsg.msg + + +Next, annotate the ``sensor_id`` field as ``@key`` in the generated ``KeyedSensorDataMsg.idl``. +Its content should look like the following: + +.. code-block:: idl + + /* KeyedSensorDataMsg.idl */ + module demo_keys_cpp { + module msg { + struct KeyedSensorDataMsg { + @key int16 sensor_id; + string data; + }; + }; + }; + +Building the demo package +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Once the environment has been setup and the demo package sources are available, we are ready to build the workspace. +Get into the root of the workspace and build it with the following commands: + +.. tabs:: + + .. group-tab:: Linux + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: macOS + + .. code-block:: console + + $ cd ~/tutorial_ws + $ colcon build + + .. group-tab:: Windows + + .. code-block:: console + + $ cd C:\tutorial_ws + $ colcon build + +Running the demo +---------------- + +The tutorial demo consists of a controller node that subscribes to the data published by multiple sensors. +Each of the sensors are identified by a *sensor_id* and publish data to the controller at different rates, in particular, the publication period (in seconds) is the *sensor_id* times 1. +Three different valid approaches are used to address the situation: + +* In the first one, multiple sensors are publishing data to the controller using different topics for each sensor and the controller subscribing to each one of them. +* In the second approach, multiple sensors publish data to the controller using a single standalone topic. +* Finally, in the third one, the sensors use a single keyed topic defining a single data instance per unique *sensor_id*. + +In addition, all the publications and subscriptions use the following QoS settings: + +* History QoS: ``KEEP_LAST 1``. +* Reliable communication. +* Transient Local durability. + +This is set this way to recreate late joining of the controller to the application and evaluate the behavior in each of the three different scenarios. +The following diagram depicts the three different scenarios: + +.. image:: figures/tutorial_diagram.svg + :align: center + :width: 90% + +Lets start with the first scenario. +Run the demo by executing the following commands in separate terminals: + +.. note:: + + If a docker deployment was preferred, it would be necessary to attach the other two terminals to the running docker container before executing the above commands. + This can be done by running ``docker exec -it /bin/bash``. + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_cpp multiple_topic_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 run demo_keys_cpp multiple_topic_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_cpp multiple_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 run demo_keys_cpp multiple_topic_controller + +The resulting output should be similar to the following: + +.. image:: figures/multiple_topics.gif + :align: center + :width: 100% + +It is important to note that this initial approach is not the most efficient one, as it entails the creation of multiple topics, publishers, and subscriptions. +Furthermore, apart from being inefficient, it also makes the application more complex, harder to maintain, and resource demanding. +Moreover, as a consequence of creating far more entities than needed, the application incurs in an unnecessary discovery overhead. + +Lets go a step further. +In this second approach a single topic is used in which all the sensors will publish their data (without using a keyed topic). +Run the demo by executing the following commands in separate terminals: + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp single_topic_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp single_topic_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_cpp single_topic_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp single_topic_controller + +Which leads to an output similar to the one shown below: + +.. image:: figures/single_topics.gif + :align: center + :width: 100% + + +This second scenario illustrates that using one single topic, a late-joining controller will not recover the state of all the sensors when it joins the application. +This is easily noticeable in the case of sensor with *id* 10; the controller will not receive the latest data published by this sensor until it publishes a new one. +Furthermore, sensors publishing at higher rates (sensors 1~3) can overwrite the data of low rate sensors, causing starvation even in the case of augmenting the history size. +These are severe problems that should be avoided. + +Now, lets move on to the third approach for addressing the problem. +Start, or reuse previous opened terminals and run the following commands: + +.. tabs:: + + .. group-tab:: Linux + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp keyed_controller + + .. group-tab:: macOS + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + $ ros2 launch demo_keys_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ source ~/tutorial_ws/install/setup.bash + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp keyed_controller + + .. group-tab:: Windows + + .. tabs:: + + .. tab:: Shell 1 (Sensors) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + $ ros2 launch demo_keys_cpp keyed_sensors_launch.py + + .. tab:: Shell 2 (Controller) + + .. code-block:: console + + $ call C:\tutorial_ws\install\setup.bat + #Wait until sensor[10] publishes the first data (10 secs) + $ ros2 run demo_keys_cpp keyed_controller + +The resulting output should be similar to the following: + +.. image:: figures/keyed_topic.gif + :align: center + :width: 100% + +In this final case, the controller is able to successfully recover the latest state of each sensor (data instance) when it joins the application. +In addition, it uses optimum resources (it only requires one topic and one subscription) and guarantees a minimum discovery overhead. +Hence, it is by using topic keys when the reception of the latest status of each instance (sensor) is assured. +This is because the Quality of Service settings are applied per data instance. For learning how to combine keyed topics with content filter topic, please refer to the :ref:`filtered_topic_keys_tutorial`. \ No newline at end of file diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/cft_tutorial_diagram.svg b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/cft_tutorial_diagram.svg similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/cft_tutorial_diagram.svg rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/cft_tutorial_diagram.svg diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/filtered_keyed_topic.gif b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/filtered_keyed_topic.gif similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/filtered_keyed_topic.gif rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/filtered_keyed_topic.gif diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/keyed-topics-cft.gif b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/keyed-topics-cft.gif similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/keyed-topics-cft.gif rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/keyed-topics-cft.gif diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/keyed-topics.gif b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/keyed-topics.gif similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/keyed-topics.gif rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/keyed-topics.gif diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/keyed_topic.gif b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/keyed_topic.gif similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/keyed_topic.gif rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/keyed_topic.gif diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/multiple_topics.gif b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/multiple_topics.gif similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/multiple_topics.gif rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/multiple_topics.gif diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/single_topics.gif b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/single_topics.gif similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/single_topics.gif rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/single_topics.gif diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/tutorial_diagram.svg b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/tutorial_diagram.svg similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/figures/tutorial_diagram.svg rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/figures/tutorial_diagram.svg diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/CMakeLists.txt b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/CMakeLists.txt similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/CMakeLists.txt rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/CMakeLists.txt diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/README.md b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/README.md similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/README.md rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/README.md diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/keyed_sensors_launch.py diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/multiple_topic_sensors_launch.py diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/launch/single_topic_sensors_launch.py diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/KeyedSensorDataMsg.msg diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/msg/SensorDataMsg.msg diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/package.xml b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/package.xml similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/package.xml rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/package.xml diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_controller.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_controller.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_controller.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_controller.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_sensor.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_sensor.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_sensor.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/keyed_sensor.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_controller.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/multiple_topic_sensor.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_controller.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_controller.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_controller.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_controller.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Basic/src/single_topic_sensor.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/CMakeLists.txt b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/CMakeLists.txt similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/CMakeLists.txt rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/CMakeLists.txt diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/README.md b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/README.md similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/README.md rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/README.md diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/launch/keyed_sensors_launch.py diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/msg/KeyedSensorDataMsg.msg diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/package.xml b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/package.xml similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/package.xml rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/package.xml diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_controller.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp similarity index 100% rename from source/ROS-Framework/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/resources/Filtered/src/filtered_keyed_sensor.cpp diff --git a/source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst similarity index 95% rename from source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst rename to source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst index 6a88e1266f6..e30ca835c66 100644 --- a/source/ROS-Framework/topics/Working-with-topics/Wait-for-Acknowledgment.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst @@ -1,97 +1,97 @@ -.. redirect-from:: - - Tutorials/Demos/Wait-for-Acknowledgment - -Wait for acknowledgment -======================= - -**Goal:** Wait for acknowledgment of messages sent by a publisher. - -**Tutorial level:** Advanced - -**Time:** 10 minutes - -.. contents:: Table of Contents - :depth: 1 - :local: - -Overview --------- - -In Publisher-Subscriber architecture, messages are sent from the publisher to the subscribers, and the publisher does not have any built-in mechanism to confirm that the subscriber has received the messages. -This feature enables the publisher to wait for acknowledgment of messages it sent. -This is useful in scenarios where the publisher needs to ensure that the subscriber has received the message before proceeding with further actions, such as sending more messages or performing other operations. - -RMW Support ------------ - -Wait for acknowledgment requires RMW implementation support. - -.. list-table:: Wait-for-Acknowledgment Support Status - :widths: 25 25 - - * - rmw_fastrtps - - supported - * - rmw_connextdds - - supported - * - rmw_cyclonedds - - supported - -The publisher's :ref:`QoS reliability policy ` needs to be ``RELIABLE`` to use the wait for acknowledgment feature, otherwise the publisher will not wait for acknowledgment. - -Installing the demo -------------------- - -See the :doc:`installation instructions <../../../Get-Started/Installation>` for details on installing ROS 2. - -If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-examples-rclcpp-minimal-publisher`` and ``ros-{DISTRO}-examples-rclcpp-minimal-subscriber`` installed. -If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. - -Running the demo ----------------- - -This demo shows how to use the wait for acknowledgment feature in the publisher to ensure that messages sent by the publisher are acknowledged by all subscriptions. - -https://github.com/ros2/examples/blob/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/member_function_with_wait_for_all_acked.cpp - -The publisher can use the ``wait_for_all_acked`` method to wait for message acknowledgments within a specified timeout before shutdown by the signal. - -We can start the demo by running the ``publisher_wait_for_all_acked`` and ``subscriber_member_function`` executables from the ``examples_rclcpp_minimal_publisher`` package (don't forget to source the setup file first): - -Start the subscriber in one terminal: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function - [INFO] [1743121567.030751270] [minimal_subscriber]: I heard: 'Hello, world! 0' - [INFO] [1743121567.530981660] [minimal_subscriber]: I heard: 'Hello, world! 1' - [INFO] [1743121568.031032935] [minimal_subscriber]: I heard: 'Hello, world! 2' - [INFO] [1743121568.531048458] [minimal_subscriber]: I heard: 'Hello, world! 3' - [INFO] [1743121569.031049351] [minimal_subscriber]: I heard: 'Hello, world! 4' - [INFO] [1743121569.530980327] [minimal_subscriber]: I heard: 'Hello, world! 5' - [INFO] [1743121570.030825871] [minimal_subscriber]: I heard: 'Hello, world! 6' - ... - -Then start the publisher in another terminal: - -.. code-block:: console - - $ ros2 run examples_rclcpp_minimal_publisher publisher_wait_for_all_acked - [INFO] [1743121567.030353553] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 0' - [INFO] [1743121567.530420788] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 1' - [INFO] [1743121568.030461599] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 2' - [INFO] [1743121568.530435646] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 3' - [INFO] [1743121569.030431263] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 4' - [INFO] [1743121569.530447106] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 5' - [INFO] [1743121570.030353934] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 6' - ^C[INFO] [1743121570.344981639] [rclcpp]: signal_handler(signum=2) - [INFO] [1743121570.345398788] [minimal_publisher_with_wait_for_all_acked]: All subscribers acknowledge messages - -When the publisher is terminated (e.g., by pressing :kbd:`Ctrl-C`), it will wait for acknowledgment of all messages sent before shutdown. -If all subscribers acknowledge the messages, the publisher will print a message indicating that all subscribers have acknowledged the messages. -If not, it will print a message indicating that not all subscribers acknowledged the messages within the specified timeout. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Demos/Wait-for-Acknowledgment + +Wait for acknowledgment +======================= + +**Goal:** Wait for acknowledgment of messages sent by a publisher. + +**Tutorial level:** Advanced + +**Time:** 10 minutes + +.. contents:: Table of Contents + :depth: 1 + :local: + +Overview +-------- + +In Publisher-Subscriber architecture, messages are sent from the publisher to the subscribers, and the publisher does not have any built-in mechanism to confirm that the subscriber has received the messages. +This feature enables the publisher to wait for acknowledgment of messages it sent. +This is useful in scenarios where the publisher needs to ensure that the subscriber has received the message before proceeding with further actions, such as sending more messages or performing other operations. + +RMW Support +----------- + +Wait for acknowledgment requires RMW implementation support. + +.. list-table:: Wait-for-Acknowledgment Support Status + :widths: 25 25 + + * - rmw_fastrtps + - supported + * - rmw_connextdds + - supported + * - rmw_cyclonedds + - supported + +The publisher's :ref:`QoS reliability policy ` needs to be ``RELIABLE`` to use the wait for acknowledgment feature, otherwise the publisher will not wait for acknowledgment. + +Installing the demo +------------------- + +See the :doc:`installation instructions <../../../../Get-Started/Installation>` for details on installing ROS 2. + +If you've installed ROS 2 from packages, ensure that you have ``ros-{DISTRO}-examples-rclcpp-minimal-publisher`` and ``ros-{DISTRO}-examples-rclcpp-minimal-subscriber`` installed. +If you downloaded the archive or built ROS 2 from source, it will already be part of the installation. + +Running the demo +---------------- + +This demo shows how to use the wait for acknowledgment feature in the publisher to ensure that messages sent by the publisher are acknowledged by all subscriptions. + +https://github.com/ros2/examples/blob/{REPOS_FILE_BRANCH}/rclcpp/topics/minimal_publisher/member_function_with_wait_for_all_acked.cpp + +The publisher can use the ``wait_for_all_acked`` method to wait for message acknowledgments within a specified timeout before shutdown by the signal. + +We can start the demo by running the ``publisher_wait_for_all_acked`` and ``subscriber_member_function`` executables from the ``examples_rclcpp_minimal_publisher`` package (don't forget to source the setup file first): + +Start the subscriber in one terminal: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_subscriber subscriber_member_function + [INFO] [1743121567.030751270] [minimal_subscriber]: I heard: 'Hello, world! 0' + [INFO] [1743121567.530981660] [minimal_subscriber]: I heard: 'Hello, world! 1' + [INFO] [1743121568.031032935] [minimal_subscriber]: I heard: 'Hello, world! 2' + [INFO] [1743121568.531048458] [minimal_subscriber]: I heard: 'Hello, world! 3' + [INFO] [1743121569.031049351] [minimal_subscriber]: I heard: 'Hello, world! 4' + [INFO] [1743121569.530980327] [minimal_subscriber]: I heard: 'Hello, world! 5' + [INFO] [1743121570.030825871] [minimal_subscriber]: I heard: 'Hello, world! 6' + ... + +Then start the publisher in another terminal: + +.. code-block:: console + + $ ros2 run examples_rclcpp_minimal_publisher publisher_wait_for_all_acked + [INFO] [1743121567.030353553] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 0' + [INFO] [1743121567.530420788] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 1' + [INFO] [1743121568.030461599] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 2' + [INFO] [1743121568.530435646] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 3' + [INFO] [1743121569.030431263] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 4' + [INFO] [1743121569.530447106] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 5' + [INFO] [1743121570.030353934] [minimal_publisher_with_wait_for_all_acked]: Publishing: 'Hello, world! 6' + ^C[INFO] [1743121570.344981639] [rclcpp]: signal_handler(signum=2) + [INFO] [1743121570.345398788] [minimal_publisher_with_wait_for_all_acked]: All subscribers acknowledge messages + +When the publisher is terminated (e.g., by pressing :kbd:`Ctrl-C`), it will wait for acknowledgment of all messages sent before shutdown. +If all subscribers acknowledge the messages, the publisher will print a message indicating that all subscribers have acknowledged the messages. +If not, it will print a message indicating that not all subscribers acknowledged the messages within the specified timeout. + +Related content +--------------- + - `Wait-for-Acknowledgment example with rclpy `__. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/About-Discovery.rst b/source/ROS-Framework/nodes/About-Discovery.rst index 78f50e34157..e95691d98c3 100644 --- a/source/ROS-Framework/nodes/About-Discovery.rst +++ b/source/ROS-Framework/nodes/About-Discovery.rst @@ -1,25 +1,25 @@ -.. redirect-from:: - - Concepts/Basic/About-Discovery - -Discovery -========= - -.. contents:: Table of Contents - :local: - -Discovery of nodes happens automatically through the underlying middleware of ROS 2. -It can be summarized as follows: - -#. When a node is started, it advertises its presence to other nodes on the network with the same ROS domain (set with the ROS_DOMAIN_ID environment variable). - Nodes respond to this advertisement with information about themselves so that the appropriate connections can be made and the nodes can communicate. -#. Nodes periodically advertise their presence so that connections can be made with new-found entities, even after the initial discovery period. -#. Nodes advertise to other nodes when they go offline. - -Nodes will only establish connections with other nodes if they have compatible :doc:`Quality of Service <../topics/Working-with-topics/Quality-of-Service>` settings. - -Take the :ref:`talker-listener demo ` for example. -Running the C++ talker node in one terminal will publish messages on a topic, -and the Python listener node running in another terminal will subscribe to messages on the same topic. - +.. redirect-from:: + + Concepts/Basic/About-Discovery + +Discovery +========= + +.. contents:: Table of Contents + :local: + +Discovery of nodes happens automatically through the underlying middleware of ROS 2. +It can be summarized as follows: + +#. When a node is started, it advertises its presence to other nodes on the network with the same ROS domain (set with the ROS_DOMAIN_ID environment variable). + Nodes respond to this advertisement with information about themselves so that the appropriate connections can be made and the nodes can communicate. +#. Nodes periodically advertise their presence so that connections can be made with new-found entities, even after the initial discovery period. +#. Nodes advertise to other nodes when they go offline. + +Nodes will only establish connections with other nodes if they have compatible :doc:`Quality of Service <../interfaces/topics/Working-with-topics/Quality-of-Service>` settings. + +Take the :ref:`talker-listener demo ` for example. +Running the C++ talker node in one terminal will publish messages on a topic, +and the Python listener node running in another terminal will subscribe to messages on the same topic. + You should see that these nodes discover each other automatically, and begin to exchange messages. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst index 3065dda2060..4aa1bffb351 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst @@ -1,197 +1,197 @@ -.. redirect-from:: - - Tutorials/Understanding-ROS2-Nodes - Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes - -.. _ROS2Nodes: - -Understanding nodes -=================== - -**Goal:** Learn about the function of nodes in ROS 2, and the tools to interact with them. - -**Tutorial level:** Beginner - -**Time:** 10 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -1 The ROS 2 graph -^^^^^^^^^^^^^^^^^ - -Over the next few tutorials, you will learn about a series of core ROS 2 concepts that make up what is referred to as the "ROS (2) graph". - -The ROS graph is a network of ROS 2 elements processing data together at the same time. -It encompasses all executables and the connections between them if you were to map them all out and visualize them. - -2 Nodes in ROS 2 -^^^^^^^^^^^^^^^^ - -Each node in ROS should be responsible for a single, modular purpose, e.g. controlling the wheel motors or publishing the sensor data from a laser range-finder. -Each node can send and receive data from other nodes via topics, services, actions, or parameters. - -.. image:: images/Nodes-TopicandService.gif - -A full robotic system is comprised of many nodes working in concert. -In ROS 2, a single executable (C++ program, Python program, etc.) can contain one or more nodes. - -Prerequisites -------------- - -The :doc:`previous tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` shows you how to install the ``turtlesim`` package used here. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. - -Tasks ------ - -1 ros2 run -^^^^^^^^^^ - -The command ``ros2 run`` launches an executable from a package. - -.. code-block:: console - - $ ros2 run - -To run turtlesim, open a new terminal, and enter the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -The turtlesim window will open, as you saw in the :doc:`previous tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. - -Here, the package name is ``turtlesim`` and the executable name is ``turtlesim_node``. - -We still don't know the node name, however. -You can find node names by using ``ros2 node list`` - -2 ros2 node list -^^^^^^^^^^^^^^^^ - -``ros2 node list`` will show you the names of all running nodes. -This is especially useful when you want to interact with a node, or when you have a system running many nodes and need to keep track of them. - -Open a new terminal while turtlesim is still running in the other one, and enter the following command. -The terminal will return the node name: - -.. code-block:: console - - $ ros2 node list - /turtlesim - -Open another new terminal and start the teleop node with the command: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - -Here, we are referring to the ``turtlesim`` package again, but this time we target the executable named ``turtle_teleop_key``. - -Return to the terminal where you ran ``ros2 node list`` and run it again. -You will now see the names of two active nodes: - -.. code-block:: console - - $ ros2 node list - /turtlesim - /teleop_turtle - -2.1 Remapping -~~~~~~~~~~~~~ - -`Remapping `__ allows you to reassign default node properties, like node name, topic names, service names, etc., to custom values. -In the last tutorial, you used remapping on ``turtle_teleop_key`` to change the cmd_vel topic and target **turtle2**. - -Now, let's reassign the name of our ``/turtlesim`` node. -In a new terminal, run the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node --ros-args --remap __node:=my_turtle - -Since you're calling ``ros2 run`` on turtlesim again, another turtlesim window will open. -However, now if you return to the terminal where you ran ``ros2 node list``, and run it again, you will see three node names: - -.. code-block:: console - - /my_turtle - /turtlesim - /teleop_turtle - -3 ros2 node info -^^^^^^^^^^^^^^^^ - -Now that you know the names of your nodes, you can access more information about them with: - -.. code-block:: console - - $ ros2 node info - -To examine your latest node, ``my_turtle``, run the following command: - -.. code-block:: console - - $ ros2 node info /my_turtle - /my_turtle - Subscribers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /turtle1/cmd_vel: geometry_msgs/msg/Twist - Publishers: - /parameter_events: rcl_interfaces/msg/ParameterEvent - /rosout: rcl_interfaces/msg/Log - /turtle1/color_sensor: turtlesim_msgs/msg/Color - /turtle1/pose: turtlesim_msgs/msg/Pose - Service Servers: - /clear: std_srvs/srv/Empty - /kill: turtlesim_msgs/srv/Kill - /my_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters - /my_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes - /my_turtle/get_parameters: rcl_interfaces/srv/GetParameters - /my_turtle/list_parameters: rcl_interfaces/srv/ListParameters - /my_turtle/set_parameters: rcl_interfaces/srv/SetParameters - /my_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically - /reset: std_srvs/srv/Empty - /spawn: turtlesim_msgs/srv/Spawn - /turtle1/set_pen: turtlesim_msgs/srv/SetPen - /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute - /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative - Service Clients: - - Action Servers: - /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute - Action Clients: - -``ros2 node info`` returns a list of subscribers, publishers, services, and actions. -i.e. the ROS graph connections that interact with that node. - -Now try running the same command on the ``/teleop_turtle`` node, and see how its connections differ from ``my_turtle``. - -You will learn more about the ROS graph connection concepts including the message types in the upcoming tutorials. - -Summary -------- - -A node is a fundamental ROS 2 element that serves a single, modular purpose in a robotics system. - -In this tutorial, you utilized nodes created in the ``turtlesim`` package by running the executables ``turtlesim_node`` and ``turtle_teleop_key``. - -You learned how to use ``ros2 node list`` to discover active node names and ``ros2 node info`` to introspect a single node. -These tools are vital to understanding the flow of data in a complex, real-world robot system. - -Next steps ----------- - -Now that you understand nodes in ROS 2, you can move on to the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. -Topics are one of the communication types that connects nodes. - -Related content ---------------- - +.. redirect-from:: + + Tutorials/Understanding-ROS2-Nodes + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes + +.. _ROS2Nodes: + +Understanding nodes +=================== + +**Goal:** Learn about the function of nodes in ROS 2, and the tools to interact with them. + +**Tutorial level:** Beginner + +**Time:** 10 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +1 The ROS 2 graph +^^^^^^^^^^^^^^^^^ + +Over the next few tutorials, you will learn about a series of core ROS 2 concepts that make up what is referred to as the "ROS (2) graph". + +The ROS graph is a network of ROS 2 elements processing data together at the same time. +It encompasses all executables and the connections between them if you were to map them all out and visualize them. + +2 Nodes in ROS 2 +^^^^^^^^^^^^^^^^ + +Each node in ROS should be responsible for a single, modular purpose, e.g. controlling the wheel motors or publishing the sensor data from a laser range-finder. +Each node can send and receive data from other nodes via topics, services, actions, or parameters. + +.. image:: images/Nodes-TopicandService.gif + +A full robotic system is comprised of many nodes working in concert. +In ROS 2, a single executable (C++ program, Python program, etc.) can contain one or more nodes. + +Prerequisites +------------- + +The :doc:`previous tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` shows you how to install the ``turtlesim`` package used here. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 ros2 run +^^^^^^^^^^ + +The command ``ros2 run`` launches an executable from a package. + +.. code-block:: console + + $ ros2 run + +To run turtlesim, open a new terminal, and enter the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +The turtlesim window will open, as you saw in the :doc:`previous tutorial <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +Here, the package name is ``turtlesim`` and the executable name is ``turtlesim_node``. + +We still don't know the node name, however. +You can find node names by using ``ros2 node list`` + +2 ros2 node list +^^^^^^^^^^^^^^^^ + +``ros2 node list`` will show you the names of all running nodes. +This is especially useful when you want to interact with a node, or when you have a system running many nodes and need to keep track of them. + +Open a new terminal while turtlesim is still running in the other one, and enter the following command. +The terminal will return the node name: + +.. code-block:: console + + $ ros2 node list + /turtlesim + +Open another new terminal and start the teleop node with the command: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + +Here, we are referring to the ``turtlesim`` package again, but this time we target the executable named ``turtle_teleop_key``. + +Return to the terminal where you ran ``ros2 node list`` and run it again. +You will now see the names of two active nodes: + +.. code-block:: console + + $ ros2 node list + /turtlesim + /teleop_turtle + +2.1 Remapping +~~~~~~~~~~~~~ + +`Remapping `__ allows you to reassign default node properties, like node name, topic names, service names, etc., to custom values. +In the last tutorial, you used remapping on ``turtle_teleop_key`` to change the cmd_vel topic and target **turtle2**. + +Now, let's reassign the name of our ``/turtlesim`` node. +In a new terminal, run the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node --ros-args --remap __node:=my_turtle + +Since you're calling ``ros2 run`` on turtlesim again, another turtlesim window will open. +However, now if you return to the terminal where you ran ``ros2 node list``, and run it again, you will see three node names: + +.. code-block:: console + + /my_turtle + /turtlesim + /teleop_turtle + +3 ros2 node info +^^^^^^^^^^^^^^^^ + +Now that you know the names of your nodes, you can access more information about them with: + +.. code-block:: console + + $ ros2 node info + +To examine your latest node, ``my_turtle``, run the following command: + +.. code-block:: console + + $ ros2 node info /my_turtle + /my_turtle + Subscribers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /turtle1/cmd_vel: geometry_msgs/msg/Twist + Publishers: + /parameter_events: rcl_interfaces/msg/ParameterEvent + /rosout: rcl_interfaces/msg/Log + /turtle1/color_sensor: turtlesim_msgs/msg/Color + /turtle1/pose: turtlesim_msgs/msg/Pose + Service Servers: + /clear: std_srvs/srv/Empty + /kill: turtlesim_msgs/srv/Kill + /my_turtle/describe_parameters: rcl_interfaces/srv/DescribeParameters + /my_turtle/get_parameter_types: rcl_interfaces/srv/GetParameterTypes + /my_turtle/get_parameters: rcl_interfaces/srv/GetParameters + /my_turtle/list_parameters: rcl_interfaces/srv/ListParameters + /my_turtle/set_parameters: rcl_interfaces/srv/SetParameters + /my_turtle/set_parameters_atomically: rcl_interfaces/srv/SetParametersAtomically + /reset: std_srvs/srv/Empty + /spawn: turtlesim_msgs/srv/Spawn + /turtle1/set_pen: turtlesim_msgs/srv/SetPen + /turtle1/teleport_absolute: turtlesim_msgs/srv/TeleportAbsolute + /turtle1/teleport_relative: turtlesim_msgs/srv/TeleportRelative + Service Clients: + + Action Servers: + /turtle1/rotate_absolute: turtlesim_msgs/action/RotateAbsolute + Action Clients: + +``ros2 node info`` returns a list of subscribers, publishers, services, and actions. +i.e. the ROS graph connections that interact with that node. + +Now try running the same command on the ``/teleop_turtle`` node, and see how its connections differ from ``my_turtle``. + +You will learn more about the ROS graph connection concepts including the message types in the upcoming tutorials. + +Summary +------- + +A node is a fundamental ROS 2 element that serves a single, modular purpose in a robotics system. + +In this tutorial, you utilized nodes created in the ``turtlesim`` package by running the executables ``turtlesim_node`` and ``turtle_teleop_key``. + +You learned how to use ``ros2 node list`` to discover active node names and ``ros2 node info`` to introspect a single node. +These tools are vital to understanding the flow of data in a complex, real-world robot system. + +Next steps +---------- + +Now that you understand nodes in ROS 2, you can move on to the :doc:`topics tutorial <../../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`. +Topics are one of the communication types that connects nodes. + +Related content +--------------- + The :doc:`../../../../Concepts` page adds some more detail to the concept of nodes. \ No newline at end of file diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst index b9e7811a2ed..01b9107bd5f 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst @@ -1,133 +1,133 @@ -.. redirect-from:: - - Tutorials/Rqt-Console/Using-Rqt-Console - Tutorials/Beginner-CLI-Tools/Using-Rqt-Console/Using-Rqt-Console - -.. _rqt_console: - -Using ``rqt_console`` to view logs -================================== - -**Goal:** Get to know ``rqt_console``, a tool for introspecting log messages. - -**Tutorial level:** Beginner - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -``rqt_console`` is a GUI tool used to introspect log messages in ROS 2. -Typically, log messages show up in your terminal. -With ``rqt_console``, you can collect those messages over time, view them closely and in a more organized manner, filter them, save them and even reload the saved files to introspect at a different time. - -Nodes use logs to output messages concerning events and status in a variety of ways. -Their content is usually informational, for the sake of the user. - -Prerequisites -------------- - -You will need :doc:`rqt_console and turtlesim <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` installed. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. - - -Tasks ------ - -1 Setup -^^^^^^^ - -Start ``rqt_console`` in a new terminal with the following command: - -.. code-block:: console - - $ ros2 run rqt_console rqt_console - -The ``rqt_console`` window will open: - -.. image:: images/console.png - -The first section of the console is where log messages from your system will display. - -In the middle you have the option to filter messages by excluding severity levels. -You can also add more exclusion filters using the plus-sign button to the right. - -The bottom section is for highlighting messages that include a string you input. -You can add more filters to this section as well. - -Now start ``turtlesim`` in a new terminal with the following command: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -2 Messages on rqt_console -^^^^^^^^^^^^^^^^^^^^^^^^^ - -To produce log messages for ``rqt_console`` to display, let's have the turtle run into the wall. -In a new terminal, enter the ``ros2 topic pub`` command (discussed in detail in the :doc:`topics tutorial <../../../topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`) below: - -.. code-block:: console - - $ ros2 topic pub -r 1 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}" - -Since the above command is publishing the topic at a steady rate, the turtle is continuously running into the wall. -In ``rqt_console`` you will see the same message with the ``Warn`` severity level displayed over and over, like so: - -.. image:: images/warn.png - -Press ``Ctrl+C`` in the terminal where you ran the ``ros2 topic pub`` command to stop your turtle from running into the wall. - -3 Logger levels -^^^^^^^^^^^^^^^ - -ROS 2's logger levels are ordered by severity: - - 1. Fatal - 2. Error - 3. Warn - 4. Info - 5. Debug - -There is no exact standard for what each level indicates, but it's safe to assume that: - -* ``Fatal`` messages indicate the system is going to terminate to try to protect itself from detriment. -* ``Error`` messages indicate significant issues that won't necessarily damage the system, but are preventing it from functioning properly. -* ``Warn`` messages indicate unexpected activity or non-ideal results that might represent a deeper issue, but don't harm functionality outright. -* ``Info`` messages indicate event and status updates that serve as a visual verification that the system is running as expected. -* ``Debug`` messages detail the entire step-by-step process of the system execution. - -The default level is ``Info``. -You will only see messages of the default severity level and more-severe levels. - -Normally, only ``Debug`` messages are hidden because they're the only level less severe than ``Info``. -For example, if you set the default level to ``Warn``, you would only see messages of severity ``Warn``, ``Error``, and ``Fatal``. - -3.1 Set the default logger level -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can set the default logger level when you first run the ``/turtlesim`` node using remapping. -Enter the following command in your terminal: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node --ros-args --log-level WARN - -Now you won't see the initial ``Info`` level messages that came up in the console last time you started ``turtlesim``. -That's because ``Info`` messages are lower priority than the new default severity, ``Warn``. - -Summary -------- - -``rqt_console`` can be very helpful if you need to closely examine the log messages from your system. -You might want to examine log messages for any number of reasons, usually to find out where something went wrong and the series of events leading up to that. - -Next steps ----------- - +.. redirect-from:: + + Tutorials/Rqt-Console/Using-Rqt-Console + Tutorials/Beginner-CLI-Tools/Using-Rqt-Console/Using-Rqt-Console + +.. _rqt_console: + +Using ``rqt_console`` to view logs +================================== + +**Goal:** Get to know ``rqt_console``, a tool for introspecting log messages. + +**Tutorial level:** Beginner + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +``rqt_console`` is a GUI tool used to introspect log messages in ROS 2. +Typically, log messages show up in your terminal. +With ``rqt_console``, you can collect those messages over time, view them closely and in a more organized manner, filter them, save them and even reload the saved files to introspect at a different time. + +Nodes use logs to output messages concerning events and status in a variety of ways. +Their content is usually informational, for the sake of the user. + +Prerequisites +------------- + +You will need :doc:`rqt_console and turtlesim <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>` installed. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + + +Tasks +----- + +1 Setup +^^^^^^^ + +Start ``rqt_console`` in a new terminal with the following command: + +.. code-block:: console + + $ ros2 run rqt_console rqt_console + +The ``rqt_console`` window will open: + +.. image:: images/console.png + +The first section of the console is where log messages from your system will display. + +In the middle you have the option to filter messages by excluding severity levels. +You can also add more exclusion filters using the plus-sign button to the right. + +The bottom section is for highlighting messages that include a string you input. +You can add more filters to this section as well. + +Now start ``turtlesim`` in a new terminal with the following command: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +2 Messages on rqt_console +^^^^^^^^^^^^^^^^^^^^^^^^^ + +To produce log messages for ``rqt_console`` to display, let's have the turtle run into the wall. +In a new terminal, enter the ``ros2 topic pub`` command (discussed in detail in the :doc:`topics tutorial <../../../interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics>`) below: + +.. code-block:: console + + $ ros2 topic pub -r 1 /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0, y: 0.0, z: 0.0}, angular: {x: 0.0,y: 0.0,z: 0.0}}" + +Since the above command is publishing the topic at a steady rate, the turtle is continuously running into the wall. +In ``rqt_console`` you will see the same message with the ``Warn`` severity level displayed over and over, like so: + +.. image:: images/warn.png + +Press ``Ctrl+C`` in the terminal where you ran the ``ros2 topic pub`` command to stop your turtle from running into the wall. + +3 Logger levels +^^^^^^^^^^^^^^^ + +ROS 2's logger levels are ordered by severity: + + 1. Fatal + 2. Error + 3. Warn + 4. Info + 5. Debug + +There is no exact standard for what each level indicates, but it's safe to assume that: + +* ``Fatal`` messages indicate the system is going to terminate to try to protect itself from detriment. +* ``Error`` messages indicate significant issues that won't necessarily damage the system, but are preventing it from functioning properly. +* ``Warn`` messages indicate unexpected activity or non-ideal results that might represent a deeper issue, but don't harm functionality outright. +* ``Info`` messages indicate event and status updates that serve as a visual verification that the system is running as expected. +* ``Debug`` messages detail the entire step-by-step process of the system execution. + +The default level is ``Info``. +You will only see messages of the default severity level and more-severe levels. + +Normally, only ``Debug`` messages are hidden because they're the only level less severe than ``Info``. +For example, if you set the default level to ``Warn``, you would only see messages of severity ``Warn``, ``Error``, and ``Fatal``. + +3.1 Set the default logger level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can set the default logger level when you first run the ``/turtlesim`` node using remapping. +Enter the following command in your terminal: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node --ros-args --log-level WARN + +Now you won't see the initial ``Info`` level messages that came up in the console last time you started ``turtlesim``. +That's because ``Info`` messages are lower priority than the new default severity, ``Warn``. + +Summary +------- + +``rqt_console`` can be very helpful if you need to closely examine the log messages from your system. +You might want to examine log messages for any number of reasons, usually to find out where something went wrong and the series of events leading up to that. + +Next steps +---------- + The next tutorial will teach you about starting multiple nodes at once with :doc:`ROS 2 Launch <../Launching-Multiple-Nodes/Launching-Multiple-Nodes>`. \ No newline at end of file diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst b/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst index ff5bfb952ba..a8bd7e9cfd7 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst @@ -1,252 +1,252 @@ -.. redirect-from:: - - Tutorials/Parameters/Understanding-ROS2-Parameters - Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters - -.. _ROS2Params: - -Understanding parameters -======================== - -**Goal:** Learn how to get, set, save and reload parameters in ROS 2. - -**Tutorial level:** Beginner - -**Time:** 5 minutes - -.. contents:: Contents - :depth: 2 - :local: - -Background ----------- - -A parameter is a configuration value of a node. -You can think of parameters as node settings. -A node can store parameters as integers, floats, booleans, strings, and lists. -In ROS 2, each node maintains its own parameters. -For more background on parameters, please see :doc:`the concept document <../../../About-Parameters>`. - -Prerequisites -------------- - -This tutorial uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. - -As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. - -Tasks ------ - -1 Setup -^^^^^^^ - -Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. - -Open a new terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node - -Open another terminal and run: - -.. code-block:: console - - $ ros2 run turtlesim turtle_teleop_key - - -2 ros2 param list -^^^^^^^^^^^^^^^^^ - -To see the parameters belonging to your nodes, open a new terminal and enter the command: - -.. code-block:: console - - $ ros2 param list - /teleop_turtle: - qos_overrides./parameter_events.publisher.depth - qos_overrides./parameter_events.publisher.durability - qos_overrides./parameter_events.publisher.history - qos_overrides./parameter_events.publisher.reliability - scale_angular - scale_linear - use_sim_time - /turtlesim: - background_b - background_g - background_r - qos_overrides./parameter_events.publisher.depth - qos_overrides./parameter_events.publisher.durability - qos_overrides./parameter_events.publisher.history - qos_overrides./parameter_events.publisher.reliability - use_sim_time - - -You see the node namespaces, ``/teleop_turtle`` and ``/turtlesim``, followed by each node's parameters. - -The namespaces of the parameter and its name are separated using dots as you can see, for example, in ``parameter_events.publisher.depth``. - -Every node has the parameter ``use_sim_time``; it's not unique to turtlesim. - -Based on their names, it looks like ``/turtlesim``'s parameters determine the background color of the turtlesim window using RGB color values. - -To determine a parameter's type, you can use ``ros2 param get``. - - -3 ros2 param get -^^^^^^^^^^^^^^^^ - -To display the type and current value of a parameter, use the command: - -.. code-block:: console - - $ ros2 param get - -You can also query a parameter across all nodes by omitting the node name: - -.. code-block:: console - - $ ros2 param get - -Let's find out the current value of ``/turtlesim``'s parameter ``background_g``: - -.. code-block:: console - - $ ros2 param get /turtlesim background_g - Integer value is: 86 - -Now you know ``background_g`` holds an integer value. - -If you run the same command on ``background_r`` and ``background_b``, you will get the values ``69`` and ``255``, respectively. - -You can also check the ``use_sim_time`` parameter across all nodes: - -.. code-block:: console - - $ ros2 param get use_sim_time - -This will display the parameter value for each node that has this parameter set. - -4 ros2 param set -^^^^^^^^^^^^^^^^ - -To change a parameter's value at runtime, use the command: - -.. code-block:: console - - $ ros2 param set - -Let's change ``/turtlesim``'s background color: - -.. code-block:: console - - $ ros2 param set /turtlesim background_r 150 - Set parameter successful - -The background of your turtlesim window should change colors: - -.. image:: images/set.png - -Setting parameters with the ``set`` command will only change them in your current session, not permanently. -However, you can save your settings and reload them the next time you start a node. - -5 ros2 param dump -^^^^^^^^^^^^^^^^^ - -You can view all of a node's current parameter values by using the command: - -.. code-block:: console - - $ ros2 param dump - -The command prints to the standard output (stdout) by default but you can also redirect the parameter values into a file to save them for later. -To save your current configuration of ``/turtlesim``'s parameters into the file ``turtlesim.yaml``, enter the command: - -.. code-block:: console - - $ ros2 param dump /turtlesim > turtlesim.yaml - -You will find a new file in the current working directory your shell is running in. -If you open this file, you'll see the following content: - -.. code-block:: YAML - - /turtlesim: - ros__parameters: - background_b: 255 - background_g: 86 - background_r: 150 - qos_overrides: - /parameter_events: - publisher: - depth: 1000 - durability: volatile - history: keep_last - reliability: reliable - use_sim_time: false - -Dumping parameters comes in handy if you want to reload the node with the same parameters in the future. - -6 ros2 param load -^^^^^^^^^^^^^^^^^ - -You can load parameters from a file to a currently running node using the command: - -.. code-block:: console - - $ ros2 param load - -To load the ``turtlesim.yaml`` file generated with ``ros2 param dump`` into ``/turtlesim`` node's parameters, enter the command: - -.. code-block:: console - - $ ros2 param load /turtlesim turtlesim.yaml - Set parameter background_b successful - Set parameter background_g successful - Set parameter background_r successful - Set parameter qos_overrides./parameter_events.publisher.depth failed: parameter 'qos_overrides./parameter_events.publisher.depth' cannot be set because it is read-only - Set parameter qos_overrides./parameter_events.publisher.durability failed: parameter 'qos_overrides./parameter_events.publisher.durability' cannot be set because it is read-only - Set parameter qos_overrides./parameter_events.publisher.history failed: parameter 'qos_overrides./parameter_events.publisher.history' cannot be set because it is read-only - Set parameter qos_overrides./parameter_events.publisher.reliability failed: parameter 'qos_overrides./parameter_events.publisher.reliability' cannot be set because it is read-only - Set parameter use_sim_time successful - -.. note:: - - Read-only parameters can only be modified at startup and not afterwards, that is why there are some warnings for the "qos_overrides" parameters. - -.. _LoadParameterFileOnNodeStartup: - -7 Load parameter file on node startup -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -To start the same node using your saved parameter values, use: - -.. code-block:: console - - $ ros2 run --ros-args --params-file - -This is the same command you always use to start turtlesim, with the added flags ``--ros-args`` and ``--params-file``, followed by the file you want to load. - -Stop your running turtlesim node, and try reloading it with your saved parameters, using: - -.. code-block:: console - - $ ros2 run turtlesim turtlesim_node --ros-args --params-file turtlesim.yaml - -The turtlesim window should appear as usual, but with the purple background you set earlier. - -.. note:: - - When a parameter file is used at node startup, all parameters, including the read-only ones, will be updated. - -Summary -------- - -Nodes have parameters to define their default configuration values. -You can ``get`` and ``set`` parameter values from the command line. -You can also save the parameter settings to a file to reload them in a future session. - -Next steps ----------- - -Jumping back to ROS 2 communication methods, in the next tutorial you'll learn about :doc:`actions <../../../actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. \ No newline at end of file +.. redirect-from:: + + Tutorials/Parameters/Understanding-ROS2-Parameters + Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters + +.. _ROS2Params: + +Understanding parameters +======================== + +**Goal:** Learn how to get, set, save and reload parameters in ROS 2. + +**Tutorial level:** Beginner + +**Time:** 5 minutes + +.. contents:: Contents + :depth: 2 + :local: + +Background +---------- + +A parameter is a configuration value of a node. +You can think of parameters as node settings. +A node can store parameters as integers, floats, booleans, strings, and lists. +In ROS 2, each node maintains its own parameters. +For more background on parameters, please see :doc:`the concept document <../../../About-Parameters>`. + +Prerequisites +------------- + +This tutorial uses the :doc:`turtlesim package <../../../../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim>`. + +As always, don't forget to source ROS 2 in :doc:`every new terminal you open <../../../../Get-Started/Configuring-ROS2-Environment>`. + +Tasks +----- + +1 Setup +^^^^^^^ + +Start up the two turtlesim nodes, ``/turtlesim`` and ``/teleop_turtle``. + +Open a new terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node + +Open another terminal and run: + +.. code-block:: console + + $ ros2 run turtlesim turtle_teleop_key + + +2 ros2 param list +^^^^^^^^^^^^^^^^^ + +To see the parameters belonging to your nodes, open a new terminal and enter the command: + +.. code-block:: console + + $ ros2 param list + /teleop_turtle: + qos_overrides./parameter_events.publisher.depth + qos_overrides./parameter_events.publisher.durability + qos_overrides./parameter_events.publisher.history + qos_overrides./parameter_events.publisher.reliability + scale_angular + scale_linear + use_sim_time + /turtlesim: + background_b + background_g + background_r + qos_overrides./parameter_events.publisher.depth + qos_overrides./parameter_events.publisher.durability + qos_overrides./parameter_events.publisher.history + qos_overrides./parameter_events.publisher.reliability + use_sim_time + + +You see the node namespaces, ``/teleop_turtle`` and ``/turtlesim``, followed by each node's parameters. + +The namespaces of the parameter and its name are separated using dots as you can see, for example, in ``parameter_events.publisher.depth``. + +Every node has the parameter ``use_sim_time``; it's not unique to turtlesim. + +Based on their names, it looks like ``/turtlesim``'s parameters determine the background color of the turtlesim window using RGB color values. + +To determine a parameter's type, you can use ``ros2 param get``. + + +3 ros2 param get +^^^^^^^^^^^^^^^^ + +To display the type and current value of a parameter, use the command: + +.. code-block:: console + + $ ros2 param get + +You can also query a parameter across all nodes by omitting the node name: + +.. code-block:: console + + $ ros2 param get + +Let's find out the current value of ``/turtlesim``'s parameter ``background_g``: + +.. code-block:: console + + $ ros2 param get /turtlesim background_g + Integer value is: 86 + +Now you know ``background_g`` holds an integer value. + +If you run the same command on ``background_r`` and ``background_b``, you will get the values ``69`` and ``255``, respectively. + +You can also check the ``use_sim_time`` parameter across all nodes: + +.. code-block:: console + + $ ros2 param get use_sim_time + +This will display the parameter value for each node that has this parameter set. + +4 ros2 param set +^^^^^^^^^^^^^^^^ + +To change a parameter's value at runtime, use the command: + +.. code-block:: console + + $ ros2 param set + +Let's change ``/turtlesim``'s background color: + +.. code-block:: console + + $ ros2 param set /turtlesim background_r 150 + Set parameter successful + +The background of your turtlesim window should change colors: + +.. image:: images/set.png + +Setting parameters with the ``set`` command will only change them in your current session, not permanently. +However, you can save your settings and reload them the next time you start a node. + +5 ros2 param dump +^^^^^^^^^^^^^^^^^ + +You can view all of a node's current parameter values by using the command: + +.. code-block:: console + + $ ros2 param dump + +The command prints to the standard output (stdout) by default but you can also redirect the parameter values into a file to save them for later. +To save your current configuration of ``/turtlesim``'s parameters into the file ``turtlesim.yaml``, enter the command: + +.. code-block:: console + + $ ros2 param dump /turtlesim > turtlesim.yaml + +You will find a new file in the current working directory your shell is running in. +If you open this file, you'll see the following content: + +.. code-block:: YAML + + /turtlesim: + ros__parameters: + background_b: 255 + background_g: 86 + background_r: 150 + qos_overrides: + /parameter_events: + publisher: + depth: 1000 + durability: volatile + history: keep_last + reliability: reliable + use_sim_time: false + +Dumping parameters comes in handy if you want to reload the node with the same parameters in the future. + +6 ros2 param load +^^^^^^^^^^^^^^^^^ + +You can load parameters from a file to a currently running node using the command: + +.. code-block:: console + + $ ros2 param load + +To load the ``turtlesim.yaml`` file generated with ``ros2 param dump`` into ``/turtlesim`` node's parameters, enter the command: + +.. code-block:: console + + $ ros2 param load /turtlesim turtlesim.yaml + Set parameter background_b successful + Set parameter background_g successful + Set parameter background_r successful + Set parameter qos_overrides./parameter_events.publisher.depth failed: parameter 'qos_overrides./parameter_events.publisher.depth' cannot be set because it is read-only + Set parameter qos_overrides./parameter_events.publisher.durability failed: parameter 'qos_overrides./parameter_events.publisher.durability' cannot be set because it is read-only + Set parameter qos_overrides./parameter_events.publisher.history failed: parameter 'qos_overrides./parameter_events.publisher.history' cannot be set because it is read-only + Set parameter qos_overrides./parameter_events.publisher.reliability failed: parameter 'qos_overrides./parameter_events.publisher.reliability' cannot be set because it is read-only + Set parameter use_sim_time successful + +.. note:: + + Read-only parameters can only be modified at startup and not afterwards, that is why there are some warnings for the "qos_overrides" parameters. + +.. _LoadParameterFileOnNodeStartup: + +7 Load parameter file on node startup +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To start the same node using your saved parameter values, use: + +.. code-block:: console + + $ ros2 run --ros-args --params-file + +This is the same command you always use to start turtlesim, with the added flags ``--ros-args`` and ``--params-file``, followed by the file you want to load. + +Stop your running turtlesim node, and try reloading it with your saved parameters, using: + +.. code-block:: console + + $ ros2 run turtlesim turtlesim_node --ros-args --params-file turtlesim.yaml + +The turtlesim window should appear as usual, but with the purple background you set earlier. + +.. note:: + + When a parameter file is used at node startup, all parameters, including the read-only ones, will be updated. + +Summary +------- + +Nodes have parameters to define their default configuration values. +You can ``get`` and ``set`` parameter values from the command line. +You can also save the parameter settings to a file to reload them in a future session. + +Next steps +---------- + +Jumping back to ROS 2 communication methods, in the next tutorial you'll learn about :doc:`actions <../../../interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. \ No newline at end of file diff --git a/source/The-ROS2-Project.rst b/source/The-ROS2-Project.rst index 9a7aafc1050..4e50f16e5aa 100644 --- a/source/The-ROS2-Project.rst +++ b/source/The-ROS2-Project.rst @@ -1,5 +1,5 @@ -The ROS 2 Project -================= +ROS Community +============= Check out the resources below to learn more about the advancement of the ROS 2 project. diff --git a/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst b/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst index d041b95df4d..16676f34891 100644 --- a/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst +++ b/source/The-ROS2-Project/Contributing/Contributing-To-ROS-2-Documentation.rst @@ -558,7 +558,7 @@ The ``:doc:`` directive is used to create in-text links to other pages. .. code-block:: rst - :doc:`Quality of Service <../Tutorials/Quality-of-Service>` + :doc:`Quality of Service <../../ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service>` Note that the relative path to the file is used. diff --git a/source/The-ROS2-Project/Contributing/Developer-Guide.rst b/source/The-ROS2-Project/Contributing/Developer-Guide.rst index 9a0cd65afdd..8317420dd7f 100644 --- a/source/The-ROS2-Project/Contributing/Developer-Guide.rst +++ b/source/The-ROS2-Project/Contributing/Developer-Guide.rst @@ -219,7 +219,7 @@ API Documentation for ROS Packages API documentation for all released ROS packages can be `found here `__. We recommend using `index.ros.org `_ to search through available ROS packages to find their documentation. -If you are a ROS package developer looking for guidance on documenting your package please see :doc:`our "how to" guide on package level documentation <../../Developer-Tools/Build/Documenting-a-ROS-2-Package>`. +If you are a ROS package developer looking for guidance on documenting your package please see :doc:`our "how to" guide on package level documentation <../../Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package>`. The documentation for all released ROS 2 packages is automatically hosted on `docs.ros.org `_. Testing diff --git a/source/The-ROS2-Project/Features.rst b/source/The-ROS2-Project/Features.rst index a3492850baa..e0fea2c4bfa 100644 --- a/source/The-ROS2-Project/Features.rst +++ b/source/The-ROS2-Project/Features.rst @@ -1,104 +1,104 @@ -.. redirect-from:: - - Features - -.. _Features: - -Features Status -=============== - -The features listed below are available in the current ROS 2 release. -Unless otherwise specified, the features are available for all supported platforms (Ubuntu 24.04 (Noble), Windows 10), DDS implementations (eProsima Fast DDS, RTI Connext DDS, and Eclipse Cyclone DDS) and programming language client libraries (C++ and Python). -For planned future development, see the :doc:`Roadmap `. - -.. list-table:: - :header-rows: 1 - - * - Functionality - - Link - - Fine print - * - Discovery, transport and serialization over DDS - - `Article `__ - - - * - Support for :doc:`multiple DDS implementations <../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`, chosen at runtime - - :doc:`Concept <../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`, :doc:`How-to Guide <../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` - - Currently Eclipse Cyclone DDS, eProsima Fast DDS, and RTI Connext DDS are fully supported. - * - Common core client library that is wrapped by language-specific libraries - - :doc:`Details <../ROS-Framework/About-Client-Libraries>` - - - * - Publish/subscribe over topics - - `Sample code `__\ , `Article `__ - - - * - Clients and services - - `Sample code `__ - - - * - Set/retrieve parameters - - `Sample code `__ - - - * - ROS 1 - ROS 2 communication bridge - - `Tutorial `__ - - Available for topics and services, not yet available for actions. - * - Quality of service settings for handling non-ideal networks - - :doc:`Demo <../ROS-Framework/topics/Working-with-topics/Quality-of-Service>` - - - * - Inter- and intra-process communication using the same API - - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>` - - Currently only in C++. - * - Composition of node components at compile, link, load, or run time - - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/Composition>` - - Currently only in C++. - * - Multiple executors (at level of callback groups) in same node - - `Demo `__ - - Only in C++. - * - Support for nodes with managed lifecycles - - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/Managed-Nodes>` - - Currently only in C++. - * - DDS-Security support - - `Demo `__ - - - * - Command-line introspection tools using an extensible framework - - :doc:`Concept <../Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools>` - - - * - Launch system for coordinating multiple nodes - - :doc:`Tutorial <../Developer-Tools/Launch/Launch-system>` - - - * - Namespace support for nodes and topics - - `Article `__ - - - * - Static remapping of ROS names - - :doc:`How-to Guide <../Developer-Tools/Introspection-and-analysis/Node-arguments>` - - - * - Demos of an all-ROS 2 mobile robot - - `Demo `__ - - - * - Preliminary support for real-time code - - :doc:`Demo <../Capabilities/Motion-planning/Real-Time-Programming>`, :doc:`demo <../ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial>` - - Linux only. - Not available for Fast RTPS. - * - Preliminary support for "bare-metal" microcontrollers - - `Wiki `__ - - - * - Content filtering subscription - - :doc:`Demo <../ROS-Framework/topics/Working-with-topics/Content-Filtering-Subscription>` - - Currently only in C++. - * - Service Introspection - - :doc:`Demo <../Developer-Tools/Introspection-and-analysis/Service-Introspection>` - - - * - Action Introspection - - :doc:`Demo <../ROS-Framework/actions/Working-with-actions/Action-Introspection>` - - - * - :doc:`Pluggable buffer backends <../Concepts/Intermediate/About-Buffer-Backends>` for ``uint8[]`` fields (e.g. GPU memory transport) - - :doc:`Concept <../Concepts/Intermediate/About-Buffer-Backends>`, :doc:`How-to Guide <../How-To-Guides/Using-Buffer-Backends>`, :doc:`Demo <../Tutorials/Demos/GPU-Buffer-Transport>` - - Experimental. - Currently supported in ``rmw_fastrtps_cpp``. - User-facing backend APIs are C++-only today. - -Besides core features of the platform, the biggest impact of ROS comes from its available packages. -The following are a few high-profile packages which are available in the latest release: - -* `gazebo_ros_pkgs `__ -* `image_transport `__ -* `navigation2 `__ -* `rosbag2 `__ -* `RQt `__ -* `RViz2 `__ +.. redirect-from:: + + Features + +.. _Features: + +Features Status +=============== + +The features listed below are available in the current ROS 2 release. +Unless otherwise specified, the features are available for all supported platforms (Ubuntu 24.04 (Noble), Windows 10), DDS implementations (eProsima Fast DDS, RTI Connext DDS, and Eclipse Cyclone DDS) and programming language client libraries (C++ and Python). +For planned future development, see the :doc:`Roadmap `. + +.. list-table:: + :header-rows: 1 + + * - Functionality + - Link + - Fine print + * - Discovery, transport and serialization over DDS + - `Article `__ + - + * - Support for :doc:`multiple DDS implementations <../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`, chosen at runtime + - :doc:`Concept <../ROS-Framework/client-libraries/About-Different-Middleware-Vendors>`, :doc:`How-to Guide <../Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations>` + - Currently Eclipse Cyclone DDS, eProsima Fast DDS, and RTI Connext DDS are fully supported. + * - Common core client library that is wrapped by language-specific libraries + - :doc:`Details <../ROS-Framework/About-Client-Libraries>` + - + * - Publish/subscribe over topics + - `Sample code `__\ , `Article `__ + - + * - Clients and services + - `Sample code `__ + - + * - Set/retrieve parameters + - `Sample code `__ + - + * - ROS 1 - ROS 2 communication bridge + - `Tutorial `__ + - Available for topics and services, not yet available for actions. + * - Quality of service settings for handling non-ideal networks + - :doc:`Demo <../ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service>` + - + * - Inter- and intra-process communication using the same API + - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication>` + - Currently only in C++. + * - Composition of node components at compile, link, load, or run time + - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/Composition>` + - Currently only in C++. + * - Multiple executors (at level of callback groups) in same node + - `Demo `__ + - Only in C++. + * - Support for nodes with managed lifecycles + - :doc:`Demo <../ROS-Framework/nodes/Working-with-nodes/Managed-Nodes>` + - Currently only in C++. + * - DDS-Security support + - `Demo `__ + - + * - Command-line introspection tools using an extensible framework + - :doc:`Concept <../Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools>` + - + * - Launch system for coordinating multiple nodes + - :doc:`Tutorial <../Developer-Tools/Launch/Launch-system>` + - + * - Namespace support for nodes and topics + - `Article `__ + - + * - Static remapping of ROS names + - :doc:`How-to Guide <../Developer-Tools/Introspection-and-analysis/Node-arguments>` + - + * - Demos of an all-ROS 2 mobile robot + - `Demo `__ + - + * - Preliminary support for real-time code + - :doc:`Demo <../Capabilities/Motion-planning/Real-Time-Programming>`, :doc:`demo <../ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial>` + - Linux only. + Not available for Fast RTPS. + * - Preliminary support for "bare-metal" microcontrollers + - `Wiki `__ + - + * - Content filtering subscription + - :doc:`Demo <../ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription>` + - Currently only in C++. + * - Service Introspection + - :doc:`Demo <../Developer-Tools/Introspection-and-analysis/Service-Introspection>` + - + * - Action Introspection + - :doc:`Demo <../ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection>` + - + * - :doc:`Pluggable buffer backends <../Concepts/Intermediate/About-Buffer-Backends>` for ``uint8[]`` fields (e.g. GPU memory transport) + - :doc:`Concept <../Concepts/Intermediate/About-Buffer-Backends>`, :doc:`How-to Guide <../How-To-Guides/Using-Buffer-Backends>`, :doc:`Demo <../Tutorials/Demos/GPU-Buffer-Transport>` + - Experimental. + Currently supported in ``rmw_fastrtps_cpp``. + User-facing backend APIs are C++-only today. + +Besides core features of the platform, the biggest impact of ROS comes from its available packages. +The following are a few high-profile packages which are available in the latest release: + +* `gazebo_ros_pkgs `__ +* `image_transport `__ +* `navigation2 `__ +* `rosbag2 `__ +* `RQt `__ +* `RViz2 `__ diff --git a/source/Tutorials/Advanced/Writing-a-Buffer-Backend.rst b/source/Tutorials/Advanced/Writing-a-Buffer-Backend.rst index 333628f7c3a..8ac98a67354 100644 --- a/source/Tutorials/Advanced/Writing-a-Buffer-Backend.rst +++ b/source/Tutorials/Advanced/Writing-a-Buffer-Backend.rst @@ -41,7 +41,7 @@ variable-length primitive array fields. If your goal is to reduce copies within CPU memory, you are almost certainly looking for :doc:`intra-process communication <../Demos/Intra-Process-Communication>` or -:doc:`loaned messages <../../How-To-Guides/Configure-ZeroCopy-loaned-messages>` +:doc:`loaned messages <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages>` instead. Reference implementations diff --git a/source/Tutorials/Demos/GPU-Buffer-Transport.rst b/source/Tutorials/Demos/GPU-Buffer-Transport.rst index 5e10a1a6815..e1f447bec33 100644 --- a/source/Tutorials/Demos/GPU-Buffer-Transport.rst +++ b/source/Tutorials/Demos/GPU-Buffer-Transport.rst @@ -64,7 +64,7 @@ You need: * A CUDA-capable GPU and the CUDA Toolkit (>= 11.8). * SDL2, GLEW, OpenGL, X11 development packages. * A ROS 2 Lyrical Luth or later source workspace. - See the :doc:`Installation instructions <../../Installation>` for the + See the :doc:`Installation instructions <../../Get-Started/Installation>` for the canonical source-build flow. * ``rmw_fastrtps_cpp`` for the non-CPU buffer path. diff --git a/source/Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python.rst b/source/Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python.rst index 356cfed6cf5..3fa193962e5 100644 --- a/source/Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python.rst +++ b/source/Tutorials/Intermediate/Writing-An-Async-Node-With-Asyncio-Python.rst @@ -33,7 +33,7 @@ Keep in mind that a sync callback can't ``await`` anything. Prerequisites ------------- -- You should have completed the :doc:`beginner service and client tutorial <../Beginner-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>`. +- You should have completed the :doc:`beginner service and client tutorial <../../ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client>`. - You should be comfortable with basic :py:mod:`asyncio` concepts like `async def and await `_ and :py:func:`asyncio.run`. - ``AsyncNode`` currently lives in ``rclpy.experimental`` and requires Python 3.12 or newer. @@ -43,7 +43,7 @@ Tasks 1 Create a package ^^^^^^^^^^^^^^^^^^ -Open a new terminal and :doc:`source your ROS 2 installation <../Beginner-CLI-Tools/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. +Open a new terminal and :doc:`source your ROS 2 installation <../../Get-Started/Configuring-ROS2-Environment>` so that ``ros2`` commands will work. Navigate into the ``ros2_ws/src`` directory created in a :ref:`previous tutorial ` and create a new package: @@ -454,7 +454,7 @@ Because the call is awaited, the coroutine doesn't block the node — other call .. note:: - The standard ``Node`` utilizes :doc:`callback groups <../../How-To-Guides/Using-callback-groups>` to manage callback execution. + The standard ``Node`` utilizes :doc:`callback groups <../../ROS-Framework/nodes/Working-with-nodes/Using-callback-groups>` to manage callback execution. Any attempt to perform a service call from within a callback with the default ``MutuallyExclusiveCallbackGroup`` would result in deadlocking the node. With ``AsyncNode``, all callbacks run cooperatively on the ``asyncio`` event loop, so ``await client.call(request)`` works from any callback without additional configuration. From 36f725e90a96e43ddd1cdd98467b3d7da6cf96c6 Mon Sep 17 00:00:00 2001 From: Denise Marshall Date: Wed, 3 Jun 2026 10:02:39 +0000 Subject: [PATCH 15/20] Fix capitalisation --- source/Developer-Tools.rst | 2 +- source/Developer-Tools/Build/Package-Docs.rst | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/source/Developer-Tools.rst b/source/Developer-Tools.rst index 613669aa6f2..5d418de6b40 100644 --- a/source/Developer-Tools.rst +++ b/source/Developer-Tools.rst @@ -1,4 +1,4 @@ -Developer Tools +Developer tools =============== diff --git a/source/Developer-Tools/Build/Package-Docs.rst b/source/Developer-Tools/Build/Package-Docs.rst index ab998e2e8e2..d5304f3e0f4 100644 --- a/source/Developer-Tools/Build/Package-Docs.rst +++ b/source/Developer-Tools/Build/Package-Docs.rst @@ -1,8 +1,9 @@ .. redirect-from:: Package-Docs -Package Docs -============ + +Package documentation +===================== ROS package documentation, that is to say documentation for specific packages you install via apt or some other tool, can be found in multiple places. Here is a brief list of where to look for specific ROS package documentation. From 8e52a58882c8096a06fec2ebb34e656712255c2b Mon Sep 17 00:00:00 2001 From: Tully Foote Date: Fri, 5 Jun 2026 14:16:51 -0400 Subject: [PATCH 16/20] Add missing executable bit for linting Signed-off-by: Tully Foote --- sphinx-lint-with-ros | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 sphinx-lint-with-ros diff --git a/sphinx-lint-with-ros b/sphinx-lint-with-ros old mode 100644 new mode 100755 From 12fdbdeeddb7ae3f051a793361d0f1eab95a446a Mon Sep 17 00:00:00 2001 From: Tully Foote Date: Fri, 5 Jun 2026 14:26:57 -0400 Subject: [PATCH 17/20] Getting the doc8 to pass except D002 D004 and D005 errors Signed-off-by: Tully Foote --- Makefile | 2 +- source/ROS-Framework/About-Client-Libraries.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index aebff051af3..a33ff9ff627 100644 --- a/Makefile +++ b/Makefile @@ -30,7 +30,7 @@ lint: ./sphinx-lint-with-ros source test: - doc8 --ignore D001 --ignore-path build + doc8 --ignore D001 --ignore-path $(OUT) -- $(SOURCE) test-tools: $(PYTHON) -m pytest test/ diff --git a/source/ROS-Framework/About-Client-Libraries.rst b/source/ROS-Framework/About-Client-Libraries.rst index c3e5bed4050..a2d8787ccf4 100644 --- a/source/ROS-Framework/About-Client-Libraries.rst +++ b/source/ROS-Framework/About-Client-Libraries.rst @@ -4,7 +4,7 @@ Concepts/About-ROS-2-Client-Libraries Concepts/Basic/About-Client-Libraries -.. include:: ../../../global_substitutions.txt +.. include:: ../../global_substitutions.txt Client libraries ================ @@ -133,4 +133,4 @@ However, naming conventions and behaviors are not always consistent between clie Summary ------- -By utilizing the common core ROS client library, client libraries written in a variety of programming languages are easier to write and have more consistent behavior. \ No newline at end of file +By utilizing the common core ROS client library, client libraries written in a variety of programming languages are easier to write and have more consistent behavior. From da9818ff674949b4c6510457030639432efd0133 Mon Sep 17 00:00:00 2001 From: Tully Foote Date: Fri, 5 Jun 2026 14:59:12 -0400 Subject: [PATCH 18/20] fix spell checking path Signed-off-by: Tully Foote --- codespell.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/codespell.cfg b/codespell.cfg index adae4875aec..807d25420b3 100644 --- a/codespell.cfg +++ b/codespell.cfg @@ -15,4 +15,4 @@ dictionary = codespell_dictionary.txt,- # *-Changelog.rst files are generated by commit history that could include some misspellings, # but we should keep the original commit messages here. # Besides, it includes names of authors and contributors, which compile up the false alarms. -skip = source/Releases/* +skip = source/Get-Started/Releases/* From b9f58e8ceb3d5c94891d83868cde1d594038864b Mon Sep 17 00:00:00 2001 From: Denise Marshall Date: Mon, 8 Jun 2026 11:42:13 +0000 Subject: [PATCH 19/20] Ensure every RST file has a single final newline --- source/Capabilities.rst | 2 +- source/Capabilities/About-Manipulation.rst | 2 +- source/Capabilities/About-Motion-planning.rst | 2 +- source/Capabilities/About-Navigation.rst | 2 +- source/Capabilities/About-Perception.rst | 2 +- source/Capabilities/About-Simulation.rst | 2 +- source/Capabilities/Motion-planning/Real-Time-Programming.rst | 2 +- ...Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst | 2 +- .../URDF/Building-a-Movable-Robot-Model-with-URDF.rst | 2 +- .../Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst | 2 +- source/Capabilities/Simulation/URDF/Exporting-an-URDF-File.rst | 2 +- source/Capabilities/Simulation/URDF/URDF-Main.rst | 2 +- .../URDF/Using-URDF-with-Robot-State-Publisher-cpp.rst | 2 +- .../URDF/Using-URDF-with-Robot-State-Publisher-py.rst | 2 +- source/Capabilities/Simulation/dummy-robot/dummy-robot-demo.rst | 2 +- source/Developer-Tools.rst | 2 +- source/Developer-Tools/About-Debugging.rst | 2 +- source/Developer-Tools/About-Launch.rst | 2 +- source/Developer-Tools/About-introspection-and-analysis.rst | 2 +- source/Developer-Tools/About-package-documentation.rst | 2 +- source/Developer-Tools/Build/About-Build-System.rst | 2 +- source/Developer-Tools/Build/About-Cross-Compilation.rst | 2 +- source/Developer-Tools/Build/Ament-CMake-Documentation.rst | 2 +- .../Developer-Tools/Build/Ament-CMake-Python-Documentation.rst | 2 +- source/Developer-Tools/Build/Ament-Lint-For-Clean-Code.rst | 2 +- source/Developer-Tools/Build/Building-a-Custom-Deb-Package.rst | 2 +- source/Developer-Tools/Build/Core-maintainer-guide.rst | 2 +- source/Developer-Tools/Build/Cross-compilation.rst | 2 +- source/Developer-Tools/Build/DDS-tuning.rst | 2 +- .../Build/Deployment-Guidelines/Deployment-Guidelines.rst | 2 +- source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst | 2 +- .../Eclipse-Oxygen-with-ROS-2-and-rviz2.rst | 2 +- source/Developer-Tools/Build/Package-Docs.rst | 2 +- source/Developer-Tools/Build/Releasing/First-Time-Release.rst | 2 +- source/Developer-Tools/Build/Releasing/Index-Your-Packages.rst | 2 +- .../Developer-Tools/Build/Releasing/Release-Team-Repository.rst | 2 +- source/Developer-Tools/Build/Releasing/Release-Track.rst | 2 +- source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst | 2 +- source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst | 2 +- .../Developer-Tools/Build/Releasing/_Bump-Package-Version.rst | 2 +- source/Developer-Tools/Build/Releasing/_Clean-Up-Changelog.rst | 2 +- .../Build/Releasing/_Ensure-Repositories-Are-Up-To-Date.rst | 2 +- .../Developer-Tools/Build/Releasing/_Install-Dependencies.rst | 2 +- source/Developer-Tools/Build/Releasing/_Next-Steps.rst | 2 +- .../Developer-Tools/Build/Releasing/_Personal-Access-Token.rst | 2 +- .../Run-2-nodes-in-single-or-separate-docker-containers.rst | 2 +- .../Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst | 2 +- .../Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst | 2 +- source/Developer-Tools/Build/The-Keystore.rst | 2 +- source/Developer-Tools/Build/Using-Python-Packages.rst | 2 +- source/Developer-Tools/Build/Using-Variants.rst | 2 +- .../Using-Xacro-to-Clean-Up-a-URDF-File.rst | 2 +- .../Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst | 2 +- .../Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst | 2 +- .../Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst | 2 +- source/Developer-Tools/Debugging/ROS-2-IDEs.rst | 2 +- .../Introspection-and-analysis/About-Command-Line-Tools.rst | 2 +- .../Introspection-and-analysis/About-Security.rst | 2 +- .../Discovery-Server/Discovery-Server.rst | 2 +- .../Introspection-and-analysis/FastDDS-Configuration.rst | 2 +- .../Introspection-and-analysis/Improved-Dynamic-Discovery.rst | 2 +- .../Logging-and-logger-configuration.rst | 2 +- .../Introspection-and-analysis/Node-arguments.rst | 2 +- .../Publishing-Messages-Using-YAML-Files.rst | 2 +- .../Introspection-and-analysis/Security/Access-Controls.rst | 2 +- .../Introspection-and-analysis/Security/Examine-Traffic.rst | 2 +- .../Security/Introducing-ros2-security.rst | 2 +- .../Introspection-and-analysis/Security/Security-Main.rst | 2 +- .../Introspection-and-analysis/Security/Security-on-Two.rst | 2 +- .../Introspection-and-analysis/Service-Introspection.rst | 2 +- .../Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst | 2 +- .../Tracing/ROS2-Tracing-Trace-and-Analyze.rst | 2 +- source/Developer-Tools/Launch/Creating-Launch-Files.rst | 2 +- source/Developer-Tools/Launch/Launch-Main.rst | 2 +- source/Developer-Tools/Launch/Launch-file-different-formats.rst | 2 +- source/Developer-Tools/Launch/Launch-system.rst | 2 +- source/Developer-Tools/Launch/Launching-composable-nodes.rst | 2 +- source/Developer-Tools/Launch/Using-Event-Handlers.rst | 2 +- .../Launch/Using-ROS2-Launch-For-Large-Projects.rst | 2 +- source/Developer-Tools/Launch/Using-Substitutions.rst | 2 +- .../Package-documentation/Documenting-a-ROS-2-Package.rst | 2 +- .../Overriding-QoS-Policies-For-Recording-And-Playback.rst | 2 +- source/Developer-Tools/Testing/Testing.rst | 2 +- source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst | 2 +- source/Developer-Tools/Testing/Testing/CLI.rst | 2 +- source/Developer-Tools/Testing/Testing/Integration.rst | 2 +- source/Developer-Tools/Testing/Testing/Python.rst | 2 +- source/Developer-Tools/Testing/Testing/Testing-Main.rst | 2 +- source/Developer-Tools/Visualization/About-RQt.rst | 2 +- .../RViz/Marker-Display-types/Marker-Display-types.rst | 2 +- .../RViz/RViz-Custom-Display/RViz-Custom-Display.rst | 2 +- .../Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst | 2 +- source/Developer-Tools/Visualization/RViz/RViz-Main.rst | 2 +- .../Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst | 2 +- .../Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst | 2 +- source/Get-Started.rst | 2 +- source/Get-Started/About-ROS/About-ROS.rst | 2 +- source/Get-Started/Configuring-ROS2-Environment.rst | 2 +- source/Get-Started/Installation.rst | 2 +- source/Get-Started/Installation/Alternatives.rst | 2 +- .../Installation/Alternatives/Latest-Development-Setup.rst | 2 +- .../Installation/Alternatives/Maintaining-a-Source-Checkout.rst | 2 +- .../Installation/Alternatives/RHEL-Development-Setup.rst | 2 +- .../Installation/Alternatives/RHEL-Install-Binary.rst | 2 +- .../Installation/Alternatives/Ubuntu-Development-Setup.rst | 2 +- .../Installation/Alternatives/Ubuntu-Install-Binary.rst | 2 +- .../Installation/Alternatives/Windows-Development-Setup.rst | 2 +- .../Installation/Alternatives/macOS-Development-Setup.rst | 2 +- .../Get-Started/Installation/Installation-Troubleshooting.rst | 2 +- source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst | 2 +- source/Get-Started/Installation/RHEL-Install-RPMs.rst | 2 +- source/Get-Started/Installation/RMW-Implementations.rst | 2 +- .../Installation/RMW-Implementations/DDS-Implementations.rst | 2 +- .../DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst | 2 +- .../DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst | 2 +- .../DDS-Implementations/Working-with-RTI-Connext-DDS.rst | 2 +- .../DDS-Implementations/Working-with-eProsima-Fast-DDS.rst | 2 +- .../RMW-Implementations/Non-DDS-Implementations.rst | 2 +- .../Working-with-multiple-RMW-implementations.rst | 2 +- source/Get-Started/Installation/ROS-2-Mirrors.rst | 2 +- source/Get-Started/Installation/Windows-Install-Binary.rst | 2 +- source/Get-Started/Installation/_Apt-Repositories.rst | 2 +- source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst | 2 +- source/Get-Started/Installation/_Dnf-Update-Admonition.rst | 2 +- source/Get-Started/Installation/_RHEL-Set-Locale.rst | 2 +- source/Get-Started/Installation/_Ubuntu-Set-Locale.rst | 2 +- source/Get-Started/Installation/_rosdep_Linux_Mint.rst | 2 +- .../Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst | 2 +- source/Get-Started/Releases.rst | 2 +- source/Get-Started/Releases/Alpha-Overview.rst | 2 +- source/Get-Started/Releases/Beta1-Overview.rst | 2 +- source/Get-Started/Releases/Beta2-Overview.rst | 2 +- source/Get-Started/Releases/Beta3-Overview.rst | 2 +- source/Get-Started/Releases/End-of-Life.rst | 2 +- .../Releases/Galactic-Geochelone-Complete-Changelog.rst | 2 +- .../Releases/Humble-Hawksbill-Complete-Changelog.rst | 2 +- source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst | 2 +- .../Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst | 2 +- source/Get-Started/Releases/Lyrical-Luth-Complete-Changelog.rst | 2 -- source/Get-Started/Releases/Release-Ardent-Apalone.rst | 2 +- source/Get-Started/Releases/Release-Bouncy-Bolson.rst | 2 +- source/Get-Started/Releases/Release-Crystal-Clemmys.rst | 2 +- source/Get-Started/Releases/Release-Dashing-Diademata.rst | 2 +- source/Get-Started/Releases/Release-Eloquent-Elusor.rst | 2 +- source/Get-Started/Releases/Release-Foxy-Fitzroy.rst | 2 +- source/Get-Started/Releases/Release-Galactic-Geochelone.rst | 2 +- source/Get-Started/Releases/Release-Humble-Hawksbill.rst | 2 +- source/Get-Started/Releases/Release-Iron-Irwini.rst | 2 +- source/Get-Started/Releases/Release-Jazzy-Jalisco.rst | 2 +- source/Get-Started/Releases/Release-Kilted-Kaiju.rst | 2 +- source/Get-Started/Releases/Release-Process.rst | 2 +- source/Get-Started/Releases/Release-Rolling-Ridley.rst | 2 +- .../Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst | 2 +- source/Integrations-and-related/Related-Projects.rst | 2 +- .../Related-Projects/Intel-ROS2-Projects.rst | 2 +- .../Related-Projects/Nvidia-ROS2-Projects.rst | 2 +- .../Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst | 2 +- .../Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst | 2 +- source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst | 2 +- .../Simulators/Gazebo/Simulation-Gazebo.rst | 2 +- .../Simulators/MVSim/Defining-Worlds-MVSim.rst | 2 +- .../Simulators/MVSim/Getting-Started-MVSim.rst | 2 +- .../Simulators/MVSim/Simulation-MVSim.rst | 2 +- source/Integrations-and-related/Simulators/Simulation-Main.rst | 2 +- .../Simulators/Webots/Installation-MacOS.rst | 2 +- .../Simulators/Webots/Installation-Ubuntu.rst | 2 +- .../Simulators/Webots/Installation-Windows.rst | 2 +- .../Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst | 2 +- .../Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst | 2 +- .../Simulators/Webots/Simulation-Reset-Handler.rst | 2 +- .../Simulators/Webots/Simulation-Supervisor.rst | 2 +- .../Simulators/Webots/Simulation-Webots.rst | 2 +- source/Migration-and-Upgrades/Migrating-from-ROS1.rst | 2 +- .../Migrating-from-ROS1/Migrating-CPP-Package-Example.rst | 2 +- .../Migrating-from-ROS1/Migrating-CPP-Packages.rst | 2 +- .../Migrating-from-ROS1/Migrating-Interfaces.rst | 2 +- .../Migrating-from-ROS1/Migrating-Launch-Files.rst | 2 +- .../Migrating-from-ROS1/Migrating-Package-XML.rst | 2 +- .../Migrating-from-ROS1/Migrating-Packages.rst | 2 +- .../Migrating-from-ROS1/Migrating-Parameters.rst | 2 +- .../Migrating-from-ROS1/Migrating-Python-Package-Example.rst | 2 +- .../Migrating-from-ROS1/Migrating-Python-Packages.rst | 2 +- .../Migrating-from-ROS1/Migrating-Scripts.rst | 2 +- source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst | 2 +- .../Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst | 2 +- source/ROS-Framework/About-Parameters.rst | 2 +- .../client-libraries/About-Different-Middleware-Vendors.rst | 2 +- .../client-libraries/About-Executors/About-Executors.rst | 2 +- .../About-Internal-Interfaces/About-Internal-Interfaces.rst | 2 +- .../client-libraries/Working-with-Client-Libraries.rst | 2 +- .../Allocator-Template-Tutorial.rst | 2 +- .../Working-with-Client-Libraries/Colcon-Tutorial.rst | 2 +- .../Configure-ZeroCopy-loaned-messages.rst | 2 +- .../Creating-A-Workspace/Creating-A-Workspace.rst | 2 +- .../Creating-An-RMW-Implementation.rst | 2 +- .../Creating-Your-First-ROS2-Package.rst | 2 +- .../Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst | 2 +- .../Getting-Started-With-Ros2doctor.rst | 2 +- .../Working-with-Client-Libraries/Pluginlib.rst | 2 +- .../Reading-From-A-Bag-File-CPP.rst | 2 +- .../Reading-From-A-Bag-File-Python.rst | 2 +- .../Recording-A-Bag-From-Your-Own-Node-CPP.rst | 2 +- .../Recording-A-Bag-From-Your-Own-Node-Py.rst | 2 +- .../client-libraries/Working-with-Client-Libraries/Rosdep.rst | 2 +- .../Single-Package-Define-And-Use-Interface.rst | 2 +- .../Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst | 2 +- .../Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst | 2 +- .../Tf2/Learning-About-Tf2-And-Time-Cpp.rst | 2 +- .../Working-with-Client-Libraries/Tf2/Tf2-Main.rst | 2 +- .../Tf2/Time-Travel-With-Tf2-Cpp.rst | 2 +- .../Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst | 2 +- .../Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst | 2 +- .../Tf2/Writing-A-Tf2-Broadcaster-Py.rst | 2 +- .../Tf2/Writing-A-Tf2-Listener-Cpp.rst | 2 +- .../Tf2/Writing-A-Tf2-Listener-Py.rst | 2 +- .../Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst | 2 +- .../Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst | 2 +- .../Using-Parameters-In-A-Class-CPP.rst | 2 +- .../Using-Parameters-In-A-Class-Python.rst | 2 +- .../Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst | 2 +- .../Writing-A-Simple-Cpp-Service-And-Client.rst | 2 +- .../Writing-A-Simple-Py-Publisher-And-Subscriber.rst | 2 +- .../Writing-A-Simple-Py-Service-And-Client.rst | 2 +- source/ROS-Framework/interfaces/About-Interfaces.rst | 2 +- source/ROS-Framework/interfaces/About-Services.rst | 2 +- source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst | 2 +- source/ROS-Framework/interfaces/Topics-Services-Actions.rst | 2 +- .../Introduction-To-Tf2/Introduction-To-Tf2.rst | 2 +- .../Working-with-interfaces/Quaternion-Fundamentals.rst | 2 +- .../Recording-And-Playing-Back-Data.rst | 2 +- .../actions/Working-with-actions/Action-Introspection.rst | 2 +- .../actions/Working-with-actions/Creating-an-Action.rst | 2 +- .../Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst | 2 +- .../Writing-an-Action-Server-Client/Cpp.rst | 2 +- .../Working-with-actions/Writing-an-Action-Server-Client/Py.rst | 2 +- .../interfaces/services/Working-with-services/Sync-Vs-Async.rst | 2 +- .../Understanding-ROS2-Services/Understanding-ROS2-Services.rst | 2 +- .../interfaces/topics/About-Quality-of-Service-Settings.rst | 2 +- .../ROS-Framework/interfaces/topics/About-Topic-Statistics.rst | 2 +- .../Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst | 2 +- source/ROS-Framework/interfaces/topics/Working-with-topics.rst | 2 +- .../Working-with-topics/Content-Filtering-Subscription.rst | 2 +- .../topics/Working-with-topics/Quality-of-Service.rst | 2 +- .../Topic-Keys/Filtered-Topic-Keys-Tutorial.rst | 2 +- .../Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst | 2 +- .../topics/Working-with-topics/Wait-for-Acknowledgment.rst | 2 +- source/ROS-Framework/nodes/About-Composition.rst | 2 +- source/ROS-Framework/nodes/About-Discovery.rst | 2 +- source/ROS-Framework/nodes/About-Domain-ID.rst | 2 +- source/ROS-Framework/nodes/About-Logging/About-Logging.rst | 2 +- source/ROS-Framework/nodes/Working-with-nodes.rst | 2 +- source/ROS-Framework/nodes/Working-with-nodes/Composition.rst | 2 +- .../Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst | 2 +- source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst | 2 +- .../Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst | 2 +- .../Working-with-nodes/Using-Node-Interfaces-Template-Class.rst | 2 +- .../Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst | 2 +- .../nodes/Working-with-nodes/Using-callback-groups.rst | 2 +- .../nodes/Working-with-nodes/Writing-a-Composable-Node.rst | 2 +- .../intra-process/Intra-Process-Communication.rst | 2 +- .../Monitoring-For-Parameter-Changes-CPP.rst | 2 +- .../Monitoring-For-Parameter-Changes-Python.rst | 2 +- .../Understanding-ROS2-Parameters.rst | 2 +- .../parameters/Working-with-parameters/Using-ros2-param.rst | 2 +- 264 files changed, 263 insertions(+), 265 deletions(-) diff --git a/source/Capabilities.rst b/source/Capabilities.rst index f986b2fc4c4..5a8f9e17642 100644 --- a/source/Capabilities.rst +++ b/source/Capabilities.rst @@ -13,4 +13,4 @@ PLACEHOLDER Capabilities/About-Motion-planning Capabilities/About-Navigation Capabilities/About-Manipulation - Capabilities/About-Perception \ No newline at end of file + Capabilities/About-Perception diff --git a/source/Capabilities/About-Manipulation.rst b/source/Capabilities/About-Manipulation.rst index 101f58da71b..5b0e543789c 100644 --- a/source/Capabilities/About-Manipulation.rst +++ b/source/Capabilities/About-Manipulation.rst @@ -10,4 +10,4 @@ Manipulation .. contents:: Table of Contents :local: -PLACEHOLDER \ No newline at end of file +PLACEHOLDER diff --git a/source/Capabilities/About-Motion-planning.rst b/source/Capabilities/About-Motion-planning.rst index a620c3a3973..695e36a0ae6 100644 --- a/source/Capabilities/About-Motion-planning.rst +++ b/source/Capabilities/About-Motion-planning.rst @@ -10,4 +10,4 @@ Motion planning .. contents:: Table of Contents :local: -PLACEHOLDER \ No newline at end of file +PLACEHOLDER diff --git a/source/Capabilities/About-Navigation.rst b/source/Capabilities/About-Navigation.rst index 31c58256513..e1268e3ad82 100644 --- a/source/Capabilities/About-Navigation.rst +++ b/source/Capabilities/About-Navigation.rst @@ -10,4 +10,4 @@ Navigation .. contents:: Table of Contents :local: -PLACEHOLDER \ No newline at end of file +PLACEHOLDER diff --git a/source/Capabilities/About-Perception.rst b/source/Capabilities/About-Perception.rst index 28c32d6323d..eee53637937 100644 --- a/source/Capabilities/About-Perception.rst +++ b/source/Capabilities/About-Perception.rst @@ -10,4 +10,4 @@ Perception .. contents:: Table of Contents :local: -PLACEHOLDER \ No newline at end of file +PLACEHOLDER diff --git a/source/Capabilities/About-Simulation.rst b/source/Capabilities/About-Simulation.rst index b1798aaaf54..231f53bdd6f 100644 --- a/source/Capabilities/About-Simulation.rst +++ b/source/Capabilities/About-Simulation.rst @@ -11,4 +11,4 @@ Simulation .. contents:: Table of Contents :local: -PLACEHOLDER \ No newline at end of file +PLACEHOLDER diff --git a/source/Capabilities/Motion-planning/Real-Time-Programming.rst b/source/Capabilities/Motion-planning/Real-Time-Programming.rst index 259897fa49f..7947915ce9d 100644 --- a/source/Capabilities/Motion-planning/Real-Time-Programming.rst +++ b/source/Capabilities/Motion-planning/Real-Time-Programming.rst @@ -248,4 +248,4 @@ This script will produce a number of files: pendulum_demo_results_plot_majflts.svg pendulum_demo_results_plot_minflts.svg -You can view these plots in an image viewer of your choice. \ No newline at end of file +You can view these plots in an image viewer of your choice. diff --git a/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst b/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst index 7448d90cb4a..3471827e798 100644 --- a/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst +++ b/source/Capabilities/Simulation/URDF/Adding-Physical-and-Collision-Properties-to-a-URDF-Model.rst @@ -145,4 +145,4 @@ Check out the `spec `_, as they are not inc Next Steps ---------- -Reduce the amount of code and annoying math you have to do by :doc:`using xacro <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`. \ No newline at end of file +Reduce the amount of code and annoying math you have to do by :doc:`using xacro <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`. diff --git a/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst b/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst index 5feeb429540..6cddb893a7b 100644 --- a/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst +++ b/source/Capabilities/Simulation/URDF/Building-a-Movable-Robot-Model-with-URDF.rst @@ -119,4 +119,4 @@ The resulting transform tree is then used to display all of the shapes in Rviz. Next steps ---------- -Now that you have a visibly functional model, you can :doc:`add in some physical properties `, or :doc:`start using xacro to simplify your code <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`. \ No newline at end of file +Now that you have a visibly functional model, you can :doc:`add in some physical properties `, or :doc:`start using xacro to simplify your code <../../../Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File>`. diff --git a/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst b/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst index 6f644f29c65..5338972a1b4 100644 --- a/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst +++ b/source/Capabilities/Simulation/URDF/Building-a-Visual-Robot-Model-with-URDF-from-Scratch.rst @@ -575,4 +575,4 @@ The meshes for this tutorial are located within the ``urdf_tutorial`` package, i There you have it. A R2D2-like URDF model. -Now you can continue on to the next step, :doc:`making it move `. \ No newline at end of file +Now you can continue on to the next step, :doc:`making it move `. diff --git a/source/Capabilities/Simulation/URDF/Exporting-an-URDF-File.rst b/source/Capabilities/Simulation/URDF/Exporting-an-URDF-File.rst index 1c04366fab5..2bf33cc134d 100644 --- a/source/Capabilities/Simulation/URDF/Exporting-an-URDF-File.rst +++ b/source/Capabilities/Simulation/URDF/Exporting-an-URDF-File.rst @@ -52,4 +52,4 @@ However, we figured it would be helpful to produce a list of available URDF expo * `View SDF Models in RViz `_ * `Jupyterlab URDF Viewer `_ -If you have an URDF tool you like please consider adding it to the list above! \ No newline at end of file +If you have an URDF tool you like please consider adding it to the list above! diff --git a/source/Capabilities/Simulation/URDF/URDF-Main.rst b/source/Capabilities/Simulation/URDF/URDF-Main.rst index 76dd4ecbfc7..d6d01a71bfa 100644 --- a/source/Capabilities/Simulation/URDF/URDF-Main.rst +++ b/source/Capabilities/Simulation/URDF/URDF-Main.rst @@ -23,4 +23,4 @@ A URDF file follows the XML format as described on `here `__ -from which some content was reused. \ No newline at end of file +from which some content was reused. diff --git a/source/Capabilities/Simulation/dummy-robot/dummy-robot-demo.rst b/source/Capabilities/Simulation/dummy-robot/dummy-robot-demo.rst index 66b210645c9..e8036fd7ac8 100644 --- a/source/Capabilities/Simulation/dummy-robot/dummy-robot-demo.rst +++ b/source/Capabilities/Simulation/dummy-robot/dummy-robot-demo.rst @@ -87,4 +87,4 @@ The ``robot_state_publisher`` is doing the actual interesting work. It parses the given URDF file, extracts the robot model and listens to the incoming joint states. With this information, it publishes TF values for our robot which we visualize in RViz. -Hooray! \ No newline at end of file +Hooray! diff --git a/source/Developer-Tools.rst b/source/Developer-Tools.rst index 5d418de6b40..a12ef401305 100644 --- a/source/Developer-Tools.rst +++ b/source/Developer-Tools.rst @@ -22,4 +22,4 @@ PLACEHOLDER * Debugging * Builds * Visualization -* Package documentation \ No newline at end of file +* Package documentation diff --git a/source/Developer-Tools/About-Debugging.rst b/source/Developer-Tools/About-Debugging.rst index e2ccff6bbd1..447b89e4bc7 100644 --- a/source/Developer-Tools/About-Debugging.rst +++ b/source/Developer-Tools/About-Debugging.rst @@ -9,4 +9,4 @@ PLACEHOLDER Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems Debugging/ROS-2-IDEs Debugging/Getting-Backtraces-in-ROS-2 - Debugging/Building-ROS-2-with-Tracing \ No newline at end of file + Debugging/Building-ROS-2-with-Tracing diff --git a/source/Developer-Tools/About-Launch.rst b/source/Developer-Tools/About-Launch.rst index a77a83766fa..18b0b5c983a 100644 --- a/source/Developer-Tools/About-Launch.rst +++ b/source/Developer-Tools/About-Launch.rst @@ -28,4 +28,4 @@ This launch file can then be run using the ``ros2 launch`` command, and all of t To get started writing and using launch files, see `the launch tutorials <../../Tutorials/Intermediate/Launch/Launch-Main>`. -For more detailed information, see `the launch documentation `__. \ No newline at end of file +For more detailed information, see `the launch documentation `__. diff --git a/source/Developer-Tools/About-introspection-and-analysis.rst b/source/Developer-Tools/About-introspection-and-analysis.rst index 73f50a41d7f..56b7b6d9414 100644 --- a/source/Developer-Tools/About-introspection-and-analysis.rst +++ b/source/Developer-Tools/About-introspection-and-analysis.rst @@ -17,4 +17,4 @@ PLACEHOLDER Introspection-and-analysis/Security/Security-Main Introspection-and-analysis/Logging-and-logger-configuration Introspection-and-analysis/Service-Introspection - Introspection-and-analysis/Node-arguments \ No newline at end of file + Introspection-and-analysis/Node-arguments diff --git a/source/Developer-Tools/About-package-documentation.rst b/source/Developer-Tools/About-package-documentation.rst index 27dfb22b13f..0686daf2b3b 100644 --- a/source/Developer-Tools/About-package-documentation.rst +++ b/source/Developer-Tools/About-package-documentation.rst @@ -7,4 +7,4 @@ PLACEHOLDER .. toctree:: :maxdepth: 3 - Package-documentation/Documenting-a-ROS-2-Package \ No newline at end of file + Package-documentation/Documenting-a-ROS-2-Package diff --git a/source/Developer-Tools/Build/About-Build-System.rst b/source/Developer-Tools/Build/About-Build-System.rst index 4a40594aaed..c34599cb06d 100644 --- a/source/Developer-Tools/Build/About-Build-System.rst +++ b/source/Developer-Tools/Build/About-Build-System.rst @@ -149,4 +149,4 @@ Meta-build tool This is a piece of software that knows how to topologically order a group of packages, and build or test them in the correct dependency order. This software will call into the Build Tool to do the actual work of compiling, testing, and installing the package. -In ROS 2, the tool named `colcon `__ is used for this. \ No newline at end of file +In ROS 2, the tool named `colcon `__ is used for this. diff --git a/source/Developer-Tools/Build/About-Cross-Compilation.rst b/source/Developer-Tools/Build/About-Cross-Compilation.rst index 26d325d21c1..7295416d975 100644 --- a/source/Developer-Tools/Build/About-Cross-Compilation.rst +++ b/source/Developer-Tools/Build/About-Cross-Compilation.rst @@ -32,4 +32,4 @@ There are a number of factors which make this process more complex: Alternatives ------------ -An alternative to cross-compilation is to `build multi-platform Docker images `__ using ``docker buildx``. \ No newline at end of file +An alternative to cross-compilation is to `build multi-platform Docker images `__ using ``docker buildx``. diff --git a/source/Developer-Tools/Build/Ament-CMake-Documentation.rst b/source/Developer-Tools/Build/Ament-CMake-Documentation.rst index 5e716174040..676abc80c89 100644 --- a/source/Developer-Tools/Build/Ament-CMake-Documentation.rst +++ b/source/Developer-Tools/Build/Ament-CMake-Documentation.rst @@ -746,4 +746,4 @@ Best practices - **Provide fallback implementations**: When possible, provide alternative implementations for older API versions to maintain backward compatibility. - **Document version requirements**: Clearly document the minimum required versions for specific features in your package documentation. - **Test across versions**: If your package needs to support multiple ROS 2 distributions, test it against the minimum supported version. -- **Use the GTE macro**: Prefer using the ``_VERSION_GTE(major, minor, patch)`` macro for version comparisons, as it provides a cleaner and more readable syntax than manually comparing individual version components. \ No newline at end of file +- **Use the GTE macro**: Prefer using the ``_VERSION_GTE(major, minor, patch)`` macro for version comparisons, as it provides a cleaner and more readable syntax than manually comparing individual version components. diff --git a/source/Developer-Tools/Build/Ament-CMake-Python-Documentation.rst b/source/Developer-Tools/Build/Ament-CMake-Python-Documentation.rst index 45182e8968e..a1bb53f755a 100644 --- a/source/Developer-Tools/Build/Ament-CMake-Python-Documentation.rst +++ b/source/Developer-Tools/Build/Ament-CMake-Python-Documentation.rst @@ -122,4 +122,4 @@ The ``CMakeLists.txt`` should contain: Compared to the usage of ament_python, which supports automatic test discovery, ament_cmake_pytest must be called with the path to each test file. The timeout can be reduced as needed. -Now, you can invoke your tests with the :doc:`standard colcon testing commands <../Testing/Testing/CLI>`. \ No newline at end of file +Now, you can invoke your tests with the :doc:`standard colcon testing commands <../Testing/Testing/CLI>`. diff --git a/source/Developer-Tools/Build/Ament-Lint-For-Clean-Code.rst b/source/Developer-Tools/Build/Ament-Lint-For-Clean-Code.rst index d07dd0670ae..b3293ac8efe 100644 --- a/source/Developer-Tools/Build/Ament-Lint-For-Clean-Code.rst +++ b/source/Developer-Tools/Build/Ament-Lint-For-Clean-Code.rst @@ -358,4 +358,4 @@ A few of these tools are listed below. * ``ament_pep257`` - Check Python docstrings against the style conventions in `PEP 257 `_. Ament is highly extensible and ROS users are encouraged to build and use ament tools that make them more productive. -You can search for other community contributed ament lint tools by using the ``apt search`` or by `searching for ament on ROS Index `_. \ No newline at end of file +You can search for other community contributed ament lint tools by using the ``apt search`` or by `searching for ament on ROS Index `_. diff --git a/source/Developer-Tools/Build/Building-a-Custom-Deb-Package.rst b/source/Developer-Tools/Build/Building-a-Custom-Deb-Package.rst index 88774e4afc9..1b27fdb0b08 100644 --- a/source/Developer-Tools/Build/Building-a-Custom-Deb-Package.rst +++ b/source/Developer-Tools/Build/Building-a-Custom-Deb-Package.rst @@ -51,4 +51,4 @@ Run the following commands to build the deb: $ bloom-generate rosdebian $ fakeroot debian/rules binary -Assuming that all required dependencies are available and that compilation succeeds, the new package will be available in the parent directory of this directory. \ No newline at end of file +Assuming that all required dependencies are available and that compilation succeeds, the new package will be available in the parent directory of this directory. diff --git a/source/Developer-Tools/Build/Core-maintainer-guide.rst b/source/Developer-Tools/Build/Core-maintainer-guide.rst index 5734ff58881..b5898d8a282 100644 --- a/source/Developer-Tools/Build/Core-maintainer-guide.rst +++ b/source/Developer-Tools/Build/Core-maintainer-guide.rst @@ -182,4 +182,4 @@ While doing maintenance on a package, questions about general procedures or indi For general questions, please follow the :doc:`contributing guidelines <../../The-ROS2-Project/Contributing>`. -For questions on individual issues, please tag the ROS 2 GitHub team (@ros/team), and someone on the team will take a look. \ No newline at end of file +For questions on individual issues, please tag the ROS 2 GitHub team (@ros/team), and someone on the team will take a look. diff --git a/source/Developer-Tools/Build/Cross-compilation.rst b/source/Developer-Tools/Build/Cross-compilation.rst index bfbc453f401..e974cabce04 100644 --- a/source/Developer-Tools/Build/Cross-compilation.rst +++ b/source/Developer-Tools/Build/Cross-compilation.rst @@ -9,4 +9,4 @@ Cross-compilation The `cross_compile `__ tool is not supported anymore. -An alternative to cross-compilation is to `build multi-platform Docker images `__ using ``docker buildx``. \ No newline at end of file +An alternative to cross-compilation is to `build multi-platform Docker images `__ using ``docker buildx``. diff --git a/source/Developer-Tools/Build/DDS-tuning.rst b/source/Developer-Tools/Build/DDS-tuning.rst index 4577bcad8d5..f1bb6c04145 100644 --- a/source/Developer-Tools/Build/DDS-tuning.rst +++ b/source/Developer-Tools/Build/DDS-tuning.rst @@ -171,4 +171,4 @@ It has slow, medium and fast flow controllers (seen in the Connext QoS profile l The medium flow controller produced the best results for our case. However, the controllers will still need to be tuned for the particular machine/network/environment they are operating in. -The Connext flow controllers can be used to tune bandwidth and its aggressiveness for sending out data, though once the bandwidth of a particular setup is passed, performance will start to drop. \ No newline at end of file +The Connext flow controllers can be used to tune bandwidth and its aggressiveness for sending out data, though once the bandwidth of a particular setup is passed, performance will start to drop. diff --git a/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst b/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst index 5bc161486a2..fb4710ca56b 100644 --- a/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst +++ b/source/Developer-Tools/Build/Deployment-Guidelines/Deployment-Guidelines.rst @@ -228,4 +228,4 @@ Note that: .. note:: - For the sake of simplicity, the same CA is used within this enclave for both identity and permissions. \ No newline at end of file + For the sake of simplicity, the same CA is used within this enclave for both identity and permissions. diff --git a/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst b/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst index 3a6090a3eaa..1ad38389b4c 100644 --- a/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst +++ b/source/Developer-Tools/Build/Developing-a-ROS-2-Package.rst @@ -152,4 +152,4 @@ Combined C++ and Python Packages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When writing a package with both C++ and Python code, the ``setup.py`` file and ``setup.cfg`` file are not used. -Instead, use :doc:`ament_cmake_python `. \ No newline at end of file +Instead, use :doc:`ament_cmake_python `. diff --git a/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst index 4f931b92747..8d9d9b75fc3 100644 --- a/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst +++ b/source/Developer-Tools/Build/Eclipse-Oxygen-with-ROS-2-and-rviz2/Eclipse-Oxygen-with-ROS-2-and-rviz2.rst @@ -227,4 +227,4 @@ Go to "C/C++-Build" and add to the build command: Then in eclipse go to "Run->Debug Configurations" and add the following and click on "Debug". -.. image:: images/eclipse-oxygen-35.png \ No newline at end of file +.. image:: images/eclipse-oxygen-35.png diff --git a/source/Developer-Tools/Build/Package-Docs.rst b/source/Developer-Tools/Build/Package-Docs.rst index d5304f3e0f4..c7f8e6528c7 100644 --- a/source/Developer-Tools/Build/Package-Docs.rst +++ b/source/Developer-Tools/Build/Package-Docs.rst @@ -38,4 +38,4 @@ Adding Your Package to docs.ros.org ----------------------------------- All released ROS 2 packages are automatically added to docs.ros.org and `ROS Index `_. -If you would like to enable or configure your own package please see: :doc:`../Package-documentation/Documenting-a-ROS-2-Package`. \ No newline at end of file +If you would like to enable or configure your own package please see: :doc:`../Package-documentation/Documenting-a-ROS-2-Package`. diff --git a/source/Developer-Tools/Build/Releasing/First-Time-Release.rst b/source/Developer-Tools/Build/Releasing/First-Time-Release.rst index d320d8dbdeb..ea92138dd0b 100644 --- a/source/Developer-Tools/Build/Releasing/First-Time-Release.rst +++ b/source/Developer-Tools/Build/Releasing/First-Time-Release.rst @@ -128,4 +128,4 @@ Bloom will automatically create a pull request for you against `rosdistro `__. You've completed an important step toward releasing your package. -Proceed to the next guide: :doc:`First Time Release `. \ No newline at end of file +Proceed to the next guide: :doc:`First Time Release `. diff --git a/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst b/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst index a8b92c2e2c0..7e69449a4eb 100644 --- a/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst +++ b/source/Developer-Tools/Build/Releasing/Release-Team-Repository.rst @@ -83,4 +83,4 @@ If you have previously released your packages for ROS 2, when raising the `Add N Release repositories hosted elsewhere are still supported for stable distributions if you are not planning to release the repository into Rolling. Since stable distributions created from Rolling will start with release repositories in the ros2-gbp organization it is recommend that you use the ros2-gbp release repositories for all ROS 2 distributions to avoid fragmenting the release information. - A ros2-gbp release repository may become a hard requirement for all distros in the future and maintaining a single release repository for all ROS 2 distributions simplifies the maintenance of releases for both the Rolling distribution maintainers and package maintainers. \ No newline at end of file + A ros2-gbp release repository may become a hard requirement for all distros in the future and maintaining a single release repository for all ROS 2 distributions simplifies the maintenance of releases for both the Rolling distribution maintainers and package maintainers. diff --git a/source/Developer-Tools/Build/Releasing/Release-Track.rst b/source/Developer-Tools/Build/Releasing/Release-Track.rst index a033e48dc08..e59d9c8bda1 100644 --- a/source/Developer-Tools/Build/Releasing/Release-Track.rst +++ b/source/Developer-Tools/Build/Releasing/Release-Track.rst @@ -247,4 +247,4 @@ Release Repository Push URL to push rather than a https:// url. [None]: -Can be left as the default in most cases. \ No newline at end of file +Can be left as the default in most cases. diff --git a/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst b/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst index 94611980328..0986c9da644 100644 --- a/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst +++ b/source/Developer-Tools/Build/Releasing/Releasing-a-Package.rst @@ -32,4 +32,4 @@ This will: * :doc:`First Time Release ` - if this is the first release for the package, but it is already indexed * :doc:`Subsequent Releases ` - if you are releasing a new version of a package that has already been released -After successfully following the instructions, your package will be released into the ROS ecosystem on the next distro synchronization! \ No newline at end of file +After successfully following the instructions, your package will be released into the ROS ecosystem on the next distro synchronization! diff --git a/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst b/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst index 32d4c557e7f..3a94bc72ad0 100644 --- a/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst +++ b/source/Developer-Tools/Build/Releasing/Subsequent-Releases.rst @@ -68,4 +68,4 @@ Bloom will automatically create a pull request for you against `rosdistro `_. \ No newline at end of file +To get updates on when the next synchronization (sync) is coming, subscribe to the `Packaging and Release Management Category on Open Robotics Discourse `_. diff --git a/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst b/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst index d0c8b7fe244..2f870274ebc 100644 --- a/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst +++ b/source/Developer-Tools/Build/Releasing/_Personal-Access-Token.rst @@ -46,4 +46,4 @@ You can additionally use different GitHub accounts and PATs for individual relea [credential "https://github.com/ros2-gbp/my_package-release.git"] username = x-access-token - helper = "!f() { test \"$1\" = get && echo \"password=\"; }; f" \ No newline at end of file + helper = "!f() { test \"$1\" = get && echo \"password=\"; }; f" diff --git a/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst b/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst index 3a8d28dd972..5b4e8432f3d 100644 --- a/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst +++ b/source/Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers.rst @@ -87,4 +87,4 @@ As an alternative to the command line invocation, you can create a ``docker-comp - talker To run the containers call ``docker compose up`` in the same directory. -You can close the containers with ``Ctrl+C``. \ No newline at end of file +You can close the containers with ``Ctrl+C``. diff --git a/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst b/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst index 2b622f41300..89467ac54ed 100644 --- a/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst +++ b/source/Developer-Tools/Build/Setup-ROS-2-with-VSCode-and-Docker-Container.rst @@ -224,4 +224,4 @@ Inside the terminal do the following: .. Note:: There might be a problem with displaying RVIZ. Please make sure to allow the user to access X window system with ``xhost +local:``. If no window still pops up, then check the value of ``echo $DISPLAY`` - if the output is 1, you can fix this problem with ``echo "export DISPLAY=unix:1" >> /etc/bash.bashrc`` and then test it again. - You can also change the DISPLAY value in the devcontainer.json and rebuild it. \ No newline at end of file + You can also change the DISPLAY value in the devcontainer.json and rebuild it. diff --git a/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst b/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst index 75a5dd8dba9..7f38c233b53 100644 --- a/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst +++ b/source/Developer-Tools/Build/Supplementing-Custom-Rosdep-Keys.rst @@ -142,4 +142,4 @@ Further reading --------------- - https://docs.ros.org/en/independent/api/rosdep/html/rosdep_yaml_format.html -- https://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html \ No newline at end of file +- https://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html diff --git a/source/Developer-Tools/Build/The-Keystore.rst b/source/Developer-Tools/Build/The-Keystore.rst index b257bf38779..6580395596d 100644 --- a/source/Developer-Tools/Build/The-Keystore.rst +++ b/source/Developer-Tools/Build/The-Keystore.rst @@ -260,4 +260,4 @@ Make a backup copy of ``permissions.p7s`` before beginning. $ openssl smime -verify -in permissions.p7s -CAfile permissions_ca.cert.pem -Restore your original, properly signed ``permissions.p7s`` file before proceeding to the next tutorial. \ No newline at end of file +Restore your original, properly signed ``permissions.p7s`` file before proceeding to the next tutorial. diff --git a/source/Developer-Tools/Build/Using-Python-Packages.rst b/source/Developer-Tools/Build/Using-Python-Packages.rst index 1860778fcdd..2af30155f92 100644 --- a/source/Developer-Tools/Build/Using-Python-Packages.rst +++ b/source/Developer-Tools/Build/Using-Python-Packages.rst @@ -99,4 +99,4 @@ Now you can build your workspace and run your python node that depends on packag .. _rosdep key contribution guide: http://docs.ros.org/en/independent/api/rosdep/html/contributing_rules.html -.. _rosdep documentation: http://docs.ros.org/en/independent/api/rosdep/html/ \ No newline at end of file +.. _rosdep documentation: http://docs.ros.org/en/independent/api/rosdep/html/ diff --git a/source/Developer-Tools/Build/Using-Variants.rst b/source/Developer-Tools/Build/Using-Variants.rst index 01497bd5622..20a25cffcb6 100644 --- a/source/Developer-Tools/Build/Using-Variants.rst +++ b/source/Developer-Tools/Build/Using-Variants.rst @@ -69,4 +69,4 @@ Some platforms have tools for creating basic packages that do not require a full It is possible to use these tools to create platform-dependent variants. This approach does not include support for ROS packaging tools and is platform dependent but requires much less infrastructure to produce if you are creating collections of existing packages rather than a mix of public and private ROS packages. For example, on Debian or Ubuntu systems you can use the ``equivs`` utilities. -The Debian Administrator's handbook has a `Section on meta-packages `_. \ No newline at end of file +The Debian Administrator's handbook has a `Section on meta-packages `_. diff --git a/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File.rst b/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File.rst index e5a5b59b6de..c211a3c2a67 100644 --- a/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File.rst +++ b/source/Developer-Tools/Build/Using-Xacro-to-Clean-Up-a-URDF-File/Using-Xacro-to-Clean-Up-a-URDF-File.rst @@ -282,4 +282,4 @@ You can use a macro and some simple math to reduce the amount of code you have t * Common Trick 2: Use math to calculate joint origins. In the case that you change the size of your robot, changing a property with some math to calculate the joint offset will save a lot of trouble. * Common Trick 3: Using a reflect parameter, and setting it to 1 or -1. - See how we use the reflect parameter to put the legs on either side of the body in the base_to_${prefix}_leg origin. \ No newline at end of file + See how we use the reflect parameter to put the legs on either side of the body in the base_to_${prefix}_leg origin. diff --git a/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst b/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst index 7709c6608f5..f2302eb8149 100644 --- a/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst +++ b/source/Developer-Tools/Debugging/Building-ROS-2-with-Tracing.rst @@ -100,4 +100,4 @@ It should print out: Tracing disabled through configuration -If something else is printed, then something went wrong. \ No newline at end of file +If something else is printed, then something went wrong. diff --git a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst index b52739b6aba..b5fdda2993b 100644 --- a/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst +++ b/source/Developer-Tools/Debugging/Debugging-Tf2-Problems/Debugging-Tf2-Problems.rst @@ -316,4 +316,4 @@ Summary ------- In this tutorial you learned how to use a systematic approach for debugging tf2 related problems. -You also learned how to use tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames`` to help you debug those tf2 problems. \ No newline at end of file +You also learned how to use tf2 debugging tools, such as ``tf2_echo``, ``tf2_monitor``, and ``view_frames`` to help you debug those tf2 problems. diff --git a/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst b/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst index 5ebd708aee3..aadc84a5633 100644 --- a/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst +++ b/source/Developer-Tools/Debugging/Getting-Backtraces-in-ROS-2.rst @@ -354,4 +354,4 @@ Automatic backtrace on crash The `backward-cpp `_ library provides beautiful stack traces, and the `backward_ros `_ wrapper simplifies its integration. -Just add it as a dependency and ``find_package`` it in your CMakeLists and the backward libraries will be injected in all your executables and libraries. \ No newline at end of file +Just add it as a dependency and ``find_package`` it in your CMakeLists and the backward libraries will be injected in all your executables and libraries. diff --git a/source/Developer-Tools/Debugging/ROS-2-IDEs.rst b/source/Developer-Tools/Debugging/ROS-2-IDEs.rst index 5c1f257622c..905009a57f3 100644 --- a/source/Developer-Tools/Debugging/ROS-2-IDEs.rst +++ b/source/Developer-Tools/Debugging/ROS-2-IDEs.rst @@ -267,4 +267,4 @@ It should work like any Python project now, allowing easy additions of breakpoin .. note:: - On Windows it seems the capitalization of the ``PATH`` variable under "Environment Variables:" must be "path" (all lowercase) in order to work. \ No newline at end of file + On Windows it seems the capitalization of the ``PATH`` variable under "Environment Variables:" must be "path" (all lowercase) in order to work. diff --git a/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst b/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst index 9250fbfd5b5..7c1ed82520b 100644 --- a/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst +++ b/source/Developer-Tools/Introspection-and-analysis/About-Command-Line-Tools.rst @@ -109,4 +109,4 @@ Implementation The source code for the ``ros2`` command is available at https://github.com/ros2/ros2cli. The ``ros2`` tool has been implemented as a framework that can be extended via plugins. -For example, the `sros2 `__ package provides a ``security`` sub-command that is automatically detected by the ``ros2`` tool if the ``sros2`` package is installed. \ No newline at end of file +For example, the `sros2 `__ package provides a ``security`` sub-command that is automatically detected by the ``ros2`` tool if the ``sros2`` package is installed. diff --git a/source/Developer-Tools/Introspection-and-analysis/About-Security.rst b/source/Developer-Tools/Introspection-and-analysis/About-Security.rst index 41f062271c5..3ce0f7431a3 100644 --- a/source/Developer-Tools/Introspection-and-analysis/About-Security.rst +++ b/source/Developer-Tools/Introspection-and-analysis/About-Security.rst @@ -92,4 +92,4 @@ These variables generally assist ROS in managing enclaves and locating the secur Learn More ---------- -For more information and hands-on exercises enabling ROS 2 communications security, see the :doc:`Security/Introducing-ros2-security`. \ No newline at end of file +For more information and hands-on exercises enabling ROS 2 communications security, see the :doc:`Security/Introducing-ros2-security`. diff --git a/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst b/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst index 69ba3b4ba5c..a8c2dacc544 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Discovery-Server/Discovery-Server.rst @@ -765,4 +765,4 @@ The reduction from this method increases with the number of nodes, making this a The new Fast DDS Discovery Server v2 is available since *Fast DDS* v2.0.2, replacing the old discovery server. In this new version, those nodes that do not share topics will automatically not discover each other, saving the whole discovery data required to connect them and their endpoints. -The experiment above does not show this case, but even so the massive reduction in traffic can be appreciated due to the hidden infrastructure topics of ROS 2 nodes. \ No newline at end of file +The experiment above does not show this case, but even so the massive reduction in traffic can be appreciated due to the hidden infrastructure topics of ROS 2 nodes. diff --git a/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst b/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst index 66ec3db77f1..cdd7b94704c 100644 --- a/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst +++ b/source/Developer-Tools/Introspection-and-analysis/FastDDS-Configuration.rst @@ -800,4 +800,4 @@ At the same time, the output in the server console has been updated: [INFO] [1612977403.805799037] [ping_server]: Ready to serve. [INFO] [1612977404.807314904] [ping_server]: Incoming request - [INFO] [1612977404.836405125] [ping_server]: Sending back response \ No newline at end of file + [INFO] [1612977404.836405125] [ping_server]: Sending back response diff --git a/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst b/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst index 0d687fdf0a4..2b03d5cfc80 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Improved-Dynamic-Discovery.rst @@ -271,4 +271,4 @@ For example, the following commands will limit the ROS 2 communication only with .. code-block:: console $ setx ROS_AUTOMATIC_DISCOVERY_RANGE LOCALHOST - $ setx ROS_STATIC_PEERS 192.168.0.1;remote.com \ No newline at end of file + $ setx ROS_STATIC_PEERS 192.168.0.1;remote.com diff --git a/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst b/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst index 74a0ff845d0..e029f238687 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Logging-and-logger-configuration.rst @@ -524,4 +524,4 @@ You can change the log file name prefix to one of your choice using the ``--log- $ ros2 run demo_nodes_cpp talker --ros-args --log-file-name filename -This configures the log file name prefix to ``filename``, instead of the executable file name (which is ``talker`` in this case). \ No newline at end of file +This configures the log file name prefix to ``filename``, instead of the executable file name (which is ``talker`` in this case). diff --git a/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst b/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst index 01eb2bc465d..eb52e191d69 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Node-arguments.rst @@ -172,4 +172,4 @@ Other nodes will be able to retrieve the parameter values, e.g.: use_sim_time wildcard_full wildcard_namespace - wildcard_nodename_root_namespace \ No newline at end of file + wildcard_nodename_root_namespace diff --git a/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst b/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst index 747425c75c3..e8c830a00f3 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Publishing-Messages-Using-YAML-Files.rst @@ -112,4 +112,4 @@ By executing the same command as before, we publish three different messages to Next steps ---------- -If you are interested in publishing multiple topics using the CLI, you can take a look at the :doc:`Recording and playing back data <../../ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` tutorial. \ No newline at end of file +If you are interested in publishing multiple topics using the CLI, you can take a look at the :doc:`Recording and playing back data <../../ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data>` tutorial. diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst index c7e0ae05acb..4ab408c8f7b 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Access-Controls.rst @@ -182,4 +182,4 @@ However, the following attempt for the ``listener`` node to subscribe to a topic .. code-block:: console $ ros2 run demo_nodes_py listener --ros-args --enclave /talker_listener/listener \ - --remap chatter:=not_chatter \ No newline at end of file + --remap chatter:=not_chatter diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst index c750aeadd42..328074563bb 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Examine-Traffic.rst @@ -214,4 +214,4 @@ A typical data packet looks like the following: The data in this RTPS packet is all encrypted. In addition to this data packet, you should see additional packets with node and enclave names; these support other ROS features such as parameters and services. -Encryption options for these packets can also be controlled by security policy. \ No newline at end of file +Encryption options for these packets can also be controlled by security policy. diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst index e9bac8a9e0d..6cf40766cbb 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Introducing-ros2-security.rst @@ -411,4 +411,4 @@ Learn More! Are you ready to go further with ROS Security? Take a look at the `Secure Turtlebot2 Demo `_. You'll find a functioning and complex implementation of ROS 2 security, ready to try out your own custom scenarios. -Be sure to create pull requests and issues here so we can continue improving security support in ROS! \ No newline at end of file +Be sure to create pull requests and issues here so we can continue improving security support in ROS! diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst index 38168da5837..44d5486b449 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Security-Main.rst @@ -11,4 +11,4 @@ Security Introducing-ros2-security Security-on-Two Examine-Traffic - Access-Controls \ No newline at end of file + Access-Controls diff --git a/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst b/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst index 59877e76d28..7431f52c0e1 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Security/Security-on-Two.rst @@ -118,4 +118,4 @@ and launch the listener on ``Alice``: Alice will now be receiving encrypted messages from Bob. -With two machines successfully communicating using both encryption and authentication, you can use the same procedure to add more machines to your ROS graph. \ No newline at end of file +With two machines successfully communicating using both encryption and authentication, you can use the same procedure to add more machines to your ROS graph. diff --git a/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst b/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst index da51a704515..cfdbef4c3cd 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Service-Introspection.rst @@ -378,4 +378,4 @@ Related content - `service introspection client example (rclcpp) `__ and `service introspection service example (rclcpp) `__. - `service introspection client and service example (rclpy) `__. -- `Service Introspection REP-2012 `__. \ No newline at end of file +- `Service Introspection REP-2012 `__. diff --git a/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst b/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst index 3fa0cc8124c..e547d69254d 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Topic-Statistics-Tutorial/Topic-Statistics-Tutorial.rst @@ -314,4 +314,4 @@ Related content --------------- To observe how the ``message_age`` period is calculated please see the -`ROS 2 Topic Statistics demo `__. \ No newline at end of file +`ROS 2 Topic Statistics demo `__. diff --git a/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst b/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst index 9e098540372..611f548cb16 100644 --- a/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst +++ b/source/Developer-Tools/Introspection-and-analysis/Tracing/ROS2-Tracing-Trace-and-Analyze.rst @@ -196,4 +196,4 @@ This tutorial showed how to install tracing-related tools. Then it showed how to trace a `performance_test `_ experiment using `ros2_tracing `_ and plot the callback durations using `tracetools_analysis `_. For more trace analyses, take a look at the `other sample notebooks `_ and the `tracetools_analysis API documentation `_. -The `ros2_tracing design document `_ also contains a lot of information. \ No newline at end of file +The `ros2_tracing design document `_ also contains a lot of information. diff --git a/source/Developer-Tools/Launch/Creating-Launch-Files.rst b/source/Developer-Tools/Launch/Creating-Launch-Files.rst index ac983e38d44..cbedeee13a1 100644 --- a/source/Developer-Tools/Launch/Creating-Launch-Files.rst +++ b/source/Developer-Tools/Launch/Creating-Launch-Files.rst @@ -249,4 +249,4 @@ Summary ------- Launch files simplify running complex systems with many nodes and specific configuration details. -You can create launch files using XML, YAML, or Python, and run them using the ``ros2 launch`` command. \ No newline at end of file +You can create launch files using XML, YAML, or Python, and run them using the ``ros2 launch`` command. diff --git a/source/Developer-Tools/Launch/Launch-Main.rst b/source/Developer-Tools/Launch/Launch-Main.rst index c015b3c75d3..ce9e4c2cd9c 100644 --- a/source/Developer-Tools/Launch/Launch-Main.rst +++ b/source/Developer-Tools/Launch/Launch-Main.rst @@ -43,4 +43,4 @@ ROS 2 Launch files allow you to start up and configure a number of executables c .. note:: - If you are coming from ROS 1, you can use the :doc:`ROS Launch Migration guide <../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files>` to help you migrate your launch files to ROS 2. \ No newline at end of file + If you are coming from ROS 1, you can use the :doc:`ROS Launch Migration guide <../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files>` to help you migrate your launch files to ROS 2. diff --git a/source/Developer-Tools/Launch/Launch-file-different-formats.rst b/source/Developer-Tools/Launch/Launch-file-different-formats.rst index a34713c7e76..2674e289997 100644 --- a/source/Developer-Tools/Launch/Launch-file-different-formats.rst +++ b/source/Developer-Tools/Launch/Launch-file-different-formats.rst @@ -106,4 +106,4 @@ Using Python for ROS 2 launch is more flexible because of following two reasons: * Python is a scripting language, and thus you can leverage the language and its libraries in your launch files. * `ros2/launch `_ (general launch features) and `ros2/launch_ros `_ (ROS 2 specific launch features) are written in Python and thus you have lower level access to launch features that may not be exposed by XML and YAML. -That being said, a launch file written in Python may be more complex and verbose than one in XML or YAML. \ No newline at end of file +That being said, a launch file written in Python may be more complex and verbose than one in XML or YAML. diff --git a/source/Developer-Tools/Launch/Launch-system.rst b/source/Developer-Tools/Launch/Launch-system.rst index cbaca2a9011..0f65ea8878c 100644 --- a/source/Developer-Tools/Launch/Launch-system.rst +++ b/source/Developer-Tools/Launch/Launch-system.rst @@ -232,4 +232,4 @@ Documentation `The launch documentation `__ provides more details on concepts that are also used in ``launch_ros``. Additional documentation/examples of launch capabilities are forthcoming. -See the source code (https://github.com/ros2/launch and https://github.com/ros2/launch_ros) in the meantime. \ No newline at end of file +See the source code (https://github.com/ros2/launch and https://github.com/ros2/launch_ros) in the meantime. diff --git a/source/Developer-Tools/Launch/Launching-composable-nodes.rst b/source/Developer-Tools/Launch/Launching-composable-nodes.rst index a8de2d3391f..45470253ed3 100644 --- a/source/Developer-Tools/Launch/Launching-composable-nodes.rst +++ b/source/Developer-Tools/Launch/Launching-composable-nodes.rst @@ -94,4 +94,4 @@ For more information on what intra-process communications are, see the :doc:`int XML, YAML, or Python: Which should I use? ----------------------------------------- -See the :ref:`discussion ` in :doc:`Launch-file-different-formats` for more information. \ No newline at end of file +See the :ref:`discussion ` in :doc:`Launch-file-different-formats` for more information. diff --git a/source/Developer-Tools/Launch/Using-Event-Handlers.rst b/source/Developer-Tools/Launch/Using-Event-Handlers.rst index 88e22449fa3..b1c5bccce21 100644 --- a/source/Developer-Tools/Launch/Using-Event-Handlers.rst +++ b/source/Developer-Tools/Launch/Using-Event-Handlers.rst @@ -132,4 +132,4 @@ Summary ------- In this tutorial, you learned about using event handlers in launch files. -You learned about their syntax and usage examples to define a complex set of rules to dynamically modify launch files. \ No newline at end of file +You learned about their syntax and usage examples to define a complex set of rules to dynamically modify launch files. diff --git a/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst b/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst index 1a0fb24ba46..05cab09760e 100644 --- a/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst +++ b/source/Developer-Tools/Launch/Using-ROS2-Launch-For-Large-Projects.rst @@ -548,4 +548,4 @@ It will show all turtle frames relative to the ``world`` frame, whose origin is Summary ------- -In this tutorial, you learned about various tips and practices of managing large projects using ROS 2 launch files. \ No newline at end of file +In this tutorial, you learned about various tips and practices of managing large projects using ROS 2 launch files. diff --git a/source/Developer-Tools/Launch/Using-Substitutions.rst b/source/Developer-Tools/Launch/Using-Substitutions.rst index b57b5349d51..a9044d33c4d 100644 --- a/source/Developer-Tools/Launch/Using-Substitutions.rst +++ b/source/Developer-Tools/Launch/Using-Substitutions.rst @@ -546,4 +546,4 @@ Summary In this tutorial, you learned about using substitutions in launch files. You learned about their possibilities and capabilities to create reusable launch files. -You can now learn more about :doc:`using event handlers in launch files ` which are used to define a complex set of rules which can be used to dynamically modify the launch file. \ No newline at end of file +You can now learn more about :doc:`using event handlers in launch files ` which are used to define a complex set of rules which can be used to dynamically modify the launch file. diff --git a/source/Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package.rst b/source/Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package.rst index 0df8c85d055..a2980b49620 100644 --- a/source/Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package.rst +++ b/source/Developer-Tools/Package-documentation/Documenting-a-ROS-2-Package.rst @@ -246,4 +246,4 @@ Further Reading * `rosdoc2 readme `_ * `ROS 2 design document on package documentation `_ -* `The ROS 2 cookbook `_ \ No newline at end of file +* `The ROS 2 cookbook `_ diff --git a/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst b/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst index 4f20f60b370..22e5c69cc68 100644 --- a/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst +++ b/source/Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback.rst @@ -109,4 +109,4 @@ We can see the results with ``ros2 topic`` .. code-block:: console - $ ros2 topic echo --qos-reliability best_effort /talker std_msgs/String \ No newline at end of file + $ ros2 topic echo --qos-reliability best_effort /talker std_msgs/String diff --git a/source/Developer-Tools/Testing/Testing.rst b/source/Developer-Tools/Testing/Testing.rst index 6b0dfab848e..68b70162832 100644 --- a/source/Developer-Tools/Testing/Testing.rst +++ b/source/Developer-Tools/Testing/Testing.rst @@ -152,4 +152,4 @@ For Ubuntu Linux, there is also a nightly Docker image based on the nightly bina $ docker run -it osrf/ros2:nightly -For support on running GUI applications in Docker, take a look at the tutorial `User GUI's with Docker `_ or the tool `rocker `_. \ No newline at end of file +For support on running GUI applications in Docker, take a look at the tutorial `User GUI's with Docker `_ or the tool `rocker `_. diff --git a/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst b/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst index 8c1ff213f1c..72f0b22fc49 100644 --- a/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst +++ b/source/Developer-Tools/Testing/Testing/BuildFarmTesting.rst @@ -66,4 +66,4 @@ For each ROS distro that you want pull request testing for, you must enable the `Example `_. `Documented in REP 143 `_. -Note that after the pull request has been added, the job will usually not be created until the nightly Jenkins reconfiguration. \ No newline at end of file +Note that after the pull request has been added, the job will usually not be created until the nightly Jenkins reconfiguration. diff --git a/source/Developer-Tools/Testing/Testing/CLI.rst b/source/Developer-Tools/Testing/Testing/CLI.rst index ef9b1e13ea3..bf98f665451 100644 --- a/source/Developer-Tools/Testing/Testing/CLI.rst +++ b/source/Developer-Tools/Testing/Testing/CLI.rst @@ -45,4 +45,4 @@ To see the exact test cases which fail, use the ``--verbose`` flag: Debugging tests with GDB ^^^^^^^^^^^^^^^^^^^^^^^^ -For detailed guidance on debugging tests using GDB, refer to the :doc:`GDB Tutorial <../../Debugging/Getting-Backtraces-in-ROS-2>`. \ No newline at end of file +For detailed guidance on debugging tests using GDB, refer to the :doc:`GDB Tutorial <../../Debugging/Getting-Backtraces-in-ROS-2>`. diff --git a/source/Developer-Tools/Testing/Testing/Integration.rst b/source/Developer-Tools/Testing/Testing/Integration.rst index 8e7ea856aa4..7b8ae157657 100644 --- a/source/Developer-Tools/Testing/Testing/Integration.rst +++ b/source/Developer-Tools/Testing/Testing/Integration.rst @@ -275,4 +275,4 @@ Related content * :doc:`C++ unit testing with GTest <../../Intermediate/Testing/Cpp>` and :doc:`Python unit testing with Pytest ` * `launch_pytest documentation `_, - an alternative launch integration testing package to ``launch_testing`` \ No newline at end of file + an alternative launch integration testing package to ``launch_testing`` diff --git a/source/Developer-Tools/Testing/Testing/Python.rst b/source/Developer-Tools/Testing/Testing/Python.rst index 71499b6f6f6..bd0f055b49c 100644 --- a/source/Developer-Tools/Testing/Testing/Python.rst +++ b/source/Developer-Tools/Testing/Testing/Python.rst @@ -93,4 +93,4 @@ To see the pytest output while running the tests, use these flags: .. code-block:: console - $ colcon test --event-handlers console_cohesion+ \ No newline at end of file + $ colcon test --event-handlers console_cohesion+ diff --git a/source/Developer-Tools/Testing/Testing/Testing-Main.rst b/source/Developer-Tools/Testing/Testing/Testing-Main.rst index dcc93e3864b..fce56406c49 100644 --- a/source/Developer-Tools/Testing/Testing/Testing-Main.rst +++ b/source/Developer-Tools/Testing/Testing/Testing-Main.rst @@ -68,4 +68,4 @@ To get the benefits of testing, some investment is necessary. When the design of the component changes, a lot of tests become invalidated (for instance they no longer compile, or throw runtime exceptions related to the API design). These tests fail not only because the redesign re-introduced bugs but also because they need to be updated to the new design. Occasionally, with bigger redesigns, old regression tests should be dropped. -* Large bodies of tests can take a long time to run, which can increase Continuous Integration server costs. \ No newline at end of file +* Large bodies of tests can take a long time to run, which can increase Continuous Integration server costs. diff --git a/source/Developer-Tools/Visualization/About-RQt.rst b/source/Developer-Tools/Visualization/About-RQt.rst index f6de9605a2d..a859afa876c 100644 --- a/source/Developer-Tools/Visualization/About-RQt.rst +++ b/source/Developer-Tools/Visualization/About-RQt.rst @@ -81,4 +81,4 @@ Further Reading * ROS 2 Discourse `announcement of porting to ROS 2 `__) * `RQt for ROS 1 documentation `__ -* Brief overview of RQt (from `a Willow Garage intern blog post `__) \ No newline at end of file +* Brief overview of RQt (from `a Willow Garage intern blog post `__) diff --git a/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst b/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst index f26deb39983..ac4f7c895ad 100644 --- a/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst +++ b/source/Developer-Tools/Visualization/RViz/Marker-Display-types/Marker-Display-types.rst @@ -319,4 +319,4 @@ and the lines will be correct relative to the ``frame id`` specified in the head 4 Rendering Complexity Notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A single marker is always less expensive to render than many markers. -For example, a single cube list can handle thousands of cubes, where we will not be able to render thousands of individual cube markers. \ No newline at end of file +For example, a single cube list can handle thousands of cubes, where we will not be able to render thousands of individual cube markers. diff --git a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst index 4a2f3b1dd98..9cdc732a91f 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Display/RViz-Custom-Display.rst @@ -455,4 +455,4 @@ And finally, here's the icon in the standard interface: :alt: screenshot with icon in standard interface -Note, if you change the plugins name, previous RViz configurations will no longer work. \ No newline at end of file +Note, if you change the plugins name, previous RViz configurations will no longer work. diff --git a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst index 1d5b305c420..e065b5d9f04 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-Custom-Panel/RViz-Custom-Panel.rst @@ -353,4 +353,4 @@ The panel will also have an updated icon. .. image:: images/RViz3.png :target: ../../../../_images/RViz3.png - :alt: screenshot of the RViz panel with custom icon \ No newline at end of file + :alt: screenshot of the RViz panel with custom icon diff --git a/source/Developer-Tools/Visualization/RViz/RViz-Main.rst b/source/Developer-Tools/Visualization/RViz/RViz-Main.rst index 6f4129ea743..5d7591c6274 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-Main.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-Main.rst @@ -19,4 +19,4 @@ RViz is a 3D visualizer for the Robot Operating System (ROS) framework. Marker-Points-and-Lines/Marker-Points-and-Lines Marker-Display-types/Marker-Display-types RViz-Custom-Display/RViz-Custom-Display - RViz-Custom-Panel/RViz-Custom-Panel \ No newline at end of file + RViz-Custom-Panel/RViz-Custom-Panel diff --git a/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst b/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst index f383764e534..e162b3a272f 100644 --- a/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst +++ b/source/Developer-Tools/Visualization/RViz/RViz-User-Guide/RViz-User-Guide.rst @@ -376,4 +376,4 @@ The time panel also lets you reset the visualizer's internal time state, which r .. image:: images/time.png If you are not running in simulation, the time panel is mostly useless. -In most cases it can be closed and you will probably not even notice (other than having a bit more screen real estate for the rest of rviz). \ No newline at end of file +In most cases it can be closed and you will probably not even notice (other than having a bit more screen real estate for the rest of rviz). diff --git a/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst b/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst index ec0ccf43cfa..054e8278856 100644 --- a/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst +++ b/source/Developer-Tools/Visualization/Rqtbag/Create-An-Rqtbag-Plugin.rst @@ -383,4 +383,4 @@ If computing the message representation on timeline is more computationally dema `Timeline Cache `__ like the `ImageTimelineViewer `__ -does, but figuring that out is left as an exercise to the reader. \ No newline at end of file +does, but figuring that out is left as an exercise to the reader. diff --git a/source/Get-Started.rst b/source/Get-Started.rst index a69fd219865..cbf56226791 100644 --- a/source/Get-Started.rst +++ b/source/Get-Started.rst @@ -13,4 +13,4 @@ PLACEHOLDER Get-Started/Releases First-Steps Get-Started/Configuring-ROS2-Environment - Get-Started/Introducing-Turtlesim/Introducing-Turtlesim \ No newline at end of file + Get-Started/Introducing-Turtlesim/Introducing-Turtlesim diff --git a/source/Get-Started/About-ROS/About-ROS.rst b/source/Get-Started/About-ROS/About-ROS.rst index 564c2102716..072d0c135bc 100644 --- a/source/Get-Started/About-ROS/About-ROS.rst +++ b/source/Get-Started/About-ROS/About-ROS.rst @@ -141,4 +141,4 @@ ROS on macOS is supported by the community, and we do not recommended it for new Ubuntu support depends on the ROS distribution, with each distribution requiring a specific Ubuntu LTS (long-term support) release. Other platforms may require building from source or using containers. -:doc:`See full details of currently supported platforms and support tiers <../Releases/Release-Rolling-Ridley>` \ No newline at end of file +:doc:`See full details of currently supported platforms and support tiers <../Releases/Release-Rolling-Ridley>` diff --git a/source/Get-Started/Configuring-ROS2-Environment.rst b/source/Get-Started/Configuring-ROS2-Environment.rst index 8beff50028d..222600ac704 100644 --- a/source/Get-Started/Configuring-ROS2-Environment.rst +++ b/source/Get-Started/Configuring-ROS2-Environment.rst @@ -224,4 +224,4 @@ If you ever face any problems locating or using packages with ROS 2, the first t Next steps ---------- -Now that you have a working ROS 2 installation and you know how to source its setup files, you can start learning the ins and outs of ROS 2 with the :doc:`turtlesim tool `. \ No newline at end of file +Now that you have a working ROS 2 installation and you know how to source its setup files, you can start learning the ins and outs of ROS 2 with the :doc:`turtlesim tool `. diff --git a/source/Get-Started/Installation.rst b/source/Get-Started/Installation.rst index 8a7af2edc9d..6379a57a578 100644 --- a/source/Get-Started/Installation.rst +++ b/source/Get-Started/Installation.rst @@ -87,4 +87,4 @@ Building from source also gives you the option to install the absolute latest ve Contributing to ROS 2 core? ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -If you plan to contribute directly to ROS 2 core packages, you can install the :doc:`latest development from source ` which shares installation instructions with the :ref:`Rolling distribution `. \ No newline at end of file +If you plan to contribute directly to ROS 2 core packages, you can install the :doc:`latest development from source ` which shares installation instructions with the :ref:`Rolling distribution `. diff --git a/source/Get-Started/Installation/Alternatives.rst b/source/Get-Started/Installation/Alternatives.rst index 9ecd1f873ce..97089cbfe15 100644 --- a/source/Get-Started/Installation/Alternatives.rst +++ b/source/Get-Started/Installation/Alternatives.rst @@ -18,4 +18,4 @@ A list of alternative ways to install ROS 2 – whether it's by building from s Alternatives/RHEL-Install-Binary Alternatives/macOS-Development-Setup Alternatives/Latest-Development-Setup - Alternatives/Maintaining-a-Source-Checkout \ No newline at end of file + Alternatives/Maintaining-a-Source-Checkout diff --git a/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst index e919f0bd9ab..dd8558dd0af 100644 --- a/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/Latest-Development-Setup.rst @@ -29,4 +29,4 @@ Follow the links below for the latest setup instructions for your platform: * :doc:`RHEL ` * :doc:`macOS ` -For keeping your source code up-to-date, see :doc:`Maintain a source checkout `. \ No newline at end of file +For keeping your source code up-to-date, see :doc:`Maintain a source checkout `. diff --git a/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst b/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst index f7307b21992..033d8704105 100644 --- a/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst +++ b/source/Get-Started/Installation/Alternatives/Maintaining-a-Source-Checkout.rst @@ -153,4 +153,4 @@ If you wish to know the versions of the set of repositories in your workspace, y $ cd \dev\ros2_{DISTRO} $ vcs export src > my_ros2.repos -This ``my_ros2.repos`` file can then be shared with others so that they can reproduce the state of the repositories in your workspace. \ No newline at end of file +This ``my_ros2.repos`` file can then be shared with others so that they can reproduce the state of the repositories in your workspace. diff --git a/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst index 9e1f5280330..2bc2aab1380 100644 --- a/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/RHEL-Development-Setup.rst @@ -210,4 +210,4 @@ Uninstall .. code-block:: console - $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file + $ rm -rf ~/ros2_{DISTRO} diff --git a/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst b/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst index 869634d67db..432b8413c3d 100644 --- a/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst +++ b/source/Get-Started/Installation/Alternatives/RHEL-Install-Binary.rst @@ -171,4 +171,4 @@ Uninstall .. code-block:: console - $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file + $ rm -rf ~/ros2_{DISTRO} diff --git a/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst index 4334f1176f3..d9bc73e57a5 100644 --- a/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/Ubuntu-Development-Setup.rst @@ -199,4 +199,4 @@ Uninstall .. code-block:: console - $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file + $ rm -rf ~/ros2_{DISTRO} diff --git a/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst b/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst index 471a7cbf0b1..9b654f028d7 100644 --- a/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst +++ b/source/Get-Started/Installation/Alternatives/Ubuntu-Install-Binary.rst @@ -155,4 +155,4 @@ Uninstall .. code-block:: console - $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file + $ rm -rf ~/ros2_{DISTRO} diff --git a/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst index 3e43d252348..f7376d15ea5 100644 --- a/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/Windows-Development-Setup.rst @@ -275,4 +275,4 @@ Uninstall .. code-block:: console - $ rmdir /s /q C:\dev\{DISTRO} \ No newline at end of file + $ rmdir /s /q C:\dev\{DISTRO} diff --git a/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst b/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst index 3c48f3869ed..6b7e151ee0a 100644 --- a/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst +++ b/source/Get-Started/Installation/Alternatives/macOS-Development-Setup.rst @@ -215,4 +215,4 @@ Uninstall .. code-block:: console - $ rm -rf ~/ros2_{DISTRO} \ No newline at end of file + $ rm -rf ~/ros2_{DISTRO} diff --git a/source/Get-Started/Installation/Installation-Troubleshooting.rst b/source/Get-Started/Installation/Installation-Troubleshooting.rst index d7105b67c9a..95bb75ab562 100644 --- a/source/Get-Started/Installation/Installation-Troubleshooting.rst +++ b/source/Get-Started/Installation/Installation-Troubleshooting.rst @@ -361,4 +361,4 @@ One possible solution to this is to force RViz to use software rendering: $ export LIBGL_ALWAYS_SOFTWARE=true $ rviz2 - [INFO] [1695823660.091830699] [rviz2]: Stereo is NOT SUPPORTED \ No newline at end of file + [INFO] [1695823660.091830699] [rviz2]: Stereo is NOT SUPPORTED diff --git a/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst b/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst index 8a988de65d6..62923fd4083 100644 --- a/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst +++ b/source/Get-Started/Installation/Installing-on-Raspberry-Pi.rst @@ -67,4 +67,4 @@ Inside of the directory, build the container with: $ docker build -t ros_docker . -On a supported system it will only take a minute or two to build the docker containers, as the source code is already built in to binaries. \ No newline at end of file +On a supported system it will only take a minute or two to build the docker containers, as the source code is already built in to binaries. diff --git a/source/Get-Started/Installation/RHEL-Install-RPMs.rst b/source/Get-Started/Installation/RHEL-Install-RPMs.rst index bbdbe7c6bac..af9bf3274c7 100644 --- a/source/Get-Started/Installation/RHEL-Install-RPMs.rst +++ b/source/Get-Started/Installation/RHEL-Install-RPMs.rst @@ -166,4 +166,4 @@ To remove the repository configuration run .. code-block:: console - $ sudo dnf remove ros2-release \ No newline at end of file + $ sudo dnf remove ros2-release diff --git a/source/Get-Started/Installation/RMW-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations.rst index b7022903d57..3278c1eb893 100644 --- a/source/Get-Started/Installation/RMW-Implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations.rst @@ -25,4 +25,4 @@ Review all the possible options: RMW-Implementations/* * :doc:`DDS implementations ` explains how to use DDS. -* :doc:`Non DDS implementations ` explains how to use non DDS implementations. \ No newline at end of file +* :doc:`Non DDS implementations ` explains how to use non DDS implementations. diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst index ffeeab57834..73feb6e1b45 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations.rst @@ -21,4 +21,4 @@ These are the available DDS implementations: If you would like to use one of the other vendors you will need to install their software separately before building. The ROS 2 build will automatically build support for vendors that have been installed and sourced correctly. -Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations `. \ No newline at end of file +Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations `. diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst index 197a8671449..131d3191bc3 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-Eclipse-CycloneDDS.rst @@ -84,4 +84,4 @@ Now run ``talker`` and ``listener`` to test Cyclone DDS. .. code-block:: console $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener \ No newline at end of file + $ ros2 run demo_nodes_cpp listener diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst index 86b8961756e..28d8fc71939 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-GurumNetworks-GurumDDS.rst @@ -93,4 +93,4 @@ Run the ``talker`` and ``listener`` nodes to verify your installation: If the nodes communicate successfully, your installation is working correctly. -.. note:: Remember to source your ROS 2 setup script before running these commands. \ No newline at end of file +.. note:: Remember to source your ROS 2 setup script before running these commands. diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst index 81d9997fd55..d055f6ec6b3 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.rst @@ -159,4 +159,4 @@ Now run ``talker`` and ``listener`` to test RTI Connext DDS .. code-block:: console $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener \ No newline at end of file + $ ros2 run demo_nodes_cpp listener diff --git a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst index 85a7c364983..d1d1358c8c0 100644 --- a/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst +++ b/source/Get-Started/Installation/RMW-Implementations/DDS-Implementations/Working-with-eProsima-Fast-DDS.rst @@ -73,4 +73,4 @@ Now run ``talker`` and ``listener`` to test Fast DDS. .. code-block:: console $ source /opt/ros/{DISTRO}/setup.bash - $ ros2 run demo_nodes_cpp listener \ No newline at end of file + $ ros2 run demo_nodes_cpp listener diff --git a/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst index 480b73b6b63..b7809f4e755 100644 --- a/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations/Non-DDS-Implementations.rst @@ -16,4 +16,4 @@ Non-DDS-Implementations If you would like to use one of the other vendors you will need to install their software separately before building. The ROS 2 build will automatically build support for vendors that have been installed and sourced correctly. -Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations `. \ No newline at end of file +Once you've installed a new RMW vendor, you can change the vendor used at runtime: :doc:`Working with Multiple RMW Implementations `. diff --git a/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst b/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst index e04fce048ea..0ff58944fb3 100644 --- a/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst +++ b/source/Get-Started/Installation/RMW-Implementations/Working-with-multiple-RMW-implementations.rst @@ -192,4 +192,4 @@ Either add to your existing ``etc/sysctl.conf`` file or create ``/etc/sysctl.con You will need to reboot the machine after modifying this file to have the changes take effect. This solution is edited from the RTI Connext community forum. -See the `original post `__ for a more detailed explanation. \ No newline at end of file +See the `original post `__ for a more detailed explanation. diff --git a/source/Get-Started/Installation/ROS-2-Mirrors.rst b/source/Get-Started/Installation/ROS-2-Mirrors.rst index fe5ac5c26be..df08b93cbd9 100644 --- a/source/Get-Started/Installation/ROS-2-Mirrors.rst +++ b/source/Get-Started/Installation/ROS-2-Mirrors.rst @@ -124,4 +124,4 @@ Mirroring docs.ros.org ---------------------- Mirroring the documentation site requires specific configuration to prevent search engine fragmentation. -If you are interested in hosting a regional mirror of the documentation, please **contact the infrastructure team** via Discourse before proceeding. \ No newline at end of file +If you are interested in hosting a regional mirror of the documentation, please **contact the infrastructure team** via Discourse before proceeding. diff --git a/source/Get-Started/Installation/Windows-Install-Binary.rst b/source/Get-Started/Installation/Windows-Install-Binary.rst index 8d9cf756337..7db4d7a211e 100644 --- a/source/Get-Started/Installation/Windows-Install-Binary.rst +++ b/source/Get-Started/Installation/Windows-Install-Binary.rst @@ -166,4 +166,4 @@ Uninstall .. code-block:: console - $ rmdir /s /q C:\dev\{DISTRO} \ No newline at end of file + $ rmdir /s /q C:\dev\{DISTRO} diff --git a/source/Get-Started/Installation/_Apt-Repositories.rst b/source/Get-Started/Installation/_Apt-Repositories.rst index a797e6ceca3..49f4ce804bb 100644 --- a/source/Get-Started/Installation/_Apt-Repositories.rst +++ b/source/Get-Started/Installation/_Apt-Repositories.rst @@ -21,4 +21,4 @@ Updates to repository configuration will occur automatically when new versions o $ sudo apt update && sudo apt install curl -y $ export ROS_APT_SOURCE_VERSION=$(curl -s https://api.github.com/repos/ros-infrastructure/ros-apt-source/releases/latest | grep -F "tag_name" | awk -F'"' '{print $4}') $ curl -L -o /tmp/ros2-apt-source.deb "https://github.com/ros-infrastructure/ros-apt-source/releases/download/${ROS_APT_SOURCE_VERSION}/ros2-apt-source_${ROS_APT_SOURCE_VERSION}.$(. /etc/os-release && echo ${UBUNTU_CODENAME:-${VERSION_CODENAME}})_all.deb" - $ sudo dpkg -i /tmp/ros2-apt-source.deb \ No newline at end of file + $ sudo dpkg -i /tmp/ros2-apt-source.deb diff --git a/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst b/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst index 30a656b66c9..3b09436728a 100644 --- a/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst +++ b/source/Get-Started/Installation/_Apt-Upgrade-Admonition.rst @@ -7,4 +7,4 @@ It is always recommended that you ensure your system is up to date before instal .. code-block:: console - $ sudo apt upgrade \ No newline at end of file + $ sudo apt upgrade diff --git a/source/Get-Started/Installation/_Dnf-Update-Admonition.rst b/source/Get-Started/Installation/_Dnf-Update-Admonition.rst index 00886edb704..e88bb2e4a6d 100644 --- a/source/Get-Started/Installation/_Dnf-Update-Admonition.rst +++ b/source/Get-Started/Installation/_Dnf-Update-Admonition.rst @@ -7,4 +7,4 @@ It is always recommended that you ensure your system is up to date before instal .. code-block:: console - $ sudo dnf update \ No newline at end of file + $ sudo dnf update diff --git a/source/Get-Started/Installation/_RHEL-Set-Locale.rst b/source/Get-Started/Installation/_RHEL-Set-Locale.rst index d5ae721dc2c..e7c0c200148 100644 --- a/source/Get-Started/Installation/_RHEL-Set-Locale.rst +++ b/source/Get-Started/Installation/_RHEL-Set-Locale.rst @@ -14,4 +14,4 @@ However, it should be fine if you're using a different UTF-8 supported locale. $ sudo dnf install langpacks-en glibc-langpack-en $ export LANG=en_US.UTF-8 - $ locale # verify settings \ No newline at end of file + $ locale # verify settings diff --git a/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst b/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst index 631729616d3..9ecf8ab418e 100644 --- a/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst +++ b/source/Get-Started/Installation/_Ubuntu-Set-Locale.rst @@ -16,4 +16,4 @@ However, it should be fine if you're using a different UTF-8 supported locale. $ sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 $ export LANG=en_US.UTF-8 - $ locale # verify settings \ No newline at end of file + $ locale # verify settings diff --git a/source/Get-Started/Installation/_rosdep_Linux_Mint.rst b/source/Get-Started/Installation/_rosdep_Linux_Mint.rst index 144c1cd9fae..32be4b46cbc 100644 --- a/source/Get-Started/Installation/_rosdep_Linux_Mint.rst +++ b/source/Get-Started/Installation/_rosdep_Linux_Mint.rst @@ -3,4 +3,4 @@ Installation/_rosdep_Linux_Mint **Note**: If you're using a distribution that is based on Ubuntu (like Linux Mint) but does not identify itself as such, you'll get an error message like ``Unsupported OS [mint]``. -In this case append ``--os=ubuntu:resolute`` to the above command. \ No newline at end of file +In this case append ``--os=ubuntu:resolute`` to the above command. diff --git a/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst b/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst index 66148829c95..f0e86690d6d 100644 --- a/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst +++ b/source/Get-Started/Introducing-Turtlesim/Introducing-Turtlesim.rst @@ -269,4 +269,4 @@ Now that you have turtlesim and rqt up and running, and an idea of how they work Related content --------------- -The turtlesim package can be found in the `ros_tutorials `_ repo. \ No newline at end of file +The turtlesim package can be found in the `ros_tutorials `_ repo. diff --git a/source/Get-Started/Releases.rst b/source/Get-Started/Releases.rst index 90985199660..87e4f9b171a 100644 --- a/source/Get-Started/Releases.rst +++ b/source/Get-Started/Releases.rst @@ -247,4 +247,4 @@ Cross-Distribution Communications Nodes are not guaranteed to be able to communicate across distributions. For example, a node built & running against Humble is not guaranteed to be able to communicate correctly with a node built & running against Iron. It may or may not work, but it is not supported and should not be relied upon. -Note that :ref:`cross-vendor (single-distro) communications are also not guaranteed `. \ No newline at end of file +Note that :ref:`cross-vendor (single-distro) communications are also not guaranteed `. diff --git a/source/Get-Started/Releases/Alpha-Overview.rst b/source/Get-Started/Releases/Alpha-Overview.rst index c288075a166..309b3e3d0a5 100644 --- a/source/Get-Started/Releases/Alpha-Overview.rst +++ b/source/Get-Started/Releases/Alpha-Overview.rst @@ -409,4 +409,4 @@ The major features included in this release are: * `Bridge communication between ROS 1 and ROS 2 `__ Pretty much anything not listed above is not included in this release. -The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. \ No newline at end of file +The next steps are described in the `Roadmap <../../The-ROS2-Project/Roadmap>`. diff --git a/source/Get-Started/Releases/Beta1-Overview.rst b/source/Get-Started/Releases/Beta1-Overview.rst index 1605726deb9..d6189cf712a 100644 --- a/source/Get-Started/Releases/Beta1-Overview.rst +++ b/source/Get-Started/Releases/Beta1-Overview.rst @@ -63,4 +63,4 @@ Known issues * We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker `__ * We'd like to highlight a `known issue `__ that we are working with eProsima to fix that results in significantly degrated performance for large messages under FastRTPS. - This will be observed when running some of the demos with larger image resolutions. \ No newline at end of file + This will be observed when running some of the demos with larger image resolutions. diff --git a/source/Get-Started/Releases/Beta2-Overview.rst b/source/Get-Started/Releases/Beta2-Overview.rst index 3baba02f405..9cc94a6cd99 100644 --- a/source/Get-Started/Releases/Beta2-Overview.rst +++ b/source/Get-Started/Releases/Beta2-Overview.rst @@ -89,4 +89,4 @@ Known issues * We're tracking issues in various repositories, but the main entry point is the `ros2/ros2 issue tracker `__ * We'd like to highlight a `known issue `__ that we are looking into which doesn't allow two topics with the same base name but different namespaces to have a different type when using ``rmw_connext_cpp``. -* Services with long responses are not working with Fast-RTPS. The fix, while not being part of beta2, is available upstream so you can work around this issue by building from source using Fast-RTPS master branch. \ No newline at end of file +* Services with long responses are not working with Fast-RTPS. The fix, while not being part of beta2, is available upstream so you can work around this issue by building from source using Fast-RTPS master branch. diff --git a/source/Get-Started/Releases/Beta3-Overview.rst b/source/Get-Started/Releases/Beta3-Overview.rst index eccffa6db0e..7b6811ed988 100644 --- a/source/Get-Started/Releases/Beta3-Overview.rst +++ b/source/Get-Started/Releases/Beta3-Overview.rst @@ -77,4 +77,4 @@ Known issues * On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. * OpenSplice support is currently not available for MacOS. Also `access to native handles `__ is not yet implemented. -* Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). \ No newline at end of file +* Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). diff --git a/source/Get-Started/Releases/End-of-Life.rst b/source/Get-Started/Releases/End-of-Life.rst index 52bc864f98e..0f9b59afbee 100644 --- a/source/Get-Started/Releases/End-of-Life.rst +++ b/source/Get-Started/Releases/End-of-Life.rst @@ -21,4 +21,4 @@ Below is a list of historic ROS 2 distributions that are no longer supported. Beta3-Overview Beta2-Overview Beta1-Overview - Alpha-Overview \ No newline at end of file + Alpha-Overview diff --git a/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst b/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst index 44d4bb1ada2..06ea952ffc7 100644 --- a/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Galactic-Geochelone-Complete-Changelog.rst @@ -5136,4 +5136,4 @@ This page is a list of the complete changes in all ROS 2 core packages since the * Zstd should not install internal headers - some of them try include others that aren't installed. We don't use them. Avoid the situation (`#631 `__) * Patch zstd 1.4.4 to include cmake_minimum_version bump to 2.8.12 (`#579 `__) * Update the package.xml files with the latest Open Robotics maintainers (`#535 `__) -* Contributors: Emerson Knapp, Michael Jeronimo, Scott K Logan \ No newline at end of file +* Contributors: Emerson Knapp, Michael Jeronimo, Scott K Logan diff --git a/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst b/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst index b169724ec7e..da957f7dbd7 100644 --- a/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Humble-Hawksbill-Complete-Changelog.rst @@ -3885,4 +3885,4 @@ This page is a list of the complete changes in all ROS 2 core packages since the * Update package maintainers (`#899 `__) * Declare missing dependency on 'git' in zstd_vendor (`#890 `__) * Switch to using 'git apply' for zstd_vendor patches (`#846 `__) -* Contributors: Chris Lalancette, Christophe Bedard, Michel Hidalgo, Scott K Logan, Shane Loretz \ No newline at end of file +* Contributors: Chris Lalancette, Christophe Bedard, Michel Hidalgo, Scott K Logan, Shane Loretz diff --git a/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst b/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst index 6e5def602b1..5368c02cc6f 100644 --- a/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Iron-Irwini-Complete-Changelog.rst @@ -4220,4 +4220,4 @@ This page is a list of the complete changes in all ROS 2 core packages since the * Add Michael Orlov as maintainer in rosbag2 packages (`#1215 `__) * Bump zstd to 1.4.8 in zstd_vendor package (`#1132 `__) * Fix/zstd vendor does not find system zstd (`#1111 `__) -* Contributors: DasRoteSkelett, Michael Orlov \ No newline at end of file +* Contributors: DasRoteSkelett, Michael Orlov diff --git a/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst b/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst index 78cfaba9e30..ad51b179bd5 100644 --- a/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Jazzy-Jalisco-Complete-Changelog.rst @@ -3326,4 +3326,4 @@ This page is a list of the complete changes in all ROS 2 core packages since the * Updated zstd to 1.5.5 (`#1617 `__) (`#1624 `__) * Switch to ament_cmake_vendor_package (`#1400 `__) -* Contributors: Scott K Logan, mergify[bot] \ No newline at end of file +* Contributors: Scott K Logan, mergify[bot] diff --git a/source/Get-Started/Releases/Lyrical-Luth-Complete-Changelog.rst b/source/Get-Started/Releases/Lyrical-Luth-Complete-Changelog.rst index d1a2b644ed5..eba780f113c 100644 --- a/source/Get-Started/Releases/Lyrical-Luth-Complete-Changelog.rst +++ b/source/Get-Started/Releases/Lyrical-Luth-Complete-Changelog.rst @@ -4693,5 +4693,3 @@ This page is a list of the complete changes in all ROS 2 core packages since the * Update CMakeLists.txt (`#617 `__) * Fix warning on Windows (`#615 `__) * Contributors: Alejandro Hernández Cordero, Barry Xu, Christophe Bedard, Julien Enoch, Tomoya Fujita, Yadunund, mosfet80 - - diff --git a/source/Get-Started/Releases/Release-Ardent-Apalone.rst b/source/Get-Started/Releases/Release-Ardent-Apalone.rst index ea85cf1e675..b3cf26ad3fb 100644 --- a/source/Get-Started/Releases/Release-Ardent-Apalone.rst +++ b/source/Get-Started/Releases/Release-Ardent-Apalone.rst @@ -154,4 +154,4 @@ Known Issues * Fast RTPS performance with larger data like the image demo * Using Connext it is currently not allowed for two topics with the same base name but different namespaces to have a different type (see `issue `__). * Listing of node names (e.g. using ``ros2 node list``) does not work across some rmw implementations. -* On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. \ No newline at end of file +* On Windows Python launch files might hang when trying to abort using ``Ctrl-C`` (see `issue `__). In order to continue using the shell which is blocked by the hanging command you might want to end the hanging Python process using the process monitor. diff --git a/source/Get-Started/Releases/Release-Bouncy-Bolson.rst b/source/Get-Started/Releases/Release-Bouncy-Bolson.rst index dd0f3001c6b..0ff50f81ae1 100644 --- a/source/Get-Started/Releases/Release-Bouncy-Bolson.rst +++ b/source/Get-Started/Releases/Release-Bouncy-Bolson.rst @@ -157,4 +157,4 @@ Known Issues * New-style launch files `may hang on shutdown `__ for some combinations of platform and RMW implementation. * Static remapping of namespaces `not working correctly `__ when addressed to a particular node. -* `Opensplice error messages may be printed `__ when using ``ros2 param`` and ``ros2 lifecycle`` command-line tools. \ No newline at end of file +* `Opensplice error messages may be printed `__ when using ``ros2 param`` and ``ros2 lifecycle`` command-line tools. diff --git a/source/Get-Started/Releases/Release-Crystal-Clemmys.rst b/source/Get-Started/Releases/Release-Crystal-Clemmys.rst index 83160fde304..87c23bc6f40 100644 --- a/source/Get-Started/Releases/Release-Crystal-Clemmys.rst +++ b/source/Get-Started/Releases/Release-Crystal-Clemmys.rst @@ -271,4 +271,4 @@ Known Issues * Cross-vendor communication between rmw_fastrtps_cpp and other implementations is not functioning on Windows (`Issue `__). * When using OpenSplice (version < 6.9.190227) on macOS and Windows you might experience naming conflicts when when referencing field types with names from other packages if the same name also exist in the current package (`Issue `__). By updating to a newer OpenSplice version as well as at least the third patch release of Crystal the problem should be resolved. - On Linux updating to the latest Debian packages will include the newest OpenSplice version. \ No newline at end of file + On Linux updating to the latest Debian packages will include the newest OpenSplice version. diff --git a/source/Get-Started/Releases/Release-Dashing-Diademata.rst b/source/Get-Started/Releases/Release-Dashing-Diademata.rst index 73bbe6e4660..cb4e712acf4 100644 --- a/source/Get-Started/Releases/Release-Dashing-Diademata.rst +++ b/source/Get-Started/Releases/Release-Dashing-Diademata.rst @@ -938,4 +938,4 @@ A few milestones leading up to the release: Wed. May 29th Freeze rosdistro. - No PRs for Dashing on the `rosdistro` repo will be merged (reopens after the release announcement). \ No newline at end of file + No PRs for Dashing on the `rosdistro` repo will be merged (reopens after the release announcement). diff --git a/source/Get-Started/Releases/Release-Eloquent-Elusor.rst b/source/Get-Started/Releases/Release-Eloquent-Elusor.rst index 0d0a85e0b51..21d017a7ed0 100644 --- a/source/Get-Started/Releases/Release-Eloquent-Elusor.rst +++ b/source/Get-Started/Releases/Release-Eloquent-Elusor.rst @@ -391,4 +391,4 @@ A few milestones leading up to the release: Tue. Nov 19th Freeze rosdistro. - No PRs for Eloquent on the `rosdistro` repo will be merged (reopens after the release announcement). \ No newline at end of file + No PRs for Eloquent on the `rosdistro` repo will be merged (reopens after the release announcement). diff --git a/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst b/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst index e9a01e67bc3..50b86193a4a 100644 --- a/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst +++ b/source/Get-Started/Releases/Release-Foxy-Fitzroy.rst @@ -608,4 +608,4 @@ A few milestones leading up to the release: No PRs for Foxy on the `rosdistro` repo will be merged (reopens after the release announcement). .. [1] The ``ros_core`` variant described in the `variants `_ repository. -.. [2] The ``desktop`` variant described in the `variants `_ repository. \ No newline at end of file +.. [2] The ``desktop`` variant described in the `variants `_ repository. diff --git a/source/Get-Started/Releases/Release-Galactic-Geochelone.rst b/source/Get-Started/Releases/Release-Galactic-Geochelone.rst index 02f6e1d0684..5f6bb5232ee 100644 --- a/source/Get-Started/Releases/Release-Galactic-Geochelone.rst +++ b/source/Get-Started/Releases/Release-Galactic-Geochelone.rst @@ -1127,4 +1127,4 @@ Timeline before the release ``rosdistro`` is reopened for Galactic PRs. .. [1] The ``ros_core`` variant is described in `REP 2001 (ros-core) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. diff --git a/source/Get-Started/Releases/Release-Humble-Hawksbill.rst b/source/Get-Started/Releases/Release-Humble-Hawksbill.rst index 0ffd9cd9402..aa4bda8d75d 100644 --- a/source/Get-Started/Releases/Release-Humble-Hawksbill.rst +++ b/source/Get-Started/Releases/Release-Humble-Hawksbill.rst @@ -1122,4 +1122,4 @@ Release Timeline ``rosdistro`` is reopened for Humble PRs. .. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. diff --git a/source/Get-Started/Releases/Release-Iron-Irwini.rst b/source/Get-Started/Releases/Release-Iron-Irwini.rst index 30b1d3c0480..4c4cc4f98e4 100644 --- a/source/Get-Started/Releases/Release-Iron-Irwini.rst +++ b/source/Get-Started/Releases/Release-Iron-Irwini.rst @@ -1021,4 +1021,4 @@ Development progress For progress on the development and release of Iron Irwini, see `the tracking GitHub issue `__. -For the broad process followed by Iron Irwini, see the :doc:`process description page `. \ No newline at end of file +For the broad process followed by Iron Irwini, see the :doc:`process description page `. diff --git a/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst b/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst index 028d88e921a..48a2e82636f 100644 --- a/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst +++ b/source/Get-Started/Releases/Release-Jazzy-Jalisco.rst @@ -792,4 +792,4 @@ Release Timeline `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Jazzy pull requests. .. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. diff --git a/source/Get-Started/Releases/Release-Kilted-Kaiju.rst b/source/Get-Started/Releases/Release-Kilted-Kaiju.rst index 6999ced7818..82168d807e2 100644 --- a/source/Get-Started/Releases/Release-Kilted-Kaiju.rst +++ b/source/Get-Started/Releases/Release-Kilted-Kaiju.rst @@ -556,4 +556,4 @@ Release Timeline `ROS 2 desktop packages `__ source freeze is lifted and ``rosdistro`` is reopened for Kilted pull requests. .. [1] The ``ros_base`` variant is described in `REP 2001 (ros-base) `_. -.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. \ No newline at end of file +.. [2] The ``desktop`` variant is described in `REP 2001 (desktop-variants) `_. diff --git a/source/Get-Started/Releases/Release-Process.rst b/source/Get-Started/Releases/Release-Process.rst index a69aaff1d80..0d5e740ad2e 100644 --- a/source/Get-Started/Releases/Release-Process.rst +++ b/source/Get-Started/Releases/Release-Process.rst @@ -73,4 +73,4 @@ For the progress through this process for a specific release, see that release's * - Final release preparations - As the new distribution enters is absolutely-completely-everything-frozen phase, the final preparations are made for the release. These include things like producing binary packages using the build farm so there will be something to release. * - Release - - The big day, which if all goes to plan coincides with World Turtle Day on May 23rd. The distribution's binary packages are made available in the release repository, and an announcement is made. Parties are held and the ROS 2 development team takes a well-earned break. \ No newline at end of file + - The big day, which if all goes to plan coincides with World Turtle Day on May 23rd. The distribution's binary packages are made available in the release repository, and an announcement is made. Parties are held and the ROS 2 development team takes a well-earned break. diff --git a/source/Get-Started/Releases/Release-Rolling-Ridley.rst b/source/Get-Started/Releases/Release-Rolling-Ridley.rst index 7186bca18e3..419bad1700a 100644 --- a/source/Get-Started/Releases/Release-Rolling-Ridley.rst +++ b/source/Get-Started/Releases/Release-Rolling-Ridley.rst @@ -44,4 +44,4 @@ New features and changes in this release ---------------------------------------- Rolling Ridley is an ongoing development distribution. -Changes between the current stable release and the upcoming one can be found on the page for the `upcoming release `. \ No newline at end of file +Changes between the current stable release and the upcoming one can be found on the page for the `upcoming release `. diff --git a/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst b/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst index 00c4a68031b..68a3d0e0435 100644 --- a/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst +++ b/source/Integrations-and-related/Deploying-ROS-2-on-IBM-Cloud.rst @@ -589,4 +589,4 @@ At this point, you are capable of creating your own docker image using ROS 2 pac It is also possible, with little changes to utilize local ROS 2 packages as well. This could be the topic of another article. However, you are encouraged to check out the following `Dockerfile `__ which uses a local copy of the demos repository. -Similarly, you can use your own local package. \ No newline at end of file +Similarly, you can use your own local package. diff --git a/source/Integrations-and-related/Related-Projects.rst b/source/Integrations-and-related/Related-Projects.rst index 3760714cd66..3db16aba59b 100644 --- a/source/Integrations-and-related/Related-Projects.rst +++ b/source/Integrations-and-related/Related-Projects.rst @@ -50,4 +50,4 @@ Company-driven Projects Related-Projects/Intel-ROS2-Projects Related-Projects/Nvidia-ROS2-Projects Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge - Related-Projects/Visualizing-ROS-2-Data-With-Foxglove \ No newline at end of file + Related-Projects/Visualizing-ROS-2-Data-With-Foxglove diff --git a/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst b/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst index be48402d9ad..2e0f0aef008 100644 --- a/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst +++ b/source/Integrations-and-related/Related-Projects/Intel-ROS2-Projects.rst @@ -29,4 +29,4 @@ We are working on below ROS 2 projects and publish source code through https://g Reference --------- -ROS components at: https://wiki.ros.org/IntelROSProject shows the relationship among those packages, which also applies to ROS 2. \ No newline at end of file +ROS components at: https://wiki.ros.org/IntelROSProject shows the relationship among those packages, which also applies to ROS 2. diff --git a/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst b/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst index 25b86491248..10a05982f8b 100644 --- a/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst +++ b/source/Integrations-and-related/Related-Projects/Nvidia-ROS2-Projects.rst @@ -37,4 +37,4 @@ Simulation Projects References ---------- -More updates on NVIDIA Jetson ROS 2 can be found `here `__. \ No newline at end of file +More updates on NVIDIA Jetson ROS 2 can be found `here `__. diff --git a/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst b/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst index 8b86bd6c9e4..35e736c0d7d 100644 --- a/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst +++ b/source/Integrations-and-related/Related-Projects/Visualizing-Data-And-Teleoperating-With-Phantom-Bridge.rst @@ -11,4 +11,4 @@ Redirecting to `https://docs.phntm.io/bridge `_... \ No newline at end of file + diff --git a/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst b/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst index da8eba9505f..46ebe23a2a8 100644 --- a/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst +++ b/source/Integrations-and-related/Related-Projects/Visualizing-ROS-2-Data-With-Foxglove.rst @@ -223,4 +223,4 @@ Edit the template to customize your message before hitting "Publish". .. image:: foxglove/publish.png :width: 300 px - :alt: Foxglove's Publish panel \ No newline at end of file + :alt: Foxglove's Publish panel diff --git a/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst b/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst index 1e2ef8a6dcc..0ed8beec7f1 100644 --- a/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst +++ b/source/Integrations-and-related/Simulators/Gazebo/Gazebo.rst @@ -63,4 +63,4 @@ If you use a different version of Gazebo than the recommended version, make sure Summary ------- -In this tutorial, you have installed Gazebo and set-up your workspace to start with the `Gazebo tutorials `__. \ No newline at end of file +In this tutorial, you have installed Gazebo and set-up your workspace to start with the `Gazebo tutorials `__. diff --git a/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst b/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst index a881050252e..a9c3600ad71 100644 --- a/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst +++ b/source/Integrations-and-related/Simulators/Gazebo/Simulation-Gazebo.rst @@ -14,4 +14,4 @@ This set of tutorials will teach you how to configure the Gazebo simulator with .. toctree:: :maxdepth: 1 - Gazebo \ No newline at end of file + Gazebo diff --git a/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst index 37b40b22782..90b0fa3c6a3 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Defining-Worlds-MVSim.rst @@ -343,4 +343,4 @@ Further resources - `MVSim documentation `__ - `MVSim GitHub repository `__ -- `MVSim paper (SoftwareX) `__ \ No newline at end of file +- `MVSim paper (SoftwareX) `__ diff --git a/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst index 419f91b3ba7..de21a990de2 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Getting-Started-MVSim.rst @@ -143,4 +143,4 @@ Summary In this tutorial, you launched MVSim demo worlds both standalone and with ROS 2. You learned how to control robots with keyboard and ROS 2 topics, inspect the published topics, and visualize data in RViz2. -The next tutorial covers how to define your own worlds with custom robots and sensors. \ No newline at end of file +The next tutorial covers how to define your own worlds with custom robots and sensors. diff --git a/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst b/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst index 196f61cf0fe..f652e667563 100644 --- a/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst +++ b/source/Integrations-and-related/Simulators/MVSim/Simulation-MVSim.rst @@ -22,4 +22,4 @@ with low computational overhead and fast iteration times. Installation-Ubuntu Getting-Started-MVSim - Defining-Worlds-MVSim \ No newline at end of file + Defining-Worlds-MVSim diff --git a/source/Integrations-and-related/Simulators/Simulation-Main.rst b/source/Integrations-and-related/Simulators/Simulation-Main.rst index 79e71b154bd..520d4f39616 100644 --- a/source/Integrations-and-related/Simulators/Simulation-Main.rst +++ b/source/Integrations-and-related/Simulators/Simulation-Main.rst @@ -23,4 +23,4 @@ This set of tutorials will teach you how to configure different simulators with Webots/Simulation-Webots Gazebo/Simulation-Gazebo - MVSim/Simulation-MVSim \ No newline at end of file + MVSim/Simulation-MVSim diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst b/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst index cc81eb6f79c..ab67d8d015b 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-MacOS.rst @@ -210,4 +210,4 @@ Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universa $ ros2 launch webots_ros2_universal_robot multirobot_launch.py -If Webots is closed or the ROS 2 process is interrupted, the local server will automatically wait for a new package launch and the shared folder will be cleaned for the next run. \ No newline at end of file +If Webots is closed or the ROS 2 process is interrupted, the local server will automatically wait for a new package launch and the shared folder will be cleaned for the next run. diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst b/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst index 4a0ed18abc1..a4ecaa18d71 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-Ubuntu.rst @@ -132,4 +132,4 @@ Use the ROS 2 launch command to start demo packages (e.g. ``webots_ros2_universa .. code-block:: console - $ ros2 launch webots_ros2_universal_robot multirobot_launch.py \ No newline at end of file + $ ros2 launch webots_ros2_universal_robot multirobot_launch.py diff --git a/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst b/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst index 7ec8aacb081..ce3598477c0 100644 --- a/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst +++ b/source/Integrations-and-related/Simulators/Webots/Installation-Windows.rst @@ -200,4 +200,4 @@ To use RViz, you can either upgrade WSL or enable X11 forwarding. .. code-block:: console - $ echo "export DISPLAY=$(ip route list default | awk '{print }'):0" >> ~/.bashrc \ No newline at end of file + $ echo "export DISPLAY=$(ip route list default | awk '{print }'):0" >> ~/.bashrc diff --git a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst index 5d4e30a373a..64f1ba4b7ad 100644 --- a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst +++ b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Advanced.rst @@ -228,4 +228,4 @@ Next steps You might want to improve the plugin or create new nodes to change the behavior of the robot. You can also implement a reset handler to automatically restart your ROS nodes when the simulation is reset from the Webots interface: -* :doc:`Simulation-Reset-Handler`. \ No newline at end of file +* :doc:`Simulation-Reset-Handler`. diff --git a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst index 7b175f09e6e..ddf6620f2f6 100644 --- a/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst +++ b/source/Integrations-and-related/Simulators/Webots/Setting-Up-Simulation-Webots-Basic.rst @@ -524,4 +524,4 @@ Next steps To improve the simulation, the robot's sensors can be used to detect obstacles and avoid them. The second part of the tutorial shows how to implement such behaviour: -* :doc:`Setting-Up-Simulation-Webots-Advanced`. \ No newline at end of file +* :doc:`Setting-Up-Simulation-Webots-Advanced`. diff --git a/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst b/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst index 1735d800ce0..459f9f597ad 100644 --- a/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst +++ b/source/Integrations-and-related/Simulators/Webots/Simulation-Reset-Handler.rst @@ -194,4 +194,4 @@ Summary In this tutorial, you learned how to implement a reset handler in a robot simulation using Webots. The reset handler allows you to restart specific nodes or perform additional actions when the reset button in Webots is pressed. -You explored different approaches based on the complexity of your simulation and the requirements of your nodes. \ No newline at end of file +You explored different approaches based on the complexity of your simulation and the requirements of your nodes. diff --git a/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst b/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst index 34286484aaf..856f1a2ed8f 100644 --- a/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst +++ b/source/Integrations-and-related/Simulators/Webots/Simulation-Supervisor.rst @@ -146,4 +146,4 @@ Summary ------- In this tutorial, you learned how to enable the ``Ros2Supervisor`` and how to extend the interface with the Webots simulation. -The node creates multiple services and topics to interact with and modify the simulation. \ No newline at end of file +The node creates multiple services and topics to interact with and modify the simulation. diff --git a/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst b/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst index bf5803bcdce..038d66436d9 100644 --- a/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst +++ b/source/Integrations-and-related/Simulators/Webots/Simulation-Webots.rst @@ -20,4 +20,4 @@ This set of tutorials will teach you how to configure the Webots simulator with Setting-Up-Simulation-Webots-Basic Setting-Up-Simulation-Webots-Advanced Simulation-Reset-Handler - Simulation-Supervisor \ No newline at end of file + Simulation-Supervisor diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1.rst index 45ea0433c43..97d8a9f608a 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1.rst @@ -30,4 +30,4 @@ There are also some automatic conversion tools that exist, though they are not e * `Magical ROS 2 Conversion Tool `_ * Launch File migrator that converts a ROS 1 XML launch file to a ROS 2 Python launch file: https://github.com/aws-robotics/ros2-launch-file-migrator * Amazon has made their tools for porting from ROS 1 to ROS 2 available at: https://github.com/awslabs/ros2-migration-tools/tree/master/porting\_tools -* `rospy2 `_ Python project to automatically convert rospy calls to rclpy calls \ No newline at end of file +* `rospy2 `_ Python project to automatically convert rospy calls to rclpy calls diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst index 514628727f1..94b23e362d9 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Package-Example.rst @@ -440,4 +440,4 @@ Conclusion ---------- You have learned how to migrate an example C++ ROS 1 package to ROS 2. -Use the :doc:`Migrating C++ Packages reference page ` to help you migrate your own C++ packages from ROS 1 to ROS 2. \ No newline at end of file +Use the :doc:`Migrating C++ Packages reference page ` to help you migrate your own C++ packages from ROS 1 to ROS 2. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst index af5c9bd02af..5f6b4d03f0f 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-CPP-Packages.rst @@ -475,4 +475,4 @@ Replace: * ``#include `` with ``#include `` -* ``boost::function`` with ``std::function`` \ No newline at end of file +* ``boost::function`` with ``std::function`` diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst index d7ec9bd6bba..e72fb51f6ca 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Interfaces.rst @@ -52,4 +52,4 @@ In your ``CMakeLists.txt``: * Add ``find_package(rosidl_default_generators REQUIRED)`` * For each dependent message package, add ``find_package(message_package REQUIRED)`` and replace the CMake function call to ``generate_messages`` with ``rosidl_generate_interfaces``. -This will replace ``add_message_files`` and ``add_service_files`` listing of all the message and service files, which can be removed. \ No newline at end of file +This will replace ``add_message_files`` and ``add_service_files`` listing of all the message and service files, which can be removed. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst index 90e2fef97c2..6b805f188cb 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files.rst @@ -459,4 +459,4 @@ For example: Some attributes accept more than a single type, for example ``value`` attribute of ``param`` tag. -It's usual that parameters that are of type ``int`` (or ``float``) also accept an ``str``, that will be later substituted and tried to convert to an ``int`` (or ``float``) by the action. \ No newline at end of file +It's usual that parameters that are of type ``int`` (or ``float``) also accept an ``str``, that will be later substituted and tried to convert to an ``int`` (or ``float``) by the action. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst index fbdebdc1dd7..d0d0e667622 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Package-XML.rst @@ -133,4 +133,4 @@ Test your new ``package.xml`` ----------------------------- Build and test your package as you normally do using ``catkin_make``, ``cakin_make_isolated``, or the ``catkin`` build tool. -If everything succeeds, then your ``package.xml`` is valid. \ No newline at end of file +If everything succeeds, then your ``package.xml`` is valid. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst index 79fd5b70690..d4d593fd30a 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Packages.rst @@ -62,4 +62,4 @@ Changing the License It is possible to change the license, however you will need to contact all the contributors and get permission. For most packages this is likely to be a significant effort and not worth considering. -If the package has a small set of contributors then this may be feasible. \ No newline at end of file +If the package has a small set of contributors then this may be feasible. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst index 7b9984d987a..2a83a984cb7 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters.rst @@ -99,4 +99,4 @@ When migrating parameter groups from ROS 1 to ROS 2, there are important differe In ROS 1, ``dynamic_reconfigure`` handles parameter groups atomically, meaning all parameters in a reconfiguration request are processed together in a single callback. In ROS 2, the ``set_parameters`` service processes each parameter individually, which may lead to multiple callback invocations. To maintain atomic behavior when migrating from ``dynamic_reconfigure``, use the ``set_parameters_atomically`` service, which validates and applies all parameters as a single operation. -If any parameter fails validation, no parameters will be updated. \ No newline at end of file +If any parameter fails validation, no parameters will be updated. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst index 9b65af521e1..f8dd6bc0635 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Package-Example.rst @@ -862,4 +862,4 @@ Conclusion ---------- You have learned how to migrate an example Python ROS 1 package to ROS 2. -From now on, refer to the :doc:`Migrating Python Packages reference page ` as you migrate your own Python packages. \ No newline at end of file +From now on, refer to the :doc:`Migrating Python Packages reference page ` as you migrate your own Python packages. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst index 6bbae5e3486..f8dc68376cc 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Python-Packages.rst @@ -175,4 +175,4 @@ In ROS 2: .. warning:: Do not use ``rclpy.spin_until_future_complete`` in a ROS 2 callback. - For more details see the :doc:`sync deadlock article <../../ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file + For more details see the :doc:`sync deadlock article <../../ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async>`. diff --git a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst index 3591d84d007..41352342678 100644 --- a/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst +++ b/source/Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Scripts.rst @@ -69,4 +69,4 @@ Quick reference | node name | __name:=foo | -r __node:=foo | +------------+-------------+----------------+ | namespace | __ns:=foo | -r __ns:=foo | -+------------+-------------+----------------+ \ No newline at end of file ++------------+-------------+----------------+ diff --git a/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst b/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst index 1d0e950c9cf..240528301c1 100644 --- a/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst +++ b/source/Migration-and-Upgrades/Using-Custom-Rosdistro.rst @@ -68,4 +68,4 @@ A previous index also exists without the ``v4`` which is still present for histo Afterward, you can ``rosdep update``, which will now use the changes to update the index in accordance to the Rolling distribution's state on February 28, 2024 before the breakages began. You can see this in action in `Nav2's CircleCI `_ and `ros_gz's GitHub Actions `_ in order to bypass a temporary Rolling outage in their CI systems. -.. Note:: If you are using a custom rosdistro version, you can substitute the final URLs in the default list and index URL with your fork or index location. \ No newline at end of file +.. Note:: If you are using a custom rosdistro version, you can substitute the final URLs in the default list and index URL with your fork or index location. diff --git a/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst b/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst index 2acc70cf4ce..6575cc3c6b3 100644 --- a/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst +++ b/source/Migration-and-Upgrades/Using-ros1_bridge-Jammy-upstream.rst @@ -108,4 +108,4 @@ Build ``ros1_bridge`` $. ~/ros2_humble/install/local_setup.bash # Source the ROS 2 workspace $ colcon build # Build -After building all of ``ros1_bridge``, the remainder of the `ros1_bridge examples `__ should work with your new installation \ No newline at end of file +After building all of ``ros1_bridge``, the remainder of the `ros1_bridge examples `__ should work with your new installation diff --git a/source/ROS-Framework/About-Parameters.rst b/source/ROS-Framework/About-Parameters.rst index c1e8e62559d..de79f9c879a 100644 --- a/source/ROS-Framework/About-Parameters.rst +++ b/source/ROS-Framework/About-Parameters.rst @@ -136,4 +136,4 @@ Migrating from ROS 1 The :doc:`Launch file migration guide <../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Launch-Files>` explains how to migrate ``param`` and ``rosparam`` launch tags from ROS 1 to ROS 2. -The :doc:`Migration guide <../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` explains how to migrate parameter from ROS 1 to ROS 2. \ No newline at end of file +The :doc:`Migration guide <../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` explains how to migrate parameter from ROS 1 to ROS 2. diff --git a/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst b/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst index a7972aaed9c..355dd3f90a9 100644 --- a/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst +++ b/source/ROS-Framework/client-libraries/About-Different-Middleware-Vendors.rst @@ -113,4 +113,4 @@ Cross-Vendor Communication among DDS middleware For many cases you will find that nodes using different DDS middleware implementations are able to communicate, however this is not true under all circumstances. While the different DDS implementations may be compatible in limited circumstances, this is not guaranteed. -Thus it is suggested that users ensure that all parts of a distributed system are using the same ROS version and the same RMW implementation. \ No newline at end of file +Thus it is suggested that users ensure that all parts of a distributed system are using the same ROS version and the same RMW implementation. diff --git a/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst b/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst index 3a73442fded..30e8653df3d 100644 --- a/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst +++ b/source/ROS-Framework/client-libraries/About-Executors/About-Executors.rst @@ -238,4 +238,4 @@ Further information ROS Industrial Conference. Virtual event. 16 December 2020. -* Daniel Casini, Tobias Blass, Ingo Lütkebohle, and Björn Brandenburg: `"Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling" `_, Proceedings of 31st ECRTS 2019, Stuttgart, Germany, July 2019. \ No newline at end of file +* Daniel Casini, Tobias Blass, Ingo Lütkebohle, and Björn Brandenburg: `"Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling" `_, Proceedings of 31st ECRTS 2019, Stuttgart, Germany, July 2019. diff --git a/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst index 7ef0536e6da..b652674fe79 100644 --- a/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/About-Internal-Interfaces/About-Internal-Interfaces.rst @@ -238,4 +238,4 @@ These are mainly used for error handling, commandline argument parsing, and logg The ``rcutils`` |API| and implementation are located in the `ros2/rcutils `_ repository on |GitHub|_ which contains the interface as C headers. -For a complete definition of the ``rcutils`` |API|, see `the rcutils docs `_. \ No newline at end of file +For a complete definition of the ``rcutils`` |API|, see `the rcutils docs `_. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst index 947cc9ae971..3258190b1e5 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries.rst @@ -25,4 +25,4 @@ Working with Client libraries Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP Working-with-Client-Libraries/Reading-From-A-Bag-File-Python Working-with-Client-Libraries/Creating-An-RMW-Implementation - Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages \ No newline at end of file + Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst index da2a6093cc0..c02f39c4fbe 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Allocator-Template-Tutorial.rst @@ -242,4 +242,4 @@ For more information about TLSF, see `this page via Universitat Politècnica de Note that the TLSF allocator is licensed under a dual-GPL/LGPL license. A full working example using the TLSF allocator is here: -https://github.com/ros2/realtime_support/blob/{REPOS_FILE_BRANCH}/tlsf_cpp/example/allocator_example.cpp \ No newline at end of file +https://github.com/ros2/realtime_support/blob/{REPOS_FILE_BRANCH}/tlsf_cpp/example/allocator_example.cpp diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst index 558609fe765..5cd21b25daa 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Colcon-Tutorial.rst @@ -388,4 +388,4 @@ Then, try out using the ``debug`` mixin: $ colcon build --mixin debug -For more details, see the `colcon mixin repository `__. \ No newline at end of file +For more details, see the `colcon mixin repository `__. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst index 9d6fd5294ab..b7b3d2fef16 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Configure-ZeroCopy-loaned-messages.rst @@ -275,4 +275,4 @@ To enable *Loaned Messages* on subscription, you need to set the environment var .. code-block:: console - $ setx ROS_DISABLE_LOANED_MESSAGES 0 \ No newline at end of file + $ setx ROS_DISABLE_LOANED_MESSAGES 0 diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst index 010a0d69080..523765ea549 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-A-Workspace/Creating-A-Workspace.rst @@ -402,4 +402,4 @@ Using overlays is recommended for working on a small number of packages, so you Next steps ---------- -Now that you understand the details behind creating, building and sourcing your own workspace, you can learn how to :doc:`create your own packages <../Creating-Your-First-ROS2-Package>`. \ No newline at end of file +Now that you understand the details behind creating, building and sourcing your own workspace, you can learn how to :doc:`create your own packages <../Creating-Your-First-ROS2-Package>`. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst index 03a35ca82b3..217524a29b6 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-An-RMW-Implementation.rst @@ -482,4 +482,4 @@ Footnotes For example, the C++ message Fast CDR serialization/deserialization code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_fastrtps_cpp/std_msgs/msg/detail/dds_fastrtps/header__type_support.cpp`` under the ``build/`` directory. .. [#fn_ts_dynamic] - For example, the C++ message introspection code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_introspection_cpp/std_msgs/msg/detail/header__type_support.cpp`` under the ``build/`` directory. \ No newline at end of file + For example, the C++ message introspection code generated for {interface(std_msgs/msg/Header)} is at ``std_msgs/rosidl_typesupport_introspection_cpp/std_msgs/msg/detail/header__type_support.cpp`` under the ``build/`` directory. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst index ec136d3c4b7..93cd52f50df 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Creating-Your-First-ROS2-Package.rst @@ -535,4 +535,4 @@ Next steps ---------- Next, let's add something meaningful to a package. -You'll start with a simple publisher/subscriber system, which you can choose to write in either :doc:`C++ ` or :doc:`Python `. \ No newline at end of file +You'll start with a simple publisher/subscriber system, which you can choose to write in either :doc:`C++ ` or :doc:`Python `. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst index bcb815c6a8a..54c3caa2490 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Custom-ROS2-Interfaces.rst @@ -797,4 +797,4 @@ You can learn more about it in :doc:`About ROS 2 interfaces <../../interfaces/Ab Next steps ---------- -The :doc:`next tutorial ` covers more ways to use interfaces in ROS 2. \ No newline at end of file +The :doc:`next tutorial ` covers more ways to use interfaces in ROS 2. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst index e8e6ed1ddd9..fe0f4dd2da2 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Getting-Started-With-Ros2doctor.rst @@ -215,4 +215,4 @@ You might want to take a look around the ``ros2doctor`` repo as well, since it's Next steps ---------------- -You've completed the beginner level tutorials! \ No newline at end of file +You've completed the beginner level tutorials! diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst index ea1ac557f90..202ccd992c9 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Pluginlib.rst @@ -368,4 +368,4 @@ Summary ------- Congratulations! -You've just written and used your first plugins. \ No newline at end of file +You've just written and used your first plugins. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst index c5c475c5c37..d74db1aee75 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-CPP.rst @@ -324,4 +324,4 @@ Summary ------- You created a C++ executable that reads data from a bag. -You then compiled and ran the executable which printed some information from the bag to the console. \ No newline at end of file +You then compiled and ran the executable which printed some information from the bag to the console. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst index e236774c6fa..067b35b8a02 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Reading-From-A-Bag-File-Python.rst @@ -261,4 +261,4 @@ Summary You created a Python node that reads data from a bag. You tested reading a bag using the node, and publishing the data by playing back the bag. -This approach can be used to read and publish the data with additional data from the bag file, for example modifying the original data stored in the bag file. \ No newline at end of file +This approach can be used to read and publish the data with additional data from the bag file, for example modifying the original data stored in the bag file. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst index 11dd5eb053e..fad455e2077 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-CPP.rst @@ -678,4 +678,4 @@ Summary You created a node that records data it receives on a topic into a bag. You tested recording a bag using the node, and verified the data was recorded by playing back the bag. -You then went on to create a node and an executable to generate synthetic data and store it in a bag. \ No newline at end of file +You then went on to create a node and an executable to generate synthetic data and store it in a bag. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst index 057b6ab6a4b..36001728292 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Recording-A-Bag-From-Your-Own-Node-Py.rst @@ -676,4 +676,4 @@ You created a node that records data it receives on a topic into a bag. You tested recording a bag using the node, and verified the data was recorded by playing back the bag. This approach can be used to record a bag with additional data than it received over a topic, for example with results obtained from processing the received data. You then went on to create a node and an executable to generate synthetic data and store it in a bag. -The latter approaches are useful especially for generating synthetic data that can be used, for example, as training sets. \ No newline at end of file +The latter approaches are useful especially for generating synthetic data that can be used, for example, as training sets. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst index addea48c263..328ae44da50 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Rosdep.rst @@ -205,4 +205,4 @@ Breaking that down: There are additional arguments and options available. Use ``rosdep -h`` to see them, or look at the more complete documentation for rosdep at http://docs.ros.org/en/independent/api/rosdep/html/ . -.. [1] "released into the ROS ecosystem" means the package is listed in one or more of the ``/distribution.yaml`` directories in the `rosdistro database `_. \ No newline at end of file +.. [1] "released into the ROS ecosystem" means the package is listed in one or more of the ``/distribution.yaml`` directories in the `rosdistro database `_. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst index 86c2eaadb28..6b0651c6201 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Single-Package-Define-And-Use-Interface.rst @@ -469,4 +469,4 @@ Again, you can choose to write it in either :doc:`C++ `_ on ROS 2 interfaces and the IDL (interface definition language). \ No newline at end of file +There are `several design articles `_ on ROS 2 interfaces and the IDL (interface definition language). diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst index 523b62d8f2e..cd6f95074bd 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Cpp.rst @@ -584,4 +584,4 @@ Summary ------- In this tutorial, you learned about the tf2 transformation tree, its structure, and its features. -You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. \ No newline at end of file +You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst index 5999c92c594..5566bb3baec 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Adding-A-Frame-Py.rst @@ -540,4 +540,4 @@ Summary ------- In this tutorial, you learned about the tf2 transformation tree, its structure, and its features. -You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. \ No newline at end of file +You also learned that it is easiest to think inside a local frame, and learned to add extra fixed and dynamic frames for that local frame. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst index 60a5883306f..7aabf8e3e29 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Learning-About-Tf2-And-Time-Cpp.rst @@ -135,4 +135,4 @@ Once the timeout has been reached (fifty milliseconds in this case), an exceptio Summary ------- -In this tutorial, you learned how to acquire a transform at a specific timestamp and how to wait for a transform to be available on the tf2 tree when using the ``lookupTransform()`` function. \ No newline at end of file +In this tutorial, you learned how to acquire a transform at a specific timestamp and how to wait for a transform to be available on the tf2 tree when using the ``lookupTransform()`` function. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst index 20d2911cecc..009e0c32b85 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Tf2-Main.rst @@ -86,4 +86,4 @@ Using sensor messages with tf2 #. :doc:`Using stamped datatypes with tf2_ros::MessageFilter `. - This tutorial teaches you how to use ``tf2_ros::MessageFilter`` to process stamped datatypes. \ No newline at end of file + This tutorial teaches you how to use ``tf2_ros::MessageFilter`` to process stamped datatypes. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst index 75b077b4184..427f26cb577 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Time-Travel-With-Tf2-Cpp.rst @@ -156,4 +156,4 @@ Summary In this tutorial, you have seen one of the advanced features of tf2. You learned that tf2 can transform data in time and learned how to do that with turtlesim example. -tf2 allowed you to go back in time and make frame transformations between old and current poses of turtles by using the advanced ``lookupTransform()`` API. \ No newline at end of file +tf2 allowed you to go back in time and make frame transformations between old and current poses of turtles by using the advanced ``lookupTransform()`` API. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst index c40a2916609..630b5dee8d8 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Using-Stamped-Datatypes-With-Tf2-Ros-MessageFilter.rst @@ -769,4 +769,4 @@ Summary ------- In this tutorial you learned how to use sensor data/messages in tf2. -Specifically speaking, you learned how to publish ``PointStamped`` messages on a topic, and how to listen to the topic and transform the frame of ``PointStamped`` messages with ``tf2_ros::MessageFilter``. \ No newline at end of file +Specifically speaking, you learned how to publish ``PointStamped`` messages on a topic, and how to listen to the topic and transform the frame of ``PointStamped`` messages with ``tf2_ros::MessageFilter``. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst index 28a92529368..d3aca60d34e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Cpp.rst @@ -491,4 +491,4 @@ Summary ------- In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. -To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. \ No newline at end of file +To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst index 14b93c31c7c..39133f560b9 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Broadcaster-Py.rst @@ -509,4 +509,4 @@ Summary ------- In this tutorial you learned how to broadcast the pose of the robot (position and orientation of the turtle) to tf2 and how to use the ``tf2_echo`` tool. -To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. \ No newline at end of file +To actually use the transforms broadcasted to tf2, you should move on to the next tutorial about creating a :doc:`tf2 listener `. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst index 70f761a5250..b493735ad2e 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Cpp.rst @@ -412,4 +412,4 @@ Summary ------- In this tutorial you learned how to use tf2 to get access to frame transformations. -You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. \ No newline at end of file +You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst index ebb3eacb191..e1a02e08676 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Listener-Py.rst @@ -366,4 +366,4 @@ Summary ------- In this tutorial you learned how to use tf2 to get access to frame transformations. -You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. \ No newline at end of file +You also have finished writing your own turtlesim demo that you first tried in :doc:`Introduction to tf2 <../../../interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2>` tutorial. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst index 90d8cc9fd41..b91fd5ad1be 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Cpp.rst @@ -437,4 +437,4 @@ Summary In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. -Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. \ No newline at end of file +Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst index 2919b7ceaa9..8aeb9438517 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Tf2/Writing-A-Tf2-Static-Broadcaster-Py.rst @@ -456,4 +456,4 @@ Summary In this tutorial you learned how static transforms are useful to define static relationships between frames, like ``mystaticturtle`` in relation to the ``world`` frame. In addition, you learned how static transforms can be useful for understanding sensor data, such as from laser scanners, by relating the data to a common coordinate frame. -Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. \ No newline at end of file +Finally, you wrote your own node to publish static transforms to tf2 and learned how to publish required static transformations using ``static_transform_publisher`` executable and launch files. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst index 894705aeec4..6c002aa5764 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-CPP.rst @@ -437,4 +437,4 @@ Related content --------------- * For more detailed information about using YAML files to load parameters, please refer to :ref:`this section ` of Managing large projects tutorial. -* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (C++) <../../parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP>` tutorial. \ No newline at end of file +* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (C++) <../../parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP>` tutorial. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst index 221ac557191..af83df9ae16 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Using-Parameters-In-A-Class-Python.rst @@ -448,4 +448,4 @@ Related content --------------- * For more detailed information about using YAML files to load parameters, please refer to :ref:`this section ` of Managing large projects tutorial. -* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (Python) <../../parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python>` tutorial. \ No newline at end of file +* If you want to learn, how to monitor and respond to parameter changes, check out :doc:`Monitoring for parameter changes (Python) <../../parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python>` tutorial. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst index bd76ae118cb..344a199b88b 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Publisher-And-Subscriber.rst @@ -534,4 +534,4 @@ Again, you can choose to write it in either :doc:`C++ `_ repo. \ No newline at end of file +There are several ways you could write a publisher and subscriber in C++; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst index 35bbbb361ff..52531ac1a1b 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Cpp-Service-And-Client.rst @@ -407,4 +407,4 @@ Next, you'll learn how to :doc:`create custom interfaces `_ repo. \ No newline at end of file +* There are several ways you could write a service and client in C++; check out the ``minimal_service`` and ``minimal_client`` packages in the `ros2/examples `_ repo. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst index d80378374cb..b1c7e040d84 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Publisher-And-Subscriber.rst @@ -513,4 +513,4 @@ Again, you can choose to write it in either :doc:`C++ `_ repo. \ No newline at end of file +There are several ways you could write a publisher and subscriber in Python; check out the ``minimal_publisher`` and ``minimal_subscriber`` packages in the `ros2/examples `_ repo. diff --git a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst index 6ed570d5cfc..a58c3e6dea6 100644 --- a/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst +++ b/source/ROS-Framework/client-libraries/Working-with-Client-Libraries/Writing-A-Simple-Py-Service-And-Client.rst @@ -392,4 +392,4 @@ Related content * In this tutorial, you used the ``call_async()`` API in your client node to call the service. There is another service call API available for Python called synchronous calls. - We do not recommend using synchronous calls, but if you'd like to learn more about them, read the guide to :doc:`Synchronous vs. asynchronous clients <../../interfaces/services/Working-with-services/Sync-Vs-Async>`. \ No newline at end of file + We do not recommend using synchronous calls, but if you'd like to learn more about them, read the guide to :doc:`Synchronous vs. asynchronous clients <../../interfaces/services/Working-with-services/Sync-Vs-Async>`. diff --git a/source/ROS-Framework/interfaces/About-Interfaces.rst b/source/ROS-Framework/interfaces/About-Interfaces.rst index dcac18f1f8e..4c5ee4530aa 100644 --- a/source/ROS-Framework/interfaces/About-Interfaces.rst +++ b/source/ROS-Framework/interfaces/About-Interfaces.rst @@ -311,4 +311,4 @@ For instance, the ``Fibonacci`` action definition contains the following: int32[] sequence This is an action definition where the action client is sending a single ``int32`` field representing the number of Fibonacci steps to take, and expecting the action server to produce an array of ``int32`` containing the complete steps. -Along the way, the action server may also provide an intermediate array of ``int32`` containing the steps accomplished up until a certain point. \ No newline at end of file +Along the way, the action server may also provide an intermediate array of ``int32`` containing the steps accomplished up until a certain point. diff --git a/source/ROS-Framework/interfaces/About-Services.rst b/source/ROS-Framework/interfaces/About-Services.rst index 6c6685cf68b..78aba0e3941 100644 --- a/source/ROS-Framework/interfaces/About-Services.rst +++ b/source/ROS-Framework/interfaces/About-Services.rst @@ -58,4 +58,4 @@ Service client A service client is an entity that will request a remote service server to perform a computation on its behalf. Following from the example above, the service client is the entity that creates the initial message containing ``a`` and ``b``, and waits for the service server to compute the sum and return the result. -Unlike the service server, there can be arbitrary numbers of service clients using the same service name. \ No newline at end of file +Unlike the service server, there can be arbitrary numbers of service clients using the same service name. diff --git a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst index aa8fd2053ea..26eca47509a 100644 --- a/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst +++ b/source/ROS-Framework/interfaces/About-Tf2/About-Tf2.rst @@ -158,4 +158,4 @@ The advanced tutorial about tf2 and time :doc:`(C++) <../../client-libraries/Wor Paper ----- -There is a paper on tf2 presented at TePRA 2013: `tf: The transform library `_. \ No newline at end of file +There is a paper on tf2 presented at TePRA 2013: `tf: The transform library `_. diff --git a/source/ROS-Framework/interfaces/Topics-Services-Actions.rst b/source/ROS-Framework/interfaces/Topics-Services-Actions.rst index 23cc9124ab7..947014719ed 100644 --- a/source/ROS-Framework/interfaces/Topics-Services-Actions.rst +++ b/source/ROS-Framework/interfaces/Topics-Services-Actions.rst @@ -34,4 +34,4 @@ Actions * Slow perception routines which take several seconds to terminate or initiating a lower-level control mode are good use cases for actions. * More complex non-blocking background processing. Used for longer tasks like execution of robot actions. - Semantically for real-world actions. \ No newline at end of file + Semantically for real-world actions. diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst index 6b452eff046..8cb18467633 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Introduction-To-Tf2/Introduction-To-Tf2.rst @@ -170,4 +170,4 @@ Let's look at our turtle frames using ``rviz2`` by starting it with a configurat .. image:: images/turtlesim_rviz.png In the side bar you will see the frames broadcast by tf2. -As you drive the turtle around you will see the frames move in rviz. \ No newline at end of file +As you drive the turtle around you will see the frames move in rviz. diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst index 9b279eea5b3..6d7be307568 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Quaternion-Fundamentals.rst @@ -243,4 +243,4 @@ Summary ------- In this tutorial, you learned about the fundamental concepts of a quaternion and its related mathematical operations, like inversion and rotation. -You also learned about its usage examples in ROS 2 and conversion methods between two separate Quaternion classes. \ No newline at end of file +You also learned about its usage examples in ROS 2 and conversion methods between two separate Quaternion classes. diff --git a/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst b/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst index 21cd2dafdf2..c0015121506 100644 --- a/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst +++ b/source/ROS-Framework/interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data.rst @@ -736,4 +736,4 @@ Related content A more thorough explanation of ``ros2 bag`` can be found in the README `here `__. For more information on service recording and playback can be found in the design document `here `__. For more information on action recording and playback can be found in the design document `here `__. -For more information on QoS compatibility and ``ros2 bag``, see :doc:`../../../../Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback`. \ No newline at end of file +For more information on QoS compatibility and ``ros2 bag``, see :doc:`../../../../Developer-Tools/Testing/Overriding-QoS-Policies-For-Recording-And-Playback`. diff --git a/source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst index 38826475f96..e637d0793be 100644 --- a/source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Action-Introspection.rst @@ -343,4 +343,4 @@ Now you can see the action communication between ``FibonacciActionServer`` and ` Related content --------------- -- `Action Introspection REP-2018 `__. \ No newline at end of file +- `Action Introspection REP-2018 `__. diff --git a/source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst index 52e9977f0cd..945fd977bd4 100644 --- a/source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Creating-an-Action.rst @@ -220,4 +220,4 @@ Next, let's utilize your newly defined action interface by creating an action se Related content --------------- -For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file +For more detailed information about ROS actions, please refer to the `design article `__. diff --git a/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst index 6131e81c02f..c103e2c671e 100644 --- a/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions.rst @@ -422,4 +422,4 @@ The last few tutorials in this set will introduce you to some tools and techniqu Related content --------------- -You can read more about the design decisions behind actions in ROS 2 `here `__. \ No newline at end of file +You can read more about the design decisions behind actions in ROS 2 `here `__. diff --git a/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst index 728e322d69b..86968dbd1a1 100644 --- a/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Cpp.rst @@ -396,4 +396,4 @@ Related content * There are several ways you could write an action server and client in C++; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. -* For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file +* For more detailed information about ROS actions, please refer to the `design article `__. diff --git a/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst index d9262e20e94..8980c41f642 100644 --- a/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst +++ b/source/ROS-Framework/interfaces/actions/Working-with-actions/Writing-an-Action-Server-Client/Py.rst @@ -362,4 +362,4 @@ Related content * There are several ways you could write an action server and client in Python; check out the ``minimal_action_server`` and ``minimal_action_client`` packages in the `ros2/examples `_ repo. -* For more detailed information about ROS actions, please refer to the `design article `__. \ No newline at end of file +* For more detailed information about ROS actions, please refer to the `design article `__. diff --git a/source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst b/source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst index e6c6c239d6f..fdf3e936f8e 100644 --- a/source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst +++ b/source/ROS-Framework/interfaces/services/Working-with-services/Sync-Vs-Async.rst @@ -148,4 +148,4 @@ It is not recommended to implement a synchronous service client. They are susceptible to deadlock, but will not provide any indication of issue when deadlock occurs. If you must use synchronous calls, the example in section `1 Synchronous calls`_ is a safe method of doing so. You should also be aware of the conditions that cause deadlock outlined in section `1.1 Sync deadlock`_. -We recommend using async service clients instead. \ No newline at end of file +We recommend using async service clients instead. diff --git a/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst index 98163f7d833..79d360aeaf4 100644 --- a/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst +++ b/source/ROS-Framework/interfaces/services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services.rst @@ -413,4 +413,4 @@ In the next tutorial, :doc:`../../../../parameters/Working-with-parameters/Under Related content --------------- -Check out `this tutorial `_; it's an excellent realistic application of ROS services using a Robotis robot arm. \ No newline at end of file +Check out `this tutorial `_; it's an excellent realistic application of ROS services using a Robotis robot arm. diff --git a/source/ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings.rst b/source/ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings.rst index ac3c83b152c..32d98b07351 100644 --- a/source/ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings.rst +++ b/source/ROS-Framework/interfaces/topics/About-Quality-of-Service-Settings.rst @@ -333,4 +333,4 @@ Developers can subscribe to this event with a publisher or a subscription. There are demos showing how to use the event: * rclcpp: `demo code `__ -* rclpy: `demo code `__ \ No newline at end of file +* rclpy: `demo code `__ diff --git a/source/ROS-Framework/interfaces/topics/About-Topic-Statistics.rst b/source/ROS-Framework/interfaces/topics/About-Topic-Statistics.rst index 95630a44dbb..3380c780970 100644 --- a/source/ROS-Framework/interfaces/topics/About-Topic-Statistics.rst +++ b/source/ROS-Framework/interfaces/topics/About-Topic-Statistics.rst @@ -69,4 +69,4 @@ Support This feature is currently supported in ROS 2 Foxy for C++ only (rclcpp). Future work and improvements, such as Python support, can be found -`here `__. \ No newline at end of file +`here `__. diff --git a/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst index eef5142e177..d8269db4530 100644 --- a/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst +++ b/source/ROS-Framework/interfaces/topics/Understanding-ROS2-Topics/Understanding-ROS2-Topics.rst @@ -547,4 +547,4 @@ You should now have a good idea of how data moves around a ROS 2 system. Next steps ---------- -Next you'll learn about another communication type in the ROS graph with the tutorial :doc:`../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services`. \ No newline at end of file +Next you'll learn about another communication type in the ROS graph with the tutorial :doc:`../../services/Working-with-services/Understanding-ROS2-Services/Understanding-ROS2-Services`. diff --git a/source/ROS-Framework/interfaces/topics/Working-with-topics.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics.rst index 02429afec16..b8ff3e1921b 100644 --- a/source/ROS-Framework/interfaces/topics/Working-with-topics.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics.rst @@ -12,4 +12,4 @@ PLACEHOLDER Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial Working-with-topics/Content-Filtering-Subscription Working-with-topics/Quality-of-Service - Working-with-topics/Wait-for-Acknowledgment \ No newline at end of file + Working-with-topics/Wait-for-Acknowledgment diff --git a/source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst index 943e2fea0d2..03a2bb763b0 100644 --- a/source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Content-Filtering-Subscription.rst @@ -309,4 +309,4 @@ Related content --------------- - `content filtering examples `__ that covers all interfaces for content filtering subscription. -- `content filtering design PR `__ \ No newline at end of file +- `content filtering design PR `__ diff --git a/source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst index b68fb865827..133f2b09070 100644 --- a/source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Quality-of-Service.rst @@ -185,4 +185,4 @@ When you're done, remember to delete the queueing discipline: .. code-block:: console - $ sudo tc qdisc delete dev lo root netem loss 5% \ No newline at end of file + $ sudo tc qdisc delete dev lo root netem loss 5% diff --git a/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst index 0cd6ecd7509..e51d899ca01 100644 --- a/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Filtered-Topic-Keys-Tutorial.rst @@ -386,4 +386,4 @@ That is specified in the filter expression ``sensor_id >= 2 AND sensor_id <= 4 A Even in a late-joining scenario, the controller node will receive the latest data of the sensors that meet the filtering criteria at the moment it joins the application, which could be crucial depending on the type of the real application. Overall, the combination of topic instances with a content filter topic offers significant benefits in terms of data efficiency, scalability, adaptability and resource optimization. -By leveraging these capabilities, ROS 2 applications can efficiently manage and distribute data in complex distributed environments. \ No newline at end of file +By leveraging these capabilities, ROS 2 applications can efficiently manage and distribute data in complex distributed environments. diff --git a/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst index 13eef26ab4e..0870f993eef 100644 --- a/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Topic-Keys/Topic-Keys-Tutorial.rst @@ -583,4 +583,4 @@ In this final case, the controller is able to successfully recover the latest st In addition, it uses optimum resources (it only requires one topic and one subscription) and guarantees a minimum discovery overhead. Hence, it is by using topic keys when the reception of the latest status of each instance (sensor) is assured. This is because the Quality of Service settings are applied per data instance. -For learning how to combine keyed topics with content filter topic, please refer to the :ref:`filtered_topic_keys_tutorial`. \ No newline at end of file +For learning how to combine keyed topics with content filter topic, please refer to the :ref:`filtered_topic_keys_tutorial`. diff --git a/source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst b/source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst index e30ca835c66..c66341c8419 100644 --- a/source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst +++ b/source/ROS-Framework/interfaces/topics/Working-with-topics/Wait-for-Acknowledgment.rst @@ -94,4 +94,4 @@ If not, it will print a message indicating that not all subscribers acknowledged Related content --------------- -- `Wait-for-Acknowledgment example with rclpy `__. \ No newline at end of file +- `Wait-for-Acknowledgment example with rclpy `__. diff --git a/source/ROS-Framework/nodes/About-Composition.rst b/source/ROS-Framework/nodes/About-Composition.rst index 7e56e0d063b..076ac9b5743 100644 --- a/source/ROS-Framework/nodes/About-Composition.rst +++ b/source/ROS-Framework/nodes/About-Composition.rst @@ -135,4 +135,4 @@ The three most common ones are: Practical application --------------------- -Try the :doc:`Composition demos `. \ No newline at end of file +Try the :doc:`Composition demos `. diff --git a/source/ROS-Framework/nodes/About-Discovery.rst b/source/ROS-Framework/nodes/About-Discovery.rst index e95691d98c3..bdf8144adb3 100644 --- a/source/ROS-Framework/nodes/About-Discovery.rst +++ b/source/ROS-Framework/nodes/About-Discovery.rst @@ -22,4 +22,4 @@ Take the :ref:`talker-listener demo ` for example. Running the C++ talker node in one terminal will publish messages on a topic, and the Python listener node running in another terminal will subscribe to messages on the same topic. -You should see that these nodes discover each other automatically, and begin to exchange messages. \ No newline at end of file +You should see that these nodes discover each other automatically, and begin to exchange messages. diff --git a/source/ROS-Framework/nodes/About-Domain-ID.rst b/source/ROS-Framework/nodes/About-Domain-ID.rst index 48e96f48c1c..1f8496f5f4b 100644 --- a/source/ROS-Framework/nodes/About-Domain-ID.rst +++ b/source/ROS-Framework/nodes/About-Domain-ID.rst @@ -161,4 +161,4 @@ Domain ID to UDP Port Calculator discoveryUnicastPort.value = PB + (DG * domainID.value) + d1 + (PG * participantID.value); userUnicastPort.value = PB + (DG * domainID.value) + d3 + (PG * participantID.value); } - \ No newline at end of file + diff --git a/source/ROS-Framework/nodes/About-Logging/About-Logging.rst b/source/ROS-Framework/nodes/About-Logging/About-Logging.rst index d2da959a9c7..1f95a9359cf 100644 --- a/source/ROS-Framework/nodes/About-Logging/About-Logging.rst +++ b/source/ROS-Framework/nodes/About-Logging/About-Logging.rst @@ -381,4 +381,4 @@ Logging usage .. group-tab:: Python * See the `rclpy examples `__ for example usage of a node's logger. - * See the `rclpy tests `__ for example usage of keyword arguments (e.g. ``skip_first``, ``once``). \ No newline at end of file + * See the `rclpy tests `__ for example usage of keyword arguments (e.g. ``skip_first``, ``once``). diff --git a/source/ROS-Framework/nodes/Working-with-nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes.rst index a0552bd1560..34b8321d086 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes.rst @@ -16,4 +16,4 @@ PLACEHOLDER Working-with-nodes/Using-Node-Interfaces-Template-Class Working-with-nodes/Managed-Nodes Working-with-nodes/intra-process/Intra-Process-Communication - Working-with-nodes/Using-callback-groups \ No newline at end of file + Working-with-nodes/Using-callback-groups diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst b/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst index 66d50f784e6..601297cb3dd 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Composition.rst @@ -428,4 +428,4 @@ To create a component that is not derived from a node, follow these guidelines: Here's an example of a component that is not derived from a node, which listens to a ROS topic: `node_like_listener_component `__. -For more information on this topic, you can refer to this `discussion `__. \ No newline at end of file +For more information on this topic, you can refer to this `discussion `__. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst index 85e9705389e..51c5fea7c34 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Launching-Multiple-Nodes/Launching-Multiple-Nodes.rst @@ -103,4 +103,4 @@ For more tutorials on ROS 2 launch files, see the :doc:`main launch file tutoria Next steps ---------- -In the next tutorial, :doc:`../../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data`, you'll learn about another helpful tool, ``ros2 bag``. \ No newline at end of file +In the next tutorial, :doc:`../../../interfaces/Working-with-interfaces/Recording-And-Playing-Back-Data/Recording-And-Playing-Back-Data`, you'll learn about another helpful tool, ``ros2 bag``. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst index 1370ccfc609..23259775cc2 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Managed-Nodes.rst @@ -52,4 +52,4 @@ Packages/reference: * `rclcpp_lifecycle `_ (implementation library): Package containing a prototype for lifecycle implementation. * `lifecycle_msgs `_ (interface definitions): Package containing some lifecycle related message and service definitions. -* `lifecycle `_: Package containing demos for lifecycle implementation. \ No newline at end of file +* `lifecycle `_: Package containing demos for lifecycle implementation. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst b/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst index 4aa1bffb351..2485028590e 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Understanding-ROS2-Nodes/Understanding-ROS2-Nodes.rst @@ -194,4 +194,4 @@ Topics are one of the communication types that connects nodes. Related content --------------- -The :doc:`../../../../Concepts` page adds some more detail to the concept of nodes. \ No newline at end of file +The :doc:`../../../../Concepts` page adds some more detail to the concept of nodes. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst index 3a78dee8384..932118d0b9c 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-Node-Interfaces-Template-Class.rst @@ -249,4 +249,4 @@ However, they are not included for demonstration purposes. In the main function, a ``SharedPtr`` to both ``rclcpp_lifecycle::LifecycleNode`` and ``rclcpp::Node`` is created. The function declared above is called once with each node type as an argument. -.. note:: The ``SharedPtr`` needs to be dereferenced as the template accepts a reference to the ``NodeT`` object. \ No newline at end of file +.. note:: The ``SharedPtr`` needs to be dereferenced as the template accepts a reference to the ``NodeT`` object. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst index 01b9107bd5f..4cb71b0c06b 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-Rqt-Console/Using-Rqt-Console.rst @@ -130,4 +130,4 @@ You might want to examine log messages for any number of reasons, usually to fin Next steps ---------- -The next tutorial will teach you about starting multiple nodes at once with :doc:`ROS 2 Launch <../Launching-Multiple-Nodes/Launching-Multiple-Nodes>`. \ No newline at end of file +The next tutorial will teach you about starting multiple nodes at once with :doc:`ROS 2 Launch <../Launching-Multiple-Nodes/Launching-Multiple-Nodes>`. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst b/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst index 9023216154a..1879863d019 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Using-callback-groups.rst @@ -579,4 +579,4 @@ repeatedly and service calls are completed. .. code-block:: python client_cb_group = ReentrantCallbackGroup() - timer_cb_group = None \ No newline at end of file + timer_cb_group = None diff --git a/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst b/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst index f0ef3231fc7..95d905c7fc5 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/Writing-a-Composable-Node.rst @@ -172,4 +172,4 @@ you can replace it with .. caution:: - If you need multi-threading, simply add the ``--executor-type multi-threaded`` argument to your container node. \ No newline at end of file + If you need multi-threading, simply add the ``--executor-type multi-threaded`` argument to your container node. diff --git a/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst b/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst index 170bb14b01b..06f164077df 100644 --- a/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst +++ b/source/ROS-Framework/nodes/Working-with-nodes/intra-process/Intra-Process-Communication.rst @@ -391,4 +391,4 @@ This will look something like this: It's hard to pause both images at the same time so the images may not line up, but the important thing to notice is that the ``image_pipeline_all_in_one`` image view shows the same address for each step. This means that the intra-process zero-copy is preserved even when an external view is subscribed as well. -You can also see that the inter-process image view has different process IDs for the first two lines of text and the process ID of the standalone image viewer in the third line of text. \ No newline at end of file +You can also see that the inter-process image view has different process IDs for the first two lines of text and the process ID of the standalone image viewer in the third line of text. diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst index 8f955cddba1..5ead393226c 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-CPP.rst @@ -461,4 +461,4 @@ The ParameterEventHandler is a convenient way to monitor for parameter changes s Related content --------------- -To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` tutorial. \ No newline at end of file +To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` tutorial. diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst index 38fd683e2b7..3e411096311 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Monitoring-For-Parameter-Changes-Python.rst @@ -453,4 +453,4 @@ The ParameterEventHandler is a convenient way to monitor for parameter changes s Related content --------------- -To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` tutorial. \ No newline at end of file +To learn how to adapt ROS 1 parameter files for ROS 2, see the :doc:`Migrating YAML parameter files from ROS 1 to ROS2 <../../../Migration-and-Upgrades/Migrating-from-ROS1/Migrating-Parameters>` tutorial. diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst b/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst index a8bd7e9cfd7..e0003a827c3 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.rst @@ -249,4 +249,4 @@ You can also save the parameter settings to a file to reload them in a future se Next steps ---------- -Jumping back to ROS 2 communication methods, in the next tutorial you'll learn about :doc:`actions <../../../interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. \ No newline at end of file +Jumping back to ROS 2 communication methods, in the next tutorial you'll learn about :doc:`actions <../../../interfaces/actions/Working-with-actions/Understanding-ROS2-Actions/Understanding-ROS2-Actions>`. diff --git a/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst b/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst index 22fe33e8a86..f8e00ba2923 100644 --- a/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst +++ b/source/ROS-Framework/parameters/Working-with-parameters/Using-ros2-param.rst @@ -128,4 +128,4 @@ That is, this command can reload values at runtime that were dumped out by ``ros .. code-block:: console - $ ros2 param load /my_node my_node.yaml \ No newline at end of file + $ ros2 param load /my_node my_node.yaml From 8fe3d7a05ef8775202678b4d53f0c99b431a18de Mon Sep 17 00:00:00 2001 From: Denise Marshall Date: Mon, 8 Jun 2026 14:33:26 +0000 Subject: [PATCH 20/20] Removed trailing whitespace --- source/Capabilities/About-Manipulation.rst | 2 +- source/Capabilities/About-Motion-planning.rst | 2 +- source/Capabilities/About-Navigation.rst | 2 +- source/Capabilities/About-Perception.rst | 2 +- source/Capabilities/About-Simulation.rst | 2 +- source/Developer-Tools.rst | 11 +- .../About-package-documentation.rst | 2 +- source/Developer-Tools/About-testing.rst | 2 +- source/Get-Started.rst | 2 +- source/Get-Started/Installation.rst | 178 +++++++++--------- source/Get-Started/Releases.rst | 2 +- .../interfaces/About-Actions.rst | 132 ++++++------- .../interfaces/About-Interfaces.rst | 2 +- .../ROS-Framework/interfaces/About-Topics.rst | 132 ++++++------- .../interfaces/Working-with-interfaces.rst | 2 +- .../actions/Working-with-actions.rst | 2 +- .../services/Working-with-services.rst | 2 +- .../interfaces/topics/Working-with-topics.rst | 2 +- .../nodes/Working-with-nodes.rst | 2 +- .../parameters/Working-with-parameters.rst | 4 +- 20 files changed, 239 insertions(+), 248 deletions(-) diff --git a/source/Capabilities/About-Manipulation.rst b/source/Capabilities/About-Manipulation.rst index 5b0e543789c..2da9fd96900 100644 --- a/source/Capabilities/About-Manipulation.rst +++ b/source/Capabilities/About-Manipulation.rst @@ -4,7 +4,7 @@ Manipulation .. toctree:: :maxdepth: 1 :hidden: - + .. list of child topics here .. contents:: Table of Contents diff --git a/source/Capabilities/About-Motion-planning.rst b/source/Capabilities/About-Motion-planning.rst index 695e36a0ae6..6268257b096 100644 --- a/source/Capabilities/About-Motion-planning.rst +++ b/source/Capabilities/About-Motion-planning.rst @@ -4,7 +4,7 @@ Motion planning .. toctree:: :maxdepth: 1 :hidden: - + Motion-planning/Real-Time-Programming .. contents:: Table of Contents diff --git a/source/Capabilities/About-Navigation.rst b/source/Capabilities/About-Navigation.rst index e1268e3ad82..bcc82f5175d 100644 --- a/source/Capabilities/About-Navigation.rst +++ b/source/Capabilities/About-Navigation.rst @@ -4,7 +4,7 @@ Navigation .. toctree:: :maxdepth: 1 :hidden: - + .. list of child topics here .. contents:: Table of Contents diff --git a/source/Capabilities/About-Perception.rst b/source/Capabilities/About-Perception.rst index eee53637937..35f79a93adf 100644 --- a/source/Capabilities/About-Perception.rst +++ b/source/Capabilities/About-Perception.rst @@ -4,7 +4,7 @@ Perception .. toctree:: :maxdepth: 1 :hidden: - + .. list of child topics here .. contents:: Table of Contents diff --git a/source/Capabilities/About-Simulation.rst b/source/Capabilities/About-Simulation.rst index 231f53bdd6f..660ee533c69 100644 --- a/source/Capabilities/About-Simulation.rst +++ b/source/Capabilities/About-Simulation.rst @@ -4,7 +4,7 @@ Simulation .. toctree:: :maxdepth: 1 :hidden: - + Simulation/URDF/URDF-Main Simulation/dummy-robot/dummy-robot-demo diff --git a/source/Developer-Tools.rst b/source/Developer-Tools.rst index a12ef401305..1d470b9db3f 100644 --- a/source/Developer-Tools.rst +++ b/source/Developer-Tools.rst @@ -6,7 +6,7 @@ PLACEHOLDER .. toctree:: :maxdepth: 3 - + Developer-Tools/About-introspection-and-analysis Developer-Tools/About-Debugging Developer-Tools/About-Build @@ -14,12 +14,3 @@ PLACEHOLDER Developer-Tools/About-package-documentation Developer-Tools/About-Launch Developer-Tools/About-testing - - -* Introspection -* Analysis -* Node management -* Debugging -* Builds -* Visualization -* Package documentation diff --git a/source/Developer-Tools/About-package-documentation.rst b/source/Developer-Tools/About-package-documentation.rst index 0686daf2b3b..1d78aa8f6a8 100644 --- a/source/Developer-Tools/About-package-documentation.rst +++ b/source/Developer-Tools/About-package-documentation.rst @@ -6,5 +6,5 @@ PLACEHOLDER .. toctree:: :maxdepth: 3 - + Package-documentation/Documenting-a-ROS-2-Package diff --git a/source/Developer-Tools/About-testing.rst b/source/Developer-Tools/About-testing.rst index 7dec9c91466..b5178c27f3d 100644 --- a/source/Developer-Tools/About-testing.rst +++ b/source/Developer-Tools/About-testing.rst @@ -14,4 +14,4 @@ PLACEHOLDER Testing/Testing/Integration Testing/Testing/BuildFarmTesting Testing/Overriding-QoS-Policies-For-Recording-And-Playback - + diff --git a/source/Get-Started.rst b/source/Get-Started.rst index cbf56226791..63c907b6b7f 100644 --- a/source/Get-Started.rst +++ b/source/Get-Started.rst @@ -7,7 +7,7 @@ PLACEHOLDER .. toctree:: :maxdepth: 3 - + Get-Started/About-ROS/About-ROS Get-Started/Installation Get-Started/Releases diff --git a/source/Get-Started/Installation.rst b/source/Get-Started/Installation.rst index 6379a57a578..5d14c3ba5d7 100644 --- a/source/Get-Started/Installation.rst +++ b/source/Get-Started/Installation.rst @@ -1,90 +1,90 @@ -.. redirect-from:: - - Installation - -.. _InstallationGuide: -.. _RollingInstall: - -Installation -============ - -Options for installing ROS 2 {DISTRO_TITLE_FULL}: - -.. toctree:: - :maxdepth: 1 - - Installation/Ubuntu-Install-Debs - Installation/Windows-Install-Binary - Installation/RHEL-Install-RPMs - Installation/Alternatives - Installation/RMW-Implementations - Installation/ROS-2-Mirrors - Installation/Installing-on-Raspberry-Pi - Installation/Installation-Troubleshooting - -.. _binary-package-platforms: - -Binary packages ---------------- - -Binaries are only created for the Tier 1 operating systems listed in :doc:`Lyrical Luth release docs `. -If you are not running any of the following operating systems you may need to build from source or use a :doc:`container solution <../Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers>` to run ROS 2 on your platform. - -We provide ROS 2 binary packages for the following platforms: - -* Ubuntu Linux (amd64 / aarch64) - Resolute Raccoon (26.04) - - * :doc:`deb packages ` (recommended) - * :doc:`binary archive ` - -* Red Hat Enterprise Linux 10 (amd64) - - * :doc:`RPM packages ` (recommended) - * :doc:`binary archive ` - -* Windows 11 (amd64) - - * :doc:`Windows Binary (VS 2019) ` - -.. _building-from-source: - -Building from source --------------------- - -We support building ROS 2 from source on the following platforms: - -* :doc:`Ubuntu Linux 26.04 ` -* :doc:`Ubuntu Linux 26.04 (Pixi) ` -* :doc:`Windows 11 ` -* :doc:`RHEL-10/Fedora ` -* :doc:`macOS ` - -Which install should you choose? --------------------------------- - -Installing from binary packages or from source will both result in a fully-functional and usable ROS 2 install. -Differences between the options depend on what you plan to do with ROS 2. - -**Binary packages** are for general use and provide an already-built install of ROS 2. -This is great for people who want to dive in and start using ROS 2 as-is, right away. - -Linux users have two options for installing binary packages: - -- Packages (debs or RPMS, depending on the platform) -- binary archive - -Installing from packages is the recommended method, as it installs necessary dependencies automatically and also updates alongside regular system updates. -However, you need root access in order to install deb packages. -If you don't have root access, the binary archive is the next best choice. - -Windows users who choose to install from binary packages only have the binary archive option -(deb packages are exclusive to Ubuntu/Debian). - -**Building from source** is meant for developers looking to alter or explicitly omit parts of ROS 2's base. -It is also recommended for platforms that don't support binaries. -Building from source also gives you the option to install the absolute latest version of ROS 2. - -Contributing to ROS 2 core? -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - +.. redirect-from:: + + Installation + +.. _InstallationGuide: +.. _RollingInstall: + +Installation +============ + +Options for installing ROS 2 {DISTRO_TITLE_FULL}: + +.. toctree:: + :maxdepth: 1 + + Installation/Ubuntu-Install-Debs + Installation/Windows-Install-Binary + Installation/RHEL-Install-RPMs + Installation/Alternatives + Installation/RMW-Implementations + Installation/ROS-2-Mirrors + Installation/Installing-on-Raspberry-Pi + Installation/Installation-Troubleshooting + +.. _binary-package-platforms: + +Binary packages +--------------- + +Binaries are only created for the Tier 1 operating systems listed in :doc:`Lyrical Luth release docs `. +If you are not running any of the following operating systems you may need to build from source or use a :doc:`container solution <../Developer-Tools/Build/Run-2-nodes-in-single-or-separate-docker-containers>` to run ROS 2 on your platform. + +We provide ROS 2 binary packages for the following platforms: + +* Ubuntu Linux (amd64 / aarch64) - Resolute Raccoon (26.04) + + * :doc:`deb packages ` (recommended) + * :doc:`binary archive ` + +* Red Hat Enterprise Linux 10 (amd64) + + * :doc:`RPM packages ` (recommended) + * :doc:`binary archive ` + +* Windows 11 (amd64) + + * :doc:`Windows Binary (VS 2019) ` + +.. _building-from-source: + +Building from source +-------------------- + +We support building ROS 2 from source on the following platforms: + +* :doc:`Ubuntu Linux 26.04 ` +* :doc:`Ubuntu Linux 26.04 (Pixi) ` +* :doc:`Windows 11 ` +* :doc:`RHEL-10/Fedora ` +* :doc:`macOS ` + +Which install should you choose? +-------------------------------- + +Installing from binary packages or from source will both result in a fully-functional and usable ROS 2 install. +Differences between the options depend on what you plan to do with ROS 2. + +**Binary packages** are for general use and provide an already-built install of ROS 2. +This is great for people who want to dive in and start using ROS 2 as-is, right away. + +Linux users have two options for installing binary packages: + +- Packages (debs or RPMS, depending on the platform) +- binary archive + +Installing from packages is the recommended method, as it installs necessary dependencies automatically and also updates alongside regular system updates. +However, you need root access in order to install deb packages. +If you don't have root access, the binary archive is the next best choice. + +Windows users who choose to install from binary packages only have the binary archive option +(deb packages are exclusive to Ubuntu/Debian). + +**Building from source** is meant for developers looking to alter or explicitly omit parts of ROS 2's base. +It is also recommended for platforms that don't support binaries. +Building from source also gives you the option to install the absolute latest version of ROS 2. + +Contributing to ROS 2 core? +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + If you plan to contribute directly to ROS 2 core packages, you can install the :doc:`latest development from source ` which shares installation instructions with the :ref:`Rolling distribution `. diff --git a/source/Get-Started/Releases.rst b/source/Get-Started/Releases.rst index 87e4f9b171a..0590a307148 100644 --- a/source/Get-Started/Releases.rst +++ b/source/Get-Started/Releases.rst @@ -35,7 +35,7 @@ Rows in the table marked in blue are the currently supported distributions. Releases/Release-Rolling-Ridley Releases/Development Releases/End-of-Life - + .. raw:: html